S9API interface

Separate compilation of XQuery modules is available (under Saxon-EE only). An overloaded method compileLibrary() is available in the XQueryCompiler class to compile a library module; any subsequent compilation using the same XQueryCompiler may import this module (using import module specifying only a module URI - any location hint will be ignored), and the global functions and variables declared in the library module will be imported without incurring the cost of recompiling them.

The XPathCompiler has a new option to permit undeclared variables in XPath expressions. This allows an expression to be compiled without pre-declaring the variables that it references. It is possible to discover what variables are used in the expression (so that they can be initialized) by means of new methods provided on the XPathExecutable object.

The class XdmValue has a new method append() allowing a new XdmValue to be constructed by concatenating two existing instances of XdmValue.

The classes DocumentBuilder and XdmDestination have a new method setTreeModel() (and a corresponding accessor getTreeModel()) to indicate that what tree model should be used for the constructed tree. This allows selection of a linked tree in the case where XQuery Update access is required, or of the new condensed tiny tree. These methods are defined in terms of a new TreeModel class which in principle defines an extensibility point where new user-defined tree models can be supported.

The class XdmNode has a new method getColumnNumber() allowing the column number in the original lexical XML to be obtained, in cases where line numbers have been preserved.

The Processor object is now accessible to the code of extension functions by calling context.getConfiguration().getProcessor(), assuming that the method in question has a first argument of type net.sf.saxon.expr.XPathContext. This is useful when the extension function wants to create new nodes or invoke Saxon operations such as XSLT or XQuery processing.

A new mechanism is provided in the s9api Processor for declaring so-called integrated extension functions. Unlike traditional extension functions invoked as Java methods through reflexion, an integrated extension function is implemented as a pair of classes: a class that extends the abstract class net.sf.saxon.functions.ExtensionFunctionDefinition, which defines static properties of the extension function, and a second class which extends net.sf.saxon.functions.ExtensionFunctionCall, and represents a specific call on the extension function, and provides a call() method to evaluate its result.

Many Saxon extension functions have been re-implemented using this mechanism; examples are saxon:parse() and saxon:serialize().

The XsltTransformer class now has methods to get and set an ErrorListener for dynamic errors.