> > > This is where #3 is a non-starter for me: it requires us to > > change all of the matching schemes in ways that are > > incompatible with our previous tenets. > > We already have to. There's no way you can compare cmn with zh-HK > or vice versa (if you want to) withouFrom ltru-bounces at ietf.org Tue Jul 1 11:44:41 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 05A923A6BB6; Tue, 1 Jul 2008 11:44:41 -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 8B4E53A6BB6 for <ltru at core3.amsl.com>; Tue, 1 Jul 2008 11:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.539 X-Spam-Level: X-Spam-Status: No, score=-105.539 tagged_above=-999 required=5 tests=[AWL=1.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 po3wVxDa35tz for <ltru at core3.amsl.com>; Tue, 1 Jul 2008 11:44:38 -0700 (PDT) Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) by core3.amsl.com (Postfix) with ESMTP id 8CF9E3A6BB5 for <ltru at ietf.org>; Tue, 1 Jul 2008 11:44:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,732,1204502400"; d="scan'208";a="80041774" Received: from smtp-in-0201.sea3.amazon.com ([172.20.19.24]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jul 2008 18:44:48 +0000 Received: from ex-hub-4101.ant.amazon.com (ex-hub-4101.ant.amazon.com [10.248.163.22]) by smtp-in-0201.sea3.amazon.com (8.12.11/8.12.11) with ESMTP id m61IilYC020932 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 1 Jul 2008 18:44:47 GMT Received: from ex-pub-4102.ant.amazon.com (10.248.180.20) by ex-hub-4101.ant.amazon.com (10.248.163.22) with Microsoft SMTP Server (TLS) id 8.1.263.0; Tue, 1 Jul 2008 11:44:47 -0700 Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.28]) by ex-pub-4102.ant.amazon.com ([10.248.180.20]) with mapi; Tue, 1 Jul 2008 11:44:25 -0700 From: "Phillips, Addison" <addison at amazon.com> To: Shawn Steele <Shawn.Steele at microsoft.com>, Peter Constable <petercon at microsoft.com>, LTRU Working Group <ltru at ietf.org> Date: Tue, 1 Jul 2008 11:44:45 -0700 Thread-Topic: extlang & deprecation (was draft updated Thread-Index: AcjSvbtyGak94BzbROi83Ty/WYVRDQIwsqJQAAS91iAAAng7gAACp0Gw Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA013B7B4250 at EX-SEA5-D.ant.amazon.com> References: <C51F9153327D4470A0DDA6726CBB7A10 at DGBP7M81> <20080619035712.GI32073 at mercury.ccil.org> <6.0.0.20.2.20080620155949.06087920 at localhost> <DDB6DE6E9D27DD478AE6D1BBBB8357956338F0C9FF at NA-EXMSG-C117.redmond.corp.microsoft.com> <4D25F22093241741BC1D0EEBC2DBB1DA013B7B4015 at EX-SEA5-D.ant.amazon.com> <C9BF0238EED3634BA1866AEF14C7A9E561C81B5EC5 at NA-EXMSG-C116.redmond.corp.microsoft.com> In-Reply-To: <C9BF0238EED3634BA1866AEF14C7A9E561C81B5EC5 at NA-EXMSG-C116.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Ltru] extlang & deprecation (was draft updated 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 > > > This is where #3 is a non-starter for me: it requires us to > > change all of the matching schemes in ways that are > > incompatible with our previous tenets. > > We already have to. There's no way you can compare cmn with zh-HK > or vice versa (if you want to) without modifyt modifying the doc. (laughing) Sure you can: they don't match. Not even if you canonicalize in the other direction (to zh-cmn). You can create, of course, a proprietary matching scheme that recognizes that there is some relationship between these two tags/ranges. But this is somewhat similar to Mark's famous handling of Breton and French. That is, "en-US" and "en-boont" don't match, even though, obviously, there is some kind of relationship between them. > > > I didn't have to change the matching code because I > > canonicalize tags and ranges before matching. With a deprecation, > > the registry provides all of the information for this using > > the same mechanism I already use for mapping > > The registry could provide similar equivalence for you, without > deprecation, since you find the registry useful. Ah... but I already have a validating implementation that produces the "right" result via tag canonicalization (something I'm permitted to do to a tag or range). The distinction is that we'd be introducing a *separate* process only done in tag matching? Ick. I find the registry useful for validation, but don't ignore the fact that I don't need the registry to peel off the macrolanguage from an extlang in a well-formed implementation. Requiring the registry for matching is a deep fundamental change to matching: one that I feel requires separate algorithm(s), not modifications to the existing ones. > > > "Better" may not be the right word. "Preferred" would better > > describe the situation. Either form may be better for *your* > > application (or mine), depending on circumstances. > > That's not the definition of Deprecate: > > So I have a hard time reading "deprecated" as being "allowed" to > use either form, it seems that people would "pray" that I wouldn't > use the deprecated form and "belittle" the implementation if a > deprecated form was used :) > Deprecated is not forbidden. It will never go away, but it might not produce the results that you want in *all* situations (cf. matching using 3066 implementations). Addison Addison Phillips Globalization Architect -- Lab126 Internationalization is not a feature. It is an architecture. _______________________________________________ Ltru mailing list Ltru at ietf.org https://www.ietf.org/mailman/listinfo/ltru ing the doc. (laughing) Sure you can: they don't match. Not even if you canonicalize in the other direction (to zh-cmn). You can create, of course, a proprietary matching scheme that recognizes that there is some relationship between these two tags/ranges. But this is somewhat similar to Mark's famous handling of Breton and French. That is, "en-US" and "en-boont" don't match, even though, obviously, there is some kind of relationship between them. > > > I didn't have to change the matching code because I > > canonicalize tags and ranges before matching. With a deprecation, > > the registry provides all of the information for this using > > the same mechanism I already use for mapping > > The registry could provide similar equivalence for you, without > deprecation, since you find the registry useful. Ah... but I already have a validating implementation that produces the "right" result via tag canonicalization (something I'm permitted to do to a tag or range). The distinction is that we'd be introducing a *separate* process only done in tag matching? Ick. I find the registry useful for validation, but don't ignore the fact that I don't need the registry to peel off the macrolanguage from an extlang in a well-formed implementation. Requiring the registry for matching is a deep fundamental change to matching: one that I feel requires separate algorithm(s), not modifications to the existing ones. > > > "Better" may not be the right word. "Preferred" would better > > describe the situation. Either form may be better for *your* > > application (or mine), depending on circumstances. > > That's not the definition of Deprecate: > > So I have a hard time reading "deprecated" as being "allowed" to > use either form, it seems that people would "pray" that I wouldn't > use the deprecated form and "belittle" the implementation if a > deprecated form was used :) > Deprecated is not forbidden. It will never go away, but it might not produce the results that you want in *all* situations (cf. matching using 3066 implementations). Addison Addison Phillips Globalization Architect -- Lab126 Internationalization is not a feature. It is an architecture. _______________________________________________ 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.