[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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?

The subtlety doesn't lie in the intent, but in the difficulty of achieving it.
You can construct HTML that can be read without an HTML processor of any sort.
But few if any agents that emit text/html actually do this. Instead they emit
junk that is quite difficult to read even if you're familiar with HTML, and
nearly impossible if you aren't.

> > 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

No. There's a specific purpose to the +xml suffix and it should be used
when it is appropriate.

> 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).

This isn't necessarily true in light of the definition of the +xml suffix. In
addition, there is more to it than this. Top level types in particular are
intended to tell you generally how something is or can be processed. This can
assist an agent in handling material even when a specific definition isn't

> 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.

No it isn't, because that's not what the top-level text type is for. The intent
of the text type is to label material that can sensible be presented to people
without any processing.

You seem to think that the top-level text type label is intended to label
structured text, but that's just not what it is for.

> 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.

The +xml suffix is intended to make XML detectable even when the specific
type isn't known. This eliminates the need to use application/xml to
insure such processing is possible.