- From: <bugzilla@wiggum.w3.org>
- Date: Fri, 21 Apr 2006 08:56:42 +0000
- To: public-qt-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=3123 ------- Comment #1 from mike@saxonica.com 2006-04-21 08:56 ------- 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
Received on Friday, 21 April 2006 08:56:50 UTC