W3C home > Mailing lists > Public > public-qt-comments@w3.org > July 2005

[Bug 1813] New: Does format-number still need notion of overflow?

From: <bugzilla@wiggum.w3.org>
Date: Mon, 25 Jul 2005 00:33:04 +0000
To: public-qt-comments@w3.org
Cc:
Message-Id: <E1Dwqu0-0008S5-54@wiggum.w3.org>

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

           Summary: Does format-number still need notion of overflow?
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Platform: All
        OS/Version: All
            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


As you know, I wrote the original text for part 16.4 (number Formatting) in 
XSLT 2.0, and I included the notion of an overflow threshold. This notion came 
from older languages that format data by means of a picture string. The 4 April 
2005 draft continues to have a definition of the concept and a formula for 
determining that overflow has occurred, but step 5 of the formatting procedure 
in 16.4.4 seems to make it moot. Step 5 says in essence that a picture like
0000
is really
#0000
(and of course #0000 is really ##0000 or ###0000 or whatever it takes). In that 
case, why bother to define overflow? Why not rewrite step 5 to simply mention 
that numbers can grow leftward as much as necessary?

Alternatively, why not revive the notion of overflow, which will be familiar to 
some people and serves a useful purpose? I suppose the WG has already voted 
that one off the table. If it were revived, people who wanted overflow fillers 
would have a way to express it (0000), while people who wanted leftward growth 
as needed would still have a way to have a minimum number of places (#0000).
Received on Monday, 25 July 2005 00:33:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:25 UTC