124709 - MIME type application/mathml+xml should be supported

Status: RESOLVED FIXED

(Core :: MathML, defect)

Description

[Tobias Burnus]

The mime type  application/mathml+xml should be supported by Mozilla. See URL
for a few pointer.

It is used for instance by the MML tests on W3C:
http://www.w3.org/Math/testsuite/

Comment 1

[Christopher Hoess (gone)]

cc'ing Gerv.  Needs to be added to the Accept: header.   RFC 3236 just registeredapplication/xhtml+xml; what is the status of the RFC for this content-type?

Comment 2

[Tobias Burnus]

http://www.ietf.org/rfc/rfc3236.txt?number=3236 (Januar 2002):
|Status of this Memo
|
|  This memo provides information for the Internet community.  It does
|  not specify an Internet standard of any kind.  Distribution of this
|  memo is unlimited.

See also:
http://www.w3.org/TR/MathML2/chapter7.html#N40759

Comment 3

[Tobias Burnus]

A better document: The Math2 standard points to
http://www.ietf.org/rfc/rfc3023.txt (Januar 2001, Category: Standards Track)

8.16 Application/mathml+xml

   Content-type: application/mathml+xml

   <?xml version="1.0" ?>

   MathML documents are XML documents whose content describes
   mathematical information, as defined by [MathML].  As a format based
   on XML, MathML documents SHOULD use the '+xml' suffix convention in
   their MIME content-type identifier.  However, no content type has yet
   been registered for MathML and so this media type should not be used
   until such registration has been completed.

Comment 4

[Gervase Markham [:gerv]]

As I understand this, the way this should work is that you should serve the
document as application/xml, and Mozilla should use XML namespaces to determine
that it's MathML and act accordingly.

However, I'm not sure who to check with to verify this assertion.

Gerv

Comment 5

[Christopher Aillon (sabbatical, not receiving bugmail)]

Gerv: your assertion is not entirely correct.  If the document is pure MathML,
it should be served with a MathML content type.  If it uses multiple namespaces,
for example XHTML plus MathML, then a generic XML content type would be fine.

Nominating for 1.0.  We currently support application/xhtml+xml, and
image/svg+xml.  Anyone who wants to test our MathML support will likely find
their way to the MathML test suite at the W3C and lo and behold, we can't even
_load_ half of it, let alone render it.  I'm sure we render much of it okay, but
an end user will not realize that.  They might try a few pages, give up and lose
faith in our MathML support...

Comment 6

[Gervase Markham [:gerv]]

caillon: are you saying that the W3C test suite does not load because we do not
send this type in our Accept: header?

> If the document is pure MathML,
> it should be served with a MathML content type. 

My understanding of the way Mozilla works internally is that it uses XML
namespaces to work out what to do with some XML it gets, and so the standard XML
content-type is fine for any sort of XML. If I'm incorrect about this, please
find a hacker who wrote/understands the relevant code to tell me I'm wrong.

Gerv

Comment 7

[Christopher Aillon (sabbatical, not receiving bugmail)]

> caillon: are you saying that the W3C test suite does not load because we do
> not send this type in our Accept: header?

I did not say that.  I said the test suite does not load half of the pages. 
Half of the suite is using application/mathml+xml and the other half uses
text/html  See for yourself at one of the tests which we fail to load:
http://www.w3.org/Math/testsuite/Presentation/TokenElements/mi/miAtoken5.mml

> My understanding of the way Mozilla works internally is that it uses XML
> namespaces to work out what to do with some XML it gets, and so the standard 
> XML content-type is fine for any sort of XML.

That is correct.  *If* the document is sent as XML mime type _that we recognize_
then we use namespaces.  If we don't recognize the mime type, then we won't even
load the document, we'll present a download dialog, and all the namespace
processing in the world won't help us.

But saying that application/xml is an appropriate type for any type of XML, is
like saying that text/plain is an appropriate type for any type of text
document, or image/jpeg is appropriate for any image file.  If you have a
document which is _specifically_ MathML, and MathML _only_, then is there a
reason to use a generic type, and not the specific type?  The current
recommendation for XHTML as I understand it is to use the specific XHTML type
application/xhtml+xml and _not_ application/xml when the document is pure XHTML.
 We do support that.  This should apply to MathML as well, and thus we should
