[Latingp] Latin GP Task 6

[Tan Tanaka, Dennis]

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 at icann.org on behalf of Michael.Bauland at 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 at knipp.de
         Software-Entwicklung        E-Mail: Michael.Bauland at knipp.de
    
                                     Registereintrag:
                                     Amtsgericht Dortmund, HRB 13728
    
                                     Geschäftsführer:
                                     Dietmar Knipp, Elmar Knipp
    _______________________________________________
    Latingp mailing list
    Latingp at 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.