- From: Noah Mendelsohn <nrm@arcanedomain.com>
- Date: Tue, 12 Apr 2011 23:02:53 -0400
- 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. 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