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 12854 - I am quite surprised to see that things such as the list of allowed values for the "rel" attribute of the "link" tag (aka. the list of link types) as well as the list of allowed values for the "name" attribute of the "meta" tag are supposed to be listed o
Summary: I am quite surprised to see that things such as the list of allowed values fo...
Status: RESOLVED DUPLICATE of bug 14363
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: contributor
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-02 15:16 UTC by contributor
Modified: 2011-12-02 18:12 UTC (History)
10 users (show)

See Also:


Attachments

Description contributor 2011-06-02 15:16:25 UTC
Specification: http://www.w3.org/TR/html5/
Section: http://www.whatwg.org/specs/web-apps/current-work/#top

Comment:
I am quite surprised to see that things such as the list of allowed
values for the "rel" attribute of the "link" tag (aka. the list of link
types) as well as the list of allowed values for the "name" attribute of
the "meta" tag are supposed to be listed on external wiki pages
(http://microformats.org/wiki/existing-rel-values and
http://wiki.whatwg.org/wiki/MetaExtensions). The standard mandates that
the wiki pages can be edited by anyone, and that conformance checkers
must use them to establish if a value is valid or invalid.

As I understand it, a close reading of this part of the standard means
that, were the wiki pages blanked by an malicious or clueless user, a
great number of documents would instantly become, strictly speaking,
invalid. In pretty much the same way, if the wiki were temporarily
unavailable for some technical reason, the conformance of documents
could not be evaluated. This would mean that, strictly speaking, the
precise notion of HTML5 conformance could change at any time, at the
whim of absolutely anyone, and that validators should theoretically
enforce this.

In my opinion, the wiki pages should be presented as a recommended place
to read about existing usage and discuss possible additions; however,
this should be clearly separated from the normative part of the standard
which should indicate that any ASCII case-insensitive value (or absolute
URL for link types) is legal. Making some common values part of the
standard, as is done currently, seems reasonable, but the other values
should be normatively accepted, not accepted depending on their presence
on the wiki.

This is quite a minor point and of little practical importance, but the
current state of the text makes it quite hard to write a fully compliant
conformance checker or to ensure that a given document remains fully
compliant over time; I consider this an issue worth mentioning.

The relevant sections of the document as of this writing are:
http://www.w3.org/TR/html5/links.html#other-link-types
http://www.w3.org/TR/html5/semantics.html#other-metadata-names

Thank you for your time,

-- 
Antoine Amarilli


Posted from: 66.108.174.98
User agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.19) Gecko/20110430 Iceweasel/3.5.19 (like Firefox/3.5.19)
Comment 1 Aryeh Gregor 2011-06-02 22:13:01 UTC
Plenty of things rely on registries.  You have to use common sense: if the IETF registry for MIME types is down due to a network outage at the data center they use, that doesn't suddenly make all MIME types invalid until it's back up.  Likewise, if the wiki page is briefly vandalized, wait until it's fixed.  As Wikipedia demonstrates, things like deleting the page contents don't have to last long on a wiki.  The microformats wiki has served as a de facto registry for a long time.

