[whatwg] Where did the "rev" attribute go?

Charles Iliya Krempeaux supercanadian at gmail.com
Wed Jul 5 17:15:50 PDT 2006


Hello Lachlan,

On 7/5/06, Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
>
> Charles Iliya Krempeaux wrote:
> > What happened to the "rev" attribute?
>
> The problem with the rev attribute is that it's difficult for authors to
> understand the concept of a reverse link relationship; and compared with
> rel, it's hardly ever used.
>
> There's only one use of rev that I'm aware of which is listed on
> microformats.org.  It's for vote-links, but I don't think those
> relationships should be used anyway.



It would be a shame to get rid of it now, now that web developers are
starting to become "semantically minded".

Sure no one is using it that much right now.  But developers seemed to only
recently awaken to the idea of adding semantics into HTML.  (And it seems to
be catching on more and more.)

As developers start building semantics into web technologies, their going
find that they need the "rev" attribute.  (Not sure if that would be enough
"justification" here to keep it.  But since we already have it, it would be
nice to keep it.)


For example, I'm interested in trust metrics and reputation, so I consider a
"rel" and "rev" to work hand-in-hand to establish this.

For a real life example, consider these "community marks" people have been
talking about.  People want to essentially say someone is a member of a
group.  Let's use the Microformats.org group for example.  Well, if I wanted
to claim that I'm a member of that group, then I could put a Microformats
badge on my blog, and link it to the Microformats.org website.

But, being semantically minded, I'd link it like this:

<a rev="member" href="http://microformats.org/">
    <img src="http://microformats.org/image/badge.png" alt="Microformats.org"
/>
</a>

(Note the rev-member.)

Now that's great and all, but anyone can put a badge like that on their
site.  How do you know you can trust that?

Well, what if the Microformats.org website had a members page, and linked to
all their members, including my blog with the following:

<a rel="member" href="http://changelog.ca/">
    Charles Iliya Krempeaux
</a>

(Note that we are using "rel" here, instead of "rev" like before.  Also note
that the exact same label was using -- "member".)

Well then we'd know that we trust this relation, because we have the same
relation being asserted both ways.  (Or at least can trust it more than if
only one page was asserting the relation.)

Without the "rev", we could still do this with "rel" however, the exact same
label could NOT be used.  And then any kind of system to analyse this would
have to understand what this labels actually meant and know what the
"reverse relation" name was.


That is essentially my personal reason for wanting "rev".  So that the exact
same label can be used no matter what the direction of the relation.  (That
way a generic parser and query engine can be written for this type of stuff,
even if the system does NOT understand the meaning of the labels.)


> Neither the <a> or <link> element seems to have it anymore...
>
> I think it should still be present, but it's semantics would need to be
> clarified and explained.  We should probably also identify some real use
> cases where it is actually useful for authors.



I'm using it for trust metrics and reputation.  (But that's just me and the
software I write  :-)  )


> The "rev" attribute is important for allowing what I call "opaque
> > semantics".
>
> Can you more clearly define what you mean by "opaque semantics"?


Think about XML (as compared to SGML-based HTML).  One of the design goals
for it was to make it so that a generic parser could be written for it
without knowing anything about the meaning of the elements/tags.

This was accomplished by requiring lone elements -- elements without a
closing tag -- to have a "trailing slash".  So, for example, you would NOT
write "<br>" or "<hr>"; but you would write "<br />" and "<hr />".

This meant that the semantics of the elements/tags could be opaque.  A
generic XML parser didn't need to know that a "<br>" element did NOT have an
ending tag.

In fact, anyone can create their own custom XML-based language, and any XML
parser will be able to handle it properly.

In the same way, I'd like to keep this kind of advantage with typed links.
(I.e., keep this kind of advantage with linked that use "rel" and "rev".)

Analysing all these typed links (spread out across the web), you can create
a graph connecting URI's.  And the edges of the graph would have these
labels and which side of the URI asserted the relation.

With the "rev" attribute, the exact same label can be used.  The semantics
of the label can be opaque, but the system for analysing all this will work
anyways.

So, for example,... if the page http://z.example.com/ had links like the
following:

<a rel="aaa" href="http://a.example.com/">...</a>
<a rel="bbb" href="http://b.example.com/">...</a>
<a rel="ccc" href="http://c.example.com/">...</a>

And the page http://a.example.com/ had links like the following:

<a rev="aaa" href="http://z.example.com/">...</a>
<a rel="ccc" href="http://c.example.com/">...</a>

And none of the other pages had typed links, then we could form the
following graph and not even care what any of those labels meant.  (Hope
this looks OK in your e-mail program)

                     aaa (assert by both)
                   +-----+
                   |     |
                   V     |
                   A     Z
                   |    /|
               ccc |   / | bbb
                   |  /  |
   (asserted by A) V /|  V (asserted by Z)
                   C  |  B
                      |
                      |
                      |
                     ccc (asserted by Z)

(Note, I've used the sub-domain names only in the diagram below.)


Does that all make sense?  Have I explained things well enough?


See ya

-- 
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Make Television                                http://maketelevision.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20060705/87f8289a/attachment.htm>


More information about the whatwg mailing list