Apparently, in the whats-hot-whats-not department, Web services are not.

Norm’s playing around with media types. This one is served with application/xml.

Let’s have a look at what should happen in a perfect world if XHTML is served with that media type. RFC 3023 says;

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.

What that means is that one cannot assume that namespace dispatching will occur, and therefore the semantics of application/xml are ambiguous; it is reasonable that the recipient see it as XHTML/HTML, but also reasonable that they see it as “XML” (such as in the IE XML tree view).

In the real world of course, reality can trump specification; concensus (in the form of running code) may very well be that namespace dispatching is assumed, and in that case at least the ambiguity vanishes. But then we’ve lost the ability to send plain-old XML. For example if somebody asks me for a sample XML document, I’d like to be able to send them some XHTML without it being interpreted by the other end as XHTML, just XML. I think it would be great if application/xml could be used for this purpose, but it’s not a huge deal; text/plain would also be appropriate in many cases.

So I set up a little test. Let me know what you see and I’ll record it. It could be useful in the soon-to-come revision to 3023, enabling us to be a bit more specific than “might”.