[Neobrahmigp] [lgr] [ChineseGP] Question about coordination principles for C J and K

Kenny Huang, Ph.D. huangksh at gmail.com
Tue Oct 28 06:14:36 UTC 2014


Dear Asmus,

Thanks for your feedback, please see my comments below

Kenny Huang


> Dear Wang Wei,
>
> the way variants are defined for the integrated root zone LGR matches the
> second understanding - they are what you call "tightly coupled" in your
> document and it is not possible to have the und-Jpan LGR treat them as
> independent while the und-Hani LGR treats them as variants.
>
The presented sample table complies with the principles
(1)same variant mappings amount CJK (2)variant types (allocatable/block)
can be different.
in the case, und-Jpan treats them as "block variants" while und-Hani treats
them with (allocatable/block) variants.
>
>
>
> 2)       Opposite to the case 1, the other understanding is that “Variant
> mappings” is a tight coupled relationship which applies in all LGRs, and
> “Variant Type” must be ”allocatable” or “blocked”, illustrated by the
> following example:
>
>
>
> *Code Point*
>
> *Allocatable Variant*
>
> *Blocked Variant*
>
> *Tag*
>
> 一 (U+4E00)
>
> --
>
> 壱 (U+58F1)
>
> 壹 (U+58F9)
>
> 弌 (U+5F0C)
>
> und-hani
>
> 壹 (U+58F9)
>
> --
>
> 一 (U+4E00)
>
> 壱 (U+58F1)
>
> 弌 (U+5F0C)
>
> und-hani
>
> 弌 (U+5F0C)
>
> 一(U+4E00)
>
>
>
> 壹 (U+58F9)
>
> 壱 (U+58F1)
>
> und-hani
>
> 壱 (U+58F1)
>
> 壹(U+58F9)
>
> 一 (U+4E00)
>
> 弌 (U+5F0C)
>
> und-hani
>
> 一 (U+4E00)
>
> --
>
> 壹 (U+58F9)
>
> 弌 (U+5F0C)
>
> 壱 (U+58F1)
>
> und-Jpan
>
> 壹 (U+58F9)
>
> --
>
> 一 (U+4E00)
>
> 弌 (U+5F0C)
>
> 壱 (U+58F1)
>
> und-jpan
>
> 弌 (U+5F0C)
>
> --
>
> 一 (U+4E00)
>
> 壹 (U+58F9)
>
> 壱 (U+58F1)
>
> und-jpan
>
> 壱 (U+58F1)
>
> --
>
> 一 (U+4E00)
>
> 壹 (U+58F9)
>
> 弌 (U+5F0C)
>
> und-jpan
>
>  In this table, no matter what language tag was set, for any given code
> point in a variant mapping cluster, its variants must be configured to
> either “allocatable” or “blocked”, its variants cannot stay as an
> INDEPENDENT code point, regardless of the fact that in Japanese language
> environment they are treated as different OLD form and NEW form.
>

All variants under 2nd column and 3rd column has been assigned variant type
(allocatable/block).
The default type of the 1st column is "allocatable".


> It means that if anybody registers the label .一一 for the first time under
> the und-Jpan tag, then nobody can register the label .弌弌 under any tag.
> If they had first registered the label .弌弌 under the und-Hani tag, then
> the same applicant can request to register the label .一一 as well (but
> whether that request is granted, and how, is outside the scope of the LGR).
>
>
>
Yes, this is the goal of the proposal based on informed constraints.


>  Moreover, only the allocatable code points can be used to generate valid
> whole label package, and this whole label package will go (be allocated) to
> the SAME applicant, which means, the co-existence of old form label
> registrant and new form label registrant will not happen at Root level.
>

Yes, only the allocatable code points (1st column) can be used to generate
valid whole label package (2nd/3rd column).
(ref: RFC3743)


>  if it is felt desirable to allow somebody to register the old form and
> the new form under the "und-Jpan" tag, then the only way to do that is to
> declare these as "allocatable" variants under the und-Jpan tag.
>

>
> Because the root is a shared resource, variants must be tightly coupled.
>

yes, if the presented sample table is considered "tightly coupled".
Otherwise it has to be
clearly defined somewhere.

Regards

Kenny Huang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/neobrahmigp/attachments/20141028/b931f12e/attachment-0001.html>
-------------- next part --------------
_______________________________________________
lgr mailing list
lgr at icann.org
https://mm.icann.org/mailman/listinfo/lgr


More information about the Neobrahmigp mailing list