Re: PRI #202: Extensions to NameAliases.txt for Unicode 6.1.0

From: Asmus Freytag <>
Date: Sun, 28 Aug 2011 22:25:26 -0700

On 8/28/2011 6:43 PM, Philippe Verdy wrote:
> 2011/8/27 Asmus Freytag<>:
>> I also think that the status field "iso6429" is badly named. It should be
>> "control", and what is named control should be "control-alternate", or
>> perhaps, both of these groups should become simply "control". I think the
>> labels chosen by the data file just set up bad precedents. If 6429, why not
>> a section for 9535 (or whatever the kbd standard is) etc.
> Thanks a lot for admitting what I was trying to demonstrate to you in a
> prior message (which was early dismissed as a complete "non-starter").

You appeared to be making a non-starter proposal, rather than clearly
making a hypothetical proposal designed only to showcase certain logical
flaws in the PRI. If the latter was your intention, well we
misunderstood you, but everybody seems to be on the same page, which is
> I lso think that there are too many aliases for controls, if the only
> need is for Perl to have a name to uniquely designate those controls.
> Choose one alias name, but there's absolutely no emergency for now for
> adding four aliases at once for them, when there's no demonstration
> that all those aliases are needed! This is just unnecessary pollution
> of the UCS namespace.

I tend to agree - however, I do think giving the common abbreviations
some formal status is useful.

If I remember correctly, even in Perl there were some names that are
legacy names. If programs other than Perl have an active need to support
legacy names, then I would favor adding these one-by-one as demonstrated
needs arise, but NOT wholesale, just because they existed in 6429 in
some version.

Now, here's a subtle point: adding certain alias strings to the file is
a cheap way for the editing tools that verify the uniqueness of the
namespace to "reserve" a name (so it can't ever be given to a different
character). Kind of like what happened to "BELL". I bet a big motivation
behind the long list (all for control codes) was to prevent any
non-control code from ever getting a name that happens to match a known
control code name.

While I appreciate that sentiment, I think this part of the proposal
should not be rushed - aliases are forever, and warehousing all known
obsolete names for control codes is a bit bizarre. I think you and I are
possibly in agreement on that.

> If there are other mappings ...

I've replied on the issue of mappings in reply to Doug's message.

Received on Mon Aug 29 2011 - 00:27:25 CDT

This archive was generated by hypermail 2.2.0 : Mon Aug 29 2011 - 00:27:26 CDT