There are really a few purposes for this list. 1. Cover the aliases for a given character that are in *very* widespread use in the industry. 2. Cover the aliases for a given character that we have recommended that people use in UTS #18, for quite some time. 3. *Most importantly, reserve the names in #1 and #2 so as to prevent new characters from having colliding names.*
There is no intention of covering all possible aliases from any standard or usage, so the list has already been filtered down substantially. Mark *— Il meglio è l’inimico del bene —* On Fri, Sep 2, 2011 at 12:43, Benjamin M Scarborough < [email protected]> wrote: > On 2011.09.01 13:38, Asmus Freytag wrote: > >No. I'm firmly with you, I support the requirement for 1 (ONE) alias for > >control codes because they don't have names, but are used in > >environments where the need a string identifier other than a code point. > >(Just like regular characters, but even more so). > > > >I also support the requirement for 1 (ONE) short identifier, for all > >those control AND format characters for which widespread usage of such > >an abbreviation is customary. (VS-257 does not qualify). > > I think this is a sensible approach. NameAliasesProv-6.1.0d3.txt provides > SIX different aliases for U+000A ("LINE FEED," "NEW LINE," "END OF LINE," > "LF," "NL," and "EOL"), and I can't think of any good reason to have so many > different names attached to one character. > > I think this was a knee-jerk reaction to the addition of U+1F514 BELL, and > it feels like someone's trying to push it through with minimal scrutiny. I > think the ISO 6429 names are good enough (plus they're already in > UnicodeData.txt as the Unicode 1.0 names for those characters) and the extra > 'control' aliases are superfluous (except for U+0007, U+0084, and U+FEFF). > > At the very least, the 'control' aliases for U+008E, U+008F, U+0091, and > U+0092 should be removed immediately. They violate Unicode's naming > conventions and are hardly any different from the 'iso6429' aliases. > > I'm also not fond of adding all these abbreviations as aliases, but it's > not anything I'll lose sleep over. > > —Ben Scarborough > > >
