Re: Radical cure for BOS confusion

[David Durand:]

| As I understood the proposal, ilinks would only be legal in separate
| documents according to this DTD. That seems like the "one true ilink
| DTD" to me.

It wasn't a proposal so much as a challenge, and I'm seeing that the
link set DTD bit is an inessential distraction from the point I was
trying to make (in addition to smelling hubristic).  Let's forget
about that part.

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

I assume that by "explicit user control" you mean "explicit
author/publisher control".  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.  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?

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?"

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.

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.

Jon

Received on Thursday, 9 January 1997 11:42:44 UTC