Resubmission of Change proposal for HTML WG ISSUE-140: Conformance terminology when applicable specifications are used

Sam Ruby pointed out that the change proposal [1] I submitted yesterday 
(see below) was lacking some of the information you need. So, here's an 
expanded resubmission:

Summary of the Proposal:
========================

This proposal is intended to address HTML WG ISSUE-140 [2], which was 
opened in response to concerns raised by me.  This proposal offers what I 
believe to be improvements to the terminology for document conformance, 
particularly in the case where "applicable specifications" are used to 
extend or change the base HTML5 specification.

The main changes proposed are:

* The term "conforming document" is changed to "conforming HTML5 document". 
Except for clarifying the case where applicable specifications are used, 
the definition and use of the (renamed) term is unmodified.

* The term "conforming HTML5 document" (formerly "conforming document") is 
reserved only for documents that conform to the HTML5 specification itself 
(I.e. no applicable specs. needed to define syntax or for correct 
interpretation).

* In the case where applicable specifications define additional 
constructions, or change the semantics or processing of content that is 
already legal (conforming) per HTML5 itself, then those applicable 
specifications SHOULD define conformance terminology for those cases.

* The form: "conforming HTML5+xxx document" (e.g. conforming HTML5+ 
Automotive Extensions") is suggested, but not required.

Rationale
=========

* As explained when the issue was raised, the current drafts are unclear as 
to how the term "conforming document" should or should not apply when 
applicable specifications enable new sorts of content, or change the 
meaning vs. what HTML5 itself calls for.

* I think the term "conforming HTML5 document", with the narrower 
definition proposed here, will be useful in general discourse, and for 
reference from other specifications. People will come to understand that a 
"conforming HTML5 document" just works, if you have a good HTML5 
implementation.

* I think it's appropriate for extension specifications to define their own 
conformance terminology.

Proposal details
================

The attached HTML file is based on the 14 January 2011 version of the 
common infrastructure editors' draft [3]. I'm not familiar work WG 
conventions for marking up changes, so this uses three simple CSS classes 
(add, del, and comment). You can search for these in the source if 
necessary -- there are only a few changes in any case. I hope this ad-hoc 
markup isn't too inconvenient.  (This is the same file that accompanied the 
first submission of this proposal).

Impact
======

Positive impact:

* As noted above, I believe that the term "conforming HTML5 document", with 
the narrow definition proposed, will be very useful.

* I believe that, when applicable specifications change the interpretation 
of otherwise conforming content and/or when such specifications provide for 
new content (which may or may not closely resemble HTML5); it's appropriate 
for those specifications to define the conformance terminology to be used.


Negative impact:

* I infer that some may have preferred for the term "conforming document", 
whether renamed or not, to be applicable to content that is supported only 
by applicable specifications, and in situations where applicable specs. 
change the interpretation.  Those who desire such a broader term will find 
this proposal a step backwards (FWIW: I strongly believe that the narrower 
term is needed; maybe or maybe not there is value in additionally having 
the broader one was well, but I'm unconvinced.)


Implementation impact:

* No direct impact on document generators, user agents, parsers, etc., 
except perhaps wrt/ terminology used in error reports.

* Validators, especially those supporting applicable specifications, will 
likely want to report or provide APIs that test for the conformance levels 
as proposed.

* Media type registrations: I don't think this proposal simplifies or 
complicates things, and I don't think it expands or reduces the range of 
options open, but there is in any case a question of what the text/html 
media type registration should say about use applicable specifications. 
The choices made on conformance terminology might affect the way the media 
type registration is >written< (e.g. whether it explicitly references terms 
like "conforming document" or "conforming HTML5 document".)

Again, my thanks to the working group for considering this proposal.

Noah

[1] http://lists.w3.org/Archives/Public/public-html/2011Jan/0191.html
[2] http://www.w3.org/html/wg/tracker/issues/140
[3] http://dev.w3.org/html5/spec/infrastructure.html