Re: Radical cure for BOS confusion (2 ccs' to Jon's address deleted)

At 8:40 AM 1/9/97, Jon Bosak wrote:
>[David Durand:]
>| >I put the "radical cure" forward in order to be shot down, but to
>| >shoot it down you're going to have to exhibit a solution that's that
>| >easy to understand and still gets the basic job done.  Show me.
>|
>| I think I already did. I'll try again, as succinctly as my bloated prose
>| style allows.
>|
>| We need a new architectural form "required-for-processing":
>|
>| <!element required-for-processing EMPTY>
>| <!attlist required-for-processing
>|    -XML-ARCH #FIXED "required-for-processing"
>|    -XML-required-doc CDATA #REQUIRED>
>| Each "required-for-processing" document should be loaded by a processor
>| when its containing document is processed. It is a recoverable error if
>| this cannot be done (but the resulting document may then not work right).
>|
>| Since this is true for any document, in including a required document, the
>| recursion falls out naturally, but is under explicit user control. The
>| documents required by a given document form its "XML BOS".
>|
>| "Ilinks" are links that do not reside at an endpoint of the data they they
>| links, and may not even reside in the same document. Ilinks in an XML BOS
>| should be resolvable relative to documents in that BOS.
>|
>| Finis.
>|
>| I just don't see that this is that complicated. Is this is a clearer way of
>| explaining it?
>
>Yes, thank you.  I think that I understand most of what you are saying
>now, but the XML BOS itself still appears to be arbitrarily complex.
Not really, but I see from a little later on that there's still a
misunderstanding.

>I assume that by "explicit user control" you mean "explicit
>author/publisher control".

Yes.

>If I understand the proposal correctly,
>ilinks can be scattered throughout a document like raisins in a
>pudding, and any one of them can potentially pull into the BOS any
>number of other ilinks via recursion.

No. Only an occurence of a required-for-processing AF instance pulls in
other documents. That is the real difference between the HyTime BOS, which
follows all links to some fixed level of recursion, and the XML BOS that I
am proposing, which pulls in only documents explicitly requested by the
author.

They are like raisins in a pudding though.

> So as the author/publisher of a
>document, I have "explicit control" over the ilinks with which I
>populate a document, but no control at all over the resulting BOS.  I
>may, for example, include an ilink to your well-behaved document, and
>tomorrow you may decide to update your document to include a link to a
>100 MB collection of topic maps.  Result: today my user brings up my
>document in five seconds, tomorrow the same document takes several
>hours to load and then runs out of memory and dumps core.  Do I
>understand correctly that this is a necessary implication of your
>proposal?

No, the above misunderstanding makes this secnario possible, but on my
scenario, the author has control as long as she does not make someone
else's document "required-for-processing".

>Assuming that I've got that part wrong and that you are not suggesting
>a scheme that can result in a variable BOS of arbitrary size beyond my
>control, I am still uncomfortable with a form of organization that
>allows ilinks to be distributed at random even in a single document,
>let alone in multiple documents.  The key problem with links is link
>management, and I just can't see how management is easy if ilinks are
>allowed to be located arbitrarily.  A Knowledgeable Person has
>suggested to me offline that what I'm really after here is the concept
>of a link database, and that's exactly right.  "It's eleven o'clock;
>do you know where your ilinks are?"

This is a matter of strategy. If I've got a series of glossed text examples
with complicated alignments between them, I can best control my links by
having a little bundle of ilinks associated with each example. If I am
using ilinks to annotate an entire file, I might prefer the single "ilink
bunch" proposal you started with.

We can only enable good organization, not require it, unless we think we
can formally define all the reasonable uses ahead of time.

>My problem (and I think Martin's problem and Len's problem) can be
>solved with a mechanism that allows the construction of ilink
>databases and a way to include specific ilink databases in the XML
>BOSs of specific documents.  I like this approach partly because it
>gives me a believably finite set of links to manage and partly because
>I can divide up the work of maintaining such a structure and assign
>that work to specific people.

My proposal enables that as well, but does not preclude internal ilinks,
which have a suprising number of uses. (graphic callouts, for instance).

>Another correspondent has suggested that the kind of industrial
>problem I'm trying to solve is just a small part of the problem space.
>No doubt this is true, but I'm much happier with a solution to the
>more pedestrian application that can be extended later than I am with
>a general solution that seems inherently fragile or unmanageable.

I don't think that the general solution is fragile, when understood
properly. And I think I gave two nice examples of places where separate
ilink files might be inconvenient.

You are right that any strategy that follows links will cause trouble in
one of two ways:
  1. each link will have to be labelled with whether or not its destination
is XML BOS-augmenting. I think this fails the complexity test.
  or
  2. We pull in too much stuff, including things written by others that
might uncontrollably bloat the relevant XML BOS.

  -- 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 Thursday, 9 January 1997 12:39:44 UTC