MathML - Mathematical Markup Language is an XML application for describing mathematical notation and capturing both its structure and content. The goal of MathML is to enable mathematics to be served, received, and processed on the World Wide Web, just as HTML has enabled this functionality for text.This specification of the markup language MathML is intended primarily for those who will be developing or implementing renderers or editors using it, or software that will communicate using MathML as a protocol for input or output. While MathML is human-readable, it is anticipated that, in all but the simplest cases, authors will use equation editors, conversion programs, and other specialized software tools to generate MathML. Several versions of such MathML tools already exist, and a number of others, both freely available software and commercial products, are under development. Most Computer Algebra Systems support import and export of MathML, and the W3C Math Working Group participants encourage implementation using the specification and comment on it.

The World Wide Web, which was originally conceived as an effective method for making information available to widely dispersed groups of individuals, has encountered many problems with communicating highly structured content. Although the World Wide Web was initially developed by scientists for the use of scientists, the possibilities for including mathematical expressions in HTML have been limited. At present, most mathematics represented on the Web consists of text with images of scientific notation (in GIF or JPEG format), which are difficult to read and to author, or of entire documents in PDF form. The demand for effective means of electronic scientific communication remains high. The image-based methods that are currently the predominant means of transmitting scientific notation over the Web are inadequate. Document quality is generally poor, authoring can be difficult, and mathematical information contained in images is not available for searching, indexing, or reuse in other applications.

The most obvious problems with HTML for maths communication are of three types:

- Image-based equations are generally harder to see, read and comprehend than the surrounding text in the browser window. Moreover, these problems become worse when the document is printed. The resolution of the equations as images will be around 70 dots per inch, while the surrounding text will typically be 300, 600 or more dots per inch. The disparity in quality is judged to be unacceptable by most people.
- Encoding Problems - trying to search document for part of an equation, to cut and paste an equation into another application, or even more demanding to cut and paste a sub-expression - none of these common needs can be adequately addressed.
- Size of the documents published on web and loading time - markup describing an equation is typically smaller and more compressible than an image of the equation, and by using markup-based encoding, more of the rendering process is moved to the client machine.

In order to meet the diverse needs of the scientific community, MathML has been designed with the following ultimate goals in mind.

MathML should:

- Encode mathematical material suitable for teaching and scientific communication at all levels.
- Encode both mathematical notation and mathematical meaning.
- Facilitate conversion to and from other mathematical formats, both presentational and semantic. Output formats should include: graphical displays, speech synthesizers, input for computer algebra systems, other mathematics typesetting languages, such as TEX, plain text displays, print media, including braille.

MathML may achieve its goals as a markup language and it only will be useful if it is implemented well. Therefore the W3C Math Working Group has identified a short list of additional implementation goals. These goals attempt to describe concisely the minimal functionality MathML rendering and processing software should try to provide.

- MathML expressions in HTML (and XHTML) pages should render properly in popular Web browsers, in accordance with reader and author viewing preferences, and at the highest quality possible given the capabilities of the platform.
- HTML (and XHTML) documents containing MathML expressions should print properly and at high-quality printer resolutions.
- MathML expressions in Web pages should be able to react to user gestures, such those as with a mouse, and to coordinate communication with other applications through the browser.
- Mathematical expression editors and converters should be developed to facilitate the creation of Web pages containing MathML expressions.

These goals have begun to be addressed for the near term by using embedded elements such as Java applets, plug-ins and ActiveX controls to render MathML. However, the extent to which these goals are ultimately met depends on the cooperation and support of browser vendors, and other software developers. The W3C Math Working Group has continued to work with the working groups for the Document Object Model (DOM) and the Extensible Style Language (XSL) to ensure that the needs of the scientific community will be met in the future, and feels that MathML 2.0 shows considerable progress in this area over the situation that obtained at the time of the MathML 1.0 Recommendation in April 1998.

MathML is designed to provide the encoding of mathematical information for the bottom, more general layer in a two-layer architecture. It is intended to encode complex notational and semantic structure in an explicit, regular, and easy-to-process way for renderers, searching and indexing software, and other mathematical applications. Raw MathML markup is not primarily intended for direct use by authors. Instead, it is anticipated that authors will use equation editors, conversion programs, and other specialized software tools to generate MathML. Alternatively, some renderers and systems supporting mathematics may convert other kinds of input directly included in Web pages into MathML on the fly, in response to a cut-and-paste operation, for example.

In some ways, MathML is analogous to other low-level, communication formats such as Adobe's PostScript language. You can create PostScript files in a variety of ways, depending on your needs; experts write and modify them by hand, authors create them with word processors, graphic artists with illustration programs, and so on. Once you have a PostScript file, however, you can share it with a very large audience, since devices which render PostScript, such as printers and screen previewers, are widely available.

