[ChineseGP] some questions for IP on CJK coordinaton

王伟 wangwei at cnic.cn
Fri May 15 12:47:02 UTC 2015


Dear IP members

 

During the discussion in CJK coordination meeting this afternoon, I checked the draft of “Representing Label Generation Rulesets using XML” (https://www.ietf.org/id/draft-davies-idntables-09.txt) again.

Here are some questions about the terminology and label disposition rule in the draft.

 

1)       Terminology for “variant subtype”

Besides the variant type  like “allocatable” and “blocked”, some other attributes like “trad” “simp” “both” are given in the draft as follows:

-------------------------------------------------------------------------------------------------------------------

   Assuming an LGR where all variants have been given suitable "type"

   attributes of "block", "simplified", "traditional", or "both",

   similar to the ones discussed in Appendix B.  Given such an LGR, the

   following example actions evaluate the disposition for the variant

   label:

 

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

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

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

       <action disp="block" all-variants="simplified traditional " />

       <action disp="allocate" />

 

   The first action matches any variant label for which at least one of

   the code point variants is of type "block".  The second matches any

   variant label for which all of the code point variants are of type

   "simplified" or "both", in other words an all-simplified label.  The

   third matches any label for which all variants are of type

   "traditional" or "both", that is all traditional.  These two actions

   are not triggered by any variant labels containing some original code

   points, unless each of those code points has a variant defined with a

   reflexive mapping (Section 4.2.4).

----------------------------------------------------------------------------------------------------------------

Yoneya san suggested that we define them  (“simp”“trad””both”…) as “variant subtype”

If it is not appropriate to call that, is there any other terminology you might prefer?

 

 

2)       The variant type of “out-of-repertoire”

In a work email last year, Asmus mentioned 

“The MSR already contains a default action  <action disposition="invalid" any-variant="out-of-repertoire-var" comment="any variant label with a code point out of repertoire is invalid"/>”

However, I didn’t find the definition of “out-of-repertoire” and the corresponding action in draft-davies-idntables-09

Will this part be added in the next version?

 

3)        suggestion about a new variant type and action type

JGP-LGR-1 doesn’t have variants, but many CGP variants will be added into JGP-LGR-2,which means, JGP will adopt many Chinese variants to reach a CJK consensus,

The meaning of most those variants are same, however, there are some specific code points mean totally different things in Japanese language environment, while the exchangeable variants in Chinese.

Like 机/機,both  mean machine in Chinese, but mean machine and table separately in Japanese.

Though JGP will set them as variants and both “allocatable”, I wonder if it is possible to create a new type of “allocatable-reserved” to help tell the difference  in WLE.

The corresponding action will go like <action disposition="allocatable-reserved" any-variant="allocatable-reserved">

Which means, when机上 is applied, 機上will be generated and allocatable, but a special process is needed before the real delegation/activation of “機上”

Because unlike the common allocatable variant label, the activation of these “allocatable-reserved” label might bring domain name disputes or abuse.

 

does the new type suggestion make sense? Do you think it is practical ?

 

 

looking forward to your answer.

 

 

Best Regards

Wang wei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/chinesegp/attachments/20150515/14915ed5/attachment.html>


More information about the ChineseGP mailing list