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
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
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
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).
In the NodeInfo interface, the
copy() method has been changed to take a bit-significant
copyOptions argument replacing the previous
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
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
(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
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.