Closed Bug 124709 Opened 23 years ago Closed 14 years ago

MIME type application/mathml+xml should be supported

Categories

(Core :: MathML, defect)

Product:
Core
Component:
MathML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9.3a5

People

(Reporter: burnus, Assigned: fredw)

References

(
URL
)

Details

(Keywords: helpwanted)

Attachments

(2 files, 2 obsolete files)

Add application/mathml+xml mime type
2.79 KB, patch
bzbarsky
: review+
Details | Diff | Splinter Review
reftest
1.72 KB, patch
Details | Diff | Splinter Review 
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/
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?
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
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.
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
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...
Keywords: mozilla1.0, nsbeta1
OS: Linux → All
Hardware: PC → All
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
> 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.
> 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



> 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.
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.
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
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.
OK, so what's the Hixie Plan (TM), then? :-)

Gerv
Banish the +xml MIME types, and rely on UA Capability Negotiaiton technologies
that are being developed.
Right... and the plan for right now?

Gerv
I plan for the long term. The short term plan is irrelevant since on the short
term Mozilla has no market share.
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
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.
> 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
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.
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
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.
Kai, I'm not exactly sure what you just said... are you saying that MSIE has
MathML support?  Please clarify :)
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.
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.
*** Bug 144719 has been marked as a duplicate of this bug. ***
Blocks: 152001
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).
Keywords: helpwanted
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.
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.

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")
        )
Blocks: 160882
I had missed the two references to RFC 3023 in this bug, my bad. I retract my
objections to treating */*+xml as XML.
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-)
See also bug 155730. (Your pages display in Opera & Konqueror when 
served as application/mathml+xml, but not text/xml? That's bizarre.)
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.
This should be fixed by bug 155730.
Depends on: */*+xml
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
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.
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.
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.
Keywords: mozilla1.0, nsbeta1-
Blocks: 377499
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.
QA Contact: ian → mathml
Blocks: mathml-2
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)
Assignee: rbs → fred.wang
Status: NEW → ASSIGNED
No longer depends on: */*+xml
Attachment #416267 - Flags: review?(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?
Attachment #416267 - Flags: review?(bzbarsky) → review+
(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...)
Pushed http://hg.mozilla.org/mozilla-central/rev/41eb585e76c3

Might be nice to write a test here.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
(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...
Attached patch reftest (obsolete) — — Splinter Review 

        Attachment #428310 -
        Flags: review?(bzbarsky)

    
    

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

    
    

    
  

      
      
      
      

        Attached patch
          
          
        reftest (obsolete)
        — 
          — Splinter Review
      

    


  
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.

        Attachment #428310 -
        Attachment is obsolete: true

        Attachment #428422 -
        Flags: review?(bzbarsky)

        Attachment #428310 -
        Flags: review?(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).

        Attachment #428422 -
        Flags: review?(bzbarsky) → review+

    
    

    
  

      
      
      
      

        Attached patch
          
          
        reftest
        — 
          — Splinter Review
      

    


  

        Attachment #428422 -
        Attachment is obsolete: true

    
    

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

Thank you again!
Flags: in-testsuite? → in-testsuite+

    
  
Target Milestone: --- → mozilla1.9.3a5

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: