29615 2016-05-07 11:29:41 +0000 [F+O 3.1] roman and max-width year 2016-07-21 14:19:57 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Functions and Operators 3.1 Working drafts PC Linux CLOSED FIXED P2 normal --- 1 benito jonathan.robie abel.braaksma andrew_coleman josh.spiegel liam mike public-qt-comments oldest_to_newest 126366 0 benito 2016-05-07 11:29:41 +0000 Comment 10 in #29555 seems as if it could just as well apply to years that then are formatted Roman numbers. Printing 2007 with '[Yi,3-3]' as vii instead as mmvii like in test case format-dateTime-006 126367 1 mike 2016-05-07 16:38:07 +0000 So how would you use that rule to format the year 1999? I don't think years in roman numerals have ever been expressed modulo 100, and if they had, you couldn't express the requirement to do so by means of a minimum or maximum width. 126368 2 benito 2016-05-07 21:23:09 +0000 999 ? cmxcix Makes as much sense as truncating year 654321 to 54321 with max width 5 126389 3 josh.spiegel 2016-05-09 15:45:13 +0000 The point of the truncation logic is to get the year to fit within the maximum width. format-date(xs:date("1998-01-01"), "[Y,2-2]") => 98 format-date(xs:date("1999-01-01"), "[Y,2-2]") => 99 If we applied this logic in the case of roman numerals, it would fail to print a value within the maximum width in many cases. format-date(xs:date("1998-01-01"), "[Yi,2-2]") => xcviii (instead of mcmxcviii) format-date(xs:date("1999-01-01"), "[Yi,2-2]") => xcix (instead of mcmxcix) And in some cases it will unnecessarily truncate the value. format-date(xs:date("0101-01-01"), "[Yi,2-2]") => i (instead of ci) 126390 4 liam 2016-05-09 18:10:45 +0000 On the whole people working with Roman numerals and fixed-width fields are in for a hard time, and will probably use string processing to do what they need. It seems specialist enough that I've no clue how to predict a "majority" use case. Josh's result - apply the width in decimal before conversion - and Benito's - apply the width in characters after conversion - both seem plausible and I don't see any reason to prefer one over the other in general. Benito, when you opened this bug you didn't say that anything was wrong, nor what goes wrong, nor what you think ought to happen. Is anything wrong with the spec here? 126392 5 benito 2016-05-09 19:37:57 +0000 I implemented comment 10 of #29555 and afterwards that test case failed The comment says to truncate the year if there is a max width without exception The specs says somewhere >If no mechanism is available for fitting the value within the specified maximum width (for example, when roman numerals are used), then the value should be output in its full representation. but the comment provides a mechanism for the year and it gets shorter, even if it stays too long. 126393 6 benito 2016-05-09 19:44:35 +0000 >Josh's result - apply the width in decimal before conversion - and Benito's - apply the width in characters after conversion - both seem plausible You switched me and Josh 126769 7 abel.braaksma 2016-06-14 16:36:52 +0000 Please note that we currently say the following already about roman numerals and the width modifier: "If no mechanism is available for fitting the value within the specified maximum width (for example, when roman numerals are used), then the value should be output in its full representation." 126770 8 abel.braaksma 2016-06-14 16:43:24 +0000 (which typically means that implementations are allowed to do as they wish if they feel that there is such mechanism, making it implementation-defined what happens if you try to truncate roman numerals, but the suggestion of the text, by means of "should", is to do nothing in such cases) 126789 9 andrew_coleman 2016-06-17 10:20:57 +0000 At the meeting on 2016-06-14, the WG discussed this and acknowledge the comment. This will be used as input to the existing action item A-643-01 (MikeK to update proposal on Bug 29555)