# Chapter 6: Combining Presentation and Content Markup

 < Day Day Up >

# Chapter 6: Combining Presentation and Content Markup

This chapter explains the rules for combining presentation and content tags and the situations in which combining them is useful. It also explains the difference between mixed and parallel markup, and shows how you can use cross-references for expressing parallel markup more compactly.

## 6.1 Introduction

As we saw in Chapters 3, 4, and 5, MathML consist of two different markup schemes, each with its own set of tags and attributes. Presentation markup describes the visual structure of mathematical notation. It is useful in contexts that emphasize the visual aspects of mathematics; for example, displaying a technical paper in a Web page. Content markup, on the other hand, describes the symbolic meaning of a mathematical expression. It is useful in contexts where the precise meaning of a mathematical expression has to be communicated; for example, when you are evaluating an equation in a computer algebra system.

In many cases, there is a natural correspondence between the notation for a mathematical expression and its symbolic meaning. Hence, given the presentation encoding for an expression, you can infer its meaning-and therefore its content encoding. However, the correspondence between mathematical notation and meaning is imperfect. As we saw in Section 3.3, the same notation may express more than one mathematical concept; conversely, a given concept can be expressed by different notations. In such cases, there is no simple relationship between the presentation markup and content markup for an expression.

Presentation markup and content markup thus play a complementary role, with each providing a different type of information about a mathematical expression. When authoring a document containing MathML, you can use either presentation or content markup exclusively, depending on the audience for the document and the purpose for which it will be used. However, each of these options has certain limitations. If you use presentation markup, you are limited in the amount of information you can provide about the meaning of the encoded expression. If you use content markup, you cannot directly control how a given expression will be rendered.

To overcome these limitations, MathML also allows a third option, mixing presentation and content tags inside the same math element. This type of markup is called combined markup . It provides a way to specify information about both the presentational and semantic aspects of mathematics, in a single MathML expression, thus allowing a more complete description of any mathematical construct.

Combined markup can be classified into two main types, depending on the structure of the expression tree. If presentation and content tags are mixed together within a single branch of the expression tree, the resulting markup is called mixed markup . If the expression tree contains both content and presentation encodings of the same expression, enclosed in parallel within a semantics element, the resulting markup is called parallel markup . In the rest of this chapter we shall see examples of both types of markup, the situations in which they are useful, and the rules that govern them.

 < Day Day Up >
 < Day Day Up >

## 6.2 Mixed Markup

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:

• x 2

```<mrow> <apply> <power/> <ci>x</ci> <cn>2</cn> </apply> </mrow>
```

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:

```<ci type="vector"> <mover> <mi mathvariant="bold">A</mi> <mo>&RightArrow;</mo> </mover> </ci>
```

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 :

```<mroot> <mi><x></mi> <degree>3</degree > </mroot>
```

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):

```<mrow> <bvar>x</bvar> <mo>+</mo> <mi>1</mi> <dis2> </mrow>
```

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:

```<apply> <ci>x</ci><mo>+</mo><ci>y</ci> </apply>
```

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):

• X 2

```<ci> <msub> <mi>X</mi> <mn>2</mn> </msub> </ci>
```

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

```<cn> <mfrac bevelled="true"> <mn>2</mn> <mn>3</mn> </mfrac> </cn>
```

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:

• C 1

```<csymbol encoding="text" definitionURL = "http://www.example.org/ContDiffFunc.htm"> <msup> <mi>C</mi> <mn>1</mn> </msup> </csymbol>
```

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:

```<csymbol encoding="text" definitionURL = "http://www.example.org/ChristoffelSymbol.htm"> <mmultiscripts> <mi>&Gamma;</mi> <mi>i</mi> <mi>k</mi> <mi>j</mi> <none/> </mmultiscripts> </csymbol>
```

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

 < Day Day Up >