If a supermarket labels a package of pork by-products as rib-eye steak, does that make it beef? Vice versa, if it labels a rib-eye steak as pig snouts, does that make it pork?

The MIME type does not determine whether or not a given data stream is XML. If the stream is well-formed according to the XML 1.0 specification, then it is XML…

Labels such as MIME types and file extensions suggest to applications (including web browsers) how they might choose to interpret a given sequence of bytes; but they do not determine the nature of those byte sequences.

Your analogy breaks down because the MIME type isn’t just a hint as to the contents of a file — it is the only reliable indicator of how a document should be treated.

If you serve an XML document as text, it is not an XML document so far as your browser is concerned, nor does the server intend your browser to treat it as such. For example, let’s say I serve you the following comment as a plain text document:

<sarcasm>IE 4 is a *really* great browser for the modern day…</sarcasm>

All fine and dandy, if your browser follows the simple imperative I delivered by indicating the MIME. However, if your browser declares, “Aha! This looks like XML, so that’s how I will parse it,” what exactly is it going to deliver to the end user in place of my actual comment? Are they going to see the “sarcasm” tag I used purely for effect, and which was an important part of my message?

As for XHTML content, serving it as pure XML should remove any default formatting from every element, something which will generally have unpleasant implications for most stylesheets, which take such formatting into account. Serving a document designed to be served as text/html as application/xhtml+xml has a slew of implications for how any scripts or stylesheets associated with a document should be written.

To reiterate, the MIME type isn’t just a hint, it’s the only reliable way to know how to parse and display any document.

Anybody who views the XHTML source of this page will see that there’s an XML declaration (XHTML is XML, after all) but no doctype declaration. A doctype declaration may have usefulness in HTML, but it is needless in XHTML. I am so glad Rusty Elliott…

I learned about XHTML a long time ago, but I’ll admit that it hasn’t been that long since I learned that XHTML should be served with a MIME type of application/xhtml+xml. I went ahead and converted a separate blog I run to use XHTML with the proper…

debug html/css? use the EYES html/css debugger.

As to the XML discussion, I prefer YAML myself.

rationality is overrated
Craig

Thank you very much for this informative article! I just want to add some points, which may be the source for some misconceptions of some of the commenters.

First of all having XML data-islands in XHTML is completely valid, its just that DTD can’t handle them properly; that is, if you try to validate a combound document with a DTD, it will give you false negatives ( the validator shows an error, even if there is none ). Just consider DTDs as deprecated, since the W3C now uses RelaxNG instead of DTDs.

Second and more importantly, in a moderns XML world, you don’t have simple plain HTML documents, but instead you have document fragments in different namespaces mixed into another ( http://www.w3.org/2004/CDF/ ). A namespace aware browser treats a fragment in the XHTML namespace as XHTML, so it doesn’t matter much what MIME type you use ( as long as its an XML MIME type), that is the type of document is completely irrelevant.

And as a third argument, people seem to forget that there are different languages you can use, but microfomats only work in (x)HTML. a “macroformat” can be used in
any other XML based language, without any change.

I’ve written a very simple example of a bar chart ( as a prove of concept ), which can be used in XHTML, SVG, XSL-FO, standalone or any other XML vocabulary, without changing the data or the stylesheet.( http://www.treebuilder.de/default.asp?file=306286.xml )

Examples of well known and widely supported “macroformats” that come to mind are
the CC license stuff and the Dublin Core vocabulary.

cheers
Holger

Debugging XML/CSS issues is much easier than debugging HTML/CSS issues because the browser doesn’t have any preconceptions about how it should or should not display any given element. It’s all in the style sheet.