[SG16-Unicode] Feedback on P1139: Address wording issues related to ISO 10646
martinho.fernandes
martinho.fernandes at native-instruments.de
Tue Feb 5 11:45:46 CET 2019
> I am not certain what the text is meant to say.
> Is the intention merely that the numeric value shall be within the UCS
> codespace (0x0-0x10FFFF, inclusive)?
> Is the intention that the code point shall be one of those that are
> assigned to characters by ISO/IEC 10646 (in which case, the additional
> limitation on surrogate code points is redundant)?
> Is the intention that the code point shall not be one whose basic type is
> the noncharacter type?
Jens is correct; the only limitation intended is constraining the range
of values to 0..D7FF + E000..10FFFF (i.e. 0..10FFFF with surrogates
carved out). I should not have used "character" there. The note uses
correct unambiguous wording with "ISO/IEC 10646 code points", so I will
rephrase the normative text as follows.
> If a /universal-character-name/ does not correspond to a code point
> in ISO/IEC 10646 or if a /universal-character-name/ corresponds to a
> surrogate code point [...]
Note that I omitted the notes here for brevity and clarity; I think they
should remain.
Once I have updated the paper I will put it on the wiki (and also
include the changes from the PR directly in the paper so it is
self-contained)
--
Martinho Fernandes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x80FBF70BC6F44BE8.asc
Type: application/pgp-keys
Size: 18600 bytes
Desc: not available
Url : http://www.open-std.org/pipermail/unicode/attachments/20190205/008f175f/attachment-0001.bin
More information about the Unicode
mailing list