XPath 2.0 conformance

Saxon for many years has implemented the full XPath 2.0 language as defined in the Second Edition Recommendation of 14 December 2010.

Recent Saxon releases focus primarily on XPath 3.1 support, and deliver XPath 2.0 when required by restricting some of the capabilities of the XPath 3.1 processor. For example, this is the default for XPath expressions appearing within assertions or conditional type alternatives in XSD 1.1 schemas. However, a few constructs behave as defined in XPath 3.1 even when 2.0 is requested: details appear below.

• In 2.0 mode, syntatic constructs defined only in 3.0/3.1 are generally disallowed. These include:

  • Let expressions
  • Inline functions, dynamic function calls, function literals, and partially-applied functions
  • New operators: ||, !, ?, =>
  • Map and array constructor expressions
  • EQNames in the format Q{uri}local

• Functions in the standard function library are added to the static context only if they were available in XPath 2.0

SaxonJ-EE 11.1 passes 15338 out of 15341 applicable XPath 2.0 tests in the W3C test suite.

SaxonCS 11.1 passes 15295 out of 15298 applicable XPath 2.0 tests in the W3C test suite.

The failures occur in cases where XPath 3.1 relaxes the rules and it is not practical or sensible for Saxon to enforce several different sets of constraints. In particular:

• XPath 2.0 only allowed casting of a string to a QName if the string was written as a literal. This restriction was always difficult to enforce because it straddles the boundaries between the lexical and semantic parts of the compiler, and it also serves very little purpose, so Saxon no longer enforces it.
• XPath 2.0 required the first argument to fn:string-join to be of type xs:string*, while XPath 3.1 allows xs:anyAtomicType*, and casts the supplied values to strings.
• XPath 3.1 extends what is allowed in the picture string of fn:format-number().

The general rule is that when Saxon acts as an XPath 2.0 processor, all correct (non-error) inputs produce a conformant result, but a small number of error cases are not detected.

There are also a few situations where XPath 3.1 chose to introduce incompatible changes. For example, fn:format-time() was changed in 3.1 to truncate the fractional seconds value rather than rounding it. In such cases Saxon follows the XPath 3.1 rules, since the change was made for good reasons.