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 <
benjamin.scarborough_at_utdallas.edu> 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
>
>
>
Received on Fri Sep 02 2011 - 15:19:53 CDT
This archive was generated by hypermail 2.2.0 : Fri Sep 02 2011 - 15:19:56 CDT