Subject: RE: [Ltru] ISO 639-6 (was: Great Script Debate Part II: Formats...)

From: "Addison Phillips" <[email-masked]>
Date: Tue, 12 Apr 2005 08:06:40 -0700

I don't think we need to do anything positive or negative about ISO 639-6 currently. The current draft doesn't prevent adoption of it, if it were to become a standard and be useful in language tags. Let's let Debbie/et al do their work and evaluate the results. Note that this is the same thing we are doing for ISO 639-3. If people feel super strongly about this, then let's change the ABNF in the draft to:

lang = 2*8ALPHA  ; primary language subtags

This leaves, as I see it, just a few remaining issues in the draft:

1. Location and handling of scripts.
2. Inclusion (or not) of French descriptions.
3. Handling of deprecation and canonical mapping in regions.

If we could focus on reaching consensus on those, we could at least put out a fresh draft -01.

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 L.Gillam
> Sent: mardi 12 avril 2005 02:23
> To: ltru
> Subject: RE: [Ltru] Great Script Debate Part II: Formats...
> 
> 
> There are two things that apply here - harmonisation and data fusion.
> The definitions of these two are varied, so in this instance
> harmonisation can refer to determining the general principles between
> these various systems (-4) which can provide for data fusion, described
> in a certain quarter recently as merging datasets based on common values.
> The upper layers of the Linguasphere and what is proposed for 639-5 are,
> based on a small sample, highly interoperable. "gaps" such as there may
> be can be reconciled because of construction based on slightly differing
> characteristics, and where characteristics do differ needs to be
> documented.
> Whether this is a -4 or -6 task, at an abstract level, is open for
> discussion.
> -3 and -5 provide a means for disambiguating -1/-2 as I perceive them. -6,
> then, maps to the upper layers provided in this quadruple and provides
> its most specific contribution at levels of variety in
> written/spoken/signed
> and subcomponents thereof. I would consider that these systems provide
> validation for each other and in combination are a very good basis
> for informed theoretical discussion and practical application. Perhaps
> I'm slightly biased!
> 
> Of course, this doesn't answer the "show us" requirement, and we do need
> to pull everything together fairly soon. Perhaps we should be posting
> to this list a bit less frequently!
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On
> > Behalf Of John Cowan
> > Sent: 12 April 2005 03:53
> > To: Debbie Garside
> > Cc: [email-masked]
> > Subject: Re: [Ltru] Great Script Debate Part II: Formats...
> >
> >
> > Debbie Garside scripsit:
> >
> > > At present, other than the information that I gave last
> > year outlining the
> > > system (which basically stands), it would not be a good
> > idea for me to
> > > reveal too much (perhaps my ISO/BSI colleagues currently
> > monitoring this
> > > list can help here... I don't know the ISO protocol on this).
> >
> > I think that the most important point for this list is: is there going
> > to be a normative mapping between -6 tags and -1/-2 tags, and if so,
> > will -3 and -5 tags be mapped when those parts are available?  Or is
> > the basis for -6 irreconcilable (not in principle but in detail) with
> > the unified model of -1/-2/-3/-4/-5?
> >
> > --
> > You let them out again, Old Man Willow!                 John Cowan
> > What you be a-thinking of?  You should not be waking!
> > [email-masked]
> > Eat earth!  Dig deep!  Drink water!  Go to sleep!
> > www.reutershealth.com
> > Bombadil is talking.
> > www.ccil.org/~cowan
> >
> > _______________________________________________
> > 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: Frank Ellermann <[email-masked]>
Date: Tue, 12 Apr 2005 18:05:58 +0200

> lang = 2*8ALPHA  ; primary language subtags

At the moment it's:

lang            = 2*3ALPHA         ; shortest ISO 639 code
                  / registered-lang
registered-lang = 4*8ALPHA         ; registered language subtag

If the idea is to reserve alpha-4 for ISO 639-6, how about:

lang            = 2*4ALPHA         ; shortest ISO 639 code
                  / registered-lang
registered-lang = 5*8ALPHA         ; registered language subtag

Your text says about registered-lang tags (none at the moment):

| MAY be used to form the primary language subtag
[...]
| future registrations of this type will be discouraged:
| primary languages are STRONGLY RECOMMENDED for registration
| with ISO 639 and subtags rejected by ISO 639 will be closely
| scrutinized before they are registered with IANA.

In other words NOT RECOMMENDED, please use lower case instead
of STRONGLY, screaming doesn't help with RfC 2119.  Why do we
need registered-lang at all ?  The old i-whatever was good
enough for this purpose.  You would get a much simpler ABNF,
and the old i-whatever system is automagically discouraging.

Just say (modulo "shortest" if necessary for ISO 639-6):
lang            = 2*4ALPHA         ; shortest ISO 639 code

Remove registered-lang everywhere.  Then fix the registration
procedures to allow new IANA i-whatever tags.  For the ABNF
that means:

1 - insert "individual" between "private-use / gradfathered"
2 - lang = 2*4ALPHA, remove "registered-lang" in "lang"
3 - remove registered-lang
4 - replace 1*3ALPHA in "grandfathered" by 2*3ALPHA, strip the
    singleton i- comment from "grandfathered"
5 - add a new "individual" before "grandfathered":
    individual = "i" 1*2("-" (2*8alphanum))

In the procedures replace "registered-lang" by "individual",
mention that an "individual" tag is deprecated when a proper
ISO 639 tag is introduced.

The tag reviewer has accepted several obscure tags for fantasy
Macao-languages, it's time to stop this nonsense in 3066bis.

The old i-whatever was better for dubious tags.  Bye, Frank

---

From: John Cowan <[email-masked]>
Date: Tue, 12 Apr 2005 12:05:10 -0400

Addison Phillips scripsit:

> I don't think we need to do anything positive or negative about ISO
> 639-6 currently. The current draft doesn't prevent adoption of it,
> if it were to become a standard and be useful in language tags. Let's
> let Debbie/et al do their work and evaluate the results. Note that
> this is the same thing we are doing for ISO 639-3. If people feel
> super strongly about this, then let's change the ABNF in the draft to:

I just want to make sure that there is no collision between a registered
subtag and an ISO 639-6 code.  The simplest way to achieve this is to
require that registered language subtags have at least 5 characters.

> lang = 2*8ALPHA  ; primary language subtags

We could do that and then add a prose requirement that no language subtag
less than 5 characters in length can be registered.

-- 
Well, I have news for our current leaders       John Cowan
and the leaders of tomorrow: the Bill of        [email-masked]
Rights is not a frivolous luxury, in force      http://www.ccil.org/~cowan
only during times of peace and prosperity.      http://www.reutershealth.com
We don't just push it to the side when the going gets tough.  --Molly Ivins