- From: Marcos Caceres <marcosc@opera.com>
- Date: Tue, 2 Jun 2009 16:44:28 +0200
- To: Marcin Hanclik <Marcin.Hanclik@access-company.com>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>
On Tue, Jun 2, 2009 at 3:50 PM, Marcin Hanclik <Marcin.Hanclik@access-company.com> wrote: > 9.1 > a user agent must to decompress ... > should be > a user agent must decompress ... fixed > ... instructions on how to extract a file for Zip archive. > should be > ... instructions on how to extract a file from Zip archive. fixed > The rule for dealing with an invalid Zip archive is described in this section. > </p><p> could follow this sentence as in the previous subsection. > Rule for finding a file within a widget package > > If none if found > should be > If none is found fixed > ... the name of the path ( > could be > ... the path ( fixed > Rule for finding a file within a widget package: algorithm > > 3.B If path points to a file entry within the widget package, then return the corresponding file. > should be > 3.B If path points to a file entry within the widget package, let file be the result of applying the rule for extracting file data from a file entry to path. > And maybe jump to 4.B or terminate as 4.B and 4.C do. I added a new 3.C: "If file is a processable file, then return file and terminate this algorithm. " > An unusable file entry is one where by any of following conditions occur/apply ... > should be > An unusable file entry is one where any of following conditions occur/apply I rewrote that section, as it was a bit of a mess. It now just returns true or false. > Rule for Getting Text Content > > "Let input be the [DOM3Core] Element to be processed." > Unclear: Where does the [DOM3Core] Element come from? Step 7, "Let doc be the result of loading the widget config doc as a [DOM3Core] Document using a [XMLNS]-aware parser." > Probably some assignment like: > "the element to be processed MUST be interpreted as [DOM3Core] Element" > would help. Removed the reference. Added your text: "The rule for getting text content is given in the following algorithm. The element to be processed must be interpreted as a [DOM3Core] Element. The algorithm always returns a string, which may be empty." > "Return the value of the textContent property for input." > Where does the textContent property come from? [http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent ? ] > right > " There may be implementation-specific limits on the range of integers allowed, and behavior outside such limits is undefined." > What about interoperability, again. See Robin's email, again. > Rule for Identifying the Media Type of an Image > > ... the first bytes of the file matches one of ... > should be > ... the first bytes of the file match one of ... Fixed > ... in hexadecimal column of .. > and > ... in the second column ... Right, I changed it to the the "magic number column" and "media type column" > both should be revisited, since the column names seem not to match the text. (Are the columns indexed from 0?) > Fixed. > "A 0 word following by a 1 word," > Endianness is unclear. Removed "A 0 word following by a 1 word". > The rule for identifying the media type of a file are given by ... > should be > The rule for identifying the media type of a file is given by ... Fixed > 1. Let file be the file to be processed. ... > could be > 1. Let filename be the name of the file to be processed. > 2. If filename includes a file-extension, attempt ... I think file is correct here. > attempt to match the file-extension to one in the first column > should be > attempt to match the file-extension to one of the strings in the first column Fixed > Comments as above for "Rule for Identifying the media type of a file". > As above. -- Marcos Caceres http://datadriven.com.au
Received on Tuesday, 2 June 2009 14:45:29 UTC