Part of the reason for designing MathML as a markup language for a low-level, general, communication layer is to stimulate mathematical Web software development in the layer above. MathML provides a way of coordinating the development of modular authoring tools and rendering software. By making it easier to develop a functional piece of a larger system, MathML can stimulate a "critical mass" of software development, greatly to the benefit of potential users of mathematics on the Web.

MathML allows authors to encode both the notation which represents a mathematical object and the mathematical structure of the object itself. Moreover, authors can mix both kinds of encoding in order to specify both the presentation and content of a mathematical idea. All MathML elements fall into one of three categories: presentation elements, content elements and interface elements.

MathML presentation elements only suggest specific ways of rendering in order to allow for medium-dependent rendering and for individual preferences of style. This specification describes suggested visual rendering rules in some detail, but a particular MathML renderer is free to use its own rules as long as its renderings are intelligible. The presentation elements are meant to express the syntactic structure of mathematical notation in much the same way as titles, sections, and paragraphs capture the higher-level syntactic structure of a textual document. Because of this, for example, a single row of identifiers and operators, such as "x + a /2", will often be represented not just by one mrow element (which renders as a horizontal row of its arguments), but by multiple nested mrow elements corresponding to the nested sub-expressions of which one mathematical expression is composed - in this case

$<\mathrm{mrow}>$

$<\mathrm{mi}>x</\mathrm{mi}>$

$<\mathrm{mo}>+</\mathrm{mo}>$

$<\mathrm{mrow}>$

$<\mathrm{mi}>a</\mathrm{mi}>$

$<\mathrm{mo}>/</\mathrm{mo}>$

$<\mathrm{mi}>2</\mathrm{mi}>$

$</\mathrm{mrow}>$

$</\mathrm{mrow}>$

Similarly, superscripts are attached not just to the preceding character, but to the full expression constituting their base. This structure allows for better-quality rendering of mathematics, especially when details of the rendering environment such as display widths are not known to the document author; it also greatly eases automatic interpretation of the mathematical structures being represented.

For example, in the context of content markup a superscript would typically be denoted by an exponentiation operation ${x}^{n}$ that would require two operands: a "base" and an "exponent". This is no coincidence, since as a general rule, mathematical notation's layout closely follows the logical structure of the underlying mathematical objects.

$<\mathrm{msup}>$

$<\mathrm{mi}>x</\mathrm{mi}>$

$<\mathrm{mi}>n</\mathrm{mi}>$

$</\mathrm{msup}>$

The presentation elements are divided into two classes.

- Token elements represent individual symbols, names, numbers, labels, etc. In general, tokens can have only characters as content. The only exceptions are the vertical alignment element malignmark, mglyph, and entity references.
- Layout schemata build expressions out of parts, and can have only elements as content (except for whitespace, which they ignore). There are also a few empty elements used only in conjunction with certain layout schemata.

All individual "symbols" in a mathematical expression should be represented by MathML token elements. The primary MathML token element types are identifiers (e.g. variables or function names), numbers, and operators (including fences, such as parentheses, and separators, such as commas). There are also token elements for representing text or whitespace that has more aesthetic than mathematical significance, and for representing "string literals" for compatibility with computer algebra systems. Note that although a token element represents a single meaningful "symbol" (name, number, label, mathematical symbol, etc.), such symbols may be comprised of more than one character. For example arccos and 77 are represented by the single tokens $<\mathrm{mi}>\mathrm{arccos}</\mathrm{mi}>\phantom{\rule{mediummathspace}{0.2em}}$and $<\mathrm{mn}>77</\mathrm{mn}>$.

MathML 2.0 does not address right-to-left or bidirectional layout in mathematics formulas. Only left-to-right layout is supported. Right-to-left layout of mathematical formulas may be addressed in a future version of MathML.

mi | identifier |

mn | number |

mo | operator, fence or separator |

mtext | text |

mspace | space |

ms | string literal |

mglyph | accessing glyphs for character from MathML |

mrow | group any number of sub-expressions horizontally |

mfrac | form a fraction from two sub-expressions |

msqrt | form a square root (radical without an index) |

mroot | form a radical with specified index |

mstyle | style change |

merror | enclose a syntax error message from a preprocessor |

mpadded | adjust space around content |

mphantom | make content invisible but preserve its size |

mfenced | surround content with a pair of fences |

menclose | enclose content with a stretching symbol such as a long division sign |

msub | attach a subscript to a base |

