W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: [widgets] P&C Last Call comments, 6

From: Marcos Caceres <marcosc@opera.com>
Date: Tue, 2 Jun 2009 16:44:28 +0200
Message-ID: <b21a10670906020744p1d9ccf6hcfe5f799857e8cb6@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT