Ok. I see three issues. Here is a brief proposal for separating
the issues and developing an attribute value naming scheme. This is
not a fully fleshed out model, but is an attempt to provide a simple
scheme that appears to provide most of the features we desire.
Note that I don't think it is enough to consider REL/REV in isolation
of their use. In my opinion, the lack of a well-defined *use* for
REL/REV is a major reason why they were not implemented.
I envision four useful (two new) attributes to LINK or Anchor elements:
1. Relationship definitions: REL/REV=.......
This should *not* define the functional relationship between
linked objects, but only the semantic relationship. Thus
something like <... HREF="URL_B" REL="is_index" > means something
like "URL_B is an index of A". Clearly the grammar for this needs
to be clarified, as the last few letters on this subject have pointed
out. Nevertheless, I think it is important that REL/REV does not imply
a browser action (by which I mean things like cloning windows, replacing
the current document, creating a popup miniwindow, a sidebar window,
etc), although replacing the current document with the linked resource
is the obvious default. It also should not imply what type of HTTP
method should be used, although GET is the obvious default.
In a LINK element, the REL value can be used to indicate browser-
preferred action. For example, if you had REL=is_TOC the browser might
have a preferred (if it is a graphical browser) icon-bar entry to
bind to this relatinship, and might even have a preferred browser
behaviour (such as cloning a window) once this type of LINK is accessed.
In an A element, REL could be used to provide additional information
about a link, for example as a balloon help message when the cursor
is left lying over anchored text. If a TITLE attribute is present,
this information would also be presented as part of the balloon help.
If we want REL/REV to contain additional information about a link,
then these pieces of information should be separated by a defined
separator from the defines semantic names. For example:
"IS_TOC/Table of Contents for the Professional Bowling Web Site".
I prefer putting this information in a TITLE attribute.
2. Information about the linked resource: TITLE="title"
Information over and above the semantic relationship between
two objects could be expressed in the TITLE attribute. This is
consistent with older definitions of TITLE.
3. Browser Behavioural Hints: ACT=CLONE|REPLACE|POPUP|SPLITSCREEN.....
It seems reasonable to allow the author to suggest browser behaviour
when links are activated. For example, when I click on a LINK button,
should I clone a window for the link, or pop up a subwindow for
a glossary entry? Perhaps this should be part of a CLASS attribute,
but to my mind CLASS should be used to define the presentation/meaning
of a document element in the document BODY as opposed to browser
behaviour....
Possible values might be: CLONE|REPLACE|POPUP|SPLITSCREEN
4. Link Action: METHOD=GET|TEXTSEARCH
It would often be convenient to access a link using a defined HTTP
method other than GET. For example, suppose I have a LINK
attribute defining a related, searchable glossary. One desireable
behavior is as follows: the user highlights a word and clicks a
mouse button (or presses a glossary button). The browser accesses
the linked object, passing to it the highlighted text. The server
then returns the glossary entry relevant to the highlighted word.
This requres standardized methods and data encoding schemes. There
is only one, namely the HTTP TEXTSEARCH method, which is how ISINDEX
search data are sent to a server. I therefore propose that the
METHOD attribute have two possible values, namely GET|TEXTSEARCH,
to indicate how the client should access the linked resource.
nice to have this
Ian
-- Ian Graham ................................... igraham@utirc.utoronto.ca Instructional and Research Computing University of Toronto