msup | attach a superscript to a base |

msubsup | attach a subscript-superscript pair to a base |

munder | attach an underscript to a base |

mover | attach an overscript to a base |

munderover | attach an underscript-overscript pair to a base |

mmultiscripts | attach prescripts and tensor indices to a base |

mtable | table or matrix |

mlabeledtr | row in a table or matrix with a label or equation number |

mtr | row in a table or matrix |

mtd | one entry in a table or matrix |

maligngroup, malignmark | alignment markers |

maction | bind actions to a sub-expression |

Example 1. MathML code for expression $\phantom{\rule{0ex}{0ex}}\frac{1-\sqrt[3]{x}}{{y}^{4}+{z}^{2}}\phantom{\rule{mediummathspace}{0.2em}}$ is as follows

<math xmlns="http://www.w3.org/1998/Math/MathML">

<mfrac>

<mrow>

<mn> 1 </ mn><mo> - </ mo>

<mroot>

<mrow><mi> x </ mi></ mrow>

<mrow><mn> 3 </ mn></ mrow>

</ mroot>

</ mrow>

<mrow>

<msup><mrow><mi> y </ mi></ mrow><mrow><mn> 4 </ mn></ mrow></ msup>

<mo> + </ mo>

<msup><mrow><mi> z </ mi></ mrow><mrow><mn> 2 </ mn></ mrow></ msup>

</ mrow>

</ mfrac>

</ math>

Example 2.
*MathML code for expression * $\phantom{\rule{0ex}{0ex}}\phantom{\rule{0ex}{0ex}}\underset{a}{\overset{b}{\int}}$${e}^{2{x}^{5}}\mathrm{dx}$ is

<math xmlns="http://www.w3.org/1998/Math/MathML">

<munderover>

<mo> ∫ </ mo>

<mrow><mi> a </ mi></ mrow>

<mrow><mi> b </ mi></ mrow>

</ munderover>

<msup>

<mrow><mo> ⅇ </ mo></ mrow>

<mrow>

<mn> 2 </ mn>

<msup>

<mrow><mi> x </ mi></ mrow>

<mrow><mn> 5 </ mn></ mrow>

</ msup>

</ mrow>

</ msup>

<mi> dx </ mi>

</ math>

Presentation elements describe mathematical notation's visually oriented two-dimensional structure. Typical examples are the mrow element, which is usually employed to indicate a horizontal row of pieces of expressions, and the msup element, which is used to mark up a base expression and a superscript to it. As a general rule, each presentation element corresponds to a single kind of notational "schema" such as a row, a superscript, a subscript, an underscript and so on. Any formula is made by putting together parts which ultimately can be analyzed down to the simplest items such as digits, letters, or other symbol characters. Although the previous paragraph was concerned with the display aspect of mathematical notation, and hence with presentation markup, the same observation about decomposition applies equally well to abstract mathematical objects, and hence to content markup. For example, in the context of content markup a superscript would typically be denoted by an exponentiation operation that would require two operands: a "base" and an "exponent". This is no coincidence, since as a general rule, mathematical notation's layout closely follows the logical structure of the underlying mathematical objects.

The semantics of general mathematical notation is not a matter of consensus. It would be an enormous job to systematically codify most of mathematics - a task that can never be complete. Instead, MathML makes explicit a relatively small number of commonplace mathematical constructs, chosen carefully to be sufficient in a large number of applications. In addition, it provides a mechanism for associating semantics with new notational constructs. In this way, mathematical concepts that are not in the base collection of elements can still be encoded.

The base set of content elements is chosen to be adequate for simple coding of most of the formulas used from kindergarten to the end of high school in the United States, and probably beyond through the first two years of college, that is up to A-Level or Baccalaureate level in Europe. Subject areas covered to some extent in MathML are:

- arithmetic, algebra, logic and relations
- calculus and vector calculus
- set theory
- sequences and series
- elementary classical functions
- statistics
- linear algebra

It is not claimed, or even suggested, that the proposed set of elements is complete for these areas, but the provision for author extensibility greatly alleviates any problem omissions from this finite list might cause.

The primary goal of the content encoding is to establish explicit connections between mathematical structures and their mathematical meanings. The content elements correspond directly to parts of the underlying mathematical expression tree. Each structure has an associated default semantics and there is a mechanism for associating new mathematical definitions with new constructs.

Significant advantages to the introduction of content-specific tags include:

- Usage of presentation elements is less constrained. When mathematical semantics are inferred from presentation markup, processing agents must either be quite sophisticated, or they run the risk of inferring incomplete or incorrect semantics when irregular constructions are used to achieve a particular aural or visual effect.
- It is immediately clear which kind of information is being encoded simply by the kind of elements that are used.
- Combinations of semantic and presentation elements can be used to convey both the appearance and its mathematical meaning much more effectively than simply trying to infer one from the other.

