Copyright © 2007-2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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. For updates see the latest version of that document.
The errata are numbered, and are listed in reverse chronological order of their date of origin. Each erratum is classified as Substantive, Editorial, or Markup. These categories are defined as follows:
Substantive: a change to the specification that may require implementations to change and that may change the outcome of a stylesheet or query.
Editorial: a clarification, correction of a textual error, or removal of an inconsistency, where the Working Group does not believe that the intent of the specification has changed. The erratum may affect implementations or user-written queries and stylesheets if the previous lack of clarity in the specification resulted in a misreading.
Markup: correction of formatting; the effect is cosmetic only.
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 (part of the XML Activity), where there is 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/.
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.
The Working Group does not intend to progress these errata to normative status; instead, it intends to publish a second edition of the Recommendation incorporating these errata, and to progress the second edition to normative status.
Errata
XT.E36 Nothing is said about the default collation in the absence of the [xsl:]default-collation attribute
XT.E35 Error in example of xsl:processing-instruction
XT.E34 The description of xsl:number contains unspecific references to the Unicode specification
XT.E33 The rules determining when a key is evaluated in backwards-compatible mode are unclear
XT.E32 Editorial inconsistencies in the description of disable-output-escaping
XT.E31 There is no way for an overriding xsl:output or xsl:result-document instruction to indicate that the serialization parameters doctype-system or doctype-public should take the value "absent", overriding a previously specified explicit value.
XT.E30 The rule for numbering with level="any" gives a counter-intuitive result in the case where the selected node (or another counted node) matches the "from" pattern.
XT.E29 Examples of format-time use GMT+1 and GMT+01:00 interchangeably, and it is not clear which should be used when.
XT.E28 Error in example of inline schema.
XT.E27 Add warning that with character maps (as well as disable-output-escaping) there is no guarantee that the serialized output will be well formed or valid.
XT.E26 The description of the case-order attribute in xsl:sort needs to be clarified.
XT.E25 The specification of xsl:for-each-group needs to take into account the non-transitivity of the eq operator.
XT.E24 Examples of format-time use GMT+1 and GMT+01:00 interchangeably, and it is not clear which should be used when.
XT.E23 Error in example of format-date call using the Islamic calendar.
XT.E22 Error in example of format-time call.
XT.E21 There are two full stops after the description of error XTSE0530.
XT.E20 It is unclear what should happen when errors occur during xsl:message processing (in particular, serialization errors).
XT.E19 Current mode is underspecified: it is unclear what its value should be in all circumstances.
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
See Bug 6231
Nothing is said about the default collation in the absence of the [xsl:]default-collation attribute
13 Mar 2009: Proposed
19 Mar 2009: Accepted
Insert at the end of section 3.6.1 The default-collation attribute
The following:
In the absence of an [xsl:]default-collation attribute, the default collation
may be established by the calling application in an
implementation-defined way. The
recommended default, unless the user chooses otherwise, is to
use the Unicode codepoint collation.
See Bug 6282
Error in example of xsl:processing-instruction
12 Feb 2009: Proposed
19 Mar 2009: Accepted
In 11.6 Creating Processing Instructions (first example box, first code section):
Replace the text:
<xsl:processing-instruction name="xml-stylesheet"
select="('href="book.css"', 'type="text/css")"/>With:
<xsl:processing-instruction name="xml-stylesheet"
select="('href="book.css"', 'type="text/css"')"/>See Bug 6186
The description of xsl:number contains unspecific references to the Unicode specification
30 Jan 2009: Proposed
19 Mar 2009: Accepted
In 12.3 Number to String Conversion Attributes (second paragraph):
Replace the text:
The main attribute is format. The default value for
the format attribute is 1. The
format attribute is split into a sequence of tokens where
each token is a maximal sequence of alphanumeric characters or a
maximal sequence of non-alphanumeric characters. Alphanumeric means
any character that has a Unicode category of Nd, Nl, No, Lu, Ll, Lt,
Lm or Lo. The alphanumeric tokens (format tokens) indicate the format
to be used for each number in the sequence; in most cases the format token
is the same as the required representation of the number 1 (one).
With:
The main attribute is format. The default value for
the format attribute is 1. The
format attribute is split into a sequence of tokens where
each token is a maximal sequence of alphanumeric characters or a
maximal sequence of non-alphanumeric characters. Alphanumeric means
any character that has a Unicode category of Nd, Nl, No, Lu, Ll, Lt,
Lm or Lo (see
[Unicode]
).
The alphanumeric tokens (format tokens) indicate the format
to be used for each number in the sequence; in most cases the format token
is the same as the required representation of the number 1 (one).
In 12.3 Number to String Conversion Attributes (first bulleted list, first item):
Replace the text:
Any token where the last character has a decimal digit value
of 1 (as specified in the Unicode character property database),
and the Unicode value of preceding characters is one less than the
Unicode value of the last character generates a decimal
representation of the number where each number is at least as long as
the format token. The digits used in the decimal
representation are the set of digits containing the digit character used
in the format token. Thus, a format token 1 generates the
sequence 0 1 2 ... 10 11 12 ..., and a format token
01 generates the sequence 00 01 02 ... 09 10 11 12
... 99 100 101. A format token of ١
(Arabic-Indic digit one) generates the sequence ١ then ٢ then ٣ ...
With:
Any token where the last character has a decimal digit value
of 1 (as specified in the Unicode character property database, see
[Unicode]
),
and the Unicode value of preceding characters is one less than the
Unicode value of the last character generates a decimal
representation of the number where each number is at least as long as
the format token. The digits used in the decimal
representation are the set of digits containing the digit character used
in the format token. Thus, a format token 1 generates the
sequence 0 1 2 ... 10 11 12 ..., and a format token
01 generates the sequence 00 01 02 ... 09 10 11 12
... 99 100 101. A format token of ١
(Arabic-Indic digit one) generates the sequence ١ then ٢ then ٣ ...
In A.1 Normative References, in its correct alphabetical position, add a reference to The Unicode Standard, using the same form of words as appears in the XPath 2.0 specification. Note that this reference advises implementors to use the latest version of the Unicode specification.
See Bug 6164
The rules determining when a key is evaluated in backwards-compatible mode are unclear
30 Jan 2009: Proposed
19 Mar 2009: Accepted
In 16.3.2 The key Function (sixth paragraph):
Replace the text:
Different rules apply when backwards compatible
behavior is enabled. Specifically, if any of the xsl:key elements in the definition of the
key enables backwards compatible behavior, then the value of the
key specifier and the value of the second argument of the
key function are both converted after atomization to a sequence of strings, by
applying a cast to each item in the sequence, before performing the comparison.
With:
Different rules apply when backwards compatible
behavior is enabled. A key (that is, a set of xsl:key declarations
sharing the same key name) is processed in backwards compatible mode if any of the xsl:key elements
in the definition of the key enables backwards compatible behavior. When a
key is processed in backwards compatible mode, then:
The result of evaluating the key specifier
in any xsl:key declaration having this key name is converted after atomization to a sequence of strings,
by applying a cast to each item in the sequence.
When the first argument to the key function specifies this key name, then the value
of the second argument is converted after
atomization to a sequence of strings, by applying a cast to each item in the sequence.
The values are then compared as strings.
See Bug 6140
Editorial inconsistencies in the description of disable-output-escaping
30 Jan 2009: Proposed
19 Mar 2009: Accepted
In 20.2 Disabling Output Escaping (fifth paragraph):
Replace the text:
An xsl:value-of
or xsl:text element may have a
disable-output-escaping attribute; the allowed values are
yes or no. The default is no;
if the value is yes, then every character in the text node generated by
evaluating the xsl:value-of or xsl:text
element should have the disable-output property set.
With:
An xsl:value-of
or xsl:text element may have a
disable-output-escaping attribute; the allowed values are
yes or no. The default is no;
if the value is yes, then every character in the text node generated by
evaluating the xsl:value-of or xsl:text
element should have the disable-escaping property set.
In J.1.4 Incompatibility in the Absence of a Schema (first numbered list, twentieth item):
Replace the text:
20 | An erratum to XSLT 1.0 specified what has become known as "sticky
disable-output-escaping": specifically, that it should be possible to use |
With:
20 | An erratum to XSLT 1.0 specified what has become known as "sticky
disable-output-escaping": specifically, that it should be possible to use |
See Bug 5893
There is no way for an overriding xsl:output or xsl:result-document instruction to indicate that the serialization parameters doctype-system or doctype-public should take the value "absent", overriding a previously specified explicit value.
30 Jan 2009: Proposed
19 Mar 2009: Accepted
In 19.1 Creating Final Result Trees (second note):
Insert after the text:
Note:
In the case of the attributes method, cdata-section-elements,
and use-character-maps,
the effective value of the attribute contains
one or more lexical QNames. The prefix in such a QName is expanded using the
in-scope namespaces for the xsl:result-document element. In the case of
cdata-section-elements, an unprefixed element name is expanded using the default
namespace.
The following:
In the case of the attributes doctype-system and doctype-public, setting the effective value of the
attribute to a zero-length string has the effect of overriding any value for these attributes obtained from the output definition.
The corresponding serialization parameter is not set (is "absent").
In 20 Serialization (second bulleted list, fourth item):
Replace the text:
The value of the doctype-system attribute provides the
value of the doctype-system parameter to the serialization method.
By default, the parameter is not supplied.
With:
The value of the doctype-system attribute provides the
value of the doctype-system parameter to the serialization method.
If the attribute is absent or has a zero-length string as its value, then the serialization
parameter is not set (is "absent").
In 20 Serialization (second bulleted list, fifth item):
Replace the text:
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.
With:
The value of the doctype-public attribute provides the
value of the doctype-public parameter to the serialization method.
If the attribute is absent or has a zero-length string as its value, then the serialization
parameter is not set (is "absent").
The value of doctype-public must conform to the rules
for a PubidLiteralXML
(see
[XML 1.0]
).
See Bug 5849
The rule for numbering with level="any" gives a counter-intuitive result in the case where the selected node (or another counted node) matches the "from" pattern.
30 Jan 2009: Proposed
19 Mar 2009: Accepted
In 12.2 Numbering based on Position in a Document (fourth bulleted list, second item, second paragraph):
Replace the text:
$S/(preceding::node()|ancestor::node())[matches-from(.)][last()]
With:
$S/(preceding::node()|ancestor-or-self::node())[matches-from(.)][last()]
See Bug 5308
See Bug 5309
Examples of format-time use GMT+1 and GMT+01:00 interchangeably,
and it is not clear which should be used when. It is also unclear whether "Z" or "+00:00" should be
used for the UTC timezone. (Supersedes erratum E24)
30 Jan 2009: Proposed
19 Mar 2009: Accepted
In 16.5.1 The Picture String (first table, first table body, fifteenth row, second column):
Replace the text:
| timezone as a time offset using GMT, for example GMT+1 |
With:
timezone as a time offset using GMT, for example GMT+1 or GMT-05:00. For this component there is a fixed
prefix of GMT, or a localized
variation thereof for the chosen language, and the presentation modifier controls the representation of the
signed time offset that follows. |
In 16.5.1 The Picture String (fifteenth paragraph):
Replace the text:
If the minumum and maximum width are unspecified, then the output uses as many characters as are required to represent the value of the component without truncation and without padding: this is referred to below as the full representation of the value.
With:
If the minimum and maximum width are unspecified, then the output uses as
many characters as are required to
represent the value of the component without truncation and without padding: this is referred to below
as the full representation of the value.
For a timezone offset (component
specifier z), the full representation consists of a sign for the offset, the
number of hours of the offset, and if the offset is not an integral number of hours,
a colon (:) followed by the two digits of the minutes of the offset.
In 16.5.1 The Picture String (seventeenth paragraph):
Replace the text:
If the full representation of the value is shorter than the specified minimum width, then the processor should pad the value to the specified width. For decimal representations of numbers, this should be done by prepending zero digits from the appropriate set of digit characters, or appending zero digits in the case of the fractional seconds component. In other cases, it should be done by appending spaces.
With:
If the full representation of the value is shorter than the specified minimum width, then the processor should pad the value to the specified width.
For decimal representations of numbers, this should be done by prepending zero digits from the appropriate set of digit characters, or appending zero digits in the case of the fractional seconds component.
For timezone offsets this should be done by first appending
a colon (:) followed by two
zero digits from the appropriate set of digit characters if the full
representation does not already include a minutes component and if
the specified minimum width permits adding three characters,
and then if necessary prepending zero digits from the
appropriate set of digit characters to the hour component.
In other cases, it should be done by appending spaces.
Note:
Formatting of timezones is not fully defined by this specification. Some aspects of the formatting are implementation-dependent.
For component specifier "z", the choice between "GMT+2" and "GMT+02:00" is guided by the width specifier, as indicated above. The string "GMT" may be localized, for example to "UTC". The representation of the UTC timezone itself (that is, a timezone offset of zero) is not defined in this specification.
For component specifier "Z" with a numeric presentation modifier, the implementation may optionally use "Z" rather than "+00:00" to indicate UTC.
Component specifier "Z" with the presentation modifier "N" is used to request timezone names such as
"PST" or "CET". Translation of a timezone offset into the name of a civil timezone can only be done heuristically.
The implementation may use the $country argument as a guide to the civil timezones to match
against; if $value includes a date then the implementation may also use a database of
daylight-savings-time changes to distinguish two timezone names, such as "EDT" and "AST", that have the same
timezone offset.
In 16.5.3 Examples of Date and Time Formatting (first example box, first table, first table body, nineteenth row, second column):
Replace the text:
format-time($t,"[H01]:[m01]:[s01] [z]", "en", (), ()) |
With:
format-time($t,"[H01]:[m01]:[s01] [z,6-6]", "en", (), ()) |
In 16.5.3 Examples of Date and Time Formatting (first example box, first table, first table body, twentieth row, first column):
Replace the text:
15.58 Uhr GMT+02:00 |
With:
15.58 Uhr GMT+2 |
See Bug 6093
Error in example of inline schema. The select expression of the variable needs to explicitly convert the supplied value to the type defined in the schema; declaring the type is not enough.
28 Sep 2008: Proposed
9 Oct 2008: Accepted
In 3.14 Importing Schema Components (first example box, first code section):
Replace the text:
<xsl:import-schema>
<xs:schema targetNamespace="http://localhost/ns/yes-no"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:simpleType name="local:yes-no">
<xs:restriction base="xs:string">
<xs:enumeration value="yes"/>
<xs:enumeration value="no"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
</xsl:import-schema>
<xs:variable name="condition" select="'yes'" as="local:yes-no"/>
With:
<xsl:import-schema>
<xs:schema targetNamespace="http://localhost/ns/yes-no"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:simpleType name="local:yes-no">
<xs:restriction base="xs:string">
<xs:enumeration value="yes"/>
<xs:enumeration value="no"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
</xsl:import-schema>
<xs:variable name="condition" select="local:yes-no('yes')" as="local:yes-no"/>
See Bug 5667
Add warning that with character maps (as well as disable-output-escaping) there is no guarantee that the serialized output will be well formed or valid.
10 Jul 2008: Proposed
9 Oct 2008: Accepted
Insert at the end of section 20.1 Character Maps
The following:
Note:
When character maps are used, there is no guarantee that the serialized output will be well-formed XML (or HTML). Furthermore, the fact that the result tree was validated against a schema gives no guarantee that the serialized output will still be valid against the same schema. Conversely, it is possible to use character maps to produce schema-valid output from a result tree that would fail validation.
Insert at the end of section 20.2 Disabling Output Escaping
The following:
Note:
When disable-output-escaping is used, there is no guarantee that the serialized output will be well-formed XML (or HTML). Furthermore, the fact that the result tree was validated against a schema gives no guarantee that the serialized output will still be valid against the same schema. Conversely, it is possible to use disable-output-escaping to produce schema-valid output from a result tree that would fail validation.
See Bug 5324
The description of the case-order attribute in xsl:sort needs to
be clarified.
17 Jul 2008: Proposed
9 Oct 2008: Accepted
In 13.1.3 Sorting Using Collations (first bulleted list, second item):
Insert after the text:
The case-order attribute indicates whether
the desired collation should sort upper-case letters before
lower-case or vice versa. The
effective value of
the attribute must be either lower-first (indicating
that lower-case letters precede upper-case letters in the collating
sequence) or upper-first (indicating that upper-case
letters precede lower-case).
The following:
When lower-first is requested, the
returned collation should have the property that when two strings differ only
in the case of one or more characters, then a string in which the first
differing character is lower-case should precede a string in which the
corresponding character is title-case, which should in turn precede a string in
which the corresponding character is upper-case. When upper-first is requested,
the
returned collation should have the property that when two strings differ only
in the case of one or more characters, then a string in which the first
differing character is upper-case should precede a string in which the
corresponding character is title-case, which should in turn precede a string in
which the corresponding character is lower-case.
So, for example, if lang="en", then A a B b are sorted with
case-order="upper-first" and a A b B are sorted with case-order="lower-first".
As a further example, if lower-first is requested, then a sorted sequence might be "MacAndrew, macintosh, macIntosh, Macintosh, MacIntosh, macintoshes, Macintoshes, McIntosh". If upper-first is requested, the same sequence would sort as "MacAndrew, MacIntosh, Macintosh, macIntosh, macintosh, MacIntoshes, macintoshes, McIntosh"
See Bug 5295
The specification of xsl:for-each-group needs to take into account
the non-transitivity of the eq operator.
11 Jul 2008: Proposed
9 Oct 2008: Accepted
In 14.3 The xsl:for-each-group Element (first bulleted list, first item, third paragraph):
Insert after the text:
The number of groups will be the same as the number of distinct grouping key values present in the population.
The following:
If the population contains values of different numeric types that differ
from each other by small amounts, then the eq operator is not transitive,
because of rounding effects occurring during type promotion. The effect of this is described
in 14.5 Non-Transitivity.
Insert at the end of section 14 Grouping
The following:
If the population contains values of different numeric types that differ
from each other by small amounts, then the eq operator is not transitive,
because of rounding effects occurring during type promotion. It is thus
possible to have three values A, B, and C among the grouping keys of the
population such that A eq B, B eq C, but A ne C.
For example, this arises when computing
<xsl:for-each-group group-by="." select="
xs:float('1.0'),
xs:decimal('1.0000000000100000000001',
xs:double( '1.00000000001')">because the values of type xs:float and xs:double both compare equal to the
value of type xs:decimal but not equal to each other.
In this situation the results must be equivalent to the results obtained by the following algorithm:
For each item I in the population in population order, for each of the grouping keys K for that item in sequence, the processor identifies those existing groups G such that the grouping key of the initial item of G is equal to K.
If there is exactly one group G, then I is added to this group, unless I is already a member of this group.
If there is no group G, then a new group is created with I as its first item.
If there is more than one group G (which can only happen in exceptional circumstances involving non-transitivity), then one of these groups is selected in an implementation-dependent way, and I is added to this group, unless I is already a member of this group.
The effect of these rules is that (a) every item in a non-singleton group has a grouping key that is equal to that of at least one other item in that group, (b) for any two distinct groups, there is at least one pair of items (one from each group) whose grouping keys are not equal to each other.
Superseded by Erratum XT.E29
See Bug 5309
Examples of format-time use GMT+1 and GMT+01:00 interchangeably,
and it is not clear which should be used when.
11 Jul 2008: Proposed
9 Oct 2008: Accepted
In 16.5.1 The Picture String (first table, first table body, fifteenth row, second column):
Replace the text:
| timezone as a time offset using GMT, for example GMT+1 |
With:
timezone as a time offset using GMT, for example GMT+1 or GMT-05:00. For this component there is a fixed
prefix of GMT, or a localized
variation thereof for the chosen language, and the presentation modifier controls the representation of the
signed time offset that follows. |
In 16.5.1 The Picture String (fifteenth paragraph):
Replace the text:
If the minumum and maximum width are unspecified, then the output uses as many characters as are required to represent the value of the component without truncation and without padding: this is referred to below as the full representation of the value.
With:
If the minimum and maximum width are unspecified, then the output uses as
many characters as are required to
represent the value of the component without truncation and without padding: this is referred to below
as the full representation of the value.
For a timezone offset (component
specifier z), the full representation consists of a sign for the offset, the
number of hours of the offset, and if the offset is not an integral number of hours,
a colon (:) followed by the two digits of the minutes of the offset.
In 16.5.1 The Picture String (seventeenth paragraph):
Replace the text:
If the full representation of the value is shorter than the specified minimum width, then the processor should pad the value to the specified width. For decimal representations of numbers, this should be done by prepending zero digits from the appropriate set of digit characters, or appending zero digits in the case of the fractional seconds component. In other cases, it should be done by appending spaces.
With:
If the full representation of the value is shorter than the specified minimum width, then the processor should pad the value to the specified width.
For decimal representations of numbers, this should be done by prepending zero digits from the appropriate set of digit characters, or appending zero digits in the case of the fractional seconds component.
For timezone offsets this should be done by first appending
a colon (:) followed by two
zero digits from the appropriate set of digit characters if the full
representation does not already include a minutes component and if
the specified minimum width permits adding three characters,
and then if necessary prepending zero digits from the
appropriate set of digit characters to the hour component.
In other cases, it should be done by appending spaces.
In 16.5.3 Examples of Date and Time Formatting (first example box, first table, first table body, nineteenth row, second column):
Replace the text:
format-time($t,"[H01]:[m01]:[s01] [z]", "en", (), ()) |
With:
format-time($t,"[H01]:[m01]:[s01] [z,6-6]", "en", (), ()) |
In 16.5.3 Examples of Date and Time Formatting (first example box, first table, first table body, twentieth row, first column):
Replace the text:
15.58 Uhr GMT+02:00 |
With:
15.58 Uhr GMT+2 |
See Bug 5853
Error in example of format-date call using the Islamic calendar.
10 Jul 2008: Proposed
9 Oct 2008: Accepted
In 16.5.3 Examples of Date and Time Formatting (second example box, first table, first table body, first row, second column):
Replace the text:
format-date($d, "[D١] [Mn] [Y١]", "Islamic", "ar", "AH", ()) |
With:
format-date($d, "[D١] [Mn] [Y١]", "ar", "AH", ()) |
See Bug 5571
Error in example of format-time call.
20 Mar 2008: Proposed
10 Jul 2008: Accepted
In 16.5.3 Examples of Date and Time Formatting (first example box, first table, first table body, sixteenth row, second column):
Replace the text:
format-time($t, "[h]:[m01]:[s01] o'clock [PN] [ZN,*-3]",
"en") |
With:
format-time($t, "[h]:[m01]:[s01] o'clock [PN] [ZN,*-3]", "en", (), ()) |
See Bug 5482
There are two full stops after the description of error XTSE0530.
20 Mar 2008: Proposed
9 Oct 2008: Accepted
In 6.4 Conflict Resolution for Template Rules (first numbered list, second item, second paragraph):
Replace the text:
err:XTSE0530
The value of this attribute
[the priority attribute of the xsl:template element]for Appendix E
must conform to the rules for the xs:decimal
type defined in
[XML Schema Part 2]
. Negative values are permitted..
With:
err:XTSE0530
The value of this attribute
[the priority attribute of the xsl:template element]for Appendix E
must conform to the rules for the xs:decimal
type defined in
[XML Schema Part 2]
. Negative values are permitted.
See Bug 5278
It is unclear what should happen when errors occur during xsl:message processing (in particular, serialization errors).
20 Mar 2008: Proposed
9 Oct 2008: Accepted
Insert at the end of section 17 Messages
The following:
Any dynamic error that occurs
while evaluating the select expression or the
contained sequence constructor,
and any serialization error
that occurs while
processing the result, is treated as a
recoverable error even if the error
would not be recoverable under other circumstances. The
optional recovery
action is implementation-dependent.
Note:
An example of such an error is the serialization error that occurs when
processing the instruction <xsl:message select="@code"/> (on the grounds that
free-standing attributes cannot be serialized). Making such errors recoverable
means that it is implementation-defined whether or not they are signaled to the
user and whether they cause termination of the transformation. If the processor
chooses to recover from the error, the content of any resulting message is
implementation-dependent.
One possible recovery action is to include a description of the error in the generated message text.
See Bug 4843
Current mode is underspecified: it is unclear what its value should be in all circumstances.
20 Mar 2008: Proposed
9 Oct 2008: Accepted
In 5.4.4 Additional Dynamic Context Components used by XSLT (first table, first table body, third row, fourth column):
Replace the text:
| calls on stylesheet functions |
With:
calls on stylesheet functions,
evaluation of global variables and stylesheet parameters, evaluation of the sequence constructor
contained in xsl:key or xsl:sort. Clearing the current mode
causes the current mode to be set to the default (unnamed) mode. |
In 6.5 Modes (eighth paragraph):
Replace the text:
[Definition] At any point in the processing
of a stylesheet, there is a current mode. When the transformation is initiated,
the current mode is the default mode, unless a different initial
mode has been supplied, as described in 2.3 Initiating a Transformation.
Whenever an xsl:apply-templates
instruction is evaluated, the current mode becomes the mode selected by this instruction.
When a stylesheet function is called, the current mode becomes the default mode.
No other instruction changes the current mode. On completion of the xsl:apply-templates
instruction, or on return from a stylesheet function call,
the current mode reverts to its previous value. The current mode is used when an
xsl:apply-templates instruction uses the syntax mode="#current";
it is also used by the xsl:apply-imports
and xsl:next-match
instructions (see 6.7 Overriding Template Rules).
With:
[Definition] At any point in the processing
of a stylesheet, there is a current mode. When the transformation is initiated,
the current mode is the default mode, unless a different initial
mode has been supplied, as described in 2.3 Initiating a Transformation.
Whenever an xsl:apply-templates
instruction is evaluated, the current mode becomes the mode selected by this instruction.
When a stylesheet function is called, the current mode is set to the default mode.
While
evaluating global variables and parameters, and the sequence constructor
contained in xsl:key or xsl:sort, the current mode is set to the default mode.
No other instruction changes the current mode.
The
current mode while evaluating an attribute set
is the same as the current mode of the caller.
On completion of the xsl:apply-templates
instruction, or on return from a stylesheet function call,
the current mode reverts to its previous value. The current mode is used when an
xsl:apply-templates instruction uses the syntax mode="#current";
it is also used by the xsl:apply-imports
and xsl:next-match
instructions (see 6.7 Overriding Template Rules).
See Bug 3336
A change that clarified the namespace fixup rules was agreed during the Candidate Recommendation phase but was incorrectly applied. (Note: this erratum incorporates change 5 of Erratum E6.)
7 Nov 2007: Proposed
15 Nov 2007: Accepted
In 11.3 Creating Attribute Nodes Using xsl:attribute (twelfth paragraph):
Replace the text:
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.
With:
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.
The term conflict here
means any violation of the constraints defined in
[Data Model]
, for example the
use of the same prefix to refer to two different namespaces in the element and
in one of its attributes, the use of the prefix xml to refer to a namespace
other than the XML namespace, or any use of the prefix xmlns.
See Bug 4878
Error XTTE0950 is listed in the wrong section of Appendix E
10 Oct 2007: Proposed
15 Nov 2007: Accepted
In Appendix E, move error XTTE0950 from the Static Errors section to the Type Errors section.
See Bug 3069
Error XTDE0485 should not be listed, as it can never happen. (The change log in the Proposed Recommendation reported that this error had been removed, but the decision to delete it was not implemented.)
10 Oct 2007: Proposed
15 Nov 2007: Accepted
In 5.7.3 Namespace Fixup (sixth paragraph):
Delete the text:
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.
See Bug 4696
The explanatory text for the type-available function
misrepresents the use cases for this function. The effect of the erratum is to document
its limitations when used in a use-when expression.
10 Oct 2007: Proposed
15 Nov 2007: Accepted
In 18.1.4 Testing Availability of Types (first paragraph):
Replace the text:
The type-available function
can be used, for example with the
[xsl:]use-when attribute (see 3.12 Conditional Element Inclusion), to
explicitly control how a stylesheet behaves if a particular
schema type is not available in the static context.
With:
The type-available function
can be used to control how a stylesheet behaves if a particular
schema type is not available in the static context.
In 18.1.4 Testing Availability of Types (fifth paragraph):
Insert after the text:
err:XTDE1428
It is a
non-recoverable dynamic error
if the argument
[passed to the type-available function]for Appendix E
does not evaluate to a string that is a valid QName,
or if there is no namespace declaration in scope for the prefix of the QName.
If the processor is able to detect the error statically (for example, when the argument is
supplied as a string literal), then the processor may optionally signal this
as a static error.
The following:
Note:
The type-available function
is of limited use within an [xsl:]use-when expression, because the
static context for the expression does not include any user-defined types.
See Bug 4546
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.
10 Oct 2007: Proposed
7 Nov 2007: Amended
15 Nov 2007: Accepted
In 16.6.5 system-property (first bulleted list):
Insert after the text:
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.
The following:
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.
See Bug 4849
A comma has been doubled in 13.1.2.
10 Oct 2007: Proposed
15 Nov 2007: Accepted
In 13.1.2 Comparing Sort Key Values (sixth paragraph):
Replace the text:
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.
With:
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.
See Bug 4548
Identity constraints are scoped to an element, so they should be applied when validating at element level. This change is worded as a "should" so that existing processors remain conformant.
8 May 2007: Proposed
21 Jun 2007: Amended
15 Nov 2007: Accepted
In 19.2.1.3 The Validation Process (first bulleted list, second item):
Replace the text:
The validation rule "Validation Rule: Identity-constraint Satisfied" is not applied.
With:
The validation rule "Validation Rule: Identity-constraint Satisfied" should be applied.
See Bug 4620
The scope of a conditional sentence is unclear. It is possible to misread
the paragraph in section 2.4 that starts "If the initial template has
an as attribute..." as if this condition applies to the whole paragraph,
whereas it actually applies only to the first sentence of the paragraph.
10 Jun 2007: Proposed
21 Jun 2007: Accepted
In 2.4 Executing a Transformation (starting at third paragraph):
Replace the text:
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>With:
The result sequence produced by evaluating the initial template is handled as follows:
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 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>See Bug 4600
The specification does not state that duplicate attributes can be validated before they are discarded. This erratum clarifies that an error may be reported when a constructed attribute has an invalid value, even if the attribute is subsequently discarded as a duplicate.
6 Jun 2007: Proposed
21 Jun 2007: Accepted
In 5.7.1 Constructing Complex Content (first numbered list, ninth item):
Replace the text:
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.
With:
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.
See Bug 4591
The rules for defaulting of the namespace attribute in xsl:import-schema
are unclear.
30 May 2007: Proposed
21 Jun 2007: Accepted
7 Nov 2007: Amended
15 Nov 2007: Accepted
In 3.14 Importing Schema Components (fifth paragraph):
Replace the text:
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.
With:
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.
See Bug 4589
The specification of xsl:for-each-group does not mention the impact of
stable="no" when sorting groups. This erratum confirms that stable="no"
has the expected effect in this situation.
29 May 2007: Proposed
21 Jun 2007: Accepted
In 14.3 The xsl:for-each-group Element (twenty-first paragraph):
Replace the text:
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.
With:
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.
See Bug 4513
A non-normative note concerning namespace fixup is potentially misleading. This erratum confirms
that the rules for choice of a prefix in xsl:element and xsl:attribute
take precedence.
29 Apr 2007: Proposed
17 May 2007: Accepted
In 11.7 Creating Namespace Nodes (first note, third paragraph):
Replace the text:
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.
With:
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.
See Bug 4464
There are no rules preventing misuse of the xmlns namespace.
23 Apr 2007: Proposed
17 May 2007: Accepted
In 3.2 Reserved Namespaces (first bulleted list, fifth item):
Insert after the text:
The following:
The
namespace http://www.w3.org/2000/xmlns/ is reserved for use as described in
[Namespaces in XML 1.0]
. No element or attribute node can have a name in this
namespace, and although the prefix xmlns is implicitly bound to this
namespace, no namespace node will ever define this binding.
In 11.2 Creating Element Nodes Using xsl:element (tenth paragraph):
Replace the text:
It is a non-recoverable dynamic error if
the effective value
of the namespace attribute
[of the xsl:element instruction]for Appendix E
is not in the lexical space of the xs:anyURI data type.
With:
It is a non-recoverable dynamic error if
the effective value
of the namespace attribute
[of the xsl:element instruction]for Appendix E
is not in the lexical space of the xs:anyURI data type
or if it is the string http://www.w3.org/2000/xmlns/.
In 11.2 Creating Element Nodes Using xsl:element (eleventh paragraph):
Insert after the text:
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 element node.
In the event of a conflict a prefix
may subsequently be added, changed, or removed
during the namespace fixup process (see 5.7.3 Namespace Fixup).
The following:
xml to refer to a namespace
other than the XML namespace, or any use of the prefix xmlns.In 11.3 Creating Attribute Nodes Using xsl:attribute (eleventh paragraph):
Replace the text:
It is a non-recoverable dynamic error if
the effective value
of the namespace attribute
[of the xsl:attribute instruction]for Appendix E
is not in the lexical space of the xs:anyURI data type.
With:
It is a non-recoverable dynamic error if
the effective value
of the namespace attribute
[of the xsl:attribute instruction]for Appendix E
is not in the lexical space of the xs:anyURI data type
or if it is the string http://www.w3.org/2000/xmlns/.
In 11.3 Creating Attribute Nodes Using xsl:attribute (twelfth paragraph):
Insert after the text:
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 following:
xml to refer to a namespace
other than the XML namespace, or any use of the prefix xmlns.In 11.7 Creating Namespace Nodes (fourth paragraph):
Replace the text:
It is a
non-recoverable dynamic error if
the string value of the new namespace node
[created using xsl:namespace]for Appendix E
is not valid in the lexical space of the data type xs:anyURI.
[err:XTDE0835]
With:
It is a non-recoverable dynamic error if the
string value of the new namespace node is not valid in the lexical space of the
data type xs:anyURI,
or if it is the string http://www.w3.org/2000/xmlns/.
In 5.7.3 Namespace Fixup (first bulleted list, fourth item):
Replace the text:
A namespace node must not have the name xmlns.
With:
A namespace node must not have the name xmlns
or the string value http://www.w3.org/2000/xmlns/.
See Bug 2388
The term "static error" is poorly defined. The concept is defined in terms of when it is detected, which is circular, given that the specification goes on to state requirements on processors to detect static errors before evaluation starts.
17 Apr 2007: Proposed
17 Apr 2007: Accepted
In 2.9 Error Handling (first paragraph):
Replace the text:
[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.
With:
[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.
See Bug 2321
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.
17 Apr 2007: Proposed
17 Apr 2007: Accepted
In 16.5.2 The Language, Calendar, and Country Arguments (second paragraph):
Replace the text:
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.
With:
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.
Superseded by Erratum XT.E31
See Bug 4372
The specification does not constrain the value of the serialization parameter
doctype-public to the values that will be accepted in well-formed XML.
The primary place for such rules is the Serialization specification, but this erratum
adds a sentence to the XSLT specification to make it clear that restrictions apply.
The change affects xsl:output and xsl:result-document.
A corresponding change is being made to the Serialization specification: see Serialization erratum E1.
16 Apr 2007: Proposed
15 Nov 2007: Accepted
13 Mar 2009: Superseded
In 20 Serialization (second bulleted list, fifth item):
Insert after the text:
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 following:
The value of doctype-public must conform to the rules
for a PubidLiteralXML
(see
[XML 1.0]
).
See Bug 4315
The rules for trimming whitespace from attribute values in the stylesheet are unclear.
3 Apr 2007: Proposed
17 Apr 2007: Accepted
In 2.2 Notation (first bulleted list, third item, second paragraph):
Replace the text:
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.
With:
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.
See Bug 4237
There are errors in the published schema for XSLT 2.0. The corrected schema has been placed at http://www.w3.org/2007/schema-for-xslt20.xsd, overwriting the original, and the version in Appendix G needs to be updated accordingly.
16 Mar 2007: Proposed
17 Apr 2007: Accepted
The changes made to the schema are as follows:
A global element definition for xsl:document has been added.
The content model for xsl:sequence has been restricted to
match the element proforma in the normative text.
The new schema replaces the schema published as Appendix G.
2.2 Notation
XT.E2
2.4 Executing a Transformation
XT.E11
2.9 Error Handling
XT.E5
3.2 Reserved Namespaces
XT.E6
3.6.1 The default-collation attribute
XT.E36
3.14 Importing Schema Components
XT.E9 XT.E28
5.4.4 Additional Dynamic Context Components used by XSLT
XT.E19
5.7.1 Constructing Complex Content
XT.E10
5.7.3 Namespace Fixup
XT.E6 XT.E16
6.4 Conflict Resolution for Template Rules
XT.E21
6.5 Modes
XT.E19
11.2 Creating Element Nodes Using xsl:element
XT.E6
11.3 Creating Attribute Nodes Using xsl:attribute
XT.E6 XT.E18
11.6 Creating Processing Instructions
XT.E35
11.7 Creating Namespace Nodes
XT.E6 XT.E7
12.2 Numbering based on Position in a Document
XT.E30
12.3 Number to String Conversion Attributes
XT.E34
13.1.2 Comparing Sort Key Values
XT.E13
13.1.3 Sorting Using Collations
XT.E26
14 Grouping
XT.E25
14.3 The xsl:for-each-group Element
XT.E8 XT.E25
16.3.2 The key Function
XT.E33
16.5.1 The Picture String
XT.E24 XT.E29
16.5.2 The Language, Calendar, and Country Arguments
XT.E4
16.5.3 Examples of Date and Time Formatting
XT.E22 XT.E23 XT.E24 XT.E29
16.6.5 system-property
XT.E14
17 Messages
XT.E20
18.1.4 Testing Availability of Types
XT.E15
19.1 Creating Final Result Trees
XT.E31
19.2.1.3 The Validation Process
XT.E12
20 Serialization
XT.E3 XT.E31
20.1 Character Maps
XT.E27
20.2 Disabling Output Escaping
XT.E27 XT.E32
A.1 Normative References
XT.E34
E Summary of Error Conditions (Non-Normative)
XT.E17
G Schema for XSLT Stylesheets (Non-Normative)
XT.E1
J.1.4 Incompatibility in the Absence of a Schema
XT.E32
Bug #2321: XT.E4
Bug #2388: XT.E5
Bug #3069: XT.E16
Bug #3336: XT.E18
Bug #4237: XT.E1
Bug #4315: XT.E2
Bug #4372: XT.E3
Bug #4464: XT.E6
Bug #4513: XT.E7
Bug #4546: XT.E14
Bug #4548: XT.E12
Bug #4589: XT.E8
Bug #4591: XT.E9
Bug #4600: XT.E10
Bug #4620: XT.E11
Bug #4696: XT.E15
Bug #4843: XT.E19
Bug #4849: XT.E13
Bug #4878: XT.E17
Bug #5278: XT.E20
Bug #5295: XT.E25
Bug #5308: XT.E29
Bug #5324: XT.E26
Bug #5482: XT.E21
Bug #5571: XT.E22
Bug #5667: XT.E27
Bug #5849: XT.E30
Bug #5853: XT.E23
Bug #5893: XT.E31
Bug #6093: XT.E28
Bug #6140: XT.E32
Bug #6164: XT.E33
Bug #6186: XT.E34
Bug #6231: XT.E36
Bug #6282: XT.E35
xsl:attribute: XT.E6 XT.E7 XT.E10 XT.E18
xsl:character-map: XT.E27
xsl:copy: XT.E12
xsl:copy-of: XT.E12
xsl:document: XT.E1
xsl:element: XT.E6 XT.E7 XT.E10 XT.E12
xsl:for-each-group: XT.E8 XT.E25
xsl:import-schema: XT.E9 XT.E28
xsl:key: XT.E33
xsl:message: XT.E20
xsl:output: XT.E3 XT.E27 XT.E31
xsl:processing-instruction: XT.E35
xsl:result-document: XT.E3 XT.E31
xsl:sequence: XT.E1
xsl:text: XT.E32
xsl:value-of: XT.E32
format-date: XT.E4 XT.E23 XT.E24 XT.E29
format-dateTime: XT.E4 XT.E24 XT.E29
format-time: XT.E4 XT.E22 XT.E24 XT.E29
system-property: XT.E14
type-available: XT.E15
XTDE0485: XT.E16
XTDE0835: XT.E6
XTSE0530: XT.E21
XTTE0950: XT.E17
[xsl:]default-collation: XT.E36