<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../make-menu.xsl" type="text/xsl"?><html>
   <head>
      <this-is section="conformance" page="schema11" subpage=""/>
      <!--
           Generated at 2011-12-09T20:47:22.916Z--><title>Saxonica: XSLT and XQuery Processing: XML Schema 1.1 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.1 Conformance"/>
      <meta name="robots" content="noindex,nofollow"/>
      <link rel="stylesheet" href="../saxondocs.css" type="text/css"/>
   </head>
   <body class="main">
      <h1>XML Schema 1.1 Conformance</h1>
      <p>Saxon includes a complete implementation of the proposed specification of XSD 1.1. At the time
      of release of Saxon 9.4, the specification is very close to becoming a Recommendation, and there is a test suite that is
      believed to cover all new features of the specification. Saxon achieves 100% pass rate againts these tests.
      Saxonica has worked closely with other implementors of XSD 1.1 to ensure that implementations are fully interoperable.
      There is still, however, a possibility that the treatment of some edge cases in the specification will change, or
      that new tests will be added which Saxon does not pass.</p>
      <p>XSD 1.1 features are available only if explicitly requested by using the -xsdversion:1.1 option
on the command line, or equivalent options in the API.</p>
      <p>The rules for valid type derivation follow the XML Schema 1.1 specification, regardless of this
