Re: An HTML language specification vs. a browser specification

Julian Reschke wrote:
> Jonas Sicking wrote:
>> ...
>> I think that if we make the order something like
>>
>> 1) Find someone else to deal with portion X
>> 2) Verify that this person understands the HTML 5 charter and the HTML
>>    design principles and agrees to honor them.
>> 3) Let this new person publish a draft for this portion
>> 4) Verify that the new draft defines X as well or better than what is
>>    in the HTML 5 spec today.
>> 5) Verify that the new draft is being edited as effectively as portion X
>>    in HTML 5 spec is today by Ian.
>> 6) Remove the relevant sections from the HTML5 spec.
>>
>> we can be fairly sure that there is a net gain. Though of course the 
>> bigger portion X is the more sure we will have to be that the editor 
>> won't drop the job on the floor as has happened several times in the 
>> past once the editors realized the scope of the work involved.
> 
> Again: the # of authors is orthogonal to the # of specs. Multiple 
> authors can edit a single spec (with coordination), but also a single 
> author can edit multiple specs.

I don't believe it is orthogonal. First of all it depends heavily on
which parts are broken out into separate specs. For example I've heard
suggested to break out error handling during parsing from the rest of
the parsing, given how tightly the two are coupled I think it would be
significantly more work to have the two as separate specs.

Other things like database API seems to *me* that it could be more
easily broken out as there are much fewer interdependencies.

Then there are things like the window object (or rather the browsing 
context) which at first look seems like it could be broken out, but 
which actually is fairly heavily interconnected, in part due to things 
like document.write which affects parsing and is affected by the 
browsing context.

Then of course there is the administrative overhead with multiple specs. 
There is quite a bit of infrastructure set up (which is very helpful and 
has increased transparency to a point of making it more transparent than 
any w3c spec ever in the past, something that I personally really 
appreciate). This would have to be cloned for each new spec that is created.

> Furthermore, the checklist you suggest seems to be written with the 
> intent of discouraging anybody coming up.

The point is moving the burden of proof that the current process can be 
improved onto the people that are claiming it can be improved.

Which part of the above steps do you consider unresonable? Do you have 
an alternative proposal?

Ultimately what I want to prevent is that we risk wasting time while 
trying to deal with meta-issues such as which part of the specified 
behavior lives in which spec document.

> The working group should make a decision whether a split is feasible and 
> a good thing to do, and then should select one or multiple editors. But 
> "go ahead, waste your time, until we'll tell you that you're not a 
> second Ian after all" will not fly.

Sure, trying to reach a working group decision is the way to go. I think 
that is what we are doing here through this (and other) discussions, no?

/ Jonas

Received on Wednesday, 19 November 2008 03:06:02 UTC