<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 11/5/2014 5:05 PM, Yoshiro YONEYA
      wrote:<br>
    </div>
    <blockquote
      cite="mid:20141106100530.4b51343ac49469e8e89ecaf6@jprs.co.jp"
      type="cite">
      <pre wrap="">Dear IP members and RootLGR staff,

I have two questions regarding RootLGR.

(1) Why mixing Japanese scripts and alphabet is denied 
    in RootLGR?

  During RoogLGR Workshop on Oct 15th, I asked that if
  Japanese rule can consist from jpan(hani+hira+kata) +
  alphabet.  The answer from Asmus was "No", but I couldn't
  get the reason at that time.  Would you please give me the
  reason why jpan + alphabet (latn) can't mix?</pre>
    </blockquote>
    Dear Yoneya-san,<br>
    <br>
    I am discussing the reply to your first question with the<br>
    other IP members, so let me get back to you separately on that.<br>
    <br>
    Just out of interest, can you give me an example of a label <br>
    where jpan+latn needs to be mixed?<br>
    <br>
    On your second question, let me try to clarify the issue.<br>
    I hope I will succeed. Feel free to ask any follow-up<br>
    questions:<br>
    <blockquote
      cite="mid:20141106100530.4b51343ac49469e8e89ecaf6@jprs.co.jp"
      type="cite">
      <pre wrap="">

(2) How does language tag work in RootLGR?

  Language LGR specifies its language tag as &lt;language&gt;
  element.  How does it work in RootLGR?  For example, 
  if CGP defined variants for U+767C and U+73FE as follows:

  &lt;language&gt;und-Hani&lt;/language&gt;
  &lt;char cp="767C" tag="sc:Hani"&gt;
    &lt;var cp="53D1" type="simp" /&gt;
    &lt;var cp="5F42" type="blocked" /&gt;
    &lt;var cp="767C" type="trad" comment="identity" /&gt;
    &lt;var cp="9AEA" type="blocked" /&gt;
    &lt;var cp="9AEE" type="blocked" /&gt;
  &lt;/char&gt;
  &lt;char cp="73FE" tag="sc:Hani"&gt;
    &lt;var cp="73B0" type="simp" /&gt;
    &lt;var cp="73FE" type="trad" comment="identity" /&gt;
  &lt;/char&gt;</pre>
    </blockquote>
    <br>
    First, this definition of variants is incomplete. An actual LGR
    would need to have &lt;char&gt; entries for all the variants, with
    their own sets of mappings so that the full set of mappings is both
    symmetric and transitive. So let's assume you left these out for
    simplicity but that they are, in fact, specified in the LGR for
    und-Hani, as required.<br>
    <blockquote
      cite="mid:20141106100530.4b51343ac49469e8e89ecaf6@jprs.co.jp"
      type="cite">
      <pre wrap="">

  and if JGP defined variants for U+7670 and U+73FE as follows:</pre>
    </blockquote>
    <br>
    I assume this is a typo for U+767C<br>
    <blockquote
      cite="mid:20141106100530.4b51343ac49469e8e89ecaf6@jprs.co.jp"
      type="cite">
      <pre wrap="">

  &lt;language&gt;unt-Jpan&lt;/language&gt;
  &lt;char cp="767C" tag="sc:Jpan"&gt;
    &lt;var cp="767C" type="alloc" comment="identity" /&gt;
    &lt;var cp="767A" type="alloc" /&gt;
  &lt;/char&gt;
  &lt;char cp="73FE" tag="sc:Jpan"&gt;
    &lt;var cp="73FE" type="alloc" comment="identity" /&gt;
  &lt;/char&gt;</pre>
    </blockquote>
    <br>
    First of all, in the integrated LGR, the full set of mappings would
    have to be present, that is, there are many mappings of type "block"
    (or blocked) that would have to be added because of integration with
    the Chinese LGR.<br>
    <br>
    <pre wrap="">  &lt;language&gt;und-Jpan&lt;/language&gt;
  &lt;char cp="767C" tag="sc:Jpan"&gt;
    &lt;var cp="53D1" type="blocked" /&gt;
    &lt;var cp="5F42" type="blocked" /&gt;
<font color="#3333ff"><b>    &lt;var cp="767C" type="alloc" comment="identity" /&gt; &lt;!-- Jpan --&gt;
    &lt;var cp="767A" type="alloc" /&gt;</b></font> <font color="#3333ff"><b>&lt;!-- Jpan --&gt;</b></font>
    &lt;var cp="9AEA" type="blocked" /&gt;
    &lt;var cp="9AEE" type="blocked" /&gt;
  &lt;/char&gt;
  &lt;char cp="73FE" tag="sc:Jpan"&gt;
    &lt;var cp="73B0" type="blocked" /&gt;
