W3C home > Mailing lists > Public > www-archive@w3.org > November 2012

Re: Draft: Plan and next steps for AppCache.NG

From: Arthur Barstow <art.barstow@nokia.com>
Date: Fri, 09 Nov 2012 12:27:26 -0500
Message-ID: <509D3CFE.2000403@nokia.com>
To: ext Maciej Stachowiak <mjs@apple.com>, Charles McCathie Nevile <chaals@yandex-team.ru>, Tobie Langel <tobie@fb.com>
CC: ext Chris Wilson <cwilso@google.com>, Philippe Le Hégaret <plh@w3.org>, Mike Smith <mike@w3.org>, Doug Schepers <doug@w3.org>, Paul Cotton <Paul.Cotton@microsoft.com>, Sam Ruby <rubys@us.ibm.com>, Robin Berjon <robin.berjon@gmail.com>, Jonas Sicking <sicking@mozilla.com>, Adrian Bateman <adrianba@microsoft.com>, Marcos Caceres <w3c@marcosc.com>, Jake Archibald <jaffathecake@gmail.com>, www-archive@w3.org
On 11/9/12 11:47 AM, ext Maciej Stachowiak wrote:
> On Nov 6, 2012, at 7:12 AM, Arthur Barstow <art.barstow@nokia.com> wrote:
>> Re the joint deliverable - I'm not a big fan of them either but an assumption I made is -> if AppCache.NG is embedded in someversion of HTML, then WebApps couldn't publish it without explicit consent of the HTMLWG. It seemed a bit strange that WebApps could publish a version of HTML so I presumed some type of joint deliverable with HTMLWG would be neededbut if not, that's certainly OK with me (and preferred actually).
> I don't think a joint deliverable is needed,


> nor is embedding of AppCache.NG in some version of HTML needed or especially desirable.

I guess time will tell but that's good to know.

>> Re the fate of AppCache.AsImplementedToday and HTML5.0, I*thought* the discussion last week indicated AppCache.NG could  indeed - at least in theory - replace AppCache.AsImplementedToday in HTML5.0. Did I get that wrong? (Regardless, I agree the Draft Q&As need some clarification re the HTML numberingand the pragmatic expectations for AppCache.AsImplementedToday.)
> Here's what I expect:
> - HTML 5.0 will continue to include its current definition of AppCache at least for now, as there are multiple implementations and content using it.
> - AppCache will be marked "at risk", not because we believe the current spec lacks implementations, but because it's possible that a Web Apps WG spec will completely supersede the current section before HTML5 exits CR.
> - Web Apps WG will work on an AppCache.NG spec using the HTML5 "applicable specifications" clause for extensions - this allows it to either build on the existing AppCache spec, or strike it and entirely replace it. HTML5 explicitly allows extensions to remove or replace part of the spec.
> - If Web Apps WG produces a sufficiently complete and advanced AppCache.NG which fully replaces the AppCache section of HTML5 (as opposed to building on it), and this occurs sufficiently before HTML5 exits CR, then we could choose to remove the current AppCache section from HTML5 to avoid having two conflicting specs.
> None of this requires a joint deliverable, or textual embedding of AppCache.NG in HTML5 or any future version of HTML. If the community developing AppCache.NG decides at some future point that they'd like to reintegrate it into the main HTML spec, either for 5.0 or a future version, we do have a process for that. But I would personally not recommend it, because I think we are better served by more granular specifications instead of a kitchen sink spec.

The points above all WFM.

What is your expectation re the role or non-role of the Fixing AppCache 
CG re AppCache.NG? Will the CG close and _all_ AppCache.NG work be done 
by WebApps (on public-webapps)? Will the CG have some role e.g. working 
on UCs and Requirements? [I just noticed it's a relatively small group 
(31 people) although I didn't try to intersect the mail lists.]

(BTW, I agree with those that interpret WebApps' charter such that the 
charter will need to be formally updated to add AppCache.NG.)

-Thanks, AB
Received on Friday, 9 November 2012 17:30:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:34:38 UTC