- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Thu, 17 Mar 2011 08:14:37 -0400
- To: marcosc@opera.com
- CC: "Phillips, Addison" <addison@lab126.com>, "public-webapps@w3.org" <public-webapps@w3.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>
[Ooops; Sent before read ... ] Marcos - Addison's comments were submitted during the comment period of a proposal to publish a new LCWD of this spec. I think that publication should be blocked until there is consensus on how to address the comments. -AB On Mar/17/2011 7:49 AM, ext Arthur Barstow wrote: > Marcos - Addison's comments were submitted during the comment period > of a proposal to publish a new LCWD of this spec. > > On Mar/17/2011 7:21 AM, ext Marcos Caceres wrote: >> (accidentally hit reply instead of reply all, so sending again) >> >> On Tue, Mar 15, 2011 at 4:41 PM, Phillips, >> Addison<addison@lab126.com> wrote: >>> Hello Webapps WG, >>> >>> (these are personal comments) >>> >>> I happened to be referring to the Widget spec this morning and >>> noticed a few minor items that I feel should be brought to your >>> attention. >>> >>> 1. Section 5.3 (Zip Relative Paths). The ABNF defines >>> "language-range". I think this is not desirable. Language ranges are >>> input to the matching algorithm (i.e. the user's request). You don't >>> really want paths like "locale/de-*-1901". You want concrete paths >>> here and "*" has no business in a path. Ideally you would reference >>> the "Language-Tag" production in BCP 47 (RFC 5646). However, since >>> it is a large production and you don't probably want to directly >>> incorporate it, you could incorporate the "obs-language-tag" >>> production in the same document instead. You should still say that >>> language tags used in paths "must" be valid language tags according >>> to the more formal production. >>> >> Valid point. I don't think anyone will complain if we change this. >> >>> 2. Section 5.3. The same production corresponds to BCP 47 (RFC 4647) >>> "extended-language-range", although it only allows the tags to use >>> lowercase letters. I really feel that mixed case is not that >>> difficult to support and that it will save many developers from >>> inexplicable silent failures. >>> >> This is true... however, most engines implemented the case sensitive >> requirement (implementers had concerns about Unicode case >> comparisons)). I think it might be hard to fix this one without >> breaking a bunch of runtimes and maybe content.... need to think about >> it. >> >>> 3. There is no mention of case sensitivity of filenames anywhere >>> that I can find. You should define if filenames are case sensitive >>> (or not) and what is meant by "case sensitive" if it is supported >>> (just ASCII case? Unicode default case mapping?) >>> >> Search for "case-sensitively" or "case-sensitive" instead. The >> case-sensitive requirement on files comes a fair bit. >> >> >
Received on Thursday, 17 March 2011 12:15:36 UTC