[uf-discuss] Vote Links: rel="voted-for"

[Ara Pehlivanian]

> I disagree.
>
> First of all, you don't need both @rel and @rev for votelinks. Right
> now you just need @rev to declare votes. Linking in the opposite
> direction doesn't add anything, as it is a 3rd party assertion (or
> hearsay).
>
> Secondly, if people can't figure out how to use it properly, they'll
> use it improperly. Then people building tools will have to deal with
> that confusion. It's better to just make the technology simpler and
> unambiguous.
>
> Removing @rev is not hobbling HTML5. Very few people who use it
> properly and even more use it improperly. See Google Web Authoring
> statistics for more data [1].

As I'm sure you're already aware, two discreet bits of data are
communicated via the rev/rel attributes. The attribute itself
communicates the direction of the relationship while the value states
the type of relationship. By dropping one of the directions, you
introduce ambiguity in the data.

At least one real world example for the implementation of a rev/rel
relationship exists: my previously stated "site of the month"
scenario. A vote using rev is made for a site of the month. That site
in turn will link back to the originator via an icon with a rel. This
would properly describe the forward/reverse relationships between
sites. To a machine crawling the vote icon (rel), it will properly
pick up the URL of as the source for the vote and not a site that's
being voted for. Similarly, if a machine were to crawl the site where
the "sites of the month" are picked, it would know that this is the
originator who is voting (rev). The ambiguity caused by ignoring the
direction of the vote could really throw off stats when tallying
votes. And that's just one example.

I don't agree that rev should be dropped in order to fall in line with
the way rel is being (badly) used today. Rather, if a change is to be
made to the spec, it would make more sense to revisit the entire
attribute set so as to come up with something that is easier to
use/understand while still being able to define a direction for the
relationship as well as a type. Either that, or we should stick with
the existing spec and simply require developers to understand and use
it correctly. Nobody dumbs down compilers because of thick coders, why
is this any different? It took me a couple of posts on this list and I
ended up learning.

If the spec just ends up bending to the popular usage, then what's the
point behind the standards movement? We may as well invest our time
writing better error correction.