To accomplish these goals, the MathML content encoding is based on the concept of an expression tree. A content expression tree is constructed from a collection of more primitive objects, referred to herein as containers and operators. MathML possesses a rich set of predefined container and operator objects, as well as constructs for combining containers and operators in mathematically meaningful ways.

As a general rule, the terminal nodes in the tree represent basic mathematical objects, such as numbers, variables, arithmetic operations and so on. The internal nodes in the tree generally represent some kind of function application or other mathematical construction that builds up a compound object. Function application provides the most important example; an internal node might represent the application of a function to several arguments, which are themselves represented by the terminal nodes underneath the internal node.The MathML content elements can be grouped into the following categories based on their usage:

- constants and symbols
- containers
- operators and functions
- qualifiers
- relations
- conditions
- semantic mappings.

These are the building blocks out of which MathML content expressions are constructed.

The most fundamental way of building up a mathematical expression in MathML content markup is the ''apply'' construct. An apply element typically applies an operator to its arguments. It corresponds to a complete mathematical expression, which means a piece of mathematics that could be surrounded by parentheses or "logical brackets" without changing its meaning. The opening and closing tags of apply specify exactly the scope of any operator or function.

Example 3. Mathematical expression (x + y) might be encoded as

<apply>

<plus />

<ci> x </ ci>

<ci> y </ ci>

</ apply>

The content model can be sybolically described as

<apply>

op

a

b

</ apply>

where the operands ''a'' and ''b'' are containers or other content-based elements themselves, and op is an operator or function. Note that since apply is a container, this allows apply constructs to be nested to arbitrary depth.

Example 4. Expression ''a x + b'' would be encoded as

<apply>

<plus />

<apply>

<times />

<ci> a </ ci>

<ci> x </ ci>

</ apply>

<ci> b </ ci>

</ apply>

Given functions, it is natural to have functional inverses. This is handled by the inverse element. Functional inverses can be rather problematic from a mathematical point of view as they implicitly involve the definition of an inverse ${f}^{-1}\phantom{\rule{mediummathspace}{0.2em}}$for an arbitrary function *f*. MathML adopts the following concept of an inverse function:

If *f* is a function from a domain *D* to *D* ', then the inverse *g* of *f* is a function over *D* ' such that *g*(*f* (*x*)) = *x* for *x* in *D*.

This definition does not assert that such an inverse exists for all or indeed any ** x** in

<apply>

<apply>

<inverse />

<sin />

</ apply>

<ci> x </ ci>

</ apply>

Example 5. The following markup declares and constructs the function *J* such

that *J*(*x*, *y*) is the integral from *x* to *y* of function ${t}^{4}$ with respect to *t*.

<declare type="function''>

<ci> f </ ci>

<lambda>

<bvar><ci> x </ ci></ bvar>

<apply>

<plus />

<apply>

<power />

<ci> x </ ci>

<cn> 2 </ cn>

</ apply>

<ci> x </ ci>

<cn> 3 </ cn>

</ apply>

</ lambda>

</ declare>

Containers provide a means for the construction of mathematical objects of a given type.

Tokens | ci,cn,csymbol |

Constructors | interval, list, matrix, matrixrow, set, vector, apply, reln, fn, lambda, piecewise, piece, otherwise |

Specials | declare |

The operators and functions defined by MathML can be divided into categories as shown in the table below.

quantifierunary arithmetric | factorial, minus, abs, conjugate, arg, real, imaginary, floor, ceiling |

unary logic | not |

unary functional | inverse, ident, domain, codomain, image |

unary elementary classical functions | sin, cos, tan, sec, csc, cot, sinh, cosh, tanh, sech, csch, coth, arcsin, arccos, arctan, arccosh, arccot, arccoth, arccsc, arccsch, arcsec, arcsech, arcsinh, arctanh, exp, ln, log |

unary linear algebra | determinant, transpose |

unary calculus and vector calculus | divergence, grad, curl, laplacian |

unary set-theoretic | card |

binary arithmetic | quotient, divide, minus, power, rem |

binary logical | implies, equivalent, approx |

binary set operators | setdiff |

binary linear algebra | vectorproduct, scalarproduct, outerproduct |

n-ary arithmetic | plus, times, max, min, gcd, lcm |

n-ary statistical | mean, sdev, variance, median, mode |

n-ary logical | and, or, xor |

n-ary linear algebra | selector |

