[* Note: Much of the material in these sections also appears in the documentation page for the translator applet.]
This article uses MathML, so it requires a MathML-enabled browswer, such as Firefox 1.5 or later (check to be sure you have the math fonts installed) or Explorer with the Design Science MathPlayer plug-in.
If you can read the math notation in this article, you will be able to read the documentation page above -- it also uses MathML. The translator applet requires a browser with a Java 5 runtime environment. The translator applet page uses some special XML and DOM coding in JavaScript to accomplish "live" rendering of the Content MathML -- this code, which complies with W3C recommendations, works in Firefox but not in Explorer. The translator works without the live rendering in Explorer, though.
Update (Sept. 2010): The translator code has been rewritten in JavaScript, so the Java runtime environment is no longer necessary.
This article introduces the Content Pseudo-TeX translator applet. The applet was designed as a tool to simplify writing Content MathML for web pages. The applet takes input in a "TeX-like" syntax and translates it into strict Content MathML which can be cut and pasted directly into pages. This article begins by describing the motivation for designing the applet, then gives the basic elements of the input syntax, with examples, limitations, and recommendations for further work.
The W3C's proposed (but so far only sporadically accepted) standard for presenting technical mathematics formulas in Web pages is MathML, a mark-up language based on the very broad standard known as XML, the eXtensible Mark-up Language. MathML is divided into two "flavors," Presentation MathML and Content MathML.
Presentation MathML, as its name suggests, is concerned mostly with how mathematics formulas are rendered in a Web browser, so its elements have mostly to do with the positioning and layout of the various operators, identifiers, and other elements of a mathematical formula. As such, it carries some inherent limitations, having mostly to do with how notation for the same mathematical entity can differ between different contexts.
Perhaps the easiest way to see these limitations is to consider how mathematical notation can differ between countries or regions. One straightforward example is the notation for intervals of real numbers. In the United States, the usual notation for a closed interval of real numbers from a to b is "[a,b]," and an open interval is "(a,b)." In most of Europe, Africa, the Middle East, and India, however, an open interval is written "]a,b[."
Ideally, an author would like to set up the MathML in such a way that a local stylesheet can be applied to give the appropriate notation for that region. Stylesheet languages, such as CSS or the newer XSLT, are quite powerful, but there are again limitations in what a stylesheet can accomplish. If Presentation MathML is used, the stylesheet must try to interpret what is given as layout information in a mathematically meaningful way in order to decide how to transform the notation. Consider, for example, the ambiguity in American notation for open intervals, as in "(a,b)," and ordered pairs, as in "(a,b)." How is a stylesheet, given only this layout information, to decide which of these is intended by a particular segment of mark-up?
The other flavor of MathML, Content MathML, is designed to address these issues by describing mathematical entities semantically rather than in terms of layout and presentation. In the above example, an open interval is described in Content MathML as an "interval" object of type "open," with given endpoints. This way, also, there is no ambiguity in the notation between an open interval and an ordered pair -- an ordered pair is described as a "list" object with two entries.
Content MathML is implemented via an XSL stylesheet which maps the Content MathML tag set to Presentation MathML, which is then given to the browser for rendering. This stylesheet may be specific to particular countries or regions, thus automatically rendering the notation for open intervals correctly for the region for which the stylesheet applies.
A MathML expression must be enclosed within a "<math>...</math>" environment, similar to using "$" or "$$" to delimit expressions in TeX, or the LaTeX environments "\(...\)" and "\[...\]." Within a "\<math>" environment, either Presentation MathML or Content MathML may be used, and in some circumstances the two flavors of MathML can even be mixed, although such usage tends to be limited to advanced applications.
In Content MathML, all identifiers, numerals, and symbols are enclosed within an environment: "<cn>...</cn<" for numerals (so you cannot simply write "2" in a Content MathML expression, you must write "<cn>2</cn>"), "<ci>...</ci>" for identifiers (the variable "x" must be represented "<ci>x</ci>"), and "<csymbol>...</csymbol>" for more advanced mathematical symbols (the contents of a "<csymbol>" environment are often Presentation MathML markup for the advanced symbol -- this is one of the ways in which Content MathML can be extended by mixing it with Presentation MathML). Content MathML does support several stand-alone tags to represent common mathematical symbols such as "<infinity/>" and "<pi/>."
More complicated expressions in Content MathML are composed using prefix notation, with the operator and its arguments expressly delimited within an "<apply>...</apply>" environment. This makes a certain sense for functions -- for example, "f(x,y)" would be expressed in Content MathML as follows:
f x y ]]>
Here the first child of the "<apply>" environment ("<ci>f</ci>") is the function "f", and the other children ("<ci>x</ci>" and "<ci>y</ci>") are the arguments to "f," in this case the variables "x" and "y." I refer to these as "children" because the whole point of using an XML-based syntax, as MathML does, is to represent expressions as trees -- here the "<apply>" environment provides the parent node in the tree, with the contents of the environment providing a list of child nodes.
This applied prefix notation in Content MathML may make sense for representing functions, but it is less intuitive for representing expressions more commonly written using infix operators, such as "x+y" -- this must be written in Content MathML as follows:
x y ]]>
Note here that the "<plus/>" entity, representing the addition operator, must be the first item in the list of children in the "<apply>" environment -- this is the prefix notation for addition. Content MathML supports a fairly wide assortment of such entities to represent common functions and operations in various fields of basic mathematics, including basic algebra (such as the "<plus/>" entity above), exponential and logarithmic functions (e.g. "<ln/>"), trigonometric functions (e.g. "<sin/>"), calculus (e.g. "<int/>"), statistics (e.g. "<sdev/>"), set theory (e.g. "<union/>"), and others, but these all must be used within the context of an "<apply>" environment. The intent of supplying these basic operations in Content MathML is to allow authors to represent essentially any of the expressions common in K-12 mathematics, and even a bit further (e.g. vector calculus, with "<div/>," "<grad/>," "<curl/>," etc.).
For certain operators, the list of children in the "<apply>" environment may include "qualifiers" to the operators. This is how, for example, bound variables and limits for integrals are handled in Content MathML. For example, the integral expression below:
This would be written in Content MathML as follows:
x 0 ]]> x
Here the environments "<bvar>" (for identifying the bound variable for the integral, i.e. the variable "x" for the "dx" part of the expression), "<lowlimit>" (the lower limit), and "<uplimit>" (the upper limit) are the qualifiers for the "<int/>" operator. This example also demonstrates how "<apply>" tags can be nested -- the inner "<apply>," containing the expression for "sin(x)," is the last child element in the outer "<apply>."
Some Content MathML tags also support "attributes" which can affect both the meaning and the rendering of the expression. One common example, following on the examples used earlier in this article, is the "<interval>...</interval>" environment. The opening "<interval>" tag can take a "closure" attribute to specify what sort of interval to represent. For example, the closed interval "[a,b]" would be written in Content MathML as follows:
a b ]]>
Some of the examples above begin to demonstrate the most serious drawbacks of Content MathML, though -- its excessive verbosity and unfamiliar notational conventions for representing even the most simple mathematical expressions. For example, the definite integral used in an example above can be computed fairly easily using basic calculus techniques -- its value is 2. Representing this equality using Content MathML now requires using the "<equal/>" entity, which must be used within the context of an "<apply>" environment, in prefix form, as follows:
x 0 x 2 ]]>
This same equality would be represented in TeX as follows:
\int_0^\pi \sin x\, dx = 2
Since Content MathML does have these problems which directly affect its usability and acceptance, it seems natural to ask if another mark-up notation for mathematical formulas would address these problems, and many authors of mathematics would immediately suggest TeX. As familiar as TeX may be for many people writing mathematics for Web pages, as a mark-up language for mathematical formulas, it presents many of the same problems as Presentation MathML. Indeed, especially in its syntax for formulas, it is an inherently presentation-oriented mark-up language. For one simple example, consider the "^" operator in TeX. In some contexts, such as "$x^2$," it is interpreted as an exponent; in other contexts, such as "$\sum_{n=1}^\infty\frac1n$," it can interpreted as specifying a superscript or upper limit. In American notation, this makes sense, since superscripts and exponents are rendered similarly, but semantically, superscripts and exponents are fundamentally different. A different regional notation may require one or the other to be rendered differently. As such, a strict TeX syntax for mathematical formulas will be inappropriate for content-level notation.
However, this does not imply that TeX-like syntax must be completely abandoned in developing a content-level notation. It simply implies that some compromises and adaptations of the TeX syntax must be accepted in order to reach a content-level notation with syntax familiar to TeX users.
The syntactic elements which a TeX author would find familiar must begin with the fundamental TeX backslash-escaped "macro" notation, as in "\sum," "\int," "\frac," and "\sqrt." Other syntactic elements in particular familiar to users of LaTeX would include square-bracket delimited optional arguments, as in "\sqrt[3]{x}," and environments using "\begin{identifier}" and "\end{identifier}."
Another important aspect for acceptance of any proposed content-level syntax would be support for infix notation applied to standard binary operators and relations. While the prefix notation with "<apply>" tags provides Content MathML with a very high-level approach to expressing mathematics by its meaning rather than by its layout, that notation is the primary cause of the excessive verbosity and unfamiliarity of its syntax.
To be fair, the "criteria" by which I developed the TeX-like syntax did go through some modifications as I worked on the details of the syntax and the software to translate to Content MathML. Initially, I just felt that I wanted to keep to a concise, TeX-like syntax which would map in a very general way directly to Content MathML, with as little reference as possible to particular MathML tag identifiers. In some aspects of the TeX-like syntax, this was pretty easy to achieve -- for example, a TeX-like environment "\begin{id}...\end{id}" could map directly to a Content MathML environment "<id>...</id>" without the software translator knowing anything about the "id" identifier. Similarly, "\id{...}" could map directly to "<apply><id/>...</apply>." The primary advantage of handling these translations without any particular dependence on the identifiers will be that the translation will still provide meaningful output for tags which are added to Content MathML in the future.
The standard infix notation for binary operators and relations
can be handled similarly -- for example, "x+y" can map
to "
The issues of syntactic translation become a bit more difficult
for Content MathML stand-alone entities such as
"<infinity/>"
(which generally do not appear as the first child in an
"<apply>"
environment), and for binary relations which do not have simple
keyboard equivalents, such as the TeX "\in" relation (as in
"$x\in A$"). These elements need to be treated differently in
the TeX-like syntax in order to map correctly into Content MathML.
I decided to handle these elements using different characters
to end a backslash-escaped macro identifier -- so, for example,
"\id;" maps to "<id/>"
(without any "<apply>" tags),
and "x\id|y" maps to
"
In Content MathML, "qualifiers" provide a mechanism for specifying
details about how an applied element is to be interpreted. For
example, the "<bvar>"
qualifier provides information about a
bound variable, as for an integral, so that
"
Finally, in MathML, "attributes" applied to the tags provide
additional information about the tags which can affect both
meaning and rendering. In particular, the "type" attribute
for many tags provides information about what the tag represents.
For example, the "<interval>" environment in Content MathML
supports the "closure" attribute, by which an interval can be
described as "open," "closed," or the mixed closures
"open-closed" or "closed-open." I couldn't find a truly
appropriate element of TeX-like syntax to represent these
attributes, so here I strayed even farther from standard TeX syntax.
I introduce attributes into the source syntax using the special
"@" character, so that
"\begin{interval}@open a b\end{interval}"
maps to "
[Note: Much of this section also appears in the documentation page for the translator applet.]
So ultimately I judged the design of the TeX-like syntax and its translation software by the following criteria:
[Note: Much of this section also appears in the documentation page for the translator applet.]
The resulting syntactic mapping scheme worked out as follows:
| Source: | Content MathML: |
| Source: | Content MathML: |
| foo(...) |
|
| \foo; | <foo/> |
| x\foo|y |
|
| x\foo@bar|y |
|
| &foo; | &foo;]]> |
| \foo{...} |
|
| \foo@bar{...} |
|
| \begin{foo}...\end{foo} | ... ]]> |
| \begin{foo}@bar...\end{foo} | ... ]]> |
Qualifiers are specified as given in the following table:
Attributes are specified using the special character "@" as follows:
| Element: | Attribute: | Allowed values: |
| cn | type | real, integer, rational, e-notation, complex-cartesian, complex-polar |
| ci | type | many -- see W3C documentation (generally do not affect rendering) |
| tendsto | type | two-sided, above, below |
| set | type | normal, multiset |
| interval | closure | closed, open, open-closed, closed-open |
| list | order | numerical, lexicographic |
There are some other features and subtleties of the translator's source syntax which are not covered in the above tables -- see the documentation page for details. I refer to the resulting mark-up language (the source code syntax for the translator applet) as "Content Pseudo-TeX."
[Note: Much of this section also appears in the documentation page for the translator applet.]
The table below shows a few more involved examples of expressions given first in the Content Pseudo-TeX source syntax, then in the Content MathML output from the translator applet, then finally rendered by the browser from the Content MathML source. Some of these examples expand or complete examples used earlier in this article.
| Source: | Content MathML: | Rendered: |
| \int[v:x][l:0][u:\pi;]{\sin{x}}=2 |
|
|
\limit[v:x][c:{x\tendsto@above|0}]{\sin{x}/x}=1 |
|
|
x_1=(-b+\root{b^2-4a*c})/2a |
|
|
\sum[v:n][l:1][u:\infinity;]{1/n^2}=\pi;^2/6
|
|
|
\int[v:x][l:-\infinity;][u:\infinity;]
{\exp{-(x^2)}}=\root{\pi;}
|
|
|
\diff[v:x]{
\int[v:t][l:a][u:x]{f(t)}
}=f(x)
|
|
[Note: Much of this section also appears in the documentation page for the translator applet.]
The list below gives the elements of Content MathML which cannot be generated in any usable way by the translator applet.
Content mark-up of any type does carry its own inherent limitations. One fairly simple example illustrating this is the common use of the "plus-or-minus" operator. Content MathML does not have a built-in element corresponding to this operator, so for example the Quadratic Formula must be expressed as two separate expressions differing only in that single operator, using "<plus/>" in one of the expressions and "<minus/>" in the other. This may seem like yet another place where the restrictions of Content MathML lead to excessive verbosity, but the issue here is actually somewhat deeper. To see how, though, the Quadratic Formula is not the best example -- a better example is the angle-sum and angle-difference identities for cosine. These identities are usually presented in a form where the two versions of the identities are compressed into a single expression, using both a "plus-or-minus" operator and a "minus-or-plus" operator. This expression implies a link between the choices of operators at these two positions in the expression, and indeed this link is important to the meaning of the expression. The table below shows the mark-up code for the separate forms of the expressions in both the Content Pseudo-TeX syntax and in Content MathML, and the combined form in Presentation MathML.
| Separate: | Combined: | |
\cos{α+β}=
\cos{α}*\cos{β}-
\sin{α}*\sin{β}
|
\cos{α-β}=
\cos{α}*\cos{β}+
\sin{α}*\sin{β}
|
Presentation MathML only |
|
|
|
How can this link be captured in a content-level notation, though? Since Content MathML is based on XML, the relationships between the MathML tags are represented (in the Document Object Model, or DOM) as a tree-based structure. This link between the "plus-or-minus" and "minus-or-plus" operators at two different places in the expression would require an association between nodes on distinct branches of the tree structure. On their own, neither Content MathML nor the more general XML support such associations. Yet without the association, the meaning of the expression is lost. The correct formal answer to this issue must then be to represent the two versions of the angle-sum and angle-difference identities for cosine as two separate expressions, for the purposes of a content-level representation. Note, however, that the MathML "<semantics>" tag can be used to associate the Content MathML with Presentation MathML that combines the two expressions in the usual way. It is important to point out that the Presentation MathML does not actually link the two operators -- it simply places them correctly without any actual semantic association between them.
The W3C maintains a Document Type Definition (DTD) which can be used for documents which use XHTML, MathML, and SVG (Scalable Vector Graphics) together. This profile would allow authors of online mathematics to include very sophisticated equations and figures in their documents. This profile provides an obvious first step toward next-generation web pages which include mathematics. Indeed, this article uses a W3C profile with XHTML and MathML, but not SVG since the article doesn't use graphics.
The latest version of XHTML groups the tags into "modules," such as a "tables" module and a "forms" module. One of the modules is the "presentation" module, which includes such tags as "<br>," "<b>," and "<i>." (In place of the presentation tags "<b>" and "<i>," there are corresponding content-level tags "<strong>" and "<em>.") It is worth noting that XHTML does not support the HTML "<font>" tag at all. A simple recommendation for maintaining content-level markup, then, would be to use XHTML without the presentation-module tags.
A more draconian, but perhaps nonetheless ultimately preferable, recommendation would be to create a new stylesheet using XSLT transformations to implement a new tag set, with tag names derived from document structure macros in LaTeX. For example, the stylesheet could implement a "<theorem>...</theorem>" XML environment analogous to the LaTeX "\begin{theorem}...\end{theorem}" environment. The document structure environments in LaTeX do not specify any particular presentation for theorems or definitions, leaving such decisions to the LaTeX style -- in other words, they provide content-level information about the document. The syntax of tags in a document written for this stylesheet would still be XML-based, but at least the tag identifiers would be familiar to LaTeX users. I am working on a stylesheet based on this idea, and I hope to have a prototype available soon.
Finally, as of this writing, W3C has just introduced the working draft for MathML version 3.0. Bringing the translator into compliance with this new version will require some modifications to the applet, in particular to change how bound variables, qualifiers, and attributes are handled. The changes in Content MathML between versions 2.0 and 3.0 are designed to bring Content MathML closer to OpenMath, including the introduction of "content dictionaries" for defining symbols and entities. I will work on the necessary changes as soon as possible and make the revised applet available from the current translator applet page, but I will not roll the new applet out onto the main translator page until this new version of MathML moves from "working draft" to "recommendation" status within W3C. In the meantime, MathML 2.0 is the current accepted standard supported by available browsers and plug-ins, and even those browsers which do begin to support the new working draft will include legacy support features included in the working draft, so the current version of the translator will still generate acceptable output.