[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



It sounds reasonable to me.

Mark

On Tue, Jul 1, 2008 at 10:34 PM, Doug Ewell <doug at ewellic.org> wrote:
What about this:
(Warning: some of these suggestions are radical, but meant to reach a workable accord)

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.

2.  Define all of the Y forms (e.g. "cmn") in the Registry as Type: extlang, none as Type: language.  Bear with me here.

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.

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 would allow both extlangistas and non-extlangistas to tag as needed to achieve the desired matching and fallback behavior, and would solve Addison's concern about being able to normalize without the Registry, since all valid tags of form XX(X)-YYY could be normalized to YYY blindly.  Determining validity in the first place still requires the Registry, but there is no way around that anyway.

Part 3 prevents needless and confusing duplication in the Registry, a problem which would be made worse by Part 4.

Part 4 removes arbitrariness, partly to help this document survive IETF LC, but also for its own sake.  I am sensitive to Addison's point that we should have as few duplicate tags as possible, but I still feel this is an adequate compromise, in which the extlangistas concede the formal "preferability" of the non-extlangy forms but reserve the right to use the easily normalized, deprecated forms that they prefer without being branded with a scarlet D.

Parts 2 and 3 must be implemented together or not at all.  Part 1 is severable from the rest, not all that radical, and probably a good idea no matter what else we do.  Part 4 is also severable from the rest.

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.

--
Doug Ewell  *  Arvada, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

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

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