Got it. Sounds good Thanks, Dennis Sent from my iPhone On Dec 10, 2019, at 5:00 PM, Bill Jouris <bill.jouris@insidethestack.com> wrote: Hi Dennis, That was my intention. I figured to put sample tables (probably just headers) in, just so the IP is clear that we are not ignoring their comments. But that's it. Bill Sent from Yahoo Mail on Android<https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_Andr...> On Tue, Dec 10, 2019 at 1:04 PM, Tan Tanaka, Dennis via Latingp <latingp@icann.org> wrote: Michael is correct. We register Latin's view of variants (in-script and cross-script) and produce well-formed variant sets. We don't need to worry about those relationships created by other GPs. IP will do this during integration and call out any issues, as they have. Bill - I would suggest leaving the task of creating variant set tables until the end. The LGR tool can help with that and alleviate the time consuming task of doing this by hand. Note that this is necessary for our own proposal before submitting to IP as well. As a panel we need to make certain all variant sets are well formed. The LGR tool make this easier. Dennis On 12/9/19, 6:11 AM, "Latingp on behalf of Michael Bauland" <latingp-bounces@icann.org<mailto:latingp-bounces@icann.org> on behalf of Michael.Bauland@knipp.de<mailto:Michael.Bauland@knipp.de>> wrote: Hi Bill, On 07.12.2019 20:42, Bill Jouris wrote: > This task appears to have two separate parts. > > 1) *ASCII variants resulting from Transitivity* > > At the meeting with the Armenian, Cyrillic, Greek, and Latin GPs in > Montreal, the IP noted that cross-script variants and transitivity > resulted in Latin Small Letter V and Latin Small Letter Y being variants > -- which, since they are ASCII characters, is not allowed. The cause > (at least part of the cause) was determined to be the Greek GP's finding > that Greek Small Letter Nu and Greek Small Letter Gamma are variants. > That finding also resulted in an in-script Cyrillic variant which the > Cyrillic GP found unacceptable. > > The result of discussion between the GPs was that the Greek GP would > reconsider their finding regarding Nu and Gamma. Thus no action is > required of the Latin GP. yes, that is also what I remember from the discussion. The Greek did not seem to mind too much to lose that variant relationship. > > 2) *Variants due to Transitivity* > > A complete listing will, of course, await finalizing our decisions on > Latin in-script variants. But I have started creating tables for them. > For example, for Cyrillic cross-script variants, each case we found will > also require a new transitivity listing for each of the Latin in-script > variants we find for the Latin element in the cross-script variant. > Tedious to generate, or course, but not calling for any particular > decision process by us. I agree. Let's have two examples. Let's say Lx are Latin characters and Cx are Cyrillic ones. Example 1: ---------- If we then have have the following: L1 a variant of C1. L1 a variant of L2. L2 a variant of L3. C2 a variant of L4. And the Cyrillic also have C1 a variant of C2. In that case, as I understand it, we have to list the following variant sets: {L1, L2, L3, C1} {L4, C2} The IP will then in a second step realise that C2 and C1 are variants and therefore combine the two sets to one: {L1, L2, L3, L4, C1, C2} But that is out of our scope, as I understand it. We don't have to look at any in-script variants within other scripts. Example 2: ---------- If we have L1 a variant of L2 but not L1 a variant of C1 And the Cyrillic team has C1 a variant of L1 Then we don't have to put C1 into our {L1, L2} variant set. That's the task of the Cyrillic team. They do {C1, L1} and the IP will then generate {L1, L2, C1} from this. We always just look at the variant relationships we think are valid and generate the transitive closure for those, ignoring any results from other teams. Cheers, Michael -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeißer-Weg 9 44227 Dortmund Deutschland Dipl.-Informatiker Tel: +49 231 9703-0 Fax: +49 231 9703-200 Dr. Michael Bauland SIP: Michael.Bauland@knipp.de<mailto:Michael.Bauland@knipp.de> Software-Entwicklung E-Mail: Michael.Bauland@knipp.de<mailto:Michael.Bauland@knipp.de> Registereintrag: Amtsgericht Dortmund, HRB 13728 Geschäftsführer: Dietmar Knipp, Elmar Knipp _______________________________________________ Latingp mailing list Latingp@icann.org<mailto:Latingp@icann.org> https://mm.icann.org/mailman/listinfo/latingp _______________________________________________ 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. _______________________________________________ Latingp mailing list Latingp@icann.org<mailto:Latingp@icann.org> https://mm.icann.org/mailman/listinfo/latingp _______________________________________________ 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.