> 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.
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".
CONCLUDING PLEA:
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 craig@passport.ca 416-778-6136 416-778-1965 FAX Seventy Eaton Avenue, Toronto, Ontario, Canada M4J 2Z5