n-ary set operator | union, intersect, cartesianproduct |

n-ary functional | fn, compose |

integral, sum, product operators | int, sum, product |

differential operator | diff, partialdiff |

quantifier | forall,exists |

The table below contains the qualifiers and the predefined operators defined as taking qualifiers in MathML.

qualifiers | lowlimit, uplimit, bvar, degree, logbase, interval, condition, domainofapplication, momentabout |

operators | int, sum, product, root, diff, partialdiff, limit, log, moment forall, exists |

n-ary operators | plus, times, max, min, gcd, lcm, mean, sdev, variance, median, mode, and, or, xor, union, intersect, cartesianproduct, compose, eq, leq, lt, geq, gt |

user defined operators | csymbol, ci |

Operators taking qualifiers are canonically empty functions that differ from ordinary empty functions only in that they support the use of special qualifier elements to specify their meaning more fully. Qualifiers always follow the operator and precede any arguments that are present. If more than one qualifier is present, they appear in the order ''bvar, lowlimit, uplimit, interval, condition, domainofapplication, degree, momentabout, logbase''.

Example 6. A typical example is

<apply>

<int />

<bvar><ci> x </ ci></ bvar>

<condition>

<apply><in /><ci> x </ ci><ci type=''set''> C </ ci></ apply>

</ condition>

<apply><sin /><ci> x </ ci></ apply>

</ apply>

binary relation | neq, equivalent, approx, factorof |

binary logical relation | implies |

binary set relation | in, notin, notsubset, notprsubset |

binary series relation | tendsto |

n-ray relation | eq, leq, lt, geq, gt |

n-ray set relation | subset, prsubset |

The MathML content tags include a number of canonically empty elements which denote arithmetic and logical relations. Relations are characterized by the fact that, if an external application were to evaluate them (MathML does not specify how to evaluate expressions), they would typically return a truth value. By contrast, operators generally return a value of the same type as the operands. For example, the result of evaluating $a<b\phantom{\rule{mediummathspace}{0.2em}}$is either true or false (by contrast, 1 + 2 is again a number).

Example 7. The example from the preceding paragraph is properly marked up as:

<apply>

<lt />

<ci> a <ci />

<ci> b <ci />

</ apply>

condition | condition |

Example 8. The following markup encodes "there exists $x<3$ such that ${x}^{2}=4$''.

<apply>

<exists />

<bvar><ci> x </ ci></ bvar>

<condition>

<apply><lt /><ci> x </ ci><cn> 3 </ cn></ apply>

</ condition>

<apply>

<eq />

<apply>

<power /><ci> x </ ci><cn> 2 </ cn>

</ apply>

<cn> 4 </ cn>

</ apply>

</ apply>

mappings | semantics, annotation, annotation-xml |

The use of content markup rather than presentation markup for mathematics is sometimes referred to as semantic tagging. The parse-tree of a valid element structure using MathML content elements corresponds directly to the expression tree of the underlying mathematical expression. We therefore regard the content tagging itself as encoding the syntax of the mathematical expression. This is, in general, sufficient to obtain some rendering and even some symbolic manipulation (e.g. polynomial factorization).

Although semantic mappings can easily be provided by various proprietary, or highly specialized encodings, there are no widely available, non-proprietary standard schemes for semantic mapping. In part to address this need, the goal of the OpenMath effort is to provide a platform-independent, vendor-neutral standard for the exchange of mathematical objects between applications. Such mathematical objects include semantic mapping information. The OpenMath group has defined an XML syntax for the encoding of this information [OpenMath2000]. This element set could provide the basis of one annotation-xml element set. An attractive side of this mechanism is that the OpenMath syntax is specified in XML, so that a MathML expression together with its semantic annotations can be validated using XML parsers.

MathML provides a collection of predefined constants and symbols which represent frequently-encountered concepts in mathematics. These include symbols for well-known sets, such as integers and rationals, and also some widely known constant symbols such as false, true, exponentiale.

The "constant" type is used to denote named constants. Several important constants such as $\pi $ have been included explicitly in MathML 2.0 as empty elements. This use of the cn is discouraged in favor of the defined constants, or the use of csymbol with an appropriate value for the definitionURL. For example, instead of using the $\pi $ element, an instance of <cn type="constant">π</ cn> could be used. This should be interpreted as having the semantics of the mathematical constant $\pi $. The data for a constant cn tag may be one of the following common constants:

Symbol | Value |

π | Ludolf number, the usual $\pi $ of trigonometry, approximately 3.141592653... |

ⅇ or ⅇ | Euler number, the base for natural logarithms, approximately 2.718281828... |

