W3C home > Mailing lists > Public > public-html@w3.org > May 2009

Re: Consistence with other specifications, was: Design Principles

From: Shelley Powers <shelleyp@burningbird.net>
Date: Tue, 26 May 2009 06:46:27 -0500
Message-ID: <4A1BD693.6080609@burningbird.net>
To: Julian Reschke <julian.reschke@gmx.de>
CC: Ian Hickson <ian@hixie.ch>, HTML WG <public-html@w3.org>
Julian Reschke wrote:
> 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 11:47:16 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:45 UTC