OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xslt-conformance message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [xslt-conformance] xsl:number issue: when to render a zero






The following issue is exemplified by several of the Xalan numbering
tests, but numbering62 illustrates it especially well. The input has
the familiar structure of b inside a, c inside b, etc. and each has a
<title> sub-element that we want to number. We say
<xsl:number level="single" from="b" count="c" format="1"/>
and that infernal from attribute causes the creation of an empty list
in some cases.

The same situation has been noted in numbering22, numbering31,
numbering66, numbering71, and others. First issue: do we emit a zero
or null string? Second issue: if there is a format that specifies
prefix and suffix strings, should they be suppressed when and if we
choose the null string?

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. I suspect that the business about a "list of
numbers" to be formatted is intended to deal with the right side.

Incredibly, the spec provides very thin guidance:
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....
and that's all he wrote. At least the quotes above are in sequence!

As I read it, the empty list is a dead end. It is not converted to a
string, and you only get the prefix/suffix if you generate a string.
Jonas Sicking disagrees, citing the "first token...last token" part
above.

I'm concerned that it says "The numbers are integers greater than 0"
as if the previous verbiage guarantees that will be the case. In fact,
that sentence may serve to clarify some of the "ancestors that are
searched" type of verbiage back in 7.7!

What do you think, and why?
A) It should be (); anything gets formatted
B) It should be (0); 0 is the size of an empty list
C) It should be the null string; only non-empty lists are stringified
D) Different answers for level="multiple" and level="single|any"
   SPECIFY WHICH ANSWER FOR EACH CASE
E) Some other output?
F) Must refer this to the XSL WG for resolution

Of course, we could refer just level="single|any" to the WG if we think
we answered level="multiple" on our own, or vice versa.
................David Marston



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC