[Neobrahmigp] Devanagari LGR v.6.2 20190220

Sarmad Hussain sarmad.hussain at icann.org
Mon Mar 4 03:41:39 UTC 2019


Dear Akshat and NBGP members,

IP has suggested some edits to consider before final submission of the proposal, listed in their message below.  

As next steps, once these edits are incorporated, the proposal will be published at the proposals’ webpage <https://www.icann.org/resources/pages/lgr-proposals-2015-12-01-en>  as the final version after public comment, and then IP will undertake its evaluation.

Regards,
Sarmad

  _____  

To: NeoBrahmi Generation Panel
From: Integration Panel

 

We reviewed the 20feb19 version of the Devanagari proposal and found one showstopper which should be easy to correct and several editorial items in the XML file.


- Integration Panel

 

Detailed Feedback:

DOCX

no issues

 

XML

proposal-devanagari-lgr-20feb19-en.xml 

SHOWSTOPPER:

(1) when processing the XML, our tool complains about missing symmetric variants (for fix, see next item)

(2) the XML has

for cp="0901":
      <var cp="0945 0902" type="blocked" when="follows-only-C-or-CN"/>

for cp="0945 0902":
      <var cp="0901" type="blocked" when="follows-only-V-or-C-or-N-or-M"/>

This issue may have arisen from an incomplete understanding what makes a variant mapping definition "symmetric". As written, the two definitions aren't symmetric. For variant definitions to be symmetric, the context condition must be the same for both (or both absent) and the mappings must have matching source and target, except one is the inverse of the other. In other words, both highlighted context should be the same (and should be the more restrictive one).

In this case, the confusion stems from the fact that the two code points have context rules on the <char> level; In this kind of situation, the context rule on the variant level should be the more restrictive of the the two, or, where that is not possible, the intersection. In this case, both <var> should have: follows-only-C-or-CN.

This requires the entry for <var cp="0901 ....> to be updated to follows-only-C-or-CN.

Editorial issues in XML

(1) In "Variant Disposition" in the <description>: change "the other one label" --> "any other equivalent label"



 (2) To provide necessary explanation about context rules for variants and sequences used with variants add a subsection at then end of "Variants" section in the <description>:

    <p>Context Rules for Variants: some of the variants defined in this LGR are "effective null variants", that is,
    both some  code points in the source map to "nothing" in the target with all other code points unchanged. 
    (Because mappings are symmetric, it does not matter whether it is the forward or reverse mapping that 
    maps to "null"). Such variants require a context rule to keep the variant well behaved. Symmetry requires 
    the same context rule for both forward and reverse mappings.</p>
    
    <p>In other cases, the sequences or code points making up source and target are constrained by context 
    rules on the code points.  In such a case, any variants require context rules that match the intersection
    between the contexts for both source and target; otherwise a sequence might be considered valid in some 
    variant label when it would not be valid in an equivalent context in an original label.</p> 

 

(3) In "Character Classes" change: "The writing system of Devanagari could be summed up as composed of Consonants, Implicit Vowel Killer: Halant, Vowels, Anusvara, Candrabindu, Nukta and a Visarga." to "The writing system of Devanagari could be summed up as composed of Consonants,  Halant, Vowels, Anusvara, Candrabindu, Nukta and  Visarga."

This changes the unwieldy "Implicit Vowel Killer:Halant" to the actual name of the character class being enumerated, that is simply "Halant". There's also an extra "a" near the end of the sentence.

 

(4) At the end of WLE Rules section, add:

    <p>An additional rule is used only for variants where a Nukta maps to a "null":</p>
    <ul>
        <li>Variant is not defined if followed by a Nukta</li>
    </ul> 

 

TXT

  

We found no change other than internal file date. Did not repeat test, particularly as the normative definition of the XML still has an error.

  _____  

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/neobrahmigp/attachments/20190304/af51faa6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5026 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/neobrahmigp/attachments/20190304/af51faa6/smime-0001.p7s>


More information about the Neobrahmigp mailing list