Radical cure for BOS confusion

I have read the recent exchange regarding the BOS concept with great
interest because it seemed to me to be attempting to address the
central question I raised earlier about how an application finds
ilinks.  It may seem strange that I would now essay a contribution to
a subject on which I am notoriously clueless, but in this case I can
start with a statement that, as a representative of our target
audience, I can make with complete authority:

   The kinds of schemes you guys are describing are way too
   complicated for xml-link 1.0.

Going beyond that negative assertion to provide a simpler solution
that will still satisfy the requirements of applications like Martin's
(or Len's, or mine, for that matter) is rather more difficult, but one
possible direction does occur to me.  There is probably something
wrong with it, but it would be very useful (to me at least) to find
out why.  So I would be obliged if the HyTime experts would indulge me
far enough to show me what's wrong with this idea.

Let's begin by ignoring the elegant realization that alinks (to use
Eliot's proposed terminology) are a subclass of hlinks.  Most people
don't know that, and it would take a fair amount of explaining to get
them to see it.  Instead, we'll think about links that live in
documents and links that live outside of documents as two entirely
different animals.  We could even call the first kind "links" and the
second kind "webs" or some such, though I am not suggesting that.
(And let's leave aggregates out of the discussion entirely at this
point.  We can pick them up later if this idea goes anywhere.)

We implement alinks just the way that Eliot is proposing, which (if I
understand him correctly) means to the naive user that an element
tagged <alink...> will by default behave as if we had actually
reserved the name "alink" in XML, though of course we can override
this in a supplied DTD (if this isn't what Eliot is proposing, then I
think that he should), and that we can make other elements into alinks
by declaring them to be so in a DTD or by using a reserved attribute
that says that they are alinks even in the absence of a DTD (again, if
this is not what's being proposed, then I would like to propose it).
So to the naive user, an XML alink is an improved version of an HTML
<A HREF>.  So far, so cool.

For hlinks (nee ilinks) -- here comes the radical part -- we could
take Dave Durand's "companion document" idea to a logical extreme.  We
could define a special document type (i.e., provide a standard DTD)
for something called, say, "linkset" that is nothing but a collection
of hlinks (plus whatever other linking/addressing stuff we find useful
to put in there).  In doing so, we would entirely eliminate the idea
that ordinary documents could contain hlinks; they could only contain
alinks.  Then linksets (collections of hlinks) would exist for just
one purpose: the creation and management of links that stand outside
of individual documents.  This is, I believe, something like what
Steve Newcomb has been calling a "subhub", but radically simplified by
specifying a fixed tagset, eliminating all ordinary document content
from linksets, and forbidding the use of independent links in ordinary
documents.

To associate one or more linksets with a document, the author would
simply include a pointer (URL/URN or PUBLIC identifier, assuming as I
do that we will eventually add PUBLIC back into XML) to each linkset
at the head of the document.  I'm not assuming any particular syntax
for this; the HyTime folks can probably think of a way that would make
such "linkset includes" legal in the HyTime world.  Whatever the
syntax, the author would think of this as something akin to putting
#include statements at the top of a C program: these are things that
need to be in the environment for this document.

The point of this scheme is that it would make the author responsible
for specifying the applicable set(s) of independent links directly in
the document.  An intelligent browser should allow knowledgeable users
to choose between author-specified linksets and to associate other
linksets as well, including perhaps linksets made available
commercially.  And certainly this mechanism could be greatly expanded
sometime in the future by allowing linksets to point to other
linksets.  But just allowing the author to specify nonrecursive
linksets would, I believe, solve the kind of problem that Martin and
Len and I and lot of other content publishers need to deal with now.

Example: Suppose that I want to publish a set of Solaris
documentation.  All the things that I think of as cross-references can
be done with alinks using PUBLIC identifiers that rely on server-based
socats or that fall back on NAPTR for URL resolution, as discussed
last month.  (I note parenthetically that a lot of the problems that
we have been trying to solve in the BOS discussion are problems that
ought to be addressed through a mechanism of persistent
location-independent identifiers rather than through link management
per se.)

In addition to all the cross-referencing, however, I wish to provide a
set of annotations for users, another set of annotations for system
administrators, a third set of annotations for software developers,
and a set of links between every occurence of a significant word in
the documentation and one or more places in other documents where that
word is defined.  So I form four linksets using the standard linkset
DTD, put them on docs.sun.com, and provide URLs to those linksets
(syntax to be defined) at the top of each document.  Given a way to
select the appropriate set of annotations based on user preferences,
this scheme works for me.

Intuition tells me that this must be too simple, but I would very much
like to know why.  What's wrong with this picture?

Jon

Received on Monday, 6 January 1997 15:51:07 UTC