Re: Normative Dependency and the Seven Drafts (was: Canvas API Editors)

On Mon, Aug 17, 2009 at 10:46 PM, Doug Schepers<schepers@w3.org> wrote:
> Hi, Shelley-
>
> Shelley Powers wrote (on 8/17/09 9:42 PM):
>>
>> On Mon, Aug 17, 2009 at 8:11 PM, Doug Schepers<schepers@w3.org>  wrote:
>>>
>>>  Shelley Powers wrote (on 8/17/09 6:50 PM):
>>> >
>>>>
>>>>  but splitting it out into a spin off is probably OK. I'm not
>>>>  quite sure how these spin-offs work, especially from a deadline
>>>>  perspective.
>>>
>>>  In this instance, I'm not certain myself.  I'd expect that in order for
>>> it
>>>  to be included in HTML5, it will still need an aggressive schedule,
>>> without
>>>  which it might lose relevance... it might just get shipped in HTML5
>>> anyway,
>>>  if we don't resolve the outstanding issues quickly.  I don't want it to
>>> slow
>>>  down HTML5, and I don't think anyone else does either.
>>
>> A concern with this is that what happens if the accessibility effort
>> is going to require a significant chunk of time and work?
>>
>> I'm not sure splitting the text out but tying it into the HTML 5 spec
>> really buys us anything. Let's say folks want to extend the 2D API
>> later -- does the work need to occur through the HTML WG? Does it rely
>> on the release of a new version of HTML?
>>
>> I just don't understand how these spin-offs work. Sorry.
>
> It's not really the spin-off aspect that is the issue, it's the maturity
> along the Recommendation Track.  The same situation applies to the
> XmlHttpRequest (XHR) spec, which was never part of HTML5, but which has a
> normative dependency on aspects of the HTML5 spec (that is, XHR references
> HTML5 for an essential part of its functionality).
>
> Here are the steps of the Recommendation track:
>
> 1) Editor's Draft (ED): not really part of the Rec track, but a normal
> step... this is where the Canvas API spec is right now, a sort of unofficial
> sketchpad by the WG.
>
> 2) First Public Working Draft (FPWD): the first official publication of the
> spec by the WG... this is also one of 2 IP exclusion opportunities, a chance
> for a member of the WG to examine their patent portfolio in light of the
> contents of the spec, see if there are any parts of the spec that can't be
> implemented without one of their patents, and decide if they are going to be
> a mensch and grant a Royalty-Free license, or a nudnik and declare a patent
> exclusion.  At FPWD, they have 150 days from publication to fish or cut
> bait.  Note that here is where one of the trickier aspects of MUST vs.
> SHOULD comes into play... if a spec says MUST, that part of the spec is
> essential, and RF terms apply... if the spec says SHOULD, then a WG
> participant who holds a patent on that bit of the technology doesn't make
> any such RF licensing commitment... it's not just a matter of saying, "this
> is required by implementations/authors/users", it's a legal shibboleth.
>
> 3) Working Draft (WD): after FPWD, there may be several normal iterative
> Working Drafts which refine the spec, and during which the public is allowed
> to provide feedback (and almost inevitably doesn't).  It's fairly typical,
> and even beneficial, for participating implementers to prototype support for
> features throughout this part of the process to examine the best options,
> but much less desirable for them to ship the features in production code
> (because it then locks the spec into an uncomfortable position).  It's
> really useful for authors to test out any available running code at this
> point, and salt to taste (but don't count on them doing so).
>
> 4) Last Call Working Draft (LC): the point at which a WG believes it's
> pretty much done with the spec, and at which point the public decides to let
> the WG just how wrong they were.  This is normally the last opportunity for
> public comments (unless the spec is significantly changed and has to have a
> second or third or fourth LC), and is the last exclusion opportunity.  At
> LC, the exclusion period is 60 days.
>
> 5) Candidate Recommendation (CR): might be better known as the
> "implementation phase"; the spec is pretty stable, and will only have minor
> clarifications and editorial changes unless significant implementation
> experience tells the WG that they need to rethink things and change the spec
> (at which point they would have to return to LC). This is also the point at
> which the WG suddenly remembers that it has to have a comprehensive test
> suite that tests each feature of the spec, which it should have been doing
> all along (think of night-before cramming and hail-mary passes across the
> deadlines).  As more and more implementations start making public releases,
> this is the point at which cutting-edge authors tend to really start kicking
> the tires.
>
> 6) Proposed Recommendation (PR): the spec is done, the test suite is
> completed, and there are at least 2 passing implementations for each test.
>  At this point, we're just giving the W3C Members that chance to come to
> their senses and realize that the spec is question is a shoddy contraption
> that should never have seen the light of day.  All over now but the crying.
>  (This phase usually goes fine.)
>
> 7) W3C Recommendation (REC): the horns are sounded, and the spec is placed
> on the pedestal and declared sacrosanct...  until the wider community starts
> to implement and use it, and sends in incredulous, confused, and angry
> comments, and the WG sheepishly starts issuing errata and prepares a second
> edition that whitewashes over the ugliest of the problems.  It is when (and
> only when) a spec becomes a Recommendation that Royalty-Free licensing
> commitments, made either implicitly or explicitly by WG participants during
> FPWD and LC, kick in and the implementers of the spec are free from concerns
> about patent-infringement litigation from any of the WG participants (at
> least as regards the technology covered by the spec).
>
>
> Meanwhile, back at the ranch... if HTML5 were to normatively reference the
> Canvas 2D API spec, it could not proceed more than one step further along
> the Recommendation track than the aforementioned Canvas spec, and could not
> pass to Recommendation unless the Canvas spec were also ready for Rec
> status.  So, there is strong incentive to avoid normative dependencies among
> specs with lopsided publication timelines.
>
> That said, it could still help the HTML5 spec move faster in one of several
> ways:
> * HTML5 could include "version 1" of the Canvas API, with the understanding
> that more a more accessible version would follow as a separate spec
> * HTML5 could drop Canvas (since it is already implemented widely, it isn't
> really at risk), and rely on the functionality being defined in the Canvas
> spec
> * HTML5 could make Canvas a SHOULD, not a MUST, and proceed forward toward
> Rec, with the knowledge that Canvas would be done in its own time
> * a dedicated group of people could focus on making sure that a separate
> Canvas API spec is done in a timely manner through rapid iteration of drafts
> (actually, this would have been much easier had we split the spec out as I
> suggested 2 years ago)
>
> I don't know which of any of these options the HTML WG might find palatable.
>  One thing is sure... splitting the Canvas API spec out decouples it from
> the HTML5 production cycle, allowing each to grow at their own natural rate,
> with interested parties able to focus on the subject of their specific
> interest (which in a mailing list as busy as public-html has to count for
> something).
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
>

Thanks for the detailed answers on the steps. Provides a great deal of clarity.

I'm not sure if dropping is an option, as this was voted on a couple
of years ago, and can only be addressed again if new info presents
itself. At least, that's my understanding of what was discussed last
week. What's your opinion on this in light of the past vote?

I'm not sure the accessibility folks are going to want to wait for
some nebulous future release in order to incorporate accessibility. In
fact, from my understanding, we really shouldn't be addressing future
versions, anyway. We should assume what we're delivering is gold, and
meets the general needs, today. Tomorrow's versions are for tomorrow's
needs, etc etc.

I do agree that decoupling it makes sense, for both HTML and
Canvas--including growing at own rate and allowing interested parties
to focus. I also agree that this would have been so much better if the
split had been made two years ago.

I'd be curious about what the accessibility in canvas folks think on
splitting this out.

Shelley

Received on Tuesday, 18 August 2009 12:50:18 UTC