Bug 13479 - Document conformance/validity has to be stable over the time
Summary: Document conformance/validity has to be stable over the time
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Travis Leithead [MSFT]
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: WGDecision
Depends on:
Blocks:
 
Reported: 2011-07-30 20:37 UTC by Jirka Kosek
Modified: 2012-08-21 21:48 UTC (History)
10 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jirka Kosek 2011-07-30 20:37:26 UTC
On several places conformance of document relies on external registry which is not versioned -- it can add or remove any value at any time. This means that for frozen document its validity can change. This is unacceptable for many reasons.

Each edition of HTML spec should include snapshot of such registries which can easily change over time to create more stable grounds for document conformance.

This includes rel values, extensions of metadata names and extensions to pragma directives.
Comment 1 Anne 2011-07-31 07:53:22 UTC
I strongly disagree with this. Since implementations can vary over time, conformance should vary over time too.
Comment 2 Aryeh Gregor 2011-07-31 14:39:17 UTC
I agree with the original commenter.  The point of document conformance is to encourage authors to do the right thing by letting them claim their page is conforming, as a reward for good behavior.  If authors go to the effort of making a page conforming, they should be rewarded by having the page conform indefinitely.  If authors do all that work and then overnight their pages retroactively become invalid due to some spec writers deciding some feature isn't a good idea anymore, they're going to become demoralized and not want to make their pages valid.

Specifically, I propose the following approach to versioning for authoring conformance.  Every X years (say two or four), declare a snapshot version of authoring requirements, maybe call it HTML 2012 or whatever.  Anytime a page that was previously valid is made invalid by a spec or registry change, note in the spec or registry that it's still valid HTML 2012 (or whatever), but not later.  Anytime a page that was previous invalid is made valid, make pages retroactively valid too, so authors don't have to rewrite their pages to use new features and remain valid.  Then have the validator say "This is valid HTML 2012, but not HTML latest" or something.

Examples:

1) In 2012, we take a snapshot of author conformance requirements.  In 2013, we decide that <a name> should be made invalid.  Then we change the spec to say something like: "The name attribute on the a element is not conforming in versions of HTML later than 2012.  For HTML 2012 and earlier, conformance checkers must treat a nonempty name attribute on an a element as obsolete but conforming."  When this spec change is made, validators will no longer say (e.g.) "This page is fully valid HTML", but instead something like "This page is valid HTML 2012", with a link you can click to see what stops it from being valid HTML.

2) In 2012, we take a snapshot of author conformance requirements.  In 2017, we add a new <jack> element to support new hardware that allows users with appropriate neural implants to control their computer telekinetically, a feature that proprietary application APIs had for a few years but which was only just stable enough to add to the web platform.  Pages that were already valid HTML 2012 but use the new element are still valid HTML 2012.

We'd have to make sure all the registries take the same approach, making sure that they don't outright remove things but instead just mark them as being only in the appropriate old version.