ⅈ or ⅈ | Square root of -1, imaginery unit |

γ | Euler's constant: approximately 0.5772156649... |

∞ or &infty; | Infinity. Proper interpretation varies with context |

&true; | the logical constant true |

&false; | the logical constant false |

&NotANumber; or &NaN; | represents the result of an ill-defined floating point division |

Presentation markup and content markup can be combined in two ways. The first manner is to intersperse content and presentation elements in what is essentially a single tree. This is called mixed markup. The second manner is to provide both an explicit presentation and an explicit content in a pair of trees. This is called parallel markup.

Presentation markup captures notational structure. It encodes the notational structure of an expression in a sufficiently abstract way to facilitate rendering to various media. Thus, the same presentation markup can be rendered with relative ease on screen in either wide and narrow windows, in ASCII or graphics, in print, or it can be enunciated in a sensible way when spoken. It does this by providing information such as structured grouping of expression parts, classification of symbols, etc. Presentation markup does not directly concern itself with the mathematical structure or meaning of an expression. In many situations, notational structure and mathematical structure are closely related, so a sophisticated processing application may be able to heuristically infer mathematical meaning from notational structure, provided sufficient context is known. However, in practice, the inference of mathematical meaning from mathematical notation must often be left to the reader. Employing presentation tags alone may limit the ability to re-use a MathML object in another context, especially evaluation by external applications.

Content markup captures mathematical structure. It encodes mathematical structure in a sufficiently regular way in order to facilitate the assignment of mathematical meaning to an expression by application programs. Though the details of mapping from mathematical expression structure to mathematical meaning can be extremely complex, in practice, there is wide agreement about the conventional meaning of many basic mathematical constructions. Consequently, much of the meaning of a content expression is easily accessible to a processing application, independently of where or how it is displayed to the reader. In many cases, content markup could be cut from a Web browser and pasted into a mathematical software tool with confidence that sensible values will be computed. Since content markup is not directly concerned with how an expression is displayed, a renderer must infer how an expression should be presented to a reader. While a sufficiently sophisticated renderer and style sheet mechanism could in principle allow a user to read mathematical documents using personalized notational preferences, in practice, rendering content expressions with notational nuances may still require intervention of some sort. Employing content tags alone may limit the ability of the author to precisely control how an expression is rendered.

Both content and presentation tags are necessary in order to provide the full expressive capability one would expect in a mathematical markup language. Often the same mathematical notation is used to represent several completely different concepts. For example, the notation ${x}^{i}$ may be intended (in polynomial algebra) as the *i*-th power of the variable *x*, or as the *i*-th component of a vector **x** (in tensor calculus). In other cases, the same mathematical concept may be displayed in one of various notations. For instance, the factorial of a number might be expressed with an exclamation mark, a Gamma function, or a Pochhammer symbol. Thus the same notation may represent several mathematical ideas, and, conversely, the same mathematical idea often has several notations. In order to provide authors with the ability to precisely control notation while at the same time encoding meanings in a machine-readable way, both content and presentation markup are needed.

In many common situations, an author or authoring tool may choose to generate either presentation or content markup exclusively. For example, a program for translating legacy documents would most likely generate pure presentation markup. Similarly, an educational software package might very well generate only content markup for evaluation in a computer algebra system. However, in many other situations, there are advantages to mixing both presentation and content markup within a single expression.

The use of presentation markup within content markup is limited to situations that do not effect the ability of content markup to unambiguously encode mathematical meaning. Specifically, presentation markup may only appear in content markup in three ways:

1. within ci and cn token elements

2. within the csymbol element

3. within the semantics element

Any other presentation markup occurring within a content markup is a MathML error.

The guiding principle for embedding content markup within presentation expressions is that the resulting expression should still have an unambiguous rendering. In general, this means that embedded content expressions must be semantically meaningful, since rendering of content markup depends on its meaning. Certain content elements derive part of their semantic meaning from the surrounding context, such as whether a bvar element is qualifying an integral, logical quantifier or lambda expression. Another example would be whether a degree element occurs in a root or partialdiff element. Thus, in a presentation context, elements such as these do not have a clearly defined meaning, and hence there is no obvious choice for a rendering. Consequently, they are not allowed.

Operator, relation, container, constant and symbol elements make sense on their own, while elements of the qualifier and condition type do not. (Note that interval may be used either as a general container, or as a qualifier.) Outside these categories, certain elements deserve specific comment: the elements declare, sep, annotation and annotation-xml can only appear in very specific contexts and consequently are not permitted as direct sub-expressions of any presentation element. Finally, the element semantics carries with it sufficient information to be permitted in presentation.The complete list of content elements that cannot appear as a child in a presentation element is: annotation, annotation-xml, sep, declare, bvar, condition, degree, logbase, lowlimit, uplimit.

