Re: Why splitting HTML5 into several specs has failed to work (Was: Request for clarification on HTML 5 publication status)

Ian Hickson wrote:
> On Thu, 29 Nov 2007, Sam Ruby wrote:
>> Why is "the" (as in one and only) specification the only document in 
>> which this information can make it onto a W3C site?  I've seen several 
>> specifications which are spread across volumes.  Can't different volume 
>> in a series be in different states at any given time?
> 
> There are a few reasons, but primarily the parts are too interconnected. 
> (For example, the offline stuff has to integrate with the navigation stuff 
> and the parsing stuff, which has to integrate with the scripting stuff, 
> and soon enough you've brought in most of the current spec.)

Care to elaborate?

 From a quick scan of the current draft, the only occurrences of the 
word "offline" are in section 4.6.  I have no problem believing that 
that section would depend on navigation, parsing, and scripting stuff; 
what I am curious to see to what extent the reverse is true.

> There's also the lack of resources. There is such a high overhead to 
> editing a spec that the cost of editing two specs of size x is actually 
> higher than the cost of editing one spec of size 2x. This wouldn't be 
> necessarily a big problem if we had editors, but we don't -- we are 
> already desperately short on editors to work on CSS3, setTimeout, Web DOM 
> Core, CSSOM, DOM3 Events, Keyboard Events, a 3D Canvas API, etc. If we 
> suddenly magically had ten fulltime experienced Web specification editors 
> volunteer tomorrow, we _still_ would be short on editing resources.

Not all of those items are equal.  Let me take two from your list, 
hopefully identifying extremes: setTimeout and 3D Canvas API.

I agree that splitting setTimeout would increase the overall workload. 
Furthermore, I see it as entirely possible that it would not only 
increase the entire workload of the working group, but that it could 
also lead to increasing the workload for the people working on the base 
document.  The second statement is not necessarily true, but is enough 
of a possibility that the very idea of splitting this out deserves to be 
scrutinized.

I also agree that splitting a 3D Canvas API out would increase the 
overall workload.  However, I see it as extremely unlikely that doing 
such would result in a net increase in the workload of the editors 
working on the base document.  I've got experience in working in 
all-volunteer contexts, and from my experience: that's a good tradeoff.

Furthermore, there is another key difference between these two.  If 
setTimeout isn't spec'ed, that's an indication that the spec isn't 
complete.  If a 3D Canvas API isn't spec'ed, that's an indication that 
that features is ready for standardization.

Now, before the above paragraph is misconstrued as me being "against" a 
3D Canvas API, as has recently has occurred, let me make two things 
clear: it seems plainly obvious to me that there is considerable support 
for a 3D Canvas API, enough so that it would surprise me greatly if 
nobody stepped forward to help out.  And secondly, I believe that 
creating a viable ecosystem for extensions doesn't curtail innovation, 
it enables it.  "Centrally designed protocols start out strong and 
improve logarithmically. Evolvable protocols start out weak and improve 
exponentially. It's dinosaurs vs. mammals, and the mammals win every 
time." -- http://www.shirky.com/writings/evolve.html

> So far we've tried taking four things out of HTML5. We have one success 
> story, XMLHttpRequest. The Window interface was taken out, put into its 
> own spec, and neglected to the point where it was blocking work on HTML5 
> and I had to reinclude it (a lot of work), setTimeout was taken out and 
> had nowhere to go so it's been rotting in a section at the end of HTML5, 
> and the alternative style sheet selection API was taken out of HTML5 and 
> moved to CSSOM where it is currently dying of neglect as well. (setTimeout 
> and the alternative stylesheet stuff may have to be brought back into 
> HTML5 so that we can at least get interop on these features, even if this 
> isn't the ideal place for them.)
> 
> I agree whole heartedly that it would be great if we could just have a 
> bunch of tiny specs that are self-contained and well maintained. In 
> practice, though, this hasn't worked. I truly wish it would.

With such a small sample size, the only thing you can reasonably 
determine here is that these samples were not suitable for splitting out.

Also, with open source projects, you don't attract developers by 
defining tasks that nobody wants to work on and ask for volunteers.  I 
suspect that the same thing applies here.

- Sam Ruby

Received on Friday, 30 November 2007 15:38:55 UTC