2 MathML Fundamentals

2.1.1 Taxonomy of MathML Elements

All MathML elements fall into one of three categories: presentation elements, content elements and interface elements. Each of these categories is described in detail in 3 Presentation Markup, 4 Content Markup and 7 The MathML Interface, respectively.

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 recursive nature of mathematical objects and notation is strongly reflected in MathML markup. In use, most presentation or content elements contain some number of other MathML elements corresponding to the constituent pieces out of which the original object is recursively built. The original schema is commonly called the parent schema, and the constituent pieces are called child schemata. More generally, MathML expressions can be regarded as trees, where each node corresponds to a MathML element, the branches under a "parent" node correspond to its "children", and the leaves in the tree correspond to atomic notation or content units such as numbers, characters, etc.

Most leaf nodes in a MathML expression tree are either canonically empty elements with no bodies, or token elements. Canonically empty elements represent symbols directly in MathML, for example, the content element plus does this. MathML token elements are the only MathML elements permitted to contain MathML character data. MathML character data consists of Unicode characters with the infrequent addition of special character constructions done with the mglyph element. A third kind of leaf node permitted in MathML is the annotation element, which is used to hold data which is not in MathML format.

The most important presentation token elements are mi, mn and mo for representing identifiers, numbers and operators respectively. Typically a renderer will employ slightly different typesetting styles for each of these kinds of character data: numbers are usually in upright font, identifiers in italics, and operators have extra space around them. In content markup, there are only three tokens, ci, cn and csymbol, for identifiers, numbers and new symbols introduced in the document itself, respectively. In content markup, separate elements are provided for commonly used functions and operators. The apply element is provided for user-defined extensions to the base set.

In terms of markup, most MathML elements are denoted by a start tag and an end tag, which enclose the markup for their contents. In the case of tokens, the content is character data, and in most other cases, the content is the markup for child elements. Elements in a third category, called canonically empty elements, do not require any contents, and are denoted by a single tag of the form name. An example of this kind of markup is plus in content markup.

Let us take the very simple example of (a + b)², and we can now see how the principles discussed above play out in practice. One form of presentation markup for this example is:

 <mrow>
   <msup>
     <mfenced>
       <mrow>
         <mi>a</mi>
         <mo>+</mo>
         <mi>b</mi>
       </mrow>
     </mfenced>
     <mn>2</mn>
   </msup>
 </mrow>

This example demonstrates a number of presentation elements. The first element, one that is used a great deal is mrow. This element is used to denote a row of horizontally aligned material. The material contained between the mrow and mrow tags is considered to be an argument to the mrow element. Thus the whole expression here is contained in an mrow element. As previously noted, almost all mathematical expressions decompose into subexpressions. These subexpressions can, in turn, also be contained in an mrow element. For example, a + b is also contained in an mrow.

The mfenced element is used to provide fences (braces, brackets, and parentheses) around formula material. It defaults to using parentheses.

Note the use of the mi element for displaying the variables a and b and the mo element for marking the + operator.

The msup element is for expressions involving superscripts and takes two arguments, in order, the base expression (here, (a+b)) and the exponent expression (here, 2).

The content markup for the same example is:

 <mrow>
   <apply>
     <power/>
     <apply>
       <plus/>
       <ci>a</ci>
       <ci>b</ci>
     </apply>
     <cn>2</cn>
   </apply>
 </mrow>

Here, the apply content element means apply an operation to an expression. In this example, the power element (for exponentiation), which requires no body, and the similar plus element (for addition) are both applied. Observe that both operators take two arguments, the order being particularly significant in the case of the power operator. But the order of the children is crucial in the use of the apply since the first child, the operator, takes as argument list the remaining ones.

Note the use of the ci element to mark up the variables a and b, and the cn element to mark up the number 2.

2.1.2 Presentation Markup

MathML presentation markup consists of about 30 elements which accept over 50 attributes. Most of the elements correspond to layout schemata, which contain other presentation elements. Each layout schema corresponds to a two-dimensional notational device, such as a superscript or subscript, fraction or table. In addition, there are the presentation token elements mi, mo and mn introduced above, as well as several other less commonly used token elements. The remaining few presentation elements are empty elements, and are used mostly in connection with alignment.