option setting. This is because the rules in the 1.0 specification do not meet the stated intent, namely that
type derivation is valid in all cases where the restricted type allows a subset of the instances permitted
by the base type.</p>
      <p>An outline of the changes between XSD 1.0 and XSD 1.1 can be found in 
         <a href="http://www.w3.org/TR/xmlschema11-1/#changes" class="bodylink">Appendix G of the specification</a>.</p>
      <p class="subhead">Implementation-defined features</p>
      <p>Appendix E1 of XSD 1.1 (Part 1) provides a checklist of implementation-defined and implementation-dependent features.
      The following list describes how these are implemented in Saxon.</p>
      <ul>
         <li>
            <p><i>For the datatypes defined by [XML Schema: Datatypes] which depend on [XML 1.1] or [XML Namespaces 1.1], 
            it is ·implementation-defined· whether a schema processor takes the relevant definitions from [XML 1.1] 
            and [XML Namespaces 1.1], or from [XML 1.0] and [Namespaces in XML 1.0]. Implementations may support either 
            the ·XML-1.0-based· datatypes, or the ·XML-1.1-based· datatypes, or both. The same applies to the definition of whitespace.
         </i></p>
            <p>The definition of whitespace is the same in all XML editions. The definition of the syntax of names is the same
            in XML 1.1 and in XML 1.0 fifth edition, and Saxon uses this definition</p>
         </li>
         <li>
            <p><i>It is ·implementation-defined· whether a schema processor can read schema documents in the form of XML documents.
         </i></p>
            <p>Saxon-EE can read XML schema documents.</p>
         </li>
         <li>
            <p><i>Whether a processor is able to retrieve schema documents from the Web is ·implementation-defined·. (See Conformance (§2.4), which defines "·Web-aware·" processors as processors which can retrieve schema documents from the Web.)
         </i></p>
            <p>Saxon-EE is able to read XML schema documents from the Web.</p>
         </li>
         <li>
            <p><i>The way in which a processor is invoked, and the way in which values are specified for the schema to be used,
            the information item to be validated, and the declaration or definition with which to begin validation, 
            is ·implementation-defined·. 
         </i></p>
            <p>Saxon-EE allows validation to be invoked from the command line, via a Java or .NET API, or from XSLT and XQuery.
         The documentation fors interfaces provides the required information.</p>
         </li>
         <li>
            <p><i>The manner in which a processor provides access to the information items and properties in the PSVI 
            to any downstream or user applications, or to the invoker, is ·implementation-defined·.
         </i></p>
            <p>Saxon provides only that part of the PSVI used by the XQuery and XSLT specifications. This amounts to adding a type
         annotation to each element and attribute node where the outcome of validation is 'valid', and providing error messages
         where it is not.</p>
         </li>
         <li>
            <p><i>The information items and properties in the PSVI to which the processor provides access, 
            if any, is ·implementation-defined·. 
         </i></p>
            <p>See previous answer.</p>
         </li>
         <li>
            <p><i>When the ·post-schema-validation infoset· includes [type definition name] and similar properties, 
            it is ·implementation-defined· whether unique names are provided for anonymous type definitions.
         </i></p>
            <p>Saxon allocates unique names to anonymous type definitions.</p>
         </li>
         <li>
            <p><i>The method used for assembling a set of schema components for use in validation is ·implementation-defined·. 
         </i></p>
            <p>Saxon generally assembles schema components from XML schema documents as described in the XSD specification.
         However, it has built-in knowledge of the schema for the XML namespace, and these components can be included in a schema
         simply by importing the relevant namespace. It also has built-in knowledge of the schema components defined
         in the FN namespace, used in the result document of the <code>analyze-string</code> function in XPath 3.0</p>
         </li>
         <li>
            <p><i>It is ·implementation-defined· whether a schema processor provides a value for the 
            [type definition name] and [member type definition name] properties of attribute and element information-items. 
            If it does so, the choice of name is ·implementation-dependent·.
         </i></p>
            <p>The information is not directly available.</p>
         </li>
         <li>
            <p><i>Everything ·implementation-defined· in [XML Schema: Datatypes] is also ·implementation-defined· in this specification.
         Note: This includes, but is not limited to, the choice of ·XML-1.0-based· or ·XML-1.1-based· datatypes, or both; 
         support for ·implementation-defined· primitive datatypes; and support for ·implementation-defined· constraining facets. 
         See the appendix on implementation-defined and implementation-dependent features in [XML Schema: Datatypes].
         </i></p>
            <p>See the checklist that follows.</p>
         </li>
         <li>
            <p><i>It is ·implementation-defined· whether a processor detects violations of clause 2.4.2 of 
            Derivation Valid (Restriction, Complex) (§3.4.6.3) (a) always by examination of the schema in isolation, 
            (b) only when some element information item in the input document is valid against its ·governing type definition· T 
            but not against T.{base type definition}, or (c) sometimes the one and sometimes the other. 
            In case (c), the circumstances in which the processor does one or the other are ·implementation-dependent·.
         </i></p>
            <p>Saxon-EE attempts to detect all violations of Derivation Valid by examination of the schema in isolation; if it is not
         able to determine at this stage that the derivation is valid, the schema is considered to be in error.</p>
         </li>
         <li>
            <p><i>It is ·implementation-defined· when a processor detects type errors in XPath expressions and whether it treats 
            type errors as static or dynamic errors.
         </i></p>
            <p>Saxon uses optimistic static type checking; it reports a static error in the XPath expression if its type analysis
         concludes that the type of a supplied value and the type required by the context in which it is used are disjoint, so that execution
         can never succeed.</p>
         </li>
         <li>
            <p><i>It is ·implementation-defined· under what conditions a processor will detect the equivalence of 
            two distinct Type Table or Type Alternative components. All processors must detect equivalence under 
            certain specified conditions, but the ability to detect equivalence under other conditions is not constrained.
         </i></p>
            <p>In considering whether two type tables are equivalent, Saxon tests the equivalence of XPath expressions by comparing
            their normalized expression trees. Inessential factors such as whitespace and parentheses are therefore ignored, and 
            in some cases different expressions are recognized as equivalent, for example <code>(a=b)</code> is equivalent to
            <code>(b=a)</code>. In general the two expressions must have the same static context, but differences in the static context
            that do not affect the outcome of evaluating the expressions may be discounted.</p>
         </li>
         <li>
            <p><i>It is ·implementation-defined· what effect invalid elements within 
               &lt;annotation&gt; have on the construction of schema components from a schema document, 
               and whether a processor treats schema documents which are invalid only in consequence of 
               containing such invalid elements as being in ·error· or not.
            </i></p>
            <p>Saxon ignores the content of annotations entirely, other than ensuring that they are
            namespace-well-formed.</p>
         </li>
      </ul>
      <p>A similar checklist appears in appendix H.1 of XSD 1.1 Part 2. The corresponding answers for Saxon-EE are given below.</p>
      <ul>
         <li>
            <p><i>For the datatypes which depend on [XML] or [Namespaces in XML], it is ·implementation-defined· 
         whether a conforming processor takes the relevant definitions from [XML] and [Namespaces in XML], 
         or from [XML 1.0] and [Namespaces in XML 1.0]. Implementations may support either the form of these datatypes based on version 1.0 of those specifications, or the form based on version 1.1, or both.
      </i></p>
            <p>See above. The definitions are taken from XML 1.0 Fifth Edition and XML 1.1, which are identical.</p>
         </li>
         <li>
            <p><i>For the datatypes with infinite ·value spaces·, it is ·implementation-defined· whether 
            conforming processors set a limit on the size of the values supported. 
            If such limits are set, they must be documented, and the limits must be equal to, or exceed, 
            the minimal limits specified in Partial Implementation of Infinite Datatypes (§5.4). .
         </i></p>
            <p>For integers, decimals, and strings, the only limits imposed by Saxon are those inherent in the underlying Java
         types <code>BigInteger</code>, <code>BigDecimal</code>, and <code>String</code>.</p>
            <p>For calendar data types, the year must be in the range of a signed 32-bit integer.</p>
            <p>For durations, the number of months must fit in a signed 32-bit integer; the integer number of seconds must fit
         in a signed 64-bit integer, and the precision is to microseconds.</p>
         </li>
         <li>
            <p><i>It is ·implementation-defined· whether ·primitive· datatypes other than those defined in this 
            specification are supported.
         </i></p>
            <p>Saxon does not support any additional primitive datatypes.</p>
         </li>
         <li>
            <p><i>It is ·implementation-defined· whether ·constraining facets· other than those defined in this specification are supported.
      </i></p>
            <p>Saxon supports an additional facet, <code>saxon:preprocess</code>. This is a pre-lexical facet that
      invokes user-written Java code to modify a value before validation and before serialization. For example,
      this can be used to allow <code>xs:decimal</code> values to be written using comma as a decimal point. For details
      see <a class="bodylink" href="../schema-processing/extensions11/preprocess.xml">The saxon:preprocess facet</a>.</p>
         </li>
      </ul>
      <table width="100%">
         <tr>
            <td>
               <p align="right"><a class="nav" href="serialization.xml">Next</a></p>
            </td>
         </tr>
      </table>
   </body>
</html>