143842 - implement the MathML DOM

Status: RESOLVED WONTFIX

(Core :: MathML, enhancement)

Description

[Alex Vincent [:WeirdAl]]

The MathML 2.0 specification includes a Document Object Model for MathML
documents.  I'm interested in developing code to read content MathML from
JavaScript, preferably using the MathML DOM if possible.

The W3C currently provides in Appendixes D and E of MathML 2.0 a breakdown of
the MathML DOM, IDL files and ECMAScript bindings.  I'm wondering what steps
would be needed to enable a MathML DOM in Mozilla.

Comment 1

[Christopher Aillon (sabbatical, not receiving bugmail)]

Wow, very interesting indeed that you would file this since I was looking at the
MathML DOM last night and considering this very issue...  I don't think it
wouldn't be that difficult to do really.  Just time consuming.

This should probably be treated as a meta bug.  The initial hookups should
probably be done in this bug, and then specific implementations in other bugs.

Comment 2

[Fabian Guisset]

Just FYI, the DOMClassInfo MathML additions could (have to, actually) be done
using the new external DOMClassInfo registering methods. I agree it should be
easy enough to do, it's just really time-consuming to code everything.
For information on how to do pretty much everything, see the following docs:
http://mozilla.org/docs/dom/mozilla/xpcomintro.html (interfaces and implementation)
http://mozilla.org/docs/dom/mozilla/hacking.html (DOMClassInfo)
For MathML manipulations, see with rbs :-)

As Alex asked for required steps, here's what needs to be done on the DOM side:
- Write all the interfaces (IDL)
- Write all the cpp files implementing the interfaces
- Add external DOMClassInfo stuff
- Copy what SVG did to link to the main DOM (I don't know how they did it)

I don't know what is needed on the MathML side to have stuff work dynamically.

Comment 3

[Alex Vincent [:WeirdAl]]

Well, could we borrow the W3C IDL file for MathML 2.0?

http://www.w3.org/TR/2001/REC-MathML2-20010221/mathml-dom.idl

That would knock out step 1.

Comment 4

[Alex Vincent [:WeirdAl]]

http://gmetadom.sourceforge.net/

C++ implementation, beta status, MathML DOM included, and LGPL to boot.

I'm going to e-mail the project managers, see if we can get them involved here.
 Maybe they can tri-license it to us... :)

Comment 5

[Fabian Guisset]

I don't know how easy it would be to adapt that library to Moz since I can't
seem to get the code without CVS (no CVS access at the moment here). If someone
can grab the code for me I can give an estimate of what needs to be done to
convert it.
And yes the IDL files can be taken from the W3C spec, but they have to be
converted to XPIDL (i.e. split into multiple files, have the correct includes,
the correct types, ...)

Comment 6

[Alex Vincent [:WeirdAl]]

Here you go, Fabian:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gmetadom/

Their reply to me is polite, but to the point:  They're interesting in
"promoting" it, but not in actually implementing it themselves right now for
Mozilla.  (Almost their exact words; I can fwd my e-mail and their reply to
anyone interested.)  They're looking to promote it as a thesis for undergraduate
students (which, when you examine the context they develop MathML from, makes
sense).

Their e-mail implies no current support for MathML DOM in GMetaDOM.  I didn't
see any when I browsed over the filenames yesterday either.  Ah, well.

In a few days I mean to get myself a serious memory upgrade and even a C++
compiler.  I'll probably work on this bug personally just to learn how to do it
(Fabian, you'll get docs from me on building a DOM from scratch if you want
them).  I need to start learning C++ anyway, as there's a couple other bugs for
which I'm wanting results and waiting on a developer to be nice to me... ;) 
When I get that memory and compiler, I'll probably want to take ownership of
this bug, if rbs doesn't mind.

Comment 7

[Alex Vincent [:WeirdAl]]