The layout schemata fall into several classes. One group of elements is concerned with scripts, and contains elements such as msub, munder, and mmultiscripts. Another group focuses on more general layout and includes mrow, mstyle, and mfrac. A third group deals with tables. The maction element is in a category by itself, and allows coding of various kinds of actions on notation, such as occur in an expression which toggles between two pieces of notation.

An important feature of many layout schemata is that the order of child schemata is significant. For example, the first child of an mfrac element is the numerator and the second child is the denominator. Since the order of child schemata is not enforced at the XML level by the MathML DTD, the information added by ordering is only available to a MathML processor, as opposed to a generic XML processor. When we want to emphasize that a MathML element such as mfrac requires children in a specific order, we will refer to them as arguments, and think of the mfrac element as a notational "constructor".

2.1.3 Content Markup

Content markup consists of about 120 elements accepting roughly a dozen attributes. The majority of these elements are empty elements corresponding to a wide variety of operators, relations and named functions. Examples of this sort include partialdiff, leq and tan. Others such as matrix and set are used to encode various mathematical data types, and a third, important category of content elements such as apply are used to apply operations to expressions and also to make new mathematical objects from others.

The apply element is perhaps the single most important content element. It is used to apply a function or operation to a collection of arguments. The positions of the child schemata are again significant, with the first child denoting the function to be applied, and the remaining children denoting the arguments of the function in order. Note that the apply construct always uses prefix notation, like the programming language LISP. In particular, even binary operations such as subtraction are marked up by applying a prefix subtraction operator to two arguments. For example, a - b would be marked up as

<mrow>
<apply>
   <minus/>
   <ci>a</ci>
   <ci>b</ci>
</apply>
</mrow>

A number of functions and operations require one or more quantifiers to be well-defined. For example, in addition to an integrand, a definite integral must specify the limits of integration and the bound variable. For this reason, there are several qualifier schemata such as bvar and lowlimit. They are used with operators such as diff and int.

The declare construct is especially important for content markup that might be evaluated by a computer algebra system. The declare element provides a basic assignment mechanism, where a variable can be declared to be of a certain type, with a certain value.

In both the presentation and content markup examples, mathematical expressions are recursively decomposed into nested, simpler MathML elements specifying each stage of the decomposition. The examples in the following sections illustrate this with more complex expressions.

2.1.4 Mixing Presentation and Content

Different kinds of markup will be found most appropriate for different kinds of tasks. Documents written before the World Wide Web became important were most often intended only for visual communication of information, so that legacy data is probably best translated into pure presentation markup, since semantic information about what the author meant can only be guessed at heuristically. By contrast, some mathematical applications and pedagogically-oriented authoring tools will likely choose to be entirely content-based. The majority of applications fall somewhere in between these extremes. For these applications, the most appropriate markup is a mixture of both presentation and content markup.

The rules for mixing presentation and content markup derive from the general principle that mixed content should only be allowed in places where it makes sense. For content markup embedded in presentation markup this basically means that any content fragments should be semantically meaningful, and should not require additional arguments or quantifiers to be fully specified. For presentation markup embedded in content markup, this usually means that presentation markup must be contained in a content token element, so that it will be treated as an indivisible notational unit used as a variable or function name.

Another option is to use a semantics element. The semantics element is used to bind MathML expressions to various kinds of annotations. One common use for the semantics element is to bind a piece of content markup to some presentation markup as a semantic annotation. In this way, an author can specify a non-standard notation to be used when displaying a particular content expression. Another use of the semantics element is to bind some other kind of semantic specification, such as an OpenMath expression, to a MathML expression. In this way, the semantics element can be used to extend the scope of MathML content markup.

2.3.1 Presentation Examples

Notation: x² + 4x + 4 = 0.

Markup:

<mrow>
  <mrow>
    <msup>
      <mi>x</mi>
      <mn>2</mn>
    </msup>
    <mo>+</mo>
    <mrow>
      <mn>4</mn>
      <mo>&InvisibleTimes;</mo>
      <mi>x</mi>
    </mrow>
    <mo>+</mo>
    <mn>4</mn>
  </mrow>
  <mo>=</mo>
  <mn>0</mn>
</mrow>

