Working Draft 15-May-1997
In what follows, we describe how to mix presentation and content tags for the purpose of creating MathML objects.
The previous sections describe two levels of tags for markup in mathematical documents:
Presentation markup captures mathematical notation. It provides a notational expression with sufficient structure for rendering in various contexts. For example, presentation markup will allow an expression to be displayed sensibly in a window, whether the window is wide or narrow, or to 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 concern itself with the mathematical meaning of text, but it is concerned with the way an expression is presented to the eye or ear.
Employing presentation tags alone may limit the ability to render or re-use a MathML object in another context, especially for evaluation by external applications.
Content markup conveys mathematical meaning. It provides a mathematical expression with sufficient structure for the its contents to be understood. For example, with a sufficiently sophisticated renderer and style-sheet mechanism, content markup might allow a user to read mathematical documents using familiar notations. With content markup, an expression has the same mathematical value independently of where or how it appears. For example, an expression 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 correct values will be computed.
Employing content tags alone may limit the ability of the author to precisely control how an expression is rendered, or easily use non-standard notation.
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. Another example, the notation (a/b) may represent division, differentiation (dy/dx), or the Legendre symbol in number theory. In other cases, depending on the context, the same mathematical concept may be displayed in one of various notations. For example, the factorial of a number might be expressed with an exclamation mark, a Gamma function, or a Pochhamer symbol. An inner product might be represented using a dot a . b , a pair <a,b> or a vertical bar (a | b).
Thus we see that the same notation may represent several mathematical ideas, and, conversely, that the same mathematical idea often has several notations. Thus, in order to provide authors with the ability to precisely control notational nuances while at the same time encoding meanings in a uniform way for renderers and other applications, both content and presentation markup are needed.
If it is important that the expression appear in exactly a certain way, then presentation markup should be used. If it is important that the expression have a certain meaning, then content markup should be used.
An analogy may be drawn with the non-mathematical aspects of HTML. At one level, writing
is akin to using MathML content tags, while writing<H2>Why two different kinds of tags?</H2>
is akin to using MathML presentation tags.<BR><B>Why two different kinds of tags?</B></BR>
However, this analogy is only partly accurate. In natural language, we encode our ideas by means of many thousands of words, filled with subtle shades of syntactic nuance which cannot be captured by a rigid, formalized system. In a typical prose document, there are relatively few purely notational constructs like paragraphs and headings, and they carry little of the semantic meaning of the document. Most of the meaning of the document is encoded in the words themselves.
In mathematics, by contrast, notational constructs are much more complex and express a great deal of the meaning to a reader. A typical math notation might be at roughly the same level as a "question construct" or a "dependent clause" construct in natural language. Indeed, one might argue that notational schema like fractions in mathematics correspond more closely to words in the amount of meaning they carry, than they do to notational devices like paragraphs; a fraction, like many words, has only a few of well-defined meanings, and it is usually clear from context which is intended. From this point of view, the MathML presentation elements represent a level of notational abstraction at least as great as that of ordinary HTML tags, while MathML content elements represent a level of encoding not possible in natural language, and certainly not present in ordinary HTML.
Of course, neither of these analogies captures the essence of the interplay between notation and meaning in mathematics. If we compare mathematics to written natural language, the richness of the notational system has been expanded, while the universe of discourse has been narrowed to the point where they nearly coincide. Regardless of the philosophical implications of such observations, it is clear that part of the unique character of mathematics is that is possible to communicate virtually without ambiguity. Just as clearly, both presentational and content markup have a role to play in facilitating such communication.
There are several reasons why an author may wish to use a combination of presentation markup and content markup
If an author is primarily presentation-oriented, it will still be more convenient, and produce better, more accessible results to use some content markup, e.g.
<EXPR>x<POWER/>2</EXPR>
vs.
<MSUP><MI>x</MI><MN>2</MN></MSUP>
In this example, it is a bit shorter to use content markup, and more
importantly, the meaning of the superscript is unambiguously encoded,
which facilitates the proper voice rendering.
If an author is primarily content-oriented, there will be some areas of discourse which do not have content tags pre-defined, so it will be necessary to combine notation with semantics in some circumstances. There may also be situations in which an author needs to supplement the default rendering for content markup with additional presentation markup. For example, to express a statement of linear algebra,
rank(uTv) = 1,
we use the presentation tags
<mi>, <mo> and <msup>
together with the content markup:
<e>
<expr>
<semantics semtype="OpenMath">
<mo fontweight="bold">rank</mo>
<st/>
<OMSymbol CD="BasicLinAlg">matrix-rank</OMSymbol>
</semantics>
<apply/>
<expr>
<semantics semtype="OpenMath">
<msup><mi>u</mi> <mi>T</mi></msup>
<st/>
<OMApply>
<OMSymbol CD="BasicLinAlg">matrix-transpose<OMSymbol>
<mi>u</mi>
</OMApply>
</semantics>
<times/>
<mi>v</mi>
</expr>
</expr>
<eq>
1
</e>
Although there is a MathML vector content element, it is necessary to markup u and v as MIs, since the default rendering for vectors is a parenthesized list. Similarly, we must use the MO schema to produce the bold rank operator.
Here, the semantics of the presentation subexpressions have been given using symbols from OpenMath content dictionaries (CD).Including presentation with semantic annotation inside content markup greatly broadens the range of mathematical discourse in which the meaning of expressions can be given. This allows MathML expressions to interact with numeric and symbolic computation systems; theorem proving systems; special purpose scientific programs; interactive textbook applications designed to display and manipulate mathematical content; archiving of semantic mathematical information; and the electronic transmission of mathematical data.
As we see from the example above, introducing new mathematical content as combined presentation-semantics pairs can be 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 standard which anticipates most strongly the use of macros. As stated earlier, the main priority for the HTML Math working group will to develop extension protocols for MathML which include the definition of a suitable macro mechanism. With such a mechanism, it would be possible, for example, to define
<rank> X </rank>and
<transpose> X </transpose>to expand, respectively, to
<expr>
<semantics semtype="OpenMath">
<mo fontweight="bold">rank</mo>
<st/>
<OMSymbol CD="BasicLinAlg">matrix-rank</OMSymbol>
</semantics>
<apply/>
X
</expr>
and
<expr>
<semantics semtype="OpenMath">
<msup>X <mi>T</mi></msup>
<st/>
<OMApply>
<OMSymbol CD="BasicLinAlg">matrix-transpose<OMSymbol>
X
</OMApply>
</semantics>
</expr>
Similarly, we might define a <vect> macro to render vectors as we
want. Then, the second example of the previous section becomes:
<e>
<rank>
<expr>
<transpose><vect>u</vect></transpose>
<times/>
<vect>v</vect>
</expr>
</rank>
<eq>
1
</e>
From this example we see how the combination of presentation
and content markup will become much simpler and effective to
write by hand as time goes on.