Up: Table of Contents | Working Draft 6-Jan-98 |

- 5.1 When to Use Mixed Markup
- 5.2 How to use Mixed Markup
- 5.3 Anticipating Macros for Combined Markup

5.1 When to Use Mixed Markup

MathML offers authors a choice between content and presentation markup. Whether to use one or the other, or a mixture of both, depends on what aspects of rendering and evaluation an author wishes to control, and what kinds of re-use he or she wishes to facilitate.

5.1.1 Why two different kinds of tags?Chapters 3 and 4 describe two kinds of markup for encoding mathematical material in documents:

**Presentation markup**
captures *notational structure*. It encodes notational
structure 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
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. 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
applications. Though the details of mapping from mathematical
structure to mathematical meaning are exceedingly complex, in
practice, there is wide agreement about the conventional meaning of
many basic mathematical constructs. 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
(such as future versions of Axiom, Maple or Mathematica) 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 still requires human intervention of some
sort.

Employing content tags alone may limit the ability of the author to precisely control how an expression is rendered.

It is important to emphasize that both content and presentation
tags are necessary in order to provide the full expressive
capability one would like 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

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 notational nuances while at the same time encoding meanings in a machine readable way, both content and presentation markup are needed.

In general, if it is important to control exactly how an expression is rendered,presentation markup will be necessary. If it is important that an expression can be evaluated dependably, then content markup will be necessary.

5.1.2 Analogy with HTMLOne difficulty in thinking about MathML is the temptation to compare it with HTML. In some ways, writing

is akin to using MathML content tags, while writing<H2>Why two different kinds of markup?</H2>

is more like using MathML presentation tags. However, this analogy is somewhat misleading, because text documents and mathematical expressions have a number of fundamental differences.<B>Why two different kinds of markup?</B><BR>

In a typical text document, there are relatively few purely notational constructs like paragraphs and headings, and they carry little of the meaning of the document. Most of the meaning is encoded in the words themselves. In mathematics, by contrast, there are many more notational constructs and they often have fairly specific meaning to a reader; though a fraction may mean several different things in different contexts, it is a much more specific notational device than a paragraph.

Another fundamental difference between text documents and mathematical expressions is that one can come much closer to describing the meaning of a math expression in a regular, unambiguous way than one can with a sentence of phrase. As a consequence, HTML deals with structure primarily at the document level, i.e. headings, paragraphs, etc., and makes no attempt to describe structure in fine enough detail to begin to convey the meaning of individual sentences. From this point of view, MathML presentation markup roughly corresponds to HTML elements like headings, while content markup corresponds to something not present in HTML at all.

By narrowing the domain of discourse, for example from text documents to bibliographies, one can envision a markup language with much closer parallels to MathML. In devising a bibliographic markup language, it is natural to begin with elements for authors, books, journals, publishers, dates, page references and so on. Such elements are analogous to MathML content markup; they capture the abstract structure of a generic bibliographic citation, and they have relatively unambiguous, conventional meanings.

However, as one tries to deal with more and more kinds of citations -- multiple authors, conference proceedings, newsletters, etc. -- the payoff for making further distinctions ceases to be worth the effort being put into the markup. Further distinctions may actually decrease the quality of the markup because the additional complication will result in input errors. Ultimately, it becomes more effective to introduce markup for directly encoding the desired presentation of an exceptional citation, rather than create another special case in the content-based markup.

5.1.3 Reasons to Mix MarkupIn many common situations, an author or authoring tool may choose to generate either presentation or content markup exclusively. For example, a programs 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.

If an author is primarily presentation-oriented, interspersing some content markup will often produce more accessible, more re-usable results. For example, an author writing about linear algebra might write:

where<mrow> <apply> <power/> <ci>x</ci><cn>2</cn> </apply> <mo>+</mo> <msup> <mi>v</mi><mn>2</mn> </msup> </mrow>

If an author is primarily content-oriented, there are two reasons to intersperse presentation markup. First, using presentation markup provides a way of modifying or refining how a content expression is rendered. For example, one might write:

In this case, the use of embedded presentation markup allows the author to specify that<relation> <in/> <ci><mi fontweight="bold">v</mi></ci> <ci>S</ci> </relation>

A second reason to intersperse presentation in content markup is that there is a continually growing list of areas of discourse which do not have pre-defined content elements for encoding their objects and operators. As a consequence, any system of content markup inevitably requires an extension mechanism which combines notation with semantics in some way. MathML content markup specifies several ways of attaching an external semantic definitions to content objects. However, it is necessary to use MathML presentation markup to specify how such user-defined, semantic extensions should be rendered.

For example, the **rank** operator from linear algebra is not
included as a pre-defined MathML content element. Thus, to express
the statement

we use therank(u,^{T}v) = 1

<relation> <eq> <apply> <fn> <semantics semtype="OpenMath"> <mo>rank</mo> <OMSymbol CD="BasicLinAlg">matrix-rank</OMSymbol> </semantics> </fn> <apply> <times> <apply> <transpose> <ci>u</ci> </apply> <ci>v</ci> </apply> </apply> <cn>1</cn> </relation>

Here, the semantics of the presentation subexpressions have been given using symbols from OpenMath content dictionaries (CD).

5.2 How to Mix MarkupThere are two main considerations when mixing presentation and content markup. First, mixed markup must be done is such a way that every presentation expression can be algorithmically rendered in a sensible, valid way. Second, mixed markup must be done in such a way that the meaning of content expressions can still be algorithmically determined. In general, the rules for mixing content markup within presentation markup are less stringent than mixing presentation within content; the constraint of an algorithmic way of evaluating content markup is naturally more stringent than the constraint of an algorithmic way of rendering presentation markup.

