Re: unmarked linkend awareness by XML engines

> >Upon arrival at the read-only asset,
> >the BOS is still pretty much guaranteed to include the session-start
> >document; otherwise, the user couldn't have arrived at the read-only
> >asset.

> This only works if your read-only asset inherits the BOS of all the
> documents in the chain used to reach it, or the BOS of a start point
> document that covers the whole of a document set.

Yes, but it is literally impossible for such inheritance NOT to take
place without deliberate user intervention.  If a user is in a
document, then that document is by definition in the BOS.  If a user
traverses to another document, he can only get there by adding that
document to the BOS.  When he arrives at the traversed-to document,
removal of the traversed-from document from the BOS can only be done
deliberately and consciously.  There is no automatic removal of items
from the BOS.

But what HyTime says (or doesn't say) is irrelevant here.  The
important thing is that this concept works, it works solidly, it's as
foolproof as it can be, it answers Terry's heartfelt and very real
requirement, it imposes no unreasonable demands on applications, it's
relatively easy to implement, and it provides very significant power
that is now unavailable to Web users.

> What you are talking about in the first of these is the browser's
> History list. But how on earth do I know which entry in my History
> list is the one that contains the copyright notice and any necessary
> disclaimers?

Because the session-start (hub) document was in fact browsed by the
user, the links it contains are known to the application, and their
linkends in other documents, when the user stumbles across them for
whatever reason, are therefore also known to the application, full
stop.  There is no need to look anything up.  None of this imposes a
requirement for a history list.  The application is responsible for
knowing where the links are that it is providing the hotspots for,
and, since it knows where the links are, it also knows their other
linkends and can take you there, if possible, on demand.

> On the Web there is no guarantee that you will access a document via
> its session start document. In fact, for any reasonably large data
> set you can normally guarantee that you won't. So the question
> becomes "how do you identify the BOS" associated with this page if
> it resides with the session start document". What you need to do is
> to have a pointer to the BOS that says "This Web page should be used
> with this BOS". (Isn't this the catalog for the file set?)

When you use the BOS concept, the only thing that matters is the
user's decisions as to which documents (and therefore, which link
sets) are known to the application.  As I said before, upon arrival at
any document, the user has the option of adding that document's BOS to
the actual BOS in effect for this session, or of replacing the active
BOS with that document's BOS (which means that the application will
"forget" about the links that exist in documents that are not present
in the new BOS).  At any time, the user can create and/or use *any*
BOS.  If the user fails to use any suggested BOS, the user does so at
his own risk.  If this means that he may unknowingly violate some term
of his license agreement, that's tough for him.  Ignorance does not
excuse malfeasance, especially when pains have been taken to ensure
that access to the relevant knowledge is easily available.

> >If the user is running an application which is like any
> >typical Web browser, the session-start document is still in a local
> >cache, so the frailty of the Web network is not even an issue.  The
> >session-start document contains links which effectively place one or
> >more hot links at various points in the read-only asset back to the
> >session-start document.  When traversed, those hot links can take the
> >user to the copyright notice or the license agreement, or whatever.
> 
> How? The problem is which set of links should be used. If I annotate one of
> your documents the session start document will point to my copyright notice.

Oops.  I do not understand why your annotation of my document has
anything to do with this discussion, so I'm now going to try to bring
your scenario together with mine.

If Martin annotates Steven's valuable read-only document, then Martin
must put Martin's annotations in Martin's own document.  (I'm assuming
here that Martin's rights do not include the right to change Steven's
document.)  Privately, Martin loans his annotations to David.  If
David wants to read Steven's document as annotated by Martin, David
must include Martin's document in David's session's BOS, as well as
Steven's document, in order to see Martin's annotations in the context
of Steven's document.  If David does not include Martin's annotation
document in David's session's BOS, he can't see Martin's annotations
in the context of Steven's document, or in any other context, for that
matter.  The BOS *is* the user's context in some very fundamental
sense.

