Re: A serious detail point

Henry writes:
| Here's the problem: I want to have tens of thousands of links in a
| single document, all pointing to (spans in) ONE target document.
| Without a way to specify a default containing resource OTHER THAN the
| document contain the linking element, I will have to reproduce the URL
| for my target document in the specification of EVERY ONE of those
| links.
| 
| Or have I missed something?

No, but you have stated too simple a version of the problem.  Assume
instead that you have 5,000 links to spans in one target document,
intermixed in logical order of presentation with 5,000 links to
300 other documents.

(proposal omitted)

| [I wasn't going to say anything about implementation efficiency, but I
| will because it stands as a counter-argument to the best work-around
| I've come up with, namely
| 
| <!ENTITY c "http://www.library-of-congress.gov/index/">
| ...
| <myptr href="&c;#ID(p324)..&c;#ID(p334)"/>
| 
| This will work, of course, and it cuts the overhead down to 6
| characters per locator, but a) it's obnoxious and b) it's likely to be
| seriously slow if implemented without caching, which is I claim much
| more likely to be the case for resources in general than it would be
| for a (reasonable to expect to be small) set of containing resources.]

I haven't checked to see that this actually will work, and don't understand
all of the syntax, but just on the issue of entities, it sounds like by far 
the easiest solution to the problem as I restated it.  6 chars per locator 
is trivial, and I don't see what's obnoxious.

Above all, though, let's stop supporting positions by appeal to what
will be most common.  This cannot be known before XML is deployed,
and it should not be a consideration in writing the spec, unless a
full scenarios document is developed.  


Regards,
  Terry Allen    Electronic Publishing Consultant    tallen[at]sonic.net
                   http://www.sonic.net/~tallen/
    Davenport and DocBook:  http://www.ora.com/davenport/index.html
          T.A. at Passage Systems:  terry.allen[at]passage.com 

Received on Thursday, 17 April 1997 14:54:23 UTC