Consistence with other specifications, was: Design Principles

Ian Hickson wrote:
> On Tue, 26 May 2009, Julian Reschke wrote:
>> Ian Hickson wrote:
>>> ...
>>> This is the approach I have taken, and intend to continue taking, in editing
>>> the HTML5 specification, so long as this working group continues to allow me
>>> to edit it. I believe technical soundness and practical usefulness is more
>>> important than theoretical purity and consistency with other specifications.
>> Can we please have a vote on on the last part?
> 
> I would definitely support having a vote on this. Sam?

I think that consistency with other specifications is a very important 
goal, and that it needs extremely good reasons to give up on that.

In general, if another specification clearly has a bug, it should be 
reported to the standards body maintaining that spec. In the worst case, 
this is where the process ends (such as for IETF specs with an Erratum 
on the RFC Editor page), on the other hand that Standards Body may be 
revising that spec anyway.

But then, there's apparently disagreement about what constitutes a bug. 
Many WhatWG contributors operate under the assumption that a spec that 
doesn't define error handling somehow is "broken" or "incomplete". 
That's not a reason to ignore it. If HTML5 *needs* to mandate specific 
error handling (if!), then it can describe it, but that doesn't mean 
that spec can be ignored otherwise.

As far as I can tell, ignoring/overriding other specs often is a symptom 
of an assumption that one can do something better than those who were 
involved writing the "other" spec (a certain kind of "NIH"). This may be 
true sometimes, in which case the right thing to do is to help making 
that other spec better.

BR, Julian

Received on Tuesday, 26 May 2009 09:42:02 UTC