Mixed markup

(Excerpt from "The MathML Handbook" by Pavi Sandhu)

Mixed markup itself can be of two types, depending on whether the outermost element is a presentation element or a content element:

  1. You can embed content markup inside presentation markup. This allows you to specify additional information about the meaning of the presentation markup, and processing applications can use this information to provide a more meaningful rendering of the encoded expression.
  2. You can embed presentation markup inside content markup. This allows you to specify how a particular piece of content markup should be rendered. You can, for example, specify a nonstandard rendering for a particular content expression. You can also specify a rendering for a content expression that does not have a well-defined default rendering.

Here is an example of content markup embedded in a presentation expression:


A processing application can use this content markup to provide a better rendering of the mixed expression. For example, in an audio rendering, the markup might be spoken as "x square" to clearly indicate its logical meaning. If pure presentation markup were used instead, the exponent would have to be represented using an msup element. This element does not contain enough information for a renderer to distinguish a power from a plain superscript.

Here is an example of presentation markup embedded in a content expression:

Mixed markup: example 2

<ci type="vector">
    <mi mathvariant="bold">A</mi>

Here, presentation markup is used to specify that the identifier A should be rendered in a bold font and with an arrow in the overscript position, to indicate that it represents a vector.

Rules for mixing markup

Of course, you cannot freely mix presentation and content tags in any order. For any instance of combined markup to be valid, it must satisfy some additional rules beyond those required for presentation or content markup alone. The exact rules that apply depend on whether you are including content tags in a presentation expression or vice versa.

If the combined markup is contained in a presentation expression, that expression must have a well-defined rendering. Similarly, if the combined markup is contained in a content expression, that expression must have a precise and unambiguous semantic meaning. Both of these requirements are a consequence of the general principle that any expression containing combined markup must have a sensible interpretation as a whole. Some specific rules that result as a consequence of this general principle are discussed below.

Content markup in presentation markup

The main requirement for content markup contained within a presentation expression is that the content markup be self-contained and have a well-defined semantic meaning. The reason for this is that any content expression whose semantic meaning is well defined also has a well-defined rendering, in the sense that the corresponding presentation markup can be inferred.

One consequence of this requirement is that certain content elements, such as bvar, uplimit, or lowlimit, cannot be directly included as children of a presentation element. The reason for this is that each of these content elements derives its meaning from the context in which it occurs. For example, the bvar element has a different meaning depending on whether it occurs inside an integral, derivative, root, or lambda expression. Similarly, the meaning of the degree element depends on whether it is qualifying a derivative, a root, or a statistical moment. Hence, to be meaningful, each of these elements must be enclosed in an appropriate content element.

The following markup is illegal, since the qualifier element degree has been directly included as a child of the presentation element mroot:

  <degree>3</degree > 

The enclosing presentation expression therefore does not have a well-defined rendering. Hence, this type of markup is not allowed.

Another example of an illegal expression is given below (in this case the <bvar> element has been wrongly inserted as the child of an <mrow> element):


The complete list of content elements that cannot be directly included as children of a presentation element is as follows: bvar, uplimit, lowlimit, degree, logbase, condition, domainofapplication, momentabout, declare, sep, annotation, and annotation-xml.

This list includes all the qualifier elements like bvar and degree since these exist only to qualify the meaning of other elements and are not meaningful on their own. In addition, the list includes some other elements that require a specific context to be meaningful. For example, the sep element can occur only inside a cn element. Similarly, the annotation and annotation-xml elements must be enclosed in a semantics element.

In general, content elements that represent operators, relations, containers, constants, and symbols have a meaning on their own and can be directly included in a presentation expression. However, content markup cannot occur inside the presentation token elements, namely mi, mn, and mo. The reason is that the token elements of presentation markup are allowed to contain only character data or a specific set of presentation elements.

Presentation markup in content markup

Presentation markup placed within a content expression must be semantically meaningful. An expression like the following is not allowed, since it does not have a well-defined semantic interpretation:


To prevent ill-defined expressions like the one above, presentation markup is allowed to occur in content markup in only one of four elements: ci, cn, csymbol, and semantics.

Each ci or cn element serves as an indivisible notational unit that represents an identifier or number. The ci and cn elements can contain any sequence of presentation elements freely interspersed with MathML characters. The role of the included presentation elements is only to specify a rendering for the particular object that is represented by the ci or cn element.

The following markup represents the second component of a vector, X (the presentation tags indicate that the expression should be rendered in a bold font and the 2 should be rendered in the subscript position):

Presentation markup in content markup: example 1


The following example uses presentation tags to specify a rendering for a rational number:

Presentation markup in content markup: example 2

  <mfrac bevelled="true">

A MathML application that recognizes both presentation and content tags could, in principle, parse the above markup so that it is rendered as a bevelled fraction, while still retaining the mathematical meaning associated with the number 2/3.

The csymbol element is provided as an extension mechanism for content markup. It can be used to describe concepts for which existing content elements are inadequate. This element can contain any valid presentation markup or any valid content markup. However, it cannot contain both presentation and content markup.

Here is an example of mixed markup using the csymbol element:

Presentation markup in content markup: example 3

<csymbol encoding="text" definitionURL="http://www.example.org/ContDiffFunc.htm">

This markup defines a symbol to represent the space of continuously differentiable functions. The enclosed presentation markup is used to specify the conventional notation for this symbol.

The embedded presentation markup can be as elaborate as desired. Here is an example of a symbol with a slightly more complex rendering than the previous example:

Presentation markup in content markup: example 4

<csymbol encoding="text" definitionURL="http://www.example.org/ChristoffelSymbol.htm">

Finally, presentation markup can occur inside a semantics element, in the form of parallel markup. A detailed discussion of parallel markup is given on the next pages.


<< back next >>




Tipp der data2type-Redaktion:
Zum Thema MathML bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an:


Copyright © CHARLES RIVER MEDIA, INC., Massachusetts (USA) 2003
Printing of the online version is permitted exclusively for private use. Otherwise this chapter from the book "The MathML Handbook" is subject to the same provisions as those applicable for the hardcover edition: The work including all its components is protected by copyright. All rights reserved, including reproduction, translation, microfilming as well as storage and processing in electronic systems.

CHARLES RIVER MEDIA, INC., 20 Downer Avenue, Suite 3, Hingham, Massachusetts 02043, United States of America