[Bug 27060] New: [xslt 3.0] xsl:number level="multiple" start-at="3"

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27060

            Bug ID: 27060
           Summary: [xslt 3.0] xsl:number level="multiple" start-at="3"
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: mike@saxonica.com
          Reporter: mike@saxonica.com
        QA Contact: public-qt-comments@w3.org

This is prompted by a suggestion on StackOverflow to use xsl:number/@start-at
where it doesn't actually do what the respondent wanted to achieve, namely (b)
below.

There are three potential uses for start-at with level="multiple".

(a) where you want numbering at every level to start at zero, e.g.

0.0, 0.1, 0.2, 1.0.0, 1.0.1 etc

(b) where you want the top-level number to start at something greater than one,
typically because you are only processing one chapter of a document:

3.1.1, 3.1.2, 3.2., 3.2.1 etc

(c) where for some reason different levels start at different points, e.g.

1.x, 1.y, 1.z

1.0.1, 1.0.2, 1.1.1, 1.1.2

Our current spec only allows for (a). People might be a little surprised if
they say level="multiple" start-at="3" and get

3.3.3, 3.3.4, 3.4.3, 3.5, 3.6.3

when they were expecting

3.1.1, 3.1.2, 3.2.1, 3.3, 3.4.1

I think it would be much more useful to specify a list of numbers, representing
the start point for each level. Corresponding to the existing convetion for the
format attribute, if the list is shorter than the number of levels, the last
number in the list would be used (which falls back to the current spec if there
is only one number in the list).

So for (a) you would specify start-at="0", for (b) you would specify
start-at="3.1", for (c) you would specify start-at="1.24". (Or we could be more
friendly and make it start-at="1.x", i.e. use the formatted representation
rather than the unformatted).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 15 October 2014 15:50:10 UTC