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

[Wang Wei]

Dear Asmus

         

         Thanks for your detailed expatiation  in the last mail.

 

         here is some other questions about language-tag and variant types we countered  when we make whole label rules in XML format.

 

In the draft of “Representing Label Generation Rulesets using XML”,  <https://tools.ietf.org/html/draft-davies-idntables-08> Appendix B. How to Translate  <https://tools.ietf.org/html/rfc3743> RFC 3743 based Tables into the XML Format

We have an example  as follows:

<data> …

         <char cp="9FA0" tag="sc:Hani">

                   <var cp="9FA0" type="both" comment="identity" />

         </char>

         <char cp="9FA2" tag="sc:Hani">

                   <var cp="548C" type="simp" />

                   <var cp="924C" type="block" />

                   <var cp="9FA2" type="trad" comment="identity" />

         </char>….

<data>

         ……

<rules>  <!-- RFC 3743 rules, draft-davies-idntables-08#section-6.2.2 -->

         <action disp="block" any-variant="block" />

         <action disp="allocate" only-variants="simp both" />

         <action disp="allocate" only-variants="trad both" />

         <action disp="block" any-variant="simp trad" />

         <action disp="allocate" comment="catch-all" />

</rules>

 

         Does that mean, for the “allocatable” variants, we are allowed to define sub-variant-types for them?

         In the above example, sub-variant-types include trad, simp and both.

 

         Moreover, is JGP allowed to do the similar thing,  like define “old”, “new”, “both” under allocatable variants?

         then JGP will generate its own whole label rule in accordance with its sub-variant-types.

 

         Finally, do that mean IP accept the solution that for the same variant-mapping-cluster, different language tag will introduce different whole label generation rule?

 

 

         Looking forward to your reply.

 

Regards

Wang Wei

 

发件人: Asmus Freytag [mailto:asmusf at ix.netcom.com] 
发送时间: 2014年10月28日 12:33
收件人: Sarmad Hussain; Wang Wei
抄送: hotta at jprs.co.jp; 'KIM Kyongsok'; LGR at icann.org
主题: Re: [lgr] Question about coordination principles for C J and K

 





From: Wang Wei [mailto:wangwei at cnnic.cn] 
Sent: Tuesday, October 28, 2014 7:31 AM
To: Sarmad Hussain; 'KIM Kyongsok'; hotta at jprs.co.jp <mailto:hotta at jprs.co.jp> 
Cc: ChineseGP at icann.org <mailto:ChineseGP at icann.org> ; LGR at icann.org <mailto:LGR at icann.org> 
Subject: Question about coordination principles for C J and K

 

Dear Sarmad

 

         During the recent discussion in ICANN 51 and CGP fortnightly meeting, we realized that there is different understandings about the coordination principles proposed by IP.

         

         CGP discussed this issue with J and K, then we drafted a document (as the attached file) including two different solutions based on two different understandings.

         

         Could you please tell us which solution complies the original intention of the coordination principles?

 

 

 

Regards

Wang Wei

 


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.

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.


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).

 

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.

 

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.
A./ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/chinesegp/attachments/20141109/43ebe711/attachment-0001.html>