On Mon, 29 Oct 2001, David Carlisle wrote:
Sorry for delay (been off line ...)
having to upgrade that installed base is exactly the problem with
the xxx+xml proposals. If XML is served as text or application/xml
....
But if your mail agent comes across an xxx+xml document and it doesn't
know this type, basically it's stumped. It won't even (currently) by
default do the "obvious" thing of dropping the xxx+ and trying the more
general xml mime type.
you say
This of course, is all IMHO, as RFC 3023 explicitly supports you
serving all XML as application/xml if you really want to. But as A.15
mentions, there are no apparent downsides from using custom types and
several advantages.
....
Incidentally it seems to be widely held belief that text/xml was a
mistake and that xml ought almost always be in application/xml. I don't
really hold that view. For decades TeX users have sent tex markup as
plain text emails and been more or less happy. I don't see
(document-oriented) XML as significantly different. If someone sends me
some email with some mathematics in, and I'm sat at a machine without a
mathml renderer, I'd much rather just see the mathml markup inline
(which can be read, in small doses, honestly:-) than just be offered a
file/save option on the grounds that the lovingly constructed
mathematics is just unreadable application specific data.
I've been thinking about this one a bit more, and perhaps a useful
alternative would be to expand upon the XML 'type' information with extra
XML-specific headers ... something like:
Content-type: text/mathml
xml-primary-namespace: http://www.whatever.org/namespace
xml-secondary-namespace: http://some.other.org/namespace
xml-secondary-namespace: http://and.another.org/namespace
Older MIME-aware applications would just use content-type, and ignore
the rest, while newer 'XML-aware' applications could use the namepace
headers to more finely 'type' the message content, and process it
appropriately.
Any thoughts?
Ian