Max Froumentin
One year after MathML2 became a Recommendation, it is beginning to be in use by mathematicians who need it as an interchange format between mathematical software. However MathML is starting to make it on browsers, for displaying equations on the Web. This may seem a bit late to some, but as David Carlisle reminded, TeX took more than 10 years to becomethe de facto scientific document typesetting system. This report is an attempt at summarising what has been presented at the MathML Conference on 29-30 July 2002.
The most important challenge MathML is currently facing is browser adoption. Much progress has been made, though, as modern browsers can display MathML on most platforms. Either as plug-ins for Internet Explorer (Design Science MathPlayer, or techexplorer), or natively, as part of the browser implementation (Mozilla/Netscape7, Amaya).
However because different architectures required different syntaxes, a single page containing MathML would only render in the browser it was designed font. Obviously a major problem for worldwide adoption. David Carlisle from the Math Working Group remedied to that situation with his Universal MathML Stylesheet, presented below.
Effective conversion from other mathematical formats is also very important for the adoption of MathML. In particular, since most of today's scientific papers are written in TeX or LaTeX it is of great interest to be able to transform a document typeset in TeX/LaTeX to MathML for display on a Web page. Few tools exist yet, but they are getting better. Most of the big mathematical computation engines (Wolfram Mathematica, Waterloo Maple) import and export both TeX and MathML, but also a few specialised tools exist, such as ORCCA's on-line converter, itex2mml, TtM or TeX4ht. Ivor Philips (Boeing) and Stan Devitt (Stratum Technical Services) demonstrate some of those within a TeX translation environment, with an emphasis on the user's point of view, in particular regarding migration cost. They show use cases at Boeing, where a lot of documents is stored in many different formats. Moving from these formats to MathML would be a costly investment, and therefore it is not enough to say that a particular translator "works". With TeX in particular it is deemed impossible to have a TeX translator that will manage every possible equation, therefore a translator should specify the particular subset of TeX is supports, and a potential user should evaluate the cost of aligning to that subset.
MathML to TeX conversion is also investigated: Elena Smirnova from ORCCA shows how transforming to TeX does not necessarily mean losing MathML's higher level of semantics, and that in certain cases roundtripping is possible. Conversion projects that target different formats also exist: Marc Gaëtano from Université Nice-Sophia Antipolis presents a renderer that turns Presentation MathML to SVG, providing a new way to enable MathML in browsers. Clifford Johnston from West Chester University shows another conversion method, this time from the text format used on TI scientific calculators.
Mathematics is a good test case for Web services. A simple example is a powerful computer system that can factor big numbers and which offers that as a Web service: a client just sends a number to be crunched, and later receives the results over the Web.
Tom Wickam-Jones from Wolfram Research shows webMathematica, a service
that one can call to perform Mathematica operations remotely, returning
results in different formats, such as plot as images, SVG, 3D plots through a
java application on the client, or mathematica files, built on-demand on the
server and sent over. The service is called through an HTML form containing
Mathematica code enclosed within a <%mathlet> tag (yes, it
is not XML), or MathML.
Paul Mansfield and Laurent Bernardin, from Waterloo Maple, demonstrates MapleNet, a similar service with will come with a welcome feature: the use of SOAP to encode requests and replies. The request is written in a Maple session running on the client, which build a SOAP message containing the request encoded in MathML. Another alternative is to directly edit the request in Mathml using Design Science's webEQ, which allows the service to be called without a local copy of Maple. The use of SOAP and other protocol standards allows us to envisage a cross software use of MathML Web services, such as calling a webMathematica service from Maple or any other mathematical Web service.
A piece of MathML is not easy to read or write. Unlike with TeX, people will probably not want to write their mathematics in the XML markup directly. While convertors leverage the problem, another important means to address the issue is to provide editing tools (hopefully WYSIWIG) that allow simple user input. In this area too, many products are presented at the conference:
Design Science's tools can take a web page with MathML and send the MathML contents to their editor or other tools in order to change the document live. Sam Dooley from IBM demonstrates techexplorer and Expression Editor, which unlike other tools, uses Content MathML for editing formulas. Both only work using IE and object tags, ActiveX controls, COM, and other Windows centric mechanisms. [Correction: Design Science's WebEQ is in fact written in cross-platform Java and is available on many platforms]. MathML seems like an island on a sea of non-standard technologies, but it's a good start to use it. Fortunately other products are better web citizen: W3C's amaya which completely integrates the equation editor within the XHTML editor, and also mathmled by Steve Swanson, another equation editors built on top of Mozilla's DOM. Of course both aren't as fancy and powerful as what IBM or Design Science show us. Nevertheless, when it comes to saving for publication of mathematics on the Web, all tools correctly save XHTML+MathML with David Carlisle's stylesheet PI for (almost) universal viewing.
A related topic is mathematical Web repositories based on MathML. Two rather impressive frameworks are shown: Connexions, presented by, Bret Hendricks from Rice Univeristy, which aims at creating a shared repository of coursework based on CNXML, a lightweight document markup language in which MathML can be embedded. Within the remarkably similar CCAPS project, Michael Kohlhase shows how legacy content in Mathematica notebooks or PowerPoint can be converted to the Content-MathML based OpenMath Document format. Again, unification of such frameworks would be more than welcome.
MathML is also appearing on new types of devices, in particular PDAs and other calculators. Stephen Watt presents ORCCA's work on handwritten recognition of equations: "Math is a killer app for handwriting apps." Indeed, mathematics is an area where handwriting is a lot faster than keyboard or mouse input. However it is more prone to ambiguities than standard text recognition, due to the intrisically two-dimensional layout of equations. Moreover, applying handwritten math recognition techniques to PDAs is even trickier than working on standard PCs, as everything is obviously much smaller: computing power (and handwriting recognition requires more than one would expect), input area as well as display. On the rendering front, Luca Padovani, also from ORCCA, talks about the PocketMathML project, which aims at providing an architecture for rendering mathematics on a wide variety of target media, with different rendering capabilities.
Extensions to MathML are also presented: Hanane Naciri from INRIA presents use-cases for mathematics in arabic texts, where equations can be displayed from left to right (as is done in Morocco) or from right to left (as is done in Egypt). MathML does not address the latter case, so INRIA's FIGUE project aims at defining new display rules for this particular case. Bill Naylor, from ORCCA, presents extension to the Presentation MathML syntax, in order to remove ambiguities or add information to elements of variable size (such as vectors) and thus provide an easier mapping to OpenMath.
David explains the problems in putting mathematics on the Web: IE's
plug-ins require <object> or <embed>,
Mozilla and Netscape 7 do it right with the <math
xmlns="http://www.w3.org/1998/Math/MathML"> element embedded within
XHTML. Thus an author cannot put one web page with MathML for use with
everyone, they have to have one different page for each browser that will be
reading this. The solution David devised (nicknamed the "Universal MathML
stylesheet") is an browser-side XSLT stylesheet that, applied to a
XHTML+MathML document in either form, transforms it to whatever syntax the
browser understand. It can even render MathML on plugin-less IEs, using CSS.
And he goes on to show what this yields by showing the same page displayed
correctly in IE6, Mozilla and Amaya. Apparently a little achievement in this
age of compatibility and interoperability but a great leap for the adoption
of MathML.
However some problems remain, the biggest of which is Internet Explorer 6's failure to display the mathematical symbols residing in the Unicode Plane-1 character set, not only not displaying them but rejecting the whole document. Microsoft have announced a fix for the next release, but is has been almost a year now.
David finishes by explaining how a similar XSLT stylesheet could be
written for SVG, again solving the <embed> vs. inline SVG
problem encountered in the Adobe SVG Plug-in.
Roger Sidje singlehandedly wrote the MathML renderer in Mozilla, and now also in Netscape 7 (Preview Release 1). He does not work for AOL/Netscape, and so is a perfect example of successful distributed Open Source development. Roger shows impressive stuff: pages with hundreds of nicely rendered mathematical expressions, including equations where the symbols are images (<html:img> embedded within MathML). He also demonstrates Steve Swanson's Mozilla-based MathML editor and then goes on to enumerate Mozilla's Building Blocks, i.e. the standards that the browser supports, notably: HTTP1.1, XHTML1.0 and1.1, MathML2, CSS 1,2 and 3, DOM (visible with Mozilla's DOM Inspector), RDF and P3P. SOAP support is also mentionned, and Roger underlines the "missing" link between Mozilla's SOAP and mathematical web services such as webMathematica or Maplets. He ends up reminding that Mozilla's licence allows anyone to include the code in their proprietary software for free and that it doesn't force people to make their derived products open source.
Lamport, who not only wrote LaTeX in 1985, but is also an esteemed researcher in parallel processing, talks about something more general than MathML: the quality, and in particular clarity, of mathematical notation. The presentation starts with a history of writing mathematical proofs, from 17th century prose (amusingly similar to today's writing of patents) to current typography of math formulas and the use of the idiosyncracies of the computer as a media (links, foldable documents, etc.). The second part presents how a computer-based cleaner style of writing proofs should make it harder to publish incorrect results, or make it easier to check proofs. Finally, Lamport forecasts that "In 2010 proofs will be on-line, annotated with intuitive explanations but will still need to be reduced on paper."