This section describes how to use Saxon as an XQuery processor, either from the command line, or from the Java API.
For details of the .NET API, see Saxon API for .NET.
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
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 Collations.