support the specific MathML type, application/mathml+xml

So what I'm saying in a nutshell is that we should add application/mathml+xml to
our internally supported XML mime types so that we _can_ process it and not
present the user with a download dialog.

Comment 8

[Gervase Markham [:gerv]]

> That is correct.  *If* the document is sent as XML mime type _that we recognize_
> then we use namespaces.  If we don't recognize the mime type, then we won't even
> load the document, we'll present a download dialog, and all the namespace
> processing in the world won't help us.

If this is the case, then it has _nothing_ to do with the Accept: header. That
header is merely a set of suggestions to the server. What MIME types Mozilla
"recognises" is different code entirely. According to choess in comment 1, this
bug is about the Accept: header, and it's adding the MathML MIME type to the
Accept: header that I'm resisting. If you want to add it somewhere else, it's
nothing to do with me and I couldn't care less :-)

Gerv

Comment 9

[Christopher Aillon (sabbatical, not receiving bugmail)]

> If this is the case, then it has _nothing_ to do with the Accept: header.

Correct.  This needs to be handled elsewhere.  Though an entry in the Accept:
header would be nice if MathML is enabled to allow authors to serve MathML if
accepted, and perhaps an image if not.

Comment 10

[Hixie (not reading bugmail)]

The growing list of MIME types that end in +xml that we will have to add to our
Accept: header (including all those that we can instantly support simply by
adding a few rules to ua.css) is exactly the reason I am against the
proliferation of +xml MIME types. I don't see what is wrong with using text/xml
and then deciding how to handle it (including which DOM to use, and whether to
hand it to an external application) based on the namespace of the root element.

But I guess this is not the right forum to be complaining about that.

Comment 11

[Gervase Markham [:gerv]]

Hixie is correct. What we should be doing is passing all "*+xml" types to
Mozilla to handle. If we aren't currently doing that (and popping up a download
dialog instead) then that's a bug. 

We should have only the basic XML types in Accept:.

The problem of a site finding out whether MathML is supported or not is an
orthogonal one. The best way to do this is to check for Gecko date from the date
it got turned on.

Gerv

Comment 12

[Hixie (not reading bugmail)]

That won't work for two reasons. First of all, there is no guarentee that all
+xml MIME types are XML. For example, text/x-uuencoded+xml isn't XML. Secondly,
you can't sniff based on Gecko date because just because there is no guarentee
that any particular distribution will enable everything. For instance, my build
has SVG and MathML enabled, Mozilla test builds have only MathML enabled, and an
unnamed other distributor has MathML disabled in its nightly builds.

Comment 13

[Gervase Markham [:gerv]]

OK, so what's the Hixie Plan (TM), then? :-)

Gerv

Comment 14

[Hixie (not reading bugmail)]

Banish the +xml MIME types, and rely on UA Capability Negotiaiton technologies
that are being developed.

Comment 15

[Gervase Markham [:gerv]]

Right... and the plan for right now?

Gerv

Comment 16

[Hixie (not reading bugmail)]

I plan for the long term. The short term plan is irrelevant since on the short
term Mozilla has no market share.

Comment 17

[Gervase Markham [:gerv]]

Right...

Everyone else, back in the world of this bug, let's make sure all +xml MIME
types are passed to Mozilla rather than presenting a Download dialog. 

I'm still not sure what to do about the MathML support detection problem. I'd
very much like to avoid extending Accept:, because I can see SVG queueing up to
be next.

Gerv

Comment 18

[Hixie (not reading bugmail)]

I'm serious. Content-Type sniffing is pathetic. You don't want to do it. Look at
the flak IE has got from the standards community over doing exactly that. I've
already given you several reasons why it won't work in this case.

I do think we should pass some specific MIME types that we support over to our
XML processor, application/mathml+xml being one of them. I do _not_ think we
should pass other MIME types that we _don't_ support to our XML processor. If
they are not using the text/xml MIME type then we have _no_ reason to assume
that styling it with CSS is going to be of any help whatsoever. In fact, I can't
think of a single XML vocabulary which has its own MIME type that we could
handle without some explicit C++ support (this includes all the obvious types
like XHTML, SVG, MathML, and XUL).

