Internal changes

There has been some reorganization of the structure of classes and packages. Many of the interfaces that are intended for applications to implement (such as CollectionURIResolver), and also classes defining constants for use as parameters in an API (such as FeatureKeys and SaxonOutputKeys) have been moved to the new package net.sf.saxon.lib. Classes and packages that are purely for internal use have in same cases been buried in a more deeply nested package hierarchy, to make it easier to find the classes that are of interest to applications. For example, implementations of SequenceIterator have been pushed down into net.sf.saxon.om.iter. Classes concerned with serialization have been moved out of the event package into a new serialize package.

There is no longer a separate parser for XSLT Patterns; instead, patterns are parsed as XPath expressions, and the resulting expression tree is then converted to a pattern object.

In the representation of a stylesheet tree, there is now a distinction between a stylesheet document (XSLStylesheet), and a stylesheet module (StylesheetModule). This caters for the case where the same stylesheet document is imported several times with different import precedence. The new structure allows several StylesheetModules therefore to share the same source code, but with different precedence. This also paves the way to allowing stylesheet modules eventually to be parsed once and shared between different stylesheets (but this is not easy, because references such as variable references and function calls may be resolved differently in the different cases).

The class PreparedStyleSheet now subclasses Executable, and duplication of functionality between these two classes has been eliminated.

Dropped the methods (deprecated since Saxon 8.9) build() and setStripSpace() in net.sf.saxon.sxpath.XPathEvaluator.

In the NodeInfo interface, the copy() method has been changed to take a bit-significant copyOptions argument replacing the previous whichNamespaces and typeAnnotations arguments. (It also allows an additional option for requesting that the copy should be mutable.)

There is a new optimization for the expression (A intersect B); if the first operand (say) is a singleton, the operator is rewritten as singleton-intersect and the run-time evaluation does a serial search of the second operand to see if the first item is present. This avoids an unnecessary sort of the second operand.

There have been improvements to schema-aware type checking for the descendant axis, in particular (a) for expressions starting at the document node, in cases where the type of the document node is known in the form document-node(schema-element(X)), and (b) where the structure is recursive (or more generally, where the descendant element can be reached by different routes, but has the same type in each case). The result is that misspelt names appearing in a path after a "//" operator are more likely to be detected and reported; and in some cases more efficient code will be generated to handle the atomized result of the path expression.

When parameters are passed to a stylesheet or query, Saxon generally applies the function conversion rules to the supplied values. For example, if the required type is xs:double then it is acceptable to supply an integer. Two changes have been made in this area. Firstly, the existing code was too liberal in the case of numeric parameters: if the supplied value and the required type were both numeric, it applied the casting rules rather than only allowing numeric promotion. Secondly, the XQJ specification requires the supplied value to match the required type without conversion or promotion, so Saxon now provides an option in the XQuery interface to suppress conversion, and this option is always set in the case of XQJ applications.

In the JAXP XPath API, Saxon's implementation of XPathFactory now automatically registers JDOM, DOM4J, and XOM as supported external object models if a Saxon-PE or Saxon-EE configuration is in use.