History of MathML

Input for Computation

The question of how to input mathematical expressions, equations, and formulas is as old as computers are. The first computers were built to carry out scientific calculations, and early computer languages were designed to simplify the process of translating mathematical formulas into computer-interpretable form. The early language FORTRAN was even named after this task: FORmula TRANslation.

Since input and output on early computers were limited to simple sequences of letters (punch cards or teletypes, for example), it was natural to use a simple linear syntax such as 1/(2+a**2) to represent .

The fundamental notion behind these languages was to use the available simple text editors (or card punches) to build up input expressions (programs) one letter at a time. Then, when you were happy with your input, you would submit it to the system, which parsed it according to the rules of the language and created an internal representation in which unique interpretations were assigned to each part of the expression (for example, "power" as the interpretation assigned to a**2).

Input for Display and Printout

Almost as soon as computers had the capability, people started inventing languages to allow them to create printed, typeset mathematical expressions (along with typesetting the text around the expressions).

TeX was a system that became very popular with academic users for writing research papers and books, and the SGML standard ISO 12083 was used by many publishers.

In these languages a linear text syntax is used to describe the mathematical expression, and the intention is always to display or print the expression and not to perform calculations with it. Because mathematical typesetting involves only a very limited number of concepts (superscript, subscript, vertical and horizontal stacking, a set of special letters, and a few odd-ball notations like square roots), mathematical typesetting languages can be fairly simple. The only real complexity comes about in naming the large number of special symbols (Greek letters, Hebrew letters, integral signs, etc).

Eventually, interactive graphical editors were created. These editors used palettes and menus to allow the user to interactively construct typeset expressions, which could then be saved in Tex or similar formats. Again the goal was always just to format and not to compute.

Typeset Input for Computation

As computers became more powerful and graphical displays became common, you might have expected some kind of convergence in which 2D typeset mathematical expressions could be used as input for computational systems. But by and large this did not happen. There were several systems for creating and printing typeset mathematical expressions, and there were several systems for doing mathematical calculations (numerical and symbolic), but there were (and still are) remarkably few that combined 2D typeset input with computation.

One reason for this is that languages like TeX and ISO 12083, because they were intended strictly for typesetting, did not represent mathematical expressions in a particularly mathematical way. For example, in TeX it is typical to represent the dx portion of an integral such as:

as simply the characters "dx". It is very difficult for a computer system to unambiguously differentiate between this being "differential operator x" vs. "variable d times variable x" vs. "variable named dx".

These kinds of ambiguous, difficult-to-disentangle syntaxes pervade TeX and ISO 12083, making them entirely unsuitable as input languages for computer mathematics systems.

Another reason linear syntaxes remained the preferred form of entry for computation was that early interactive 2D input systems were much more cumbersome and time consuming to use than the linear syntaxes that they might have replaced. Typing 1/(2+a**2) took much less time than using the large palettes and confusing submenus of the typical interactive 2D math input system. So users who were interested just in getting calculations done didn't want to bother with typeset input, and understandably so.

While there were several factors that made these typesetting systems cumbersome, one of the most important was that they were fundamentally not based on a parsing model. Instead of allowing the user to build up a complex expression by assembling a small number of simple building blocks, as linear syntaxes did, these systems essentially required the user to assign the interpretations manually, choosing them from large palettes one at a time.

The fixed template-based model of these typesetting systems also made editing quite difficult because it did not allow intermediate states that might not be valid input but that are very convenient ways of getting from here to there in the editing process.

An analogy could be made between template vs. parsing-based systems and pictographic vs. alphabetic written languages. An alphabetic language, in which words are built up (parsed) out of a small number of letters, allows for significantly more convenient input (by way of a suitably sized keyboard) than do pictographic languages in which, roughly speaking, each word is given a separate icon that must be selected from some kind of palette. Without meaning any disrespect to the great and ancient cultures whose languages are pictographic, the fact is that alphabets are faster for computer input--and the same is true for mathematical expression input.

How to Get out of This Impasse

