After reading Roy's mail, I have had to breathe a deep sigh too.
There is a lot of value in what Roy offers here, but there are
also a few contentious -- to me anyway -- assertions which do
not coincide with my own experience in developing a corpus of
computer system software documentation for use with a compliant
HTML browser.
>
> 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.
Which W3C team? Perhaps it would have been useful to share
that discussion with others on the HTML WG.
>
> 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]
Hmmm! Well I suppose that depends on what you mean by the WWW model.
I may be mistaken, but I thought that the HTML WG was the group,
within the context of the IETF, made decisions about reality within
the scope of the HTML WG. Perhaps we need to have a discussion
about the relationship between and among the various parties involved
in the HTML WG and the W3C.
>
> * 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".
I don't see how a proposed spec and a working implementation
can be labelled as wrong. At the most recent IETF meeting
it became clear that there was a great deal of confusion over
the correct semantics to apply to REL/REV and various people
called for clarification in the spec.
> For example, Murray [in his very nice paper] defines them as
[definition elided]
> which are, in fact, polar opposites of the WWW definitions:
[definition elided]
I'll concede that two definitions are opposite. So what?
With all due respect to Tim, his original thinking on the
subject was -- apparently -- not expressed in the HTML spec.
SCO developed an implementation based on the spec as it
was then defined and continued to develop. Dave Raggett
developed the HTML 3.0 spec with a similar understanding.
>
> ==================
> 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,
[examples and discussion elided]
>
> 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).
I think that the so-called "WWW Link Model" was abandoned a long time ago.
The HTML 2.0 spec is somewhat ambiguous in saying that REL "gives the
relationship described by the hypertext link from the anchor to the
target." ... "Values and their semantics will be registered by the HTML
registration authority."
I am most assuredly opposed to deprecating REL/REV, noting that the
online documentation browser which employs <LINK REL=...> is now
being shipped with SCO OpenServer Release 5.
I am, on the other hand, in favor of using NAMES for REL/REV.
> ===============
> Link Type Names
> ===============
[discussion elided]
>
> ============
> 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.
Point taken on "GET" vs. "goto.
Please explain about link actions being better represented as FORMs?
Please explain in detail what you mean by "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.
Please explain and give examples.
>
> Presentation style is orthogonal to link actions, though the latter
> may affect the presentation in non-optional ways.
>
> =====================================
> Presentation Style and Link Semantics
> =====================================
This is a very useful exposition. I disagree with minor points,
but largely think that Roy has got this part dead right.
>
> 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.
Agreed. But we don't have stylesheets yet. To what extent should
the HTML spec -- or a separate I-D for links -- attempt to provide
guidance/hints/suggestions as to appropriate default behaviour under
certain well-defined circumstances.
>
> Role serves as the name upon which styles are attached.
Here we disagree.
> 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)
Hmmm. Would the AutoExit derivative provide a means for me to
do indirection? For example, in document A I have <A HREF=B#foo>,
and in B I have <LINK NAME=foo STYLE=AutoExit HREF=C>. Would
asserting the anchor in A lead me to C? If so, wonderful.
If not, then why not and what then?
Please explain the meaning of "Export"? That is, if I use it
what does it imply about "when should the action take place"?
>
> (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.
I agree that the WG does not intend to use the "WWW link model".
I entirely disagree that there is no valid current practice!
> 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.
Been there, doing that!
>
>
> ....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>