Re: [xml-dev] Registration status (fwd)

[Ian Graham <igraham@xxxxxxxxxxxxxxxxxxxxxx>]

---------- Forwarded message ----------

>cc: elharo@xxxxxxxxxxxxxxx, ietf-xml-mime@xxxxxxx, xml-dev@xxxxxxxxxxxxx
>
>
>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