<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../../make-menu.xsl" type="text/xsl"?><html>
<head>
<this-is section="changes" page="s90" subpage="schema90"/>
<!--
Generated at 2011-12-09T20:47:22.916Z--><title>Saxonica: XSLT and XQuery Processing: Schema-related changes</title>
<meta name="coverage" content="Worldwide"/>
<meta name="copyright" content="Copyright Saxonica Ltd"/>
<meta name="title"
content="Saxonica: XSLT and XQuery Processing: Schema-related changes"/>
<meta name="robots" content="noindex,nofollow"/>
<link rel="stylesheet" href="../../saxondocs.css" type="text/css"/>
</head>
<body class="main">
<h1>Schema-related changes</h1>
<p>The command line interface <code>com.saxonica.Validate</code> has been completely redesigned, allowing
multiple schema documents to be loaded and multiple instance documents to be validated.</p>
<p>This release of Saxon introduces preliminary support for assertions in a schema, based on the
current (31 August 2006) draft of XML Schema version 1.1. This allows a complex type to contain an assertion
about the content of the corresponding element expressed as an arbitrary XPath 2.0 expression. Please note that this
facility in the Working Draft is likely to change, and the Saxon implementation will change accordingly. For further
details see <a class="bodylink" href="../../schema-processing/schema11/assertions.xml">Assertions</a>.</p>
<p>The XML Schema specification imposes a rule that when one type R is derived from another type B by restriction,
then every element particle ER in the content model of R must be compatible with the corresponding element particle EB in B.
One aspect of this is that the identity constraints defined in the declaration of ER (that is, unique, key, and keyref) must
be a superset of the constraints defined for EB. The specification doesn't say how to decide whether two constraints are
equivalent for this purpose, and Saxon has previously ignored this requirement. At this release a check is introduced which
partially implements the rule. Specifically, Saxon will count the number of constraints that are defined, and will
report an error if EB has more constraints of any particular kind (unique, key, or keyref) than ER has. If EB has at least one
constraint and ER has one or more, then Saxon will output a warning saying that it was unable to check whether the constraints
were compatible with each other.</p>
<p>It is now possible when requesting validation of an instance to specify the required name of the top-level element
in the document being validated. This is possible through the option <code>-top:clarkname</code> on the
<code>com.saxonica.Validate</code> command, or via a new property on the <code>AugmentedSource</code> object.
The property is also available on the <code>DocumentBuilder</code> in the .NET API and in the new s9api Java API.
A validation error occurs if the document being validated has a top-level element with a different name.</p>
<p>I discovered that Saxon allows you to use the types <code>xs:dayTimeDuration</code> and <code>xs:yearMonthDuration</code>
in a schema as built-in types. XML Schema 1.0 doesn't recognize these types (though I can't find a rule that says it is
absolutely non-conformant to accept them). I have changed the code to give an interoperability warning if they are
used. I have also disallowed the use of the type <code>xs:anyAtomicType</code>, which has no defined validation
semantics.</p>
<p>The mechanisms for comparing values in the course of schema validation and processing have now been separated
completely from the mechanisms used when implementing XPath operators. This means that the semantics of comparison
and ordering should now follow the XML Schema specification precisely. Previously some operations were implemented
according to the XPath semantics.</p>
<p>A duplicate <code>xsi:schemaLocation</code> or <code>xsi:noNamespaceSchemaLocation</code> attribute is now
ignored (previously it was rejected under the rule that such an attribute cannot appear after the first element
in the relevant namespace). Duplicates can arise naturally from XInclude processing, so they are now accepted
and ignored. The schema specification permits this but does not require it. To be considered duplicates, the
declarations must match in the namespace URI and in the absolutized schemaLocation URI.</p>
<p class="subhead">Result tree validation</p>
<p>Saxon now does more extensive compile-time checking where an <code>xsl:document</code> or <code>xsl:result-document</code>
instruction requests validation of the result tree. This means that validation errors that were previously detected
at stylesheet execution time are now sometimes detected at compile time. Previously these checks were only done when
validation was requested on an element-constructor instruction.</p>
<p class="subhead">Expansion of attribute and element defaults</p>
<p>When the input or output of a query or transformation is validated, it is now possible to request that fixed and default
element and attribute values defined in the schema should not be expanded. This is done using the option <code>-expand:off</code>
on the command line, or equivalent options in the <code>TransformerFactory</code> and <code>Configuration</code> APIs.</p>
<p>The same option also applies to DTD-based attribute default expansion, provided that the XML parser reports sufficient
information to the application.</p>
<p class="subhead">Serializing a Schema Component Model</p>
<p>It is now possible to export the contents of the schema cache held in the <code>Configuration</code>
object to an XML file (with the conventional extension <code>.scm</code> for Schema Component Model). The contents
can subsequently be reloaded. This is faster than reloading the original source schema documents,
because it allows most of the validation to be skipped, along with the sometimes expensive operation of constructing
and determinizing finite state machines. This facility is intended to be used in conjunction with XQuery
Java code generation: it allows the schemas that were imported by a compiled query to be saved on disk alongside
the compiled query itself, for rapid reloading at run time.</p>
<p>The serialized SCM file is also designed to be easy for applications to process. The representation of schema components
is more uniform than in source .xsd documents (there are fewer defaults, and fewer alternative ways of expressing the same
information). This makes it a suitable representation for applications that need to process or analyze schema information,
as an alternative to using the Java API.</p>
<div class="boxed"
style="border: solid thin; background-color: #B1CCC7; padding: 2px">This has proved useful within Saxon itself. Saxon's schema analyzer was previously written using ad-hoc parsing techniques
to validate schemas against the rules defined in the schema-for-schemas. The addition of <code>assert</code> and <code>report</code>
elements threatened to make this even more complex. So a simple XSLT transformation was written to take the finite state
machines in the SCM version of the schema-for-schemas and generate Java code from them. This means that Saxon's schema validation
logic is now derived directly from the published schema-for-schemas, while retaining the efficiency of hard-coded Java.</div>
<p class="subhead">Changes to the Schema Component Model API</p>
<p>Changes have been made to the API for the schema component model (package <code>com.saxonica.schema</code>)
to align it more closely with the abstract model defined in the W3C specifications.</p>
<p>All named components now consistently expose
methods <code>getName()</code> and <code>getTargetNamespace()</code>
to provide access to the local part of the name and the namespace URI respectively.
The wide variety of existing names for these accessors have been retained for the
time being as deprecated methods. The new names are chosen because they correspond
to the names used for these properties in the W3C schema component model.</p>
<p>The class <code>FacetCollection</code> has disappeared; its functionality has been merged into <code>UserSimpleType</code>.</p>
<p>The class <code>Compositor</code> has been renamed <code>ModelGroup</code>, and its subclasses
such as <code>ChoiceCompositor</code> have been renamed accordingly. In the W3C schema model, the
compositor (all, choice, sequence) is one of the properties of the <code>ModelGroup</code>. This is now
available using the method <code>getCompositorName()</code> on the <code>ModelGroup</code> object.</p>
<p><code>Particle</code> is now an abstract class rather than an interface, and the previous
abstract class <code>AbstractParticle</code> no longer exists. There are three subclasses of
<code>Particle</code>, namely <code>ElementParticle</code>, <code>ElementWildcard</code>,
and <code>ModelGroupParticle</code>. This means there is now a destinction between the <code>ModelGroupParticle</code>,
which represents a reference to a <code>ModelGroup</code>, and the <code>ModelGroup</code> itself.
The class <code>ModelGroupDefinition</code> (which represents a named model group) no longer
implements <code>Particle</code>; it is now a subclass of <code>ModelGroup</code>.</p>
<p>The class <code>ModelGroupParticle</code> replaces <code>GroupReference</code>; it is no longer
necessarily a reference to a (named) <code>ModelGroupDefinition</code>, but now can be a reference
to any (named or unnamed) <code>ModelGroup</code>.</p>
<p><code>ElementWildcard</code> and <code>AttributeWildcard</code> are no longer subclasses
of <code>Wildcard</code>; instead <code>Wildcard</code> is now a helper class to which these
two classes delegate. Instead, <code>ElementWildcard</code> is now a subclass of <code>Particle</code>.
The <code>getTerm()</code> method of <code>ElementWildcard</code> returns the <code>Wildcard</code> object
(previously it returned the <code>ElementWildcard</code> object itself).</p>
<p>The use of exceptions <code>SchemaException</code> and <code>ValidationException</code> has been made
more consistent. A <code>SchemaException</code> indicates that the schema is invalid, and should occur only
while the schema is being loaded and validated. A <code>ValidationException</code> indicates that an instance
document is invalid against the schema, and should occur only during instance validation. Errors relating to the
consistency of a stylesheet or query against a valid schema should result in an <code>XPathException</code> being thrown.
An inconsistency in the schema found during instance validation is an internal error, and should result in an
<code>IllegalStateException</code>, except for unresolved references to missing schema components (which is defined
in the schema spec not to constitute a schema invalidity), which results in an <code>UnresolvedReferenceException</code>.
Because it can occur almost anywhere, <code>UnresolvedReferenceException</code> is an unchecked exception.</p>
<table width="100%">
<tr>
<td>
<p align="right"><a class="nav" href="oldapi90.xml">Next</a></p>
</td>
</tr>
</table>
</body>
</html>
