This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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).
You're right. When we decided that overflow would no longer be an (optionally) recoverable error, but that processors would instead always take the recovery action, I implemented the decision by making the minimal necessary changes to the text. It seems that the algorithm produces the same results if the third bullet of 16.4.3 and list item 5 in 16.4.4 are deleted, so I will do this. Since this change does not affect the semantics of the language, I will treat it as editorial. I will mark the issue as fixed, and assume your tacit approval; you (or any WG member) can reopen the bug if you feel that further discussion is required. Michael Kay