Errata for XSL Transformations (XSLT) Version 2.0

23 November 2007

Latest version:

http://www.w3.org/XML/2007/qt-errata/xslt-errata.html

Editor:

Michael Kay, Saxonica http://www.saxonica.com/

Copyright © 2007 W3C^® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

Abstract

This document addresses errors in the XSL Transformations (XSLT) Version 2.0 Recommendation published on 23 January 2007. It records all errors that, at the time of this document's publication, have solutions that have been approved by the XSL Working Group and/or the XML Query Working Group. For updates see the latest version of that document.

The errata are numbered, classified as Substantive, Editorial, or Markup, and are listed in reverse chronological order of their date of origin. Each entry contains the following information:

• A description of the error.

• A reference to the Bugzilla entry recording the original problem report, subsequent discussion, and resolution by the Working Group.

• Key dates in the process of resolving the error.

• Where appropriate, one or more textual changes to be applied to the published Recommendation.

Colored boxes and shading are used to help distinguish new text from old, however these visual clues are not essential to an understanding of the change. The styling of old and new text is an approximation to its appearance in the published Recommendation, but is not normative. Hyperlinks are shown underlined in the erratum text, but the links are not live.

A number of indexes appear at the end of the document.

Substantive corrections are proposed by the XSL Working Group and/or the XQuery Working Group (both part of the XML Activity), which have consensus that they are appropriate; they are not to be considered normative until approved by a Call for Review of Proposed Corrections or a Call for Review of an Edited Recommendation.

Please report errors in this document using W3C's public Bugzilla system (instructions can be found at http://www.w3.org/XML/2005/04/qt-bugzilla). If access to that system is not feasible, you may send your comments to the W3C XSLT/XPath/XQuery public comments mailing list, public-qt-comments@w3.org. It will be very helpful if you include the string [XTerrata] in the subject line of your report, whether made in Bugzilla or in email. Each Bugzilla entry and email message should contain only one error report. Archives of the comments and responses are available at http://lists.w3.org/Archives/Public/public-qt-comments/.

Status of this Document

This is a public draft. None of the errata reported in this document have been approved by a Call for Review of Proposed Corrections or a Call for Review of an Edited Recommendation. As a consequence, they must not be considered to be normative.

Table of Contents

  Errata

     XT.E18   A change that clarified the namespace fixup rules was agreed during the Candidate Recommendation phase but was incorrectly applied.

     XT.E17   Error XTTE0950 is listed in the wrong section of Appendix E

     XT.E16   Error XTDE0485 should not be listed, as it can never happen.

     XT.E15   The explanatory text for the type-available function misrepresents the use cases for this function.

     XT.E14   This erratum defines a new system property ('supports-namespace-axis') which implementations may choose to provide to indicate whether they allow use of the namespace axis.

     XT.E13   A comma has been doubled in 13.1.2.

     XT.E12   Identity constraints are scoped to an element, so they should be applied when validating at element level.

     XT.E11   The scope of a conditional sentence is unclear.

     XT.E10   The specification does not state that duplicate attributes can be validated before they are discarded.

     XT.E9   The rules for defaulting of the namespace attribute in xsl:import-schema are unclear.

     XT.E8   The specification of xsl:for-each-group does not mention the impact of stable="no" when sorting groups.

     XT.E7   A non-normative note concerning namespace fixup is potentially misleading.

     XT.E6   There are no rules preventing misuse of the xmlns namespace.

     XT.E5   The term "static error" is poorly defined.

     XT.E4   The specification for format-date and related functions was intended to give implementations complete freedom to localize messages, but can be read as being over-prescriptive.

     XT.E3   The specification does not constrain the value of the serialization parameter doctype-public to the values that will be accepted in well-formed XML.

     XT.E2   The rules for trimming whitespace from attribute values in the stylesheet are unclear.

     XT.E1   There are errors in the published schema for XSLT 2.0.

  Indexes

    Index by affected section

    Index by Bugzilla entry

    Index by element

    Index by function

    Index by error-code

The prefix of the lexical QName specified in the name attribute (or the absence of a prefix) is copied to the prefix part of the expanded-QName representing the name of the new attribute node. In the event of a conflict this prefix (or absence of a prefix) may subsequently be changed during the namespace fixup process (see 5.7.3 Namespace Fixup). If the attribute is in a non-null namespace and no prefix is specified, then the namespace fixup process will invent a prefix.

The prefix of the lexical QName specified in the name attribute (or the absence of a prefix) is copied to the prefix part of the expanded-QName representing the name of the new attribute node. In the event of a conflict this prefix may subsequently be added, changed, or removed during the namespace fixup process (see 5.7.3 Namespace Fixup). If the attribute is in a non-null namespace and no prefix is specified, then the namespace fixup process will invent a prefix.