If there turn out to be practical problems with using a wiki for an official registry, that can be dealt with at the time, possibly by requiring wiki edits to undergo moderation or similar.  However, there's no reason to worry until it proves to be a problem in practice.  Other registries (like the MIME type registry) have tended to be extremely incomplete or out-of-date because of the difficulty of registering new entries.  It's worth trying to find out if this way works better.
Comment 2 Antoine Amarilli 2011-06-03 05:05:17 UTC
(In reply to comment #1)
> Plenty of things rely on registries.  You have to use common sense: if the IETF
> registry for MIME types is down due to a network outage at the data center they
> use, that doesn't suddenly make all MIME types invalid until it's back up.

Okay, I admit that this point of mine was probably a bit far-fetched.
 
> Likewise, if the wiki page is briefly vandalized, wait until it's fixed.  As
> Wikipedia demonstrates, things like deleting the page contents don't have to
> last long on a wiki.

This is no problem for a human, indeed, but the standard specifically indicates that compliance checkers must abide by the wiki page, and they cannot show common sense to estimate if the current state of the wiki page is sane.

>   The microformats wiki has served as a de facto registry
> for a long time.

I understand that. My point is that this should continue to remain unofficial, and probably be mentioned by the standard though not in a normative sense.

> If there turn out to be practical problems with using a wiki for an official
> registry, that can be dealt with at the time, possibly by requiring wiki edits
> to undergo moderation or similar.

This is not allowed by the current wording of the standard, which states that "Anyone is free to edit the Microformats wiki existing-rel-values page at any time to add a type." The standard even states that "conformance checkers should offer to add [unknown values] to the Wiki" (supposedly to make the document valid).

>   However, there's no reason to worry until it
> proves to be a problem in practice.  Other registries (like the MIME type
> registry) have tended to be extremely incomplete or out-of-date because of the
> difficulty of registering new entries.  It's worth trying to find out if this
> way works better.

I think you can get the best of both worlds by indicating the Wiki as a recommended discussion page in the standard, but not as part of the norm. I fail to see how the currently proposed approach is better: it imposes a burden on compliance checkers, and amounts to the same as accepting mostly anything (if compliance checkers really allow users to add any value they like to the wiki to make their documents valid, do you really expect the wiki to be useful to standardize attribute values?).
Comment 3 Henri Sivonen 2011-06-03 12:33:13 UTC
FWIW, current known validator deployments need human intervention to update the validators' copies of the registry lists, so validators currently don't start reporting things as invalid the moment someone breaks the wikis.
Comment 4 Aryeh Gregor 2011-06-05 18:14:07 UTC
(In reply to comment #2)
> This is no problem for a human, indeed, but the standard specifically indicates
> that compliance checkers must abide by the wiki page, and they cannot show
> common sense to estimate if the current state of the wiki page is sane.

Well, in particular, the validator maintainers could always revert the changes themselves.  Or decide not to update their copy of the list at this moment.  The standard specifically indicates that validators can cache the page contents -- they don't have to use the very latest version.  Henri is the only one I know of who runs an HTML5 validator, and he only updates the allowed value list manually.

> This is not allowed by the current wording of the standard, which states that
> "Anyone is free to edit the Microformats wiki existing-rel-values page at any
> time to add a type." The standard even states that "conformance checkers should
> offer to add [unknown values] to the Wiki" (supposedly to make the document
> valid).

That wording is not incompatible with some type of moderation.  It doesn't say the edits have to be visible immediately.  In practice they currently are and it's not an issue, but if you're worried about futureproofing, the wording could doubtless be loosened a bit.

> I think you can get the best of both worlds by indicating the Wiki as a
> recommended discussion page in the standard, but not as part of the norm. I
> fail to see how the currently proposed approach is better: it imposes a burden
> on compliance checkers, and amounts to the same as accepting mostly anything
> (if compliance checkers really allow users to add any value they like to the
> wiki to make their documents valid, do you really expect the wiki to be useful
> to standardize attribute values?).

Anyone can add an entry, but other people can remove it too if they think it's illegitimate.  That's how wikis work.  Personally I do expect a wiki will be useful to standardize attribute values, but we won't know until we try.  This wording has been in the standard for a while now and there have been no notable problems, so it's fair to say that the burden of proof should be on the ones arguing for its removal, not the ones arguing to keep it.
Comment 5 Antoine Amarilli 2011-06-09 05:11:26 UTC
(In reply to comment #4)
> (In reply to comment #2)
> > This is no problem for a human, indeed, but the standard specifically indicates
> > that compliance checkers must abide by the wiki page, and they cannot show
> > common sense to estimate if the current state of the wiki page is sane.
> 
> Well, in particular, the validator maintainers could always revert the changes
> themselves.  Or decide not to update their copy of the list at this moment. 
> The standard specifically indicates that validators can cache the page contents
> -- they don't have to use the very latest version.

The current wording seems to suggest that this is only supposed to happen for technical (connectivity) reasons, not that validators maintainers should cache the page and update it manually as a way to filter out bad wiki edits. What you suggest seems sensible, but I feel the current wording is slightly unclear.

> Henri is the only one I
> know of who runs an HTML5 validator, and he only updates the allowed value list
> manually.

Ok, this is sensible; again, maybe the wording could be altered to suggest that this is acceptable.

> > This is not allowed by the current wording of the standard, which states that
> > "Anyone is free to edit the Microformats wiki existing-rel-values page at any
> > time to add a type." The standard even states that "conformance checkers should
> > offer to add [unknown values] to the Wiki" (supposedly to make the document
> > valid).
> 
> That wording is not incompatible with some type of moderation.  It doesn't say
> the edits have to be visible immediately.

That seems quite a stretch. In practice, what would happen if someone validates a document with an unknown value and accepts the validator's (recommended) suggestion of adding it to the wiki? It would seem quite confusing for this addition not to be visible immediately, wouldn't it?

> In practice they currently are and
> it's not an issue, but if you're worried about futureproofing, the wording
> could doubtless be loosened a bit.

Yeah, I would think that this would be safer.

> > I think you can get the best of both worlds by indicating the Wiki as a
> > recommended discussion page in the standard, but not as part of the norm. I
> > fail to see how the currently proposed approach is better: it imposes a burden
> > on compliance checkers, and amounts to the same as accepting mostly anything
> > (if compliance checkers really allow users to add any value they like to the
> > wiki to make their documents valid, do you really expect the wiki to be useful
> > to standardize attribute values?).
> 
> Anyone can add an entry, but other people can remove it too if they think it's
> illegitimate.  That's how wikis work.  Personally I do expect a wiki will be
> useful to standardize attribute values, but we won't know until we try.  This
> wording has been in the standard for a while now and there have been no notable
> problems,

This does not prove much if, as you say, there is only one current implementation of the validator and it doesn't follow this part of the standard to the letter.

>  so it's fair to say that the burden of proof

I can't see how I could prove that problems with arise until validators start implementing this part of the standard.

>  should be on the ones
> arguing for its removal, not the ones arguing to keep it.

My point is just that you could do this experiment without giving a real normative role to the wiki, which would serve as a de facto appendix to the standard if things do well as you hope they will. It seems simpler and safer to make the wording less specific and just advise validators to use the wiki and refer users to it rather than requiring them to use it.
Comment 6 Michael[tm] Smith 2011-08-04 05:34:22 UTC
mass-move component to LC1
Comment 7 Ian 'Hixie' Hickson 2011-12-02 18:12:28 UTC

*** This bug has been marked as a duplicate of bug 14363 ***