Saxon XSLT and XQuery Processor

> It seems to me that the >= operator and similar operators should imply
> conversion of any string arguments to numbers.

No, they do in 1.0 but 2.0 supports ordering operations on strings so if
you supply two strings they are ordered according to the default
collation.

David

Yes, there's an incompatibility here between XPath 1.0 and 2.0. In 1.0, the
"=" operator compares values as they are. But the < and > operators convert
both operands to numbers. This has the strange effect that

"4" <= "4.0"
and
"4" >= "4.0"
are both true, but
"4" = "4.0"
is false.

In 2.0, there's no implicit conversion: strings are compared as strings,
using the default collating sequence, and if you want them compared as
numbers, you have to convert them.

You can retain the 1.0 behaviour by using backwards-compatibility mode,
activated when version="1.0" appears in the xsl:stylesheet element (or
elsewhere).

Michael Kay
http://www.saxonica.com/ 

> -----Original Message-----
> From: saxon-help-bounces@... 
> [mailto:saxon-help-bounces@...] On Behalf 
> Of Jay Bryant
> Sent: 23 August 2006 22:11
> To: saxon-help@...
> Subject: [saxon] Implicit conversion from string to number in Saxon 8
> 
> Hi, Mike,
> 
> I was working with the DocBook stylesheets today when I 
> bumped into something that struck me as an odd issue.
> 
> A named template contains (among other things) the following choose
> statement:
> 
> <xsl:choose>
>   <xsl:when test="$ecol &gt;= $scol">
>     <xsl:value-of select="$ecol - $scol + 1"/>
>   </xsl:when>
>   <xsl:otherwise>
>     <xsl:value-of select="$scol - $ecol + 1"/>
>   </xsl:otherwise>
> </xsl:choose>
> 
> When $ecol = 10 and $scol = 9, the otherwise part of the 
> statements gets chosen. I assume that happens because they 
> are both strings and because 1 precedes 9 in the character order.
> 
> I modified the statement as follows:
> 
> <xsl:choose>
>   <xsl:when test="number($ecol) &gt;= ($scol)">
>     <xsl:value-of select="$ecol - $scol + 1"/>
>   </xsl:when>
>   <xsl:otherwise>
>     <xsl:value-of select="$scol - $ecol + 1"/>
>   </xsl:otherwise>
> </xsl:choose>
> 
> Then it worked as expected.
> 
> It seems to me that the &gt;= operator and similar operators 
> should imply conversion of any string arguments to numbers. 
> However, I thought perhaps some item in the XSTL 2.0 spec 
> might prevent such implicit conversion, so I thought I'd ask.
> 
> Thanks.
> 
> Jay Bryant
> Bryant Communication Services
> 
> 
> 
> --------------------------------------------------------------
> -----------
> Using Tomcat but need to do more? Need to support web 
> services, security?
> Get stuff done quickly with pre-integrated technology to make 
> your job easier Download IBM WebSphere Application Server 
> v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&;
> dat=121642
> _______________________________________________
> saxon-help mailing list
> saxon-help@...
> https://lists.sourceforge.net/lists/listinfo/saxon-help

> Yes, there's an incompatibility here between XPath 1.0 and 2.0. In 1.0,
the
> "=" operator compares values as they are. But the < and > operators
convert
> both operands to numbers. This has the strange effect that
>
> "4" <= "4.0"
> and
> "4" >= "4.0"
> are both true, but
> "4" = "4.0"
> is false.
>
> In 2.0, there's no implicit conversion: strings are compared as strings,
> using the default collating sequence, and if you want them compared as
> numbers, you have to convert them.
>
> You can retain the 1.0 behaviour by using backwards-compatibility mode,
> activated when version="1.0" appears in the xsl:stylesheet element (or
> elsewhere).
>

Hi, Mike,

All the stylesheets in question have version="1.0" in the xsl:stylesheet
element, but I still got the behavior.

It's not a big deal (I can use Saxon 6 to turn DocBook into PDF), but I
thought I'd mention it.

Thanks.

Jay Bryant
Bryant Communication Services