- From: David Marston/Cambridge/IBM <david_marston@us.ibm.com>
- Date: Fri, 25 Oct 2002 16:03:54 -0400 (EDT)
- To: xsl-editors@w3.org
- Cc: xslt-conformance@lists.oasis-open.org
These questions are submitted on behalf of the XSLT/Xpath Conformance Technical Committee (TC). We had a detailed technical discussion at our September teleconference and concluded that we don't all agree about the meaning of the XSLT 1.0 Rec, as amended by errata up through E34. Since we will accept or reject test cases based on the meaning, we need a normative statement. If there will be a time lag before the normative statement, we can use our "gray area" mechanism while the statement is prepared for publication, as long as we know what its substance will be. Regarding xsl:number, counting is reasonably clear except when the from attribute is specified. Erratum E23 addresses one case. What do you do if the from attribute is set to a node name that has not yet been encountered? Several Xalan numbering tests exemplify this issue, with numbering61 being the simplest example for level="any". Erratum E23 addresses this situation (only for level="any") but leaves the sentence: "If the from attribute is specified, then only nodes after the first node before the current node that match the from pattern are considered." It does not say "only nodes after the nearest previous (preceding|ancestor-or-self) occurrence of a node matching the from pattern" are considered, and there is a possible interpretation that counting prior to the first from-node can proceed as normal. In other words, each from-node resets the counter but you can start counting without one. Nodes that "match the from pattern" are not considered for counting per se (but see below), but rather define the range of nodes over which scanning for countable nodes will take place. But does lack of a from-node (so far) mean no range? For the other kinds of level, there is no erratum to date. See the Xalan test numbering20 for level="single" and numbering19 for level="multiple", neither having count specified. I will quote the Rec, but insert tags <A>, <B>, etc. for later reference. When level="single", it goes up to the <A>first node in the ancestor-or-self axis that matches the count pattern</A>, and constructs a list of length one containing one plus the number of preceding siblings of <B>that ancestor</B> that match the count pattern. If there is no <C>such ancestor</C>, it constructs an empty list. If the from attribute is specified, then the only <D>ancestors</D> that are searched are those that are descendants of the nearest <E>ancestor</E> that matches the from pattern. Preceding siblings has the same meaning here as with the preceding-sibling axis. By the rules of ordinary English, we can deduce that references <B> and <C> actually mean "node on the ancestor-or-self axis" rather than simply "ancestor", but what about <D> and <E>? Actually, the main concern is for level="multiple", which has the same sentence about from, with <D> and <E> in it. Two questions arise. Larger question: does the lack of an ancestor(-or-self?) matching the from pattern mean (1) do what you do for an empty list, (2) put out no characters because the xsl:number instruction is moot, or (3) number as usual because the from-node is a reset to the counter? Smaller question: what should be done when a node matches both from and count? (See Xalan test numbering63, which has <xsl:number level="single" from="a" count="a|b|c|d|e" format="1"/> in the stylesheet and has <a> elements in its input data.) Referring back to the quote from the spec, note the word "descendants" rather than "elements on the descendant-or-self axis" between <D> and <E>. That's the difference between a count of 0 and 1 when an <a> is encountered. In summary, we want to know the prescribed counting result before the first occurrence of a from-node, and when the count-node is also the from-node. If the level attribute makes a difference, we want to know the required behavior for each kind of level. .................David Marston
Received on Saturday, 26 October 2002 09:35:28 UTC