<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../../make-menu.xsl" type="text/xsl"?><html>
<head>
<this-is section="changes" page="intro92" subpage="dotnet92"/>
<!--
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 IKVM 0.40. However, the OpenJDK Classpath library has been customised to reduce its size,
by removing parts that Saxon does not need.</p>
<p>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 <code>PREFER_JAXP_PARSER</code> to false, or use Saxon API interfaces that take an <code>XmlReader</code>
as an explicit argument. When a <code>DocumentBuilder</code> is used, the supplied <code>XmlResolver</code> will be used to
dereference external entity references whichever parser is used.</p>
<p>Interfaces that take an <code>XmlReader</code> as an argument (for compiling a stylesheet or a schema) now use that
<code>XmlReader</code> without modification: they no longer wrap a supplied <code>XmlTextReader</code> in an <code>XmlValidatingReader</code>,
as these classes have been deprecated since .NET 2.0. It is therefore the user's responsibility to supply a correctly-configured
<code>XmlReader</code>.</p>
<p>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.</p>
<p>The <code>XPathCompiler</code> 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 <code>XPathExecutable</code> object.</p>
<p>The class <code>XdmValue</code> has a new method <code>Append()</code> allowing a new <code>XdmValue</code>
to be constructed by concatenating two existing instances of <code>XdmValue</code>.</p>
<p>The <code>Processor</code> object is now accessible to the code of extension functions by calling
<code>context.getConfiguration().getProcessor()</code>, assuming that the method in question has a first argument of type
<code>net.sf.saxon.expr.XPathContext</code>. This is useful when the extension function wants to create new
nodes or invoke Saxon operations such as XSLT or XQuery processing.</p>
<p>The <code>XdmDestination</code> object now has a <code>TreeModel</code> property, allowing a query or
transformation result to be written to a LinkedTree, which makes it amenable to processing using
XQuery Update.</p>
<p>A number of classes have been added to the API to represent types (notably <code>XdmSequenceType</code> and <code>XdmItemType</code>
with subtypes such as <code>XdmAtomicType</code>). These were introduced primarily to support the new class <code>ExtensionFunction</code>
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 <code>ExtensionFunction</code> can be registered with the <code>Processor</code>.</p>
<table width="100%">
<tr>
<td>
<p align="right"><a class="nav" href="xslt92.xml">Next</a></p>
</td>
</tr>
</table>
</body>
</html>
