Comments on this specification may be sent to firstname.lastname@example.org.
Added text marked thus. Removed text marked thus. Changed text marked thus.
Section 1, first paragraph.
This specification defines the syntax and semantics of the XSLT language. A transformation in the XSLT language is expressed as a well-formed XML document [XML] or [XML 1.1] conforming to the Namespaces in XML Recommendation [XML Names] or [XML Names 1.1], which may include both elements that are defined by XSLT and elements that are not defined by XSLT. For convenience, XML 1.0 and XML Names 1.0 references are usually used. Thus, URI references are also used though IRI may also be supported. In some cases, the XML 1.0 and XML 1.1 definitions may be exactly the same.
Section 3.5, new section.
The data model is capable of representing either an XML 1.0 document (conforming to [XML] and [XML Names]) or an XML 1.1 document (conforming to [XML 1.1] and [XML Names 1.1]), and it makes no distinction between the two. In principle, therefore, XSLT 1.0 can be used with either of these XML versions; the only differences arise outside the boundary of the transformation proper, either while creating the data model from textual XML (parsing), or while producing textual XML from the data model (serialization).
Construction of the data model is outside the scope of this specification, so XSLT 1.0 places no formal requirements on an XSLT processor to accept input from either XML 1.0 documents or XML 1.1 documents or both. This specification defines capability to output XML 1.0 or XML 1.1 documents (16 Output). There is again no formal requirement on an XSLT processor to support either or both of these XML versions.
Because the data model is the same whether the original document was XML 1.0 or XML 1.1, the semantics of XSLT processing do not depend on the version of XML used by the original document. There is no reason in principle why all the input and output documents used in a single transformation must conform to the same version of XML.
Section 11.5, first paragraph.
As well as being allowed at the top-level, both
xsl:paramare also allowed in templates.
xsl:variableis allowed anywhere within a template that an instruction is allowed. In this case, the binding is visible for all following siblings and their descendants.the descendants of all following siblings that are not
xsl:fallbackinstructions. Note that the binding is not visible for the
xsl:paramis allowed as a child at the beginning of an
xsl:templateelement. In this context, the binding is visible for all following siblings and their descendants.the descendants of all following siblings that are not
xsl:fallbackinstructions. Note that the binding is not visible for the
Section 16.1, first paragraph.<?xml version="xml-version"?> <!DOCTYPE doc [ <!ENTITY e SYSTEM "entity-URI"> ]> <doc>&e;</doc>
entity-URIis a URI for the entity and
xml-versioncorresponds to the XML version of the entity, then the wrapper document as a whole should be a well-formed XML document conforming to the XML Namespaces Recommendation [XML Names]. either to [XML Names] or [XML Names 1.1].
Section 16.1, fourth paragraph.
versionattribute specifies the version of XML to be used for outputting the result tree. If the XSLT processor does not support this version of XML, it should use a version of XML that it does support. The version output in the XML declaration (if an XML declaration is output) should correspond to the version of XML that the processor used for outputting the result tree. The value of the
versionattribute should match the VersionNum production of the XML Recommendation [XML]. The default value is
1.0.The default value is 1.0. If the value is 1.1 and the XSLT processor does support XML 1.1 and XML Names 1.1, then the following restrictions apply:
Undeclaring prefixes must not occur.
Unicode normalization must not occur.
Section 16.1, fifth paragraph.
encodingattribute specifies the preferred encoding to use for outputting the result tree. XSLT processors are required to respect values of
UTF-16. For other values, if the XSLT processor does not support the specified encoding it may signal an error; if it does not signal an error it should use
UTF-16instead. The XSLT processor must not use an encoding whose name does not match the EncName production of the XML Recommendation [XML] or [XML 1.1]. If no
encodingattribute is specified, then the XSLT processor should use either
Section A.1, Add the following references:
World Wide Web Consortium. Extensible Markup Language (XML) 1.1. W3C Recommendation. See http://www.w3.org/TR/xml11/
World Wide Web Consortium. Namespaces in XML 1.1. W3C Recommendation. See http://www.w3.org/TR/xml-names11/
Section 2.1, second paragraph.
Elements from the XSLT namespace are recognized only in the stylesheet and not in the source document.
Section 2.5, first paragraph. Spurious reference to literal result element as stylesheet without
xsl:versionattribute. See http://lists.w3.org/Archives/Public/xsl-editors/1999OctDec/0035.html.
An element enables forwards-compatible mode for itself, its attributes, its descendants and their attributes if either it is an
versionattribute is not equal to
1.0, or it is a literal result element that has an
xsl:versionattribute whose value is not equal to
1.0, or it is a literal result element that does not have an
xsl:versionattribute and that is the document element of a stylesheet using the simplified syntax (see [2.3 Literal Result Element as Stylesheet]). A literal result element that has an
xsl:versionattribute whose value is equal to
1.0disables forwards-compatible mode for itself, its attributes, its descendants and their attributes.
Section 2.5, first note.
NOTE: If a stylesheet depends crucially on a top-level element introduced by a version of XSLT after 1.0, then the stylesheet can use an
terminate="yes"(see [13 Messages]) to ensure that XSLT processors implementing earlier versions of XSLT will not silently ignore the top-level element. For example,
Section 2.7, final note.
NOTE:A stylesheet that is embedded in the document to which it is to be applied or that may be included or imported into an stylesheet that is so embedded typically needs to contain a template rule that specifies that
xsl:stylesheetelements are to be ignored.
Section 3.4, paragraph 6. Description of
xsl:preserve-spaceis unclear, see http://lists.w3.org/Archives/Public/xsl-editors/1999OctDec/0083.html.
For source documents, the set of whitespace-preserving element names is specified by
xsl:preserve-spacetop-level elements. Whether an element name is included in the set of whitespace-preserving names is determined by the best match amongst
xsl:preserve-spaceelements: it is included if and only if there is no match or the best match is an
xsl:preserve-spaceelement. These The
xsl:preserve-spaceelements each have an
elementsattribute whose value is a whitespace-separated list of NameTests; an element name matches an
xsl:preserve-spaceelement if it matches one of the NameTests. An element matches a NameTest if and only if the NameTest would be true for the element as an XPath node test. When more than one
xsl:preserve-spaceelement matches, the best matching element is determined by the best matching NameTest. This is determined in the same way as with template rules:
Section 5.2, fourteenth bullet.
itemelement that has an
itemsparent and that is not the first
itemchild of its parent
Section 7.1.2, second paragraph.
An XSLT processor may signal the error; if it does not signal the error, then it must recover by making the the result of instantiating the
xsl:elementelement be the sequence of nodes created by instantiating the content of the
xsl:elementelement, excluding any initial attribute nodes.
Section 7.1.3, third bullet. Recovery behavior for element nodes in instantiated content of
xsl:attributeis unclear. See http://lists.w3.org/Archives/Member/w3c-xsl-wg/2000May/0092.html (members only).
- Creating nodes other than text nodes during the instantiation of the content of the
xsl:attributeelement; implementations may either signal the error or ignore the offending nodes together with their content.
Section 7.1.4, last paragraph. Interaction of
xsl:importis unspecified. See http://lists.w3.org/Archives/Member/w3c-xsl-wg/2000Jun/0057.html (members only) and http://lists.w3.org/Archives/Public/xsl-editors/2000JulSep/0095.html.
Multiple definitions of an attribute set with the same expanded-name are merged. An attribute from a definition that has higher import precedence takes precedence over an attribute from a definition that has lower import precedence. It is an error if there are two attribute sets that have the same expanded-name and equal import precedence and that both contain the same attribute, unless there is a definition of the attribute set with higher import precedence that also contains the attribute. An XSLT processor may signal the error; if it does not signal the error, it must recover by choosing from amongst the definitions that specify the attribute that have the highest import precedence the one that was specified last in the stylesheet. Where the attributes in an attribute set were specified is relevant only in merging the attributes into the attribute set; it makes no difference when the attribute set is used. For each attribute set name occurring in a
use-attribute-setsattribute on an
xsl:attribute-setelement, all definitions of an attribute set with that name must be merged before the
use-attribute-setsattribute is replaced by the equivalent sequence of
xsl:attributechild elements. Any
use-attribute-setsattribute on an
xsl:attribute-setelement must be replaced by the equivalent sequence of
xsl:attributechild elements before that
xsl:attribute-setelement is merged with other
xsl:attribute-setelements with the same expanded-name. When
xsl:attribute-setelements with the same expanded-name are merged, any
xsl:attributechild elements added to replace a
use-attribute-setsattribute are treated exactly as if they had originally been specified in the stylesheet as child elements.
Section 7.5. Behavior when copying a namespace node is unspecified. See http://lists.w3.org/Archives/Public/xsl-editors/2000JulSep/0095.html.
Add the following paragraph before the final paragraph of the section:
When the current node is a namespace node, then copying it adds a namespace node to the containing node in the result tree. It is an error if this containing node is not an element; implementations may either signal the error or ignore the namespace node. It is an error to add a namespace node to an element after children have been added to it or after attributes have been added to it; implementations may either signal an error or ignore the namespace node. It is an error to add a namespace node to an element if the element already has a namespace node with the same name, unless both namespace nodes have the same string-value, in which case the duplicate is ignored. It is an error to add a namespace node to an element if the namespace node has a null name and the element has a null namespace URI.
[Section 11.3, first paragraph] The
xsl:copy-ofelement can be used to insert a result tree fragment into the result tree, without first converting it to a string as
xsl:value-ofdoes (see [7.6.1 Generating Text with
xsl:value-of]). The required
selectattribute contains an expression. When the result of evaluating the expression is a result tree fragment, the complete fragment is copied into the result tree. When the result is a node-set, all the nodes in the set are copied in document order into the result tree; copying an element node copies the attribute nodes, namespace nodes and children of the element node as well as the element node itself; a root node is copied by copying its children. For copying an attribute or namespace node, the same rules apply as with
xsl:copy(see [7.5 Copying]). When the result is neither a node-set nor a result tree fragment, the result is converted to a string and then inserted into the result tree, as with
Section 7.7, first paragraph. Behavior unspecified when an expression specified by a
xsl:numberevaluates to a numeric value that after rounding is not a strictly positive integer. See http://lists.w3.org/Archives/Public/xsl-editors/2000JulSep/0057.html.
xsl:numberelement is used to insert a formatted number into the result tree. The number to be inserted may be specified by an expression. The
valueattribute contains an expression. The expression is evaluated and the resulting object is converted to a number as if by a call to the number function. It is an error if the number is NaN, infinite or less than 0.5; an XSLT processor may signal the error; if it does not signal the error, it must recover by converting the number to a string as if by a call to the string function and inserting the resulting string into the result tree. Otherwise, tThe number is rounded to an integer and then converted to a string using the attributes specified in [7.7.1 Number to String Conversion Attributes]; in this context, the value of each of these attributes is interpreted as an attribute value template. After conversion, the resulting string is inserted in the result tree. For example, the following example numbers a sorted list:
Section 7.7, sixth bullet. Behavior unspecified when
xsl:number level="any"and there are no matching nodes. See http://lists.w3.org/Archives/Member/w3c-xsl-wg/2000Apr/0017.html (members only).
level="any", it constructs a list of length one containing the number of nodes that match the
countpattern and belong to the set containing the current node and all nodes at any level of the document that are before the current node in document order, excluding any namespace and attribute nodes (in other words the union of the members of the
ancestor-or-selfaxes). If there are no matching nodes, it constructs an empty list. If the
fromattribute is specified, then only nodes after the first node before the current node that match the
frompattern are considered.
Section 10, first paragraph.
When a template is instantiated by
xsl:for-each, the current node list list consists of the complete list of nodes being processed in sorted order.
Section 10, second paragraph. See http://lists.w3.org/Archives/Member/w3c-xsl-wg/2000Jul/0004.html (members only).
For each node to be processed, the expression is evaluated with that node as the current node and with the complete list of nodes being processed in document order as the current node list.
Section 10, fifth bullet. Behavior unspecified when sorting
data-type="number". See http://lists.w3.org/Archives/Member/w3c-xsl-wg/2000Jun/0057.html (members only).
numberspecifies that the sort keys should be converted to numbers and then sorted according to the numeric value; the sort key is converted to a number as if by a call to the number function; the
langattribute is ignored; in ascending order a NaN precedes all other numeric values and in descending order it follows them
Section 10, seventh bullet. Interaction of case order and sorting direction underspecified. See http://lists.w3.org/Archives/Member/w3c-xsl-wg/2000Jul/0004.html (members only).
case-orderhas the value
lower-first; this applies when
data-type="text", and specifies that in ascending order upper-case letters should sort before lower-case letters or vice-versa respectively. For example, if
A a B bare sorted in ascending order with
a A b Bare sorted in ascending order with
case-order="lower-first". In descending order, the effect is reversed. For example, if
b B a Aare sorted in descending order with
case-order="upper-first". The default value is language dependent.
Section 11, last paragraph. Description of shadowed variables is overly general given the prohibition on local variables shadowing other local variables. See http://lists.w3.org/Archives/Public/xsl-editors/1999OctDec/0082.html.
For any use of these variable-binding elements, there is a region of the stylesheet tree within which the binding is visible; within this region, any binding of the variable that was visible on the variable-binding element itself is hidden. Thus, only the innermost binding of a variable is visible. The set of variable bindings in scope for an expression consists of those bindings that are visible at the point in the stylesheet where the expression occurs.
[Section 11.4, first paragraph.] Both
xsl:paramare allowed as top-level elements. A top-level variable-binding element declares a global variable that is visible everywhere (except where it is shadowed by another binding).
[Section 11.5, second paragraph.] A binding shadows another binding if the binding occurs at a point where the other binding is visible, and the bindings have the same name. It is an error if a binding established by an
xsl:paramelement within a template shadows another binding established by an
xsl:paramelement also within the template. It is not an error if a binding established by an
xsl:paramelement in a template shadows another binding established by an
xsl:paramtop-level element. In this case, the top-level binding will not be visible in the region of the stylesheet where it is shadowed by the other binding. Thus, the following is an error:
Section 11.4, first paragraph. Behavior of multiple top-level variables with the same name and different import precedences is unspecified. See http://lists.w3.org/Archives/Public/xsl-editors/1999OctDec/0082.html.
... A top-level
xsl:paramelement declares a parameter to the stylesheet; XSLT does not define the mechanism by which parameters are passed to the stylesheet. If a stylesheet contains more than one binding for a variable of a particular name, then the binding with the highest import precedence is used. It is an error if a stylesheet contains more than one binding of a top-level variable with the same name and same import precedence.
Section 11.6, first paragraph. Behavior of
xsl:with-paramelements with the same
nameis unspecified. See http://lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0088.html.
Parameters are passed to templates using the
xsl:with-paramelement. The required
nameattribute specifies the name of the parameter (the variable the value of whose binding is to be replaced). The value of the
nameattribute is a QName, which is expanded as described in [2.4 Qualified Names].
xsl:with-paramis allowed within both
xsl:apply-templates. It is an error if a single
xsl:apply-templateselement contains more than one
xsl:with-paramelement with the same name. The value of the parameter is specified in the same way as for
xsl:param. The current node and current node list used for computing the value specified by
xsl:with-paramelement is the same as that used for the
xsl:call-templateelement within which it occurs. It is not an error to pass a parameter x to a template that does not have an
xsl:paramelement for x; the parameter is simply ignored.
Section 12.1, fourth paragraph.
The semantics of the fragment identifier are dependent on the media type of the result of retrieving the URI.
Section 12.1, sixth paragraph. Behavior unspecified when the
documentfunction is called with an empty nodeset as a second argument. See http://lists.w3.org/Archives/Public/xsl-editors/2000JulSep/0095.html.
The URI reference may be relative. The base URI (see [3.2 Base URI]) of the node in the second argument node-set that is first in document order is used as the base URI for resolving the relative URI into an absolute URI. It is an error if the second argument node-set is empty and the URI reference is relative; the XSLT processor may signal the error; if it does not signal an error, it must recover by returning an empty node-set. If the second argument is omitted, then it defaults to the node in the stylesheet that contains the expression that includes the call to the document function.
Section 12.2, eighth paragraph. Calls to the
xsl:keyelements may cause cycles. See http://lists.w3.org/Archives/Member/w3c-xsl-wg/2000Jun/0048.html (members only).
It is an error for the value of either the
useattribute or the
matchattribute to contain a VariableReference, or a call to the key function.
Section 12.2, ninth paragraph.
When the second argument to the key function is of type node-set, then the result is the union of the result of applying the key function to the string-value of each of the nodes in the argument node-set.
Section 12.2, next-to-last paragraph. Text introducing example is confusing. See http://lists.w3.org/Archives/Member/w3c-xsl-wg/2000Jul/0008.html (members only).
The key always returns nodes that are in the same document as the current node; to retrieve a key from any other document, it is necessary first to change the current node. For example, suppose a document contains bibliographic references in the form
<bibref>XSLT</bibref>, and there is a separate XML document
bib.xmlcontaining a bibliographic database with entries in the form:
Section 12.3, second paragraph. Behaviour of the
format-numberfunction in the absence of an
xsl:decimal-formatelement is unspecified. See http://lists.w3.org/Archives/Member/w3c-xsl-wg/2000Jun/0057.html (members only).
xsl:decimal-formatelement declares a decimal-format, which controls the interpretation of a format pattern used by the format-number function. If there is a
nameattribute, then the element declares a named decimal-format; otherwise, it declares the default decimal-format. The value of the
nameattribute is a QName, which is expanded as described in [2.4 Qualified Names]. It is an error to declare either the default decimal-format or a decimal-format with a given name more than once (even with different import precedence), unless it is declared every time with the same value for all attributes (taking into account any default values). If a stylesheet does not contain a declaration of the default decimal format, a declaration equivalent to an
xsl:decimal-formatelement with no attributes is implied.
Section 12.4. Restrictions on system properties in the XSLT namespace unclear. See http://lists.w3.org/Archives/Public/xsl-editors/2000JulSep/0095.html.
Add the following paragraph at the end of the section:
Vendors must not define additional system properties in the XSLT namespace.
Section 13, final example.<xsl:param name="lang" select="'en'"/>
Section 15, third paragraph. Interaction of a default namespace with the
element-availablefunction is unspecified. See http://lists.w3.org/Archives/Public/xsl-editors/1999OctDec/0039.html.
The argument must evaluate to a string that is a QName. The QName is expanded into an expanded-name using the namespace declarations in scope for the expression. If there is a default namespace in scope, then it is used to expand an unprefixed QName. The element-available function returns true if and only if the expanded-name is the name of an instruction. If the expanded-name has a namespace URI equal to the XSLT namespace URI, then it refers to an element defined by XSLT. Otherwise, it refers to an extension element. If the expanded-name has a null namespace URI, the element-available function will return false.
Section 16.1, first bullet. Serialization need not preserve ordering of namespace nodes. See http://lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0086.html.
- The order of attribute and namespace nodes in the two trees may be different.
Section 16.1 Serialization cannot preserve base URIs.
Add the following text as a third bullet:
The base URIs of nodes in the two trees may be different.
Section 16.1, second paragraph. If the output includes a standalone document declaration or document type declaration, then it must be an XML document and not merely an external general parsed entity. See http://lists.w3.org/Archives/Public/xsl-editors/1999OctDec/0074.html.
If the XSLT processor generated a document type declaration because of the
doctype-systemattribute or generated a standalone document declaration because of the
standaloneattribute, then the output must be a well-formed XML document, and the above requirements apply to the tree constructed by parsing that document directly, without any wrapper, using an XML processor that does not process the DTD.NOTE:Processing the DTD might cause additional attributes to appear in the tree because of attribute defaulting.
Section 16.1, tenth paragraph.
Otherwise, it should not include a standalone document declaration; this ensures that it is both an XML declaration (allowed at the beginning of a document entity) and a text declaration (allowed at the beginning of an external general parsed entity).
Section 16.4 Interaction of
disable-output-escapingand result tree fragments unspecified. See http://lists.w3.org/Archives/Member/w3c-xsl-wg/2000Apr/0061.html (members only) and http://lists.w3.org/Archives/Member/w3c-xsl-wg/2000May/0066.html (members only).
Add the following text after the second paragraph:
When a root node is copied using an
xsl:copy-ofelement (see [11.3 Using Values of Variables and Parameters with
xsl:copy-of]) and escaping was disabled for a text node descendant of that root node, then escaping should also be disabled for the resulting copy of that text node. For example<xsl:variable name="x"> <xsl:text disable-output-escaping="yes"><</xsl:text> </xsl:variable> <xsl:copy-of select="$x"/>
Appendix E. Add "Boris Moore, RivCom" to the list of XSL WG members.