<?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="schema10support91"/>
      <!--
           Generated at 2011-12-09T20:47:22.916Z--><title>Saxonica: XSLT and XQuery Processing: XML Schema 1.0</title>
      <meta name="coverage" content="Worldwide"/>
      <meta name="copyright" content="Copyright Saxonica Ltd"/>
      <meta name="title" content="Saxonica: XSLT and XQuery Processing: XML Schema 1.0"/>
      <meta name="robots" content="noindex,nofollow"/>
      <link rel="stylesheet" href="../../saxondocs.css" type="text/css"/>
   </head>
   <body class="main">
      <h1>XML Schema 1.0</h1>
      <p>Saxon now implements enumeration facets on union and list types as the authors of the
specification intended. Although the spec as written has problems (bug 5328 has been raised), the intent is that
the enumeration facet as written should be interpreted as an instance of the type being restricted. Previously
enumeration facets on union and list types were doing a string comparison on the lexical value.</p>
      <p>The reporting of <code>keyRef</code> validation errors has been improved. Multiple errors can now be reported in a single
schema validation run, and the line number given with the error message reflects the location of the unresolved
<code>keyRef</code> value, rather than the end of the document as before.</p>
      <p>A new configuration option is available to control whether the schema processor takes notice (and attempts to
dereference) <code>xsi:schemaLocation</code> and <code>xsi:noNamespaceSchemaLocation</code> attributes encountered
in an instance document that is being validated. This is available as the named property <code>FeatureKeys.USE_XSI_SCHEMA_LOCATION</code>
on the <code>TransformerFactory</code> and <code>Configuration</code> classes, via methods on the S9API and .NET 
<code>SchemaValidator</code> classes, and the XQJ class <code>SaxonXQDataSource</code>, and via the <code>-xsiloc</code>
option on the command line interfaces <code>Validate</code>, <code>Transform</code>, and <code>Query</code>.</p>
      <p>New methods have been added to class <code>com.saxonica.schema.SchemaCompiler</code> to allow setting of "deferred validation
mode". In this mode a sequence of calls on <code>readSchema()</code> can be made, followed by a single call on <code>compile()</code>.
The effect is to defer all generation of the finite state machines used for run-time validation until <code>compile()</code> is
called. This avoids repeated (and wasted) recompilation of complex types every time new elements are added to a substitution
group, or every time a new complex type is derived by extension from an existing type. This facility was developed with
XBRL as the primary use case, and has the effect of reducing compilation time for this collection of schema documents from 
400 seconds to 560 milliseconds.</p>
      <p>When <code>minOccurs</code> and numeric <code>maxOccurs</code> constraints (other than 0, 1, or unbounded)
appear on an element or wildcard particle, Saxon now implements a finite state machine using simple counters to count the
number of occurrences, rather than "unfolding" the FSM as previously. This removes the limits on the values
of <code>minOccurs</code> and <code>maxOccurs</code>, as well as the cost in time and memory of handling large 
finite values of <code>minOccurs</code> and <code>maxOccurs</code>. The unfolding technique is still used when
<code>minOccurs</code> and <code>maxOccurs</code> appear on other kinds of particle, specifically on 
 sequence or choice groups, or when "vulnerable" repeated element and wildcard particles appear within a model group that
 can itself be repeated (a particle is vulnerable if all the other particles in the model group are optional). 
 A side-effect of this change is that the diagnostics are more specific when a validation failure occurs.</p>
      <p><i>Another side-effect, hopefully temporary, is that some rather artificial type derivations are no longer allowed: specifically those
where a wildcard with maxOccurs in the base type is specialized to a sequence of specific element particles in the 
derived type</i></p>
      <table width="100%">
         <tr>
            <td>
               <p align="right"><a class="nav" href="xslt91.xml">Next</a></p>
            </td>
         </tr>
      </table>
   </body>
</html>