XPath 3.1 Conformance

Saxon 9.9 implements the final XPath 3.1 Recommendation in its entirety.

At the time of release Saxon-EE 9.9 passes all 22049 applicable tests in the W3C XPath/XQuery test suite (QT3). Tests are run on both the Java and .NET platforms.

Although the W3C XQuery Working Group has ceased operation, the W3C QT3 test suite continues to be developed by volunteers, and Saxonica remains an active contributor. The test suite can be found at https://github.com/w3c/qt3tests. Tests are labeled to indicate which specifications (XPath/XQuery) and versions they apply to. Conformance issues raised by Saxon users typically result in new test cases being added to the test suite.

New features that were introduced in XPath 3.0 include the following:

• String contatenation operator ||

• Simple mapping operator !

• Casting is allowed from a string to a union or list type

• Union types, provided they meet certain rules, can be used as a SequenceType

• Higher order functions, including:

  • Inline functions, for example function($i) {$i*$i}
  • Dynamic function calls
  • Function literals, for example substring#2
  • Partial function application, for example concat('$', ?)

• Let expressions, for example let $v := expr return f($v)

• EQNames (Q{uri}local) wherever QNames are allowed

XPath 3.1 added:

• Support for maps and arrays

• Functions to read and write data in JSON format

• A new operator (=>) to allow function chaining

• Various new functions including random-number-generator(), sort(), parse-ietf-date().

Implementation-defined aspects of Functions and Operators

The Functions and Operators specification includes a number of implementation-defined behaviors. This section describes how these are implemented in Saxon.

1. The destination of the trace for fn:trace() output is implementation-defined.

   ► By default trace output is sent to the standard error output. It can be redirected in various ways: by redirecting System.err, by supplying a user-written MessageEmitter, or by changing the output destination of the standard MessageEmitter to a defined output stream or writer.

2. For [overflow during] xs:integer operations, implementations that support limited-precision integer operations must either raise an error [err:FOAR0002] or provide an implementation-defined mechanism that allows users to choose between raising an error and returning a result that is modulo the largest representable integer value.

   ► Saxon supports unlimited-precision integer arithmetic, so this provision does not apply.

3. For xs:decimal values the number of digits of precision returned by the numeric operators is implementation-defined. If the number of digits in the result exceeds the number of digits that the implementation supports, the result is truncated or rounded in an implementation-defined manner.

   ► Saxon supports unlimited-precision decimal arithmetic. For addition, subtraction, and multiplication, no rounding or truncation occurs; the full precision of the result is maintained. For division, the number of digits in the result is: the number of digits in the numerator, the number of digits in the divisor, or 18, whichever is greatest. Rounding of values in the range .0 to .5 inclusive is towards zero, otherwise away from zero.

4. It is implementation-defined which version of Unicode is supported by the features defined in this specification, but it is recommended that the most recent version of Unicode be used.

   ► For the Unicode character categories used in regular expressions, Saxon (since release 9.4) uses the tables from Unicode 6.0.0. For Unicode blocks in regular expressions, Saxon uses the definitions in Unicode 6.0.0, but also supports block names (such as "Greek") from earlier Unicode versions where the blocks have since been renamed.

   Some functions such as the implementations of upper-case() and lower-case() are delegated to the Java VM, and the result therefore depends on the Unicode version supported by the Java VM. In JDK 5.0 this is Unicode version 4.0.

   Other functions such as normalize-unicode() are implemented natively within Saxon. The character tables used for this are derived from the Unicode 4.0 database.

5. For normalize-unicode(), conforming implementations must support normalization form "NFC" and may support normalization forms "NFD", "NFKC", "NFKD", "FULLY-NORMALIZED". They may also support other normalization forms with implementation-defined semantics.

   ► Saxon currently supports normalization forms NFC, NFD, NFKC, and NFKD.

6. The ability to decompose strings into collation units suitable for substring matching is an implementation-defined property of a collation.

   ► Saxon supports this capability for a collation implemented using a Java RuleBasedCollator. Any Java Comparator can be used to implement a collation, but the substring matching functions will fail (error FOCH0004) if the Comparator is not a RuleBasedCollator.

   Saxon also supports this capability on the .NET platform. However, the results delivered by the collation support on the .NET platform do not appear to be 100% aligned with the XPath specification.

7. All minimally conforming processors must support year values with a minimum of 4 digits (i.e., YYYY) and a minimum fractional second precision of 1 millisecond or three digits (that is, s.sss). However, conforming processors may set larger implementation-defined limits on the maximum number of digits they support in these two situations.

   ► Saxon allows the year to be any 32-bit signed integer. The interpretation of negative years depends on whether the system is configured to use XSD 1.0 or XSD 1.1 semantics (in XSD 1.1, year zero exists, in XSD 1.0 it does not). Seconds are supported to a fractional precision of six digits (that is, microsecond precision).

8. Various aspects of the processing provided by doc() are implementation-defined. Implementations may provide external configuration options that allow any aspect of the processing to be controlled by the user.

   ► Saxon allows the URI dereferencing to be performed using a user-supplied URIResolver, as defined in the JAXP specification, or using an XmlResolver on the .NET platform. Saxon also provides various options to control whitespace stripping, validation using a DTD or schema, handling of errors, and support for XML 1.1. If appropriate configuration options are set, then query parameters are recognized in the URI to control some of these decisions.