Re: Radical cure for BOS confusion

[Terry Allen:]

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

I'm going to leave this quarrel to people who care more deeply about
it than I do.  I just don't get all that terribly excited about name
space purity.  Outside of a symbolic logic class I took once in which
the primitive marks were vertical strokes and spaces, I've never seen
a formal language that didn't have some reserved words, and the
attempt to completely eliminate them seems pointless.  The average
user loves sensible conventions and reserved words as long as the set
is kept to a reasonable size and doesn't take anything away from the
user's normal vocabulary.

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

The approach that I was suggesting is skewed heavily in favor of
publisher preferences.  I don't see how you can go very much farther
in that direction and still have a usable system.

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

If you need to reuse a document that includes a pointer to a link set
in a way that requires it to use some other link set instead, then you
do indeed have to go in and change that pointer.  Requiring all such
pointers to be of a particular form and occur at a particular place in
the document minimizes the work needed to do this but doesn't
eliminate it.  The point I'm trying to make is that I strongly suspect
that a scheme general enough to provide the level of indirection you
want here is a scheme that is too complicated for our first attempt at
link specification.  This is just a hunch and certainly open to
disproof, but I have yet to see in this discussion a proposal for a
system that provides the flexibility you want and is still simple
enough to get widely adopted.

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

As I noted in my response to Martin, the content and structure of the
"link set" are still blissfully undefined.  Maybe your concept of an
inventory is closer to what we would really want.  I return to my
analogy with #include statements: the author is specifying the
environment within which a given text is to be interpreted.  What
belongs in that environment is an open question.  I'm just saying that
I feel a lot more secure with a system in which the environment for a
document is explicitly specified in the document than one in which it
is magically constructed by an implicit dynamic recursion through the
hyperverse.

| 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

Right.  And I'm not arguing with your desire to work it the other way,
I'm just questioning whether that's something that's practical to
implement in a first attempt.

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

You've lost me here.

| | | 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 don't see any reasonably simple way to provide this.  If anyone else
has seen a reasonably simple way to provide this, they haven't told us
about it yet.  I don't consider the BOS schemes described so far to be
reasonably simple.

Here we have a river to cross: links as first-class objects.  I think
I see a way to get across the river using stone arches.  I believe the
proponents of the cantilever approach and I believe the proponents of
the suspended span approach when they tell me that there are more
elegant ways to solve the problem, but I also know that they will have
to watch a few of their creations collapse before they get it right.
I'd like to start with something simple and sturdy.

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

Could be.

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

Maybe not in the most general case, but I believe that it *is* simple
in the typical industrial case that I think we should focus on first.
Allow me to use the Solaris example again.  If I have 40 writers
working away on the Solaris documentation set, I can designate one of
them as the constructor and maintainer of the four link sets that I
described previously.  The link set maintainer creates four files on
docs.sun.com containing the link sets for user annotations,
administrator annotations, developer annotations, and glossaries,
creates a four-line header (using the HyTime-friendly syntax yet to be
defined) pointing to those files, and says to the other 39, "Hey, put
this at the top of your books."  End of story.  No, it doesn't do
everything you might want a hypertext system to do, but I think that
it gets us across the river.

Jon

Received on Tuesday, 7 January 1997 20:42:05 UTC