Re: Radical cure for BOS confusion

Jon wrote, thoughtfully:

| 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.

Except for the name space pollution.  I'll suggest that as XML
is already into application-specific PIs, it could use a PI here, too.
I don't think that would be too hard on users (after seeing folks
at FSC using the Netobjects product I'd say that "naive users" these
days don't even know what A and HREF are; for them the tool will
supply the PI anyway).

| 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.

Parameterization of function is good.

| 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.  

How does the user employ those link sets (oh, let's call them golf 
courses)?  [see below at *]

| 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.)

Agreed.

| 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.

What is that way?  especially if the user should see only the set
of annotations peculiar to his station?

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

If I understand how this would work, the user may obtain links to 
inappropriate link sets that you may not want him to be able to use.  
In the absence of location-independent identifiers (and certainly if 
you don't use queries), these links contain early-bound information 
that should be late-bound (for your convenience as publisher).  

Would you not prefer to point the user at the document through
the link sets?  You can then exercise effectivity control at the
server (through negotiation with the user's agent), serve the
appropriate link set, and then the wanted document (or both 
together), or serve the link set as part of the top-level
node of the document or its TOC.  

And what makes this better than allowing ilinks in ordinary
documents?  You wrote:

| 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. 

Aside from late or early binding, why is that better than allowing the 
author to include the ilinks in the first place?  Isn't the document 
you're serving really the document plus its annotations including the 
ilinks, so that the ilinks are really in one of the entities composing
the (annotated) document anyway, just as if they'd been included
in the top-level node or TOC?  

[*] Now what about the user who wishes to use alien annotations?
His user agent has one method for obtaining the publisher's link
sets; must it use another for obtaining (and parsing and using)
alien link sets?  Or do alien link sets require their own
"ordinary documents," free of ilinks, solely to point to themselves?
What gets parsed when, and in what order, in the two cases of
publisher-supplied and alien link sets?

And, idly, must the ilinks in the pointed-to link set be anchored in the
document from which the pointing was done?  


Regards,
    Terry Allen    Fujitsu Software Corp.    tallen@fsc.fujitsu.com
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Received on Monday, 6 January 1997 20:15:01 UTC