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).
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,
2011/9/1 Karl Williamson pub...@khwilliamson.com:
Unicode 6.0 broke UTS #18, which since 1999 has suggested that BELL be the
name used in regular expressions for U+0007. In 2003, this was strengthened
to should be used. The breakage occurred by requiring that BELL instead
be the name for a
On Wednesday 31 August 2011, Doug Ewell d...@ewellic.org wrote:
Coming back full circle, this is where many of the PUA protests on this list
come from -- some folks want to use the Unicode PUA to encode things that are
not characters, not even glyphs or symbols, nor anything else remotely
On 8/31/2011 11:25 PM, Philippe Verdy wrote:
2011/9/1 Karl Williamsonpub...@khwilliamson.com:
But now that I'm an UTC member, I hope I will hear these cases earlier...
Congratulations!
Does it justify so many new aliases at the same time ?
No. I'm firmly with you, I support the
So now we completely agree. Thanks.
2011/9/1 Asmus Freytag asm...@ix.netcom.com:
On 8/31/2011 11:25 PM, Philippe Verdy wrote:
2011/9/1 Karl Williamsonpub...@khwilliamson.com:
But now that I'm an UTC member, I hope I will hear these cases earlier...
Congratulations!
Does it justify so many
For your information, here is a copy of a recent post I made privately
with an existing UTC member.
===
I just posted two new feedbacks (using the feedback form) related to
the proposed alias names. These feedbacks are all related to recent
decisions taken this year (in February) after a PRI...
The solution would have been easy:
- use www.example.org for the generic site
- use www.en.example.org for the English-language site
- use www.fr.example.org for the French-language site
- use www.www.example.org (and only that) for the Wawa site
No need for private-use identifiers here. (I
2011/8/31 Doug Ewell d...@ewellic.org:
The solution would have been easy:
- use www.example.org for the generic site
- use www.en.example.org for the English-language site
- use www.fr.example.org for the French-language site
- use www.www.example.org (and only that) for the Wawa site
No
Philippe Verdy verdy underscore p at wanadoo dot fr wrote:
No need for private-use identifiers here. (I agree that coding
standards like 639 should have private-use areas, but not to extend the
standard beyond its intended scope as Philippe suggests in his last
paragraph.)
I've not
2011/8/31 Doug Ewell d...@ewellic.org:
Philippe Verdy verdy underscore p at wanadoo dot fr wrote:
No need for private-use identifiers here. (I agree that coding
standards like 639 should have private-use areas, but not to extend the
standard beyond its intended scope as Philippe suggests in
Philippe Verdy verdy underscore p at wanadoo dot fr wrote:
That would be extending the use of ISO 639 beyond identification of
languages.
Nothing is extended, there already exists private-use codes in ISO 639
(e.g. qaa-qtz).
Extending conceptually, not architecturally. Yes, the
2011/8/31 Doug Ewell d...@ewellic.org:
Or you could actually follow BCP 47, and use x-www instead.
No, because locale tags in BCP 47 starting by the x singleton
subtags are not parsable to differentiate a language, a region, and a
script (as well as other Unicode u extensions). They just
2011/8/31 Doug Ewell d...@ewellic.org:
Philippe Verdy verdy underscore p at wanadoo dot fr wrote:
That would be extending the use of ISO 639 beyond identification of
languages.
Nothing is extended, there already exists private-use codes in ISO 639
(e.g. qaa-qtz).
Extending conceptually,
Philippe Verdy wrote:
Or you could actually follow BCP 47, and use x-www instead.
No, because locale tags in BCP 47
BCP 47 specifies language tags. They are sometimes used to identify
locales, but that is not their primary use case.
starting by the x singleton
subtags are not parsable to
2011/8/31 Doug Ewell d...@ewellic.org:
Philippe Verdy wrote:
the existing
BCP 47 implementations, but that would limit the may-be future
extension of ISO 639 to longer codes): ISO 639 could immediately say
that it will never allocate any language code (of any length) starting
by qa..qz.
On 08/30/2011 06:27 PM, Philippe Verdy wrote:
After looking at the effective reason why this PRI #202 emerged (a
request from Perl authors), exposed in UTC document number
L2/2011/11281, I think now that even *all* these aliases were not
needed.
The bug emerged in Perl only because a character
After looking at the effective reason why this PRI #202 emerged (a
request from Perl authors), exposed in UTC document number
L2/2011/11281, I think now that even *all* these aliases were not
needed.
The bug emerged in Perl only because a character named BELL was
added, entering in conflict with
2011/8/27 Asmus Freytag asm...@ix.netcom.com:
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
Philippe Verdy wrote:
If there are other mappings to do with other standards, and those
standards must be only informative, we already have the /MAPPINGS
directory beside the /UNIDATA directory where the UCD belongs too.
But in general, with the exception of MAPPINGS/VENDORS/MISC/SGML.TXT,
On 8/28/2011 9:46 PM, Doug Ewell wrote:
Philippe Verdy wrote:
If there are other mappings to do with other standards, and those
standards must be only informative, we already have the /MAPPINGS
directory beside the /UNIDATA directory where the UCD belongs too.
But in general, with the
On 8/28/2011 6:43 PM, Philippe Verdy wrote:
2011/8/27 Asmus Freytagasm...@ix.netcom.com:
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
On 8/26/2011 10:09 PM, Philippe Verdy wrote:
2011/8/27 Asmus Freytagasm...@ix.netcom.com:
I agree with Ken that Phillipe's suggestion of conflating the annotations
for mathematical use with formal Unicode name aliases is a non-starter.
Yes but why then adding ISO 6429 alias names ? What makes
On 8/26/2011 7:52 PM, Benjamin M Scarborough wrote:
Are name aliases exempted from the normal character naming conventions? I ask
because four of the entries have words that begin with numbers.
008E;SINGLE-SHIFT 2;control
008F;SINGLE-SHIFT 3;control
0091;PRIVATE USE 1;control
0092;PRIVATE USE
It would have the advantage of suppressing those names from the
proposed table for UTR #25 (characters used in Mathematical
notations).
In the merged name aliases table, we could as well include :
- SGML/HTML/XML character entity names (and some standardized synonyms) ?
HTML character
On 27 August 2011 03:52, Benjamin M Scarborough
benjamin.scarboro...@utdallas.edu wrote:
Are name aliases exempted from the normal character naming conventions? I ask
because four of the entries have words that begin with numbers.
008E;SINGLE-SHIFT 2;control
008F;SINGLE-SHIFT 3;control
On 8/27/2011 1:31 AM, Andrew West wrote:
On 27 August 2011 09:25, Andrew Westandrewcw...@gmail.com wrote:
On 27 August 2011 03:52, Benjamin M Scarborough
benjamin.scarboro...@utdallas.edu wrote:
Are name aliases exempted from the normal character naming conventions? I ask
because four of
for links to discussion and relevant documents. Briefly,
the new issue is:
PRI #202: Extensions to NameAliases.txt for Unicode 6.1.0
Isn't there an intersection between NameAliases.txt proposed in
PRI202, and the informational table defined for UTR #25 at
http://www.unicode.org/Public/math/revision-12
On 8/26/2011 3:13 PM, Philippe Verdy wrote:
Isn't there an intersection between NameAliases.txt proposed in
PRI202, and the informational table defined for UTR #25 at
http://www.unicode.org/Public/math/revision-12/MathClassEx-12.txt
which also lists other name aliases for other standards ?
No.
2011/8/27 Ken Whistler k...@sybase.com:
On 8/26/2011 3:13 PM, Philippe Verdy wrote:
Isn't there an intersection between NameAliases.txt proposed in
PRI202, and the informational table defined for UTR #25 at
http://www.unicode.org/Public/math/revision-12/MathClassEx-12.txt
which also lists
On 8/26/2011 5:01 PM, Philippe Verdy wrote:
we could as well include... are dangerous words here. Going encyclopedic
is*completely* at odds with the normative intention of NameAliases.txt.
Your statement then contradicts what PRI 202 says:
the intent is to add various standard and de facto
Are name aliases exempted from the normal character naming conventions? I ask
because four of the entries have words that begin with numbers.
008E;SINGLE-SHIFT 2;control
008F;SINGLE-SHIFT 3;control
0091;PRIVATE USE 1;control
0092;PRIVATE USE 2;control
—Ben Scarborough
I agree with Ken that Phillipe's suggestion of conflating the
annotations for mathematical use with formal Unicode name aliases is a
non-starter. The former exist to help mathematicians identify symbols in
Unicode, when they know their name from entity lists. The latter are
designed to allow
2011/8/27 Asmus Freytag asm...@ix.netcom.com:
I agree with Ken that Phillipe's suggestion of conflating the annotations
for mathematical use with formal Unicode name aliases is a non-starter.
Yes but why then adding ISO 6429 alias names ? What makes ISO 6429 a
better choice than another ISO
2011/8/27 Ken Whistler k...@sybase.com:
Was there such formal request from the ISO standard maintainers, and
an agreed policy ?
It has nothing to do with ISO standard maintainers.
And yes, there was a formal request to do something about this problem,
but it came from one of the maintainers
35 matches
Mail list logo