<font color="#3333ff"><b>    &lt;var cp="73FE" type="alloc" comment="identity" /&gt; </b></font><font color="#3333ff"><b><font color="#3333ff"><b>&lt;!-- Jpan --&gt;</b></font></b><b>
</b></font>  &lt;/char&gt;</pre>
    I have highlighted the Japanese-specific entries.<br>
    <br>
    However, if &lt;var cp="767A" type="alloc" /&gt; is added, then the
    Chinese LGR would have an additional entry: &lt;var cp="767A"
    type="blocked" /&gt;<br>
    <br>
    (BTW, in the root zone LGR we will use "blocked" instead of "block",
    even though the XML-LGR draft uses "block" - they mean the same
    thing).<br>
    <blockquote
      cite="mid:20141106100530.4b51343ac49469e8e89ecaf6@jprs.co.jp"
      type="cite">
      <pre wrap="">

  How does integrated RootLGR look like? </pre>
    </blockquote>
    <br>
    The integrated LGR contains the additional variant mappings needed
    to <br>
    a) make the set transivite and symmetric<br>
    b) ensure that each "variant cluster" (or set of code points that
    are mutually variant) is the same in each script LGR.<br>
    <br>
    While the clusters must be the same, the type values can be chosen
    based on the tag.<br>
    <br>
    <blockquote
      cite="mid:20141106100530.4b51343ac49469e8e89ecaf6@jprs.co.jp"
      type="cite">
      <pre wrap=""> How does language
  tag in RootLGR work to generate variant labels?  I assume 
  that if an applicant applied-for U+767C U+73FF as und-Hani, </pre>
    </blockquote>
    that appears to be a type for U+767C U+73FE<br>
    <blockquote
      cite="mid:20141106100530.4b51343ac49469e8e89ecaf6@jprs.co.jp"
      type="cite">
      <pre wrap="">
  allocatable variant labels are U+767C U+73FE and U+53D1 U+73B0, 
  and blocked variant labels are others. </pre>
    </blockquote>
    <br>
    To achieve this, the following &lt;action&gt; elements must be
    defined<br>
    in the XML<span style="color:#1F497D" lang="EN-US"><br>
      <o:p></o:p></span>
    <p class="MsoNormal"
      style="margin-left:21.0pt;mso-para-margin-left:2.0gd"><span
        style="color:#1F497D" lang="EN-US">         &lt;action
        disp="blocked" any-variant="blocked" /&gt;<o:p></o:p></span></p>
    <p class="MsoNormal"
      style="margin-left:21.0pt;mso-para-margin-left:2.0gd"><span
        style="color:#1F497D" lang="EN-US">         &lt;action
        disp="allocatable" only-variants="simp both" /&gt;<o:p></o:p></span></p>
    <p class="MsoNormal"
      style="margin-left:21.0pt;mso-para-margin-left:2.0gd"><span
        style="color:#1F497D" lang="EN-US">         &lt;action
        disp="allocatable" only-variants="trad both" /&gt;<o:p></o:p></span></p>
    <p class="MsoNormal"
      style="margin-left:21.0pt;mso-para-margin-left:2.0gd"><span
        style="color:#1F497D" lang="EN-US">         &lt;action
        disp="blocked" any-variant="simp trad" /&gt;<o:p></o:p></span></p>
    <p class="MsoNormal"
      style="margin-left:21.0pt;mso-para-margin-left:2.0gd"><span
        style="color:#1F497D" lang="EN-US">         &lt;action
        disp="allocatable" comment="catch-all" /&gt;<o:p></o:p></span></p>
    The top-most action that matches the condition on variant mappings
    is the one that will set the disposition.<br>
    <br>
    Any variant label being created from any "blocked" variant will be
    blocked in the first action.<br>
    <br>
    Any variant label being created from only "simp" (or "both" which we
    don't have in the example) will be set to allocatable in the second
    action. (U+53D1 U+73B0)<br>
    <br>
    Same for "trad" in the third action (U+767C U+73FE)<br>
    <br>
    The fourth action would block mixed labels such as U+767C U+73B0 and
    U+53D1 U+73FE.<br>
    <br>
    And finally the last action exists to allow allocatable labels that
    do not use reflexive (identity) mappings - we don't have them in
    this example (but see below).<br>
    <blockquote
      cite="mid:20141106100530.4b51343ac49469e8e89ecaf6@jprs.co.jp"
      type="cite">
      <pre wrap=""> On the other hand, 
  I assume that if an applicant applied-for U+767C U+73FF as </pre>
    </blockquote>
    that appears to be a type for U+767C U+73FE again<br>
    <blockquote
      cite="mid:20141106100530.4b51343ac49469e8e89ecaf6@jprs.co.jp"
      type="cite">
      <pre wrap="">
  und-Jpan, allocatable variant labels are U+767C U+73FE and 
  U+767A U+73FE, and blocked variant labels are others.</pre>
    </blockquote>
    Correct.<br>
    <br>
    In fact, it is not necessary for the Japanese example to use
    reflexive mappings. As long as there is only two types meaning
    "blocked" and "allocatable", these two &lt;action&gt;<br>
    statements are sufficient:<br>
    <p class="MsoNormal"
      style="margin-left:21.0pt;mso-para-margin-left:2.0gd"><span
        style="color:#1F497D" lang="EN-US">         &lt;action
        disp="blocked" any-variant="blocked" /&gt;<o:p></o:p></span></p>
    <span style="color:#1F497D" lang="EN-US"><o:p></o:p></span>
    <p class="MsoNormal"
      style="margin-left:21.0pt;mso-para-margin-left:2.0gd"><span
        style="color:#1F497D" lang="EN-US">         &lt;action
        disp="allocatable" comment="catch-all" /&gt;</span></p>
    (The other three actions could be defined, but wouldn't get
    triggered).<br>
    <br>
    So the example would simplify to:<br>
    <br>
    <pre wrap="">  &lt;language&gt;und-Jpan&lt;/language&gt;
  &lt;char cp="767C" tag="sc:Jpan"&gt;
    &lt;var cp="53D1" type="blocked" /&gt;
    &lt;var cp="5F42" type="blocked" /&gt;
<font color="#3333ff"><b>    &lt;var cp="767A" type="alloc" /&gt;</b></font> <font color="#3333ff"><b>&lt;!-- Jpan --&gt;</b></font>
    &lt;var cp="9AEA" type="blocked" /&gt;
    &lt;var cp="9AEE" type="blocked" /&gt;
  &lt;/char&gt;
  &lt;char cp="73FE" tag="sc:Jpan"&gt;
    &lt;var cp="73B0" type="blocked" /&gt;
  &lt;/char&gt;</pre>
    <br>
    <blockquote
      cite="mid:20141106100530.4b51343ac49469e8e89ecaf6@jprs.co.jp"
      type="cite">
      <pre wrap="">
  I read draft-davies-idntables-08, but I couldn't understand 
  how to merge two LGRs into one LGR, and how to select variants 
  depend on language tag.</pre>
    </blockquote>
    <br>
    If you assume that it is possible to create a single XML file for
    the *integrated* LGR, it will be hard to understand. That is because
    it is indeed not possible to create such a single, integrated file,
    because in the XML the selection by &lt;language&gt; tag is a
    per-file issue.<br>
    <br>
    Instead, what the IP will produce is a set of files that are
    guaranteed to produce consistent results.<br>
    <br>
    Each application will be processed against a single file (selected
    by &lt;language&gt; tag, such as "und-Jpan"). The files will contain
    the full variant clusters so that the full permutation of variant
    labels can be generated. This full set of permuted labels can then
    be checked against all existing registrations (no matter whether
    they were registered under "und-Jpan" or under "und-Hani"). If no
    conflicts are found, the application can proceed to the next stage
    and the subset of allocatable variants will be determined.<br>
    <br>
    If a label U+767A U+73FE has been allocated (which is possible under
    und-Jpan) then under und-Hani
    it is not possible to apply for U+767C U+73FE or U+53D1 U+73B0.<br>
    <br>
    By ensuring that all files in the LGR are mutually consistent, one
    only needs a single file to process the application.<br>
    <br>
    The consistent files need the additional "blocked" variant mappings,
    but they also need entries for the target code points of these
    mappings. Such code points are not part of the repertoire. They are
    identified with special reflexive variant mappings. For example,
    assume 53D1 as simplified ideograph is not part of the Japanese
    repertoire. <br>
    <br>
    Because of consistency, the LGR for und-Jpan would need this entry<br>
    <br>
    &lt;language&gt;und-Jpan&lt;/language&gt;<br>
    &lt;char cp="53D1" &gt;<br>
        &lt;var cp="53D1" type="out-of-repertoire-var"
    comment="identity" /&gt;<br>
        &lt;var cp="767C" type="blocked"<br>
        &lt;var cp="5F42" type="blocked"<br>
        .....<br>
    &lt;/char&gt;<br>
    <br>
    The MSR already contains a default action<br>
    <br>
       &lt;action disposition="invalid"
    any-variant="out-of-repertoire-var" comment="any variant label with
    a code point out of repertoire is invalid"/&gt;<br>
    <br>
    which would eliminate any original label containing U+53D1, so that
    one could not apply for U+53D1 U+73FE, for example, in the
    "und-Jpan" case.<br>
    <br>
    Anyway, this is the technical meat of creating the set of mutually
    consistent files for integration.<br>
    <br>
    A./<br>
    <br>
    <br>
    <blockquote
      cite="mid:20141106100530.4b51343ac49469e8e89ecaf6@jprs.co.jp"
      type="cite">
      <pre wrap="">

Regards,

</pre>
    </blockquote>
    <br>
  </body>
</html>