Re: Comments on Widgets spec

Le mardi 07 juillet 2009 à 19:53 +0200, Marcos Caceres a écrit :
> For the sake of the Disposition of Comments, please let us know if you
> are satisfied with the fixes below (if possible, by the 9th of July).

I'm mostly satisfied, but see a few comments below.

> On Fri, Jun 12, 2009 at 6:35 PM, Dominique Hazael-Massieux<dom@w3.org> wrote:
> > Hi,
> >
> > 5.3 Zip Relative Paths has the following bugs:
> >  * the ABNF for zip-rel-path uses "localized-folder", but only
> > "locale-folder" is defined
> 
> Fixed, updated, and simplified. Can you please check the new ABNF?

Looks good; checked it with http://www.quut.com/abnfgen/

> >  * the third rule for the conformance checker should be:
> >  "A CC must inform the author of any Zip relative paths whose length
> > exceed 120 characters" (rather than "bytes").
> 
> Fixed.

You also removed the rule to inform about relative path whose length
exceed 250 bytes - was that on purpose?

> > http://www.w3.org/TR/widgets/#conformance-checker-behavior4 seems to be
> > misplaced under 7.2 instead of 7.3
> 
> Fixed. Moved to section 8 (the document sections got reshuffled to
> make the document easier to read). See:
> http://dev.w3.org/2006/waf/widgets/#conformance-checker-behavior4

(for sake of the DoC, it was actually moved to section 9.2.1, at
http://dev.w3.org/2006/waf/widgets/#conformance-checker- )

> > There are quite a few aspects that make a zip archive an invalid widget
> > described in the processing section, but which are not highlighted as
> > conformance checker requirements, e.g:
> >  * Step 1  labels an archive with a wrong media type as invalid
> 
> Added to Media Type section:
> [[
> Conformance Checker Behavior
> A CC MUST inform the author if a widget package is not being served
> from a remote location with the valid widget media type.
> ]]
> 
> >  * Step 2 adds as cause of invalidity "split"-zips, and encrypted-zips
> > (beyond the already noted requirements on version and compression
> > method)
> 
> Added to Invalid Zip Archive section:
> [[
> Conformance Checker Behavior
> 
> A CC must inform the author that a Zip archive that is split into
> multiple files or spans multiple volumes, as defined in the [ZIP]
> specification, is an invalid zip archive.
> 
> A CC must inform the author that a Zip archive that is encrypted
> (which is denoted by bit 0 of the general purpose field being set and
> by the presence of archive decryption header and an archive extra data
> record, all three of which are defined in the [ZIP] specification), is
> an invalid zip archive.
> 
> A CC must inform the author that a Zip archive that contains zero file
> entries is an invalid zip archive.
> 
> A CC must inform the author that a Zip archive that contains only
> folders is an invalid zip archive.
> ]]
> 
> >  * requirements on the configuration file (XML well-formed, vocabulary
> > constraints)
> > (and probably more)
> >
> Instead of writing conformance checking for every element and
> attribute, I wrote the following Conformance Checker Behavior:
> 
> [[
> 
> A CC should process a configuration document using the algorithm to
> process a configuration document. However, where an element or
> attribute is in error, or invalid, the conformance checker must inform
> the author.
> 
> A CC may validate a configuration document against the Relax NG for
> the configuration document.
> ]]

Looks good, thanks!

Dom

Received on Wednesday, 8 July 2009 09:26:59 UTC