I've been thinking (a sometimes dangerous thing) and have the following
observations:
Observations --
* I believe that We are attempting, through the REL/REV attributes,
to define at least two distinct things:
- the *meaning* of the relationship, and
- the desired *implementation* should that relationship
be accessed.
By the latter I mean what happens if a link is accessed. For example,
should the target (a footnote) be popped up as a sidewindow,
overloaded on the current document, or loaded in as a replacement
stylesheet?
* The use and behaviour of REL/REV are different when they are in a
LINK in the head, or in an Anchor in the body. Does an anchor
element referencing a stylesheet (REL=stylesheet) make sense?
I don't think so....
Ideas --
Stylesheets would appear sufficiently distinct from ordinarly
links that they should be given their own HEAD element.
LINK is generally used to define relationships to information bearing
on a document's *content*, whereas a stylesheet talks about how
it *looks*. I suggest a new HEAD element for stylesheets,
for example:
<STYLESHEET LOAD="overload|replace..." URL="...">
where LOAD specifies what to do with the new stylesheet
(overload the existing one (do not erase non-conflicting
definitions), replace the stylesheet (delete non-conflicting
defninitions in the old stylesheet) etc.
For REL/REV, I suggest creating two attributes reflecting the
two characteristics mentioned above. This is similar to Craig's
idea, but separates the meanings into two distinct names. As an
example I put forward:
REL - for the meaning of the relationship
ACT - the desired implementation by a browser.
The REL and REV values could have the values that have been floating
about (LocalHome, Next, Previous, Author, ToC (a.k.a. Contents), and
so on, while ACT would specify a desired action by the browser.
Some examples might be:
replace (browser replaces current document by link)
popup (browser creates a small popup window for the
linked document)
new (browser forks a copy of itself, into which it
loads the new document)
split (browser splits the screen in two, putting the
linked document in half the screen)
How would this work in practice? Consider first LINK elements.
A client reads the LINK REL/REV values and, if it understands these
values, associates a predefined menu icon or character string with
the LINK (this can be locale() specific). It then tiles the window
with the relevant LINK buttons. If it does not understand the
REL attribute it tiles a button using the REL value as a label.
The browser is configured to have a collection of default actions
is should implement when an understood REL/REV link is accessed.
Thus is might know that a LINK REL="footnotes> link should be popped
up as a small window.. If the browser does not understand the REL/REV
it should execute a default action (such as overloading the current
document with the linked one).
If the browser understands the ACT attribute values, it implements
the browser action specified by the ACT attribute, overriding any
default actions assumed by the browser. IF it does not understand
the ACT attribute value, it uses its own default actions.
Experimental REL/REV and ACT values can be defined by the prefix
X-. Practice has shown that this method rarely results in conflicts
between namespaces.
Non HTML Applications of REL --
Although it would be nice to say that REL/REV have universal
applicability. Is it not likely that many relationships will only
have meanings in certain contexts? For example, REL="Index"
does not have an obvious in a VRML scene.
----
And now back to our regularly scheduled program.....
Ian
-- Ian Graham ........................... igraham@utirc.utoronto.ca