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

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 Saturday, 26 October 2002 09:35:35 UTC