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

Murray Maloney (murray@sco.COM)
Tue, 25 Apr 95 09:55:32 EDT

> Paul Burchard <burchard@math.utah.edu> writes:
>
> |Bert Bos <bert@let.rug.nl> 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.

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.
>
> 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.
>
> |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.

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.

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.

===========================================================================
---------------------------------------------------------------------------
Murray C. Maloney Internet: murray@sco.com
Technical Publications Writer/Architect Uucp: ...uunet!sco!murray
SCO Canada, Inc. My Phone: (416) 960-4031
130 Bloor Street West, 10th Floor Fax: (416) 922-2704
Toronto, Ontario, Canada M5S 1N5 SCO Phone: (416) 922-1937
===========================================================================
Disclaimer: I'm speaking for myself. 'T ain't nobody else to blame but me.
---------------------------------------------------------------------------
Sponsor member of Davenport Group Member of IETF HTML Working Group
===========================================================================