RE: XPath number with 20 digits gives you a head ache

> Results from XSLT processors I have on my machine:
>
>   Output                XSLT Processor
>   ======================================
>   92125374252539904000  SAXON 6.1
>                         Xalan-C 1.0
>                         UXT 1.03.00
>                         XT
>   92125374252539900000  Xalan-J 2.0.D07
>                         Xalan-J 1.2.2
>                         MSXML 3.0
>   9.21253742525399E19   Oracle V2 (beta)
>   2147483647            iXSLT 2.0c
>
> Interesting. Which, if any, is actually right?

After some discussion on this a few months ago, James Clark persuaded me
that the algorithm I was using in Saxon didn't meet the spec and that xt's
did, so I simply switched to using his code.

Oracle's output is definitely wrong: the result should never be in
scientific notation.

> BTW, would SAXON
> optimize e.g.
>
>   <xsl:value-of select="number(string('42'))" />
>
> to
>
>   <xsl:value-of select="42" />

> during stylesheet preparation?

Yes, any constant expression will be evaluated at compile time.

> And even though no one would ever write
> something like
>
>   <xsl:if test="foo[boolean(contains(., 'get something better
> to read')) =
> boolean(number(string(substring('24',1))))]">
>
> would it be optimized somehow before executing the stylesheet to
>
>   <xsl:if test="foo[contains(., 'get something better to read')]">
>
> or something in those lines?

Yes, boolean(number(string(substring('24',1)))) is a constant sub-expression
which will be evaluated at compile-time to "true", and "XXXX = true" will be
optimized to "XXXX".

Perhaps more interesting, if you substitute $x for '24' in the above, the
optimisation will be done when the predicate is prepared for evaluation,
i.e. the common subexpression won't be evaluated for each element of the
node-set foo.

Mike Kay
>


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list