OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xml-dev] Registration status

> Now, all we need to do is upgrade the entire installed
> based of Internet-connected machines that understand MIME, and I'll
> agree that a MIME registration for backward compatibility is no longer
> necessary.

having to upgrade that installed base is exactly the problem with
the xxx+xml proposals. If XML is served as text or application/xml
then you do get a reasonable default behaviour (for example your mail
agent might ship all such files to internet explorer for display.
IE has a reasonable default presentation of XML and its default
stylesheet could easily include special cases for things like svg and
xhtml (and until then the document can specify a specific stylesheet).

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.

but A.15 (which I have re-read) is about the benefits of using a +xml
suffix as opposed to not. I agree, if there is to be a mime type for
mathml then it may as well be text/mathml+xml rather than just text/mathml.
I don't think there is any argument with that. But until mime agents are
upgraded to _automatically_ fall back to text/xml if they receive a
text/mathml+xml document and they don't know that mime type, then
anyone serving mathml files would be well advised to serve them as
text/xml as they will have a much wider chance of being processed.

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.


This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.