W3C home > Mailing lists > Public > public-html@w3.org > January 2011

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

From: Sam Ruby <rubys@intertwingly.net>
Date: Wed, 19 Jan 2011 14:58:23 -0500
Message-ID: <4D37425F.80605@intertwingly.net>
To: Noah Mendelsohn <nrm@arcanedomain.com>
CC: "public-html@w3.org" <public-html@w3.org>, Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>
On 01/19/2011 02:05 PM, Noah Mendelsohn wrote:
> 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:

Much better.  Recorded here:

http://dev.w3.org/html5/status/issue-status.html#ISSUE-140

- Sam Ruby

> 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
>
Received on Wednesday, 19 January 2011 19:58:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:18 GMT