SAX and delayed entity loading

[W. Eliot Kimber]

At 01:42 PM 12/3/98 -0500, Simon St.Laurent wrote:

>>1. href provides no indirection mechanism...
>>By concentrating the mapping of local names to storage objects
>>in the document prolog, processors (and authors) do not need to scan an
>>entire document to know what the doc-to-entity dependencies are.  For small
>>docs this doesn't really matter, but for very large docs, this can be a
>>significant savings.
>>...
>
>Inline hrefs can't do this directly, but similar functionality and
>management can be provided through XLink, using hub documents to provide
>links rather than keeping all links inline.

I don't see how this follows: XLink provides *no* indirection mechanism
other than extended links, which wouldn't really do what you need anyway, I
don't think (remember David's caution not to confuse storage organization
with linking--they are two fundamentally different things and confating
them will lead to pain).  If you were talking HyTime, we'd be in 100%
agreement (except that I'd still use entity declarations in the Hub
document, but I wouldn't use them anywhere else).

>>2. Notations provide a richer degree of data type specification that is
>>more flexible and more generally applicable than MIME types...
>
>Perhaps, if you're creating your own notations on a regular basis.  

Which I am.  That's the whole point. Remember, it's not just about things
like graphics formats, but about application-specific semantic things like
queries, like grove constructors for private data types, like arbitrary
application-specific data types.
                                                                       MIME
>types are quite flexible, however, especially if you don't mind declaring
>them as x-whatever.  

But I do mind: if I see "x-whatever/whatever", how do I know where to look,
as a programmer or document recipient, to understand what the rules for
that MIME type are?  If there's a place, tell me, because either I've
terribly misunderstood the MIME mechanism (quite possible) or I've
overlooked some non-obvious aspect of x-* MIME types.

>Web.  It may be worthwhile for users who do need to keep all that
>information in the document, and therefore worth keeping, but... what a
>headache...

It's not a headache if you have a document-centric system where you are not
dependent on software or the protocol of the day to define your data
dependencies.  I have clients with documents with expected life spans
measured in hundreds of years.  Will recommend that they rely on MIME
types? Not under any circumstances.  Not to say that MIME types are bad,
only that I don't expect them to be around in 100 years.  I do expect SGML
and XML, as *implementation and system independent standards* to be around
in 100 years.

>XML is SGML simplified enough to be useful to a wider audience, but there
>are many times I wish it had been simplified considerably further.  (That
>way, when we go to add all these new features, they aren't all redundant,
>among other things.)

Notations are not redundant with MIME types for the very important reason
that mapping of short name (notation name, MIME type name) to definition is
managed using SGML/XML-defined means for notations and by other means for
MIME types. (Which means, in part, that you get to choose your own local
names for notations, which you of course cannot for MIME types.)

Note also that if the external ID for a notation *is* a MIME type (or its
defining RFC), then notations can take advantage of the MIME
infrastructure, which is probably useful.  Notations are more general than
MIME types, so MIME cannot completely replace the use of notations.

It's also important to remember that XML is not designed to work *only* on
the Web, it is designed to work *well* on the Web.  It would be foolish at
best to design a language that only had those things absolutely needed by
today's Web technology.  It would be like designing roads that can only
accomodate model T's because that's all people have today.

If you don't find notations useful, don't use them in your documents.

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)