XQuery 3.1 Conformance

Saxon 9.9 fully implements the final XQuery 3.1 Recommendation of 21 March 2017. (Saxon 9.8 also claimed full conformance, and the situation is unchanged except for a small number of bugs that have been reported.)

See also XPath 3.1 Conformance; all the new features implemented for XPath 3.1 are also available in XQuery 3.1.

Test results

At the time of release Saxon-EE 9.9 passes all 30925 applicable tests in the W3C XPath/XQuery test suite (QT3). For the first time, this includes always producing the correct error code in the case of error tests. Tests are run on both the Java and .NET platforms, with bytecode enabled and disabled. Since many of the tests are simple constant expressions (for example, contains("banana", "n")), which will normally be pre-evaluated during expression optimization and thus never result in bytecode being generated, the test driver also includes an option to "unfold" the test to create artificial complications: for example the constant string "banana" is replaced by a call to a function f:scramble("banana") which actually returns its argument unchanged, but only after various manipulations designed to defeat the optimizer.

The only tests that are not run are:

• 415 tests that exercise the optional "static typing feature", which Saxon does not implement (and which W3C has discontinued).
• 2 tests that expose bugs in the ICU library, used for Unicode collation support. The bugs have been reported.

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.

Conformance overview

The various Saxon editions implement XQuery 3.1 capabilities as follows:

• Saxon-HE implements XQuery 3.1 at the Minimal Conformance level, plus the Module Feature and the Serialization Feature.

• Saxon-PE adds support for the Higher-Order Function Feature.

• Saxon-EE adds support for the Schema Aware Feature and the Typed Data Feature.

These optional features are defined in the conformance section of the XQuery 3.1 specification.

Saxon does not implement the Static Typing Feature.

New facilities in XQuery 3.0, beyond those in XPath 3.0, include the following:

• Group by clause in FLWOR expressions

• Tumbling window and sliding window in FLWOR expressions

• Count clause in FLWOR expressions

• Outer joins, represented by the syntax allowing empty in a FLWOR expression

• Try/Catch expressions

• Private functions and variables

• Switch expressions

• Computed namespace constructors

• Output declarations to control serialization

• Decimal format declarations to control use of the format-number function

• Validation against a named type

• Default values for external variables

There are no significant changes in XQuery 3.1 beyond those found in XQuery 3.0 and XPath 3.1.

For details of the function library supported, see Functions.

From 9.8 onwards, Saxon always acts as an XQuery 3.1 processor; it is no longer possible to ask it to operate as an XQuery 1.0 or XQuery 3.0 processor. However, there are very few incompatibilities, so queries that ran successfully under XQuery 1.0 or XQuery 3.0 will almost certainly continue to work.

Checklist of Implementation-Defined Items

Appendix D of the XQuery 3.1 specification lists a number of features whose behaviour is implementation-defined. For Saxon, the behaviour is as follows:

1. The version of Unicode that is used to construct expressions.

   ► For details of Saxon Unicode support, see XSLT 3.0 Conformance.

2. The statically-known collations.

   ► Collation URIs of the form http://saxon.sf.net/collation? param=value;param=value... are always available: these map to the collations offered by the locales available within the Java VM in use. Additional collation URIs may be implemented by users and registered with the Saxon configuration via the Java API.

3. The implicit timezone.

   ► The implicit timezone is normally taken from the system clock. This may, however, be overridden via the Java API.

4. The circumstances in which warnings are raised, and the ways in which warnings are handled.

   ► Warnings are raised for a variety of conditions. Compile time warnings include:

   • Use of a path expression that can never select anything (for example @a/@b )

   • Use of an expression that can only succeed if one or more operands are empty sequences

   • Use of a string literal in a PITest that is not a valid NCName

   Warnings may also be raised at run-time, for example if the collection() function fails to load a document and recovery has been requested.

   Compile-time warnings are sent to the JAXP ErrorListener registered with the Configuration; the default ErrorListener displays them as messages on System.err. Run-time warnings are sent to the JAXP ErrorListener registered with the Controller; the default is the same.

5. The method by which errors are reported to the external processing environment.

   ► Compile-time errors are sent to the JAXP ErrorListener registered with the Configuration; the default ErrorListener displays them as messages on System.err. Run-time errors are sent to the JAXP ErrorListener registered with the Controller; the default is the same. When queries are invoked from a Java application, any error will also be notified by throwing an exception.

6. Which version of XML and XML Names (e.g. [XML 1.0] and [XML Names] or [XML 1.1] and [XML Names 1.1]) and which version of XML Schema (e.g. [XML Schema 1.0] or [XML Schema 1.1]) is used for the definitions of primitives such as characters and names, and for the definitions of operations such as normalization of line endings and normalization of whitespace in attribute values. It is recommended that the latest applicable version be used (even if it is published later than this specification).

   ► Saxon gives the user the choice: see Saxon and XML 1.1. Note that since Saxon allows the user to select which XML parser to use on a per-document basis, achievement of consistency across "all aspects of the implementation" is in part a user responsibility. Saxon will not reject any attempt to use an XML 1.1 parser in a 1.0 configuration, or vice versa.

