Re: [Ltru] Re: Remove extlang from ABNF?

Felix Sasaki <fsasaki@w3.org> Wed, 12 December 2007 13:25 UTC

Return-path: <ltru-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Ral-0000HS-7y; Wed, 12 Dec 2007 08:25:39 -0500
Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1J2Raj-0000HN-Ln for ltru-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 08:25:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Raj-0000HF-Bv for ltru@ietf.org; Wed, 12 Dec 2007 08:25:37 -0500
Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Raf-0001cw-Aa for ltru@ietf.org; Wed, 12 Dec 2007 08:25:37 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id F33652BC2A; Wed, 12 Dec 2007 22:25:21 +0900 (JST)
Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro.w3.mag.keio.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRtQq04D3+1I; Wed, 12 Dec 2007 22:25:21 +0900 (JST)
Received: from [127.0.0.1] (p5011-ipad402marunouchi.tokyo.ocn.ne.jp [222.146.117.11]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id B307C2BC1F; Wed, 12 Dec 2007 22:25:21 +0900 (JST)
Message-ID: <475FE141.8010601@w3.org>
Date: Wed, 12 Dec 2007 22:25:21 +0900
From: Felix Sasaki <fsasaki@w3.org>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Martin Duerst <duerst@it.aoyama.ac.jp>
Subject: Re: [Ltru] Re: Remove extlang from ABNF?
References: <E1J01vI-0003cW-Rd@megatron.ietf.org> <019601c83818$b06c3070$6601a8c0@DGBP7M81> <DDB6DE6E9D27DD478AE6D1BBBB83579561E51429AA@NA-EXMSG-C117.redmond.corp.microsoft.com> <6.0.0.20.2.20071211163740.0a090850@localhost> <475E8342.1080206@w3.org> <DDB6DE6E9D27DD478AE6D1BBBB83579561E52A6F79@NA-EXMSG-C117.redmond.corp.microsoft.com> <475F2439.6020007@w3.org> <6.0.0.20.2.20071212153653.0ae521d0@localhost>
In-Reply-To: <6.0.0.20.2.20071212153653.0ae521d0@localhost>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: LTRU Working Group <ltru@ietf.org>
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
Errors-To: ltru-bounces@ietf.org

Martin Duerst wrote:
> At 08:58 07/12/12, Felix Sasaki wrote:
>
>   
>> As I said before, the I18N core Working Group within W3C proposed to the XML Schema Working Group to refer to the ABNF from RFC 4646. I had a call with someone from the XML Schema working group this morning, and it seems they are various opinions in the XML Schema Working Group about how to refer to language tag specs:
>>
>> 1) refer to a specific spec, e.g. RFC 3066 (this is what is currently at http://www.w3.org/TR/xmlschema-2/#language , i.e. a reference to RFC 3066)
>> 2) make no type constraint, just refer to the (ISO) language codes
>> 3) say that a validator needs to check current version of language code spec if it wants to do the right thing (where "needs" doesn't have any normative power), and providing the necessary reference for  that.
>>
>> The current tendency within the XML Schema Working Group is that they might go for 3) and replace the reference to 3066 with a reference to BCP 47.
>> However, the pattern for validation of the language data type will probably not be changed, it will stay as RFC 3066 like
>>
>> [a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*
>>     
>
> This is very much the right way to go. There is no point for a
> using spec to be too detailled in terms of the syntax. And
> for the semantics, pointing to BCP 47 is the best thing to do.
>
> But I don't think this solves the problems for us.
>
> In RFC 4646, we defined some tags as well-formed. In RFC 4646bis, we suddenly
> say that some of these tags are not well-formed. We never would do this for
> valid tags, so I'm really not sure it is a good thing to do for well-formed tags.
>   
+1

Felix



_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru