Saxon on .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.