Re: An HTML language specification vs. a browser specification

Jonas Sicking wrote:
>> 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.

That's true. Some parts can be split out more easily.

But what does that have to do with what I said? See above.

> 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.

I'm am one of the editors of a seven-part spec, of which all parts use 
the same infrastructure, and see no big overhead in spreading edits over 
those parts. Your mileage may vary, but the problem is IMHO fixable.

>> 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?

What I find unreasonable is to require somebody to invest a huge amount 
of time when the result likely would be "nice try, but now go away".

So an attempt to do a split should have the backing of the WG before a 
significant amount of time is spent.

> 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.

Well, we are wasting time already by having this discussion over and over.

>> 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?

The proposal I criticized was not to have a WG decision until a huge 
amount of time was already spent by the volunteer.

BR, Julian

Received on Wednesday, 19 November 2008 07:53:27 UTC