[ChineseGP] ??: [lgr] Question about coordination principles for C J and K
Asmus Freytag
asmusf at ix.netcom.com
Wed Nov 12 19:40:48 UTC 2014
Dear Wang Wei,
You raise an important question. Let me attempt to give you my best
understanding.
The central prescription on the disposition of variant labels based on
the definition of the variants appears to be that the final outcome is
that every variant *label *is either "allocatable" or "blocked" and that
that disposition (for the same label) may be different by script tag.
Your suggested scheme appears to satisfy that prescription while
allowing a reduction of allocatable labels as mandated in section A.3.3
of the procedure.
To consider this in detail:
The development of the LGR for the root zone is covered by the
Procedure; section B.1.2 describes the output elements. To answer your
question we need to look at items 3 and 4.
"3. Assignment of one or more “tags” to each code point in the
repertoire, and, by extension, to each disposition of a variant in
(4). For the same label, different dispositions may exist for the
same variant label, as long as the variant labels do not share
common tag values."
This tells us that variant labels for "und-Jpan" and "und-Hani" do not
have to have the same disposition, because the script tags are different.
"4. The *disposition of the labels* resulting from the application
of the rules in (2). For a given code point in the repertoire, this
element specifies whether a resulting variant label is blocked or
allocatable, /*depending on how the variant label was generated*/.
The same code point under different tags (see 3) might generate an
allocatable variant label in one case, and a blocked variant label
in another." (emphasis added)
This tells us that what matters is the ultimate disposition of the
variant *label *and not primarily the type value associated with variant
code point mapping in the XML format.
Section B.3.1 states that whole label evaluation rules can be used to
further restrict allocatable labels and section A.3.3 calls for the LGR
"to minimize the number of allocatable variants."
I personally believe that reducing the number or allocatable variants is
indeed worthwhile, and the discussion that followed the release of the
procedure as well as the user experience report, ultimately leading to
the risk study and the SSAC recommendations bear me out on this. I
further believe, that not addressing the problem of unnecessary
allocatable variants may well violate one or more of the Principles that
are set forth in the procedure, not least the Conservatism Principle.
This makes it essential to look for a solution.
Accordingly, it seems to me that your suggestion to divide allocatable
variant mappings by using the distinct type values of "trad", "simp" and
"both" together with the necessary actions will allow a way to create
dispositions for variant *labels *that are either "allocatable" or
"blocked" as specified in the procedure, but with the benefit of
*sharply reducing* the set of "allocatable" variant labels. Thus your
suggested method would fulfill the mandate in the procedure "to minimize
the number of allocatable variants".
The mechanism you propose can be characterized as a way to assign
disposition of variant labels "depending on how the label was
generated". This is because the type values are *associated with the
variant mappings*, not with the code points. Because of that, they would
fall under item 4, including the fact that the disposition of variants
may differ by script-tag.
Ordinary WLE rules, on the other hand, those that act on the code
points, are restricted: "if a *code point is associated* with some
whole-label evaluation rules, those whole-label evaluation rules must be
the same no matter what the tag."
Now, the XML Syntax was finalized only after the procedure was written,
so we cannot expect that the procedure (and the examples in it) will
make reference to specific syntax elements, but it may be possible to
examine these syntax elements in light of the procedure to determine
where they fit.
In the XML, <action> elements that use "match" and "not-match" are
associated with <rule> elements that *act on code points*. This clearly
makes them equivalent to that the procedure calls whole label evaluation
rules associated with code points and by the procedure such code
point-dependent rules would be required to be independent of script tag.
In contrast, <action> elements that use "any-variant", "only-variants"
etc. *act on variant mappings* and not on code points. Therefore, they
"depend on how the variant is generated", as defined in item (4). That
would make it possible for the latter type of <action> to be specific to
the script-tag.
Because the disposition of variant labels is specific to the script tag,
I can no reason why the JGP couldn't use its own type values. (That
assumes, that there was an interest in the JGP to allow allocatable
variant labels for the und-Jpan tag.)
You asked:
> Finally, do that mean IP accept the solution...
As a general policy, the Integration Panel never pre-approves any
feature of any LGR proposal. However, the Integration Panel or its
members are happy to point out any known areas of concern ahead of time,
to give Generation Panels the chance to address those issues prior to
formal submission.
A./
On 11/8/2014 11:10 PM, Wang Wei wrote:
> Procedure to Develop and Maintain the Label Generation Rules for the
> Root Zone in Respect of IDNA Labels
>
> 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”,
> Appendix B <https://tools.ietf.org/html/draft-davies-idntables-08>.
> How to Translate RFC 3743 <https://tools.ietf.org/html/rfc3743> 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 environmentthey 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/20141112/66fa87b9/attachment-0001.html>
More information about the ChineseGP
mailing list