- From: David Carlisle <davidc@nag.co.uk>
- Date: Wed, 08 Jun 2011 23:35:47 +0100
- To: public-html@w3.org
On 08/06/2011 19:43, Paul Cotton wrote: >> "These two specifications are generated from common base text and >> are intended to be entirely consistent. Both are normative and >> authoritative. ... > > I can live with this text but I want to point out that W3C has > successfully published two normative documents with substantive > overlapping text before that were generated from the same source (ie > XPath 2.0 [1] and XQuery 1.0 [2]) and these documents went all the > way to Recommendation status without anyone in the W3C community > expressing any concern whether one should be more normative that the > other. The situation with those documents is rather different, they are defining different (but related) languages, so if there is any difference then there is no conflict, just a difference between xquery and xpath, most of which of course are intentional (such as lack of where clause in xpath's for expression). I don't think there is any precedent for having two documents from the W3C each claiming to be normative definition of the same thing, In fact these two documents were a joint effort of two > different W3C Working Groups (XSL WG and XML Query WG) that worked > together to ensure that the common normative text worked for both > documents. > > Personally in think both the HTML5 spec and the author-only view > which are obviously aimed at different audiences can both be > normative and that the HTML WG can work on ensuring that there are no > conflicts between the two documents. I've some sympathy with the argument that the normative definition of a language ought to be more like the author-view document than the current html5 spec, but the html5 spec is what it is and making both normative seems to be the worst possible outcome. The only way to make the author-view spec normative without introducing potential conflict would be to remove the equivalent sections from the html5 spec, I don't think that would be possible without far more effort than is warranted and would require extensive rewriting and potential for the introduction of new errors. David > > /paulc l
Received on Wednesday, 8 June 2011 22:36:10 UTC