err:XTDE0485

It is a non-recoverable dynamic error if namespace fixup is performed on an element that contains among the typed values of the element and its attributes two values of type xs:QName or xs:NOTATION containing conflicting namespace prefixes, that is, two values that use the same prefix to refer to different namespace URIs.

• xsl:version, a number giving the version of XSLT implemented by the processor; for implementations conforming to the version of XSLT specified by this document, this is the string "2.0". The value will always be a string in the lexical space of the decimal data type defined in XML Schema (see [XML Schema Part 2] ). This allows the value to be converted to a number for the purpose of magnitude comparisons.

• xsl:vendor, a string identifying the implementer of the processor

• xsl:vendor-url, a string containing a URL identifying the implementer of the processor; typically this is the host page (home page) of the implementer's Web site.

• xsl:product-name, a string containing the name of the implementation, as defined by the implementer. This should normally remain constant from one release of the product to the next. It should also be constant across platforms in cases where the same source code is used to produce compatible products for multiple execution platforms.

• xsl:product-version, a string identifying the version of the implementation, as defined by the implementer. This should normally vary from one release of the product to the next, and at the discretion of the implementer it may also vary across different execution platforms.

• xsl:is-schema-aware, returns the string "yes" in the case of a processor that claims conformance as a schema-aware XSLT processor, or "no" in the case of a basic XSLT processor.

• xsl:supports-serialization, returns the string "yes" in the case of a processor that offers the serialization feature, or "no" otherwise.

• xsl:supports-backwards-compatibility, returns the string "yes" in the case of a processor that offers the backwards compatibility feature, or "no" otherwise.

In addition, processors may support the following system property in the XSLT namespace. A processor that does not support this property will return a zero-length string if the property is requested.

• xsl:supports-namespace-axis, returns the string "yes" in the case of a processor that offers the XPath namespace axis even when not in backwards compatible mode, or "no" otherwise. Note that a processor that supports backwards compatible mode must support the namespace axis when in that mode, so this property is not relevant to that case.

In general, comparison of two ordinary values is performed according to the rules of the XPath lt operator. To ensure a total ordering, the same implementation of the lt operator must be used for all the comparisons: the one that is chosen is the one appropriate to the most specific type to which all the values can be converted by subtype substitution and/or type promotion. For example, if the sequence contains both xs:decimal and xs:double values, then the values are compared using xs:double comparison, even when comparing two xs:decimal values. NaN values, for sorting purposes, are considered to be equal to each other, and less than any other numeric value. Special rules also apply to the xs:string and xs:anyURI types, and types derived by restriction therefrom,, as described in the next section.

In general, comparison of two ordinary values is performed according to the rules of the XPath lt operator. To ensure a total ordering, the same implementation of the lt operator must be used for all the comparisons: the one that is chosen is the one appropriate to the most specific type to which all the values can be converted by subtype substitution and/or type promotion. For example, if the sequence contains both xs:decimal and xs:double values, then the values are compared using xs:double comparison, even when comparing two xs:decimal values. NaN values, for sorting purposes, are considered to be equal to each other, and less than any other numeric value. Special rules also apply to the xs:string and xs:anyURI types, and types derived by restriction therefrom, as described in the next section.

The validation rule "Validation Rule: Identity-constraint Satisfied" is not applied.

The validation rule "Validation Rule: Identity-constraint Satisfied" should be applied.

If the initial template has an as attribute, then the result sequence of the initial template is checked against the required type in the same way as for any other template. If this result sequence is non-empty, then it is used to construct an implicit final result tree, following the rules described in 5.7.1 Constructing Complex Content: the effect is as if the initial template T were called by an implicit template of the form:

<xsl:template name="IMPLICIT">
  <xsl:result-document href="">
    <xsl:call-template name="T"/>
  </xsl:result-document>
</xsl:template>

The result sequence produced by evaluating the initial template is handled as follows:

1. If the initial template has an as attribute, then the result sequence of the initial template is checked against the required type in the same way as for any other template.

2. If the result sequence is non-empty, then it is used to construct an implicit final result tree, following the rules described in 5.7.1 Constructing Complex Content: the effect is as if the initial template T were called by an implicit template of the form:

   <xsl:template name="IMPLICIT">
     <xsl:result-document href="">
       <xsl:call-template name="T"/>
     </xsl:result-document>
   </xsl:template>

If an attribute A in the result sequence has the same name as another attribute B that appears later in the result sequence, then attribute A is discarded from the result sequence.

