[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