After 2.5 weeks of vacation and 1.5 weeks of catching up on back mail,
I have an interesting perspective on this whole discussion regarding
REL and REV and typed links. I am sorry that I missed the beginning
of the discussion, since I had a similar one via e-mail with the W3C
team in March.
First, let me point out a discrepancy between your discussion and
*reality*, where reality is defined as the WWW link type model.
[Note: you may define your reality differently, but not within the
scope of this WG]
* All but one of the messages on this and prior REL and REV
threads has failed to correctly define REL and REV. In fact,
almost all participants in the discussion use them backwards.
This is not really all that surprising. All of Dave's examples in
the HTML 3.0 spec are wrong. The SCO implementation is wrong.
In fact, just about every single implementation of REL and REV that
I know of is wrong, the exception being Lynx's use of REV="Made".
For example, Murray [in his very nice paper] defines them as
> REL
> Used to describe the relationship from the linked object
> specified by the HREF attribute. For example, REL=NEXT is
> used to indicate that the linked object is the next logical
> document in an author-specified sequence.
>
> The REL attribute can be used to support search for links
> serving particular relationships.
>
> REV
> Used to define the relationship to the linked object specified
> by the HREF attribute. For example, REV=PREVIOUS is
> used to indicate that the linked object is the next logical
> document in an author-specified sequence.
>
> A Table of Contents might contain a series of anchors which
> specify REV=CONTENTS.
which are, in fact, polar opposites of the WWW definitions:
REL
Used to assign relationship types to the link which apply
from the source document to the destination href and title.
For example,
<LINK rel="Precedes" href="chapter2.html">
indicates that the current document precedes chapter2.html.
A more useful example is
<LINK rel="Obsoletes" href="rfc1351">
indicating that the current document obsoletes rfc1351.
REV
Used to assign relationship types to the link which apply
from the destination href/title to the source document.
For example,
<LINK rev="Made" href="mailto:fielding@ics.uci.edu"
title="Roy T. Fielding">
indicates that Roy T. Fielding (accessible via the e-mail address
"fielding@ics.uci.edu") made the current document.
==================
The WWW Link Model (extracted from discussions w/TimBL and others)
==================
Why, you may ask, did the WWW start with these definitions for REL and REV?
The answer is that it reflects the underlying model of link relationships
as verb phrases. Originally the idea was to have relationships be verbal,
i.e., within document A:
rel="made" href="B"
or
rel="made_by" href="B"
or
rev="made" href="B"
can be read as statements
A made B
A is made by B
B made A
Unfortunately, if you use a noun phrase
B author A
it isn't so easy to read. The noun phrase has to be associated
with something. Naturally, most people assume
B author-of A
But look at what affect that has on the syntax! People assume that
you can simply say
rel="author" href="mailto:B"
which in fact means
A author B
the exact opposite of what was intended. Although this is simple
to correct, the analogous case with navigational links is not.
For example, how many people can tell me the chapter number of A
if it contains
rel="next" href="chapter2.html" ?
How about
rev="prev" href="chapter2.html" ?
or
rel="prev" href="chapter4.html" ?
Now, I dare anyone to claim that an ordinary HTML author can use
such an inherently confusing syntax with any degree of reliability!
Even when the list of names is restricted to verbs (as it should be
if we are to stick with the WWW model of REL and REV), the lack of
a visible subject for the verb (the source document) within the stated
syntax will continue to make this a user-unfriendly method of assigning
link types. Besides, people prefer using noun phrases.
RECOMMENDATION: Abandon this model. Declare REL and REV to be deprecated,
and replace them with ROLE="" (defined in SGML as type NAMES).
===============
Link Type Names
===============
Hierarchical? Ask yourself a question: Are links types within an author's
web considered to be differentiated by hierarchy? No, they are a
flat namespace within that author's realm of thinking. So, we are
left with defining well-known types and "private" types.
Now, what is the sole difference between well-known types and private types?
Someone else may not understand my private types.
Do we care?
No. It is not necessary to understand the semantics of non-well-known
types -- just knowing the implied semantics (that they are different
from links without types or with different type names) is sufficient.
But shouldn't they have an "X-" prefix, or something to indicate they
are not well-known? OVER MY DEAD BODY!
THOU SHALT NOT REUSE FAILED IDEAS FROM PAST IETF SPECIFICATIONS,
particularly when such ideas were not designed for recoverable,
interactive systems.
Can't we make it easier to discover the semantics of unknown types?
Sure, just use meaningful type names, or define an equivalent of
stylesheets for link semantics, and ask the user agent developers
to allow dynamic assignment of semantics by the users. No big deal,
and it is completely unnecessary to distinguish between private and
well-known types.
============
Link Actions
============
All link actions currently default to "GET" (not "goto", as others
have mentioned). Different link actions have differing data requirements,
and are better represented as FORMs. Furthermore, the action of selecting
a hypertext anchor should be idempotent.
Adding an ACTION="" attribute to A and LINK would be okay by me, but
only if the spec requires that non-idempotent actions be clearly
rendered as such or verified by the user.
Presentation style is orthogonal to link actions, though the latter
may affect the presentation in non-optional ways.
=====================================
Presentation Style and Link Semantics
=====================================
There are three issues here:
1) presentation of the anchor/link prior to traversal;
2) when the link should be traversed;
3) presentation of the result after traversing the link.
These are what stylesheets are for -- define a default presentation
style for each link type and allow these to be overridden within stylesheets
and UA configurations. The style should be context-sensitive to the
extent that being within a <BANNER>...</BANNER> element may change
the default style. Similarly, conditions like "has the user seen this
URL in the past" should affect the rendering style.
Role serves as the name upon which styles are attached.
The second and third issues define the link semantics.
(1) Anchor Highlighting
None
Underline
Outline
Button
...
(2) Temporal semantics -- when should the action take place
UserSelect (as is the case for anchors and FORMS)
AutoEntry (as is the case for EMBED or IMG)
AutoExit (an interesting derivative)
Export (only used external to the user process)
(3) Presentation semantics -- where should the results be "placed"
Replace
Alongside
Embed
Popup
A style="" attribute (defined as NAMES) would do nicely here.
=======
Summary
=======
Consider the following default semantics:
<IMG src="test.gif"> ==> role="Img"
style="None AutoEntry Embed"
<A href="test.gif"> ==> role="A"
style="Underline UserSelect Replace"
<LINK role="ToC"> ==> role="ToC"
style="None UserSelect Alongside"
<LINK role="ToC" style="AutoEntry">
==> role="ToC"
style="None AutoEntry Alongside"
<NOTE style="popup"> ==> role="Note"
style="Button Popup UserSelect"
The presence of link semantics inside the style NAMES serves to
override the default link semantics for that type.
=========================
Where do we go from here?
=========================
At this point I'd like to throw a wet blanket on the link type
discussion. It seems clear to me that the WG does not intend to
specify the WWW link model (not surprising really) and that there
is no valid current practice upon which to judge a specification.
Therefore, the discussion has gone outside the bounds of something
that can be effectively addressed by the WG as a whole.
My recommendation is that people go out and architect a system
(or several different systems) which supplies an HTML-compatible link
model upon which we can think about standardizing, write a concrete
specification of that model, and then come back and present it as
an Internet-Draft.
....Roy T. Fielding Department of ICS, University of California, Irvine USA
<fielding@ics.uci.edu>
<URL:http://www.ics.uci.edu/dir/grad/Software/fielding>