Subject: RE: [xsl] The Perils of Sudden Type-Safety in XPath 2.0 From: "Michael Kay" <michael.h.kay@xxxxxxxxxxxx> Date: Wed, 19 Feb 2003 21:07:10 -0000 |
> 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. In XPath 1.0 it would yield the double value 10.0, which is displayed as "10". In XPath 2.0 it yields the decimal 10.0. There is still some debate going on about how insignificant zeros should be handled by XPath 2.0 when converting a decimal or a double to a string. > > 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? "Backwards compatibility mode" in XPath 2.0 affects a small number of well-defined things. For example, it allows a string to be compared to a number, and it allows a number to be supplied as an argument to a function that expects a string. It also enables the "first node" rule when a node-set is supplied to a function expecting a string. It doesn't make everything behave as in XPath 1.0, for example 10.5 is still treated as a decimal literal not a double literal, so the precision of arithmetic results may change. It's worth checking the backwards compatibility appendix of the XPath 2.0 specification for things that have changed even if you set backwards compatibility mode, and even if you have no schema. The last published version is at http://www.w3.org/TR/xpath20/#id-backwards-compatibility - with luck the final list will be shorter than this. The decision in Saxon 7.4 to switch XPath backwards compatibility mode on when the version attribute is set to 1.0 is one that anticipates the XSLT specification, no final decision has yet been made about how this will be controlled from XSLT. (Note that you can now set the version attribute on any XSLT element, with local scope). > But I'll > still have the benefit of using, for example, xsl:for-each-group? Again, the spec isn't set in concrete, I'm making "best guesses" in Saxon 7.x, but my current thinking is that an XSLT 2.0 processor will not disable XSLT 2.0 or XPath 2.0 features just because you have set version="1.0". Michael Kay Software AG home: Michael.H.Kay@xxxxxxxxxxxx work: Michael.Kay@xxxxxxxxxxxxxx XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] The Perils of Sudden Type, Kurt Cagle | Thread | Re: [xsl] The Perils of Sudden Type, Tobias Reif |
[xsl] What's the new Java (1.4) com, William Reilly | Date | RE: [xsl] The Perils of Sudden Type, Michael Kay |
Month |