> > 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. We would have to do this. Further, we'd need to make stability rules related to it and these would likely be somewhat complicated. You wouldn't want only some of the enclosed languages of a macrolanguage to be included, for example. This is, basically, a lot of the messy logic from draft-14 that we scrapped to get the current compromise position. Only more so. > 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 themseFrom ltru-bounces at ietf.org Wed Jul 2 10:59:48 2008 Return-Path: <ltru-bounces at ietf.org> X-Original-To: ltru-archive at megatron.ietf.org Delivered-To: ietfarch-ltru-archive at core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 958CE3A696D; Wed, 2 Jul 2008 10:59:48 -0700 (PDT) X-Original-To: ltru at core3.amsl.com Delivered-To: ltru at core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 054703A6880 for <ltru at core3.amsl.com>; Wed, 2 Jul 2008 10:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.687 X-Spam-Level: X-Spam-Status: No, score=-103.687 tagged_above=-999 required=5 tests=[AWL=-1.088, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnG9pSkTAwvx for <ltru at core3.amsl.com>; Wed, 2 Jul 2008 10:59:46 -0700 (PDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) by core3.amsl.com (Postfix) with ESMTP id 6BBA33A687E for <ltru at ietf.org>; Wed, 2 Jul 2008 10:59:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,738,1204502400"; d="scan'208";a="3733318" Received: from smtp-in-5102.iad5.amazon.com ([10.218.9.29]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jul 2008 17:59:51 +0000 Received: from ex-hub-4101.ant.amazon.com (ex-hub-4101.ant.amazon.com [10.248.163.22]) by smtp-in-5102.iad5.amazon.com (8.12.11/8.12.11) with ESMTP id m62HxmIA006560 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 2 Jul 2008 17:59:49 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.28]) by ex-hub-4101.ant.amazon.com ([10.248.163.22]) with mapi; Wed, 2 Jul 2008 10:59:48 -0700 From: "Phillips, Addison" <addison at amazon.com> To: John Cowan <cowan at ccil.org>, Doug Ewell <doug at ewellic.org> Date: Wed, 2 Jul 2008 10:59:46 -0700 Thread-Topic: [Ltru] A radical proposal (was: Re: extlang & deprecation) Thread-Index: AcjcaGzBJejSjEP4Tsm6FR/+jC9K8gAAw+Dg Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA013B882ED3 at EX-SEA5-D.ant.amazon.com> References: <94CC471674DE4119B6E1FC4AA47929C3 at DGBP7M81> <20080702172357.GR31666 at mercury.ccil.org> In-Reply-To: <20080702172357.GR31666 at mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: LTRU Working Group <ltru at ietf.org> Subject: Re: [Ltru] A radical proposal (was: Re: extlang & deprecation) X-BeenThere: ltru at ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request at ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ltru> List-Post: <mailto:ltru at ietf.org> List-Help: <mailto:ltru-request at ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request at ietf.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ltru-bounces at ietf.org Errors-To: ltru-bounces at ietf.org > > 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. We would have to do this. Further, we'd need to make stability rules related to it and these would likely be somewhat complicated. You wouldn't want only some of the enclosed languages of a macrolanguage to be included, for example. This is, basically, a lot of the messy logic from draft-14 that we scrapped to get the current compromise position. Only more so. > 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, inlves, interpreted as a > full > tag rather than as a subtag). We have two semantics of "deprecated" at work here: we allow subtags to be formally deprecated with a Preferred-Value (that's the current setup). But Doug is talking about deprecating specific tag forms (which the registry would have a hard time indicating). Hence all my blather about canonical in my last email. > > 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. This is certainly a Good Thing about the current design. In fact, my current implementation relies on it rather heavily and I think is somewhat elegant because of it. All this extra mappy cruft from the registry makes for fairly ugly complications. > > 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. Hence: stability rules. The problem being that these are likely to be complicated. Something like: - if a language is assigned and it has a macrolanguage and that macrolanguage's other encompassed languages are extlangs, then so is this one. - if a language is changed to be encompassed and the macrolanguage's other encompassed languages are extlangs, then so is this one. - if a language is changed from encompassed to individual and it is an extlang, it remains an extlang (old tags still valid), but the extlang form is deprecated (somehow?) - if a language was at some point encompassed by one language and later by another language, file a complaint retag your data as "und". > > 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. +1 > (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.) +1 Addison _______________________________________________ Ltru mailing list Ltru at ietf.org https://www.ietf.org/mailman/listinfo/ltru terpreted as a > full > tag rather than as a subtag). We have two semantics of "deprecated" at work here: we allow subtags to be formally deprecated with a Preferred-Value (that's the current setup). But Doug is talking about deprecating specific tag forms (which the registry would have a hard time indicating). Hence all my blather about canonical in my last email. > > 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. This is certainly a Good Thing about the current design. In fact, my current implementation relies on it rather heavily and I think is somewhat elegant because of it. All this extra mappy cruft from the registry makes for fairly ugly complications. > > 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. Hence: stability rules. The problem being that these are likely to be complicated. Something like: - if a language is assigned and it has a macrolanguage and that macrolanguage's other encompassed languages are extlangs, then so is this one. - if a language is changed to be encompassed and the macrolanguage's other encompassed languages are extlangs, then so is this one. - if a language is changed from encompassed to individual and it is an extlang, it remains an extlang (old tags still valid), but the extlang form is deprecated (somehow?) - if a language was at some point encompassed by one language and later by another language, file a complaint retag your data as "und". > > 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. +1 > (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.) +1 Addison _______________________________________________ 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.