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

Expand | Up Next