This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 9178 - add definition of "conforming document"
Summary: add definition of "conforming document"
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC All
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://lists.w3.org/Archives/Public/p...
Whiteboard:
Keywords: WGDecision
Depends on:
Blocks:
 
Reported: 2010-03-02 07:19 UTC by Michael[tm] Smith
Modified: 2011-04-12 23:32 UTC (History)
7 users (show)

See Also:


Attachments

Description Michael[tm] Smith 2010-03-02 07:19:55 UTC
See Noah Mendelsohn's comments at http://lists.w3.org/Archives/Public/public-html-comments/2010Feb/0011.html

[[
I looked further and noticed statements like:

        "Authoring tools and markup generators must generate >conforming 
documents<."

However, the term "conforming documents" seems not to be explicitly 
defined, and is in any case not hyperlinked from references like this.  I 
think that's a problem that should be fixed.
]]
Comment 1 Ian 'Hixie' Hickson 2010-04-01 00:59:54 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: A conforming document is just one that conforms to the requirements — there's nothing magical here. I've added an explicit definition though since apparently people have had trouble with this.
Comment 2 contributor 2010-04-01 01:00:54 UTC
Checked in as WHATWG revision r4932.
Check-in comment: explain what a conforming document is
http://html5.org/tools/web-apps-tracker?from=4931&to=4932
Comment 4 Ian 'Hixie' Hickson 2010-09-30 18:58:32 UTC
Those are long e-mails... if there is a specific issue single that is a reopening of the specific issue raised in this bug, please state for the record what the issue is and reassign the bug to me. If there are new issues, please file new bugs.

(If you would rather I not assign bugs to you in situations such as this, please let me know. I'd be happy to coordinate with you in other ways instead. No dismissal of this issue is intended here.)
Comment 5 Noah Mendelsohn 2010-09-30 21:16:59 UTC
Hixie writes:

> if there is a specific issue single that is a reopening
> of the specific issue raised in this bug, please state
> for the record what the issue is

The part of the original issue that I felt was not adequately addressed is (quoting from 0029 email):

It would be desirable to clarify the applicability of the term "conforming document" in cases where "applicable specifications" had been used to augment or change the base HTML5 specification.  I believe that is ultimately a very important and deep concern that remains unaddressed.  Given the current ambiguity, someone could write a specification that very radically changes the HTML5 base, perhaps even maliciously, and claim "oh, mine is an 'applicable specification', so what you get when you write to my new spec is a 'conforming HTML5 document'".  Wouldn't it be better to require that such documents be referred to as "conforming to HTML5 as modified by my-malicious-spec-X" (or in the more likely example "conforming to HTML5 as modified by my-nonmalicious-spec-that-makes-significant-and-perhaps-otherwise-incompatible-changes"? 

> and reassign the bug to me

Above my pay grade.

> If there are new issues, please
> file new bugs.

Up to you whether this remaining bit is best tracked as new bug.  I'll open one if that's easier for you.

I've acknowledged that the main concern, I.e. to better define the term conforming documents, has been addressed (modulo the editorial suggestion that it be hyperlinked from references).  I am satisfied with the resolution to that, and I thank you!

> No dismissal of this issue is intended here.

Understood, and much appreciated.  Again, thank you very much.

Noah
Comment 6 Sam Ruby 2010-09-30 21:30:37 UTC
(In reply to comment #4)
> Those are long e-mails... if there is a specific issue single that is a
> reopening of the specific issue raised in this bug, please state for the record
> what the issue is and reassign the bug to me. If there are new issues, please
> file new bugs.

As Noah has stated what the specific issue is, I have gone ahead and reassigned the bug.

> (If you would rather I not assign bugs to you in situations such as this,
> please let me know. I'd be happy to coordinate with you in other ways instead.
> No dismissal of this issue is intended here.)

Nothing improper was done, feel free to do this again in the future as necessary.

As to this specific bug: my understanding is that there is only one part of the original bug report that Noah does not feel is addressed, and that he is willing to pursue this as a TrackerRequest if there truly is a fundamental disagreement, but first he wanted to exhaust the discussion before escalating it.

If there is a fundamental disagreement simply mark it as WONTFIX with a standard response, and Noah can evaluate the response is sufficient.  If he decides it is not, he can add the TrackerRequest keyword and we can continue with the Decision Process.
Comment 7 Noah Mendelsohn 2010-09-30 21:42:38 UTC
Sam Ruby writes:

> As to this specific bug: my understanding is that
> there is only one part of the original bug report
> that Noah does not feel is addressed, and that he
> is willing to pursue this as a TrackerRequest if
> there truly is a fundamental disagreement, but
> first he wanted to exhaust the discussion before
> escalating it.

Exactly.

> If there is a fundamental disagreement simply mark
> it as WONTFIX with a standard response, and Noah
> can evaluate the response is sufficient.  If he
> decides it is not, he can add the TrackerRequest
> keyword and we can continue with the Decision
> Process.

Works for me.  Much appreciated, thank you!

Noah
Comment 8 Ian 'Hixie' Hickson 2010-10-03 18:36:52 UTC
Thanks for the clarification; this looks like something that should be reasonably easily addressable. I'll look at it in more detail in the near future.
Comment 9 contributor 2010-10-12 06:53:32 UTC
Checked in as WHATWG revision r5605.
Check-in comment: try to clarify the applicable spec stuff
http://html5.org/tools/web-apps-tracker?from=5604&to=5605
Comment 10 Ian 'Hixie' Hickson 2010-10-12 06:54:41 UTC
(In reply to comment #5)
> 
> It would be desirable to clarify the applicability of the term "conforming
> document" in cases where "applicable specifications" had been used to augment
> or change the base HTML5 specification.  I believe that is ultimately a very
> important and deep concern that remains unaddressed.  Given the current
> ambiguity, someone could write a specification that very radically changes the
> HTML5 base, perhaps even maliciously, and claim "oh, mine is an 'applicable
> specification', so what you get when you write to my new spec is a 'conforming
> HTML5 document'".

Yes, they could. But all _you_ have to do is say "well I'm not writing things to your specification" and then that specification doesn't count as an "applicable specification" for your purposes.

This is exactly what happens with _every_ specification. If everyone in a community agrees that something applies, then it applies. If they don't think it applies, then for them it doesn't.

I've tried to add a note to the spec discussing this.


> Wouldn't it be better to require that such documents be
> referred to as "conforming to HTML5 as modified by my-malicious-spec-X" (or in
> the more likely example "conforming to HTML5 as modified by
> my-nonmalicious-spec-that-makes-significant-and-perhaps-otherwise-incompatible-changes"? 

What would such a requirement mean? How would you test it? What conformance class could pass it? What happens if someone decides that that requirement doesn't apply to them?


EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Partially Accepted
Change Description: see diff given above
Rationale: see above
Comment 11 Noah Mendelsohn 2010-10-27 15:31:05 UTC
Thank you for the attention to my concerns.  Unfortunately, I don't feel that the response in http://www.w3.org/Bugs/Public/show_bug.cgi?id=9178#c10 adequately addresses my concerns.  

For a language like HTML5, I think it is important and valuable to have a good story about whether a given document is "HTML5-compliant".  The approach taken here says, basically, "it's in the eye of the beholder".  I do understand that line of thinking, I just think it's not for the best.

First of all, we're in agreement that it should be OK for "applicable specifications" to be written that extend or change the HTML5 language.  Where we seem to disagree is on 1) whether it's worth having a clean, rigorous definition of what it means to be compatible with the unextended specification and 2) [optionally] whether there's standard terminology suggested for expressing that a document or piece of software is compatible with "HTML5 as extended with specification XXX".

I think that at least (1) is very important.

> Noah Mendelsohn wrote:
> 
> > Wouldn't it be better to require that such documents be
> > referred to as "conforming to HTML5 as modified by my-malicious-spec-X" (or in
> > the more likely example "conforming to HTML5 as modified by
> > my-nonmalicious-spec-that-makes-significant-and-perhaps-otherwise-incompatible-changes"? 

Ian Hickson wrote:

> What would such a requirement mean?

Again, my main point is that it would mean that you cannot use the term "HTML5-compatible" to refer to compatibility with the extended specification, only for documents or software that conforms to unextended HTML5.

> How would you test it? What conformance class
> could pass it? What happens if someone decides
> that that requirement doesn't apply to them?

I believe the HTML5 draft already attempts to define the main conformance I care about, which is to the unextended specification.  

I believe your question is "how would you test..." conformance to something like "HTML5 as extended with Noah's specification"?  I think the answer is to say something along the lines of:

"Where applicable specifications are used to extend or change HTML5, those specifications SHOULD define the conformance criteria for the extended language."

Example 1: Compatible extension
===============================

Let's say I write a simple specification that augments HTML 5 by requiring one additional attribute to be used by some document tracking system I'm promoting.  I write Noah's Doc Management spec, which defines the augmented language, to require the attribute.  I would in the extension specification write:

"For a document to conform to this specification, it must be a conforming HTML5 document, with the additional requirement that the @noahdoctrack attribute MUST be specified on the <HTML> element."

Example 2: Incompatible extension
=================================

Now let's say I introduce an incompatible change (for some reason). Noahs Specification Number 2 for some bizarre reason requires mismatched quotes on attributes (I'm only doing this to show how incompatible changes would be handled.)

The specification would say:

"For a document to conform to this specification, it must be a conforming to all the conformance requirements for HTML5 documents, except with regarding the quotation of attributes.  Attribute values MUST be quoted with a leading single quote and closed with a double quote.  Thus, documents conforming to HTML5+Noah's specification #2 will also be conforming HTML5 documents if and only if the documents contain no such attributes."

This shows the style in which incompatible changes could be introduced.

------------

Overall, I think this terminology is practical, simple, and useful. More importantly, I think it gives much stronger meaning to saying that a document is "HTML5 compatible", and that's very important.

Ian Hickson wrote:

> If you would like to escalate the issue to
> the full HTML Working Group, please add
> the TrackerRequest keyword to this bug,
> and suggest title and text for the tracker
> issue

I am adding the TrackerRequest keyword.

The title I suggest is: Conformance terminology

Also: I am at this point raising the issue myself, not on behalf of the TAG as a whole.  Again, thank you for your consideration of my concerns.  

Noah
Comment 12 Sam Ruby 2010-10-27 19:09:00 UTC
http://www.w3.org/html/wg/tracker/issues/140
Comment 14 contributor 2011-04-12 23:32:34 UTC
Checked in as WHATWG revision r5996.
Check-in comment: apply wg decision
http://html5.org/tools/web-apps-tracker?from=5995&to=5996