Re: Urgent: Fwd: [widgets] Last Call Comments

Hi Art,
I've got word from Martin that he is satisfied with the changes to the 
spec. Please cite this response in the Disposition of Comments as the 
commenter accepting the changes.

Kind regards,
Marcos

On 7/7/09 2:37 PM, Arthur Barstow wrote:
> Martin - please respond to Marcos' email to you by July 9th at the
> latest and please public-webapps@w3.org.
>
> -Regards, Art Barstow
>
>
> Begin forwarded message:
>
>> From: ext Marcos Caceres <marcosc@opera.com>
>> Date: July 6, 2009 11:57:10 AM EDT
>> To: public-webapps <public-webapps@w3.org>
>> Cc: Martin Nilsson <nilsson@opera.com>
>> Subject: Re: [widgets] Last Call Comments
>> Reply-To: "marcosc@opera.com" <marcosc@opera.com>
>> Archived-At:
>> <http://www.w3.org/mid/b21a10670907060857h3bd46695q3ae494f94d7700c3@mail.gmail.com>
>>
>>
>> Hi Martin,
>>
>> Inline comments below.
>>
>> For the sake of the Disposition of Comments, please let us know ASAP
>> if you are satisfied with the working group's responses below (by
>> Thursday if possible).
>>
>> On Mon, Jun 15, 2009 at 5:12 PM, Marcos Caceres<marcosc@opera.com> wrote:
>>> Section 5.3: Why not mandate all paths to be UTF-8? I really hate the
>>> notion
>>> of "If an author chooses to use cp437-chars or the UTF8-chars, they
>>> should
>>> thoroughly test their widgets on various platforms prior to
>>> distribution".
>>> No, it should work if you follow the specification.
>>
>> I agree, this sucks. But doing what you say would mean that special
>> custom tools would need to be built for creating widget packages
>> (i.e., authors could not use the zipping tool bundled with either
>> Windows, Mac, Linux, etc.). Please see my ramblings about this:
>> http://datadriven.com.au/2008/12/08/zip-files-and-encoding-i-hate-you/
>>
>>> Secondly, why case insensitive? And if so, how would a user agent
>>> treat an
>>> archive with several entries that just differ in case?
>>
>> Right, I've removed the word "case-insensitively". That section is
>> only concerned with with zip-relative-paths, but not the actual files.
>>
>>> This also looks redundant
>>>
>>> "A CC must inform the author of any Zip relative paths whose length
>>> exceed
>>> 250 bytes
>>>
>>> A CC must inform an author of any Zip relative path whose length
>>> exceeds 120
>>> bytes."
>>
>> Yes, the first was dropped.
>>
>>> Section 9.1: The rules for identifying the media type of a file doesn't
>>> explicitly mention that it could have been explicitly set from the
>>> configuration file. This is mentioned in the section below that
>>> references
>>> this, but perhaps a mention for clarity would be good.
>>
>> I've added the following note:
>>
>> "Note: This rule is only to be applied when explicitly instructed to
>> by the specification. There are situations where alternative means are
>> defined by the specification to identify the media type of a file
>> (e.g., by the presence of the content element's type attribute or
>> deriving the media type of a default start file from the default start
>> files table)."
>>
>>> As a sidenote it looks like it's not possible to define the mime type of
>>> other files than the start page. I find that a big oversight, if true.
>>
>> This is true. However, we did not find a use case for setting the MIME
>> type of files other than the start file. Which other files do you
>> think it would be important to set the MIME type for in this version
>> of the specification?
>>
>>> Another thing. In the Zip Support section of 3.1 it says that it is
>>> optional
>>> for a user agent to support "Any decompression algorithm, other than
>>> [Deflate] and Stored (no compression) [ZIP]." However in 5.1 it is
>>> stated
>>> that "Only compress Zip archives with [Deflate] or Stored (no
>>> compression);
>>> other compression formats will cause the widget package to be treated
>>> as an
>>> invalid Zip archive.".
>>>
>>> So you can optionally select something different than deflate and
>>> store, but
>>> that will cause the package to be invalid?
>>
>> Woops. This was a mistake in the authoring guideline. The actual
>> processing of the widget package does not cause processing to stop. A
>> conformance checker warns if it finds file entries compressed with
>> proprietary compression algorithms, but that is not disallowed by the
>> user agent.
>>
>> I've fixed the authoring guideline:
>>
>> "Authoring Guideline: Authoring Guideline: To ensure interoperability,
>> compress file entries in Zip archives with [Deflate] or Stored (no
>> compression); other compression methods can result in in the Zip
>> archive being treated as an invalid Zip archive."
>>
>> --
>> Marcos Caceres
>> http://datadriven.com.au
>>

Received on Thursday, 9 July 2009 15:44:11 UTC