Oh dear. Off topic, but I can't resist at least a reply... with
apologies up-front
If you want Internet Explorer to display it, you /must/ serve it as
text/html.
IE, as normally used, does not support XHTML, and it would be better
not to send it any. Faking XHTML as HTML brings no benefits at all at
the web interface, and adds a few disbenefits. It's sometimes claimed
that XML-based tools at the authoring side are a valuable benefit, and
therefore the result will be XHTML - but that is a half-truth:
XML-based tools can also emit HTML/4.01 as their end-product.
Internet Explorer refuses outright to render a document that it
knows to be XHTML.
Right from the start of the WWW, browsers which can't render a
particular MIME content-type have been configured to fire up a
suitable "helper application" to view that content type.
More recently there's been a tendency to define "plug-ins", which
render certain content types but display them in the window of the
browser.
Either of these mechanisms should be available in IE (after
sacrificing a suitable animal to XP SP2, I suppose). Years back I
configured Windows/IE to use a "helper application" for opening XHTML
MIME-types, and I defined the helper application to be Mozilla. It
worked fine. OK, I'm not promoting it in that form as a practical
solution for end-users, just offering an in-principle refutation that
if the browser-like object doesn't support it then it can't be used.
The original idea of XML was to make a clean break with "tag soup".
Fortunately, most browsers will produce acceptable results for XHTML
1.0 served as HTML.
Unfortunately, that's led to the unwashed masses of web deezyners
simply converting their HTML-flavoured tag soup into XHTML-flavoured
tag soup, and tossing the potential benefits of the clean break out of
the window (no pun intended).
XHTML 2.0 served as HTML, on the other hand, will go
straight into the toilet.
So the bottom line is:
- XHTML/1.0 Appendix C is functionally identical to HTML/4.01, and
almost - but not quite - as compatible with tag-soup slurpers. So
what's the point of deploying XHTML/1.0 to browsers which were never
designed to process it? If the original isn't HTML, XHTML/1.0 can be
converted by rote into HTML/4.01, and the result is slightly more
compatible with the browsers out there.
No other version of XHTML offers that easement. By definition, if you
serve it out as text/html it cannot be XHTML(tm), other than this
pointless, self-contradictory and counter-productive backwater:
XHTML/1.0-Appendix-C. What it would be is XHTML-flavoured tag soup,
which is no kind of improvement from what we already had.
I say choose one of:
* stay with HTML/4.01 - there's no point in XHTML/1.0; or
* make a clean break and move to Real XHTML(tm), with some kind of
Accept-type negotiation for client agents which don't grok it.
In short, XHTML is dead, murdered by Bill Gates' arrogance.
XHTML is alive and well in a subset of client agents, with useful
extras like SVG. Content-type negotiation (Accept: header) has been
working for years; IE contrives (like so much else) to get it only
vaguely right, but with a bit of sleight of hand at the server it can
be made to work with IE's default settings, and the more-aware can
adjust the Accept: header (or have it adjusted for them) to get better
results.
IMHO and YMMV.