> > 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).
That may be your opinion. My experience has been otherwise.
> 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.
Hardly. Adding an entry for a new type is one of the things most agents allow,
and generally handle pretty well.
And some agents even support wildcarding that will allow */*+xml to be
redirected. (I'm actuaally not in favor of this. I'd rather have a new type
bring up a dialogue that lets me pick the app I want to use.)
> > 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.
Speaking as someone who spent years and years doing technical support for
a math department, I have to say that your experience with users is
the exact opposite of mine in all of this.
Ned
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.