Doug Ewell scripsit:
> 1. Provide an explicit definition for the word "deprecated" in BCP 47,
> something on the order of "There is another tag or subtag that means the
> same as this one, but is preferred, and validating processors will
> translate this subtag into the preferred equivalent. But nobody will
> beat you up or make you register with the police if you use the
> non-preferred one instead." Make sure other text in the draft does not
> contradict this.
I strongly support this idea, and I think it should appear early in the
document, for clarity. At the same time we should get rid of the use of
"supersede(d)" in favor of "deprecate(d)" everywhere.
> 2. Define all of the Y forms (e.g. "cmn") in the Registry as Type:
> extlang, none as Type: language. Bear with me here.
Presumably this is meant to exclude the ones which are already in as
languages? I don't think we want to allow sh-bos, for example.
> 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.
> 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.
(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've put on my asbestos tactical vest and am now ready for WG feedback.
> Please avoid personal attacks; they don't solve technical problems.
So here's my take: +1 on #1, -1 on the other ideas. Also, cherry-pick
zh and sgn only (-16 isn't specific, as this is an RFC 4645bis issue),
restore the -14 table of special-case macrolanguages.
--
John Cowan cowan at ccil.org http://ccil.org/~cowan
If he has seen farther than others,
it is because he is standing on a stack of dwarves.
--Mike Champion, describing Tim Berners-Lee (adapted)
_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.