Saxon on .NET is now built using IKVM 0.40. However, the OpenJDK Classpath library has been customised to reduce its size, by removing parts that Saxon does not need.
The Saxon DLL file now contains a cross-compiled copy of the Apache Xerces-J XML parser. The Sun fork of Xerces (which is
part of
the standard OpenJDK) is not included. Xerces is now the preferred XML parser; to use the Microsoft System.Xml parser instead,
set the configuration option PREFER_JAXP_PARSER to false, or use Saxon API interfaces that take an XmlReader
as an explicit argument. When a DocumentBuilder is used, the supplied XmlResolver will be used to
dereference external entity references whichever parser is used.
Interfaces that take an XmlReader as an argument (for compiling a stylesheet or a schema) now use that
XmlReader without modification: they no longer wrap a supplied XmlTextReader in an XmlValidatingReader,
as these classes have been deprecated since .NET 2.0. It is therefore the user's responsibility to supply a correctly-configured
XmlReader.
Saxon now uses the regular expression library provided in OpenJDK in preference to the .NET regular expression library. This avoids the need to maintain two copies of very similar code in Saxon, and it takes advantage of the Java regex handling of high Unicode characters.
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 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.
The XdmDestination object now has a TreeModel property, allowing a query or
transformation result to be written to a LinkedTree, which makes it amenable to processing using
XQuery Update.
A number of classes have been added to the API to represent types (notably XdmSequenceType and XdmItemType
with subtypes such as XdmAtomicType). These were introduced primarily to support the new class ExtensionFunction
which provides a way of implementing extension functions that does not rely on dynamic loading, and that can take advantage
of information
in the static and dynamic context. Instances of ExtensionFunction can be registered with the Processor.
