Subject: RE: [Ltru] [psg.com #1097] ABNF cleanup in matching draft

From: "Addison Phillips" <[email-masked]>
Date: Tue, 16 Aug 2005 09:13:12 -0700

Comments interlinear, extra text removed.

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

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> 
> > Extension matching is a separate issue and may have arcane rules.
> > Draft-registry and draft-matching both say that. We can, of course,
> > including singletons into the ABNF, if anyone feels strongly about it.
> >
> > Modifying the matching ABNF requires adding wildcards in just the right
> > way. Here is what I have so far:
> 
> :: Note that one comment below also refers to the -registry draft.
[Addison Phillips] 

This refers to the square brackets around [ extlang ], about which I comment below. I think the change is purely editorial and does not have an effect on the draft-registry.
> 
> > extended-language-range  = range ; a range
> >               / privateuse              ; private use tag
> >               / grandfathered           ; grandfathered registrations
> :: Oddly this one got a strange name change for the lhs nonterminal.
[Addison Phillips] 

I don't understand this comment, nor ones like it lower in the document. Are you saying you don't like the rule names (left-hand side IDs)? Please specify what it should say.

> :: If we are to change the names of nonterminals whose formal language
> :: is changed, I'd suggest doing so more systematically (P for Pattern):
> ::Language-TagP = langtag-p
[Addison Phillips] 

The matching document refers to an "Extended Language Range". It is not, emphatically, a "Language Tag"; it can have wildcards, for example.

I don't like mysterious suffix letters. I don't see why the names can't be exactly alike here.

> 
> > range         = (language
> >                  ["-" script]
> >                  ["-" region]
> >                  *("-" variant)
> >                  *("-" extension)
> >                  ["-" privateuse])
> :: This one too got a strange name change for the lhs nonterminal.
[Addison Phillips] 

This is actually the range (the document is talking about ranges). I don't see that as "strange".

> :: If we are to change the names of nonterminals whose formal language
> :: is changed, I'd suggest doing so more systematically. It also has
> :: "*("-" extension)" though Addison has removed the productions for
> :: the nonterminal "extension". Though still odd to me, if "extension"
> :: is not to be covered in any way, it must also be removed here.
[Addison Phillips] 

The document is in a draft mode. I didn't modify text yet, pending discussion on the list.

> 
> > language      = "*"                    ; wildcard or...
> >               / (2*3ALPHA [ extlang ]) ; shortest ISO 639 code
> >               / 4ALPHA                 ; reserved for future use
> >               / 5*8ALPHA               ; registered language subtag
> :: This one did not get a name change for the lhs nonterminal.
> :: But if we are to change the names of nonterminals whose formal language
> :: is changed, I'd suggest doing so systematically, also for this one.
[Addison Phillips] 

The subtag names I purposely did not change.

> :: Further, I like to have the wildcard as the last alternative (like it
> was).
[Addison Phillips] 

I do too, and will make the change...

> :: AND, the [] around extlang are superfluous, as I think Frank already
> :: pointed out FOR THE -REGISTRY DRAFT, with an "of course" from Addison.
[Addison Phillips] 

They are superfluous, but I deliberately chose to keep them, since they make the optional nature of extlangs clear. Bill Fenner's ABNF validator likes them, so I kept them.

> 
> > extlang       = *2("-" 3ALPHA) ("-" ( 3ALPHA / "*"))
> >                                        ; reserved for future use
> >                                        ; wildcard can only appear
> >                                        ;   at the end
> :: Further, I like to have the wildcard as a separate last alternative.
> ::extlang-p     = *3("-" 3ALPHA)         ; reserved for future use
> ::              / *2("-" 3ALPHA) "-*"    ; wildcard, can only appear
> ::                                       ;   at the end
[Addison Phillips] 

These are semantically equivalent and neither is very pleasing: both ABNF versions are non-obvious, which I think it bad. Your change is more consistent with the style of the rest of the ABNF, though, so I'll make that change.

[Addison Phillips] 

Remaining comments removed, as they are repetitions of the above.

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

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 16 Aug 2005 20:15:25 +0200

Addison Phillips wrote:

> Are you saying you don't like the rule names (left-hand side
> IDs)? Please specify what it should say.

Apparently Kent proposes to refelect the tag ABNF as closely
a possible, add -p to all names (LHS) where you add "-*" to
the RHS.  If possible it's a consitent approach.  Of course
you can also use -range instead of -p.

> I don't see why the names can't be exactly alike here.

You'd need different names for a hypothetical combined ABNF:

With a "-*" anywhere a parser would say "range" (if it's
correct), without "-*" it would get a normal language tag.

I'm not sure if that's Kent's idea.  If yes I doubt that it
works as expected, a range without any wildcard is still a 
range, the hypothetical combined grammar would be ambiguous
for this case.

> Bill Fenner's ABNF validator likes them, so I kept them.