If an attribute A in the result sequence has the same name as another attribute B that appears later in the result sequence, then attribute A is discarded from the result sequence. Before discarding attribute A, the processor may signal any type errors that would be signaled if attribute B were not present.

If the xsl:import-schema element contains an xs:schema element, then the schema-location attribute must be absent, and the namespace attribute must either have the same value as the targetNamespace attribute of the xs:schema element (if present), or must be absent, in which case its effective value is that of the targetNamespace attribute of the xs:schema element if present or the zero-length string otherwise.

If the xsl:import-schema element contains an xs:schema element, then the schema-location attribute must be absent, and one of the following must be true:

• the namespace attribute of the xsl:import-schema element and the targetNamespace attribute of the xs:schema element are both absent (indicating a no-namespace schema), or

• the namespace attribute of the xsl:import-schema element and the targetNamespace attribute of the xs:schema element are both present and both have the same value, or

• the namespace attribute of the xsl:import-schema element is absent and the targetNamespace attribute of the xs:schema element is present, in which case the target namespace is as given on the xs:schema element.

Otherwise, the xsl:sort elements immediately within the xsl:for-each-group element define the processing order of the groups (see 13 Sorting). They do not affect the order of items within each group. Multiple sort key components are allowed, and are evaluated in major-to-minor order. If two groups have the same values for all their sort key components, they are processed in order of first appearance.

Otherwise, the xsl:sort elements immediately within the xsl:for-each-group element define the processing order of the groups (see 13 Sorting). They do not affect the order of items within each group. Multiple sort key components are allowed, and are evaluated in major-to-minor order. If two groups have the same values for all their sort key components, they are processed in order of first appearance if the sort key specification is stable, otherwise in an implementation-dependent order.

Namespace prefixes for element and attribute names are effectively established by the namespace fixup process described in 5.7.3 Namespace Fixup. The fixup process ensures that an element has in-scope namespace nodes for the namespace URIs used in the element name and in its attribute names, and the serializer will typically use these namespace nodes to determine the prefix to use in the serialized output. The fixup process cannot generate namespace nodes that are inconsistent with those already present in the tree. This means that it is not possible for the processor to decide the prefix to use for an element or for any of its attributes until all the namespace nodes for the element have been added.

Namespace prefixes for element and attribute names are initially established by the rules of the instruction that creates the element or attribute node, and in the event of conflicts, they may be changed by the namespace fixup process described in 5.7.3 Namespace Fixup. The fixup process ensures that an element has in-scope namespace nodes for the namespace URIs used in the element name and in its attribute names, and the serializer will typically use these namespace nodes to determine the prefix to use in the serialized output. The fixup process cannot generate namespace nodes that are inconsistent with those already present in the tree. This means that it is not possible for the processor to decide the prefix to use for an element or for any of its attributes until all the namespace nodes for the element have been added.

[Definition] An error that is detected by examining a stylesheet before execution starts (that is, before the source document and values of stylesheet parameters are available) is referred to as a static error.

[Definition] An error that can be detected by examining a stylesheet before execution starts (that is, before the source document and values of stylesheet parameters are available) is referred to as a static error.

If the fallback representation uses a different calendar from that requested, the output string must be prefixed with [Calendar: X] where X identifies the calendar actually used. The string Calendar should be localized using the requested language if available. If the fallback representation uses a different language from that requested, the output string should be prefixed with [Language: Y] where Y identifies the language actually used. The string Language may be localized in an implementation-dependent way. If a particular component of the value cannot be output in the requested format, it should be output in the default format for that component.

If the fallback representation uses a different calendar from that requested, the output string must identify the calendar actually used, for example by prefixing the string with [Calendar: X] (where X is the calendar actually used), localized as appropriate to the requested language. If the fallback representation uses a different language from that requested, the output string must identify the language actually used, for example by prefixing the string with [Language: Y] (where Y is the language actually used) localized in an implementation-dependent way. If a particular component of the value cannot be output in the requested format, it should be output in the default format for that component.

• The value of the doctype-public attribute provides the value of the doctype-public parameter to the serialization method. By default, the parameter is not supplied.

The value of doctype-public must conform to the rules for a PubidLiteral^XML (see [XML 1.0] ).

In all cases where this specification states that the value of an attribute must be one of a limited set of values, leading and trailing whitespace in the attribute value is ignored. In the case of an attribute value template, this applies to the effective value obtained when the attribute value template is expanded.

Except where the set of allowed values of an attribute is specified using the italicized name string or char, leading and trailing whitespace in the attribute value is ignored. In the case of an attribute value template, this applies to the effective value obtained when the attribute value template is expanded.