- From: Marcos Caceres <marcosc@opera.com>
- Date: Wed, 8 Jul 2009 15:20:44 +0200
- To: Dominique Hazael-Massieux <dom@w3.org>
- Cc: public-webapps@w3.org
On Wed, Jul 8, 2009 at 11:26 AM, Dominique Hazael-Massieux<dom@w3.org> wrote: > 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/ Tried, but failed to get it to work :( However, validates on this service: http://apps.mrochek.com/abnf.html >> > * 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? Yes, on purpose. We already had this one: "A CC must inform the author of any Zip relative path whose length exceeds 120 characters." >> > 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- ) right. >> > 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 > > > > -- Marcos Caceres http://datadriven.com.au
Received on Wednesday, 8 July 2009 13:23:10 UTC