7. How XDM instances are created from sources other than an Infoset or PSVI.

   ► XDM instances may be constructed programmatically, or by wrapping trees constructed using DOM, DOM4J, JDOM, XOM, or AXIOM.

8. Any components of the static context or dynamic context that are overwritten or augmented by the implementation.

   ► See the corresponding details for XQuery 1.0.

9. The default handling of empty sequences returned by an ordering key (orderspec) in an order by clause (empty least or empty greatest).

   ► Empty least.

10. The names and semantics of any extension expressions (pragmas) recognized by the implementation.

    ► Saxon-EE recognizes one pragma: saxon:validate-type. For details, see XQuery Extensions.

11. The names and semantics of any option declarations recognized by the implementation.

    ► See XQuery Extensibility.

12. Protocols (if any) by which parameters can be passed to an external function, and the result of the function can returned to the invoking query.

    ► Java methods can be called as Extension Functions.

13. The process by which the specific modules to be imported by a module import are identified, if the Module Feature is supported (includes processing of location hints, if any.)

    ► The location hint is interpreted as a relative URI, relative to the base URI of the referencing module. It is then dereferenced using the Java URL mechanisms, unless the user has nominated a ModuleURIResolver, in which case the interpretation is under user control.

14. The means by which serialization is invoked, if the Serialization Feature is supported.

    ► Serialization may be invoked from the command line or from the Java or .NET API. Serialization parameters may be supplied on the command line, from the Java or .NET API, or through option declarations in the query prolog.

15. The default values for the byte-order-mark, encoding, html-version, item-separator, media-type, normalization-form, omit-xml-declaration, standalone, and version parameters, if the Serialization Feature is supported.

    ► As specified in Appendix C.3 of the XQuery specification.

16. The result of an unsuccessful call to an external function (for example, if the function implementation cannot be found or does not return a value of the declared type).

    ► A static or dynamic error.

17. Limits on ranges of values for various data types, as enumerated in 5.3 Data Model Conformance.

    ► For integers, decimals, and strings, the only limits imposed by Saxon are those inherent in the underlying Java types BigInteger, BigDecimal, and String.

    ► For calendar data types, the year must be in the range of a signed 32-bit integer; seconds are supported to a fractional precision of nine digits (that is, nanosecond precision).

    ► For durations, the number of months must fit in a signed 32-bit integer; the integer number of seconds must fit in a signed 64-bit integer, and the precision is to nanoseconds.

    ► The maximum length of a sequence (or array) is limited to 2³¹-1 items.

18. Syntactic extensions to XQuery, including both their syntax and semantics, as discussed in 5.4 Syntax Extensions.

    ► None.

19. Whether the type system is based on [XML Schema 1.0] or [XML Schema 1.1]. An implementation that has based its type system on XML Schema 1.0 is not required to support the use of the xs:dateTimeStamp constructor or the use of xs:dateTimeStamp or xs:error as TypeName in any expression.

    ► XSD 1.0 or XSD 1.1 at user option.

20. The signatures of functions provided by the implementation or via an implementation-defined API (see 2.1.1 Static Context).

    ► A list of all recognized functions is at Function library.

21. Any environment variables provided by the implementation.

    ► The environment variables available are those exposed by the Java method System.getenv().

22. Any rules used for static typing (see 2.2.3.1 Static Analysis Phase).

    ► Saxon performs "optimistic static typing": that is, it attempts to infer a type for every expression, and reports a type error statically if there is an empty intersection between the inferred type and the required type.

23. Any serialization parameters provided by the implementation (see 2.2.4 Serialization).

24. The means by which the location hint for a serialization parameter document identifies the corresponding XDM instance (see 2.2.4 Serialization).

25. What error, if any, is returned if an external function's implementation does not return the declared result type (see 2.2.5 Consistency Constraints).

    ► Generally, a type error XPTY0004. However, external functions have the option to request suppression of this type check, in which case the consequences of the error become unpredictable.

26. Any annotations defined by the implementation, and their associated behaviour (see 4.15 Annotations).

    ► None.

27. Any function assertions defined by the implementation.

    ► None.

28. The effect of function assertions understood by the implementation on 2.5.6.3 The judgement subtype-assertions(AnnotationsA, AnnotationsB).

    ► None.

29. Any implementation-defined variables defined by the implementation (see 3.1.2 Variable References).

    ► None.

30. The ordering associated with fn:unordered in the implementation (see 3.13 Ordered and Unordered Expressions).

    ► The fn:unordered function returns its input argument value unchanged in nearly all cases. The only exceptions are where the argument is an axis expression that would normally require sorting of results into document order (for example, the preceding-sibling axis), in which case the sort is avoided.

31. Any additional information provided for try/catch via the err:additional variable (see 3.17 Try/Catch Expressions).

    ► None.

32. The default boundary-space policy (see 4.3 Boundary-space Declaration).

    ► Boundary space is significant.

33. The default collation (see 4.4 Default Collation Declaration).

    ► The name of the default collation can be specified as a configuration option.

34. The default base URI (see 4.5 Base URI Declaration).

    ► The default base URI for a query is taken from the file or URI giving the query location if available, or from an explicit setting of the base URI in the XQuery API otherwise.