[Neobrahmigp] IP review of Tamil LGR proposal v3.0

[Dr. Shanmugam Rajabadher]

Dear Dr.Sarmad,
Thanks for sharing the feedback. Will revert back with the updates.

Thanks and regards,
Dr. Shanmugam R.


On Wed 6 Feb, 2019, 8:39 AM Sarmad Hussain <sarmad.hussain at icann.org wrote:

> Dear Shanmugam, all,
>
>
>
> Please find below the review of the proposal by IP.  Please visit here
> <https://www.icann.org/resources/pages/lgr-proposals-2015-12-01-en> to
> see the Arabic proposal, in case you would like to review the no-mix rule.
>
>
>
> Kindly let us know if you have any queries.
>
>
>
> We look forward to the final version, incorporating the feedback.
>
>
>
> Regards,
> Sarmad
>
>
>
>
>
> To: NeoBrahmi Generation Panel
> From: Integration Panel
> Subject: Review of Tamil LGR dated Dec 6, 2018
>
> We have reviewed the updated proposal dated 2018-12-06 including XML and
> TXT files.
>
> Here are our findings:
>
> *TECHNICAL / DOCUMENTATION ISSUE*
>
> Tamil is one of the few LGRs that assign an "allocatable" variant, yet the
> LGR did not defined a "no-mix" rule to prevent needless multiplication of
> variant labels where the same label alternates the variant used.
>
>
>
> The LGR makes the two encodings of SRI/SHRI allocatable but it is not
> clear why it would be essential, or even desirable to support all 4
> permutations in a case where SHRI/SRI occurs twice in the same label.
>
>
>
> --- SRI ---- SRI ---
>
> --- SRI ---- SHRI ---
>
> --- SHRI ---- SRI ---
>
> --- SHRI ---- SHRI ---
>
>
>
> Here "---" stands for some code points common to both labels.
>
>
>
> It seems only necessary to allow one or the other spelling consistently
> for a single label.
>
>
>
> If, unexpectedly, there is some requirement to cater to all possible
> permutations, then this needs to be documented very clearly and the cost
> for supporting it (potentially many more than 2 allocatable labels) must be
> spelled out.
>
>
>
> Alternatively, the LGR should be amended to contain a "no-mix" rule,
> patterned after the Arabic LGR's no-mix rules, or other suitable
> restriction.
>
>
>
> *DOCx:*
>
> The main document shows no changes other than what looks like minor copy
> editing/editorial. No additional issues identified.
>
> In section 5.2.1, only the variant sequences for 6.1.3 have been listed,
> but not the ones for 6.1.1 (U+0B92 U+0BB3) and 6.1.2 (U+0BC6 U+0BB3). This
> is not consistent and is at odd with the XML/HTML where obviously sequences
> appear along single code points.
>
> The remedy is add these 2 sequences in section in 5.2.1 with references to
> 6.1.1 and 6.1.2 as it has already been done for the other pair.
>
>
>
> While the two sets are slightly different because the sets for 6.1.1 and
> 6.1.2 are 2 to 1 variants unlike the one in 6.1.3, the difference appears
> immaterial for this purpose and having a full list of sequences in section
> 5 makes sense.
>
>
>
> *XML:*
>
> No changes found other than Date. One common *editorial issue*:
>
>
>
> (1) as with all LGRs the placeholders in the <description> need to be
> updated with *final date and URL:*
>
>        Neo-Brahmi Generation Panel, "Proposal for a Tamil Script Root Zone
> Label Generation Rule-Set (LGR)", [URL and Date TBD]
>
>
>
> The XML passes the tool
>
>
>
> *TXT:*
>
> Test label file verified; existing TLDs show as valid.
>
>
>
>
> ------------------------------
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/neobrahmigp/attachments/20190206/440eb2e4/attachment.html>