Using XQuery

This section describes how to use Saxon as an XQuery processor, either from the command line, from the Java API, C# API, or SaxonC C/C++, Python or PHP APIs:

It also includes useful information on a number of other topics:

Saxon 9.8 and later releases implement the XQuery 3.1 Recommendation dated 18 April 2017. Because XQuery 3.1 is backwards compatible with XQuery 1.0 and XQuery 3.0, Saxon will also execute queries written according to the 1.0 or 3.0 versions of the specification. Saxon no longer has a mode to execute as an XQuery 1.0 or 3.0 processor (that is, to reject constructs that were not present in earlier versions of the language). For information about the conformance of Saxon to the XQuery 3.1 specification, and about the handling of implementation-defined features of the specification, see Conformance.

Saxon uses the same run-time engine to support both XQuery and XSLT, reflecting the fact that the two languages have very similar semantics. Most of the compile-time code (in particular, the type checking logic and the optimizer) is also common. The XQuery support in Saxon consists essentially of an XQuery parser (which is itself an extension of the XPath parser); the parser generates the same internal interpretable code as the XSLT processor. There are also some constructs in the internal expression tree that will only be generated from XQuery source rather than XSLT source; examples are the XQuery order by and group by clauses, which have no direct XSLT equivalent.

The XQuery processor may be invoked either from the operating system command line, or via an API from a user-written application. There is no graphical user interface provided.

Saxon is an in-memory processor. Unless you can take advantage of streaming, Saxon is designed to process source documents that fit in memory. Saxon has been used successfully to process source documents of 100Mbytes or more without streaming, but if you attempt anything this large, you need to be aware (a) that you will need to allocate sufficient memory to the Java VM (at least 5 times the size of the source document), and (b) that complex FLWOR expressions may be very time-consuming to execute. (In this scenario, Saxon-EE is recommended, because it has a more powerful optimizer for complex joins.)

For details of how to set up collation URIs for use in XQuery, see Sorting and collations.

As required by the XQuery 3.1 specification, Saxon predeclares the namespaces for prefixes xml, xs, xsi, fn, and local. As permitted (but not required) by XQuery 3.1, Saxon also predeclares prefixes err and saxon. From Saxon 12.3, it further predeclares math, map, and array.