Are you talking about the following ?

    extracted = (2*3ALPHA [ extlang ])
    extlang   = *2("-" 3ALPHA) ("-" ( 3ALPHA / "*"))

These square brackets are not superfluous, in this version
<extlang> can't be empty.   They are unnecessary in the
registry draft.  With Kent's strategy "make the grammars as
similar as possible" your only option is to keep them also
in the registry draft.  Besides that draft is now *FROZEN*
unless the IESG or IETF last call finds a serious issue.

>>> extlang       = *2("-" 3ALPHA) ("-" ( 3ALPHA / "*"))
[...]
>> Further, I like to have the wildcard as a separate last
>> alternative.
>> extlang-p     = *3("-" 3ALPHA)         
>>               / *2("-" 3ALPHA) "-*"

> These are semantically equivalent and neither is very
> pleasing: both ABNF versions are non-obvious, which I think
| is bad.
> Your change is more consistent with the style of the rest of
> the ABNF, though, so I'll make that change.

Please use a grouping as recomended in 2234(bis): 
 
 extlang   = *3("-" 3ALPHA)         
           / ( *2("-" 3ALPHA) "-*" )

After you've done that the result isn't much better than what
you have, so maybe just keep it as it is... ;-)  Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 16 Aug 2005 20:50:08 +0200

[...]
>            / ( *2("-" 3ALPHA) "-*" )

Oops, there is a major difference, the latter can be empty,
and then the square brackets would be in fact unnecessary
in both grammars as Kent and you said.  Still okay to keep
them.  For Kent's other vision "as similar a possible" the
latter is better, it preserves "can be empty".

Switching to hardcore nitpicking mode, what we really want
is square brackets combined with 1*3( "-" 3ALPHA ) instead
of *3( "-" 3ALPHA ) in the registry draft => "never empty".

If "somehow" this "missing" 1 "appears" after your AUTH48
in 3066bis it would be a major step forward for humankind
and the "lilly-guild" (not talking about Bruce).  Bye, Frank

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 16 Aug 2005 12:10:18 -0700

Hi -

Rather than artificially re-opening the WG last call, I suggest that if the
poster believes strongly that this is important, it can be submitted
as an IETF last call comment.  In the meantime, the WG of course
is free to determine whether there is merit to this comment, in
order to minimize the time required to process the potential IETF
last call comment, if it is made.  That way, if necessary, we can
include an appropriate note to the IESG in our publication request.

Randy, ltru co-chair

> From: "Frank Ellermann" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, August 16, 2005 11:50 AM
> Subject: [Ltru] Re: [psg.com #1097] ABNF cleanup in matching draft
>

---

From: "Kent Karlsson" <[email-masked]>
Date: Tue, 16 Aug 2005 21:59:09 +0200 (CEST)

Frank got the analysis of my message right.

Yes, I want the grammars as similar as ever possible,
but still combinable. Frank is also right about the
[] and emptyness possibility.

B.t.w. I don't like the term "range" for something
that is more like what is usually called a "pattern".

Further, in a language tag pattern like

sr-*

there is no way of telling if the * stands for
"any 'extended language'", "any script", "any region",
or "any variant".

But for

sr-*-Cyrl

the * stands for "any 'extended language'".

While in

sr-*-1900

the * may stand for "any 'extended language'",
"any script", or "any region". (But not combined?)

Does this matter? Or are the patterns on purpose ambiguous?
If not, the different kinds of wildcards need differing syntax,
e.g. a script wildcard could be *s, and a region wildcard could
be *r (or whatever other differing syntax strikes your fancy).

   /kent k

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 17 Aug 2005 00:43:27 +0200

Kent Karlsson wrote:

> in a language tag pattern like
> sr-*

> Does this matter?

Yes, the matching draft has to say what this means.
We have three choices:

left-to-right, the -*- would be for extended language
in all your examples.

left-to-right plus default -*-.  With that approach
we get sr-* = sr-*-*-*-*, dito
sr-*-CYRL = sr-*-CYRL-*-*, dito
sr-*-1900 = sr-*-*-*-1900

default -*-, then we get sr = sr-* and sr = sr-*-*-*-*,
so sr-* is pointless, the same as sr (?!?)

Reflecting the intended semantics in syntax could be a
PITA, but it has to be done at least in prose.  Addison
said "RTFID", I do that later, maybe it's already clear.

> a script wildcard could be *s, and a region wildcard
> could be *r (or whatever other differing syntax strikes
> your fancy).

We're not supposed to update the HTTP RfC, so that could
be difficult or impossible.

With 3066, was it ever allowed or possible to have more
than one -*- in a range ?  If not, was it ever possible
or allowed to have a -*- within a range (not at the end) ?

If a * or -* was always at the end (and at most one) the
project "matching-draft" could be really tricky.

                         Bye, Frank