If we want a short term solution, though, I don't see why we wouldn't want to
add everything we support to the Accept: headers. Especially things as high
profile as MathML and SVG. The text/xml MIME type with its implications of
support for mixed namespace content should come first, of course, but the MathML
MIME type seems like a nice clear way to indicate what we support.

Comment 19

[Gervase Markham [:gerv]]

> I'm serious. Content-Type sniffing is pathetic. You don't want to do it. Look 
> at the flak IE has got from the standards community over doing exactly that. 

Yer wot? IE got a lot of flak for _ignoring_ Content-Type and going on file
extension or file content sniffing instead. Content-Type is the right way to
determine what class of document it is, in general.

> I do think we should pass some specific MIME types that we support over to our
> XML processor, application/mathml+xml being one of them. I do _not_ think we
> should pass other MIME types that we _don't_ support to our XML processor. If

I'm sold. OK; we only need to fix the specific problem that's making us put up
download dialogs for application/mathml+xml.

> If we want a short term solution, though, I don't see why we wouldn't want to
> add everything we support to the Accept: headers. 

The reason not to do this is that the Accept: header gets sent with every HTTP
request and we need to make a very good case for making it any bigger, because
the cost adds up on slow connections.

(/me wonders why they couldn't have used "app" instead of "application").

Gerv

Comment 20

[Hixie (not reading bugmail)]

Our current accept header:
   text/xml, application/xml,
   application/xhtml+xml,
   text/html;q=0.9,
   text/plain;q=0.8,
   video/x-mng, image/png, image/jpeg, image/gif;q=0.2,
   text/css,
   */*;q=0.1

Seems like adding application/mathml+xml and image/svg+xml is reasonable. Heck,
I could even see an argument for adding our XUL MIME type.

Are there any studies anywhere on the effects of an extra few hundred bytes in
each GET header? I would have thought we added that much already simply from the
 Gecko/ and Netscape/ UA string additions, not to mention the dozens of bytes we
add each time a user adds a language.

Comment 21

[Gervase Markham [:gerv]]

We've had this argument before in other bugs - about the XUL MIME type,
certainly. Navigator 3.x put all the MIME types it supported into its Accept:
header, and the result was 4k long. 

On a 28.8k modem, if you've just requested a page and are sending several GETs,
the current few hundred bytes of header take significant time to transmit. It's
important to keep a lid on this figure, and not let it creep upwards. We've
already had customers (from IBM) complaining about the length.

Everything's a trade-off. Having said that, we may have to put SVG and MathML
in. :-(

Gerv

Comment 22

[Kai Lahmann (is there, where MNG is)]

This MUST be added before 1.0. If not this will happen:
ALL MathML files will be provided with this MIME, as there's no way to prevent
MSIE to use it's internal parser and it will look like Mozilla not being able to
handle MathML.

Comment 23

[Christopher Aillon (sabbatical, not receiving bugmail)]

Kai, I'm not exactly sure what you just said... are you saying that MSIE has
MathML support?  Please clarify :)

Comment 24

[Kai Lahmann (is there, where MNG is)]

no, it doesn't, but what about Plugins? They need (at least in normal Browsers) a Plugin to get involved. So you'll need another Mime then text/xml.

Comment 25

[Hixie (not reading bugmail)]

There's no reason plugins for XML content can't be keyed off the root element's
namespace. Indeed for mixed-content documents that's the only solution.

Comment 26

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 144719 has been marked as a duplicate of this bug. ***

Comment 27

[rbs]

So, the convergence from the discussion seems to have come down to:
1) support application/mathml+xml like the others (xlst/xhtml/svg) -- helpwanted... 
2) close the eyes and add application/mathml+xml in the Accept: header (and xul,
and svg, and xbm, and etc too?!? As comment 19 said, why din't they (also) allow
app/* for something that is sent on the net so frequently -- the standards can
have side-effects sometimes).

Comment 28

[rbs]

Or associated numeric codes could be supported as well (as in the case for HTTP
responses), e.g., assuming 404 = text/xml, 503 = text/html, one could say
"Accept: 404,503,video/x-mng,etc", and that will scale much better in the long
run.

Comment 29

[Braden]

Hixie: The whole point of the "+xml" suffix to MIME types is so that
applications  can tell if data is XML even if they don't know about its exact
type. Read Appendix A of RFC 3023.

Based on the contents of RFC 3023, I think it is completely safe to assume that
all registered *+xml types are XML.

If there is a problem with brain damaged experimental types using +xml when they
shouldn't, those types should be handled specially on a case-by-case basis.

Comment 30

[rbs]

FYI - saw this proposal to extend the content-type:
http://www.ietf.org/internet-drafts/draft-stlaurent-feature-xmlns-02.txt

Example:
      For an XHTML document containing SVG, MathML, SMIL, and XLink
      content:

        Content-Type: application/xhtml+xml
        Content-features: (|
           (xmlns="http://www.w3.org/1998/Math/MathML")
           (xmlns="http://www.w3.org/2001/SMIL20/")
           (xmlns="http://www.w3.org/2000/svg")
           (xmlns="http://www.w3.org/1999/xhtml")
           (xmlns="http://www.w3.org/1999/xlink")
        )

Comment 31

[Hixie (not reading bugmail)]

I had missed the two references to RFC 3023 in this bug, my bad. I retract my
objections to treating */*+xml as XML.

Comment 32

[Patrick Fromberg]

AAAAAh, it is such a pitty!! Mozilla can do MathML. But I only can use Amaya to
see my web pages. This really shouldnt have happened. Some comments, to what had
been written here.

> That won't work for two reasons. First of all, there is no guarentee
> that all +xml MIME types are XML. For example, text/x-uuencoded+xml
> isn't XML. Secondly, you can't sniff based on Gecko date because just
> because there is no guarentee

There is a difference between Content-Type and Enconding-type. Unfortunately the
mime type "application/gzip gz" has raised terrible confusion about this. There
should have been something like "application/packager gz zip tgz".  The
existence of "application/gzip" is a *BUG* in the mime specifications.

> I plan for the long term. The short term plan is irrelevant since on
> the short term Mozilla has no market share.

It needs to have a market niche at least (mathml, svg, proper css). My pages are
now viewable without formulas by all browsers and with the formulas they can be
seen with Amaya only. Amaya is taking Mozillas market niche away!

I can not make my pages with xml extension! If I make my pages xml, Konqueror
and Opera will not show one single character any more. I can live with only the
formulas not beeing displayed. Then I can suggest to those, who want to see the
formulas too, to use Mozilla or Amaya. But I can not live with Opera and
Konqueror just showing nothing.

As I read here, this is only, because you are trying to be clean with mime
types, which is not possible anywhay. XML ist not a file format. Its a
langauage, that can be embedded anywhere. To say, that Mozilla should not find
out about XML through mime is note the same as saying, that Mozilla should do
sniffing. If xhtml can contain MathML, Mozilla must just assume possible
existence of MathML and if there is no MathML, where is the Problem? Why should
I tell gcc that it will encounter template classes when parsing c++? It will
parse C++ and than find out by itself. Isnt this why doctype and xmlns have been
added to (x)html?

Instead of mime type "application/something+otherthing" I would suggest
"application/n-faculty" for short 8-)