Financial constraints prevent me from picking up VC++ 6.  That takes me out of 
the picture... :(

Comment 8

[Christopher Aillon (sabbatical, not receiving bugmail)]

As I said in comment #1, I've been interested in doing this.  I've already
looked through the SVG source and what they've done with the hookups, so I've
got an idea as to what exactly needs to be done.  That said, I'm not exactly
going to rush into this, but since I plan on using a fair amount of MathML in
the near future, I do want this feature myself so I'll take this bug.  The only
thing I need now is time.  Definitely not getting done in the 1.1 time frame,
but optimistically targetting for the 1.2 time frame.

Comment 9

[Fabian Guisset]

Alex: "Get a real OS!" ;-)
Great that caillon picked this up, thanks man :-)
Too bad about GMetaDOM but the mozilla code is so specific that I think it would
have taken a long time to adapt it anyway. Go Mozilla!

Comment 10

[steve.swanson]

Most of the MathML DOM can be done via XBL. AFAIK all the attributes and 
methods can be implemented.  You wouldn't be able to get the nodes named 
correctly (eg. JS would see Element instead of MathMLElement), but that 
doesn't seem especially important.

I made a little experiment implementing MathMLElement and 
MathMLFractionElement.  Works fine.  Inheritance happily works in XBL. 
Implementing most other elements would simply be a matter of typing in the 
obvious code.

The obvious way to attach the bindings is via mathml.css.  However, when I 
tried this I got "Error: uncaught exception: Permission denied to call method 
Element.getAttribute" so it's not as easy as I hoped.  But there must be a way 
since XBL binding is done for other things.

The main reason I haven't gone ahead and finished the MathML DOM is that I 
have some problems with the spec.  In particular:
1. The spec. ignores the possibility of whitespace nodes.
2. The spec. lets you add/remove arguments even if this creates invalid markup.
3. The spec. gives no access to computed attributes like scriptlevel.

Comment 11

[Christopher Aillon (sabbatical, not receiving bugmail)]

Steve, although it's probably possible to do it in XBL, there are some
shortcomings to doing so.  The main reasons are that XBL is bloatful and not
very performant.  This can potentially hurt us big with MathML where you need so
dang many nodes just to do simple things.  I contend that we should stick to C++
for this unless XBL gets some major work done on it, and even then, it may still
be wise to use C++.  You should see how picky people get about millisecond
differences in anything that JS uses :-)

Comment 12

[Hixie (not reading bugmail)]

Unlikely that caillon will get to this any time soon

Comment 13

[Daniel Kraft]

Currently I'm working on this. If you are interessted in that, look at bug 276267.

Comment 14

[Daniel Kraft]

A testcase for all the MathML-DOM would be nice! Does anybody know one? (Or
wants to implement it?)

Comment 15

[Vlad Sukhoy]

Taking over the bug to avoid any confusion and work duplication, I'm working on
this as a part of Summer 2007 MathML DOM project. WIP patches will be
posted onto bug 377499. Test cases for MathML DOM are also being developed.

Comment 16

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

Are there still people interested in getting an implementation of the MathML DOM? roc suggests WONTFIX for this bug and I agree with him, at least while nobody has given a strong argument for such an implementation. It seems to me that the MathML DOM is basically just adding notation shortcuts for the general DOM APIs. I'm not even sure that using these shortcuts in javascript code is more efficient than using the general DOM.

BTW, the MathML DOM has been removed from MathML3:

"The chapter and appendices relating to the MathML DOM have been removed from this specification, with the intention of updating them and publishing them as a separate document at a later time."

http://www.w3.org/TR/2010/PR-MathML3-20100810/appendixf.html#changes.mathml2.0e-3.0

So if we decide not to implement the MathML DOM, I think it would be a good idea to indicate Mozilla's position on the W3C Math mailing. If nobody complains, maybe the Math WG won't have to bother with adding back the MathML DOM and we can just get rid of it.

Comment 17

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

I agree with WONTFIX, especially since, AFAICT, no other browser supports it. The MathMLElement interface looks like it could be somewhat useful, but I can't really imagine using the others (and I don't think we should be cherry-picking features from specs either).

Comment 18

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

Marking bugs related to MathML DOM as WONTFIX.