Note the use of nested mrow elements to denote terms, for example, the left-hand side of the equation functioning as an operand of "=". Marking terms greatly facilitates spacing for visual rendering, voice rendering, and line breaking. The InvisibleTimes MathML character entity is used here to indicate to a renderer that there are special spacing rules between the 4 and the x, and that the 4 and the x should not be broken onto separate lines. In fact, this use of an entity which was introduced in MathML 1.0 is no longer the way that is preferred. Ultimately all ordinary character data is given by Unicode values. However, although a character for ⁢ is expected in Unicode 3.2, and there is a suggested code point under consideration in a Unicode amendment, there is no Unicode 3.0 character to be used at present. We could use the expected numerical character reference ࠎ but for clarity we will continue to use entity references in these examples. The situation is explicitly discussed in 3.2 Token Elements and in 6 Characters, Entities and Fonts.

Notation: .

Markup:

<mrow>
  <mi>x</mi>
  <mo>=</mo>
  <mfrac>
    <mrow>
      <mrow>
        <mo>-</mo>
        <mi>b</mi>
      </mrow>
      <mo>&PlusMinus;</mo>
      <msqrt>
        <mrow>
          <msup>
            <mi>b</mi>
            <mn>2</mn>
          </msup>
          <mo>-</mo>
          <mrow>
            <mn>4</mn>
            <mo>&InvisibleTimes;</mo>
            <mi>a</mi>
            <mo>&InvisibleTimes;</mo>
            <mi>c</mi>
          </mrow>
        </mrow>
      </msqrt>
    </mrow>
    <mrow>
      <mn>2</mn>
      <mo>&InvisibleTimes;</mo>
      <mi>a</mi>
    </mrow>
  </mfrac>
</mrow>

The mfrac and msqrt elements are used for generating fractions and square roots, respectively.

Notice that the "plus or minus" sign is given by the entity name ±, this is equivalent to using the character reference &#00B1;. MathML provides a very comprehensive list of character names for mathematical symbols. In addition to the mathematical symbols needed for screen and print rendering, MathML provides symbols to facilitate audio rendering. For audio rendering, it is important to be able to automatically determine whether

<mrow>
  <mi>z</mi>
  <mfenced>
    <mrow>
      <mi>x</mi>
      <mo>+</mo>
      <mi>y</mi>
    </mrow>
  </mfenced>
</mrow>

should be read as `z times the quantity x plus y' or `z of x plus y'. The characters ⁢ (U+2062) and ⁡ (U+2061) provide a way for authors to directly encode the distinction for audio renderers. For instance, in the first case ⁢ (U+2062) should be inserted after the line containing the z. MathML also introduces entities like ⅆ (U+2146) representing a "differential d", which renders with slightly different spacing in print and can be rendered as "d" or "with respect to" in speech. Unless content tags, or some other mechanism, are used to eliminate the ambiguity, authors should always use these characters here referred to as entities, in order to make their documents more accessible.

Notation: .

Markup:

<mrow>
  <mi>A</mi>
  <mo>=</mo>
  <mfenced open="[" close="]">
    <mtable>
      <mtr>
         <mtd><mi>x</mi></mtd>
         <mtd><mi>y</mi></mtd>
      </mtr>
      <mtr>
         <mtd><mi>z</mi></mtd>
         <mtd><mi>w</mi></mtd>
      </mtr>
    </mtable>
  </mfenced>
</mrow>

The mtable element denotes that a MathML table is being created. The mtr specifies a row of the table and the mtd element holds the data for an element of a row. Most elements have a number of attributes that control the details of their screen and print rendering. For example, there are several attributes for the mfenced element that controls what delimiters should be used at the beginning and the end of the grouped expression above. The attributes for operator elements given using mo are set to default values determined by a dictionary. For the suggested MathML operator dictionary, see F Operator Dictionary.

2.3.2 Content Examples

Notation: x² + 4x + 4 = 0.

Markup:

<mrow>
<apply>
  <eq/>
  <apply>
    <plus/>
    <apply>
      <power/>
      <ci>x</ci>
      <cn>2</cn>
    </apply>
    <apply>
      <times/>
      <cn>4</cn>
      <ci>x</ci>
    </apply>
    <cn>4</cn>
  </apply>
  <cn>0</cn>
</apply>
</mrow>

Note that the apply element is used for relations, operators and functions.

Notation: .

Markup:

<apply>
  <eq/>
  <ci>x</ci>
  <apply>
    <divide/>
    <apply>
      <csymbol>&PlusMinus;</csymbol>
      <apply>
        <minus/>
        <ci>b</ci>
      </apply>
      <apply>
        <root/>
        <degree><cn>2</cn></degree>
        <apply>
          <minus/>
          <apply>
            <power/>
            <ci>b</ci>
            <cn>2</cn>
          </apply>
          <apply>
            <times/>
            <cn>4</cn>
            <ci>a</ci>
            <ci>c</ci>
          </apply>
        </apply>
      </apply>
    </apply>
    <apply>
      <times/>
      <cn>2</cn>
      <ci>a</ci>
    </apply>
  </apply>
</apply>

MathML content markup does not directly contain an element for the "plus or minus" operation. Therefore, we use the csymbol element to specify this operator. Note that the default presentation is given here in prefix form, although a renderer may recognise this operator and render it as infix. Alternatively the Mixed Markup style shown below may be used to specify a presentation form for this expression as well as the Content Markup.

Notation: .

Markup:

<mrow>
<apply>
  <eq/>
  <ci>A</ci>
  <matrix>
    <matrixrow>
      <ci>x</ci>
      <ci>y</ci>
    </matrixrow>
    <matrixrow>
      <ci>z</ci>
      <ci>w</ci>
    </matrixrow>
  </matrix>
</apply>
</mrow>

Here we have used the matrix element, and the matrixrow element to wrap the entries in a row of the matrix. Note that, by default, the rendering of the content element matrix includes enclosing parentheses, so we need not directly encode them. This is quite different from the presentation element mtable which may or may not refer to a matrix, and hence requires explicit encoding of parentheses if they are desired.

2.3.3 Mixed Markup Examples

Notation: .

Markup:

<mrow>
<semantics>
  <mrow>
    <msubsup>
      <mo>&int;</mo>
      <mn>1</mn>
      <mi>t</mi>
    </msubsup>
    <mfrac>
      <mrow>
        <mo>&dd;</mo>
        <mi>x</mi>
      </mrow>
      <mi>x</mi>
    </mfrac>
  </mrow>
  <annotation-xml encoding="MathML-Content">
    <apply>
      <int/>
      <bvar><ci>x</ci></bvar>
      <lowlimit><cn>1</cn></lowlimit>
      <uplimit><ci>t</ci></uplimit>
      <apply>
        <divide/>
        <cn>1</cn>
        <ci>x</ci>
      </apply>
    </apply>
  </annotation-xml>
</semantics>
</mrow>

In this example, we use the semantics element to provide a MathML content expression to serve as a "semantic annotation" for a presentation expression. In the display markup, we have used the msubsup element to attach a subscript and a superscript to an expression, in this case the integral sign. We also used entities ∫ and ⅆ to specify the integral and differential symbols.

The semantics element has as its first child the expression being annotated, and the subsequent children are the annotations. There is no restriction on the kind of annotation that can be attached using the semantics element. For example, one might give a T_EX encoding, or computer algebra input in an annotation. The type of annotation is specified by the encoding attribute and the annotation and annotation-xml elements.

Another common use of the semantics element arises when one wants to use a content coding, and provide a suggestion for its presentation. In such a case, applied to the formula above we would have the markup:

<semantics>
  <apply>
    <int/>
    <bvar><ci>x</ci></bvar>
    <lowlimit><cn>1</cn></lowlimit>
    <uplimit><ci>t</ci></uplimit>
    <apply>
      <divide/>
      <cn>1</cn>
      <ci>x</ci>
    </apply>
  </apply>
  <annotation-xml encoding="MathML-Presentation">
    <mrow>
      <msubsup>
        <mo>&int;</mo>
        <mn>1</mn>
        <mi>t</mi>
      </msubsup>
      <mfrac>
        <mrow>
          <mo>&dd;</mo>
          <mi>x</mi>
        </mrow>
        <mi>x</mi>
      </mfrac>
    </mrow>
  </annotation-xml>
</semantics>

This kind of annotation is useful when something other than the default rendering of the content encoding is desired. For example, by default, some renderers might layout the integrand something like "(1/x) dx". Specifying that the integrand should by preference render as "dx/x" instead can be accomplished with the use of a MathML Presentation annotation as shown. Be aware, however, that renderers are not required to take into account information contained in annotations, and what use is made of them, if any, will depend on the renderer.

2.4.1 MathML Syntax and Grammar

