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. mbaker(_at_)planetfred(_dot_)com
http://www.markbaker.ca http://www.planetfred.com