Re: [widgets] Last Call Comments

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 Monday, 6 July 2009 15:58:10 UTC