5. Mixing Presentation and Content Markup

• 5.1 When to Use Mixed Markup
  • 5.1.1 Why Two Different Kinds of Markup?
  • 5.1.2 Analogy with HTML
  • 5.1.3 Reasons to Mix Markup
• 5.2 How to use Mixed Markup
  • 5.2.1 Mixing Presentation in Content Markup
  • 5.2.2 Mixing Content in Presentation Markup
• 5.3 Anticipating Macros for Combined 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.

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 ⁱ 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 Pochhamer 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 be necessary. If it is important that an expression can be evaluated dependably, then content markup will be necessary.

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

<H2>Why two different kinds of markup?</H2>

<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.

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>

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:

<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

    rank(uTv) = 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).

There 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.

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 four ways:

1. within ci and cn token elements
2. within the fn element
3. within the semantics element
4. 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:

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>

<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. 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

<rank>

<tr>X</tr>

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

<apply>
  <transpose>
  <ci>X</ci>
</apply>.

rank(uTv) = 1,

<relation>
  <eq>
  </apply>
    <rank>
    <apply>
      <times>        
      <tr>u</tr>
      <ci>v</ci>
    </apply>
  </apply>
  <cn>1</cn>
</relation>