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

Pitinan Kooarmornpatana pitinan.koo at icann.org
Sat Oct 26 12:11:23 UTC 2019


Dear Veena, 

 

Thank you for your confirmation. We will forward this to the IP. 

 

Regards,

Pitinan

 

From: veena solomon <veena.ycet at gmail.com>
Date: Saturday, October 26, 2019 at 19:01
To: Pitinan Kooarmornpatana <pitinan.koo at icann.org>
Cc: "Neobrahmigp at icann.org" <Neobrahmigp at icann.org>
Subject: [Ext] Re: [Neobrahmigp] Defect in the Root Zone LGR for Malayalam?

 

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

 

Regards
 
Veena Solomon
[instagram.com]   [facebook.com]   [twitter.com]   [linkedin.com]
 

 

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:
Update Rule #1 in docx to match the XML, allowing H to follow 0D7B
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:

 

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]

Alternative encodings for Malayalam "nta"

Liang Hai

2019-10-06

 

and a response from Cibu 

C Johny <cibucj at gmail.com>

https://docs.google.com/document/d/1K6L82VRmCGc9Fb4AOitNk4MT7Nu4V8aKUJo_1mW5X1o/ [docs.google.com]

 

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:

 

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 [icann.org]) and the website Terms of Service (https://www.icann.org/privacy/tos [icann.org]). 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/4bf157a9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 43846 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/neobrahmigp/attachments/20191026/4bf157a9/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 43848 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/neobrahmigp/attachments/20191026/4bf157a9/image002-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4610 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/neobrahmigp/attachments/20191026/4bf157a9/smime-0001.p7s>


More information about the Neobrahmigp mailing list