Re: clink/ilink direction (Was: anchor awareness)

At 8:52 PM 12/25/96, Jon Bosak wrote:
>What I'm hearing -- please correct me if I'm wrong -- is that we can
>implement contextual links for the open case (the Internet as a
>whole), thus modestly but usefully expanding the range of capabilities
>of the HTML <A HREF>, and then we have the further option of defining
>independent links that will work only in closed environments, AKA
>intranets.  (Eliot goes on to suggest a method for wrapping an
>"invisible linking element architectural form" around anchors to
>"enable the conversion of independent links into contextual ones", but
>pending a fuller description, this sounds over-engineered to me.)

I think that this is too strongly negative, as to the utility of
independent links. I see them as one of the really critical points of
expansion for web functionality, since ilinks can be applied by anyone, to
anything, without difficulty. In particular, if users wish to customize the
web by adding useful navigation that meets their needs, they need merely
instruct their browser to maintain an "ilink file" that will hold the links
they choose to create, and enable them to be displayed in context. Such
files could also be shared via the web, of course.

   It is true that this is more useful on intranets, because the
presumption of stability and organization _may_ be more well-founded, but
as infrastructure for annotaion, the creation of guided tours, and other
external customization, it is extremely useful.

>A third option that doesn't seem to have been discussed much is that
>we can define ilinks whose scope is the same as the SGML ID space, or
>to put it loosely, ilinks that are used in the same document in which
>they are defined.  I'm not sure how useful this would be.

The HyTime folks, no doubt, all assume that this will be subsumed under any
reasonbable architecture, and I agree. There is no reason to disallow any
kind of intra-document linking that is possible for inter-document linking.
The TEI, of course, already has this in the form of Correspondence maps.
Such sets of links are quite meaningful in representing textual and
linguistic commentaries, and analyses.

>If we set aside the last possibility and Eliot's invisible wrapper
>scheme, then what we seem to be left with is a clear reason to define
>a contextual link mechanism for general Internet use in our first link
>specification document and a possible case to be made for defining an
>independent link mechanism for intranets that we may want to put in a
>first link specification document or may want to defer for a later
>version.

I don't yet see any reason that ilinks should not be implemented. The issue
of how software should be instructed to find ilinks to interpret relative
to documents being processed is not really our problem (except for ilinks
within one of the documents that they link).

I agree that anchor awareness is not a concept to worry about. To some
arguable extent, I think insistence on anchor awareness has helped to
damage the hypertext research community. In any case, for "SGML on the
Web," awareness is clearly not our problem. There is work being done on
collaboration and awareness protocols, but markup has little to do with
that. We should certainly be prepared to add facilities to XML to
accomodate it should it ever be possible, but the fundamental problems of
implementing such things over global networks are unsolved -- so we should
not try to design markup that is only usable once they are solved.

   -- David

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 Thursday, 26 December 1996 17:00:08 UTC