Comment 33

[Christopher Hoess (gone)]

See also bug 155730. (Your pages display in Opera & Konqueror when 
served as application/mathml+xml, but not text/xml? That's bizarre.)

Comment 34

[rbs]

re: comment #30
>
> FYI - saw this proposal to extend the content-type:
> http://www.ietf.org/internet-drafts/draft-stlaurent-feature-xmlns-02.txt

Link is a moving target. Latest link at:
http://www.simonstl.com/ietf/ -- Registration of xmlns Media Feature Tag.

Comment 35

[Hixie (not reading bugmail)]

This should be fixed by bug 155730.

Comment 36

[Samir Gehani]

adt: nsbeta1-

Comment 37

[Manko]

Important for me. I want to use:
<object type="application/mathml+xml" data="formula.mml">
<img src="formula.png" alt="foo foo foo" />
</object>

to display MathML for aware browsers and picture for unaware.

Comment 38

[rbs]

That won't work as you expect. (In fact, you can already do that with
<object type="text/xml" data="formula.mml">.) The reason it doesn't work as you
might want is because you have to specify the height & width of the <object>.
Something that you cannot tell in advance with those nested formulas & user
fonts. Another issue is a neat alignment w.r.t. the "baseline". In short, it had
been tried (with type="text/xml") but it looked very ugly. Better not to count
on that.

