SAX and delayed entity loading

Simon St.Laurent simonstl at
Thu Dec 3 19:51:06 GMT 1998

At 01:20 PM 12/3/98 -0600, W. Eliot Kimber wrote:
>>MIME types are quite flexible, however, especially if you don't mind
>>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.

And if I get one of your notation-encrusted documents, and don't have an
application that can cope with it, where do I find the information?  I
can't.  The problem isn't that MIME mechanisms are worse than notation
mechanisms - it's that there isn't a central and flexible registry for
either system that is publicly available and works.  

I see notations as worsening this problem because they exist inside
documents and become management nightmares if the registry of whatever kind
changes.  Allowing information to identify itself when requested avoids
this complication - the registry may not be any better, but at least I
don't have to modify my documents to match up to the registry.

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

Will the software that reads your documents still be running in a hundred
years, or will people be cracking open your archives with applications that
can't make head or tail of your 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.

Yes, but I don't recommend building country lanes as four-lane highways
with double guardrails either, especially in a world where guardrail
standards change frequently.

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

I don't.  And I don't recommend them to others, either.  Describe, yes, but
not recommend. 

Simon St.Laurent
XML: A Primer / Cookies
Sharing Bandwidth (December)
Building XML Applications (January)

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

More information about the Xml-dev mailing list