Subject: RE: [Ltru] Reference lists; AND ABNF GRAMMARS

From: "Addison Phillips" <[email-masked]>
Date: Tue, 19 Jul 2005 11:03:40 -0700

I should add two notes:

1. The matching draft is not at the same maturity level as the other two drafts (i.e. it is not in last call)

2. Probably the document should have text explaining the differences and why they exist (it is there, I suppose, if you read the various extended matching schemes very carefully). For now it appears as received wisdom, which is not a good way to write specs.

Currently most of us are focused on finishing the draft-registry and draft-initial.

Best Regards,

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Addison Phillips
> Sent: 2005?7?19? 10:25
> To: Kent Karlsson
> Cc: LTRU Working Group
> Subject: RE: [Ltru] Reference lists; AND ABNF GRAMMARS
> 
> Hi Kent,
> 
> The grammar in matching is different on purpose.
> 
> 1. The matching draft allows users to specify *either* a primary language
> subtag *or* an extended language sequence. That is, extlangs, for matching
> purposes, are considered unitary with the primary language. You either
> specify the extlangs or you don't. You cannot have a sequence like:
> 
> *-cmn-*-Latn
> 
> You may have sequences like:
> 
> zh-*-Latn, zh-cmn-*-Latn
> 
> In other words, assuming an extended language range, the wild card can
> only appear at the END of a specific field. This is also illegal:
> 
> en-Latn-US-*-boont // specifies multiple variants before a specific
> variant.
> 
> 2. Extensions are specifically excluded from extended language range
> matching: their matching semantics are allowed to be different and they
> are not necessarily considered to be "part" of the language identifier
> proper. Of course they can be matched on a pure subtag basis.
> Contributions about extensions are invited.
> 
> > extlang         = 2*3ALPHA	%%%%%% I'm not sure about the non-trivial
> > differences from -registry here
> >                   *2("-" 3ALPHA)
> >                   ("-"(3ALPHA / "*"))
> 
> This says "(concrete) primary language followed by one or more extlangs or
> star"
> 
> Best Regards,
> 
> Addison
> 
> 
> Addison P. Phillips
> Globalization Architect, Quest Software
> Chair, W3C Internationalization Core Working Group
> 
> Internationalization is not a feature.
> It is an architecture.
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of Kent Karlsson
> > Sent: 2005?7?19? 10:07
> > To: Kent Karlsson
> > Cc: LTRU Working Group
> > Subject: Re: [Ltru] Reference lists; AND ABNF GRAMMARS
> >
> > I wrote:
> >
> > >>    [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for
> > Syntax
> > >>               Specifications: ABNF", RFC 2234, November 1997.
> > >
> > > I think that should be an informative reference (it is normative for
> > > -registry, but not for -matching, I would say). B.t.w., I don't find
> > > an actual reference in the text.
> >
> > Oops. It should stay normative.
> >
> >
> > The grammars in -registry and -matching should "look more similar";
> > formatting, order, comments, and structure. Here is a preliminary
> cleanup:
> >
> > ------------------------------------------------------------
> >
> > %% For -registry
> >
> > Language-Tag    = langtag
> >                 / privateuse         ; private use tag
> >                 / grandfathered      ; grandfathered registrations
> >
> > langtag         = (lang
> >                    *3("-" extlang)
> >                    ["-" script]
> >                    ["-" region]
> >                    *("-" variant)
> >                    *("-" extension)
> >                    ["-" privateuse])
> >
> > lang            = 2*4ALPHA           ; shortest ISO 639 code
> >                 / registered-lang
> >
> > registered-lang = 4*8ALPHA          ; registered language subtag
> >
> > extlang         = 3ALPHA             ; reserved for future use
> >
> > script          = 4ALPHA             ; ISO 15924 code
> >
> > region          = 2ALPHA             ; ISO 3166 code
> >                 / 3DIGIT             ; UN country number
> >
> > variant         = 5*8alphanum       ; registered variants
> >                 / ( DIGIT 3alphanum )
> >
> > extension       = singleton 1*("-" (2*8alphanum))
> >
> > singleton       = %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT
> >                 ; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9"
> >                 ; Single letters: x/X is reserved for private use
> >
> > privateuse      = ("x"/"X") 1*("-" (1*8alphanum))
> >
> > grandfathered   = 1*3ALPHA 1*2("-" (2*8alphanum))
> >                                     ; grandfathered registration
> >                                     ; Note: i is the only singleton
> >                                     ; that starts a grandfathered tag
> >
> > alphanum        = (ALPHA / DIGIT)   ; letters and numbers
> >
> >
> >
> > ------------------------------------------------------------------------
> --
> > -
> >
> > %% for -matching
> >
> > Language-Range
> >                 = langrange
> >                 / privateuse         ; private use tag
> >                 / grandfathered      ; grandfathered registrations
> >
> > langrange       = (lang
> >                    %%%%% I don't see why *3("-" extlang) is not included
> > here
> >                    ["-"script]
> >                    ["-" region]
> >                    *("-" variant)
> >                    %%%%% I don't see why *("-" extension) is not
> included
> > here
> >                    ["-" privateuse])
> >
> > lang            = 2*8ALPHA	%%%%%% I'm not sure about the non-trivial
> > differences from -registry here
> >                 / extlang
> >                 / "*"
> >
> > extlang         = 2*3ALPHA	%%%%%% I'm not sure about the non-trivial
> > differences from -registry here
> >                   *2("-" 3ALPHA)
> >                   ("-"(3ALPHA / "*"))
> >
> > script          = 4ALPHA             ; ISO 15924 code
> >                 / "*"
> >
> > region          = 2ALPHA             ; ISO 3166 code
> >                 / 3DIGIT             ; UN country number
> >                 / "*"
> >
> > variant         = 5*8alphanum       ; registered variants
> >                 / ( DIGIT 3alphanum )
> >                 / "*"
> >
> > privateuse      = ("x"/"X") 1*("-" (1*8alphanum))
> >
> > grandfathered   = 1*3ALPHA 1*2("-" (2*8alphanum))
> >                                     ; grandfathered registration
> >                                     ; Note: i is the only singleton
> >                                     ; that starts a grandfathered tag
> >
> > alphanum        = (ALPHA / DIGIT)   ; letters and numbers
> >
> > ------------------------------------------------------------------------
> --
> > --
> >
> > I'm not sure about some non-trivial differences; like why is
> > not "singleton" (and its reference) included in the -matching version?
> >
> >     /kent k
> >
> >
> >
> > _______________________________________________
> > Ltru mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ltru
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Addison Phillips" <[email-masked]>
Date: Tue, 19 Jul 2005 16:50:10 -0700

Sadly, I did catch it previously and put it on my edit list... and kept forgetting to make the change.

I did make the change when I saw Kent's email, so it should go away this time. Perchance you pointed this out before too, Frank?

Addison

Addison P. Phillips

---

From: "McDonald, Ira" <[email-masked]>
Date: Fri, 22 Jul 2005 10:55:43 -0700

Hi,

I strongly support replacing the ABNF with Kent's improved
stuff.

Martin is of course right to point out that a working group
'last call' can and should address major issues.  That does
not force a second working group 'last call', if the issues
are resolved by the usual 'rough concensus'.  

This differs from an IETF 'last call' (which can't change the 
substance without going back to the working group).

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf Of Martin Duerst
> Sent: Thursday, July 21, 2005 8:46 PM
> To: Mark Davis; Doug Ewell; LTRU Working Group
> Subject: Re: [Ltru] Re: Reference lists; AND ABNF GRAMMARS
> 
> 
> [chair hat on]
> 
> At 00:10 05/07/22, Mark Davis wrote:
>  >ABNF is tricky, and it is not trivial to 'pretty it up' 
> while maintaining
>  >precisely the same meaning. At this stage, we should only 
> be focusing on
>  >substantive issues, not whether the ABNF is pretty or not.
> 
> The last call isn't restricted to major issues. Both major 
> and cosmetic
> issues can and should be brought up, and if appropriate, 
> addressed during
> last call. So if there is a way to make the ABNF easier to understand
> (while making sure that it's still describing the same 
> syntax), then we
> (of course with WG (rough) consensus only) should do it.
> 
> This of course applies to other parts of the spec. In many WGs I have
> seen (maybe not in this one), WG Last Call is on purpose used to clean
> up loose editorial ends and work on cosmetics.
> 
> 
> Regards,    Martin.
> 
> p.s.: [chair hat off] I'll try to have a look at the new ABNF 
> from Kent,
>        but that may take a few days, sorry. 
> 
>