<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../../make-menu.xsl" type="text/xsl"?><html>
<head>
<this-is section="changes" page="intro91" subpage="dotnet91"/>
<!--
Generated at 2011-12-09T20:47:22.916Z--><title>Saxonica: XSLT and XQuery Processing: Saxon on .NET</title>
<meta name="coverage" content="Worldwide"/>
<meta name="copyright" content="Copyright Saxonica Ltd"/>
<meta name="title" content="Saxonica: XSLT and XQuery Processing: Saxon on .NET"/>
<meta name="robots" content="noindex,nofollow"/>
<link rel="stylesheet" href="../../saxondocs.css" type="text/css"/>
</head>
<body class="main">
<h1>Saxon on .NET</h1>
<p>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.</p>
<p>There is now an option <code>processor.SetProperty("http://saxon.sf.net/feature/preferJaxpParser", "true")</code> whose
effect is to cause Saxon to use the XML parser in the OpenJDK class library in preference to the (Microsoft) <code>System.Xml</code>
parser. This is useful when the stylesheet or query uses the <code>id()</code> or <code>idref()</code> 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.</p>
<p>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.</p>
<p>New constructors have been added to the class <code>DomDestination</code>, allowing new content to be attached
to an existing document, document fragment, or element node.</p>
<p>A new method is available on the <code>XPathCompiler</code> class to import a schema namespace for reference
within the body of the expression.</p>
<p>A new method <code>Processor.WriteXdmValue(XdmValue, XmlDestination)</code> has been added, allowing any
XDM value (for example, a document node) to be written to any <code>XmlDestination</code> (for example,
a <code>Serializer</code>, a <code>Validator</code>, or a <code>Transformer</code>).</p>
<p>The <code>WriteTo</code> method on <code>XdmNode</code> has been changed so it will write to any <code>XmlWriter</code>,
not only an <code>XmlTextWriter</code> as before.</p>
<p>A new property <code>MessageListener</code> has been added to the <code>XsltTransformer</code> 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 <code>XdmNode</code> to the supplied message listener. Additional parameters indicate whether the
<xsl:message> instruction specified <code>terminate="yes"</code>, and the location in the stylesheet of the originating
<xsl:message> instruction.</p>
<p>The <code>XmlResolver</code> supplied as a property of various classes including the <code>DocumentBuilder</code>, the
<code>XsltCompiler</code>, the <code>XsltTransformer</code>, and the <code>XQueryEvaluator</code>, is now used not only when
resolving URIs at the Saxon level (for example in calls to the <code>doc()</code> function or in <code>xsl:import</code> and
<code>xsl:include</code>), 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 <code>Stream</code> from the <code>GetEntity()</code> method, since
this is the only return value that the Microsoft <code>XmlTextReader</code> can handle.</p>
<p>Extension functions (external functions) may now use <code>System.Xml.XmlNode</code> as an argument type, provided
that the node that is actually passed in the call is a Saxon wrapper around an <code>XmlNode</code>. Similarly, an
<code>XmlNode</code> may also act as the return type. This also applies to subtypes of <code>XmlNode</code>, and to arrays
of <code>XmlNode</code>. 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 <code>XmlNode</code> 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.
</p>
<p>Extension functions (external functions) may also use the types <code>Saxon.Api.XdmValue</code> 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.
</p>
<p>New methods are available to allow the output from the <code>trace()</code> function to be directed
to a specified output stream, or to be discarded.</p>
<p>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 <code>TestRunner.exe</code>.</p>
<p>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.</p>
<p>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).</p>
<table width="100%">
<tr>
<td>
<p align="right"><a class="nav" href="internal91.xml">Next</a></p>
</td>
</tr>
</table>
</body>
</html>
