- From: Kay, Michael <Michael.Kay@softwareag.com>
- Date: Sun, 27 Oct 2002 15:03:20 +0100
- To: David Marston/Cambridge/IBM <david_marston@us.ibm.com>, xsl-editors@w3.org
- Cc: xslt-conformance@lists.oasis-open.org
I should have made clear that the previous response was a personal one. I hope you will get a formal response from the WG in due course - but it will take longer. Michael Kay > > > 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. > > In the xsl:number counting system, it is possible to derive a > zero, particularly when the from attribute is used to limit > the range of consideration for counting. It is also possible > to use the value attribute to assign a zero, NaN, or string > that will become NaN through round-tripping. (One must follow > Erratum E24 to see that string==>number==>string is prescribed.) > > In some cases, numbering must be based on an empty list. When > should a null string be the result, rather than a zero? > (Examples from the Xalan test suite: numbering62 is clearest, > numbering22, numbering31, numbering66, numbering71, and others.) > > When a null string is the counting resultor "NaN" is > assigned, should the prefix and suffix tokens from the > pattern be emitted on the output? > > There is a hidden issue here: should level="multiple" get > special rules? Consider the classic document hierarchy of > document/chapter/section/subsection (nested in that order), > each except <document> having a <title> to be numbered. You > want 2. Second Chapter Title 2-1. First Section in Second > Chapter 2-1-1. First Subsection in First Section in Second > Chapter and the like. Isn't it reasonable to have a section > heading in the beginning? It could look like: 0-1. First > Section in Preface The dilemma here is that the number for > the chapter level (0, since we haven't hit a <chapter> node > yet) should be visible as zero, while the subsection number > should be suppressed as usual. In other words, we have > different rules governing the left (upper) and right (lower) > sides of the section number. > > The spec provides very thin guidance. Quoting in sequence: > "The xsl:number element first constructs a list of positive > integers... [mentions getting an empty list in some cases]... > The list of numbers is then converted into a string using the > attributes specified in 7.7.1...[now jump to 7.7.1, since > nothing more is in 7.7]... The following attributes are used > to control conversion of a list of numbers into a string. The > numbers are integers greater than 0.... If the first token is > a non-alphanumeric token, then the constructed string will > start with that token; if the last token is non-alphanumeric > token, then the constructed string will end with that token...." > > Does an empty list circumvent the whole 7.7.1 > conversion-to-string process? How about an NaN? In other > words, when does the 7.7.1 process with its format tokens > apply? Can you ever get the prefix and suffix tokens with > nothing between? > > The Erratum E24 (NaN) scenario may be addressed. Quoting the > erratum: "...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, the 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]..." This > could mean that insertion of the prefix/suffix tokens into > the result must not occur unless the value is a valid number. > It would be helpful to say explicitly whether the "resulting > string" above is the entire output of the xsl:number > instruction, and make the statement consistent with the > decision about the empty-list scenario. .................David Marston >
Received on Sunday, 27 October 2002 09:03:28 UTC