Re: REL and REV attributes (Was: More comments on HTML 3.0)

Bert Bos (
Tue, 25 Apr 95 12:32:12 EDT

Murray Maloney writes:

|> Paul Burchard <> writes:
|> |Bert Bos <> writes:
|> |> p.18 "LINK":
|> |> I still don't see why we need both REL and REV. They have
|> |> exactly the same meaning.
|> |(I assume you meant, exactly the _opposite_ meaning.)
|> No, I mean the *same*.
|> |That's the point. Since links have two ends, it's inherent in the
|> |design that you want to be able to express reverse relationships.
|> |Given both REL and REV, the reversal can be accomplished precisely.
|> |(E.g., <A REV="Next"> to roll back history.)
|> Both REL and REV assign a type to a unidirectional hyperlink. They say
|> that the target fulfills role X relative to this document, where X is
|> parent, successor, glossary, translation, whatever. The choice of REL
|> or REV depends only on whether you can invent a name for the
|> relationship:
|> "that is a (the) X of this" "this is a (the) X of that"
|> --------------------------------------------------------------------
|> REL=parent is equivalent to REV=child
|> REL=successor is equivalent to REV=predecessor
|> REL=glossary is equivalent to REV=doc_for_which_that_is_glossary
|> REL=toc is equivalent to REV=doc_for_which_that_is_toc
|> REL=author is equivalent to REV=product
|Not all paired relationships can/should be described using antonyms.
|For example, it is not always the case that A's "next" document
|necesarily considers A to be its "previous" document. One might
|have a branch of nodes where each document each document points
|to the "next" in succession, but they all point to the first as
|the "previous". A procedure, for example.
|Not that is especially relevant to online doc, but if REL=uncle
|what is REV? Similarly for AUNT, NEPHEW and NIECE.

But that's not what REV does. The fact that A contains <LINK HREF=B
REV=next> has nothing to do with the fact that B contains <LINK HREF=A
REL=next>. Indeed, B may have no relation to A whatsoever.

|In the example above, Bert mentioned the Table of Contents (toc)
|-- a useful foil for describing the importance of reverse relationships.
|A Table of Contents, in many cases, is used to list the various
|nodes (objects) contained within a whole document. Its utility is obvious.
|Establishing a <LINK REL=toc HREF=toc.html> within all nodes (objects)
|of a whole document provides an educated browser with sufficient
|information to allow (even encourage) it to place a CONTENTS icon
|on a toolbar and present the Table of Contents according to the
|design specified by the browser -- adjacent pane within the app,
|a separate window, or in the same window. A very useful mechanism.
|But, an educated browser could do so much more by also reading
|a REV value. Consider a node which declares itself as a CHAPTER
|by establishing <LINK REL=toc REV=CHAPTER HREF=toc.html>. The
|browser can provide greater context when presenting the
|Table of Contents. That is, the browser could provide a means
|to display the Table of Contents only for the specific chapter
|by extracting or subsetting that information on presentation.

You want to use REV to parametrize REL. That's certainly more
useful. You can even get more than one level of subclassing by using
the syntax proposed for the CLASS attribute: CLASS="toc chapter terse".

|> Sometimes you may want a verb instead of a noun (REV=made). Note that
|> values for REV are rather unintuitive. In fact REL is somewhat
|> ambiguous as well. Why not drop both and use ROLE instead (or maybe
|> even CLASS)?
|Clearly a specific list is required with clear and agreed semantics.
|In fact, it may be necesary to specify the semantics of some
|combinations of REL and REV values.

Agreed, but don't standardize it too soon. The obvious ones (toc,
next, parent, glossary) are easy enough to agree on, but beyond that
it may be a difficult task.

One example that's not on the obvious list: In the HTML 3.0 draft,
Dave Raggett writes that he used REV="ToC" to tell the formatter that
the link was to be represented as a page number in the hard-copy
version. That style of representation is the visual outcome of a link
to a document that is assigned the role "document for which this is a
ToC", or more abstract: "section in same book" or even "part of

|> |But given only REL, one would be forced to rely on an ad-hoc
|> |catalog of "reverse words" (parent/child, made/maker, next/back,
|> |etc). Beyond some dictionary of registered antonyms, there would be
|> |no reliable way to reverse relationships.
|> The "reverse relation" is still the *same* relation. Unless you want
|> to write a natural language generator, why would you want to find
|> English words for it? There is only one relationship, whether you call
|> it "parent", "child", "foo", or "R7547". If you want to express two
|> independent relations, you should use two LINKs instead of one LINK
|> with two attributes.
|While it is possible to use REL and REV to describe the same
|relationship in reverse, that is clearly not useful or helpful.
|I don't think that anyone is interested in arguing in favor
|of such a patently useless application of REL and REV.

So let's make sure they aren't used as such.

|I trust that my brief examples have demonstrated that it is possible
|-- and very useful -- to identify relationships using REL and REV.
|Further, I hope that my examples have demonstated that it is not
|always accurate to infer or imply a reverse relationship by use
|of antonyms.
|Finally, I'd like to note that there is a difference between the
|two keyword pairs "forward/back" and "previous/next". In most
|browsers which I have used -- and certainly our own -- "forward/back"
|keywords are associated with the path that has been travelled.
|So, "back" means "go, backwards in the history, to the most recent
|node that this browser has visited" and "forward" means "go, forward
|in the history, to the most recent node that this browser has visited".
|My experience leads me to expect that "forward/back" would not be
|used as REL and REV values, unless the intention was to overwrite
|the browser's history -- a potentially annoying effect.

Good point. The same problem occurs with "home". (Exactly how the
history looks and therefore what the meaning of "back" is remains a
problem, but that's a user interface issue.)

|In SCO's online doc and context-sensitive help browser -- which is
|the only place that I have seen "previous/next" actually used --
|the "previous/next" keywords are currently used as REL values.
|These keywords are associated with "previous/next" icons which
|allow one to travel the author's intended linear path through
|a chapter or book. In this scenario, antonymic REL and REV
|relationship values would apply and are omitted for brevity.


                          Bert Bos                      Alfa-informatica
                 <>           Rijksuniversiteit Groningen
    <>     Postbus 716, NL-9700 AS GRONINGEN