[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