Corrigendum #9

[Shawn Steele]

Ø  I can't shake the suspicion that Corrigendum #9 is not actually solving a general problem, but is a special favor to CLDR as being run by insiders, and in the process muddying the waters for everyone else

I think we could generalize to other scenarios so it wasn’t necessarily an insider scenario.  For example, I could have a string manipulation library that used FFFE to indicate the beginning of an identifier for a localizable sentence, terminated by FFFF.  Any system using FFFEid1234FFFF would likely expect to be able to read the tokens in their favorite code editor.

But I’m concerned that these “conflict” with each other, and embedding the behavior in major programming languages doesn’t smell to me like “internal” use.  Clearly if I wanted to use that library in a CLDR-aware app, there is a potential risk for a conflict.

In the CLDR case, there *IS* a special relationship with Unicode, and perhaps it would be warranted to explicitly encode character(s) with the necessary meaning(s) to handle edge-case collation scenarios.

-Shawn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20140602/645d662c/attachment.html>