[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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12854

--- Comment #5 from Antoine Amarilli <a3nm@free.fr> 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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 9 June 2011 05:11:35 UTC