<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../make-menu.xsl" type="text/xsl"?><html>
   <head>
      <this-is section="conformance" page="xpath20" subpage=""/>
      <!--
           Generated at 2010-10-29T18:20:48.427+01:00--><title>Saxonica: XSLT and XQuery Processing: XPath 2.0 conformance</title>
      <meta name="coverage" content="Worldwide"/>
      <meta name="copyright" content="Copyright Saxonica Ltd"/>
      <meta name="title"
            content="Saxonica: XSLT and XQuery Processing: XPath 2.0 conformance"/>
      <meta name="robots" content="noindex,nofollow"/>
      <link rel="stylesheet" href="../saxondocs.css" type="text/css"/>
   </head>
   <body class="main">
      <h1>XPath 2.0 conformance</h1>
      <p>This release of Saxon implements
the full XPath 2.0 language as defined in the
 <a href="http://www.w3.org/TR/xpath20/" class="bodylink">Recommendation</a> of 23 January 2007.</p>
      <p>There are some minor non-conformances in XPath 2.0 regular expression support, both caused
by bugs or restrictions in the underlying platform:</p>
      <ul>
         <li content="para">
            <p>When the "i" flag is used in conjunction with back-references, Saxon relies on the
semantics of the underlying regular expression engine for case-independent matching. On most platforms
the behaviour is not identical to the rules defined in XPath, though typically this only affects corner cases.</p>
         </li>
      </ul>
      <p>All the functions defined in the <a href="http://www.w3.org/TR/xpath-functions" class="bodylink">Functions and Operators</a>
specification are implemented. Information about the way they are implemented is provided in 
<a class="bodylink" href="../functions/intro.xml">functions reference</a>.</p>
      <p>There is a non-conformance in the implementation of the <code>collection()</code> function:
with the default collection URI resolver, the results are not guaranteed to be stable. 
That is, when the same collection URI is used more
than once, both the contents of the collection and the contents of the documents within the 
collection may be different on each occasion. It is possible to achieve stable results with
a user-written collection URI resolver.</p>
      <p class="subhead">Implementation-defined aspects of Functions and Operators</p>
      <p>The Functions and Operators specification includes a number of implementation-defined behaviors.
This section describes how these are implemented in Saxon.</p>
      <ol>
         <li>
            <p><i>The destination of the trace for fn:trace() output is implementation-defined.
</i></p>
            <p>By default trace output is sent to the standard error output. It can be redirected in various ways: by redirecting System.err,
by supplying a user-written MessageEmitter, or by changing the output destination of the standard
MessageEmitter to a defined output stream or writer.</p>
         </li>
         <li>
            <p><i>For [overflow during] xs:integer operations, implementations that support limited-precision integer operations
must either raise an error [err:FOAR0002] or provide an implementation-defined mechanism that allows 
users to choose between raising an error and returning a result that is modulo the largest 
representable integer value.</i></p>
            <p>Saxon supports unlimited-precision integer arithmetic, so this provision does not apply.</p>
         </li>
         <li>
            <p><i>For xs:decimal values the number of digits of precision returned by the numeric operators
 is implementation-defined. If the number of digits in the result exceeds the number of digits
  that the implementation supports, the result is truncated or rounded in an implementation-defined manner.
</i></p>
            <p>Saxon supports unlimited-precision decimal arithmetic. For addition, subtraction, and multiplication, 
no rounding or truncation occurs; the full precision of the result is maintained. For division, the number
of digits in the result is: the number of digits in the numerator, the number of digits in
the divisor, or 18, whichever is greatest. Rounding of values in the range .0 to .5 inclusive is towards zero,
otherwise away from zero.</p>
         </li>
         <li>
            <p><i>It is implementation-defined which version of Unicode is supported by the features 
defined in this specification, but it is recommended that the most recent version of Unicode be used.
</i></p>
            <p>Some functions such as the implementations of <code>upper-case()</code> and <code>lower-case()</code>
are delegated to the Java VM, and the result therefore depends on the Unicode version supported by the
Java VM. In JDK 5.0 this is Unicode version 4.0.</p>
            <p>Other functions such as <code>normalize-unicode()</code> are implemented natively within Saxon. The character
tables used for this are derived from the Unicode 4.0 database.</p>
         </li>
         <li>
            <p><i>For normalize-unicode(), conforming implementations must support normalization
 form "NFC" and may support normalization forms "NFD", "NFKC", "NFKD", "FULLY-NORMALIZED".
  They may also support other normalization forms with implementation-defined semantics.
</i></p>
            <p>Saxon currently supports normalization forms NFC, NFD, NFKC, and NFKD.</p>
         </li>
         <li>
            <p><i>The ability to decompose strings into collation units suitable for substring matching
 is an implementation-defined property of a collation.</i></p>
            <p>Saxon supports this capability for a collation implemented using a Java <code>RuleBasedCollator</code>.
Any Java <code>Comparator</code> can be used to implement a collation, but the substring matching functions
will fail (error FOCH0004) if the <code>Comparator</code> is not a <code>RuleBasedCollator</code>.</p>
            <p>Saxon also supports this capability on the .NET platform. However, the results delivered by the collation
support on the .NET platform do not appear to be 100% aligned with the XPath specification.</p>
         </li>
         <li>
            <p><i>All minimally conforming processors must support year values with a 
 minimum of 4 digits (i.e., YYYY) and a minimum fractional second precision of 
 1 millisecond or three digits (that is, s.sss). However, conforming processors may set 
 larger implementation-defined limits on the maximum number of digits they support
 in these two situations.</i></p>
            <p>Saxon allows the year to be any 32-bit signed integer. Computations involving negative
 years are not encouraged because of speculation in the XML Schema specification about future changes
 to the semantics of the data type. Seconds are supported to a fractional precision of six digits
 (that is, microsecond precision).</p>
         </li>
         <li>
            <p><i>Various aspects of the processing provided by <code>doc()</code> are 
 implementation-defined. Implementations may provide external configuration options that
  allow any aspect of the processing to be controlled by the user.</i></p>
            <p>Saxon allows the URI dereferencing to be performed using a user-supplied <code>URIResolver</code>,
 as defined in the JAXP specification, or using an <code>XmlResolver</code> on the .NET platform.
  Saxon also provides various options to control whitespace stripping,
 validation using a DTD or schema, handling of errors, and support for XML 1.1. If appropriate configuration
 options are set, then query parameters are recognized in the URI to control some of these decisions.</p>
         </li>
      </ol>
      <table width="100%">
         <tr>
            <td>
               <p align="right"><a class="nav" href="xquery.xml">Next</a></p>
            </td>
         </tr>
      </table>
   </body>
</html>