RE: [OT] Reusing the same property (was: RE: PRI #202: Extensions to NameAliases.txt for Unicode 6.1.0)

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 suggested that.

Oh, gosh: "But this also mean that any well-behaved standard *unified*
namespace has to include a private-use space, as it allows integration
and coexistence with other standards or applications initially not
designed to identify the same thing (for example, here mixing the
identification of a language, and the identification and addressing of
an Internet host)"

That would be extending the use of ISO 639 beyond identification of
languages.

> he scope of ISO 639 remains exactly the same
> even if it reserves a private-user area, that it does not need to
> specify. Much like in ISO 3166 with its private use codes.

ISO 639 private-use code elements are still supposed to represent
"languages" according to some interpretation. Similarly for ISO 3166
and countries; people often create ISO 3166-1 private-use code elements
for geographic regions or international organizations, but at least this
is sort of within scope, whereas a code element to represent, say, a
political party or company would not be.

Where private-use goes over the edge is when it is used to represent
things that were never intended to be represented by the base standard.
Using ISO 639 code elements to encode Web protocols, Web hosts, or
anything else that is not even close to "language" is out of scope.

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 resembling the intended scope of the Unicode Standard.

> I maintain that *any* standard that wants to unify past standards,
> needs a private-use area (this includes the UCS of course). This is
> architectural and needed for long-term stability of the standard
> itself, as a solution against many incompatible variations (called
> "hacked encodings"), something that has occured a lot before the
> creation and unification of the UCS, creating a nightmare of
> ambiguities for transcoders: it's safer to isolate those few needed
> deviations in a space that will manage those exceptions, and for which
> unified solutions will emerge later as part of the core standard.

No argument there, except "will emerge" should probably be "may emerge."

--
Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
www.ewellic.org | www.facebook.com/doug.ewell | @DougEwell ­