> However, I'd really rather not be downloading material I can't use. If I
> know beforehand - from MIME types exchanges in HTTP negotiations, for
> instance - that the information is in XML, I may be (depending on my
> application type) more willing to take the risk. If not, I'll be spending
> a lot of time downloading junk, finding that it doesn't work, and trying to
> avoiding getting that type of information the next time around.
Again, this can be handled by using content-negotiation. It would be pretty
easy to add a conneg type that would describe the type of XML that you are
passing, without breaking the example I gave for protocols that don't do
negotiation.
There is also an intermediate case -- IMAP. In IMAP header information for
a MIME message can be downloaded and examined prior to downloading the
actual message content. But this is restricted to the labelling in header
fields -- media type, media type parameters, and disposition information,
in other words.
There are also instances in HTTP where the MIME type for an external
object is already known, but going through a content negotiation
step means making an external connection -- a far more costly operation.
And there's also the issue of needing to extend existing negotiation mechanisms
to accomodate new labelling information. This may be a no-brainer from a
protocol design standpoint, but unfortunately it is anything but when you
consider the restrictions that exist in deployed software.
The long and short of it is that I don't see either extreme position on this
issue as tenable. The notion of "all XML goes under the application/xml media
type and a different mechanism is used to distinguish different instances of
XML usage" is a nonstarter, and so is "every little twiddle to something done
in XML gets a new media type". I also don't think that XML is even close to
mature enough for us to attempt to establish definitive rules for when a media
type is needed and when it isn't.
Ned