Steven and Len are both publishers.  Steven's valuable document was
not always Steven's; Steven bought all the right, title, and interest
in the valuable document from Len.  At the same time, in effect,
Steven bought all of Len's customers for that valuable document,
because Len's former customers still need access to the valuable
document and now they're going to pay Steven for usage rights similar
to those they had when Len owned it.  The document used to be in Len's
catalog, but now it's in Steven's.  (Len's catalog provides a
forwarding address to Steven's catalog, as a courtesy to Len's former
and current customers.)  Not wishing to endanger the value of the
document that Steven bought from Len, Steven doesn't edit it, but
instead Steven provides it with a separate session-start document.
Steven's and Len's catalogs do not give the address of the document
itself; they only give the address of the session-start document, so
customers pretty much have to start there.  (If they don't start
there, that's their problem, because ignorance of what's in the
advertised session-start document will not excuse them from abiding by
its terms.)  In order to gain access to the valuable document, they
*must* add at least some of Steven's session-start document's
suggested BOS to their BOS in order to get to the valuable document,
because the suggested BOS is the only place where the actual address
of the valuable document can be found, and you can't traverse to
something that's not in your BOS.  In any case, the links in the
session start document must be processed by the application because,
by definition, you can't be in a document without it itself being in
your BOS.  Therefore, any annotation links in the session-start
document that can take users from the valuable document back to
session-start document, where Steven's license arrangements with the
user are documented, are guaranteed to be in the user's BOS.

Imagine now that Martin publishes his annotations.  "Wow," Eliot says,
reading about this new publication.  "I never did understand what that
document of Len's was trying to say, and I generally understand
Martin's explanations.  I'm going to try reading it again along with
Martin's annotations."  So Eliot buys the right to use Martin's
annotations from Martin, and the right to use Steven's valuable
document from Steven (or maybe from Martin because by arrangement with
Steven, Martin resells those rights along with his annotations).
Eliot enters Steven's document by means of the session-start document
that Steven provided, and he adds Martin's annotations to his BOS
manually.  (Or, more likely, he starts with Martin's annotations
document, which is easier because it includes Steven's session-start
document in its suggested BOS.  Or, maybe Martin didn't hear that Len
had sold the document to Steven, so Martin's annotations document's
suggested BOS includes only Len's old address for the document; this
causes no problem, because what's at that address now is a placeholder
document whose suggested BOS includes Steven's session-start document,
and perhaps some XML/Web-specific way of saying "Any entity
declarations that give the address of this document should be changed
to reflect its new address:
http://www.steven.org/Old_Len_Document.xml".  Of course, this new
address is not actually the address of the valuable document; it's the
address of the session-start document that Steven wants all users to
have in their BOSs when viewing the valuable document.)  When Eliot
arrives at the valuable document, both Steven's copyright notice (and
other licensing information) and Martin's annotations are available as
hot links from within the valuable document.  The valuable document,
of course, need contain no evidence that any of this is going on.

One of the great beauties of doing things this way is that Martin's
annotation links can't go stale just because Steven bought the
annotated document from Len.  Steven didn't have to edit the document
in order to change the licensing information.  No matter how Martin's
links addressed the contents of the valuable document -- even (*gulp*)
by counting all the byte offsets to each linkend -- Martin's
annotation document only needs to change exactly one entity
declaration in order to keep working, and that's absolutely the only
change necessary.  (For purposes of this discussion, I'm ignoring the
possibility of any sort of public cataloging utility that might
obviate any necessity for Martin even to change the entity
declaration.)

If ilinks, anchor awareness, and the BOS concept are supported,
anybody can annotate anything, even when the thing being annotated is
read-only.  

(Aside to Terry: The owner of the thing being annotated certainly has
the right to forbid the publication of such annotations as a condition
of licensed use.  I don't think you can -- or would want to -- prevent
people from doing something which is just like writing in the margins
of books that they have purchased.  The publication of such marginalia
is another matter, of course.)


--Steve

             Steven R. Newcomb   President
         voice +1 716 271 0796   TechnoTeacher, Inc.
           fax +1 716 271 0129   (courier: 23-2 Clover Park,
      Internet: srn@techno.com    Rochester NY 14618)
           FTP: ftp.techno.com   P.O. Box 23795
    WWW: http://www.techno.com   Rochester, NY 14692-3795 USA

Received on Monday, 30 December 1996 14:12:28 UTC