W3C

Site Navigation

Nearby

Results of Questionnaire ISSUE-140: Clarify the applicability of the term "conforming document" - Straw Poll for Objections

The results of this questionnaire are available to anybody.

This questionnaire was open from 2011-03-10 to 2011-03-17.

5 answers have been received.

Jump to results for question:

  1. Objections to the Change Proposal to reserve "conforming HTML5 document" for documents that conform to the HTML5 specification itself
  2. Objections to the Change Proposal for no conformance versions.

1. Objections to the Change Proposal to reserve "conforming HTML5 document" for documents that conform to the HTML5 specification itself

We have a Change Proposal to reserve the phrase "conforming HTML5 document" for documents that conform to the HTML5 specification itself. If you have strong objections to adopting this Change Proposal, please state your objections below.

Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.

Details

Responder Objections to the Change Proposal to reserve "conforming HTML5 document" for documents that conform to the HTML5 specification itself
Leif Halvard Silli
Simon Myers I object to this proposal because it removes the note describing that when a group of people discuss the conformance of a document it means conforming to the set of standards that their community has chosen to recognize.

Specs can't define themselves to be relevant, foisting themselves on communities; if a community ignores a spec, there's nothing the spec can do about it. And specs can't outlaw other specs, including being modified by supplementary specs; if a community recognizes an additional spec, then that's what people will use for conformance, regardless of what HTML5 says.

So the description in this note is accurate by definition. Pretending otherwise is a fiction, and I object to the spec being a work of fiction.
Ian Hickson There is no use case that actually gets satisfied by this suggestion. In particular, the obvious use case of "a way to get a common understanding with someone else so that you can collaborate in creating documents that use the same features" isn't generally satisfied by this because such use cases are likely to never cleanly fall down spec lines — they're more likely to fall down implementation lines, and implementations don't match to specs closely enough. There have been many examples of this over the past few years with other standards groups profiling HTML4 and CSS2 to fit their needs, for example the print industry with the CSS Print Profile, the WAP forum with their mobile profiles, the TV industry with their profiles, etc.

We should not make changes of this nature without very carefully determining what the use cases are that the changes would address.
Julian Reschke
Karl Dubost The conformance section of this specification needs to be polished before being able to decide on the meaning of "conforming document". The QA specification Guidelines recommends to define who and what will implement the specification, this analysis once done helps define a conformance profile.
http://www.w3.org/TR/qaframe-spec/

Comformance is not universal it is a decision of the group. For example 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.

2. Objections to the Change Proposal for no conformance versions.

We have a Change Proposal to ensure that conformance to HTML should not have version indicators.

Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.

Details

Responder Objections to the Change Proposal for no conformance versions.
Leif Halvard Silli Two objections:

1) this CP gives higher priority to spec designers than authors (http://www.w3.org/TR/html-design-principles/#priority-of-constituencies)
2) is an error to mix version indication directly in the code (which in reality is some kind of indirection issue) with profile/flavour conformance indication

Justification - 1st objection:

It's true that authors don't need to know about every spec change behind the scene - especally so while the spec is being specced. But this CP seems to say that authors do not need to know *anything* about what flavour of HTML one is dealing with (or judged against). That is disrespectful to authors, it sends the message that "we know best, just do as we say - we do the thinking". It also 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.

BUG-SPEAK: The CP speaks much about bugs and says that old specs might have bugs. But 'bug' is a word which describes a phenomena that is mostly a concern for those who make the buggy product - the spec designers. It should not concern authors so much.

Bugs are also not the primary reasons for releasing new specs. The primary reasons for new specs are 1) feature additions; 2) bringing specs in accorance with reality; 3) the current politics, current ideas or and current compromises (a.k.a. consensus) that may or may not have lasting value. Only 2) can be said to be about bugs in the narrow sense. But the 'bug speak' gives the impression that specs are only about 'progress', while they are colored by its authors: not every addition/removal survives the test of time. And no "flavour indication" hinder authors from a sensible navigation and understanding of these flavour and options.

Version indication is used in order to identify and sell a product - reaching customers: HTML5 authors. Version indication can thus promote HTML5. No version indication can hide the fact that a product has changed or become different and makes it more difficult to at least have _some_ idea about were in the mud one is situated.

VALIDITY IN THE WILD is based on version indication: CSS is often touted as unversioned. But the W3C CSS validator defaults to a CSS2 profile and lets you select other profiles too. And Validator.nu, which is based on HTML5, nevertheless lets you select from several 'presets', such as HTML5+ARIA (because ARIA was not part of HTML5 when current version of Validator.nu was made) but also HTML4+IRI profile (because, HTML4 does not support IRIs). The latter profile is very educating! Btw, 'HTML5+RDFa' is example of a spec whic already follows the thinking that this CP argues against (by its use of the formula 'HTML5+somethingelse' in the title.)

Requiring the use of the term "conforming HTML5 document" and reserving this wording to documents that validate against "HTML5 proper", will foster validation honesty and standards learning and consciousness amongst authors about what they are doing. It is also a sensible way to "visualize" HTML5's extensibility, if extensions are labeled as HTML5+something else. Version indication can also foster documenation of progress of the HTML5 standard.

Justification - 2nd objection:

Version indication directly in the code leads to indirection problems as it locks the validity to a particular profile: if the author adds something outside that profile, the doc is invalid. In XML, this *can* have an observable effect, if one uses a validating parser. Apart from the quirks-mode issues, the only observable effect in HTML is the need to change or alter the DOCTYPE (as demonstrated by how Validator.w3.org, when validating against another SGML/XML based HTML-profile, offers to change the DOCTYPE on your behalf.) But when there are no explicit version indication in DOCTYPE, the indireaction problems are largely gone as it allows the author pick validation profile, without the need to also update the DOCTYPE.
Simon Myers
Ian Hickson
Julian Reschke There's clearly a problem when we do not have precise names for conformance profiles, and also when there's confusion about what HTML5 is. This may not affect everybody, but it *does* affect people who author software that generates HTML for a living. It's quite common that contracts specify a specific language target, so not being able to clearly name what HTML5 is will be a problem.

Also note that 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)", and link relations not being validated).
Karl Dubost This change proposal doesn't really address the issue either. It mixes the notion of specification (with a version or not) with the conformance profile. A conformance profile for documents could pick items from a specification or a few.

More details on responses

  • Leif Halvard Silli: last responded on 12, March 2011 at 03:09 (UTC)
  • Simon Myers: last responded on 15, March 2011 at 11:10 (UTC)
  • Ian Hickson: last responded on 16, March 2011 at 03:27 (UTC)
  • Julian Reschke: last responded on 17, March 2011 at 09:56 (UTC)
  • Karl Dubost: last responded on 17, March 2011 at 16:51 (UTC)

Everybody has responded to this questionnaire.

Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire

Report issues on GitHub project w3c/wbs-design or by mail to sysreq.