SAX and delayed entity loading

W. Eliot Kimber eliot at
Thu Dec 3 21:18:55 GMT 1998

At 03:44 PM 12/3/98 -0500, John Cowan wrote:
>W. Eliot Kimber scripsit:
>> So in that sense, the MIME type is redundant for any data type that is
>> already self describing (e.g., XML, SGML, most graphic formats, VRML,
>> etc.).  Hmmm.
>Almost.  The MIME type gives you *some* information about the
>document even if you do not understand its type fully.  For
>example, something labeled "text/xml" is known to be text,
>even if your application has never heard of XML.  As such, it
>has certain properties that can be relied on.

I see the point, but I would argue the following:

1. The same effect can be provided by supertype data content notations
(using data attributes, which XML doesn't support)
2. having only two levels of typing seems either insufficient or
unnecessarily limiting.  
3. It assumes that the resource is something for which distinctions like
text or not-text are even relevant.  It may not be, because the data type
may be entirely abstract (like an SGML architecture or grove construction

Note that notations can be declared within architectures and used
indirectly by that means, so that, for example, you can define a hierarchy
of notation classes in an architecture but need only declare the subtype
you need in your document locally.  You could in fact have an architecture
whose sole purpose is to define a set of related notations.   This might be
quite useful, since the architecture could itself be a public resource and
therefore act as a public and managed registry of notations in a
standardized syntax.

The real issue is whether you depend on a single management mechanism or
use a general mechanism that can either encapsulate some existing mechanism
(e.g., MIME) or provide other, equivalent mechanisms.

Since I know that I will often be operating on documents in environments
where things like the MIME registry is unavailable, I need a mechanism that
I can use without it, even if I use the MIME registry when it's available
and appropriate.


<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

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