Input MathML Extension for Content MathML

[fred-wang]

I've created a content-mathml branch to add support for Content MathML (as usual, changes are only on the unpacked version). To load the extension, you must add

 MathML: {
    extensions: ["content-mathml.js"]
 }

to your config file. The extension essentially adds a prefilterHook to the MathML input Jax: the script content is parsed, transformed by David Carlisle's XSLT stylesheet and serialized again (so that other prefilterHooks and the MathML input Jax can handle it later).

This seems to work well on all Opera, Chrome, Firefox and Safari. On Internet Explorer I had to use their non-standard ActiveX-based methods. On IE9, there is an issue with self-closing tags: the script content is already corrupted so I think that's a general problem with the interpretation of self-closing tag in HTML5.

The changes are:
https://github.com/fred-wang/MathJax/compare/fc7aa04...content-mathml

Two questions:

• do we want to load this extension automatically when content MathML tags are detected (e.g. if the source contains <apply> tag)?
• should the stylesheet be applied when MathPlayer is installed?

[leathrum]

I am pleased to see this work happening -- I had recently tried a few experiments with CMML as an input mode for MathJax myself, unsuccessfully. I was trying to build my scripts based on work I had done several years ago on an abbreviated content syntax ("content pseudo-TeX," see http://cs.jsu.edu/~leathrum/mathtrans/article.xml). I think part of my problem was that I was expecting to still use XMLHttpRequest to load the XSLT, and that wasn't working well with MathJax. Which leads me to a question: I notice in your code that you put the whole XSLT stylesheet into the ctopStylesheet variable as one (very long) string, and that seems at odds with how the stylesheet should be used, is there a way to set it up as a separate file? Having the stylesheet separate would allow MathJax to adapt its content rendering for variations in notation between different locales (the classic example being the difference in notation for open and closed intervals between US and Europe). I know there is other work going on to localize MathJax menus and messages, so not allowing this stylesheet to localize would seem to clash in principle with that other project. Also, I recall when I was using David Carlisle's ctop.xsl for my content pseudo-TeX work (this is about 6 years ago now), I found a lot of little problems with the stylesheet, such as how it handled multiple derivatives -- I haven't checked the more recent versions of the stylesheet, but I would caution you to check all of the transformations with some sort of torture test for possible issues.

Regards,
Tom Leathrum

----- Original Message -----
From: "Frédéric Wang" notifications@github.com
To: "mathjax/MathJax" MathJax@noreply.github.com
Sent: Thursday, March 7, 2013 4:40:44 AM
Subject: [MathJax] Input MathML Extension for Content MathML (#404)

I've created a content-mathml branch to add support for Content MathML (as usual, changes are only on the unpacked version). To load the extension, you must add MathML: {
extensions: ["content-mathml.js"]
}

to your config file. The extension essentially adds a prefilterHook to the MathML input Jax: the script content is parsed, transformed by David Carlisle's XSLT stylesheet and serialized again (so that other prefilterHooks and the MathML input Jax can handle it later).

This seems to work well on all Opera, Chrome, Firefox and Safari. On Internet Explorer I had to use their non-standard ActiveX-based methods. On IE9, there is an issue with self-closing tags: the script content is already corrupted so I think that's a general problem with the interpretation of self-closing tag in HTML5.

The changes are:
https://github.com/fred-wang/MathJax/compare/fc7aa04...content-mathml

Two questions:

* do we want to load this extension automatically when content MathML tags are detected (e.g. if the source contains <apply> tag)? 
* should the stylesheet be applied when MathPlayer is installed? 

—
Reply to this email directly or view it on GitHub .

[fred-wang]

Thanks for the feedback Thomas. Yes, I think you are right that the stylesheet should really be in a separate file. Using this that way was how David implemented it in his Greasemonkey script, I think to avoid security issue or something. In the Firefox ctop extension (where we have more privilege) I used XMLHttpRequest to load the stylesheet. I don't know how it will work with MathJax and with the IE particularities. But it's worth trying it.

At the moment, I don't really plan to modify or improve David's stylesheet. The idea was just to propose a small feature for people that need Content MathML. Probably, if we have to do the same for other XSLT stylesheets a more general approach is needed.

[fred-wang]

Just read the MathJax.Ajax doc again:

http://docs.mathjax.org/en/latest/api/ajax.html

At the moment, only js and css files are allowed. So perhaps we could generalize that to allow "XML" or "string" return values like in XMLHttpRequest (I think the Internet Explorer's XSLT methods have string input/output while the other browsers have DOM input/output)

Alternatively, perhaps it is possible to use XMLHttpRequest but I believe the callback of the request must itself push a callback into MathJax.Hub.Queue, so that the action remains synchronized with MathJax.

[dpvc]

XMLHttpRequest is subject to the same-origin security policy, so you could snot use this to obtain fils from the CDN for example. I'm not sure if the access-control headers could be used in that case or not. In any case, the reason that the current Ajax code is restricted to javascript and css is that those are things that can be obtained through script and link tags without security problems.

On the other hand, you could make a javascript file that simply contains the string you want and load that. I guess that is Fred's first suggestion?

Davide

On Mar 8, 2013, at 4:01 AM, Frédéric Wang wrote:

Just read the MathJax.Ajax doc again:

http://docs.mathjax.org/en/latest/api/ajax.html

At the moment, only js and css files are allowed. So perhaps we could generalize that to allow "XML" or "string" return values like in XMLHttpRequest (I think the Internet Explorer's XSLT methods have string input/output while the other browsers have DOM input/output)

Alternatively, perhaps it is possible to use XMLHttpRequest but I believe the callback of the request must itself push a callback into MathJax.Hub.Queue, so that the action remains synchronized with MathJax.

—
Reply to this email directly or view it on GitHub.

[fred-wang]

Well, I think Thomas' proposal was to move the XSLT stylesheet in a separate file (and to load it directly with XMLHttpRequest) so that one can easily customize the XSLT stylesheet. I think you mean putting it in a Javascript file and still continue to use a string variable? That will just separate the XSLT content from the extension file, but still one will have to "convert" its custom XSLT into the appropriate JS string format (not hard, but still an additional work).

One small advantage of David Carlisle's "compressed" version is that the string takes less space and so the XSLT can be loaded a bit faster.

[dpvc]

Yes, I know that was Tom's suggestion. But that would restrict its use to same-origin domains or those with the ability to change the access control (if that works). Yes, my suggestion was to keep it as a javascript string, but one that can be loaded separately. The name of the file that is loaded could be a configuration parameter so that authors could replace that with their own.

An alternative that allows cross-domain loading is to use a hidden iframe that loads a page from the other domain, and that page uses XMLHttpRequest (now to the same domain) to load the data, and then the inter-window message-passing mechanism (postMessage) to give the data back to the main window. Complicated, and we don't currently have it in the code base, and also requiring a helper page in the remove domain, but it could be done.

I don't know how XSLT style sheets work; how are they usually loaded? Can we load one by adding a <link> tag to the document head, like we load CSS style sheets?

[fred-wang]

I don't know how XSLT style sheets work; how are they usually loaded? Can we load one by adding a tag to the document head, like we load CSS style sheets?

That's also what I imagined. I think you can specify a link in an XML document using a PI . Currently, my code just use the browsers' XSLT processor interface.

[leathrum]

Fred is right, the usual way to apply a standalone XSLT stylesheet is with a tag in the header of an XML document. That won't work in the context MathJax uses, working with an HTML DOM. No, HTML tags don't work for XSLT. However, the doc at this link from MDN might give some insight:

https://developer.mozilla.org/en-US/docs/Using_the_Mozilla_JavaScript_interface_to_XSL_Transformations

This suggests loading the stylesheet into an empty document-level element in the DOM via an onload handler. This might work for MathJax. The page doesn't mention same-domain restrictions, so I don't know whether that will be an issue or not.

----- Original Message -----
From: "Frédéric Wang" notifications@github.com
To: "mathjax/MathJax" MathJax@noreply.github.com
Cc: "Thomas Leathrum" leathrum@jsu.edu
Sent: Friday, March 8, 2013 5:51:42 AM
Subject: Re: [MathJax] Input MathML Extension for Content MathML (#404)

I don't know how XSLT style sheets work; how are they usually loaded? Can we load one by adding a tag to the document head, like we load CSS style sheets?

That's also what I imagined. I think you can specify a link in an XML document using a PI . Currently, my code just use the browsers' XSLT processor interface.

—
Reply to this email directly or view it on GitHub .

[leathrum]

I tried the method suggested on the MDL page, and Firefox gave me an error saying that the method was deprecated in favor of XMLHttpRequest. I then tried the iframe method that Davide suggested, and it worked just fine with an XSLT. So I think that may be the way to go. So in the case where you have XSLTProcessor, something like this should work:

MATHML.ctopXSLT = new XSLTProcessor();
xsliframe=document.createElement("iframe");
xsliframe.onload=function(){
MATHML.ctopXSLT.importStylesheet(xsliframe);
};
xsliframe.src="ctop.xsl";

Note that the call to importStylesheet() no longer needs MATHML.ParseXML() inside it. I haven't looked closely at the alternatives for IE, but something similar should work there, too.

----- Original Message -----
From: "Tom Leathrum" leathrum@jsu.edu
To: "mathjax/MathJax" reply@reply.github.com
Cc: "mathjax/MathJax" MathJax@noreply.github.com
Sent: Friday, March 8, 2013 10:39:11 AM
Subject: Re: [MathJax] Input MathML Extension for Content MathML (#404)

Fred is right, the usual way to apply a standalone XSLT stylesheet is with a tag in the header of an XML document. That won't work in the context MathJax uses, working with an HTML DOM. No, HTML tags don't work for XSLT. However, the doc at this link from MDN might give some insight:

https://developer.mozilla.org/en-US/docs/Using_the_Mozilla_JavaScript_interface_to_XSL_Transformations

This suggests loading the stylesheet into an empty document-level element in the DOM via an onload handler. This might work for MathJax. The page doesn't mention same-domain restrictions, so I don't know whether that will be an issue or not.

----- Original Message -----
From: "Frédéric Wang" notifications@github.com
To: "mathjax/MathJax" MathJax@noreply.github.com
Cc: "Thomas Leathrum" leathrum@jsu.edu
Sent: Friday, March 8, 2013 5:51:42 AM
Subject: Re: [MathJax] Input MathML Extension for Content MathML (#404)

I don't know how XSLT style sheets work; how are they usually loaded? Can we load one by adding a tag to the document head, like we load CSS style sheets?

That's also what I imagined. I think you can specify a link in an XML document using a PI . Currently, my code just use the browsers' XSLT processor interface.

—
Reply to this email directly or view it on GitHub .

[fred-wang]

Thanks for looking into that. That would be helpful if you could try on IE too, as I'm a bit less confident about this browser :-)

[leathrum]

Working on IE is quite difficult for me these days -- I have gone over almost entirely to either Linux or Android, with occasional forays into iOS. My kids still have Win7 laptops....

----- Original Message -----
From: "Frédéric Wang" notifications@github.com
To: "mathjax/MathJax" MathJax@noreply.github.com
Cc: "Thomas Leathrum" leathrum@jsu.edu
Sent: Wednesday, March 13, 2013 4:00:32 AM
Subject: Re: [MathJax] Input MathML Extension for Content MathML (#404)

Thanks for looking into that. That would be helpful if you could try on IE too, as I'm a bit less confident about this browser :-)

—
Reply to this email directly or view it on GitHub .

[pkra]

@leathrum you can use VMs in virtualbox that MS provides for free, see https://github.com/xdissent/ievms

[fred-wang]

I created a content-mathml-2 branch to experiment the iframe idea but this does not work very well on Chrome (iframe can not be treated as XML?) and Internet Explorer (needs to serialize the document? does not parse the original ctop.xsl stylesheet?). I haven't tried to use XMLHttpRequest from the iframe, but I guess that will be the same issue with Internet Explorer (although I've seen somewhere an alternative approach to parse XSLT using XMLHttpRequest rather than strings). I have a virtual machine with Internet Explorer, but it is very slow and that's not convenient to test IE for me either.

[fred-wang]

I added a basic test to check the extension:

MathMLToDisplay/Content/issue404.html

For the goal we discussed on the mathjax-dev mailing list (just a small feature to load David Carlisle's stylesheet) I believe this is enough. Of course, a more complete set of tests is welcome if later we really claim to support Content MathML.

=> In Testsuite

I still don't really like the hardcoded string. I guess the only other option is the XMLHttpRequest from the iframe, if that works with IE's XSLT interface.

[fred-wang]

For the goal we discussed on the mathjax-dev mailing list

Just for the record, the discussions about v2.2 are:
https://groups.google.com/forum/#!topic/mathjax-dev/9b4I0UB5Idg
https://github.com/mathjax/MathJax/wiki/Mathjax-v2.2-feature-discussion