W3C home > Mailing lists > Public > www-tag@w3.org > April 2011

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

From: Noah Mendelsohn <nrm@arcanedomain.com>
Date: Tue, 12 Apr 2011 23:02:53 -0400
Message-ID: <4DA5125D.8060804@arcanedomain.com>
To: Sam Ruby <rubys@intertwingly.net>
CC: HTMLWG WG <public-html@w3.org>, "www-tag@w3.org" <www-tag@w3.org>
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.


[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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:38 UTC