[Bug 3326] Ambiguity regarding non-alphanumeric format tokens, xsl:number

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3326

           Summary: Ambiguity regarding non-alphanumeric format tokens,
                    xsl:number
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Platform: PC
        OS/Version: Windows 2000
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 2.0
        AssignedTo: mike@saxonica.com
        ReportedBy: david_marston@us.ibm.com
         QAContact: public-qt-comments@w3.org


The 4th paragraph of 12.3 indicates that xsl:number could make assumptions
about format tokens and separator tokens. This gives rise to some format
possibilities lacking both:
format=""
format="()" and similar.

The 3rd paragraph must make an explicit statement the latter. (The 4th tells us
enough to know that the former defaults as "1.1.1.1.1.1" of sufficient length
to handle the longest sequence.) When the format attribute consists of only
non-alphanumeric characters, is that sequence:
just the prefix?
just the suffix?
an error?
Being an error is plausible, since the string is NOT any of:
before a format token
after a format token
between two format tokens
Being only a prefix is mildly useful for symbols like #, but not so remarkably
convenient (compared to "#1") that we should encourage users to think that way.
Being only a suffix seems less useful. Being both prefix and suffix is useless
and also violates the string-is-only-used-once verbiage.

Therefore, I suggest that adding a new error message, something like "format
string has no alphanumeric fields", is the best resolution. (I recognize that
any alphanumeric suffices, even if it is one not supported by the
implementation. Unsupported alphanumerics revert to being placeholders for 1,
not being prefix/separator/suffix.)

As an aside: I am unhappy that the 3rd paragraph does not come right out and
say that the empty sequence is formatted as the prefix and suffix adjacent. In
1.0, this was an area of ambiguity.

Received on Monday, 12 June 2006 21:41:39 UTC