<?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="internal91"/>
      <!--
           Generated at 2010-10-29T18:20:48.427+01:00--><title>Saxonica: XSLT and XQuery Processing: Internal APIs</title>
      <meta name="coverage" content="Worldwide"/>
      <meta name="copyright" content="Copyright Saxonica Ltd"/>
      <meta name="title" content="Saxonica: XSLT and XQuery Processing: Internal APIs"/>
      <meta name="robots" content="noindex,nofollow"/>
      <link rel="stylesheet" href="../../saxondocs.css" type="text/css"/>
   </head>
   <body class="main">
      <h1>Internal APIs</h1>
      <p>The three methods <code>isId()</code>, <code>isIdref()</code>, and <code>isNilled()</code> have been moved from the
<code>ExtendedNodeInfo</code> interface into <code>NodeInfo</code>, which means they must now be implemented by all concrete
classes implementing <code>NodeInfo</code>. The <code>ExtendedNodeInfo</code> interface has been dropped.</p>
      <p>The <code>SequenceIterator</code> interface now has a <code>close()</code> method. This should be called
by any consumer of iterator events if the iterator is not read to completion. Currently the only effect is where the events
derive from streamed processing of an input document; in this case the <code>close()</code> call causes the parsing of the input document
to be abandoned. This means for example that an expression such as <code>exists(saxon:stream(('doc.xml')//x))</code>
will stop parsing the input document as soon as an &lt;x&gt; element is found. Any user-written implementations of
<code>SequenceIterator</code> must be changed to provide an implementation of this method; it can safely do nothing, but if the
<code>SequenceIterator</code> uses another <code>SequenceIterator</code> as input, the call to <code>close()</code> should be passed on.</p>
      <p>To allow further application control over dynamic loading in environments with non-standard class loaders or 
other specialist requirements, dynamic loading of classes (and instantiation of these classes) is now delegated
to a new <code>DynamicLoader</code> class owned by the <code>Configuration</code>. This allows the application
to substitute a subclass of its own to intercept the calls that cause classes to be loaded dynamically.</p>
      <p>The classes used to represent path expressions have been refactored (leading to some change in -explain
output). The two classes <code>PathExpression</code> and <code>SimpleMappingExpression</code>, which contained
a lot of repeated code, have been replaced by a structure in which the general class <code>SlashExpression</code>
has two subclasses, <code>PathExpression</code> and <code>AtomicMappingExpression</code>, for use when the rhs
operand of "/" is known to deliver nodes or atomic values respectively. The expression parser initially generates
a <code>SlashExpression</code>, and this is replaced by a <code>PathExpression</code> or 
<code>AtomicMappingExpression</code> if possible during the
type checking phase. If the type of the rhs cannot be determined, the<code> SlashExpression</code> is retained as a concrete
class and is evaluated at run-time. The new <code>PathExpression</code> class is not responsible for sorting and deduplicating
nodes; when a <code>PathExpression</code> is created, it is always wrapped in a <code>DocumentSorter</code> that has this responsibility,
and the <code>DocumentSorter</code> is subsequently removed if the path expression is found to be presorted, or if sorting is
found to be unnecessary because of the context where the path expression is used.</p>
      <table width="100%">
         <tr>
            <td>
               <p align="right"><a class="nav" href="serial91.xml">Next</a></p>
            </td>
         </tr>
      </table>
   </body>
</html>