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

Wang Wei wangwei at cnnic.cn
Wed Oct 29 05:45:34 UTC 2014


Dear Asmus

 

         Thanks for your elaboration. It really help us to reduce ambiguity and conflicts.

 

 

发件人: Kenny Huang, Ph.D. [mailto:huangksh at gmail.com] 
发送时间: 2014年10月28日 14:15
收件人: Asmus Freytag
抄送: Sarmad Hussain; Wang Wei; Hiro HOTTA; KIM Kyongsok; LGR at icann.org
主题: Re: [ChineseGP] [lgr] Question about coordination principles for C J and K

 

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/20141029/a3193533/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