[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comparison of hoffman-idn-reg and jseng-idn-admin



On Tue, 1 Apr 2003, Paul Hoffman / IMC wrote:

> >2. Clear language about conflict resolution. There needs to be some clear
> >guidelines or recommendations about the times that two registered labels
> >come into an intersection regarding the variant labels associated to them.
> >This will happen with almost any multi-language Arabic-script zone
> >(e.g. U+0649 vs U+064A vs U+06CC).
> 
> I am unclear on how this differs from point #1. If any of those three 
> characters are supposed to only be represented by one of them in 
> names, then the registry-specific early mapping step will take care 
> of them. Or is that not what you are referring to? Please be more 
> specific.

I am talking about two main labels that are not variants of each other, 
but share a variant. For example, a multilanguage zone that support both 
Arabic and Persian will have something like this in its equivalence data 
table:

U+0649|U+06CC
U+064A|U+06CC
U+06CC|U+0649;U+064A

The first two characters are only used in the Arabic languages, and the
third is only used in Persian. The above data is necessary if you want 
to distinguish the first two (that are distinguished in Arabic), but avoid 
security problems (U+06CC looks *identical* to U+0649 in isolated and 
final contextual forms, and *identical* to U+064A in medial and initial 
forms).

Now, when one registers a label with a U+0649 and someone else goes with a
U+064A, who will own the U+06CC version?

> - the merging is a policy decision by the registry at the time of 
> table-making as to which language "wins" for the overlapping 
> characters

Or which character wins, or which registrant wins, or which orthography 
wins...

> - it is impossible to register without knowing the supposed language 
> of the registration
>
> I can add more discussion of that, but the third option is not 
> "merging", it is forcing the problem on the registrant (who might be 
> sly and use it as a way to make the bundle contain things that the 
> registry might not have intended). From my reading of the JET 
> document, they call the third option "merging" when in fact it is 
> just the opposite: it prevents merging by pointing at one table.

I like to see a standard that limits each zone to a specific *language*,
but I guess that can't happen in situations like a Swiss or European zone.

But also, I like to see a nice mechanism or some guideline for a Swiss 
registry: "Grab the Italian, French, and German and merge them 
according to the following guidelines." The guidelines may require a 
language priority list or whatever, but it should be usable in a 
semi-automatic way.

roozbeh