The solution to practical typeset input for computation was to combine the simplicity of typesetting-oriented languages with a 2D parser that is able to translate the essentially graphical description provided by the input language into an expression that can be interpreted mathematically. It turns out that this requires only a very small number of accommodations in the form of disambiguating notations in the language. For example, it's necessary to use a special "d" character for the differential operator, rather than the ordinary "d" character that would be used as a variable name. Consider:

Pity the poor computer system asked to interpret this if the two "d's" are represented by the same character, as they would be in TeX, for example.

The realization that it actually was possible to use a simple, parsable graphical syntax as input was the great, and to this day unique, innovation of Mathematica's 2D math input system. Instead of large complex palettes, a very small number of simple structural operations is used to build up complex expressions, and free-form editing is allowed at any stage. When it comes time to evaluate the expression, the system parses the 2D structure using a comprehensive set of rules to assign unique interpretations to all of the structures, just as is done when parsing a linear syntax.

The Mathematica editing model, which is more like a text editor than like other mathematical expression editors, allows efficient, convenient input of expressions using no more keystrokes, and often fewer, than linear syntaxes use. And the fact that typeset expressions in Mathematica are represented by building up a small number of simple "boxes" allows tremendous flexibility and extensibility without unnecessary complexity.

The Origins of MathML

There was a danger during the 1990s that a standard would emerge for mathematical representation on the web that would be based on a TeX- or ISO 12083-like typesetting language. This would have been disastrous because it would have precluded, or made far more difficult, meaningful computational interaction with mathematical expressions found on the web.

We felt that it was terrifically important that the user be able to copy/paste a mathematical expression found anywhere on the web into a computer mathematics system and have a reasonable expectation of being able to evaluate it (say, make a plot of it, integrate it, etc). We also felt that there was a significant danger of the standards evolving in a way that would make this impossible.

To head off this possibility, Wolfram Research and Neil Soiffer decided to do everything they could to encourage the creation of a practical standard that would actually be used by web browser manufacturers and that would preserve the possibility of evaluation in mathematical systems.

We realized that if a mathematical markup language were ever to be supported by web browser manufacturers, and if it were ever to be practical as a universal interchange format, it would have to be based on a very simple set of fundamental constructs. If it were to be computable, it would also have to incorporate the very set of disambiguating notations we had developed for our own typesetting system. Finally, we knew that it had taken many years of work by our top experts in the field to come up with a really good way of unambiguously specifying mathematical notations using a simple graphical syntax. We decided that we needed to use our experience to guide the development of a standard that would work for the world.

And so, Neil Soiffer and Bruce Smith of Wolfram Research were founding members of the drafting committee and creators of the original proposal upon which MathML was based. The key ideas forming the core of the MathML standard are derived directly from Wolfram Research's typesetting technology.

The Committee Process

Taking a proposal from first draft to an accepted World Wide Web Consortium (W3C) official recommendation is a long and arduous task. From Soiffer's first draft to the current MathML 2 W3C Recommendation required about a dozen face-to-face meetings and about two hundred teleconferences between the 15 to 20 committee members. Presentation materials are available from the second conference, held in 2002.

The first official MathML conference, sponsored by Wolfram Research in October 2000, proved by its almost two hundred attendees that the effort to create a good standard had been worthwhile.

Throughout the process Wolfram Research has been actively involved, always with an eye to making sure that the standard remains usable and suitable for automatic interpretation by computer mathematics systems.

As we see it, there are two fundament goals for the MathML standard: (1) that web browser manufacturers find it practical to implement, or at least support the implementation of, robust and well-integrated MathML renderers in their browsers and (2) that the standard be one in which it is possible to uniquely represent mathematical meaning in such a way that computer programs can read, parse, and evaluate expressions represented in MathML without ambiguity.

Only by achieving both of these goals can the MathML standard promote, rather than hinder, the widespread presence on the internet of interpretable mathematical expressions. We feel that through the work of Neil Soiffer and others at Wolfram Research, the standard has achieved both goals admirably.