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.
