I'd like to bring up a number of fundamental questions about the
Web's link model as we prepare for a fully interactive Web.
The Web has benefited from a common link model among its family of
hypermedia formats; indeed, HTML's simple URL HREF model is being
eagerly adopted by VRML, Hyper-TeX, and others. I believe that the
Web stands to benefit even more strongly from a common link model
when scripting is implemented. If we do a good job of enhancing
HTML linking without making it too complicated, other formats will
likely follow suit. Some of the issues that need to be addressed:
1. Links to Dynamic Documents.
What are the semantics of linking to dynamic documents, objects
whose copies modify themselves? What does a URL mean now? Note
that even today's clients can have multiple objects keyed to same
URL, due to server-side dynamism (POST), expiry, explicit reload,
etc. That is, URLs (as opposed to URNs) are already polymorphic,
but we will need to be _much_ more explicit about polymorphic
"bindings" in a dynamic world. How to disambiguate? Perhaps
something like:
<A BINDING="Copy-Selected-At-Activation" HREF="dynamic.html">
2. Making Documents Dynamic via Links to Scripts.
The model of dynamic documents I advocate is that of static
document formats being controlled by scripts thru a generic object
model. But how can linking be used to accomplish the wedding of a
script to an intial document? Some concerns not addressed by
current HTML links:
* links must be able to support arbitrarily long client-side
URL modifiers (# stuff) for script initialization parameters
* the same script instance must be able to control multiple
"active areas" -- should this be done implicitly through the
document object model (script must create its own anchors), or
by supporting links with multiple anchor areas in general?
(Note that Java's current <APP> tag is also deficient on the second
point, as its developers recognize.)
3. Separating Presentation and Activation of Links.
How (and how much) should we separate the specification of the
following link attributes?
* presentation of the link before activation
* conditions for activation
* presentation of the target object after activation
I believe it _is_ worthwhile to factor out the activation
conditions into a separate EVENT attribute. For example, why should
REL="Embed" always mean to embed _immediately_? Shouldn't it also
be possible to express that the target is to be embedding after the
link is activated?
On the other hand, the prevailing view of REL as a binary relation
between target object and source object -- simultaneously expressing
presentation semantics both before and after activation -- hints
against the separation of these two. Sometimes, it is true, the REL
can be factored as a product (independent attributes specifying
presentation before and after activation); but other times not. So
rather than make a separation, we should give ourselves relational
operators which can express this factoring when it does occur
(next).
4. Relational Operators for Link Relationships.
If we adopt the model of REL as a general binary relation (rather
than just a product of presentation before/after), we should provide
ourselves the expressive power of relational operators. They are
not a useless abstractions, viz.:
* Inverse: absorbing REV into REL
* Intersection: what Dan described as "multiple REL values"
* Product: when presentations before/after are independent
* Join: indirect relationships (e.g., glossary's author)
5. Link Composition Operators.
HTML has a number of constructs (such as <FIG>, ISMAP,
script-enhanced <FORM>) which involve multiple URLs. Besides
causing competition for URL-related attributes in certain tags, this
is a sign of structural weakness. Why don't we have a general
mechanism for creating compound links, with each component link
playing its distinct role according to REL?
The basic operations you want are <A-AND> and <A-OR>; the first
tries to present and allow activation of all applicable component
links; the second allows activation of at most one component link.
Defining the composition semantics will be a significant task, of
course.
(I will post some more specific proposals soon. For now, let's
start with the questions...)
--------------------------------------------------------------------
Paul Burchard <burchard@math.utah.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------