Re: Radical cure for BOS confusion

[Terry Allen:]

| | 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 see the default interpretation of alink as name space
pollution, because any user who cares about such things would know
enough to override the default interpretation.

[...]
| | 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?

I think that this falls into the how-to-express-user-preferences
basket.  It's a problem, but not an XML problem.  At SunSoft we are
already spending significant time figuring out how to enable users to
categorize themselves in order to identify their area of interest and
figuring out how to remember that categorization; we will probably end
up using Netscape cookies, but that's an implementation decision.  I
would certainly hope that when linksets are mutually exclusive
alternatives, browsers would indicate to users which were available
and would allow them to choose which one they wanted, just as I'm
hoping that they will do this with alternative stylesheets, but I
don't know whether we're ready to require this.  However, the question
does point up the need to identify linksets as mutually exclusive or
not (e.g., presented to the user via radio buttons or lists that allow
multiple choices).

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

True, but I don't see this as a big problem.  An ordinary user viewing
an ordinary document would be operating in a link environment
specified by the document author.  Going beyond that would require the
user to know that some other linkset not specified in the document had
some possible connection with the document.  I can see this happening
in the case where someone is selling a set of annotations to a
well-known reference work and the user learns of its existence through
advertising, but I find it hard to imagine this happening very often
in the general case.

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

I'm not seeing anything in my (very loose) proposal that would prevent
this.

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

I sense that a lot of complexity arises from the fact that the ilinks
that have something to do with a document can be located at arbitrary
places inside the document, at arbitrary places inside some other
document(s), or some combination of the two.  If ilinks are allowed
only in special ilink collections, and if all the ilinks that the
author wishes to associate with the document are specified at a
particular place in the document, then I believe that life gets much
simpler for the implementor.  (Implementors please confirm or deny.)
I *know* that life gets much simpler for the author and for the person
trying to teach that author, because now link functionality falls
neatly into two stages: the beginner stage that learns how to put
alinks in documents and the advanced stage that learns how to
construct and maintain linksets independent of "the real document
content" (the part below the "linkset headers").

| [*] 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?

I don't see why it should.  The trick is knowing that those alien link
sets exist (see above).  As the document publisher, what I care about
is that the user gets the linksets I want them to have.  If some
independent developer of linksets (annotations, guided tours, etc.)
wants to sell my reader some value adds, getting them to the user is
their problem.  I see this as a (not unfamiliar) marketing issue.

| Or do alien link sets require their own "ordinary documents," free of
| ilinks, solely to point to themselves?

Technically require, no; I don't think so.  "Require" in the sense
that a vendor of third-party add-ons may need to put up a storefront
document to advertise their linksets, sure.

| What gets parsed when, and in what order, in the two cases of
| publisher-supplied and alien link sets?

I don't know.  I'm not sure that it matters.

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

No.

Jon

Received on Tuesday, 7 January 1997 02:06:58 UTC