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

Craig Hubley (
Thu, 27 Apr 95 16:23:22 EDT

> Can we not agree on a small set of generic, useful, non- ad-hoc link
Well, *I* personally don't think I can agree for reasons given below.

> RELs? E.g" Next, Previous, Table of Contents, Index and maybe even
> Author (although I am less fond of the latter, as I can see it leading
> to lots of spurious e-mail message .... :-o )
> These all seem pretty non-controversial, and obvious to implement.

The entire discussion we are having indicates that they are *not* obvious.
Each of the postings here today has listed *several new* interpretations of
even such 'obvious' link types as 'next' and 'previous' and 'back' and 'home'
and each of us is responding 'yes thats useful but what I had in mind was...!'

Although TOC, Index, etc., are heavily used in existing systems like libraries,
don't forget that software requires a far tighter definition than a librarian;
In the four major applications of hypertext I have worked on over 10 years,
I have had generally poor luck automatically processing links/tags intended
for human interpretation, and even *worse* luck getting human authors to be
as precise about their link/tag semantics as the software demands. It is
still extremely useful to have a one-word best-human-name-for-the-link-type
in a predictable place, but don't assume that software can always act on it.

It always seems that different sets of semantics exist, each may be obvious
to a human reader in context, and possibly to application-specific software,
but NOT to a browser without this application-specific knowledge. Therefore I
continue to advise extreme caution about proposing 'standard' REL attributes.

I like the idea of deliberately marking tags that are intended for machine
processing, I do something like this now anyway. However the REL="comment..."
approach leaves me cold. I would rather see, as I indicated re: REV and link
strength, to see a quality or quantity specified in one attribute and a 'name'
for human use in another... If necessary we can segment name spaces by some
means that unambiguously identifies the body of practice / context in which
the relationship was named, e.g.


That would help (but not resolve totally) the semantics of what a link means.
But I don't want to standardize this usage or name space. Make no mistake:

... future generations will curse our names for assuming that
we understood *anything* about link semantics 'back in '95'

... some effort equivalent in scope/scale to the URI/URN effort must be
launched before we can standardize link types sensibly... in the
meantime, just as with URLs, let's just give them a place to exist
so folks can experiment and bodies of practice can arise.

If we can find clear, browser-behavior definitions for 'Table of Contents',
etc., in say the ISO 'Book' DTD, then it might be reasonable to crib such
tags as could be found there, but ONLY as 'recommendations' for establishing
a name space, e.g. REL="ISObookDTD/Author".


In case anyone still doubts, just look back at today's html-wg traffic. In
today's postings I see several different semantics for 'Back', 'Home', etc.

Is Home your own home, or the 'Home' of the corpus you are reading, or that
of the institution whose corpus you are reading, etc. ?

Does Back go back chronologically to the last state of your present page,
back topologically to the next level up towards the corpus 'Home', etc. ?

Just collecting all these is a chore, but if people remain unconvinced that
it is premature to standardize semantics of link types, I will do so myself
and repost all the contradictory definitions...

Craig Hubley                Business that runs on knowledge
Craig Hubley & Associates   needs software that runs on the net     416-778-6136    416-778-1965 FAX
Seventy Eaton Avenue, Toronto, Ontario, Canada M4J 2Z5