Working Group Decision on ISSUE-140 conformance-terminology

The decision follows.  The chairs made an effort to explicitly address
all arguments presented in the Change Proposals on this topic in
addition to arguments posted as objections in the poll.

*** Question before the Working Group ***

There is a basic disagreement in the group as to how the term
"conforming document" can be used in cases where "applicable
specifications" have been used to augment or change the base HTML5
specification.  The result was an issue, two change proposals, and a
straw poll for objections:

http://www.w3.org/html/wg/tracker/issues/140
http://lists.w3.org/Archives/Public/public-html/2011Jan/0239.html
http://lists.w3.org/Archives/Public/public-html/2011Mar/0087.html
http://www.w3.org/2002/09/wbs/40318/issue-140-objection-poll/results

== Uncontested observations:

* Different communities may have a need for a looser, less formal term
   than the one proposed by the Change Proposal.

This was not decisive.  There were people who supported either of
these proposals even after taking this fact into consideration.  The
fact that this was acknowledged up front was appreciated.

=== Scope

As noted in the survey, the Change Proposal for no conformance versions
goes well beyond the scope of the original issue.  The issue deals only
with cases where "applicable specifications" have been used to augment
or change the base HTML5 specification.

As such, the scope of this decision solely concerns itself with the
conformance of documents in cases where "applicable specifications" had
been used to augment or change the base HTML5 specification.

The introduction of the term "HTML5" into "conforming HTML5 document"
was treated as a simple factual statement that accurately reflects the
title of the specification.

=== Clarity

Starting with the Change Proposal for "Conformance terminology when
applicable specifications are used", one of the objection is that the
definition of conformance is 'unclear'.  The second change proposal
illustrates this situation as follows:

   different groups could have different meanings for what "HTML" means
   and what is permissible

It appears that both change proposals agree on this basic fact.  We now
proceed to look at the implications of this in both the Change
Proposals themselves and the survey.  We find:

   harms communication about - and learning of - the standard(s) and
   could result in different validators saying different things about
   same code, without any explanation of why.

and

   there's already confusion between "what validator.nu" checks and
   "conforming HTML5" is (for instance, a/@ping being accepted as
   "HTML5+ARIA, SVG 1.1 plus MathML 2.0 (experimental)"

The latter comment describes a situation where a feature that was
removed from HTML5 over a year ago without a single person objecting:

   http://lists.w3.org/Archives/Public/public-html/2010Mar/0132.html

This is a case where we do have different groups having different
meanings for what "HTML" means and what is permissable:

   http://developers.whatwg.org/links.html#ping

At this point, we've established a potential for confusion, and that
this potential is not hypothetical.  Next we look for claims of negative
effects of introducing clarity, and we find "makes extensions
second-class citizens", "artificial barrier".  Others find this clarity
to be a 'sensible way to "visualize" HTML5's extensibility'.
Furthermore, it is noted that:

   Validator.nu, which is based on HTML5, nevertheless lets you
   select from several 'presets', such as HTML5+ARIA

This observation is in addition to the previous statement that cites
which specific version of SVG and MathML the validator is checking a
given document against.  As no evidence has been provided that this has
led to the groups which developed such specs to feel as second-class
citizens, we find this objection to be weak.

=== Other Objections

The following are the remaining objections followed by their
evaluation:

   There is no use case that actually gets satisfied by this suggestion

 From the original Change Proposal, we find "Conforming HTML document
just works".  We interpret this to mean that when an author creates an
HTML5 compliant document with an <a> element in it, and a user agent
claims to support HTML5, both the author and user agent agree on what
these terms mean.

   if a community ignores a spec, there's nothing the spec can do
   about it

While this is a true statement in itself, it doesn't make the spec
"fiction" to those who do choose to follow the spec.  Nor does it mean
that the spec should not cater to those who do choose to follow the
spec by defining what it means for a document to be considered HTML5 or
what an <a> element means and what attributes it has.

   The conformance section of this specification needs to be
   polished...it would be possible to decide that a document is
   conforming just because it has the right doctype, or just because the
   element p is used in a document, etc. "Conforming HTML5 document" is
   not enough by itself

Conformance in the current draft of the HTML5 spec is spread throughout
the document.  Concrete suggestions in the form of bug reports are
encouraged.  Meanwhile, this objection applies equally to both
proposals, and as such doesn't affect the selection of the proposal
that draws the weakest objection.

   an applicable specification could choose to override the
   section making those restrictions, removing them

The proposed text makes it clear what it means to be a "applicable
specification", and specifically states:

   Whether a document is or is not a conforming HTML5 document does not
   depend on the use of applicable specifications

*** Decision of the Working Group ***

Therefore, the HTML Working Group hereby adopts the "Conformance
terminology when applicable specifications are used" Proposal for
ISSUE-140.  Of the Change Proposals before us, this one has drawn the
weaker objections.

== Next Steps ==

Bug 9178 is to be REOPENED and marked as WGDecision.

Since the prevailing Change Proposal does call for a spec change, the
editor is hereby directed to make the changes in accordance to the
change proposal.  Once those changes are complete, ISSUE-140 is to be
marked as CLOSED.

As major portions of the "No conformance versions" proposal were deemed
to be out of scope for this issue, they can be pursued separately via
bug reports.  Any such bugs will be treated as Last Call comments, and
we discourage the editor from processing them until after we have sent
a document out for Last Call.

== Appealing this Decision ==

If anyone strongly disagrees with the content of the decision and would
like to raise a Formal Objection, they may do so at this time. Formal
Objections are reviewed by the Director in consultation with the Team.
Ordinarily, Formal Objections are only reviewed as part of a transition
request.

Received on Thursday, 24 March 2011 12:02:03 UTC