- From: David Singer <singer@apple.com>
- Date: Thu, 29 Jan 2009 16:55:43 +0100
- To: HTML WG <public-html@w3.org>
At 10:08 -0500 29/01/09, Murray Maloney wrote: > A little bit of co-operation goes a long way, but co-operation >is most effective when it is reciprocated regularly. You should try sometime. > >I think that you have made your point. Repetition of your argument does >not convince me -- it never has. We do not see eye to eye. Indeed. I personally support Haakon's position. Having two specifications that both claim to be normative about the same subject material has never, in my experience, been a good idea. It seems that it has always resulted in avoidable problems, confusion, and conflict. This is an opinion shared by others on this list. What is your answer to the question "when the two normative specifications are in conflict, which one takes precedence?" And if your answer is that they are perfectly in alignment, and there never will be conflict, I look forward to seeing your large bug-free software projects. :-) And yes, I know that a single specification can (will) also have bugs; but adding a second normative specification adds to that count (all the matters for which either document alone is clear, but the two documents disagree). In the request "we'd like to put this document on a path to publication as normative, as it's useful" the only aspect I am seeing push-back on is "as normative". HTML5 is large, and to be successful, will need to be supported by a number of publications -- the spec., "views" of the spec. automatically produced from it, hand-produced perspectives of the document more suited to some audiences, tutorials, examples, and so on. Having this document claim to be normative has an obvious, stated problem. I am still unclear what the resistance is to having it informative, useful, and on track to publication. -- David Singer Multimedia Standards, Apple Inc.
Received on Thursday, 29 January 2009 15:56:57 UTC