Re: [xml-dev] Registration status

[Ian Graham <igraham@ic-unix.ic.utoronto.ca>]

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