The interaction of presentation and content markup can be greatly enhanced through the use of various tools. While the set of tools and standards for working with XML applications is rapidly evolving at the present, we can already outline some specific techniques. In general, the interaction of content and presentation is handled via transformation rules on MathML trees. These transformation rules are sometimes called "macros". In principle, these rules can be expressed using any one of a number of mechanisms, including DSSSL, Java programs operating on a DOM, etc., while the principal mechanism for these transformations in most applications shall be XSLT.

A MathML token element takes as content a sequence of MathML characters. MathML characters are defined to be either Unicode characters legal in XML documents or mglyph elements. The latter are used to represent characters that do not have a Unicode encoding. Because the Unicode UCS provided approximately one thousand special alphabetic characters for the use of mathematics with Unicode 3.1, and over 900 further special symbols in Unicode 3.2, the need for mglyph should be rare. Any character allowed by XML may be used in MathML in an XML document. The legal characters have the hexadecimal code numbers 09 (tab = U+0009), 0A (line feed = U+000A), 0D (carriage return = U+000D), 20-D7FF (U+0020..U+D7FF), E000-FFFD (U+E000..U+FFFD), and 10000-10FFFF (U+010000..U+10FFFF). The notation, just introduced in parentheses, beginning with U+ is that recommended by Unicode for referring to Unicode characters. The exclusions above code number D7FF are of the blocks used in surrogate pairs, and the two characters guaranteed not to be Unicode characters at all. U+FFFE is excluded to allow determination of byte order in certain encodings.

There are essentially three different ways of encoding character data.

- Using characters directly: For example, an A may be entered as 'A' from a keyboard (character U+0041). This option is only available if the character encoding specified for the XML document includes the character. Most commonly used encodings will have 'A' in the ASCII position. In many encodings, characters may need more than one byte. Note that if the document is, for example, encoded in Latin-1 (ISO-8859-1) then only the characters in that encoding are available directly. Using UTF-8 or UTF-16, the only two encodings that all XML processors are required to accept, mathematical symbols can be encoded as character data.
- Using numeric XML character references: Using this notation, 'A' may be represented as A (decimal) or A (hex). Note that the numbers always refer to the Unicode encoding (and not to the character encoding used in the XML file). By using character references it is always possible to access the entire Unicode range. For a general XML vocabulary, there is a disadvantage to this approach: character references may not be used in XML element or attribute names. However, this is not an issue for MathML, as all element names in MathML are restricted to ASCII characters.
- Using entity references: The MathML DTD defines internal entities that expand to character data. Thus for example the entity reference é may be used rather than the character reference é or, if, for example, the document is encoded in ISO-8859-1, the character é. An XML fragment that uses an entity reference which is not defined in a DTD is not well-formed; therefore it will be rejected by an XML parser. For this reason every fragment using entity references must use a DOCTYPE declaration which specifies the MathML DTD, or a DTD that at least declares any entity reference used in the MathML instance. The need to use a DOCTYPE complicates inclusion of MathML in some documents. However, entity references are very useful for small illustrative examples, and are used in most examples in this document.

Some characters, although important for the quality of print or alternative rendering, do not have glyph marks that correspond directly to them. They are called here non-marking characters. In MathML 2 control of page composition, such as line-breaking, is effected by the use of the proper attributes on the mspace element. The characters below are not simple spacers. They are especially important new additions to the UCS because they provide textual clues which can increase the quality of print rendering, permit correct audio rendering, and allow the unique recovery of mathematical semantics from text which is visually ambiguous.

Character name | Unicode | Description |

⁢ | 02062 | marks multiplication when it is understood without a mark |

⁣ | 02063 | used as a separator, e.g., in indices |

⁡ | 02061 | character showing function application in presentation tagging |

Entity name | Unicode | Description |

ⅅ | 02145 | D for use in differentials, e.g. within integrals |

ⅆ | 02146 | d for use in differentials, e.g. within integrals |

ⅇ | 02147 | e for use for the exponential base of the natural logarithms |

ⅈ | 021468 |
i for use as a square root of -1, imaginery unit in complex numbers |

To be effective, MathML must work well with a wide variety of renderers, processors, translators and editors. This chapter addresses some of the interface issues involved in generating and rendering MathML. Since MathML exists primarily to encode mathematics in Web documents, perhaps the most important interface issues are related to embedding MathML in HTML4 and XHTML.There are three kinds of interface issues that arise in embedding MathML in other XML documents.

