Re: Working Group Decision on ISSUE-140 conformance-terminology

I want to thank the HTML working group for its careful attention to my 
concerns, and I am of course pleased that my proposal was substantially 
adopted as the resolution to your ISSUE-140.

I'm copying this reponse to www-tag, because some readers there may be 
interested, but I would like to reiterate that I raised this issue as an 
individual, not on behalf of the TAG.

I do note with some regret that the change as implemented is causing 
divergence between the WHATWG and the W3C versions [1] of the spec.  I'm 
sorry for that, but I think the divergence probably represents a deeper 
difference on the pros and cons of giving names and assigning conformance 
terminology to essentially frozen versions of a specification; unless that 
underlying deeper difference is resolved (which doesn't seem likely in the 
short term), this probably is a reasonable result.

Anyway, I'd like to again thank the working group and the chairs. I found 
that the hearing I received on my original bug report and the process that 
followed to be reasonable and careful at every step, and that is all much 
appreciated, particularly since this obviously remains a contentious 
question.  Thank you.

Noah

[1] http://html5.org/tools/web-apps-tracker?from=5995&to=5996

On 3/24/2011 8:01 AM, Sam Ruby wrote:
> 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 Wednesday, 13 April 2011 03:03:19 UTC