This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29761 - [FO31] width modifier (again)
Summary: [FO31] width modifier (again)
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.1 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2016-07-29 16:18 UTC by Tim Mills
Modified: 2016-09-13 15:09 UTC (History)
0 users

See Also:


Description Tim Mills 2016-07-29 16:18:29 UTC
The text says.

"Whether or not a presentation modifier is included, a width modifier may be supplied. This indicates the number of characters to be included in the representation of the value."

Just to clarify, do ALL characters contribute to the computation of width, or just numeric characters.

e.g.  does -123 have width 4 or 3.

I'm particularly thinking of tests such as "format-date-045"

format-date(xs:date('2016-01-01'), '[Y#.0,1-4]')

which expects "".

That said, the text also says

"If the decimal digit pattern includes a grouping separator, the output is implementation-defined"

so this test and similar ones should probably go anyway.
Comment 1 Michael Kay 2016-09-06 21:30:03 UTC
I think that the detailed rules are unambiguous, though the summary cited is imprecise.  The rules say:

(a) if there are grouping separators, all bets are off

(b) otherwise, the width modifier causes the picture to be adjusted in a defined way and the rules of format-number then apply. For example Y99,4-4 is adjusted to Y9999.

(c) minus signs don't come into it: none of the integer-valued components formatted by the date formatting functions is ever negative