First, MathML must be semantically integrated. MathML markup must be recognized as valid embedded XML content, and not as an error. This is primarily a question of managing namespaces in XML.

Second, in the case of HTML/XHTML, MathML rendering must be integrated into browser software. Some browsers already implement MathML rendering natively, and one can expect more browsers will do so in the future. At the same time, other browsers have developed infrastructure to facilitate the rendering of MathML and other embedded XML content by third-party software. Using these browser specific mechanisms generally requires some additional interface markup of some sort to activate them.

Third, other tools for generating and processing MathML must be able to intercommunicate. A number of MathML tools have been or are being developed, including editors, translators, computer algebra systems, and other scientific software. However, since MathML expressions tend to be lengthy, and prone to error when entered by hand, special emphasis must be given to insuring that MathML can be easily generated by user-friendly conversion and authoring tools, and that these tools work together in a dependable, platform and vendor independent way.

The W3C Math Working Group is committed to providing support to software vendors developing any kind of MathML tool. The Working Group monitors the public mailing list www-math@w3.org, and will attempt to answer questions about the MathML specification. The Working Group works with MathML developer and user groups. For current information about MathML tools, applications and user support activities, consult the home page of the W3C Math Working Group.

While MathML can be used in isolation as a language for exchanging mathematical expressions between MathML-aware applications, the primary anticipated use of MathML is to encode mathematical expression within larger documents. MathML is ideal for embedding math expressions in other applications of XML.

Embedding MathML in XML-based documents in general, and XHTML in particular, is a matter of managing namespaces. An XML namespace is a collection of names identified by a URI. The URI for the MathML namespace is:

http://www.w3.org/1998/Math/MathML

Using namespaces, embedding a MathML expression in a larger XML document is merely a matter of identifying the MathML markup as residing in the MathML namespace. This can be accomplished by either explicitly identifying each MathML element name by attaching a namespace prefix, or by declaring a default namespace on an enclosing element.

To declare a namespace, one uses an xmlns attribute, or an attribute with an xmlns prefix. When the xmlns attribute is used alone, it sets the default namespace for the element on which it appears, and for any children elements.

Example:

<math xmlns="http://www.w3.org/1998/Math/MathML">

<mrow>...</ mrow>

</ math>

When the xmlns attribute is used as a prefix, it declares a prefix which can then be used to explicitly associate other elements and attributes with a particular namespace.

Example:

<body xmlns:m="http://www.w3.org/1998/Math/MathML">

...

<m:math><m:mrow>...</ m:mrow> </ m:math>

...

</ body>

These two methods of namespace declaration can be used together. For example, by using both an explicit document-wide namespace prefix, and default namespace declarations on individual mathematical elements, it is possible to localize namespace related markup to the top-level math element.

Example:

<body xmlns:m="http://www.w3.org/1998/Math/MathML">

...

<m:math xmlns="http://www.w3.org/1998/Math/MathML">

<mrow>...</ mrow>

</ m:math>

...

</ body>

While the use of namespaces to embed MathML in other XML applications is completely described by the relevant W3C Recommendations, a certain degree of pragmatism is still called for at present. Support for XML, namespaces and rendering behaviors in popular user agents is not always fully in alignment with W3C Recommendations. In some cases, the software predates the relevant standards, and in other cases, the relevant standards are not yet complete.

During the transitional period, in which some software may not be fully namespace-aware, a few conventional practices will ease compatibility problems:

1. When using namespace prefixes with MathML markup, use m: as a conventional prefix for the MathML namespace. Using an explicit prefix is probably safer for compatibility in current user agents.

2. When using namespace prefixes, pick one and use it consistently within a document.

3. Explicitly declare the MathML namespace on all math elements.

Examples:

<body>

...

<m:math xmlns:m="http://www.w3.org/1998/Math/MathML">

<m:mrow>...</ m:mrow>

</ m:math>

...

</ body>

or

<body>

...

<math xmlns="http://www.w3.org/1998/Math/MathML">

<mrow>...</ mrow>

</ math>

...

</ body>

Note that these suggestions alone may not be sufficient for creating functional Web pages containing MathML markup. It will generally be the case that some additional document-wide markup will be required. Additional work may also be required to make all MathML instances in a document compatible with document-wide declarations. This is particularly true when documents are created by cutting and pasting MathML expressions, since current tools will probably not be able to query global namespace information.Consult the W3C Math Working Group home page for compatibility and implementation suggestions for current browsers and other MathML-aware tools.

REFERENCES

[1] http://www.w3.org/Math/

[2] MathML at the W3C, http://www.w3.org/TR/MathML2/