SAX and delayed entity loading

Simon St.Laurent simonstl at
Thu Dec 3 18:41:52 GMT 1998

At 10:12 AM 12/3/98 -0600, W. Eliot Kimber wrote:
>At 09:30 PM 12/2/98 -0500, david at wrote:
>>I think that notations and unparsed entities in XML have proven
>>themselves to be non-starters.  They worked well in the SGML and have
>>done me good service, but MIME types and hrefs provide the same
>>functionality (if somewhat weaker validation) and they work with or
>>without a document type declaration.
>I can't agree with David's statement that MIME types and hrefs provide the
>same functionality as notations and external data entities.  They are
>similar, but weaker:

I definitely agree with David's statement, and would frankly make it
stronger.  Notations and unparsed entities make sense only if you want all
information regarding resources to be stored in the document, with no
reliance on outside assistance.  (For example, HTTP provides MIME type
headers on its transfers.)

If this isn't the case, notations and unparsed entities are a nuisance,
providing functionality that duplicates that provided by other tools in a
format all its own.

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

>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.  MIME
types are quite flexible, however, especially if you don't mind declaring
them as x-whatever.  The main point remains that MIME types work well for
Web-type situations where other facilities outside the document are capable
of describing entities as richly and as completely, with less upkeep, than
notations inside a document.

>For example,
>how do you apply a MIME type to an element or attribute? 

For the element, I could do it with a plain old CDATA attribute or with an
external document specifying what element should be processed how.  How
would I apply a MIME type to an attribute?  More important, why one earth
would I want to?  Seems like some pretty heavy overkill.

>Of course, the use or non-use of entities and notations is a data
>management choice that has to be made on a case-by-case basis. There are
>certainly classes of document for which the indirection of entities does
>not provide sufficient benefit to justify the cost. But that isn't the case
>for all XML documents.

Of course it's up to the user - but a lot of things would have been a lot
simpler if XML had just plain excised this redundant and complicated
'feature' in favor of a style that better reflects its intended use on the
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

>So saying that entities and notations are non-starters is, I think, a bit

Personally, I'd say it's a bit weak and declare them a menace or at least a
nuisance, but as I mentioned above there may be cases where this
information needs to be included in documents.  Other application-level
facilities would probably have been as capable, but it's there now...

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

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