RE: [xsl] The Perils of Sudden Type-Safety in XPath 2.0

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 -
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

Michael Kay
Software AG
home: Michael.H.Kay@xxxxxxxxxxxx
work: Michael.Kay@xxxxxxxxxxxxxx 

 XSL-List info and archive:

Current Thread