application/xml in ietf-xml-guidelines
Mark Baker <[email protected]>
| Newsgroups | gmane.ietf.xml-mime |
|---|---|
| Message-ID | <[email protected]> |
Hey, I just had a look at draft-hollenbeck-ietf-xml-guidelines-01, and saw this; "The "application/xml" media type is most appropriate for general XML; [...]" I have three concerns about it. In descending order of priority; "application/xml" (and text/xml for that matter) do not have any specified namespace dispatch behaviour. That is, if I send some XHTML as application/xml, the recipient agent doesn't know whether I want it displayed as XHTML, or in some tree like XML format, nor do I have any expectation of what the agent might do with it. According to RFC 3023, both behaviours are fine, and IMO this makes "application/xml" less suitable than believed as a generic type. Here's the relevant paragraph; ] An XML document labeled as text/xml or application/xml might contain ] namespace declarations, stylesheet-linking processing instructions ] (PIs), schema information, or other declarations that might be used ] to suggest how the document is to be processed. For example, a ] document might have the XHTML namespace and a reference to a CSS ] stylesheet. Such a document might be handled by applications that ] would use this information to dispatch the document for appropriate ] processing. (emphasis on "might" in that last sentence) Also, I believe that "text/xml" should be explicitly not recommended, due to the text/plain fallback of all text/* types. It's possible that text/* has already been abused so badly (text/html being the biggie) that a text/plain fallback cannot be assumed, but I'll let others decide if that's actually the case or not. Lastly, there's no mention of the RFC 3023 "+xml" suffix convention, which should at least be mentioned as a possibility for use. I believe that my first point above highlights a large part of the value of specific media types (whether +xml is used or not), as the required dispatch behaviour can be assigned to them. Plus, FWIW, I'm in the "don't use URNs" camp. Thanks. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. [email protected] http://www.markbaker.ca http://www.planetfred.com