MathML is an application of [XML], or Extensible Markup Language, and as such its syntax is governed by the rules of XML syntax, and its grammar is in part specified by a DTD, or Document Type Definition. In other words, the details of using tags, attributes, entity references and so on are defined in the XML language specification, and the details about MathML element and attribute names, which elements can be nested inside each other, and so on are specified in the MathML DTD. This is in A Parsing MathML.

The W3C in seeking to increase the flexibility of the use of XML for the Web, and to encourage modularization of applications built with XML, has found that the basic form of a DTD is not sufficiently flexible. Therefore, a W3C Working Group was created to develop a specification for XML Schemas [XMLSchemas], which are specification documents that will eventually supersede DTDs. MathML 2.0 is consciously designed so that mathematics may take advantage of the latest in the evolving Web technology. Thus, there is to be a schema for MathML. For further information on a MathML schema see A Parsing MathML and the MathML Home Page.

However, MathML also specifies some syntax and grammar rules in addition to the general rules it inherits as an XML application. These rules allow MathML to encode a great deal more information than would ordinarily be possible with pure XML, without introducing many more elements, and using a substantially more complex DTD or schema. A grammar for content markup expressions is given in B Content Markup Validation Grammar. Of course, one drawback to using MathML specific rules is that they are invisible to generic XML processors and validators.

There are basically two kinds of additional MathML grammar and syntax rules. One kind involves placing additional criteria on attribute values. For example, it is not possible in pure XML to require that an attribute value be a positive integer. The second kind of rule specifies more detailed restrictions on the child elements (for example on ordering) than are given in the DTD or even a schema. For example, it is not possible in XML to specify that the first child be interpreted one way, and the second in another.

The following sections discuss features both of XML syntax and grammar in general, and of MathML in particular. Throughout the remainder of the MathML specification, we will usually take care to distinguish between usage required by XML syntax and the MathML DTD (and schema) and usage required by MathML specific rules. However, we will frequently allude to "MathML errors" without identifying which part of the specification is being violated.

2.4.2 An XML Syntax Primer

Since MathML is an application of XML, the MathML specification uses the terminology of XML to describe it. Briefly, XML data is composed of Unicode characters (which include ordinary ASCII characters), "entity references" (informally called "entities") such as < which usually represent "extended characters", and "elements" such as <mi fontstyle="normal"> x </mi>.

An element quite often encloses other XML data called its "content", or "body", between a "start tag" (sometimes called a "begin tag") and an "end tag", much as in HTML. There are also "empty elements" such as plus, whose start tag ends with /> to indicate that the element has no content or end tag. The start tag can contain named parameters called "attributes", such as fontstyle="normal" in the example above. For further details on XML, consult the XML specification [XML].

As XML is case-sensitive, MathML element and attribute names are case-sensitive. For reasons of legibility, the MathML specification defines them almost all in lowercase.

In formal discussions of XML markup, a distinction is maintained between an element, such as an mrow element, and the tags mrow and mrow marking it. What is between the mrow start tag and the mrow end tag is the content, or body, of the mrow element. An "empty element" such as none is defined to have no body, and so has a single tag of the form none. Usually, the distinction between elements and tags will not be so finely drawn in this specification. For instance, we will sometimes refer to the mrow and none elements, really meaning the elements whose tags these are, in order that references to elements are visually distinguishable from references to attributes. However, the words "element" and "tag" themselves will be used strictly in accordance with XML terminology.

2.4.3 Children versus Arguments

Many MathML elements require a specific number of child elements or attach additional meanings to children in certain positions. As noted above, these kinds of requirements are MathML specific, and cannot be given entirely using XML syntax and grammar. When the children of a given MathML element are subject to these kinds of additional conditions, we will often refer to them as arguments instead of merely as children, in order to emphasize their MathML specific usage. Note that, especially in 3 Presentation Markup, the term "argument" is usually used in this technical sense, unless otherwise noted, and therefore refers to a child element.

In the detailed discussions of element syntax given with each element throughout the MathML specification, the number of required arguments and their order is implicitly indicated by giving names for the arguments at various positions. This information is also given for presentation elements in the table of argument requirements in 3.1.3 Required Arguments, and for content elements in B Content Markup Validation Grammar.

A few elements have other requirements on the number or type of arguments. These additional requirements are described together with the individual elements.

2.4.4 MathML Attribute Values

According to the XML language specification, attributes given to elements must have one of the forms

