Urgent: Fwd: [widgets] Last Call Comments

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 Tuesday, 7 July 2009 12:39:35 UTC