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

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.

> 
> 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.

Regards,
Maciej


> 
> -Thanks, AB
> 
> On 11/6/12 9:22 AM, ext Chris Wilson wrote:
>> I'm also not quite as clear that we need a joint deliverable - although I understand the reasoning, anything that increases the number of potential masters/peanut gallery seems like a detracting factor.  I'd prefer to make it a clear deliverable of one group - and don't have a strong take on which group it should be.  Chaals' questions nailed it, for me - if there's someone who can't join one group or another, but we want to have involved, that would guide the decision.
>> 
>> I do think that the current appcache spec should stay in HTML5, regardless - it's broadly implemented, and useful for a particular (sub)set of scenarios today.  I don't know if I'm completely convinced that what is needed is a whole new next-gen appcache API, or targeted changes to the current API; but either way, the current API is a reality.
>> 
>> 
>> On Tue, Nov 6, 2012 at 6:07 AM, Charles McCathie Nevile <chaals@yandex-team.ru <mailto:chaals@yandex-team.ru>> wrote:
>> 
>>    On Tue, 06 Nov 2012 14:47:32 +0100, Arthur Barstow
>>    <art.barstow@nokia.com <mailto:art.barstow@nokia.com>> wrote:
>> 
>>        Hi All - I've been thinking about "who is going to do what and
>>        when?" re AppCache.NG, and below is a series of related Q&As.
>> 
>> 
>>    They look good to me (modulo the joint deliverable idea). In
>>    particular, I agree that I was optimistic in saying we could take
>>    this under the existing charter. I infer an action item for me to
>>    draft a new webapps charter proposal.
>> 
>> 
>>        As I worked through a plan and next steps, I started to think
>>        that since it could be unwise or even potentially harmful to
>>        extract AppCache from HTML5,
>> 
>> 
>>    Maybe... Certainly, for all its faults, appcache is widely
>>    implemented so the existing spec should stay *somewhere* - if it
>>    gets pulled, it probably makes a good NOTE if we're not going to
>>    directly build on top of it.
>> 
>> 
>>        I concluded it may be best to make AppCache.NG a joint
>>        deliverable between WebApps and HTMLWG. As such, my Q&As
>>        reflect a joint deliverable for AppCache.NG.
>> 
>> 
>>    I don't understand why. Frankly I don't care - there is some
>>    overhead in coordination but not much, and it seems likely that
>>    people in HTML are interested in Appcache. I don't share the
>>    opinion of some that HTML is not a group where you can do work.
>>    The question for me comes down to:
>>    1. Is there someone in HTML who is not in Webapps, won't join it,
>>    and is important to the discussion? And more importantly
>>    2. Where does whoever does the actual work here do it?
>> 
>>    cheers
>> 
>>    Chaals
>> 
>> 
>>        Please let me know your thoughts on these points, especially
>>        the relationship between these two groups for AppCache.NG.
>> 
>>        -Thanks, AB
>> 
>>        P.S. I didn't cross-post this to the CG or the two WGs since
>>        this is basically a strawman proposal to see if "I heard what
>>        you heard" last week. However, if you want to forward this to
>>        any of those lists, that's fine with me.
>> 
>> 
>>        <Q&A>
>> 
>>        * What is the status of AppCache for the HTMLWG's
>>        HTML5.REC-track spec? AppCache will be marked as a Feature At
>>        Risk in HTML5.REC-track.
>> 
>>        * Where will work on UCs and Requirements for AppCache.NG be
>>        done? UCs and Reqs work for AppCache.NG will be lead by the
>>        Fixing AppCache CG using their public-fixing-appcache list. We
>>        expect that work to be direct input into the specification of
>>        AppCache.NG.
>> 
>>        * Currently, are there any concrete proposal(s) for the
>>        AppCache.NG spec? No, although Jonas Sicking indicated he will
>>        make a proposal.
>> 
>>        * Which WG will lead the specification of AppCache.NG? WebApps
>>        (see #WebApps-mins and #HTMLWG-mins).
>> 
>>        * Which e-mail list will be used for technical discussion
>>        about the AppCache.NG spec? public-webapps (Subject: prefix
>>        [appcache]).
>> 
>>        * Will the AppCache.NG spec be included in HTML5.REC-track or
>>        in a standalone Extension spec? This depends on a number of
>>        factors including when AppCache.NG is stable, its level of
>>        implementation, its level of interoperability, etc.
>> 
>>        * Which WG will publish AppCache.NG? WebApps & HTMLWG will
>>        jointly publish AppCache.NG since it will be a joint
>>        deliverable between the two groups.
>> 
>>        * Will WebApps need a charter update to formally add AppCache?
>>        Yes (see #WebApps-charter).
>> 
>>        * Will AppCache.NG be identified as a joint deliverable in
>>        both WebApps' and HTMLWG's charters? Yes.
>> 
>>        #WebApps-mins
>>        <http://www.w3.org/2012/10/30-webapps-minutes.html#item06>
>>        #HTMLWG-mins
>>        <http://www.w3.org/2012/11/01-html-wg-minutes.html#item02>
>>        #WebApps-charter <http://www.w3.org/2012/webapps/charter/>
>> 
>>        </Q&A>
>> 
>> 
>> 
>> 
>>    --     Charles McCathie Nevile - Consultant (web standards) CTO Office,
>>    Yandex
>>    chaals@yandex-team.ru <mailto:chaals@yandex-team.ru>         Find
>>    more at http://yandex.com
>> 
>> 
> 

Received on Friday, 9 November 2012 16:48:59 UTC