Saxonica.com

Changes in XPath 2.0 Processing

Namespace URIs have been updated as defined in the October 2004 draft specifications: for example http://www.w3.org/2004/10/xpath-functions and http://www.w3.org/2004/10/xpath-datatypes.

The right-hand operand of the "/" operator can now be an expression of any type. (The left-hand operand must still return nodes, which means that in a path expression, every step except the last must return nodes.) If the expression returns atomic values, no sorting into document order or removal of duplicates takes place. A type error occurs if the returned value contains a mixture of nodes and atomic values. This facility allows expressions such as sum(//item/(@price * @qty)), eliminating the need for range variables in many situations..

The revised rules for backwards compatible processing in general comparisons have been implemented. These are much closer to the XPath 1.0 rules. Most notably, an expression such as @price > @discount where both attributes are untyped is now a numeric comparison rather than a string comparison. Backwards-compatible mode is invoked in an XSLT stylesheet specifying version="1.0".

The revised rules for backwards compatibility in arithmetic expressions have been implemented. The main changes are (a) numeric arithmetic always produces an xs:double result (never an integer or a decimal - except in the case of the idiv operator), (b) arguments that can't be converted to a number generate NaN (rather than an error or an empty sequence).

Compile-time warning messages are now produced for steps in path expressions that can never retrieve any nodes, for example child::text() if the context node is an attribute, or .. if the context node is a document node.

Next