Subject: Re: [xsl] The Perils of Sudden Type-Safety in XPath 2.0 From: "Charles White" <chuck@xxxxxxxxxxx> Date: Wed, 19 Feb 2003 11:42:26 -0800 |
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: [xsl] 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] The Perils of Sudden Type, Jeni Tennison | Thread | RE: [xsl] The Perils of Sudden Type, Michael Kay |
Re: [xsl] xsl:if test="contains" OR, Michael A. Thompson | Date | [xsl] Re: The Perils of Sudden Type, Dimitre Novatchev |
Month |