All this isn't urgent, though, since HTML5 is still new and imposes lots of authoring conformance changes, and not many authors seem to be tracking it yet.
Comment 3 Julian Reschke 2011-07-31 14:51:29 UTC
(In reply to comment #2)
> ...

I agree with most Aryeh said.

However, versioning registries may be tricky and overkill. Furthermore, registries aren't supposed to *remove* entries anyway -- at least not in the case of "we don't like this anymore".

A simpler approach to deal with registries is not to make validity depend on them. It's fine to issue a warning for unregistered values, but it shouldn't be a conformance violation.

Also note that having unstable conformance criteria should prevent the IESG from accepting the specification as a description of the text/html media type.
Comment 4 Anne 2011-07-31 20:23:47 UTC
I disagree. If something is harmful, it should affect conformance retroactively.
Comment 5 Jirka Kosek 2011-07-31 20:37:11 UTC
(In reply to comment #4)
> I disagree. If something is harmful, it should affect conformance
> retroactively.

I disagree. 

But to move forward. On assumption that registries in question will be reasonably managed it is very unlikely that such situation will ever appear.

But it is bad in principle if conformance is depending on external resource which can constantly change and there is no trusted gatekeeper for this registry. So I still think that each published edition of HTML5 should either include snapshot of those registries or release relevant conformance criteria to allow any values.
Comment 6 Aryeh Gregor 2011-08-02 16:15:32 UTC
(In reply to comment #4)
> I disagree. If something is harmful, it should affect conformance
> retroactively.

If something was originally valid but become invalid, in most cases that should mean that it wasn't harmful originally but became harmful later, perhaps because better alternatives became reliably supported.  E.g., a page written in 1996 using <font> was written according to best practices at the time, and it's harmless to leave it as-is.  Authors should be encouraged to avoid <font> in all new pages, but there's no reason to encourage them to remove it from old pages that are already stable, especially since that's extremely burdensome if you have lots of pages.

This is especially true because one major use of conformance checking is to gauge how knowledgeable the page author was.  People who make assumptions about the quality of a page based on its conformance will be misled if it became non-conforming retroactively.  You might argue that this is misuse of conformance checking, but I'd disagree: whether the author bothered to use a validator tells you something about them.

Of course, none of this is to say that conformance requirements have to be absolutely set in stone.  If there are outright bugs or serious oversights, those can be applied retroactively.  But not stuff like "you shouldn't be doing X anymore now that there are better ways to do it".
Comment 7 Michael[tm] Smith 2011-08-04 05:34:46 UTC
mass-move component to LC1
Comment 8 Ian 'Hixie' Hickson 2011-12-02 19:03:00 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: Rejected
Change Description: no spec change
Rationale: The spec itself shouldn't be versioned, let alone the registries.
Comment 9 Julian Reschke 2011-12-02 19:07:53 UTC
I believe that basing document conformance on out-of-band information is a bad idea; if others agree with this we should make this as TrackerIssue.
Comment 10 Jirka Kosek 2011-12-02 20:36:26 UTC
(In reply to comment #9)
> I believe that basing document conformance on out-of-band information is a bad
> idea; if others agree with this we should make this as TrackerIssue.

I agree. Julian could you please make TrackerIssue. I don't have experience with this and honestly too busy now for investigating it.

Thanks,

Jirka
Comment 11 Julian Reschke 2011-12-02 20:43:11 UTC
(In reply to comment #10)
> I agree. Julian could you please make TrackerIssue. I don't have experience
> with this and honestly too busy now for investigating it.

Actually, we start with TrackerRequest (adding the keyword now).
Comment 12 Paul Cotton 2011-12-03 19:05:18 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > I believe that basing document conformance on out-of-band information is a bad
> > idea; if others agree with this we should make this as TrackerIssue.
> I agree. Julian could you please make TrackerIssue. I don't have experience
> with this and honestly too busy now for investigating it.
> Thanks,
> Jirka

Can you please "suggest title and text for the tracker issue"?

/paulc
Comment 13 Jirka Kosek 2011-12-04 10:23:28 UTC
Hi Paul, would that work:

Title: Document conformance has to be stable over the time

On several places conformance of document relies on external registry which is
not versioned -- it can add or remove any value at any time. This means that
for frozen document its validity can change.

Each edition of HTML spec should include snapshot of registries that can
easily change over the time to create more stable grounds for assessing document conformance. 

Thanks,

Jirka
Comment 14 Julian Reschke 2011-12-04 12:10:48 UTC
Raised as <https://www.w3.org/html/wg/tracker/issues/187>.
Comment 15 Julian Reschke 2012-01-10 10:29:27 UTC
Jirka, see <http://lists.w3.org/Archives/Public/public-html/2011Dec/0037.html>: A change proposal is due next weekend. Are you planning to write one?
Comment 16 Jirka Kosek 2012-01-10 10:39:03 UTC
Julian, I'm extremely bussy now, so if you have time to write one it would be perfect. If not, I will try to do my best.
Comment 17 Julian Reschke 2012-01-10 10:41:42 UTC
(In reply to comment #16)
> Julian, I'm extremely bussy now, so if you have time to write one it would be
> perfect. If not, I will try to do my best.

Jirka, I've got another one to take care of. You may want to ask the chairs for an extension then.
Comment 19 contributor 2012-07-18 07:25:36 UTC
This bug was cloned to create bug 17969 as part of operation convergence.
Comment 20 Travis Leithead [MSFT] 2012-08-21 21:48:04 UTC
[HTML5 ISSUE_187] Working Group Decision applied 

Relaxing rules for conformance checkers, so that they don't have to fail
when MetaExtensions not enumerated in the current spec are encountered.

Please see the diff for details:
https://github.com/w3c/html/commit/c2bc33702feb6c47fd96fcf9ce85042df2e4ba1b