Re: Radical cure for BOS confusion

Jon writes:
[ ... ]
| | 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.

It's one more special case to explain to users:  "You can name your
elements anything you like, but watch out for 'alink'."  There's
already an XML name space for PIs in the XML 1.0 spec.

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

I have in mind how to implement publisher preferences in those
cases where I don't want the user to have a choice (the inverse
of the approach you mentioned in the section elided below).

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

It's a considerable maintenance headache if I have a thousand
XML documents pointing to one link set, and it limits the reusability
of those documents.  

Now it would be useful to have a collection of information that points 
to everything in the multimedia work including link sets, call it an 
"inventory", and I could see the point of constructing my multimedia works 
such that I managed effectivity, etc., through inventories.  But I
still wouldn't want the contents of the multimedia works to have
to point to the inventories, I want the inventories to point to
the contents.  Your proposal, I think, binds a sort of inventory
to the content (although what is difficult about this topic is
that you can always bump the binding up a level by constructing
a higher-level document that associates the link sets with the 
content by subsuming the content).

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

It was:

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

which I took to require a document to point out to its link sets.  I may
not even want to reveal the existence of link sets the user is not
supposed to use, so I don't want any pointers to them in the documents.

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

Yes, I agree with that, and it's an argument for inventories.
 
| 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").

But it's not simpler for the author to have to maintain within
the XML document pointers to the link sets.


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 Tuesday, 7 January 1997 13:57:46 UTC