Saxon on .NET

Saxon on .NET is now built using version 0.36.0.11 of IKVMC. The main difference this makes is that the class library used is now the OpenJDK class library rather than the GNU Classpath library. This in turn has different licensing conditions.

There is now an option processor.SetProperty("http://saxon.sf.net/feature/preferJaxpParser", "true") whose effect is to cause Saxon to use the XML parser in the OpenJDK class library in preference to the (Microsoft) System.Xml parser. This is useful when the stylesheet or query uses the id() or idref() function when attribute types are defined in a DTD: the Microsoft XML parser does not report attribute types to the application, so these functions fail to find anything when the source document was built using this parser. Using the JAXP parser gets around this problem.

Saxon on .NET is now built and tested on .NET 2.0. It should be compatible with .NET 1.1 or .NET 3.5, but this cannot be guaranteed. Saxon is not tested on Mono, though users have reported running it successfully.

New constructors have been added to the class DomDestination, allowing new content to be attached to an existing document, document fragment, or element node.

A new method is available on the XPathCompiler class to import a schema namespace for reference within the body of the expression.

A new method Processor.WriteXdmValue(XdmValue, XmlDestination) has been added, allowing any XDM value (for example, a document node) to be written to any XmlDestination (for example, a Serializer, a Validator, or a Transformer).

The WriteTo method on XdmNode has been changed so it will write to any XmlWriter, not only an XmlTextWriter as before.

A new property MessageListener has been added to the XsltTransformer object. This allows the output of <xsl:message> instructions to be intercepted. Each call of <xsl:message> generates a document node, which is passed in the form of an XdmNode to the supplied message listener. Additional parameters indicate whether the <xsl:message> instruction specified terminate="yes", and the location in the stylesheet of the originating <xsl:message> instruction.

The XmlResolver supplied as a property of various classes including the DocumentBuilder, the XsltCompiler, the XsltTransformer, and the XQueryEvaluator, is now used not only when resolving URIs at the Saxon level (for example in calls to the doc() function or in xsl:import and xsl:include), but also by the XML parser in resolving URIs referring to external entities, including an external DTD. Note that this means it is unwise to return anything other than a Stream from the GetEntity() method, since this is the only return value that the Microsoft XmlTextReader can handle.

Extension functions (external functions) may now use System.Xml.XmlNode as an argument type, provided that the node that is actually passed in the call is a Saxon wrapper around an XmlNode. Similarly, an XmlNode may also act as the return type. This also applies to subtypes of XmlNode, and to arrays of XmlNode. However, this facility is only available when Saxon is invoked via the .NET API, not when it is invoked from the command line. Note that returning XmlNode values may be expensive if the extension function is called frequently, as new wrappers are created each time; the calling stylesheet or query should also not rely on the identity of nodes that are returned in this way.

Extension functions (external functions) may also use the types Saxon.Api.XdmValue and its Saxon-defined subtypes as an argument or return type. This facility is only available when Saxon is invoked via the .NET API, not when it is invoked from the command line.

New methods are available to allow the output from the trace() function to be directed to a specified output stream, or to be discarded.

The sample applications for .NET have been rewritten, and the test drivers for the W3C XQuery and XSLT test suites have been repackaged within a simple forms-based application called TestRunner.exe.

In previous releases the documentation stated that the SQL extension was untested on .NET. This time I tried it and found it wasn't working, probably due to the absence of JDBC drivers in the OpenJDK class library. In Saxon 9.1 I have therefore excluded the relevant classes from the .DLL build. It would make more sense on .NET to implement this extension directly over the .NET data access classes.

The tooling for creating the API documentation on .NET has changed. The NDOC tool, which was used in previous releases, is no longer maintained (or usable), while the promised Microsoft replacement, SandCastle, is unfinished and poorly documented, and I couldn't get it to work. I ended up writing my own documentation generator in XSLT, taking the C# source code and the generated apidoc.xml documentation as input. There are few things missing in the resulting HTML, for example there is little information about inherited methods, but I think that what is there is more easily accessible (it follows the Javadoc style of putting all the information about one class on one page).