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

Next