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 2.4 gives the official definition of an XSLT 'instruction' as those XSLT elements that appear in sequence constructors. The non-normative Appendix D marks certain elements as instructions, but the following "subsidiary elements" are not so marked: xsl:sort xsl:when, xsl:otherwise xsl:matching-substring, xsl:non-matching-substring xsl:with-param Though non-normative, this suggests that the WG might intend to restrict the definition to only those XSLT elements that are allowed as children, not just descendants, of xsl:template. The real issue is what element-available() will return when given any of those element names as an argument. They fit the normative definition, so one would expect 'true' is the correct answer. I think this is good for future-proofing XSLT as best we can. While the above elements may not appear to be good fodder for an element-available() test today, it's hard to predict all possible future enhancements to XSLT. I see no down side to having element-available() return true for these. If you agree, then all that is needed is an editorial change in Appendix D to mark these as instructions, or subsidiary instructions if you are more comfortable with that. If you disagree, then the definition needs to be tightened up. While tightening, it would be good to address the possibility for extension subsidiary elements. In other words, can xsl:choose, xsl:analyze-string, xsl:call-template, etc. take extension elements as children? (For that matter, can xsl:attribute-set, xsl:character-map, or xsl:import-schema tolerate any foreign-namespaced child elements? If not, what is the static error?)
The definition "The elements appearing within a sequence constructor are referred to as instructions." is intended to be read in conjunction with the definition of sequence constructor: "A sequence constructor is a sequence of zero or more sibling nodes in the stylesheet that can be evaluated to return a sequence of nodes and atomic values." Instructions are the element nodes appearing directly in this sequence: *not* their children or descendants. The set of XSLT elements classified as instructions are clearly labelled as such not only in the non-normative Appendix D, but also in the syntax summary of the element, for example: <!-- Category: instruction --> <xsl:apply-templates .... I think it might be helpful if the definition of "instruction" mentioned the category notation used in the element syntax summaries. Incidentally, xsl:param is not an instruction, because it is not part of a sequence constructor. In this respect the definition of template rule in 2.4 is perhaps unhelpful "A template rule has two parts: a pattern that is matched against nodes, and a sequence constructor that is evaluated to produce a sequence of items." It should perhaps say "A template rule has three parts: a pattern that is matched against nodes, a set of parameters, and a sequence constructor that is evaluated to produce a sequence of items." This would match the syntax given in 6.4 (But a template rule also has a priority, a precedence, a required type, and a mode...) The behaviour of element-available() is unchanged from XSLT 1.0, which made the same distinction: "The element-available function returns true if and only if the expanded-name is the name of an instruction". I suspect, however, that many XSLT 1.0 implementations get this wrong (and the only people who are likely to notice are conformance testers). You ask the question: can xsl:choose, xsl:analyze-string, xsl:call-template, etc. take extension elements as children? I think the answer is clearly no. Each of these elements has a content model given in the normative definition of the element, and the content model defines the list of elements that may appear as children. Extension elements can appear as children only of an element that has a sequence constructor in its content model. Michael Kay personal response
I'm sorry, but the use of the word "within" is not sufficient by itself to carry that meaning. I think you should change it to "immediately within" (a term seen in chapter 13). There are many places in the CR document where "within" means all descendants, not just children. For example: expressions within stylesheet (3.13, 5.3, 5.4, 10.3) functions within stylesheet (2.5) type references within stylesheet (2.8) LRE within stylesheet module (3.12) instruction within global variable declaration (10.1.2) XSLT element within stylesheet (5.4) function within pattern (14.1, 16.6) variable references within stylesheet function body (10.3) and on and on. Notice that some of these are situations where the item on the LHS *cannot* be a child of the item on the RHS. The use of "within" in 3.9 to describe where forwards compatibility applies also presumes descendants. >I think it might be helpful if the definition of "instruction" mentioned the >category notation used in the element syntax summaries. Agreed. I also agree with your suggestion about the 3 parts of a template rule. >The behaviour of element-available() is unchanged from XSLT 1.0, ... many >XSLT 1.0 implementations get this wrong (and the only people who are likely to >notice are conformance testers). That may be the case *now*, but element-available() is a future-proofing tool, so it should be specified well enough to make it robust. I don't see any harm in an explicit sentence (in 18.2.2) saying that element-available('xsl:param') must return false. The others (xsl:when, etc.) could be mentioned in a note at 18.2.2, but tightening the definition at 2.4 is more crucial.
"There are many places in the CR document where "within" means all descendants, not just children. " If N is a node, then yes, we regard all the descendants of the node as being within the tree rooted at that node. But if S is a sequence, then I think the natural meaning of "items within S" is the items that are members of the sequence, not their children or descendants. However, we shouldn't rely on readers guessing this so I don't mind tightening it up.
The WG asked the editor to propose wording that would resolve this problem. Proposal: (1) In 2.4 change the definition [Definition: The elements appearing within a sequence constructor are referred to as instructions.] to a non-definition paragraph The elements making up a sequence constructor are referred to as instructions. followed by the definition: [Definition: an instruction is either an XSLT element whose syntax summary identifies it as such using the annotation <!-- Category: instruction -->, or an _extension instruction_]. Extension instructions are described in _18.2_ (2) In 2.4 change the definition of "template rule" to: [Definition: A stylesheet contains a set of template rules (see 6 Template Rules). A template rule has three parts: a pattern that is matched against nodes, a (possibly empty) set of parameters, and a sequence constructor that is evaluated to produce a sequence of items.]
On re-reading the new definition, I've realized that literal results elements are instructions by virtue of the fact that they are elements making up a sequence constructor, but they are not included in the definition of "instruction". It doesn't matter a great deal whether LREs are classified as instructions or not, so long as we're consistent - it's already clear that they aren't matched by element-available(). In 2.7, the phrase "by providing new XSLT instructions" is wrong, since we use "XSLT instructions" elsewhere to mean "instructions in the XSLT namespace". I'll come back to this in due course.
I don't think there's anywhere in the spec that relies on LRE's being instructions, and in fact we probably tend to think of them as not being instructions. So I'll propose text accordingly. (1) At the start of section 2.2, add a definition: "[Definition: an *XSLT element* is an element in the _XSLT namespace_ whose syntax and semantics are defined in this specification.]. For a non-normative list of XSLT elements, see [Appendix D]." Link uses of the term to this definition where appropriate. (2) At the start of section 2.4, change the definition of template rules to: [Definition: A stylesheet contains a set of template rules (see 6 Template Rules). A template rule has three parts: a _pattern_ that is matched against nodes, a (possibly empty) set of _template parameters_, and a _sequence constructor_ that is evaluated to produce a sequence of items.] (3) In 2.4, replace the paragraph [Definition: The elements appearing within a sequence constructor are referred to as instructions.] with A sequence constructor is a sequence of sibling nodes in the stylesheet, which may be _XSLT instructions_, _literal result elements_, text nodes, or _extension instructions_. For further details, see [5.7] [Definition: an *instruction* is either an XSLT instruction, which is an _XSLT element_ whose syntax summary in this specification contains the annotation <!-- category: instruction -->, or an _extension instruction_, which is an element in a namespace that has been designated as an extension namespace (see [18.2.1]).] (3) In 3.2 (once), 5.2 (twice), 5.4.2 (once), replace "XSLT instruction" by "XSLT element" (4) In 18.2.2, replace the two paragraphs: <old> If the processor does not have an implementation of a particular extension instruction available, then the element-available function must return false for the name of the element. When such an extension instruction is evaluated, then the processor must perform fallback for the element as specified in 18.2.3 Fallback. An implementation must not signal an error merely because the stylesheet contains an extension instruction for which no implementation is available. If the processor has an implementation of a particular extension instruction available, then the element-available function must return true for the name of the element. </old> by: <new> If the expanded QName is in the _XSLT namespace_, the function returns true if and only if the expanded QName is the name of an _XSLT instruction_, that is, an _XSLT element_ whose syntax summary in this specification classifies it as an _instruction_. Note: although the result of calling this function when using a conformant XSLT 2.0 processor is entirely predictable, the function is useful in cases where the stylesheet might be executing under a processor that implements some other version of XSLT with different rules. If the expanded QName is not in the _XSLT namespace_, the function returns true if and only if the processor has an implementation available of an _extension instruction_ with the given expanded QName. This applies whether or not the namespace has been designated as an _extension namespace_. If the processor does not have an implementation of a particular extension instruction available, and such an extension instruction is evaluated, then the processor must perform fallback for the element as specified in 18.2.3 Fallback. An implementation must not signal an error merely because the stylesheet contains an extension instruction for which no implementation is available. </new>
These changes were agreed by the WG on 10 May 2006, and have been applied to the document.
These changes appear in the June draft. I am therefore marking the bug as closed.