[ChineseGP] [Japanesegp] some questions for IP on CJK coordinaton

[Yoshiro YONEYA]

Dear IP members,

First of all, I appreciate Wang Wei san for asking those questions. 

> 1)       Terminology for “variant subtype”

>From today's meeting, my understanding about the difference between 
variant type and variant subtype is that variant type is one of 
(allocatable|blocked|out-of-repertoire-var), and variant subtype is 
variant type with some limitation.  If this is correct, I'd like to 
reword preliminary terminology text like following.

Before:
(4) Variant type, variant subtype
  Variant type is an attribute of a variant, which indicates the treatment 
  of the variant in WLE. Variant type is one of (a) allocatable, (b) blocked 
  and (c) out of repertoire var. The “allocatable” variant type can have 
  subtype (variant subtype). The variant subtype can be defined by each GP.  
  For example, CGP defines (i) simp, (ii) trad and (iii) both variant subtypes. 
  Each variant subtype has to have one or more corresponding <action> element 
  in WLE.

After:
(4) Variant type, variant subtype
  Variant type is an attribute of a variant, which indicates the treatment 
  of the variant in WLE. Variant type is one of (a) allocatable, (b) blocked 
  and (c) out of repertoire var. Variant subtype is a variation of variant 
  type with certain limitation. For example, in Chinese script, variant type 
  "allocatable" are substituted by "simp" (stands for simplified), "trad" 
  (stands for "traditional") and "both" (stands for both simplified and 
  traditional) subtypes. The variant subtype can be defined by each GP.
  Each variant type and variant subtype has to have one or more corresponding 
  <action> element in WLE.

Please give your comment, or reword text if possible.

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

I found following document which explained out-of-repertoire-var.

https://community.icann.org/download/attachments/43989034/Packaging-MSR-LGR.pdf?version=1&modificationDate=1430069072000&api=v2

Any way, I support Wang Wei san's suggestion.

> 3)        suggestion about a new variant type and action type

I think this is possible option.  I'd like to hear IP's opinion about this.

Regards,

-- 
Yoshiro YONEYA <yoshiro.yoneya at jprs.co.jp>

On Fri, 15 May 2015 20:47:02 +0800 王伟 <wangwei at cnic.cn> wrote:

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