XQuery 3.1 Conformance

Saxon 9.8 fully implements thefinal XQuery 3.1 Recommendation of 21 March 2017.

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

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

Test Results

Saxon 9.8, at the time of release, passes all tests in the W3C test suite for XQuery 3.1, other than tests for features which Saxon does not implement (for example, static typing), tests whose results have been challenged by means of a bug report submitted to W3C, and tests that exceed Saxon limits (for example, a date whose year component is 25 digits long).

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.

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