This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 3.9 of XSLT 2.0[1] indicates that "An element enables forwards-compatible behavior for itself, its attributes, its descendants and their attributes if it has an [xsl:]version attribute (see 3.5 Standard Attributes) whose value is greater than 2.0." It then goes on to say that, "Within a section of a stylesheet where forwards-compatible behavior is enabled... if an element in the XSLT namespace appears as part of a sequence constructor, and XSLT 2.0 does not allow such elements to appear as part of a sequence constructor, then:" and describes the treatment of such elements depending on whether they have xsl:fallback children. Now consider the following fragment: <xsl:for-each select="foo" version="8.5"> <xsl:character-map version="2.0"> <xsl:fallback/> </xsl:character-map> </xsl:for-each> Is the xsl:character-map in a section of the stylesheet where forwards-compatible behaviour is enabled, because it is part of a sequence constructor whose parent has enabled forwards-compatible behaviour, or is it in section where forwards-compatible behaviour is disabled, because the element has disabled forwards-compatible behaviour for itself? In other words, is it the parent of the sequence constructor that ultimately decide whether it may have content that's not ordinarily permitted in a sequence constructor, or is it the nodes in the sequence constructor itself that have the final decision? I think the intent was that it is the node itself that has the final say, and I think that reading is consistent with XSLT 1.0. To make that clear, I suggest the following changes in section 3.9: o Change the first sentence of the sixth paragraph from "Within a section of a stylesheet where forwards-compatible behavior is enabled" to "If forwards-compatible behaviour is enabled for an element, and"; o In the first item in the second list, change "an element in the XSLT namespace appears as a child" to "the element is in the XSLT namespace and appears as a child"; o In the second item in the second list, change "if an element has an attribute" to read "the element has an attribute" o In the third item in the second list, change "if an element in the XSLT namespace appears as part of a sequence constructor" to "the element is in the XSLT namespace and appears as part of a sequence constructor" [1] http://www.w3.org/TR/xslt20/#forwards
Agreed that it would be desirable to clarify the wording here. Note that we use a different approach in the 2.1 spec, which may be better. Otherwise, the editor should consider how best to clarify it (including the proposal contained here).
Erratum number E52 has been allocated, but text still needs to be drafted so the bug is still open.
Draft erratum was issued, replacing seventh paragraph of section 3.9 with the following: If forwards-compatible behavior is enabled for an element, then: * if the element is in the XSLT namespace and appears as a child of the xsl:stylesheet element, and XSLT 2.0 does not allow such elements to occur as children of the xsl:stylesheet element, then the element and its content must be ignored. * if the element has an attribute that XSLT 2.0 does not allow the element to have, then the attribute must be ignored. * if the element is in the XSLT namespace and appears a child of an element whose content model requires a sequence constructor, and XSLT 2.0 does not allow such elements to appear as part of a sequence constructor, then: 1. If the element has one or more xsl:fallback children, then no error is reported either statically or dynamically, and the result of evaluating the instruction is the concatenation of the sequences formed by evaluating the sequence constructors within its xsl:fallback children, in document order. Siblings of the xsl:fallback elements are ignored, even if they are valid XSLT 2.0 instructions. 2. If the element has no xsl:fallback children, then a static error is reported in the same way as if forwards-compatible behavior were not enabled. I am satisfied that this resolves the problem.