[Neobrahmigp] Defect in the Root Zone LGR for Malayalam?

Sat Oct 26 12:01:12 UTC 2019

Thank you Pitinan. I have gone the documents and test labels and approve
the changes.

Regards

Veena Solomon
<https://www.instagram.com/vinazol>   <https://www.facebook.com/vinazol>
<https://twitter.com/vinazol>   <https://www.linkedin.com/in/vinazol>

On Sat, Oct 26, 2019 at 4:55 PM Pitinan Kooarmornpatana <
pitinan.koo at icann.org> wrote:

> Dear Veena and all NBGP members,
>
>
>
> Please find below the additional information from the IP on the previous
> message on Malayalam LGR defect issues.
>
>
>
> In consultation with Veena, we have updated the Malayalam LGR comment
> accordingly.
>
> Please find attached the updated package version 2.2 dated 26 October
> 2019.
>
>
>
> Updates in this version:
>
>    1. Update Rule #1 in docx to match the XML, allowing H to follow 0D7B
>    2. Add necessary variant member into the set due to the rule change
>
>
>
> Kindly review and finalize. Please let us know if the package is ready to
> be shared with the IP.
>
>
>
> Regards,
>
> Pitinan
>
>
> ------------------------------
>
> From: Integration Panel
> To: NeoBrahmi Generation Panel
> Re: Issue in Root Zone LGR for Malayalam
>
>
>
> We earlier sent you a request for input on an issue discovered with the
> Malayalam Root Zone LGR. We have not received a response. In the meantime,
> as anticipated (see the PS:) the underlying issue of how to encode the
> Malayalam "nta" has been taken up in the Unicode Technical Committee.
> Several documents have been filed and links to publicly available ones have
> been added to the "Update:" at the end.
>
>
> We are looking forward to your response,
>
> ---IP
>
>
>
> *Earlier message:*
>
> The IP has become aware of an *issue in the published version of the
> RZ-LGR for Malayalam.*
>
>
>
> The RZ-LGR-3 version of the Malayalam LGR uses formulation of WLE Rule 1
> that (while matching the XML file in the Malayalam LGR proposal) is more
> permissive than what the proposal document calls for in Section 7.
>
>
>
> The XML files allow 0D7B to precede Halant, while the text of the proposal
> document does not, and furthermore, the text gives one example of a
> sequence that should not be allowed by WLE Rule 1.
>
> At issue is sequence 1b from section 6.1, which the proposal text says
> should be disallowed because it doesn't render consistently. WLE Rule 1 for
> H (until the April version of the proposal) did allow the sequence, because
> VIRAMA was allowed to follow 0D7B.
>
> This provision was removed in the April version for the DOCx but not in
> the XML version of the proposal, and the RZ-LGR-3 version of the XML has
> been published with the more permissive rule.
>
> One effect is that sequence 1b, which, if permitted, should have been a
> variant, is now permitted without being a variant, a situation that
> constitutes a "loophole" that would allow variant labels to be allocated as
> if unrelated.
>
> The WLE rule in question was first changed in response to public comment
> (it did not allow 0D7B in the 2018-09-25 version).  Here's a comment on
> sequence 1b:
>
> [image: cidimage001.png at 01D58056.B96A4570]
>
>
>
> Normally, with the proposal clearly worded one way and the XML different,
> this could have been a "clerical error" and handled accordingly. However,
> given that the public comment response and the final proposal are
> different, it is not possible to unambiguously determine the underlying
> intent.
>
>
>
> As it stands, if we leave the Root-Zone's XML version of the rule as is,
> that XML would be missing a variant definition; Section 6.1 makes it  clear
> that a variant would have been required for sequence 1b if not disallowed.
> If we change the rule to match the proposal document, then the proposal XML
> file and response to public comment would need to be revised.
>
>
>
> We have further received reports that question the analysis of the three
> sequences in Section 6.1 and  that come to different conclusions on  which
> ones are unambiguously supported (and which ones should be supported). In
> particular it is claimed that sequence 1b is not supported by Windows'
> shaping engine (and neither is 1a).
>
>
>
> We therefore request the GP to revisit this issue and to resolve how to
> address this going forward.
>
>
>
> In particular, we would also like the GP to confirm which software
> platforms support which sequences.
>
>
> --IP
>
>
>
> PS: we are aware that some parties are planning to approach Unicode to
> request a change to table 12-38. While no such proposal has been received
> by Unicode today, there is the possibility, but not a certainty, that
> Unicode's position on the status of that sequence could change in the
> future.
>
>
>
> Update: *For background information:* since the first transmission of the
> above issue report, the following documents have been submitted to the
> Unicode Technical Committee or drafted in response.
>
> L2/19-345 [unicode.org]
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.unicode.org_cgi-2Dbin_GetMatchingDocs.pl-3FL2_19-2D345&d=DwMDaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=KTETvEaGPwPcawI-QmNa-kiv-ZBvdgyyLm-mxd028M4&m=z4Yh3bolzeekM73LjIua_QhM7_uLjlsqLNy4QfR9NwU&s=qTfIS69iws_kROgkn-X1Be2NGghMO_WYnNXd7LebgUY&e=>
>
> *Alternative encodings for Malayalam "nta"*
>
> Liang Hai
>
> 2019-10-06
>
>
>
> and a *response* from Cibu
>
> C Johny <cibucj at gmail.com> <cibucj at gmail.com>
>
> https://docs.google.com/document/d/1K6L82VRmCGc9Fb4AOitNk4MT7Nu4V8aKUJo_1mW5X1o/
> [docs.google.com]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1K6L82VRmCGc9Fb4AOitNk4MT7Nu4V8aKUJo-5F1mW5X1o_&d=DwMDaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=KTETvEaGPwPcawI-QmNa-kiv-ZBvdgyyLm-mxd028M4&m=z4Yh3bolzeekM73LjIua_QhM7_uLjlsqLNy4QfR9NwU&s=O_s6vEdnHxWBdnoe6_fEW2LUiH0raMTT0ldDTo3sVyM&e=>
>
>
>
> The UTC met on 2019-10-07 and discussed these documents. The conclusion
> was to retain the recommended sequence in the current version of the
> standard as the preferred one, but to better acknowledge the existence of
> the legacy sequences. The treatment in the Unicode Standard would therefore
> be somewhat similar to that of Tamil sequences for SHRII.
>
>
> ------------------------------
>
>
>
>
>
>
>
> *From: *Pitinan Kooarmornpatana <pitinan.koo at icann.org>
> *Date: *Tuesday, August 6, 2019 at 17:24
> *To: *"Neobrahmigp at icann.org" <Neobrahmigp at icann.org>
> *Subject: *FW: Defect in the Root Zone LGR for Malayalam?
>
>
>
> Dear Veena,
>
>
>
> Please find below a message from the IP to NBGP regarding an issue in the
> integrated Malayalam LGR.
>
> The IP found the discrepancy of rule #1 in three places : XML , proposal,
> and the response to public comment.
>
>
>
> Kindly review and let us know your feedback.
>
>
>
> Regards,
>
> Pitinan
> ------------------------------
>
> From: Integration Panel
> To: NeoBrahmi Generation Panel
> Re: Issue in Root Zone LGR for Malayalam
>
> The IP has become aware of an *issue in the published version of the
> RZ-LGR for Malayalam.*
>
>
>
> The RZ-LGR-3 version of the Malayalam LGR uses formulation of WLE Rule 1
> that (while matching the XML file in the Malayalam LGR proposal) is more
> permissive than what the proposal document calls for in Section 7.
>
>
>
> The XML files allow 0D7B to precede Halant, while the text of the proposal
> document does not, and furthermore, the text gives one example of a
> sequence that should not be allowed by WLE Rule 1.
>
> At issue is sequence 1b from section 6.1, which the proposal text says
> should be disallowed because it doesn't render consistently. WLE Rule 1 for
> H (until the April version of the proposal) did allow the sequence, because
> VIRAMA was allowed to follow 0D7B.
>
> This provision was removed in the April version for the DOCx but not in
> the XML version of the proposal, and the RZ-LGR-3 version of the XML has
> been published with the more permissive rule.
>
> One effect is that sequence 1b, which, if permitted, should have been a
> variant, is now permitted without being a variant, a situation that
> constitutes a "loophole" that would allow variant labels to be allocated as
> if unrelated.
>
> The WLE rule in question was first changed in response to public comment
> (it did not allow 0D7B in the 2018-09-25 version).  Here's a comment on
> sequence 1b:
>
> [image: cid:image001.png at 01D54C39.30724660]
>
>
>
> Normally, with the proposal clearly worded one way and the XML different,
> this could have been a "clerical error" and handled accordingly. However,
> given that the public comment response and the final proposal are
> different, it is not possible to unambiguously determine the underlying
> intent.
>
>
>
> As it stands, if we leave the Root-Zone's XML version of the rule as is,
> that XML would be missing a variant definition; Section 6.1 makes it  clear
> that a variant would have been required for sequence 1b if not disallowed.
> If we change the rule to match the proposal document, then the proposal XML
> file and response to public comment would need to be revised.
>
>
>
> We have further received reports that question the analysis of the three
> sequences in Section 6.1 and  that come to different conclusions on  which
> ones are unambiguously supported (and which ones should be supported). In
> particular it is claimed that sequence 1b is not supported by Windows'
> shaping engine (and neither is 1a).
>
>
>
> We therefore request the GP to revisit this issue and to resolve how to
> address this going forward.
>
>
>
> In particular, we would also like the GP to confirm which software
> platforms support which sequences.
>
>
> --IP
>
>
>
> PS: we are aware that some parties are planning to approach Unicode to
> request a change to table 12-38. While no such proposal has been received
> by Unicode today, there is the possibility, but not a certainty, that
> Unicode's position on the status of that sequence could change in the
> future.
> ------------------------------
>
>
>
>
> _______________________________________________
> Neobrahmigp mailing list
> Neobrahmigp at icann.org
> https://mm.icann.org/mailman/listinfo/neobrahmigp
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/neobrahmigp/attachments/20191026/8380f297/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 43845 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/neobrahmigp/attachments/20191026/8380f297/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 43847 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/neobrahmigp/attachments/20191026/8380f297/image002-0001.png>