- From: Shelley Powers <shelleyp@burningbird.net>
- Date: Tue, 26 May 2009 06:46:27 -0500
- 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 > > > > agree Shelley
Received on Tuesday, 26 May 2009 11:47:16 UTC