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. In particular,
During parsing of the XPath expression, new syntatic constructs are 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
Functions in the standard function library are added to the static context only if they were available in XPath 2.0
Saxon-EE 9.9 passes 15238 out of 15242 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-jointo 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
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,
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.