Re: [Ltru] A radical proposal (was: Re: extlang & deprecation)

["Randy Presuhn" <randy_presuhn at mindspring.com>]

Hi -

As a technical contributor...

> From: "John Cowan" <cowan at ccil.org>
> To: "Doug Ewell" <doug at ewellic.org>
> Cc: "LTRU Working Group" <ltru at ietf.org>
> Sent: Wednesday, July 02, 2008 10:23 AM
> Subject: Re: [Ltru] A radical proposal (was: Re: extlang & deprecation)
...
> > 3.  Change the prose (and ABNF if necessary) to specify that an 
> > "extlang" can be used either alone, as "cmn" (Y), or together with its 
> > Prefix, as "zh-cmn" (X-Y).  In other words, an "extlang" is a special 
> > type of "language" that has an optional Prefix.  Specify that the Y form 
> > is "preferred" and the X-Y form is "deprecated," using the clearly 
> > specified, watered-down definition of "deprecated" from item 1.
> 
> This breaks the invariant that subtags are deprecated iff they have a
> "Deprecated:" field, but that's tolerable (-16 makes all the extlangs
> deprecated with a Preferred-Value of themselves, interpreted as a full
> tag rather than as a subtag).
> 
> More seriously, though, it breaks the invariant that the syntactic slot
> "language" is filled only with "language" subtags.  Currently this
> invariant applies to all four kinds of subtags, and I think it's an
> important part of Getting It Right for people who haven't read all the
> fine print: once you clear away the grandfathered rubbish, you can just
> take the Cartesian product of the four lists of subtags as a rough guide
> to validity.
> 
> I would rather keep -16's scheme than this, frankly.

Though I think I see where the logic is going, I have the same trouble
with this part of the proposal.

> > 4.  Apply this logic to all encompassed languages, not just those 
> > belonging to a cherry-picked set of macrolanguages plus "sgn".  For 
> > extra credit, figure out how to make this work with changing ISO 639-3 
> > groupings.
> 
> This is where we go from Grotty Compromise to Seriously Nasty.  639-3 is
> free to change a language from independent to encompassed or vice versa
> at any time, and then the carefully crafted scheme goes down the toilet.
> 
> I continue to think that the best defense against cherry-picking
> complaints is to say we are doing this for backward compatibility,
> and we need backward compatibility only for "zh" and "sgn", period.

I'm sympathetic to this line of reasoning, but I find the analogy for things
like ar-arb too persuasive to fully agree to the limitation.

> (In this scheme I think it might make sense to restore the table from
> -14 that explains that the macrolanguage tag is preferred for Konkani,
> Malay, Swahili, and Uzbek.)

I think this would be a step in the wrong direction.  The macrolanguage
tag by itself should always have the meaning "this is some kind of X,
but we're not able / willing to say precisely which kind."

Randy

_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru