<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../../make-menu.xsl" type="text/xsl"?><html>
<head>
<this-is section="changes" page="intro93" subpage="xsd11-93"/>
<!--
Generated at 2011-12-09T20:47:22.916Z--><title>Saxonica: XSLT and XQuery Processing: XML Schema 1.1 changes</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.1 changes"/>
<meta name="robots" content="noindex,nofollow"/>
<link rel="stylesheet" href="../../saxondocs.css" type="text/css"/>
</head>
<body class="main">
<h1>XML Schema 1.1 changes</h1>
<p>The <code>xs:override</code> declaration is implemented. Pending resolution of specification bug 9661, a declaration that appears within
<code>xs:override</code> and does not override anything in the overridden schema is included in the schema; the other possible interpretation
of the specification is that it should be ignored. Restrictions: circular <code>xs:override</code> chains are not allowed, and
there has been no testing of the interaction of <code>xs:override</code> with <code>xs:redefine</code>.</p>
<p>Saxon recognizes the attribute <code>saxon:extensions</code> on the <code>xs:schema</code> element: the value is a space-separated
list of strings giving the names of extensions that are enabled in this schema document. If the extension <code>id-xpath-syntax</code>
is enabled, then the XPath syntax permitted in the <code>xs:selector</code> and <code>xs:field</code> elements of uniqueness, key
and keyref constraints is extended to allow any <i>streaming pattern</i>. For example, this allows the use of attribute-based predicates, such as
<code>xpath="employee[@location='us']"</code></p>
<p>The new primitive type <code>xs:precisionDecimal</code> is implemented - at least, to the extent required for schema validation.
It is not recommended yet to use this type in documents subject to query and transformation, or to use it for free-standing atomic values,
since (a) there is no specification for how operations such as arithmetic and comparison should behave in XPath, (b) there are gaps
in the implementation in this area, (c) very limited testing has been done, and (d) the type could yet be dropped (it is marked as
a "feature at risk", and there is some political objection to it).</p>
<p>Inheritable attributes are implemented (for use in Conditional Type Assignment only: the only effect of declaring an attribute to be inheritable is that
it can be referenced in the XPath condition of the <code>xs:alternative</code> element).</p>
<p>An element may now have more than one ID attribute.
Several ID attributes or children of an element may have the same value. ID and IDREF values appearing within a list, or as a member
type of a union, are now recognized.
(Most of these changes have been applied also to XSD 1.0, with the exception that multiple ID attributes are not allowed
on an element. Saxon 9.2 and earlier releases correctly allowed an element to have more than one ID-valued child element,
but incorrectly reported an error if more than one ID-valued child of the same parent element had the same ID value.
The rules for list types and union types with an ID or IDREF member are unclear in XSD 1.0, so for simplicity, the
XSD 1.1 rules have been implemented unconditionally.</p>
<p>It is now an error for the outermost element of the document (the validation root) to be of type <code>xs:ID</code>. (The rules in the
W3C spec have always implied this, though many cases in the W3C test suite consider this to be valid. The Working Group has confirmed
in its decision on bug #9922 that this is intended to be invalid.)</p>
<p>In element wildcards, <code>notQName="##definedSibling"</code> is implemented.</p>
<p>An <code>xs:all</code> group may now contain an <code>xs:group</code> element to refer to a named model group declaration, provided the
named model group definition in turn contains an <code>xs:all</code> group, and that <code>minOccurs</code> = <code>maxOccurs</code> = <code>1</code>.</p>
<p>The way that <code>xs:anyURI</code> values are checked (to see if they are valid URIs) has changed. In accordance with the W3C
specifications, there is now no checking at all when XSD 1.1 is selected at the <a class="bodylink" href="../../javadoc/net/sf/saxon/Configuration.html"><code>Configuration</code></a> level -
any string may be used. When 1.0
is selected, strings are checked to be valid URIs (as defined by the <code>java.net.URI</code> class) only when performing schema validation, or
explicit casting from string to <code>xs:anyURI</code>. There is no longer any check performed by methods such as <code>namespace-uri()</code>
or <code>namespace-uri-from-QName</code>, regardless whether XSD 1.0 or XSD 1.1 is selected in the Configuration. It is also possible
to configure the checking that is performed to use a user-supplied <code>URIChecker</code>, for example one that performs stricter or
more liberal checking.</p>
<table width="100%">
<tr>
<td>
<p align="right"><a class="nav" href="s9api-93.xml">Next</a></p>
</td>
</tr>
</table>
</body>
</html>
