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

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

Received on Tuesday, 18 August 2009 03:46:49 UTC