<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../make-menu.xsl" type="text/xsl"?><html>
<head>
<this-is section="conformance" page="schema" subpage=""/>
<!--
Generated at 2011-12-09T20:47:22.916Z--><title>Saxonica: XSLT and XQuery Processing: XML Schema 1.0 Conformance</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 Conformance"/>
<meta name="robots" content="noindex,nofollow"/>
<link rel="stylesheet" href="../saxondocs.css" type="text/css"/>
</head>
<body class="main">
<h1>XML Schema 1.0 Conformance</h1>
<p>Saxon Enterprise Edition (Saxon-EE)
includes a complete implementation of XML Schema 1.0.</p>
<p>Test results have been submitted against the W3C XML Schema Test Suite. All deviations from the
expected test results have been accounted for, and are believed to represent areas where the tests are
either incorrect, or where implementations can legitimately differ.</p>
<p>Known limitations include the following:</p>
<ul>
<li content="para">
<p>Saxon imposes limits on the values of <code>minOccurs</code> and <code>maxOccurs</code> appearing on any
particle other than an element particle in a content model. These limits are designed to prevent out-of-memory errors. By default, the upper limit for
<code>minOccurs</code> is 100 and the upper limit for <code>maxOccurs</code> (other than "unbounded") is 250.
If these limits are exceeded,
a warning is output, and the values specified are replaced with the highest allowed value (which is "unbounded"
in the case of <code>maxOccurs</code>). The limits are configurable using the method <code>setOccurrenceLimits()</code>
in the class <code>EnterpriseConfiguration</code>. If they are set too high, however, out-of-memory or stack overflow errors will
occur either during schema compilation or during instance validation. Since Saxon 9.1, these limits no longer
apply to the common case of element particles, which are now handled using counters.</p>
</li>
<li content="para">
<p>Saxon implements schema processing only to the extent required for XPath, XSLT, and XQuery processing
and for assessment of document validity. This
means that PSVI properties beyond those required for the XPath data model are not provided. It also means that
validation errors are fatal, they do not result in a PSVI that indicates the validation outcome for individual nodes.</p>
</li>
<li content="para">
<p>Saxon uses the rules in XSD 1.1 rather than those in XSD 1.0 to evaluate type subsumption. The Saxon
algorithm (an implementation of the algorithm published by Henry Thompson and Richard Tobin of the University of
Edinburgh) is more accurate than the one in the XSD 1.0 specification in deciding whether one complex type subsumes another.
It therefore permits some complex type restrictions that the cruder XSD 1.0 algorithm disallows.</p>
</li>
<li content="para">
<p>Saxon also uses the Thomson and Tobin algorithm to evaluate the Unique Particle Attribution constraint. The effect
of this is that no UPA violation is reported when a complex type contains two distinct element particles that are references to the
same element declaration, since the element declaration can be identified unambiguously.</p>
</li>
<li content="para">
<p>Saxon does not allow a user-defined type to be derived directly from <code>xs:anySimpleType</code>. It seems
that the XSD 1.0 specification does not disallow this, though the effect of doing it is very unclear, and it has
been banned in XSD 1.1.</p>
</li>
</ul>
<table width="100%">
<tr>
<td>
<p align="right"><a class="nav" href="schema11.xml">Next</a></p>
</td>
</tr>
</table>
</body>
</html>
