On 3/17/11 1:43 PM, Robin Berjon wrote:
On Mar 17, 2011, at 20:21 , Marcos Caceres wrote:
On Tue, Mar 15, 2011 at 4:41 PM, Phillips, Addison<addi...@lab126.com> 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.
I agree. I would be weird to have some aspects work as case-sensitive
and other parts not.
I propose this be the rule (which is what we originally intended):
lang-tag = primary-subtag *( "-" subtag )
primary-subtag = 1*8low-alpha
subtag = 1*8(alphanum)
alphanum = low-alpha / DIGIT
low-alpha = %x61-7a
