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

[David Durand:]

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

I was hoping you would say that. :-) We seem to be in agreement here.

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

So the form of organization that is easiest for me to manage is not
necessarily the form of organization that is easiest for you to
manage.  This seems to go to the heart of the matter.

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

Given the point just made, I don't see how I can disagree with you.

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

In other words, if I want to organize my ilinks into databases, I'm
free to do so, but you've got good reasons to organize them in other
ways.  Fair enough.

| >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 one of several people who have told me that implementing
"ilinks anywhere" is no more difficult than putting them in organized
collections.  This is not what I would have expected, but if that's
the case, then I have to concede a key reason for making that
simplification.

Jon

Received on Thursday, 9 January 1997 17:46:50 UTC