W3C home > Mailing lists > Public > public-html@w3.org > April 2008

RE: Feedback on "Offline Web Applications" (Editor's Draft 17 November 2007)

From: Chris Wilson <Chris.Wilson@microsoft.com>
Date: Tue, 22 Apr 2008 13:28:30 -0700
To: Anne van Kesteren <annevk@opera.com>, Julian Reschke <julian.reschke@gmx.de>, "public-html@w3.org" <public-html@w3.org>
Message-ID: <E35CF0CC5D011D49943F61E242AF48AD02C7BC5B7F@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
Out of curiousity, why does this draft refer to the SQL API but not the storage interface?  Is storage not also a solution to local data storage?

-----Original Message-----
From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Anne van Kesteren
Sent: Tuesday, April 22, 2008 6:42 AM
To: Julian Reschke; public-html@w3.org
Subject: Re: Feedback on "Offline Web Applications" (Editor's Draft 17 November 2007)


On Sun, 18 Nov 2007 19:54:35 +0100, Julian Reschke <julian.reschke@gmx.de>
wrote:
> below is some feedback on "Offline Web Applications" (Editor's Draft 17
> November 2007) (<http://dev.w3.org/html5/offline-webapps/>).

Thanks.

Since there was some interest in this draft I got ACTION-58 to address the
feedback given in this e-mail.


> Summary: if the intent of this is to make people aware of the presence
> of these new things in HTML5, it's working. However, in it's current
> state it really requires the reader to go to the real spec to understand
> what's going on -- that may be ok, but in this case it would be helpful
> if it could point directly to the section of HTML5 containing the full
> details.

I added the two relevant pointers to the introduction section:

   http://dev.w3.org/html5/offline-webapps/#introduction



> Content:
>
> 2. SQL -- Not being familiar with what is being defined, I found the
> example a bit confusing. If this is meant to be an introduction, I think
> it would make sense to (1) show the DB creation first and (2) add a few
> sentences about how the API exactly looks like. So what elements does
> openDatabase() take(), why does db.transaction take a function argument,
> what exactly does the executeSQL function expect parameter-wise?

Done.


> 3. Offline Application Caching APIs -- seems the spec defines a new text
> format for defining the application caching. Is there a MIME type being
> defined? Any grammar for the format? Turns out this is defined in
> <http://www.w3.org/html/wg/html5/#manifests>, so it's probably fine to
> leave it out here. However, *what* is defined over there ("Note: This is
> a willful double violation of RFC2046.") makes me nervous. Not sure why
> this isn't simply an XML format; instead of defining yet another special
> text format with (IMHO) quite obscure parsing rules (CR only as line
> delimiter???)

This seems to be feedback on HTML 5 rather the note so I'm unable to
address this.


> 3. Offline Application Caching APIs -- not sure that using "server.cgi"
> as a name is a good idea over here; my understanding was that Cool URIs
> Do Not Change, thus encoding some technology-specific extension into an
> URI generally is not a good idea. Suggest to simply use something like
> "events".

I think "server.cgi" more accurately indicates it takes a URI than if we
just used the "events" so I left at is. (If the technology changes a
permanent redirect can be used or you simply change the type using a
ForceType directive or something like that. Should not be much trouble.)


> Editorial:
>
> - The Javascript examples do not terminate statements with a semicolon.
> My understanding is that although it's legal, it's discouraged (see
> <http://www.jslint.com/lint.html>). Minimally, it's confusing to read
> for people who have grown up with C and Java.

I like writing JavaScript that way, but I got another example that
included them. So this is addressed now.


> - "...that takes up one mebibyte of storage." -- Typo?

This no longer appears in the draft. (It was not a typo though, a mebibyte
is the "official" name for 1024^2 bytes.)


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Tuesday, 22 April 2008 20:28:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:54 UTC