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.

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.

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.

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.

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

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

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.

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

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.

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!

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.

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 :-)

Unlikely that caillon will get to this any time soon

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

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

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.

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.

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

Marking bugs related to MathML DOM as WONTFIX.