<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../../make-menu.xsl" type="text/xsl"?><html>
   <head>
      <this-is section="changes" page="intro93" subpage="misc-93"/>
      <!--
           Generated at 2011-12-09T20:47:22.916Z--><title>Saxonica: XSLT and XQuery Processing: Internal changes</title>
      <meta name="coverage" content="Worldwide"/>
      <meta name="copyright" content="Copyright Saxonica Ltd"/>
      <meta name="title" content="Saxonica: XSLT and XQuery Processing: Internal changes"/>
      <meta name="robots" content="noindex,nofollow"/>
      <link rel="stylesheet" href="../../saxondocs.css" type="text/css"/>
   </head>
   <body class="main">
      <h1>Internal changes</h1>
      <p>There has been some reorganization of the structure of classes and packages. Many of the interfaces that are intended for applications
    to implement (such as <a class="bodylink"
            href="../../javadoc/net/sf/saxon/lib/CollectionURIResolver.html"><code>CollectionURIResolver</code></a>), 
                  and also classes defining constants for use as parameters in an API (such
    as <a class="bodylink" href="../../javadoc/net/sf/saxon/lib/FeatureKeys.html"><code>FeatureKeys</code></a> and <a class="bodylink" href="../../javadoc/net/sf/saxon/lib/SaxonOutputKeys.html"><code>SaxonOutputKeys</code></a>) 
                  have been moved to the new package <code>net.sf.saxon.lib</code>.
    Classes and packages that are purely for internal use have in same cases been buried in a more deeply nested package hierarchy,
    to make it easier to find the classes that are of interest to applications. For example, implementations of <a class="bodylink" href="../../javadoc/net/sf/saxon/om/SequenceIterator.html"><code>SequenceIterator</code></a>
    have been pushed down into <code>net.sf.saxon.om.iter</code>. Classes concerned with serialization have been moved out of the 
    <code>event</code> package into a new <code>serialize</code> package.</p>
      <p>There is no longer a separate parser for XSLT Patterns; instead, patterns are parsed as XPath expressions, and the resulting expression
tree is then converted to a pattern object.</p>
      <p>In the representation of a stylesheet tree, there is now a distinction between a stylesheet document (<a class="bodylink" href="../../javadoc/net/sf/saxon/style/XSLStylesheet.html"><code>XSLStylesheet</code></a>), and a stylesheet module
(<a class="bodylink" href="../../javadoc/net/sf/saxon/style/StylesheetModule.html"><code>StylesheetModule</code></a>). 
                  This caters for the case where the same stylesheet document is imported several times with different import precedence.
The new structure allows several <code>StylesheetModule</code>s therefore to share the same source code, but with different precedence. This also paves the
way to allowing stylesheet modules eventually to be parsed once and shared between different stylesheets (but this is not easy, because
references such as variable references and function calls may be resolved differently in the different cases).</p>
      <p>The class <a class="bodylink" href="../../javadoc/net/sf/saxon/PreparedStyleSheet.html"><code>PreparedStyleSheet</code></a> now subclasses 
         <a class="bodylink"
            href="../../javadoc/net/sf/saxon/expr/instruct/Executable.html"><code>Executable</code></a>, and duplication of functionality between these two classes
has been eliminated.</p>
      <p>Dropped the methods (deprecated since Saxon 8.9) <a class="bodylink"
            href="../../javadoc/net/sf/saxon/sxpath/XPathEvaluator.html#build"><code>build()</code></a> and
                     <a class="bodylink"
            href="../../javadoc/net/sf/saxon/sxpath/XPathEvaluator.html#build"><code>setStripSpace()</code></a> in
                     <a class="bodylink" href="../../javadoc/net/sf/saxon/sxpath/XPathEvaluator.html"><code>net.sf.saxon.sxpath.XPathEvaluator</code></a>.</p>
      <p>In the <a class="bodylink" href="../../javadoc/net/sf/saxon/om/NodeInfo.html"><code>NodeInfo</code></a> interface, the <code>copy()</code> method has been changed to take a bit-significant
<code>copyOptions</code> argument replacing the previous <code>whichNamespaces</code> and <code>typeAnnotations</code>
arguments. (It also allows an additional option for requesting that the copy should be mutable.)</p>
      <p>There is a new optimization for the expression <code>(A intersect B)</code>; if the first operand (say) is a singleton, the operator is
rewritten as <code>singleton-intersect</code> and the run-time evaluation does a serial search of the second operand to see
if the first item is present. This avoids an unnecessary sort of the second operand.</p>
      <p>There have been improvements to schema-aware type checking for the descendant axis, in particular (a) for expressions starting at the
document node, in cases where the type of the document node is known in the form <code>document-node(schema-element(X))</code>, and 
(b) where the structure is recursive (or more generally, where the descendant element can be reached by different routes, but has the
same type in each case). The result is that misspelt names appearing in a path after a "//" operator are more likely
to be detected and reported; and in some cases more efficient code will be generated to handle the atomized result of the path
expression.</p>
      <p>When parameters are passed to a stylesheet or query, Saxon generally applies the function conversion rules to the supplied
            values. For example, if the required type is <code>xs:double</code> then it is acceptable to supply an integer. Two changes have
            been made in this area. Firstly, the existing code was too liberal in the case of numeric parameters: if the supplied value and the
            required type were both numeric, it applied the casting rules rather than only allowing numeric promotion. Secondly, the XQJ
            specification requires the supplied value to match the required type without conversion or promotion, so Saxon now provides an
            option in the XQuery interface to suppress conversion, and this option is always set in the case of XQJ applications.</p>
      <p>In the JAXP XPath API, Saxon's implementation of <code>XPathFactory</code> now automatically registers JDOM, DOM4J, and XOM as supported external
            object models if a Saxon-PE or Saxon-EE configuration is in use.</p>
      <table width="100%">
         <tr>
            <td>
               <p align="right"><a class="nav" href="../intro92.xml">Next</a></p>
            </td>
         </tr>
      </table>
   </body>
</html>