Re: Minor comments on Widgets

[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