attribute-name = "value"

or

attribute-name = 'value'

where whitespace around the '=' is optional.

Attribute names are generally shown in a monospaced font within descriptive text in this specification, just as the monospaced font is used for examples.

An attribute's value, which in general in MathML can be a string of arbitrary characters, must be surrounded by a pair of either double quotes (") or single quotes ('). The kind of quotes not used to surround the value may be included within it.

MathML uses a more complicated syntax for attribute values than the generic XML syntax required by the MathML DTD. These additional rules are intended for use by MathML applications, and it is a MathML error to violate them, though they cannot be enforced by XML processing. The MathML syntax of each attribute value is specified in the table of attributes provided with the description of each element, using a notation described below. When MathML applications process attribute values, whitespace is ignored except to separate letter and digit sequences into individual words or numbers. Attribute values may contain any MathML characters listed in 6.2 MathML Characters permitted by the syntax restrictions for an attribute. Character data can be included directly in attribute values, or by using entity references as described in 6.2.1 Unicode Character Data.

In particular, the characters ", ', & and < can be included in MathML attribute values (when permitted by the attribute value syntax) using the entity references ", ', & and <, respectively.

The MathML DTD provided in A Parsing MathML declares most attribute value types as CDATA strings. This permits increased interoperability with existing SGML and XML software and allows extension to the lists of predefined values. Similar sorts of considerations apply with XML schemas.

2.4.5 Attributes Shared by all MathML Elements

In order to facilitate use with style sheet mechanisms such as [XSLT] and [CSS2] all MathML elements accept class, style, and id attributes in addition to the attributes described specifically for each element. MathML renderers not supporting CSS may ignore these attributes. MathML specifies these attribute values as general strings, even if style sheet mechanisms have more restrictive syntaxes for them. That is, any value for them is valid in MathML.

In order to facilitate compatibility with linking mechanisms, all MathML elements accept the xlink:href attribute.

All MathML elements also accept the xref attribute for use in parallel markup (5.3 Parallel Markup). The id is also used in this context.

Every MathML element, because of a legacy from MathML 1.0, also accepts the deprecated attribute other (7.2.3 Attributes for unspecified data) which was conceived for passing non-standard attributes without violating the MathML DTD. MathML renderers are only required to process this attribute if they respond to any attributes which are not standard in MathML. However, the use of other is strongly deprecated when there are already other ways within MathML of passing specific information.

See also 3.2.2 Mathematics style attributes common to token elements for a list of MathML attributes which can be used on most presentation token elements.

2.4.6 Collapsing Whitespace in Input

MathML ignores whitespace occurring outside token elements. Non-whitespace characters are not allowed there. Whitespace occurring within the content of token elements is "trimmed" from the ends, i.e., all whitespace at the beginning and end of the content is removed. Whitespace internal to content of MathML elements is "collapsed" canonically, i.e., each sequence of 1 or more whitespace characters is replaced with one space character (sometimes called a blank character).

In MathML, as in XML, "whitespace" means simple spaces, tabs, newlines, or carriage returns, i.e., characters with hexadecimal Unicode codes U+0020, U+0009, U+000A, or U+000D, respectively.

For example, <mo> ( </mo> is equivalent to <mo>(</mo>, and

<mtext>
  Theorem
  1:
</mtext>

is equivalent to <mtext>Theorem 1:</mtext>.

Authors wishing to encode whitespace characters at the start or end of the content of a token, or in sequences other than a single space, without having them ignored, must use   or other "whitespace" non-marking entities as described in 6.2.4 Non-Marking Characters. For example, compare

<mtext>
 Theorem
  1:
</mtext>

with

<mtext>
&nbsp;Theorem &nbsp;1: 
</mtext> 

When the first example is rendered, there is no whitespace before "Theorem", one space between "Theorem" and "1:", and no whitespace after "1:". In the second example, a single space is rendered before "Theorem", two spaces are rendered before "1:", and there is no whitespace after the "1:".

Note that the xml:space attribute does not apply in this situation since XML processors pass whitespace in tokens to a MathML processor; it is the MathML processing rules which specify that whitespace is trimmed and collapsed.

For whitespace occurring outside the content of the token elements mi, mn, mo, ms, mtext, ci, cn and annotation, an mspace element should be used, as opposed to an mtext element containing only "whitespace" entities.