On Mar 17, 2011, at 20:21 , Marcos Caceres wrote: > On Tue, Mar 15, 2011 at 4:41 PM, Phillips, Addison <[email protected]> wrote: >> I happened to be referring to the Widget spec this morning
Out of curiosity: in what context? >> 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. +1, it's a bug. >> 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. I would very much prefer that we stuck with case-sensitive; I think that developers can handle that trivially. -- Robin Berjon - http://berjon.com/
