RE: text/xhtml+xml vs. application/xhtml+xml

> This is a subtle issue that very few document creators will
> understand

True, but then the argument against text/html is also rooted in
such subtlety?

> It's much better to pick one MIME type for each media type then to try to
> pass on the decision to folks who won't understand or won't care about the
> subtlety.  That one type, IMHO, should almost always be
application/foo+xml
> not text/foo+xml.

In that case it would seem much better to define application/foo rather
than application/foo+xml

XML is a complex object type (as is text in general), the question is where
that complexity best resides, and where one desires interoperability. I
would argue that text/xml (as in my example) is useful, but not sufficient
because it doesn't capture everything needed to process the content. This
is one of the problems that XML brings to the fore because it can represent
so many things, and be interpreted in so many ways (MIME is built around
the assumption that the media type canonically defines how it should be
processed).

To get back to ground zero, one must ask why one is exchanging XML in the
first place. If is as a structured peice of text, then text/* is fine. More
often than not, this will *not* be the case, and so there is a good argument
for application/*. In cases where XML content is being served with
additional
defined processing, the message type will probably be a multipart message,
with one part being labelled as text/xml (another might be application/xsl
or text/css).

Bottom line: XML in well-defined cases should use XML, otherwise it will
probably use a multipart message.