| Up: Table of Contents | REC-MathML-19980407; revised 19990707 |
MathML offers authors elements for both content and presentation markup. Whether to use one or the other, or a mixture of both, depends on what aspects of rendering and interpretation an author wishes to control, and what kinds of re-use he or she wishes to facilitate.
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 xi may be intended (in polynomial algebra) as the i-th power of the variable x, or (in vector analysis) as the i-th component of the vector x. 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 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 generally be more satisfactory. If it is important that the meaning of an expression can be dependably and automatically interpreted, then content markup will generally be more satisfactory.
In 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:
<mrow>
<apply>
<power/>
<ci>x</ci><cn>2</cn>
</apply>
<mo>+</mo>
<msup>
<mi>v</mi><mn>2</mn>
</msup>
</mrow>
where v is a vector and the superscript denotes a vector
component, and x is a real variable. On account of the linear
algebra context, a visually impaired reader may have directed his or
her voice synthesis software to render superscripts as vector
components. By explicitly encoding the power, the content markup
yields a much better voice rendering than would likely happen by
default.
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 v should be rendered in boldface.<reln> <in/> <ci><mi fontweight="bold">v</mi></ci> <ci>S</ci> </reln>
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
rank(uTv) = 1,we use the mo presentation element inside a ci element to achieve the proper presentation, along with a semantics element which binds a semantic definition to the symbol. The mo element indicates to a renderer that it should use standard operator spacing around the content identifier "rank", just as it would for "sin" or "log":
<reln>
<eq/>
<apply>
<fn>
<semantics>
<ci><mo>rank</mo></ci>
<annotation-xml encoding="OpenMath">
<OMS CD="BasicLinAlg">matrix-rank</OMS>
</annotation-xml>
</semantics>
</fn>
<apply>
<times/>
<apply>
<transpose/>
<ci>u</ci>
</apply>
<ci>v</ci>
</apply>
</apply>
<cn>1</cn>
</reln>
Here, the semantics of the presentation subexpressions have been given using symbols from OpenMath content dictionaries (CD).
The main consideration when presentation markup and content markup are mixed together in a single expression is that the result should still make sense. When both kinds of markup are contained in a presentation expression, this means it should be possible to render the resulting mixed expressions simply and sensibly. Conversely, when mixed markup appears in a content expression, it should be possible to simply and sensibly assign a semantic interpretation to the expression as whole. These requirements place a few natural constraints on how presentation and content markup can be mixed in a single expression, in order to avoid ambiguous or otherwise problematic expressions.
Two motivating examples illustrate the kinds of problems that must be avoided in mixed markup. Consider:
In this example, the content element plus has been indiscriminately embedded in a presentation expression. Should the plus sign appear in its usual infix position, as it would in content markup, or should it render as the first thing in the row? Neither choice is very satisfactory, and consequently, this kind of mixing is not allowed. Similarly, consider:<mrow> <plus/> <mi> x </mi> <mi> y </mi> </mrow>
As before, the mo element is problematic. Should a renderer infer that the usual arithmetic operator is intended, and act as if the prefix content element plus had been used? Again, there is no compelling answer, and thus this kind of mixing of content and presentation markup is also prohibited.<apply> <ci> x </ci> <mo> + </mo> <ci> y </ci> </apply>
The 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 three ways:
The token elements ci and cn are permitted to contain any sequence of #PCDATA, presentation elements, and sep empty elements. Contiguous blocks of #PCDATA in ci and fn elements are rendered as if they were wrapped in mi elements. A contiguous blocks of #PCDATA within cn should be rendered as if wrapped in mn. If a token element contains both #PCDATA and presentation elements, contiguous blocks of #PCDATA (if any) are treated as if wrapped in mi or mn elements as appropriate, 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.
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.
One of the main purposes of the semantics element is to provide a mechanism for incorporating arbitrary MathML expressions into content markup in a semantically meaningful way. In particular, any valid presentation expression can be embedded in a content expression by wrapping it in a semantics element. Of course, the intention is that the meaning of the wrapped expression should be indicated by one or more annotation elements also contained in the semantics element. Suggested rendering for a semantics element is discussed in 4.2.6.
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. 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, and so on. Thus, in a presentation context, these elements do not have a clearly defined meaning, and hence there is no obvious choice for a rendering. Consequently, they are not allowed.
The complete list of content elements which may appear as a child in a presentation element is:
| <ci> | <cn> | <apply> | <fn> | <lambda> |
| <reln> | <interval> | <list> | <matrix> | <matrixrow> |
| <set> | <vector> | <declare> |
Note that within presentation markup, content expressions may only appear in locations where it is valid for any MathML expression to appear. In particular, content expressions may not appear within presentation token elements. In this regard mixing presentation and content are asymmetrical.
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:
<mfrac>
<mi>x</mi>
<interval closure="open-closed">
<cn>1</cn>
<cn>3</cn>
</interval>
</mfrac>
In this case, a visual renderer would typically render the
interval construct as (1,3]. Using presentation markup, this
might be encoded as:
Consequently, the original mixed markup should be visually rendered as<mfenced close="]"> <mn>1</mn> <mn>3</mn> </mfenced>
<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. With some kind of HTML/XML macro mechanism, it would be possible, for example, to define macros
and<rank/>
which respectively expand to<tr>X</tr>
<fn>
<semantics>
<ci><mo>rank</mo></ci>
<annotation-xml encoding="OpenMath">
<OMS CD="BasicLinAlg">matrix-rank</OMS>
</annotation-xml>
</semantics>
</fn>
and
The sample encoding of<apply> <transpose/> <ci>X</ci> </apply>.
rank(uTv) = 1,from section 5.1.3 could then be condensed to
<reln>
<eq>
</apply>
<rank/>
<apply>
<times/>
<tr>u</tr>
<ci>v</ci>
</apply>
</apply>
<cn>1</cn>
</reln>
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.