Changes specific to .NET
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
.