Subject: [Ltru] Editorial error in BNF

From: John Cowan <[email-masked]>
Date: Mon, 23 May 2005 19:42:12 -0400

The BNF rule for lang still says 2*3ALPHA instead of 2*4ALPHA, even though
section 2.2.1 bullet 4 says that 4ALPHA tags are reserved for future
standardization.

The BNF should be fixed.

-- 
John Cowan <[email-masked]>     http://www.reutershealth.com
But no living man am I!  You look upon a woman.  Eowyn I am, Eomund's daughter.
You stand between me and my lord and kin.  Begone, if you be not deathless.
For living or dark undead, I will smite you if you touch him.

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

---

From: "Peter Constable" <[email-masked]>
Date: Tue, 24 May 2005 09:07:23 -0700

> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Addison Phillips

> 2*3ALPHA describes assigned subtags (i.e. subtags that are valid).
4ALPHA
> is reserved for future standardization and are not valid currently.
That's
> the reason I didn't change the ABNF, although I'm not religious about
it.
> The opposite case is easy enough to make.

It's not at all obvious if and how a 639-6 standard would get integrated
into a successor to RFC3066. An obvious concern is that there isn't a
clean fit into the morphology of 3066bis.

Consider what *kinds* of entities are denoted. For comparison, in the
case of 639-3 the entities denoted all correspond to lang or
lang-extlang productions in 3066bis, and in the latter case how it would
fit with the morphology is clear: a 639-1/-2/-3 ID in the lang subtag
and a 639-3 ID in the extlang subtag where the two have a macrolanguage
mapping defined in 639-3. But samples from the proposed code table for
639-6 indicate that *many* kinds of entities will be denoted. These
could correspond to the following bits of morphology in 3066bis:

lang
lang-extlang
lang-*-script
lang-*-*-region
lang-*-*-*-variant
lang-*-region-variant
lang-script-*-variant (for orthographic variants)

(I leave the asterisks in to reflect the potential need for those
intervening subtags to be combinable with an 639-6 ID.) It's not at all
clear how the 639-6 IDs would interact with this morphology, though it
is clear that there'd be a big issue with synonym.

Plus there would be a large number of IDs for non-terminal nodes in
language-classification trees, like the collections of 639-2 and 639-5,
which really wouldn't be that useful in IETF language tags.

Given some pretty major issues that would need to be worked out and
which nobody here has given any thought to that I know of, my
inclination in *this* revision would be to make no reference to the
possibility of 4alpha in the lang subtag. The 639-6 project is still in
very early stages; there isn't a complete working draft yet. When it
gets to an advanced stage (at least CD, more probably DIS -- enough so
that we really know what it will look like and can estimate when it will
be completed), then we can begin to consider a further revision to
incorporate it.

Peter Constable

---

From: "Peter Constable" <[email-masked]>
Date: Tue, 24 May 2005 09:10:06 -0700

On
> Behalf Of Mark Davis

> One of the goals of the project was that the BNF never needs to be
changed
> in the future; that every current parser must be able to read every
future
> tag. (You've reminded me of this on occasion!) So it must be changed
to
> 2*4

See my comments in another msg just sent: I do not think at this point
we can know what the syntax for language tags that incorporate an ISO
639-6 standard would look like, so I think the requirement that devs be
able to anticipate that future syntax with certainty now is impossible.

Peter Constable

---

From: "Peter Constable" <[email-masked]>
Date: Tue, 24 May 2005 09:55:41 -0700

My point is that it's not even clear that the *lang* subtag is where
these would go. But I guess I don't care if you want to allow for
possible 4alpha subtags that *might* be defined some day; it just seems
rather speculative. If someone suggested we might someday allow
4alphanum (not purely alpha or purely num) in the region slot, would we
go ahead and define the syntax for that now?

Peter Constable

> -----Original Message-----
> From: Addison Phillips [mailto:[email-masked]]
> Sent: Tuesday, May 24, 2005 9:38 AM
> To: Peter Constable; [email-masked]
> Subject: RE: [Ltru] Editorial error in BNF
> 
> We wouldn't define the syntax or even the source for alpha4 primary
> language subtags. It would work thusly:
> 
> 1. The ABNF defines lang=2*4ALPHA / 5*8alphanum
> 2. The text defines that ALPHA2 and ALPHA3 subtags are defined by ISO
639-
> 1 and ISO 639-2.
> 3. The text says that ALPHA4 subtags are reserved for future
> standardization. Implementations know that four letter subtags might
be
> added to the registry in the future.
> 
> Implementations know already how to deal with the primary language
> subtag(the semantics of ISO 639-6 are not important here) and must be
> written to handle registered subtags with length two through eight.
> Ultimately this has no impact on implementations: the only effect this
has
> is that there won't be any four letter primary language subtags in the
> registry. Well, it has one effect: a primary language subtag with a
length
> of four that contains a digit is illegal.
> 
> In other words, your caution that we should wait to see ISO 639-6
before
> standardizing it in language tags is well taken, but not important at
this
> juncture. We are merely reserving a location in the registry for those
> values. Standardization of 3066-based language tags on ISO 639-6 might
> never happen or will at least happen in its own time. The exact same
can
> be said about ISO 639-3.
> 
> 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-----
> > Behalf Of Peter Constable
> > Sent: 2005?5?24? 9:10
> > To: [email-masked]
> > Subject: RE: [Ltru] Editorial error in BNF
> >

---

From: "Addison Phillips" <[email-masked]>
Date: Tue, 24 May 2005 10:36:38 -0700

> go ahead and define the syntax for that now?

Yes. It would break the design to do that, of course.

> possible 4alpha subtags that *might* be defined some day; it just seems

The consensus seemed to be: we know that ISO 639-6 is being worked on. The material is not mature enough to incorporate into 3066bis. However, we can make a very minor marginal allowance for the possibility of ISO 639-6 being of value in forming language tags at some future date and the only cost is forbidding the registration of alpha4 subtags for now.

A future update could incorporate ISO 639-6 in an appropriate way or restore the ability to register alpha4 subtags or, as you say, allow registration of alphanum4 subtags.

In other words, there is no cost to do it and it was a consensus to reserve a slot in case it becomes interesting/necessary in the future. I'm not going to defend ISO 639-6 here: I am actually skeptical about the effort, but there is no reason to prevent ISO 639-6 from being easily incorporated at a future date.

Addison

Addison P. Phillips

> From: [email-masked] [mailto:[email-masked]] On
> Sent: 2005?5?24? 9:56

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 24 May 2005 22:16:25 -0700

For what it is worth, I will go on record as saying the following:

I do not believe the mechanism described in draft-ietf-ltru-registry-*
is intended only for XML, or suitable only for XML.  I believe it is
suitable for many different tagging purposes, only one of which is XML.

I do not believe the mechanism is supported only by "W3C people."

I do not believe the concept of "script" is undefined, or even poorly
defined, either in the draft or anywhere else.

And I do not believe anyone secretly wants to "kill the project."  Those
who want it to fail have been very public about it.

--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/