BOS confusion (analysis; suggestion to resolve Newcomb/Bryan conflict)

   I've been reading Steve and Martin's notes, and I may have some idea of
the disconnect going on:

   A HyTime BOS is determined by a "hub document" and references
recursively followed out from that document, to a fixed depth.

   Martin (and I) are assuming that whenever a document is displayed, it
should be regarded as the "hub document". In that case the BOS is the
entire web (if no limit is in effect) or, at least, a pretty indisciminate
lot of documents, depending on how what kinds of links we have. We have to
actually fetch all of these documents, because otherwise we might miss
significant ilinks. But, without fetching them and parsing them, we can't
tell which of the outgoing references are really needed (because they
contain ilinks) and which are just referred to.

   Now, at least in the pre-TC world, HyTime's hub document is an
application-determined role and not an explicitly marked construct (though
the TC seems to have introduced a way to suggest hubs?). So a browser
_could_ work this way. And given the way the web currently works, this is
not an _un_-resonable way for things to work, though it is not the only way
they could worl.

   Steve is assuming that I can tell that only _some_ documents are "real"
hub documents, so that I can tell, when I follow a link, if I have left the
region governed by one hub, and entered the region governed by another hub.
At this point my application could merge the document sets defined by the
hubs, save them in a history, or anything else it wants to.

   My contention is that the notion of (even restricted) recursive document
requirement could be harmful. I think we all agree that for ilinks to be
useful, we need a way to pull in documents known to contain ilinks. And we
all agree that there should be a way for a user to explicitly add a set of
ilinks to their working document set. I have never been persuaded that the
notion of a single starting point document is essential, though it's
certainly useful in some cases. And I think that requring automatic
following of all links (even to one level) is impractical.

   So I suggest:

   1. We have identified a clear requirement for XML documents to be able
to idnetify other documents that need to be processed along with them
(mostly for ilink resolution).

   2. The term BOS is not that useful in describing browser behavior, as it
is unfamiliar outside of HyTime, and the HyTime notion can be applied to
the web in at least two distinct ways. I suggest that we use a new term
"working document set" to mean a set of documents that need to be processed
together, and within which ilinks in all the documents are supposed to be
accessible. Applications may mess with the working document set, under
arbitrary user control; but an author can augment the browser's working set
for a particalar document by declaring "companion documents", which will be
added to the working document set when that particular document is
processed.

   3. The notion of explicit "hub documents" is foreign to the web, and
easy to synthesize from the "companion document" mechanism, so we might as
well leave it be.

   Note: To get the effect of a well-known hub document, we declare that
hub as the companion for all of its desired members -- and in the hub
itself, we declare all the desired members as _its_ companions. _Viola_
wherever we start, we automatically pull in whatever documents the "hub"
indicates as essential.

  -- David

I am not a number. I am an undefined character.
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Tuesday, 31 December 1996 13:06:40 UTC