LINK has been around since HTML1, and never used, essentially because the
wg can't agree on some simple REL attributes. Without standardized
values, LINK is basically useless. This seems sad, since I've read
many, many notes over the past year saying ... "LINK damn well would
be useful, if only we could agree how to...."
No one is going to agree on meanings for simple relationships names
like Next, Forward, Back, Previous, etc, until a Name/Rule relationsip
is selected. I don't really care that much what they are. If someone
were to say: " 'REL=Next' means next logical document in a
linearly linked collection" then I'm happy as a clam. If they
say " 'REL=Following' means next logical document in a
linearly linked collection" then I'm happy too.
I don't care, so long as it works, and that it's a standard.
MY list of a few simple relationships (Next, Previous, LocalHome, LocalToC,
LocalIndex, etc) reflected those links that nearly *everybody* already
hard-wires into large collections, using regular anchors, pretty images,
etc. They put these buttons or icons at the top of pages, at the
bottom, and sometimes in the middle, just to get past the fact there
are no funtional LINK elements to accomplish these obvious tasks.
This does not preclude doing smarter things (like much of what has
been discussed in this thread) later. It just allows people to stop
doing stupid things we are forced to do currently.
So, after that diatribe -- Here's my list:
Rel=Next "next logical document in a linearly linked
document collection local to the current document"
Rel=Previous "next logical document in a linearly linked
document collection local to the current document"
Rel=LocalToC "Table of Contents page for the document collection
containing the current document"
Rel=LocalIndex "Index document for the document collection
containing the current document"
Rel=LocalHome "The home document of the document collection
local to the current document"
Rel=LocalAuthor "Informational link to the author of the current
document"
The names can be changed, to protect the innocent......
Ian
-- > > 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. >> 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. > > REL="LibraryOfCongress/Citation/Author" > > 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: > > LINK SEMANTICS ARE EVEN MORE COMPLEX THAN NAMING SEMANTICS... > ... 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".