22524 2013-07-01 13:46:23 +0000 [XT3TS] number-0819, 0821 2015-05-17 21:01:22 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Test Suite Last Call drafts PC Windows NT RESOLVED FIXED P2 normal --- 1 tim abel.online abel.braaksma mike public-qt-comments oldest_to_newest 90054 0 tim 2013-07-01 13:46:23 +0000 Test number-0819 format numbers using Unicode circled digits. However, the expected result starts with 0 (&#x30), not a circled zero (&#x2460). There is a similar problem in number-0821. 97184 1 abel.braaksma 2013-12-05 16:29:54 +0000 The number CIRCLED DIGIT ZERO is not consecutively before the CIRCLED DIGIT ONE in the Unicode codepoints. I.e., ZERO is at U+24EA and ONE is at U+2460. However, the Unicode spec makes clear that these are part of a range. I think therefor that the test output is in order if "0" is replaced with U+24EA, but would like to hear the WG consensus of this. 97189 2 mike 2013-12-05 17:57:25 +0000 The XSLT 3.0 spec for xsl:number in 12.3 says For example, the formatting token &#x2460; (circled digit one) has a range of 1 to 20 imposed by the Unicode character repertoire. But F+O 3.0 for format-integer has correctly updated this to: For example, the format token &#x2460; (circled digit one, ①) has a range imposed by the Unicode character repertoire — 1 to 20 in Unicode versions prior to 4.0, increased in subsequent versions. In both cases it's only an example, therefore non-normative, but we should fix the XSLT version of the text, and recognize that Unicode now has a circled zero, which should probably be used in this test. 118733 3 mike 2015-03-20 15:43:18 +0000 I have modified the XSLT 3.0 text to match the F+O text as suggested. 119042 4 abel.braaksma 2015-03-30 00:52:06 +0000 Tim Mills wrote: > expected result starts with 0 (&#x30), not a circled zero (&#x2460). Michael Kay wrote: > For example, the format token &#x2460; (circled digit one, ①) has a range > imposed by the Unicode character repertoire — 1 to 20 in Unicode versions > prior to 4.0, increased in subsequent versions. However, CIRCLED DIGIT ONE is U+2460, ZERO is U+24EA. They are not consecutive. Both have been around since Unicode 1.1. Are we suggesting here that the outcome from a processor should (optionally?) be: <out> 0 ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑪ ⑫ ⑬ ⑭ ⑮ ⑯ ⑰ ⑱ ⑲ ⑳ 21 22 23 24 25</out> Or: <out> ⓪ ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑪ ⑫ ⑬ ⑭ ⑮ ⑯ ⑰ ⑱ ⑲ ⑳ 21 22 23 24 25</out> Or even: <out> ⓪ ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑪ ⑫ ⑬ ⑭ ⑮ ⑯ ⑰ ⑱ ⑲ ⑳ ㉑ ㉒ ㉓ ㉔ ㉕</out> Numbers up to 50 have been supported since Unicode 3.3. These ranges are not consecutive: 0: 24EA (since 1.1, 1993) 1-20: 2460 - 2473 (since 1.1, 1993) 21-35: 3251 - 325F (since 3.2, 2002) 36-50: 32B1 - 32BF (since 3.2, 2002) So for these Unicode ranges in particular, it is incorrect that only 1 to 20 existed in Unicode prior to 4.0. All these circled digits where added earlier. This means that the sentence in the XSLT 3.0 spec is possibly incomplete: "For example, the formatting token &#x2460; (circled digit one) has a range of 1 to 20 imposed by the Unicode character repertoire." I am not sure how to move forward. Since these ranges fall under implementation-defined behavior (and add to that the supported Unicode version is implementation-defined as well), I don't think there's anything we can force here, so I propose that the result of the test should iterate these alternatives. 120330 5 abel.braaksma 2015-05-17 21:00:39 +0000 I've moved forward and implemented a solution, essentially: * added new dependency enum values for numeric formatting * added range dependency to indicate supported ranges * fixed the test by allowing alternate outcomes * fixed the test by adding (new) dependencies In addition, I added a bunch of tests for other No category numbers that have a more or less natural formatting range implied by the Unicode spec.