RE: Request clarification/erratum regarding empty lists and zero values in xsl:number

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
>