On Mon, 10 May 1999, Tim Bray wrote:
Or maybe the whole notion that a rigid 2-level type hierarchy is a useful
vehicle for interoperability is becoming bogus.
I think Tim's ambivalence is just a sign that that all these are useful,
and that we should provide enough richness to cover the major cases:
* generic XML using stylesheets and fallback (text/xml & application/xml);
* application-specific XML with no need for fallback (application/*,
model/*, etc);
* application-specific XML but which allows some measure of fallback,
even if just to allow browser users to figure out which is the best
handler for it (the XML registration tree: application/xml.*): we can
expect smarter broswers to check for <?xml when they do not have a MIME
media type registered for a specific MIME type.
Simon asked why an XML registration tree would be better than just a new
top-level MIME type: the reason is that to introduce any new types in the
(default) IETF registration tree you need to make a full RFC providing
certain information (see the RFCs on MIME types, referenced in previous
postings). It is not simply a matter of whether the strings "xml/blah"
has more information thatn "application/xml.blah" or "application/xml;
schema=blah". It is more importantly the administrative requirements
needed to maintain the integrity of MIME.
The essense of my call for an XML registration tree is that it could be
automatically registered after a minimum of information is provided.
Otherwise we will just get spurious unregistered MIME media types:
text/rdf, application/vml, etc etc. The reason we don't want the MIME
media type registration to fall over is that WWW and email browsing
relies on registered MIME media type being fixed to a particular type.
(It is bad enough that my browser has decided that all .gz files are VRML;
I don't want to encourage media-type detection using file extensions. So
I believe we need to make it easy to register new XML-based types.)
Rick Jelliffe