<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../make-menu.xsl" type="text/xsl"?><html>
<head>
<this-is section="conformance" page="xslt20" subpage=""/>
<!--
Generated at 2011-12-09T20:47:22.916Z--><title>Saxonica: XSLT and XQuery Processing: XSLT 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: XSLT 2.0 conformance"/>
<meta name="robots" content="noindex,nofollow"/>
<link rel="stylesheet" href="../saxondocs.css" type="text/css"/>
</head>
<body class="main">
<h1>XSLT 2.0 conformance</h1>
<p>This release of Saxon is a complete implementation of the XSLT 2.0
<a href="http://www.w3.org/TR/xslt20/" class="bodylink">Recommendation</a> of 23 January 2007,
together with all errata published up to 10 April 2009, which are consolidated
in the <a href="http://www.w3.org/TR/2009/PER-xslt20-20090421/" class="bodylink">Proposed Edited Recommendation</a> of 21 April 2009.</p>
<p>Saxon-HE 9.x and Saxon-PE 9.x act as a <i>Basic XSLT Processor</i>,
while Saxon-EE 9.x acts as a <i>Schema-Aware XSLT Processor</i>. The distinction is that a Basic XSLT Processor
does not allow schemas to be imported and does not support validation of source or result documents or reference
to user-defined types. These correspond to the two conformance levels defined in the XSLT 2.0 specification.</p>
<p>The XSLT 2.0 specification defines two optional conformance features, the serialization feature and
the backwards compatibility feature. These optional features are implemented all three Saxon editions.</p>
<p>The following non-conformances apply only on the .NET platform, and only when using the Microsoft <code>System.Xml</code> parser:</p>
<ul>
<li content="para">
<p>Under .NET, when the <code>System.Xml</code> parser is used, attributes declared in the DTD as being
of type <code>ID</code> are not accessible using the <code>id()</code> function. This is because the
<code>System.Xml</code> parser (<code>XMLValidatingReader</code>) does not make the DTD-defined attribute type available
to the application.</p>
</li>
<li content="para">
<p>Similarly, when the <code>System.Xml</code> parser is used, unparsed entities are not reported to Saxon by the .NET
parser, so the calls <code>unparsed-entity-uri()</code> and <code>unparsed-entity-public-id()</code> will always
return a zero-length string.</p>
</li>
</ul>
<p>These restrictions do not apply when a JAXP parser is used in place of the Microsoft parser. Since 9.3,
the JAXP parser has therefore been the default.
Setting the option <code>processor.SetProperty("http://saxon.sf.net/feature/preferJaxpParser", "true")</code>
causes Saxon to use the Apache Xerces parser in preference to the (Microsoft) <code>System.Xml</code>
parser. Xerces is bundled in the Saxon DLL; this parser is used in preference to the JAXP parser included in the
OpenJDK library because it is more reliable and because it has no unnecessary references to other libraries.</p>
<p class="subhead">Test results</p>
<p>Saxonica has submitted test results for the W3C XSLT Test Suite. At present this test suite, and the
submitted results, are available to W3C members only. Saxon's submitted results in the suite (for Saxon 8.8, which was the
first version to claim conformance), are available
<a href="http://www.saxonica.com/conformance/xslts1.0.4/published-results8.8.html"
class="bodylink">here</a>.</p>
<p>A number of bugs have been raised against the XSLT 2.0 specification which are not yet the subject of
published errata. The most significant is <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5857" class="bodylink">Bug 5857</a>,
which affects whether or not <code>xmlns=""</code> namespace undeclarations should appear in the result
of copy operations. Saxon 9.4 partially implements the proposed fix to this bug.</p>
<p class="subhead">Checklist of Implementation-Defined Items</p>
<p>The following list describes the way in which Saxon implements the features that the specification
leaves implementation-defined. The numbering of items in the list corresponds to the numbering
in the checklist provided as
<a href="http://www.w3.org/TR/xslt20/#implementation-defined-features"
class="bodylink">Appendix F of the XSLT 2.0 specification</a>.</p>
<ol>
<li>
<p><i>The way in which an XSLT processor is invoked, and the way in which values are supplied
for the source document, starting node, stylesheet parameters, and base output URI,
are implementation-defined. (See 2.3 Initiating a Transformation)</i></p>
<p>Saxon offers a <a class="bodylink" href="../using-xsl/commandline.xml">command line interface</a>,
and a <a class="bodylink" href="../using-xsl/embedding.xml">Java API</a>. The Java API conforms to the JAXP 1.3 Transformation interface
defined in the JDK specifications, extended as necessary to support XSLT 2.0 facilities.</p>
</li>
<li>
<p><i>The mechanisms for creating new extension instructions and extension functions are
implementation-defined. (See 2.7 Extensibility)
</i></p>
<p>The mechanisms offered by Saxon are described in <a class="bodylink" href="../extensibility/instructions.xml">Extension instructions</a>
<a class="bodylink" href="../extensibility/functions.xml">extension functions</a> respectively.</p>
</li>
<li>
<p><i>Where the specification provides a choice between signaling a dynamic error or recovering,
the decision that is made (but not the recovery action itself) is implementation-defined.
(See 2.9 Error Handling)
</i></p>
<p>In most cases Saxon allows the user to make this choice, using the options -w0, -w1, and -w2 on the command line
(meaning respectively: ignore the error silently, continue after a warning, treat the error as fatal).
Equivalent options are also available in the Java API.</p>
<p>There are some cases where this does not apply:</p>
<ul>
<li content="para">
<p>XTRE1160 (unrecognized media type):
this error is not detected, Saxon always takes the recovery action.</p>
</li>
<li content="para">
<p>XTRE1630 (disable-output-escaping when the result is not serialized):
this error is not detected, Saxon always takes the recovery action.</p>
</li>
</ul>
</li>
<li>
<p><i>It is implementation-defined whether type errors are signaled statically. (See 2.9 Error Handling)</i></p>
<p>Saxon does extensive type checking at compile time, though it does not follow the precise inference rules as
defined in the W3C <i>Formal Semantics</i>. Errors are signaled statically only where a construct cannot
possibly succeed (that is, where it will always fail with a type error at run time if evaluated).
Warnings are signaled (a) where a path expression will always return an empty sequence
(for example, @x/@y), and (b) in the case of a construct that can
only succeed if the supplied value is an empty sequence, for example when comparing values whose statically-inferred
types are <code>integer?</code> and <code>string?</code> respectively.</p>
</li>
<li>
<p><i>The handling of serialization errors is implementation-defined. (See 2.9 Error Handling)
</i></p>
<p>Saxon reports all serialization errors defined in the serialization specification, and treats them
as fatal unless the serialization specification itself defines them as recoverable, in which case they
are handled as warnings.</p>
</li>
<li>
<p><i>The set of namespaces that are specially recognized by the implementation
(for example, for user-defined data elements, and extension attributes) is implementation-defined.
(See 3.6.2 User-defined Data Elements)
</i></p>
<p>The only namespace that is specially recognized is <code>http://saxon.sf.net/</code>.</p>
</li>
<li>
<p><i>The effect of user-defined data elements whose name is in a namespace recognized by the
implementation is implementation-defined. (See 3.6.2 User-defined Data Elements)
</i></p>
<p>The user-defined data elements recognized by Saxon (for example, <code>saxon:collation</code>,
<code>saxon:import-query</code>, and <code>saxon:script</code>) are described in
<a class="bodylink" href="../extensions/instructions.xml">extension instructions</a>. Any other element in the Saxon namespace
is signaled as an error.</p>
</li>
<li>
<p><i>It is implementation-defined whether an XSLT 2.0 processor supports backwards-compatible behavior.
(See 3.8 Backwards-Compatible Processing)
</i></p>
<p>Saxon supports backwards-compatible behavior.</p>
</li>
<li>
<p><i>It is implementation-defined what forms of URI reference are acceptable in the href attribute
of the xsl:include and xsl:import elements, for example, the URI schemes that may be used, the forms of
fragment identifier that may be used, and the media types that are supported. (See 3.10.1 Locating Stylesheet Modules)
</i></p>
<p>Saxon allows a user-specified <code>URIResolver</code> to handle these URIs, in which case the forms of URI that are accepted
depend on this <code>URIResolver</code>. By default, Saxon on the Java platform uses the
mechanisms in the <code>java.net.URI</code> class of the underlying
Java VM, while on the .NET platform the capabilities of the System.Uri class are used.
The capabilities of these underlying classes depend on the version and variant of the platform in use,
and may also be customized by users.</p>
<p>Saxon places no restriction on the media type of a stylesheet module. Regardless of the media type, it
accepts a "bare name" fragment identifier as a reference to an element within the retrieved document, identified
by an attribute of type ID.</p>
</li>
<li>
<p><i>An implementation may define mechanisms, above and beyond xsl:import-schema, that allow schema
components such as type definitions to be made available within a stylesheet. (See 3.13 Built-in Types)
</i></p>
<p>In addition to importing types using <code>xsl:import-schema</code>, Saxon implicitly imports a type
corresponding to each class that is present in the Java classpath. These types have names in the namespace
<code>http://saxon.sf.net/java-type</code>; the local name of the type is the same as the full name of the
Java class (for example, <code>java.net.URI</code>, with any "$" signs replaced by hyphens. These types
are intended for use with extension functions written in Java.</p>
</li>
<li>
<p><i>It is implementation-defined which versions of XML and XML Namespaces (1.0 or 1.1) are supported.
(See 4.1 XML Versions)
</i></p>
<p>Saxon gives the user the choice. See
<a class="bodylink" href="../sourcedocs/xml11.xml">Saxon and XML 1.1</a>.</p>
</li>
<li>
<p><i>The implicit timezone for a transformation is implementation-defined.
(See 5.4.3.2 Other components of the XPath Dynamic Context)
</i></p>
<p>Saxon uses the timezone obtained from the system clock, unless the user specifies a different timezone as
a run-time option.</p>
</li>
<li>
<p><i>The numbering sequences supported by the <code>xsl:number</code> instructions, beyond those defined in this
specification, are implementation-defined. (See 12.3 Number to String Conversion Attributes)
</i></p>
<p>Saxon allows localized numbering sequences to be defined by user-written plug-in code: see
<a class="bodylink" href="../extensibility/localizing.xml">implementing localized numbers</a>. In the absence of such a plug-in, the sequences
that are supported are those defined in the specification, plus Greek upper-case (x0391), Greek lower-case
(x03b1), Cyrillic upper case (x0410), Cyrillic lower-case (x0430), Hebrew (x05d0), Hiragana A (x3042),
Katakana A (x30a2), Hiragana I (x3044), Katakana I (x30a4), and Kanji digits (x4e00). If an unrecognized
letter is used as a formatting token, Saxon constructs a sequence starting with that letter and making
use of the contiguous Unicode code-points starting with that letter that are classified as letters or digits.
For example, the format token "x" produces the sequence x, y, z, xx, xy, xz, ...</p>
</li>
<li>
<p><i>There may be implementation-defined upper bounds on the numbers that can be formatted by xsl:number
using any particular numbering sequence. (See 12.3 Number to String Conversion Attributes)
</i></p>
<p>Saxon imposes no limits on numbering sequences using letters or digits (other than those imposed by resource
limitations). Roman numerals are handled in the range 1 to 9999, though values above 4000 are best avoided because
there are no recognized conventions.</p>
</li>
<li>
<p><i>The set of languages for which numbering is supported by xsl:number, and the method of choosing
a default language, are implementation-defined. (See 12.3 Number to String Conversion Attributes)
</i></p>
<p>The default language is English. Localizations for number and date formatting are available for
Belgian French, Danish, Dutch, English, French, Flemish, German, Italian, and Swedish.
Other languages are supported only if user-written (or third-party) localization plug-ins
are provided. </p>
</li>
<li>
<p><i>If the data-type attribute of the xsl:sort element has a value other than "text" or "number",
the effect is implementation-defined. (See 13.1.2 Comparing Sort Key Values)
</i></p>
<p>Any value other than "text" or "number" is treated as an error.</p>
</li>
<li>
<p><i>The facilities for defining collations and allocating URIs to identify them
are implementation-defined. (See 13.1.3 Sorting Using Collations)
</i></p>
<p>Saxon allows a user-written <code>CollationURIResolver</code> to interpret the collation URI, in which case there are no
restrictions on the URI that is used. If the standard <code>CollationURIResolver</code> is used,
two forms of URI are recognized:
a URI declared using the <code>saxon:collation</code> element in the stylesheet, and a URI of the form
<code>http://saxon.sf.net/collation?keyword=value;keyword=value;...</code> as described in
<a class="bodylink" href="../extensibility/collation.xml">Collations</a>. It is also possible to register
collations (with user-defined names) via the Java API.</p>
</li>
<li>
<p><i>The algorithm used by xsl:sort to locate a collation, given the values of the lang and case-order
attributes, is implementation-defined. (See 13.1.3 Sorting Using Collations)
</i></p>
<p>Given the <code>lang</code> attribute, Saxon on the Java platform uses the
Java Locale mechanisms to find a locale for that
language, and hence a collation. On the .NET platform, Saxon similarly finds a collation appropriate to the .NET culture
for that language. Given the <code>case-order</code> attribute, Saxon takes the collation that
would be used in the absence of this attribute, changes its strength to <code>secondary</code> (making it case-blind),
and then re-evaluates the result of any comparison performed by the base collator so that if the base collator
decides two strings are equal, they are examined again to establish the effect of any case differences.</p>
</li>
<li>
<p><i>The set of media types recognized by the processor, for the purpose of interpreting fragment
identifiers in URI references passed to the document function, is implementation-defined.
(See 16.1 Multiple Source Documents)
</i></p>
<p>Saxon ignores the media type entirely. Fragment identifiers are interpreted as bare names (matching ID attribute
values) regardless of the media type.</p>
</li>
<li>
<p><i>The set of languages, calendars, and countries that are supported in the date formatting functions
is implementation-defined. If any of these arguments is omitted or set to an empty sequence,
the default is implementation-defined. (See 16.5.2 The Language, Calendar, and Country Arguments)
</i></p>
<p>Saxon allows the localizations for particular languages to be defined as user-written plug-ins. The localizations
supported for date/time formatting are the same languages that are supported for numbering (see above).
The country argument is ignored except when determining a timezone name: in this case Saxon outputs a time zone name
if the timezone is used in the specified country; if the timezone is attached to a date or dateTime then it also
takes account of whether that date is known to be in daylight savings time (summer time) in the country in question.
</p>
</li>
<li>
<p><i>The choice of the names and abbreviations used in any given language for calendar units such
as days of the week and months of the year is implementation-defined. (See 16.5.2 The Language, Calendar,
and Country Arguments)</i></p>
<p>For English, the days of the week are Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday.
If abbreviations are requested the values used are Mon, Tues, Weds, Thurs, Fri, Sat, Sun, right-truncated
if necessary to the requested maximum length. If the minimum length is 1 and the maximum is 2, then the values used are
M Tu We Th F Sa Su.</p>
<p>For English, the names of the months are January, February, March, April, May, June, July, August, September,
October, November, and December. If abbreviation is requested, the leading part of the name to the required length
is used (always returning at least three characters).</p>
</li>
<li>
<p><i>The values returned by the system-property function, and the names of the additional properties
that are recognized, are implementation-defined. (See 16.6.5 system-property)
</i></p>
<p>The following table shows the values returned for system-defined properties, for both Saxon-B and Saxon-EE: here
"9.4.0.1" is replaced by the current version number. The suffix "J" indicates the Java platform; this is replaced
by "N" on the .NET platform.</p>
<table>
<thead>
<tr>
<td content="para">
<p>Name</p>
</td>
<td content="para">
<p>Saxon-HE</p>
</td>
<td content="para">
<p>Saxon-PE</p>
</td>
<td content="para">
<p>Saxon-EE</p>
</td>
<td content="para">
<p>Notes</p>
</td>
</tr>
</thead>
<tbody>
<tr>
<td content="para">
<p>xsl:version</p>
</td>
<td content="para">
<p>2.0</p>
</td>
<td content="para">
<p>2.0</p>
</td>
<td content="para">
<p>2.0</p>
</td>
</tr>
<tr>
<td content="para">
<p>xsl:vendor</p>
</td>
<td content="para">
<p>Saxonica</p>
</td>
<td content="para">
<p>Saxonica</p>
</td>
<td content="para">
<p>Saxonica</p>
</td>
<td content="para">
<p>Changed in Saxon 9.4</p>
</td>
</tr>
<tr>
<td content="para">
<p>xsl:vendor-url</p>
</td>
<td content="para">
<p>http://www.saxonica.com/</p>
</td>
<td content="para">
<p>http://www.saxonica.com/</p>
</td>
<td content="para">
<p>http://www.saxonica.com/</p>
</td>
<td>
<p/>
</td>
</tr>
<tr>
<td content="para">
<p>xsl:product-name</p>
</td>
<td content="para">
<p>SAXON</p>
</td>
<td content="para">
<p>SAXON</p>
</td>
<td content="para">
<p>SAXON</p>
</td>
<td>
<p/>
</td>
</tr>
<tr>
<td content="para">
<p>xsl:product-version</p>
</td>
<td content="para">
<p>HE 9.4.0.1J</p>
</td>
<td content="para">
<p>PE 9.4.0.1J</p>
</td>
<td content="para">
<p>EE 9.4.0.1J</p>
</td>
<td content="para">
<p>For PE, and EE, if no license file is available then the string "(unlicensed)" is added
after the edition code.</p>
</td>
</tr>
<tr>
<td content="para">
<p>xsl:is-schema-aware</p>
</td>
<td content="para">
<p>no</p>
</td>
<td content="para">
<p>no</p>
</td>
<td content="para">
<p>yes or no</p>
</td>
<td content="para">
<p>depends on whether the particular transformation is schema-aware</p>
</td>
</tr>
<tr>
<td content="para">
<p>xsl:supports-serialization</p>
</td>
<td content="para">
<p>yes</p>
</td>
<td content="para">
<p>yes</p>
</td>
<td content="para">
<p>yes</p>
</td>
<td>
<p/>
</td>
</tr>
<tr>
<td content="para">
<p>xsl:supports-backwards-compatibility</p>
</td>
<td content="para">
<p>yes</p>
</td>
<td content="para">
<p>yes</p>
</td>
<td content="para">
<p>yes</p>
</td>
<td>
<p/>
</td>
</tr>
<tr>
<td content="para">
<p>xsl:supports-namespace-axis</p>
</td>
<td content="para">
<p>yes</p>
</td>
<td content="para">
<p>yes</p>
</td>
<td content="para">
<p>yes</p>
</td>
<td content="para">
<p>See Erratum E14 to the specification</p>
</td>
</tr>
</tbody>
</table>
<p>If the name of the system property is in the null namespace, Saxon returns the value of the Java system property
whose name matches the local name.</p>
</li>
<li>
<p><i>The destination and formatting of messages written using the <code>xsl:message</code> instruction are
implementation-defined. (See 17 Messages)
</i></p>
<p>By default, messages are formatted as XML and written to the standard error output. Both the formatting
and the destination can be customized through the Java API.</p>
</li>
<li>
<p><i>The effect of an extension function returning a string containing characters that are not
legal in XML is implementation-defined. (See 18.1.2 Calling Extension Functions)
</i></p>
<p>Saxon does not validate the values that are returned. Invalid values may cause an error during subsequent
processing, or may be written to the final output destination, resulting in ill-formed XML.</p>
</li>
<li>
<p><i>The way in which external objects are represented in the type system is implementation-defined.
(See 18.1.3 External Objects)
</i></p>
<p>Saxon represents external objects as a subtype of <code>xdt:anyAtomicType</code>. A QName is allocated to such types
based on the Java class name of the external object, within the namespace "http://saxon.sf.net/java-type".
The local name is the same as the expanded Java class name, with "$" replaced by "-".</p>
</li>
<li>
<p><i>The way in which a final result tree is delivered to an application is implementation-defined.
(See 19 Final Result Trees)
</i></p>
<p>In the case of the principal result tree, the destination is specified using the JAXP API (as the second
argument of the transform() method). If secondary result trees are not to be serialized to filestore, a
user-written <code>OutputURIResolver</code> must be nominated. Saxon will pass all generated result trees to this class,
which can then do what it likes with them.</p>
</li>
<li>
<p><i>Implementations may provide additional mechanisms allowing users to define the way in which
final result trees are processed. (See 19.1 Creating Final Result Trees)
</i></p>
<p>See previous item.</p>
</li>
<li>
<p><i>If serialization is supported, then the location to which a final result tree is serialized
is implementation-defined, subject to the constraint that relative URIs used to reference one tree
from another remain valid. (See 20 Serialization)
</i></p>
<p>The <code>href</code> attribute of <code>xsl:result-document</code> is interpreted as a relative URI,
relative to the URI that defines the destination to which the principal result tree is serialized. This
is defined by the <code>-o</code> option on the command line, or by the SystemID of the Result object
supplied using the JAXP API.</p>
</li>
<li>
<p><i>The default value of the encoding attribute of the xsl:output element is implementation-defined.
(See 20 Serialization)
</i></p>
<p>The default encoding is UTF-8.</p>
</li>
<li>
<p><i>It is implementation-defined which versions of XML, HTML, and XHTML are supported in the version
attribute of the xsl:output declaration. (See 20 Serialization)
</i></p>
<p>For HTML and XHTML, Saxon treats the version attribute as documentary only. For XML, versions 1.0 and 1.1
are recognized.</p>
</li>
<li>
<p><i>The default value of the byte-order-mark serialization parameter is implementation-defined
in the case of UTF-8 encoding. (See 20 Serialization)
</i></p>
<p>A byte order mark is written only if explicitly requested (that is, the default is "no").</p>
</li>
<li>
<p><i>It is implementation-defined whether, and under what circumstances, disabling output escaping
is supported. (See 20.2 Disabling Output Escaping)
</i></p>
<p>Disable-output-escaping is supported provided that the final result tree is being written to a StreamResult.
It can also be notified to a SAXResult, as described in the JAXP documentation. Disable-output-escaping
is not supported when writing to a temporary tree.</p>
</li>
</ol>
<table width="100%">
<tr>
<td>
<p align="right"><a class="nav" href="xslt30.xml">Next</a></p>
</td>
</tr>
</table>
</body>
</html>