Comment 39

[Brion Vibber]

I've been trying to do the same as described in comment #37 (<object> tag
pointing to MathML file, with fallback to rasterized equation). Using text/xml
or application/xml doesn't work, since there are certain popular browsers that
will happily "render" the MathML bits as a parse tree or by stripping out tags
instead of falling back to the image.

Using <object type="application/mathml+xml"> works in Amaya, and correctly falls
back to the alternate version in MSIE, classic Netscape, iCab, etc. It also
incorrectly falls back in Mozilla, which could render the MathML but doesn't
recognize the MIME type.

Additionally, if Moz sent it in the Accept: header as Amaya does, it would be
possible to tailor pages to use inline MathML (much more reliable placement than
<object>s) or images without unreliable UA sniffing (oops, this one is Gecko,
but has no MathML built in...) or manual "click here for MathML version" links.

Comment 40

[Xavier Robin]

Also it should be noted that some websites such as sciencedirect.com start to send mathematical formulas as application/mathml+xml. Currently this results in Firefox downloading the file. The user must subsequently open the file in a MathML-aware viewer (such as Firefox).

An example of this is this page: http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6V7D-4HSXVY7-1&_user=779890&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000043220&_version=1&_urlVersion=0&_userid=779890&md5=09d911435f20b4f81cf2ab6a540a1b97
(might not be open access). 

Clicking on a formula results in downloading the file. It would be a great plus if formulas could be displayed directly without additional steps.

Comment 41

[Frédéric Wang (:fredw)]

So finally, this bug is likely to be fixed in the same way as bug 160882 and not using bug 155730 as indicated in comment 35. (see bug 155730 comment 62)

Comment 42

[Frédéric Wang (:fredw)]

Attachment: Add application/mathml+xml mime type

This patch applies on top of attachment 413793 [details] [diff] [review].

Comment 43

[Frédéric Wang (:fredw)]

http://www.maths-informatique-jeux.com/international/xml_mime/mathml.foo

Comment 44

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 416267 [details] [diff] [review]
Add application/mathml+xml mime type

Looks fine to me.  Do you want me to push this, or can you do that yourself?

Comment 45

[Frédéric Wang (:fredw)]

(In reply to comment #44)
> (From update of attachment 416267 [details] [diff] [review])
> Looks fine to me.  Do you want me to push this, or can you do that yourself?

No I can't, so I would appreciate if you could push it for me. Note however, that as I says in comment 42, the patch applies on top of the one for bug 530275 (I made comment on it after your review, but I've just realized that you were not cc'ed, so I guess you have not read them...)

Comment 46

[Boris Zbarsky [:bzbarsky]]

Pushed http://hg.mozilla.org/mozilla-central/rev/41eb585e76c3

Might be nice to write a test here.

Comment 47

[Frédéric Wang (:fredw)]

(In reply to comment #46)
> Pushed http://hg.mozilla.org/mozilla-central/rev/41eb585e76c3
> 

Thanks!

> Might be nice to write a test here.

Yes, I'm going to attach one...

Comment 48

[Frédéric Wang (:fredw)]

Attachment: reftest

Comment 49

[Boris Zbarsky [:bzbarsky]]

Doesn't that reftest depend on the exact pixel sizes of "200%" fonts?

Comment 50

[Frédéric Wang (:fredw)]

Attachment: reftest

Yes, previous test could be incorrect if the default size was too large and make the text go outside the <object/>. Here is a simplified version, without text at all.

Comment 51

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 428422 [details] [diff] [review]
reftest

Can we name those mathml-type-supported instead of Bug124709?  r=me with that (and ideally a changeset that has a User and commit message in it).

Comment 52

[Frédéric Wang (:fredw)]

Attachment: reftest

Comment 53

[Boris Zbarsky [:bzbarsky]]

Pushed that test as http://hg.mozilla.org/mozilla-central/rev/18d0466b9a93

Thank you again!