<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../../make-menu.xsl" type="text/xsl"?><html>
   <head>
      <this-is section="changes" page="intro" subpage="xsd-94"/>
      <!--
           Generated at 2011-12-09T20:47:22.916Z--><title>Saxonica: XSLT and XQuery Processing: Changes to XSD support</title>
      <meta name="coverage" content="Worldwide"/>
      <meta name="copyright" content="Copyright Saxonica Ltd"/>
      <meta name="title"
            content="Saxonica: XSLT and XQuery Processing: Changes to XSD support"/>
      <meta name="robots" content="noindex,nofollow"/>
      <link rel="stylesheet" href="../../saxondocs.css" type="text/css"/>
   </head>
   <body class="main">
      <h1>Changes to XSD support</h1>
      <p>Various minor changes have been made to bring Saxon 9.4 into full conformance with
   the XSD 1.1 specification. Most of these are edge cases and bug fixes, mostly
   prompted by resolution of issues in the specification.</p>
      <p>Assertions in XSD 1.1 now use the correct rules for typing (that is, for type annotation of the
      tree made visible to the XPath expression defining the assertion).</p>
      <p>Following its removal from XSD 1.1, support for the <code>xs:precisionDecimal</code>
   data type has been dropped.</p>
      <p>In regular expressions, the block names that are recognized (whether running
   XSD 1.0 or 1.1) in constructs of the form <code>\p{IsBlockName}</code> now include
   blocks defined in all Unicode versions from version 3.1 to version 6.0 inclusive.
   Where the characters included in a block differ from one version to another, Saxon
   recognizes the union of the various definitions. When XSD 1.1 is enabled Saxon treats
   an unrecognized block name as a warning condition rather than an error; in this case
   both <code>\p{IsBlock}</code> and <code>\P{IsBlock}</code> will match any character.
   For example, Saxon now recognizes both <code>\p{IsGreek}</code> and 
   <code>\p{IsGreekAndCoptic}</code>. Internally, the recognition of block names no longer
   depends on what is recognized by the underlying Java regex library.</p>
      <p>In regular expressions, character category matches such as <code>\P{Nd}</code>
   now use the categorization of characters defined in Unicode 6.0.0. This not only
   affects characters added to Unicode since Unicode version 3.1, it also changes the
   categorization of some existing characters.</p>
      <p>In regular expressions, the metacharacters <code>\i</code> and <code>\c</code>
   now use the definitions of name characters from XML 1.0 fifth edition and XML 1.1 second
   edition (which are identical), regardless whether XML 1.1 support is enabled or not.</p>
      <p>All testing of names in Saxon now uses the rules defined in XML 1.1 and in XML 1.0 fifth
   edition (which are identical), whether or not XML 1.1 or XSD 1.1 is enabled. This includes <code>\i</code>
   and <code>\c</code> in regular expressions, the rules for data types such as <code>xs:NCName</code>
   and <code>xs:QName</code>, parsing of names in XPath expressions and XQuery element constructors,
   etc. The only thing not covered is where names are checked by non-Saxon software, for example
   the XML parser.</p>
      <p>A configuration option <a class="bodylink" href="../../javadoc/net/sf/saxon/lib/FeatureKeys.html"><code>MULTIPLE_SCHEMA_IMPORTS</code></a> 
            has been added to force
            <code>xs:import</code> to fetch the referenced schema document. By default the <code>xs:import</code>
   fetches the document only if no schema document for the given namespace has already been loaded. With this
   option in effect, the referenced schema document is loaded unless the absolute URI is the same as a schema document already
   loaded.</p>
      <p>A configuration option <a class="bodylink" href="../../javadoc/net/sf/saxon/lib/FeatureKeys.html"><code>ASSERTIONS_CAN_SEE_COMMENTS</code></a> has been added to control
   whether comments and processing instructions are visible to the XPath expression used to define
   an assertion. By default (unlike Saxon 9.3), they are not made visible.</p>
      <p>On the <code>com.saxonica.Validate</code> command line, a new option <code>-stats:filename</code>
            is available: it causes statistics about the validation episode to be captured in the specified XML file.</p>
      <table width="100%">
         <tr>
            <td>
               <p align="right"><a class="nav" href="functions-94.xml">Next</a></p>
            </td>
         </tr>
      </table>
   </body>
</html>