5.2.1 Mixing Presentation in Content MarkupThe use of presentation markup within content markup is limited to situations which do not effect the ability of content markup to unambiguously encode mathematical meaning. More specifically, presentation markup may only appear in content markup in four ways:

- within
**ci**and**cn**token elements - within the
**fn**element - within the
**semantics**element - any content element may be wrapped in an
**mstyle**element

**Presentation markup within token elements.** The token
elements **ci** and **cn** are permitted to contain any
sequence of #PCDATA, presentation elements, and **sep** empty
elements. Contiguous blocks of #PCDATA are rendered as if they were
wrapped in **mi** elements. If a token element contains both
#PCDATA and presentation elements, contiguous blocks of #PCDATA (if
any) are treated as if wrapped in **mi** elements, and the
resulting collection of presentation elements are rendered as if
wrapped in an **mrow** element.

The **sep** element is only meaningful in identifiers and
numbers defined to be of complex type, where it separates #PCDATA
into real and imaginary parts. When a token elements contains both
**sep** elements and presentation elements, the **sep**
elements are ignored.

**Presentation markup within the fn** element. The **fn**
element may contain either #PCDATA interspersed with presentation
markup, or content container elements. It is a MathML error for an
**fn** element to contain both presentation and content
elements. When the **fn** element contains both raw data and
presentation markup, the same rendering rules that apply to content
token elements should be used.

**Presentation markup within the semantics** element. It is
not technically correct to think of presentation markup within the
**semantics** elements as a case of presentation markup within
content markup, since the **semantics** elements can be used to
bind arbitrary annotations to any MathML element. However, binding
presentation markup to a content element is a completely valid use
of the **semantics** element. Suggested rendering for a **
semantics** element is discussed in 4.2.6.

**Content markup contained within an mstyle** element. Any
content element can optionally be wrapped in the presentation
element **mstyle**. The **mstyle** element in no way affects
the evaluation of content markup; applications seeking to interpret
the meaning of content markup should "tunnel" through all enclosing
**mstyle** elements. However, the attributes set by an **
mstyle** element propagate to all presentation markup within its
scope in the usual fashion. Thus, for example, enclosing a content
expression within an **<mstyle displaystyle="true"> ...
</mstyle>** construct specifies that all presentation
markup embedded in tokens, **fn** and **semantics** elements
should be typeset in display style.

A visual or aural MathML renderer should attempt to propagate
attributes set by an **mstyle** element to all markup it
encloses. What this means in the case of enclosed content markup is
of necessity renderer specific. However, in most situations, common
sense goes a long way: if the visual or aural rendering an
application generates for content markup can be described by
presentation markup, the effect of the **mstyle** element on the
content rendering should be the same as it would be for the
equivalent presentation markup.

The guiding principle for embedding content within presentation
is that the embedded content markup must be semantically
meaningful. In practice, this basically translates into the
condition that content container elements are permitted, while
other content elements such as operators, relations, and qualifier
elements are not. As a rule, content elements other than containers
derive part of their semantic meaning from the surrounding context,
such as whether an operator is being applied to arguments or not,
or whether a **bvar** element is qualifying an integral or a
limit. Thus, in a presentation context, these elements do not have
a well-defined meaning, and hence they are not allowed. The only
exception to this rule is the content container element **
declare**, whose scope depends on the enclosing content element.
Thus, even though **declare** is a container element, it is not
permitted in presentation markup.

The complete list of content elements which may appear as a
child in a presentation element other than **mstyle** (see
above) is:

<ci> |
<cn> |
<apply> |
<fn> |

<lambda> |
<e> |
<interval> |
<list> |

<matrix> |
<matrixrow> |
<set> |
<vector> |

For rendering purposes, when a permitted content element appears
within a presentation context, a processing application should
treat it as if it were replaced with an **mrow** containing a
presentation encoding of the rendering the application would
ordinarily generate for that content markup. For example,
consider:

In this case, a visual renderer would typically render the<mfrac> <mi>x</mi> <interval closure="open-closed"> <cn>1</cn> <cn>3</cn> </interval> </mfrac>

Consequently, the original mixed markup should be visually rendered as<mfenced close="]"> <mn>1</mn> <mn>3</mn> </mfenced>

5.3 Anticipating Macros for Combined Markup<mfrac> <mi>x</mi> <mfenced close="]"> <mn>1</mn> <mn>3</mn> </mfenced> </mfrac>

The examples above show that introducing new mathematical
content as *combined* presentation-content pairs is
verbose.

Certainly one can imagine generating this kind of markup with software tools, but it is at the borderline of what might be deemed tolerable to do by hand.

This is one of the areas of the MathML specification which anticipates most strongly the use of macros. A future report of the HTML-Math working will address the issue of a macro mechanism for MathML. With such a mechanism, it would be possible, for example, to define macros

and<rank>

which respectively expand to<tr>X</tr>

and<fn> <semantics semtype="OpenMath"> <mo>rank</mo> <OMSymbol CD="BasicLinAlg">matrix-rank</OMSymbol> </semantics> </fn>

The sample encoding of<apply> <transpose> <ci>X</ci> </apply>.

from section 5.1.3 could then be condensed torank(u,^{T}v) = 1

From this example we see how the combination of presentation and content markup could become much simpler and effective to generate as standard macro libraries become available.<relation> <eq> </apply> <rank> <apply> <times> <tr>u</tr> <ci>v</ci> </apply> </apply> <cn>1</cn> </relation>

Next: Entities, Characters and Fonts

Up: Table of Contents