[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Registration status

• From: David Carlisle <davidc@n...>
• To: dan@d...
• Date: Mon, 29 Oct 2001 09:44:40 +0000 (GMT)

> 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.

David

_____________________________________________________________________
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.

• Prev by Date: RE: Microsoft's deeply cynicalappealto"standards comp liance"
• Next by Date: Re: IDs without DTD/Schema , Is there a way ?
• Previous by thread: Re: Registration status
• Next by thread: TransQuery - XSLT as Query Language
• Index(es):
  • Date
  • Thread