---------- Forwarded message ----------
cc: elharo(_at_)metalab(_dot_)unc(_dot_)edu, ietf-xml-mime(_at_)imc(_dot_)org,
xml-dev(_at_)lists(_dot_)xml(_dot_)org
On Sun, 28 Oct 2001, David Carlisle wrote:
There's been some thought about doing it but I think we're watching
the progress of the html group's html+xml draft first. (speaking about
MathML here)
But personally the more I think about this, the less I like it, and see
so little use for media types for XML languages. Except for test files
MathML never lives on its own, it's always embedded in a larger document
type, XHTML, DocBook, TEI, whatever. Since the same document might also
have svg, you end up with application/xhtml+mathml+svg+xml and
permutations of that. It seems unreasonable to expect any application to
do anything with that and in practice a more workable alternative is to
serve everything as application/xml and let the application key
individual processing requirements off the namespaces contained in the
document. (Actually my "home" isp will serve .xml files as text/xml with
no possibility of changing that, but that's a different thread)
I had a similar argument about this with Simon about a year ago (maybe
longer). I too felt that the MIME mechanism should simply state the 'raw'
type, and the handler should decide the specifics of the processing.
Your example nicely illustrates the rational for this point of view.
However, RFC 3023 does expliclity talk about this, in Appendix A. The
issue really is that, without the +xml trick, new MIME types would
logically want to identify types by their role -- as in image/svg -- which
would mean that a non-svg aware applicaiton wouldn't know that the data is
XML. If it did -- which is what xml+svg gives you -- then the software
could perhaps offer appropriate alternate processing.
The core questions, I think, are:
* how 'deeply' MIME types (or some future variant of the MIME typing
mechanism) should poke into the data they are 'typing'?
* And, if they poke deeply, what type of/how much information should be
revealed?
An alternative would be to ask the question: "How can one structure XML so
that a 'shallow' look into an XML 'part' can determine which 'types' are
inside it?" Namespace declarations would do this to some degree, but at
the expense of forcing a dispatcher to parse the XML.
Ian
--Paul Hoffman, Director
--Internet Mail Consortium