Introduction

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.

1. Presentation and Content

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

2. Basics of Content MathML

2.1. Introduction to Notation

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
]]>

2.2. Excessive Verbosity of Content MathML

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

3. Is TeX an Appropriate Content Notation?

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.

4. A Content-Oriented TeX-Like Syntax

4.1. Familiar Elements of TeX Syntax

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.

4.2. Development of Design Criteria

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 xy]]>. In Content MathML, grouping is explicit with the <apply> environment, but in a standard arithmetic expression using binary infix operators, much of the grouping is implied by standard precedence rules, which can be overridden using explicit grouping by parentheses. This difference in how grouping is handled between the two forms is easily translated in the parser -- indeed, the output of any good parser for arithmetic expressions will be essentially a tree-based representation of the expression, which translates easily into the tree-based XML syntax of Content MathML.

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 xy]]>, again without the translator knowing anything about the id identifier. This may not be standard TeX notation, but it does provide a simple translation mechanism and is not so different from TeX as to be totally unfamiliar.

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 x]]>...</apply> indicates an integral with respect to the (bound) variable x. This seemed a natural place to use the LaTeX square-bracket optional argument syntax. However, here there is some necessary dependence on identifiers in order to distinguish between different qualifiers. For example, the optional argument in the form [v:...] provides the <bvar>...</bvar> qualifier.

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 ab]]> to represent the open interval from a to b. This approach to attributes, though, only allows any element in the TeX-like syntax to support one attribute. This turned out only to be a problem for the <cn> environment, which supports both the type and base attributes. In this situation, I had to decide which attribute would be more useful in general, so the @ construct in the TeX-like syntax maps to the type attribute for the <cn> environment.

4.3. Final Design Criteria

So ultimately I judged the design of the TeX-like syntax and its translation software by the following criteria:

• Output (destination) code should be strict Content MathML -- no presentation tags.
• Input (source) code should be "TeX-like" -- in particular:
• Backslash-escaped "macros" (although there will be a few different forms of them);
• Curly brackets {...} for most grouping;
• Square brackets [...] (as in LaTeX) for optional arguments (here will correspond to Content MathML "qualifiers");
• Environments similar to LaTeX: \begin{foo}...\end{foo}.
• Basic infix algebraic expressions and relations should be supported.
• Mapping from source to destination should be primarily syntactic -- so that if user wants to use foo identifier, then e.g. \foo source should yield (syntactically correct) <foo/> element, even if renderer doesn't recognize <foo/>. Primary advantage of this will be that translation will still work even if Content MathML element set expands.
• Sources of semantic ambiguity in TeX should be settled in favor of Content MathML -- for example, ^ in TeX can be used for either exponents or superscripts, but Content MathML doesn't use superscripts per se at all; here, ^ will be used only for exponents, and _ for Content MathML "selectors."
• Source expressions should be concise.
• Source expressions should cover as many cases of Content MathML as possible, even if it means departing from standard TeX-like syntax; however, it should not be expected that the source syntax would cover all cases of Content MathML.
• Source language with translator should be regarded as a tool for authoring Content MathML, not as a replacement for Content MathML.

4.4. Syntactic Mapping Scheme

The resulting syntactic mapping scheme worked out as follows:

Qualifiers are specified as given in the following table:

• [v:...] = <bvar>...</bvar>
• [u:...] = <uplimit>...</uplimit>
• [l:...] = <lowlimit>...</lowlimit>
• [i:...] = <interval>...</interval>
• [c:...] = <condition>...</condition>
• [d:...] = <domainofapplication>...</domainofapplication>
• [b:...] = <logbase>...</logbase>
• [n:...] = <degree>...</degree>
• [m:...] = <momentabout>...</momentabout>
• [s:...] = <list>...</list>

Attributes are specified using the special character "@" as follows:

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

4.5. Examples Using Content Pseudo-TeX

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.

  
  
    
      
        x
      
      
        0
      
      
        
      
      
        
          x
      
    
    2
]]>

 
 
  
  
   
	
	x
	0
   
  
  
   
   
	
	x
   
   x
  
 
 1
]]>

 
 
  
  x
  1
 
 
  
  
   
   
	
	b
   
   
	
	
	 
	 
	  
	  b
	  2
	 
	 
	  
	  
	   
	   4
	   a
	  
	  c
	 
	
   
  
  
   
   2
   a
  
 
]]>

 
 
  
  
   n
  
  
   1
  
  
   
  
  
   
   1
   
	
	n
	2
   
  
 
 
  
  
   
   
   2
  
  6
 
]]>

\int[v:x][l:-\infinity;][u:\infinity;]
	 {\exp{-(x2)}}=\root{\pi;}

 
 
  
  
   x
  
  
   
	
	
   
  
  
   
  
  
   
   
	
	
	 
	 x
	 2
	
   
  
 
 
  
  
 
]]>

\diff[v:x]{
	  \int[v:t][l:a][u:x]{f(t)}
   }=f(x)

 
 
  
  
   x
  
  
   
   
	t
   
   
	a
   
   
	x
   
   
	f
	t
   
  
 
 
  f
  x
 
]]>

4.6. Elements of Content MathML Not Covered by Content Pseudo-TeX

The list below gives the elements of Content MathML which cannot be generated in any usable way by the translator applet.

type="constant" for <cn> tag

Work-around: use defined stand-alone elements instead.

base attribute for <cn> tag

No work-around available

<csymbol>, <semantics>, <declare>, <annotation>, and <annotation-xml> elements

These are advanced Content MathML elements generally used to associate Content MathML with Presentation MathML or other encodings, and are therefore beyond the scope of the translator's source syntax

definitionURL and encoding attributes

These are advanced Content MathML elements again, generally used to associate Content MathML with external encodings, and are therefore beyond the scope of the translator's source syntax

class, id, style, href, xref, and other attributes

These attributes are used in XML to provide a way to associate elements with CSS stylesheet information, and are therefore beyond the scope of the translator's source syntax

5. Limitations of Content Mark-up

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.

\cos{α+β}=
\cos{α}*\cos{β}-
\sin{α}*\sin{β}

\cos{α-β}=
\cos{α}*\cos{β}+
\sin{α}*\sin{β}

 
 
  
  
   
   α
   β
  
 
 
  
  
   
   
    
    α
   
   
    
    β
   
  
  
   
   
    
    α
   
   
    
    β
   
  
 
]]>

 
 
  
  
   
   α
   β
  
 
 
  
  
   
   
    
    α
   
   
    
    β
   
  
  
   
   
    
    α
   
   
    
    β
   
  
 
]]>

 
  cos
  
   (
   
    α
   
   ±
   
    β
   
   )
  
 
 =
 
  
   
    cos
    
     α
    
   
   
   
    cos
    
     β
    
   
  
  ∓
  
   
    sin
    
     α
    
   
   
   
    sin
    
     β
    
   
  
 
]]>

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.

6. Further Recommendations

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.