Suggestion: A link model

A few suggestions for things that I think we need. I am describing these
somewhat like architectural forms, and somewhat like algebraic data types.
I am using prose, to avoid the prejudicing effect of inventing a new
notation, or abusing an old one.

I have built on some HyTime concepts, because they best reflect the
relationship of markup and hypertext. However, I'm still unsure as to
whether HyTime architectural forms are appropriate. However, the set of
declarations here seems sufficient for a lot of stuff. A separate list like
this should also be made for link behaviors, but I strongly urge that we
separate the behavior from the markup. I think folding it into the DSSSL
stylesheet would be best, but a separate linking-behavior stylesheet would
also be OK.

We require four primary kinds of objects (these are things that occur in
documents and would get single tags):

clink, ilink, location, anchor.

LINK (abstract superclass of ilink and clink)
   A link has 1-n linkends.  Linkends record a relationship to other
locations. The linkend locations can be specified by the ID of an element
in the containing document, or a location indicated by a TEI extended
pointer. If the location is a "location" object, the designated destination
is the object pointed to by that location (1 level of location ladder only,
for simplicity).

   A link has an optional "link explainer". This is a string, suitable for
user-consumption, describing the intent of this particular link.

   A link has (perhaps optional?) link-meta information, specifying further
user and application information about the link's data type.

CLINK:
   Linkend override: One linkend is the point (if empty) or scope (if
content containg) where the clink markup occurs.

ILINK
   An ilink has no properties other than those of the "abstract link".

LOCATION
    A location may point via an ID of an element within its containing
document, a TEI extended pointer, or a HyTime query (we need a list of
necessary location methods the TEI does not accomodate, and a way for
extending the kinds of location by the author, if desired. Some subset of
HyTime location address seems right here, but how small (or null) the
subset should be is not yet clear to me.) This is a place for discussion,
and extensibility.

ANCHOR
   An anchor is an element that exists _solely_ to facilitate the
addressing of a document portion by clinks or ilinks. Other than being
addressable, it should have no effect on processing.

Dependent objects:

LINK-META
    We need to associate some meta-information with the ends of links. This
allows multi-ended links to identify the function of link ends with
something more meaningful than sequential order.


   Link-meta contains (for each link end)
   A link-type. These should be specifiable by default (say for links with
fixed numbers of endpoints), on the instance (for links with variable
number of endpoints), and maybe by some combination (Steve DeRose and I
proposed methods to extend HyTime to accomodate this -- we don't know
what's happened in the TC process).

   A linkend explainer. This is a user-readable string (like an alt string)
that should be displayed to explain the meaning of the data located by this
link end. It should be displayed, if the interaction style enables such
display.

SUMMARY

   These are the things I want in XML linking. I could live without
explicit anchors and locations, but I think many will want them. Also,
locations are a convenient place to extend link elements without
complicating the syntax for simple links. Anchors are really formally
unnecessary, as they can simply be any elements that do not affect
formatting. However, users and authors might be served if it is possible to
say that an element _should not_ affect presentation.


  -- David (who sprinkled a little OO magic dust after all)

I am not a number. I am an undefined character.
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Saturday, 28 December 1996 18:29:03 UTC