Re: Radical cure for BOS confusion

[David Durand:]

| >One of the advantages that I thought we might get out of confining
| >ilinks to special documents of a single standardized type is the
| >chance to specify standard information that could be included in a
| >collection of ilinks -- for example, comments on why the links were
| >created, or owner, or revision history, or whatever.
| 
| I think anything we can specify will be too limiting for someone.

Yes -- *anything* we can specify will be too limiting for someone.

| >In other words, part of the tradeoff in going for what looks like a
| >much easier to implement ilink mechanism (the fixed doctype alone
| >should make tool construction simpler) is that we would have to do
| >some pretty careful design work on just what kind of things should be
| >included in a link set.  One of the things that emboldens me to make
| >this suggestion in the first place is the estimation that we have the
| >collective experience to do that.
| 
|     No, it's like the level of experience required to make the "one true
| DTD." To the naive, we may look as if we have the experience to do that
| too, but we know it's impossible.

I admit that my estimation may be overly optimistic.  But for all
their faults, standardized DTDs have proven useful.  And this wouldn't
be the "one true DTD", it would just be a minimal standard format for
sets of ilinks to be used in XML.

|     Personally I don't see that ilinks are that hard to process, nor that
| following a set of explicit companion links would be too arduous. In fact,
| I don't see that there's much difference between the fixed doctype proposal
| and the variable one -- we will still need some general way to recognize
| links in documents, so the only thing we really accomplish with the fixed
| proposal is to forcea segregation of ilinks -- we will still need to
| recognize other link types, and we will still need to process ilinks, and
| we will still need to fetch (at least 1) companion document. Once we go so
| far as that, why arbitrarily tie our own hands?
| 
|     Let's face it ilinks are powerful. For the same reason, ilinks are hard
| to understand. This fundamental fact won't change if we add a few
| restrictions, I think.

Well, your experience may vary, but I was finding it a *lot* easier to
understand ilinks when they were corraled into sets with a standard
format and bound to specific documents with explicit includes.  I
could teach someone to do that.  There's no way I could teach someone
to follow the BOS discussion.

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.

Jon

Received on Wednesday, 8 January 1997 00:34:50 UTC