Subject: [Ltru] ABNF beautification...

From: "Addison Phillips" <[email-masked]>
Date: Tue, 26 Jul 2005 17:13:37 -0700

I took Kent's suggestion for modifying and cleaning up the ABNF and made some changes to it. Mostly I removed extra rules from it, re-combining some things (per messages from Frank and I), and doing some gentle tugging. 

You will note that I renamed the production rule "lang" to "language". It puts the "extlang" production as an option on 2*3ALPHA subtags. The 4ALPHA production explicitly reserved here, which is an innovation in the ABNF but not in the text or overall meaning of the ABNF (previously we had 2*3ALPHA followed by extlang and 4*8ALPHA was registered lang and most recently the relationship of extlangs to the likely use of 4ALPHA ISO639-6 was discussed).

This ABNF is slightly cleaner than the current draft-09 ANBF (all the language subtag stuff is together, the extlang relationship is clear, the rule names are more expressive.

Here is the current result:

--
Language-Tag    = langtag
                / privateuse           ; private use tag
                / grandfathered        ; grandfathered registrations

langtag         = (language
                   ["-" script]
                   ["-" region]
                   *("-" variant)
                   *("-" extension)
                   ["-" privateuse])

language        = 2*3ALPHA [ extlang ] ; shortest ISO 639 code
                / 4ALPHA               ; reserved for future use
                / 5*8ALPHA             ; registered language subtag

extlang         = *3("-" 3ALPHA)       ; reserved for future use

script          = 4ALPHA               ; ISO 15924 code

region          = 2ALPHA               ; ISO 3166 code
                / 3DIGIT               ; UN M.49 code

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
--

This checks out via http://rtg.ietf.org/~fenner/abnf.cgi

Any comments? Can I get a hum to use this in preference to draft-09's version?

Addison

Addison P. Phillips
Globalization Architect, Quest Software
http://www.quest.com

Chair, W3C Internationalization Core Working Group
http://www.w3.org/International

Internationalization is not a feature.
It is an architecture. 

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

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 26 Jul 2005 18:23:25 -0700

It looks good to me. Note that for valid, non-grandfathered tags, where A
means alpha, D means digit, and E means A or D:

The first subtag:
- AA..AAAAAAAA is always a language
- 'x' is private use
- others are errors: E (!= 'x'), or EE..EEEEEEEE where any E is a digit

Between the first subtag and the first E:
- AAAA is always a script
- AAA is always an extlang
- AA or DDD is always a region
- AEEEE..AEEEEEEE, and DEEE..DEEEEEEE is always a variant
- others are errors: DD, and EE, EEE, AEEE if mixed (one E is an A and one
is a D)

‎Mark

----- Original Message ----- 
From: "Addison Phillips" <[email-masked]>
To: "LTRU Working Group" <[email-masked]>
Sent: Tuesday, July 26, 2005 17:13
Subject: [Ltru] ABNF beautification...

> I took Kent's suggestion for modifying and cleaning up the ABNF and made
some changes to it. Mostly I removed extra rules from it, re-combining some
things (per messages from Frank and I), and doing some gentle tugging.
>
> You will note that I renamed the production rule "lang" to "language". It
puts the "extlang" production as an option on 2*3ALPHA subtags. The 4ALPHA
production explicitly reserved here, which is an innovation in the ABNF but
not in the text or overall meaning of the ABNF (previously we had 2*3ALPHA
followed by extlang and 4*8ALPHA was registered lang and most recently the
relationship of extlangs to the likely use of 4ALPHA ISO639-6 was
discussed).
>
> This ABNF is slightly cleaner than the current draft-09 ANBF (all the
language subtag stuff is together, the extlang relationship is clear, the
rule names are more expressive.
> Here is the current result:

----------------------------------------------------------------------------
----

---

From: John Cowan <[email-masked]>
Date: Tue, 26 Jul 2005 21:29:07 -0400

Mark Davis scripsit:

> It looks good to me. 

+1
-- 
Long-short-short, long-short-short / Dactyls in dimeter,
Verse form with choriambs / (Masculine rhyme):  [email-masked]
One sentence (two stanzas) / Hexasyllabically   http://www.reutershealth.com
Challenges poets who / Don't have the time.     --robison who's at texas dot net

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 27 Jul 2005 06:23:59 +0200

>                 / grandfathered        ; grandfathered registrations
  ...............-X......................Y+

You could shift column X to the right (X-1), and column Y to
the left (Y+1) everywhere:

| Language-Tag   = langtag
|                / privateuse             ; private use tag
|                / grandfathered          ; grandfathered registrations
  ...............-X......................Y+

Then you would have the place for the recommended (2234(bis))
 
>                 / 5*8ALPHA             ; registered language subtag
  ...............-X......................Y+
| language       = (2*3ALPHA [ extlang ]) ; shortest ISO 639 code
|                / 4ALPHA                 ; reserved for future use
|                / 5*8ALPHA               ; registered language subtag
  
Only a lower case 2234-"recommended", and here it's probably
unnecessary.  Even 2234 didn't follow its own recommendation
for LWSP, and there it's less obvious than in <language>.

> Can I get a hum to use this in preference to draft-09's
> version?

IMHO it's better and clearer, and if we didn't destroy Kent's
original idea it should be also better for the version in the
matching draft.  The alpha4 case is also perfectly clear now.

                            Bye, Frank

---

From: r&d afrac <[email-masked]>
Date: Wed, 27 Jul 2005 08:10:47 +0200

For the records I oppose the exclusion ABNF for private use.

>Any comments? Can I get a hum to use this in preference to draft-09's version?

I note that Martin Duerst has not answered my mail explaining why this 
format is absurd.
As long as he has not, this Last Call cannot be closed.
jfc

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 26 Jul 2005 23:44:55 -0700

Hi -

> From: "r&d afrac" <[email-masked]>
> To: "Addison Phillips" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Tuesday, July 26, 2005 11:10 PM
> Subject: Re: [Ltru] ABNF beautification...
>

> As long as he has not, this Last Call cannot be closed.

Nonsense.  Procedural questions can be addressed by either of the
co-chairs or the AD.  There is nothing that requires him personally to
respond to any of your technical points; technical decisions are by
the rough consensus of the WG.  Your complaints about the syntax
for private use (sub)tags have been discussed at length. If you
believe that the co-chairs have mis-read the WG consensus,
you may appeal to our AD.

> jfc

Randy, ltru co-chair

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 27 Jul 2005 08:31:16 -0700

Hi -

There have been quite a few deltas in the "ABNF beautification", but
it sounds like there is quite a bit of support.  I'd like the editors to post
a message with the ABNF as they see it based on the comments so far,
and I'd like to hear from the rest of the WG participants on whether they
support or oppose the revision, in order to be clear whether there is
indeed a rough consensus to make this change.

Randy, ltru co-chair

---

From: r&d afrac <[email-masked]>
Date: Thu, 28 Jul 2005 04:40:37 +0200

At 08:44 27/07/2005, Randy Presuhn wrote:
> > format is absurd.  As long as he has not, this Last Call cannot be closed.
>
>Nonsense.  Procedural

I repeat for the records my position:

1. the RFC 3066 bis intended Draft would organises a de facto exclusive on 
language identification, and by way of commercial iteration, on language 
industry (cf. one of the question of one of the co-Chairs), to the benefit 
of dominant publishers by refusing to include in the langtag the name of a 
language referent, and by wanting to replace BPC 47 while it claims to 
restrict it, rather than complement it (what it could do in the particular 
case of the users utilising the products and solutions of the members of 
the consortium of such dominant publishers).

2. the Draft organises a definite exclusion of alternative tagging system 
in making sure that every private system using its "x-" private use escape 
sequence will run into every risk of conflict in leaving it - in toto - 
only an ... 8 alphanums name space to support the right of billions of 
users to privately document 20.000 languages and their own possibly quasi 
unlimited languages variants, in every region of the world, etc. Some even 
having the contempt (how else qualify this?) to say that such a format (8 
alphanums) may support every other format in adding ad libitum 8 alphanums 
labels separated by a dash.

3. the WG-ltru has organised this in full knowledge of this problem and of 
the existence of competitive solutions and projects, however they are 
supported by running code and by public and private investors, are 
conforming or wanting to conform with ISO 11179 and to be multilingual, and 
after having been explained that whole project constitutes an unfair 
business practice that will be legally objected and would badly harm the 
internet in reducing the IANA credibility as a common un biased clearing house.

4. that this position has been made clear for eight months, has never been 
discussed except through the answer "it has been discussed before" by half 
a score of main participants to the WG and one of the co-Chairs. This 
position has been repeated during the WGLC and has lead one of the co-chair 
to request it to be documented (what has been done and is here repeated) 
without any resulting debate or humming.

5. The remark that the WGLC cannot be closed without this point being 
satisfactorily addressed has been qualified of "nonsense" by the 
other  co-Chair. In that case RFCs make clear that the responsibility to 
decide, and to document on appeal, if there is a consensus to refute this 
position is to the co-Chairs. To help them I will compile and document the 
statistics of the WGLC once it is completed.

jfc