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).