System Programming Interfaces

There have been a number of changes to APIs that may affect users.

• The XSLTContext object has been merged into net.sf.saxon.Controller. This class was exposed in the traditional Saxon Java event-handling API, and was also available for use by extension functions, extension elements, and trace listeners. Extension functions that require context information must now declare a first argument of class XPathContext.
• The tracing API has changed, as the execution flow can no longer be described in terms of nodes in the stylesheet tree. Since it had to change anyway, I have taken the opportunity to redesign it in terms of interfaces that hopefully will stand the test of time.
• The element extensibility API is changed because extension elements, like other nodes in the stylesheet, must be compiled into separate data structure for execution. The ExtensionElementFactory interface is unaffected, but the classes implementing individual instructions must be split in two: a subclass of StyleElement representing the node on the stylesheet tree, which contains a compile() method, which in turn generates a corresponding instance of a subtype of the class net.sf.saxon.instruct.Instruction. The SQL extension library has been updated to show how the new scheme works.
• The NodeHandler interface (used by the old "non-XSLT" Java interface to Saxon) has changed again. Its start() method is replaced by a process() method that takes a single argument, the Controller object.

It is now possible to control the use of NamePools via the TransformerFactory. The call factory.setAttribute(FeatureKeys.NAME_POOL, pool) causes the specified namepool to be used by all stylesheets that are compiled (using newTemplates()) following this call. Note: unless you really know what you are doing, it is safest to let Saxon manage the namePools automatically.

The HTML output method now uses its own internal method for URI escaping, rather than relying on the utf8 encoding available in the Java IO library. {outp52, 57}