Re: The Perils of Sudden Type-Safety in XPath 2.0

What a fantastic explanation! It's like somebody just opened a curtain that
had covered my eyes. I've been running some tests on Saxon 7.4, and I'm sure
that will help further.

Thank-you!!

~ chuck white

Chuck White
Author, Mastering XSLT, Sybex Books
http://www.javertising.com/webtech
http://www.tumeric.net
----- Original Message -----
From: "Jeni Tennison" <jeni@xxxxxxxxxxxxxxxx>
To: "Charles White" <chuck@xxxxxxxxxxx>
Cc: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, February 19, 2003 11:21 AM
Subject: Re:  The Perils of Sudden Type-Safety in XPath 2.0


> Hi Chuck,
>
> > Just to help clarify, then, if I have an expression in XSLT 2.0 like
> > this: 4.5 + 5.5
> >
> > it should yield 10.0 in XPath 2.0, right?
> >
> > This would have yielded 10 in XSLT 1.0.
>
> Well, if you had the literals 4.5 and 5.5 they would both be
> interpreted as values of the type xs:decimal. If you add two decimals
> together, you get another decimal as a result, so the result of the
> expression "4.5 + 5.5" is the decimal value 10.0.
>
> On the other hand, if you had two untyped attributes, one with the
> value "4.5" and the other with the value "5.5" then when you added
> them together they'd be converted to doubles and the result would be
> the double value 10E0.
>
> If you use <xsl:value-of> to convert either a decimal or a double to a
> string then the way it gets serialised now depends on the value of the
> decimal or double. This isn't yet in the public drafts, but in Saxon's
> implementation the idea is that if there aren't any significant digits
> after the decimal point then it is serialised as an integer, so that
> you get "10". (Also, I think that if it's a fairly small or very large
> double then an appropriate exponent will be used; I couldn't find
> these large/small numbers in testing with Saxon 7.4 so either Mike
> hasn't implemented that or I'm misremembering.)
>
> > If I am using an XSLT 2.0 compliant processor, and I want to
> > maintain my original results, is the solution as you described to
> > Gunther, to keep the version attribute value at "1.0" and that
> > otherwise XPath 2.0 casting takes over and therefore the result will
> > be an xs:decimal type? But I'll still have the benefit of using, for
> > example, xsl:for-each-group?
>
> Setting the XPath 1.0 compatibility mode on using version="1.0" should
> mean that any XPath 1.0 expression will give the same results as it
> used to. The places where it doesn't are listed in Appendix F of XPath
> 2.0 at:
>
>   http://www.w3.org/TR/xpath20/#id-backwards-compatibility
>
> If you find something that isn't listed there, you should let the WG
> know by writing to public-qt-comments@xxxxxxx
>
> Using version="1.0" with XPath 2.0 expressions gives you:
>
>   - First item semantics when passing a sequence to a function that
>     expects a single item. For example, if you pass a function that
>     expects a single node a sequence of five nodes then it will pick
>     the first one whereas under XPath 2.0 it will give an error.
>
>   - Automatic conversion to a string when passing a value to a
>     function that expects a string. For example, if you pass
>     substring() the current-dateTime() as the first argument then it
>     will be converted to a string in backwards compatible mode whereas
>     under XPath 2.0 it will give an error.
>
>   - Automatic conversion to a double when passing a value to a
>     function that expects a double.
>
>   - Automatic conversion to a double of operands in arithmetic
>     expressions. For example if you try to subtract one xs:date from
>     another then you'll get the double NaN under the backwards
>     compatibility rules whereas under XPath 2.0 you will get the
>     xdt:dayTimeDuration between the two dates.
>
>   - Automatic conversion to a double of the items in operands in
>     general comparisons when either operand sequence contains a
>     numeric value. For example, 1 = '1' should, I think, be true in
>     backwards compatibility mode as it is in XPath 1.0, whereas in
>     XPath 2.0 it will give an error because integers cannot be
>     compared to strings.
>
> Using version="1.0" with an XSLT 2.0 processor does not prevent you
> from using XSLT 2.0 and XPath 2.0 constructs such as conditional
> expressions and <xsl:for-each-group>. Note that this means that if you
> want to make sure that a stylesheet works under XSLT 1.0, you have to
> test it with an XSLT 1.0 processor rather than an XSLT 2.0 processor.
>
> Cheers,
>
> Jeni
>
> ---
> Jeni Tennison
> http://www.jenitennison.com/
>
>


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