<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../../make-menu.xsl" type="text/xsl"?><html>
<head>
<this-is section="changes" page="intro92" subpage="xsd92"/>
<!--
Generated at 2011-12-09T20:47:22.916Z--><title>Saxonica: XSLT and XQuery Processing: XML Schema</title>
<meta name="coverage" content="Worldwide"/>
<meta name="copyright" content="Copyright Saxonica Ltd"/>
<meta name="title" content="Saxonica: XSLT and XQuery Processing: XML Schema"/>
<meta name="robots" content="noindex,nofollow"/>
<link rel="stylesheet" href="../../saxondocs.css" type="text/css"/>
</head>
<body class="main">
<h1>XML Schema</h1>
<p class="subhead">XML Schema 1.0</p>
<p>The implementation of <code>xs:redefine</code> has been revised slightly, to better reflect the notion of "pervasiveness"
described (with tantalising lack of detail) in the language specification. Every component now has a redefinition level;
a component defined within <code>xs:redefine</code> has a redefinition level one higher than that of the component it
redefines. If two different but identically-named components have the same redefinition level, this is an error; but if they
have different redefinition levels, the higher one wins. An example where this comes into play is if a module R.XSD contains
two <code>xs:redefine</code> elements; the first one redefines A.XSD, which itself includes B.XSD, and the second redefines
B.XSD, providing a revised version of a type T contained in B.XSD. Previously Saxon reported this as an error, on the grounds
that the schema returned by the first <code>xs:redefine</code> and the schema returned by the second <code>xs:redefine</code>
could not be combined because they contained incompatible definitions of type T. This schema is now accepted as valid,
and the redefined type T wins.</p>
<p>In the command line interface, a new option <code>-config:filename</code> is available. This refers to a configuration
file in which many
configuration options can be specified. The configuration described by this file must be an EnterpriseConfiguration.
Options specified directly on the command line override corresponding options
in the configuration file. The format of the configuration file is given in
<a class="bodylink" href="../../configuration/configuration-file.xml">The Saxon configuration file</a>.</p>
<p>The bogus <code>gMonth</code> format <code>--MM--</code> is no longer accepted. This format appeared in error in the
original XML Schema 1.0 Recommendation, and was subsequently corrected by erratum. It still appears in a number of books on XML Schema.
It was recognized in all Saxon releases until and including 9.1. The correct format is <code>--MM</code>.</p>
<p class="subhead">XML Schema 1.1</p>
<p>The type <code>xs:error</code> has been implemented.</p>
<p>The facility for conditional inclusion of parts of schema documents, based on attributes such as <code>vc:minVersion</code> and
<code>vc:maxVersion</code>, is now implemented. This works whether the schema processor is in 1.0 or 1.1 mode, allowing a schema
that is processed in 1.0 mode to ignore facilities such as assertions that require XSD 1.1.</p>
<p>For this purpose the set of types that are "automatically known" to the processor includes only the built-in types (which are currently
the same for XSD 1.0 and XSD 1.1, with the exception of <code>xs:error</code> which is available only in 1.1), and the set of facets are the built-in
facets, which includes <code>xs:assert</code> when running in 1.1 mode, but not when running in 1.0 mode.</p>
<p>An element declaration may now appear in more than one substitution group.</p>
<p>The <code>ref</code> attribute of <code>xs:unique</code>, <code>xs:key</code>, and <code>xs:keyref</code> has been implemented.</p>
<p>The <code>notNamespace</code> and <code>notQName</code> attributes are now supported on <code>xs:any</code> and
<code>xs:anyAttribute</code> wildcards. However, the option <code>notQName="##definedSibling"</code> is not yet
implemented. </p>
<p>Although these attributes are only available when XSD 1.1 is enabled (command line switch <code>-xsdversion:1.1</code>),
a side-effect of the change is that wildcard unions and intersections that were not expressible in 1.0 are now expressible,
and this change applies whether or not 1.1 is enabled. This means that some rather obscure conditions that are errors in
1.0 but not in 1.1 are no longer detected as errors.</p>
<p>The algorithm for testing subsumption among <code>xs:all</code> content models now performs a more intelligent analysis of
wildcard particles.</p>
<p>Open content is implemented. The <code>xs:defaultOpenContent</code> element can appear as a child of <code>xs:schema</code>,
and and <code>xs:openContent</code> as a child of <code>xs:complexType</code>, <code>xs:extension</code> or
<code>xs:restriction</code>. This works with sequence, all, empty and mixed
content models.</p>
<p>There are some limitations in subsumption testing: for a type R to be a valid restriction of B, the "primary content" of R
must be a valid restriction of the primary content of B, and the "open content" of R must be a valid restriction of the
open content of B.</p>
<p>Default attributes are implemented (that is, the <code>defaultAttributes</code> attribute of <code>xs:schema</code>,
and the <code>defaultAttributesApply</code> attribute of <code>xs:complexType</code>).</p>
<p>An <code>xs:all</code> content model may now be derived by extension from another <code>xs:all</code> content model.</p>
<p>A new facet <code>xs:explicitTimezone</code> is available with values <code>required</code>, <code>optional</code>, or <code>prohibited</code>.
This allows control of whether
or not the timezone part of a <code>date</code>, <code>time</code>, <code>dateTime</code>, <code>gYear</code>,
<code>gYearMonth</code>, <code>gMonth</code>, <code>gMonthDay</code>, or <code>gDay</code> is present or absent.</p>
<p>The new built-in data type <code>xs:dateTimeStamp</code> (an <code>xs:dateTime</code> with timezone required)
is implemented.</p>
<p class="subhead">Saxon XSD Extensions</p>
<p>In assertions, and on all elements representing facets (for example <code>pattern</code>),
Saxon supports the attribute <code>saxon:message="message text"</code>.
This message text is used in error messages when the assertion or facet is not satisfied.</p>
<p>The XSD 1.1 specification allows vendor extensions in the form of vendor-defined primitive types and vendor-defined
facets. Saxon 9.2 exploits this freedom to provide a new facet, <code>saxon:preprocess</code>. This is a pre-lexical
facet (like <code>xs:whiteSpace</code>) in that it is used to transform the supplied value before validation. The preprocessing
is done using an arbitrary XPath expression which takes a string as input and produces a string as output. For example
<code><saxon:preprocess action="normalize-unicode($value)"/></code> can be used to perform Unicode normalization, while
<code><saxon:preprocess action="upper-case($value)"/></code> normalizes the value to upper case. This
is done before application of other facets such as the <code>pattern</code> and <code>enumeration</code> facets.
It is also possible to provide another XPath expression to reverse the process, for use when the typed value
is converted back to a string.
For more information see <a class="bodylink" href="../../schema-processing/extensions11/preprocess.xml">The saxon:preprocess facet</a>.</p>
<table width="100%">
<tr>
<td>
<p align="right"><a class="nav" href="streaming92.xml">Next</a></p>
</td>
</tr>
</table>
</body>
</html>
