[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MIME types and content negotiation

At 07:28 PM 3/17/00 +0000, Graham Klyne wrote:
>At 02:20 PM 3/17/00 -0500, Simon St.Laurent wrote:
>>I don't see the 'complexity' that certain other folks here are complaining
>>about - in fact, I think these 4 bytes promise considerable simplification
>>over any multi-parameter approach, for both humans and machines.
>This argument might hold if the only requirement is to (a) recognize a 
>specific application of XML, and (b) (usually) recognize a generic 
>XML-based file format, even when the specific application is not recognized.

a and b describe the applications we're working on here, and are also
useful even when the problem described below - a very separate issue, in my
opinion - emerges.

>I have read a lot of stuff recently that indicates the forward vision of 
>much W3C activity is that a single XML file may contain data corresponding 
>to many different XML applications.  Once we get into this kind of 
>territory, I think the idea of a MIME subtype suffix becomes hopelesly 
>lost, and some kind of multiparameter approach becomes the simplest way to 
>deal with the recognition problem.

This is a separate problem.  The MIME type discussion in draft-murata-xml
is about identifiers for complete documents, not for the admittedly more
difficult problem of providing a manifest of all types within a document.

Put a different way, the MIME types are only describing the container, not
the content.  While an XHTML document may contain SVG, SMIL, and twelve
other vocabularies, the container is still XHTML.  From my perspective,
it's still worthwhile to know that the XHTML document is also XML, and
similarly it would be worthwhile to know that a 'polluted' SVG, SMIL, or
other document is XML.

In fact, having the suffix might give applications a heads-up that more
complex negotiations may be in order, whereas not having a suffix means
keeping track of these possibilities for every single type.  It might in
fact be worthwhile for a sophisticated generic processor to start by
recognizing the content as XML and then dispatching the subcomponents based
on its reading of the document.  At the same time, less generic processors
might want to know something more about the document than "it's XML."

I don't see this argument as making a case against the suffix.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth