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