5 Combining Presentation and Content Markup

Overview: Mathematical Markup Language (MathML) Version 3.0
Previous: 4 Content Markup
Next: 6 Characters, Entities and Fonts

5 Combining Presentation and Content Markup
    5.1 Why Two Different Kinds of Markup?
    5.2 Mixed Markup
        5.2.1 Reasons to Mix Markup
        5.2.2 Combinations that are prohibited
        5.2.3 Presentation Markup Contained in Content Markup
        5.2.4 Content Markup Contained in Presentation Markup
    5.3 Parallel Markup
        5.3.1 Top-level Parallel Markup
        5.3.2 Fine-grained Parallel Markup
        5.3.3 Parallel Markup via Cross-References: id and xref
        5.3.4 Annotation Cross-References using XLink: id and href
    5.4 Notation Documents for Content to Presentation
        5.4.1 Rendering Agent at Work
        5.4.2 Context Information
        5.4.3 Notation Elements and Processing
        5.4.4 Precedence Rules and Bracket Output
        5.4.5 Support for Functions with Arbitrary Number of Arguments
    5.5 Tools, Style Sheets and Macros for Combined Markup
        5.5.1 Notational Style Sheets
        5.5.2 Content-Faithful Transformations
        5.5.3 Style Sheets for Extensions
    5.6 Combining MathML and Other Formats
        5.6.1 Invoking MathML Processors: namespace and mime-types
        5.6.2 Mixing MathML and HTML
        5.6.3 Linking
        5.6.4 Images
        5.6.5 MathML and Graphical Markup
    5.7 Using CSS with MathML

Issue update_mixing	`wiki (member only)`
Update Combining Presentation and Content Markup
The current chapter describes MathML2, it will need to be updated in later drafts.
Resolution	None recorded

Presentation markup and content markup can be combined in three ways. The first manner is to intersperse content and presentation elements in what is essentially a single tree. This is called mixed markup. The second manner is to provide both an explicit presentation and an explicit content in a pair of trees. This is called parallel markup. The third manner is to provide notation-documents which enable processors to render content markup to to presentation markup. This chapter describes all three manners and how they may be used in conjunction with style sheets and other tools.

5.1 Why Two Different Kinds of Markup?

Chapters 3 and 4 describe two kinds of markup for encoding mathematical material in documents.

Presentation markup captures notational structure. It encodes the notational structure of an expression 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 structured 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, provided sufficient context is known. 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 application programs. Though the details of mapping from mathematical expression structure to mathematical meaning can be extremely complex, in practice, there is wide agreement about the conventional meaning of many basic mathematical constructions. 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 with confidence that sensible values ~~will be~~ would 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 may still require intervention of some sort. [Unclear. Intervention by what on what?]

~~Employing content tags alone may limit the ability of the author to precisely control how an expression is rendered.~~ [This can be removed.]

Both content and presentation tags are necessary in order to provide the full expressive capability one would expect 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 as the i-th component of a vector x (in tensor calculus). 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 notation, 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 interpreted dependably and automatically, then content markup will generally be more satisfactory.

5.2 Mixed Markup

MathML offers authors elements for both content and presentation markup. Whether to use one or the other, or a combination 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.

5.2.1 Reasons to Mix Markup

In many common situations, an author or authoring tool may choose to generate either presentation or content markup exclusively. For example, a program 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~~ concerned with presentation, 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~~ Because 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~~ concerned with content, 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:

<apply>

  <in/>

  <ci><mi mathvariant="bold">v</mi></ci>

  <ci>S</ci>

</apply>

Issue confirm-mathml-p-in-c	`wiki (member only)` ISSUE-15 (member only)
Keep Including MathML-P in csymbol and ci ?
MathML-presentation is allowed within ci and csymbol and the usage of this seems to be precisely for rendering purposes. This comes as a supplement to notation-documents and, to me, is bad since it duplicates the MathML-p tree at every-occurrence of the ci or csymbol element. This approach also has the strong problem that it is left to computing engines to identify when to variables are equal. E.g. should <ci><mi style="font-weight:bold">b</mi></ci> and <ci><mi style="font-weight:700">b</mi></ci> be considered the same variable? (they are "CSS-equivalent" !)
Resolution	None recorded

In this case, the use of embedded presentation markup allows the author to specify that v should be rendered in boldface. In the same way, it is sometimes the case that a completely different notation is desired for a content expression. For example, here we express a fact about factorials, n = n!/(n-1)!, using the ascending factorial notation:

<apply>

  <equivalent/>

  <ci>n</ci>

  <apply>

     <divide/>

     <semantics>

        <apply>

           <factorial/>

           <ci>n</ci>

        </apply>

        <annotation-xml encoding="MathML-Presentation">

           <msup>

              <mn>1</mn>

              <mover accent="true">

                 <mi>n</mi>

                 <mo>&OverBar;</mo>

              </mover>

           </msup>

        </annotation-xml>

     </semantics>

     <semantics>

        <apply>

           <factorial/>

           <apply><minus/><ci>n</ci><cn>1</cn></apply>

        </apply>

        <annotation-xml encoding="MathML-Presentation">

           <msup>

              <mn>1</mn>

              <mover accent="true">

                 <mrow><mi>n</mi><mo>-</mo><mn>1</mn></mrow>

                 <mo>&OverBar;</mo>

              </mover>

           </msup>

        </annotation-xml>

     </semantics>

   </apply>

</apply>

This content expression would render using the given notation as: $n \equiv \frac{1^{\bar{n}}}{1^{\frac{}{n-1}}}$

A second reason to use presentation within content markup is that there is a continually growing list of areas of discourse that 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 that combines notation with semantics in some way. MathML content markup specifies several ways of attaching an external semantic definitions to content objects. It is necessary, however, 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(u^Tv)=1 we use a semantics element to bind a semantic definition to the symbol rank.

<apply>

  <eq/>

  <apply>

    <semantics>

      <mi>rank</mi>

      <annotation-xml encoding="OpenMath">

        <OMS name="rank" cd="linalg4" xmlns="http://www.openmath.org/OpenMath"/>

      </annotation-xml>

    </semantics>

    <apply>

      <times/>

      <apply> <transpose/> <ci>u</ci> </apply>

      <ci>v</ci>

    </apply>

  </apply>

  <cn>1</cn>

</apply>

Here, the semantics of rank have been given using a symbol from an OpenMath [OpenMath2000] content dictionary (CD).

In some cases the alternatives children ??? of the semantics elements are not required for a default behaviour, for example that of presentation within a browser, but may be useful to specialized processors or when copied into a system clipboard. To enable the availability of several formats without overloading the delivery [what does that mean?], the annotation and annotation-xml can be provided without children but with the encoding and the href attributes providing a location reference to the content of the semantics alternative. [I find this paragraph unclear. Could you reword it and provide an example?]

Processing agents which export expressions (or sub-expressions, provided referenced parallel markup allows it) in a world where the request of such alternative could be impossible should enrich the MathML-expression with the result of requesting the indicated URL. [Unclear.] Clipboards in contemporary desktop environments are such exports; indeed, when a copy action is requested, the environment's clipboard needs to be populated with all possible alternative encodings thus guaranteeing their availability even after a network connection or some other such conditions are not applicable anymore.

5.2.2 Combinations that are prohibited

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 a 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 examples illustrate the kinds of problems that must be avoided in mixed markup. Consider:

<mrow>

  <bvar> x </bvar> <mo> + </mo> <bvar> y </bvar>

</mrow>

In this example, the content element bvar has been indiscriminately embedded in a presentation expression. Since bvar requires an enclosing context for its meaning, this expression is unclear.

Similarly, consider:

<apply>

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

</apply>

Here, 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? Or should this be literally interpreted as the operator x applied to two arguments, <mo>+</mo> and <mi>y</mi> ? Even if we were to decide that <mo>+</mo> was the operator, then what should its meaning be? These questions do not have particularly compelling answers, so this kind of mixing of content and presentation markup is also prohibited.

5.2.3 Presentation Markup Contained in Content Markup

The use of presentation markup within content markup is limited to situations that do not effect the ability of content markup to unambiguously encode mathematical meaning. Specifically, presentation markup may only appear in content markup in three ways:

1. within ci and cn token elements

2. within the csymbol element

3. within the semantics element

Any other presentation markup occurring within a content markup is a MathML error. More detailed discussion of these three cases follows:

Presentation markup within token elements.

The token elements ci and cn are permitted to contain any sequence of MathML characters (defined in Chapter 6 Characters, Entities and Fonts), presentation elements, and sep empty elements [Is sep deprecated now?]. Contiguous blocks of MathML characters in ci and cn elements are rendered as if they were wrapped in mi and mn elements respectively. If a token element contains both MathML characters and presentation elements, contiguous blocks of MathML characters (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.

Presentation markup within the csymbol element.

The csymbol element may contain either MathML characters interspersed with presentation markup, or content elements of the container type. It is a MathML error for a csymbol element to contain both presentation and content elements. When the csymbol element contains both raw data and presentation markup, the same rendering rules that apply to content elements of the token type should be used.

Presentation markup within the semantics element.

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 placing it as the first child of a semantics element. The meaning of this wrapped expression should be indicated by one or more annotation elements also contained in the semantics element.

5.2.4 Content Markup Contained in Presentation Markup

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.

Certain content elements derive part of their semantic meaning from the surrounding context, such as whether a bvar element is qualifying an integral, logical quantifier or lambda expression. Another example would be whether a degree element occurs in a root or partialdiff element. Thus, in a presentation context, elements such as these do not have a clearly defined meaning, and hence there is no obvious choice for a rendering. Consequently, they are not allowed.

Using the terminology of Section 4.1.2 The Scope of Content Markup, we see that operator, relation, container, constant and symbol elements make sense on their own, while elements of the qualifier and condition type do not. (Note that interval may be used either as a general container, or as a qualifier.)

Outside these categories, certain elements deserve specific comment: the elements declare, sep, annotation and annotation-xml can only appear in very specific contexts and consequently are not permitted as direct sub-expressions of any presentation element. Finally, the element semantics carries with it sufficient information to be permitted in presentation.

The complete list of content elements that cannot appear as a child in a presentation element is: annotation, annotation-xml, sep, declare, bvar, condition, degree, logbase, lowlimit, uplimit.

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.

Note that embedding content markup in presentation markup will often require applications to render operators outside of an apply context. ~~E.g~~., For example, it may be necessary to render abs, plus, root or sin outside of an application. Content/presentation mixing does not introduce any new requirements, however, since unapplied operators are already permitted in content expressions, for example:

<apply><compose/><sin/><apply><inverse/><root/></apply></apply>

5.3 Parallel Markup

Some applications are able to make use of both presentation and content information. For these applications it is desirable to provide both forms of markup for the same mathematical expression. This is called parallel markup.

Parallel markup is achieved with the semantics element. Parallel markup for an expression can be used on its own, or can be incorporated as part of a larger content or presentation tree.

5.3.1 Top-level Parallel Markup

In many cases what is desired is to provide presentation markup and content markup for a mathematical expression as a whole. To achieve this, a single semantics element is used pairing two markup trees, with the first branch being the MathML presentation markup, and the second branch being the MathML content markup.

The following example encodes the boolean arithmetic expression (a+b)(c+d) in this way.

<semantics>

  <mrow>

    <mrow><mo>(</mo><mi>a</mi> <mo>+</mo> <mi>b</mi><mo>)</mo></mrow>

    <mo>&InvisibleTimes;</mo>

    <mrow><mo>(</mo><mi>c</mi> <mo>+</mo> <mi>d</mi><mo>)</mo></mrow>

  </mrow>

  <annotation-xml encoding="MathML-Content">

    <apply><and/>

      <apply><xor/><ci>a</ci> <ci>b</ci></apply>

      <apply><xor/><ci>c</ci> <ci>d</ci></apply>

    </apply>

  </annotation-xml>

</semantics>

This example is non-trivial ~~in the sense that~~ because the content markup could not be easily derived from the presentation markup alone.

5.3.2 Fine-grained Parallel Markup

Top-level pairing of independent presentation and content markup is sufficient for many, but not all, situations. Applications that allow treatment of sub-expressions of mathematical objects require the ability to associate presentation, content or information with the parts of an object with mathematical markup. Top-level pairing with a semantics element is insufficient in this type of situation; identification of a sub-expression in one branch of a semantics element gives no indication of the corresponding parts in other branches.

The ability to identify corresponding sub-expressions is required in applications such as mathematical expression editors. In this situation, selecting a sub-expression on a visual display can identify a particular portion of a presentation markup tree. The application then needs to determine the corresponding annotations of the sub-expressions; in particular, the application requires the sub-expressions of the annotation-xml tree in MathML content notation.

It is, in principle, possible to provide annotations for each presentation node by incorporating semantics elements recursively.

<semantics>

  <mrow>

    <semantics>

      <mrow><mo>(</mo><mi>a</mi> <mo>+</mo> <mi>b</mi><mo>)</mo></mrow>

      <annotation-xml encoding="MathML-Content">

        <apply><plus/><ci>a</ci> <ci>b</ci></apply>

      </annotation-xml>

    </semantics>

    <mo>&InvisibleTimes;</mo>

    <semantics>

      <mrow><mo>(</mo><mi>c</mi> <mo>+</mo> <mi>d</mi><mo>)</mo></mrow>

      <annotation-xml encoding="MathML-Content">

        <apply><plus/><ci>c</ci> <ci>d</ci></apply>

      </annotation-xml>

    </semantics>

  </mrow>

  <annotation-xml encoding="MathML-Content">

    <apply><times/>

      <apply><plus/><ci>a</ci> <ci>b</ci></apply>

      <apply><plus/><ci>c</ci> <ci>d</ci></apply>

    </apply>

  </annotation-xml>

</semantics>

To be complete this example would be much more verbose, wrapping each of the individual leaves mi, mo and mn in a further seven semantics elements.

This approach is very general and works for all kinds of annotations (including non-MathML annotations and multiple annotations). It leads, however, to an O(n log n) increase in the size of the document. This is therefore not a suitable approach for fine-grained parallel markup of large objects.

5.3.3 Parallel Markup via Cross-References: `id` and `xref`

To better accommodate applications that must deal with sub-expressions of large objects, MathML uses cross-references between the branches of a semantics element to identify corresponding sub-structures.

Cross-referencing is achieved using id and xref attributes within the branches of a containing semantics element. These attributes may optionally be placed on MathML elements of any type.

The following example shows this cross-referencing for the boolean arithmetic expression (a+b)(c+d).

<semantics>

  <mrow id="E">

    <mrow id="E.1">

      <mo id="E.1.1">(</mo>

      <mi id="E.1.2">a</mi>

      <mo id="E.1.3">+</mo>

      <mi id="E.1.4">b</mi>

      <mo id="E.1.5">)</mo>

    </mrow>

    <mo id="E.2">&InvisibleTimes;</mo>

    <mrow id="E.3">

      <mo id="E.3.1">(</mo>

      <mi id="E.3.2">c</mi>

      <mo id="E.3.3">+</mo>

      <mi id="E.3.4">d</mi>

      <mo id="E.3.5">)</mo>

    </mrow>

  </mrow>

  <annotation-xml encoding="MathML-Content">

    <apply xref="E">

      <and xref="E.2"/>

      <apply xref="E.1">

        <xor xref="E.1.3"/><ci xref="E.1.2">a</ci><ci xref="E.1.4">b</ci>

      </apply>

      <apply xref="E.3">

        <xor xref="E.3.3"/><ci xref="E.3.2">c</ci><ci xref="E.3.4">d</ci>

      </apply>

    </apply>

  </annotation-xml>

</semantics>

An id attribute and a corresponding xref appearing within the same semantics element create a correspondence between sub-expressions.

In creating these correspondences by cross-reference, all of the id attributes referenced by any xref must be in the same branch of an enclosing semantics element. This constraint guarantees that these correspondences do not create unintentional cycles. (Note that this restriction does not exclude the use of id attributes within the other branches of the enclosing semantics element. It does, however, exclude references to these other id attributes originating in the same semantics element.)

There is no restriction on which branch of the semantics element may contain the destination id attributes. It is up to the application to determine which branch to use.

In general, there will not be a one-to-one correspondence between nodes in parallel branches. For example, a presentation tree may contain elements, such as parentheses, that have no correspondents in the content tree. It is therefore often useful to put the id attributes on the branch with the finest-grained node structure. Then all of the other branches will have xref attributes to some subset of the id attributes.

In absence of other criteria, the first branch of the semantics element is a sensible choice to contain the id attributes. Applications that add or remove annotations will then not have to re-assign attributes to the semantics trees.

In general, the use of id and xref attributes allows a full correspondence between sub-expressions to be given in text that is at most a constant factor larger than the original. The direction of the references should not be taken to imply that sub-expression selection is intended to be permitted only on one child of the semantics element. It is equally feasible to select a subtree in any branch and to recover the corresponding subtrees of the other branches.

5.3.4 Annotation Cross-References using XLink: `id` and `href`

It is possible to give cross-references between a MathML expression and a non-MathML XML annotation using the XLink protocol [XLink]. As an example, the boolean expression of the previous section can be annotated with OpenMath, and cross-linked as follows:

<semantics>

  <mrow id="E">

    <mrow id="E.1">

      <mo id="E.1.1">(</mo>

      <mi id="E.1.2">a</mi>

      <mo id="E.1.3">+</mo>

      <mi id="E.1.4">b</mi>

      <mo id="E.1.5">)</mo>

    </mrow>

    <mo id="E.2">&InvisibleTimes;</mo>

    <mrow id="E.3">

      <mo id="E.3.1">(</mo>

      <mi id="E.3.2">c</mi>

      <mo id="E.3.3">+</mo>

      <mi id="E.3.4">d</mi>

      <mo id="E.3.5">)</mo>

    </mrow>

  </mrow>

  <annotation-xml encoding="MathML-Content">

    <apply xref="E">

      <and xref="E.2"/>

      <apply xref="E.1">

        <xor xref="E.1.3"/><ci xref="E.1.2">a</ci><ci xref="E.1.4">b</ci>

      </apply>

      <apply xref="E.3">

        <xor xref="E.3.3"/><ci xref="E.3.2">c</ci><ci xref="E.3.4">d</ci>

      </apply>

    </apply>

  </annotation-xml>

  <annotation-xml encoding="OpenMath"

                  xmlns:om="http://www.openmath.org/OpenMath"

                  xmlns:xlink="http://www.w3.org/1999/xlink">

    <om:OMA xlink:href="#xpointer(id('E'))" xlink:type="simple">

      <om:OMS name="and" cd="logic1"

              xlink:href="#xpointer(id('E.2'))" xlink:type="simple"/>

      <om:OMA xlink:href="#xpointer(id('E.1'))" xlink:type="simple">

        <om:OMS name="xor" cd="logic1"

                xlink:href="#xpointer(id('E.1.3'))" xlink:type="simple"/>

        <om:OMV name="a"

                xlink:href="#xpointer(id('E.1.2'))" xlink:type="simple"/>

        <om:OMV name="b"

                xlink:href="#xpointer(id('E.1.4'))" xlink:type="simple"/>

      </om:OMA>

      <om:OMA xlink:href="#xpointer(id('E.3'))" xlink:type="simple">

        <om:OMS name="xor" cd="logic1"

                xlink:href="#xpointer(id('E.3.3'))" xlink:type="simple"/>

        <om:OMV name="c"

                xlink:href="#xpointer(id('E.3.2'))" xlink:type="simple"/>

        <om:OMV name="d"

                xlink:href="#xpointer(id('E.3.4'))" xlink:type="simple"/>

      </om:OMA>

    </om:OMA>

  </annotation-xml>

</semantics>

: Here OMA, OMS and OMV are elements defined in the OpenMath standard for representing application, symbol and variable, respectively. The references from the OpenMath annotation are given by the xlink:href attributes which in this case use XPointer [XPointer] to refer to ids within the current document.

Note that the application might or might not have a mechanism for extending DTDs. It will therefore be the case, ~~therefore~~ that some applications will give well-formed, but not "valid", XML within annotation-xml elements. Consequently, some MathML applications using annotation-xml will not be validated. More flexibility is offered by the use of XML Schemas.

5.4 Notation Documents for Content to Presentation

As stated above, the definition of a new symbol or a new notation is common mathematical communication act. MathML-content supports this well through the usage of the csymbol element of the content-dictionaries; the need to convert a new symbol to presentation-MathML arises naturally.

For this purpose, MathML-3 proposes notation-documents which are exchangeable descriptions of a notation for new content-symbols. They are expected to be processed by rendering agents so as to render the MathML-content expressions, within the context of the user, for example, respecting the customs of his language or country.

5.4.1 Rendering Agent at Work

A rendering agent is a processor that, on behalf of a user, for example through an HTTP request, converts content-mathematical-expressions to presentation. We call this conversion, the delivery of the rendering agent. Typically, the delivery is happening within a user-interaction which lives within a context: information about this context can be multiple, it includes the preferred languages of the user, the preferred notational styles of the user or of the surrounding content. A rendering agent should be able to process arbitrary content expressions and should be able to do so even dynamically, encountering a fully new csymbol element, or being instructed to render a complex expression in a different way.

For this purpose, MathML-3 introduces four elements which allow to associate content-expressions (the prototype) to presentation-expressions (the rendering) together defining a mathematical notation. The notations are packaged in exchangeable files and can be dynamically discovered and incorporated.

A notation's prototype is an arbitrary content-MathML expression, which is said to match a content-MathML-expression if values can be assigned to the variables of the prototype so that, when replaced with these values, the prototype becomes equal to the expression. Within a notation, variables of the prototype that are not used in the rendering should be matched explicitly, with a variable of the same name. Below, we shall extend once more this definition of matching when explaining about support for arbitrary number of arguments.

5.4.2 Context Information

Information about a context that should discriminate the choice of a notation is encoded in context elements which encode the following suggested attributes:

Name	values	default
style-class	name-tokens, space separated
style-class	name-tokens, space separated
xml:lang	encodes a language for which this notation applies
format	encodes the mime-type of a target rendering	application/xml+mathml-presentation
deliveryPath	encodes part of the URL under which the current expression is being rendered

A context element may inherit from a parent context by simply accepting the attribute values of its parent for the attributes it does not have.

A context element is said to match for a rendering process if all of the attributes above are considered valid by the agent, i.e. if the language is deemed understandable by the user, if the format is supported, if the deliveryPath is a substring of the current delivery's address (if defined) or if a name within the style attributed is encoded as part of the current rendering styles (e.g. using class attributes in a parent element of the expression to be rendered).

5.4.3 Notation Elements and Processing

Notations are bundled in XML documents under notation-document element.

Name	values	default
cdbase	a URI specifying the base-URI from which all `symbol` references will be resolved.	(see ISSUE-13)

Notations are grouped within a notations element which groups a set of notation and is assigned a target, that is, the URI of a symbol that all notations mainly address.

The elements notations may contain one or more prototypes, in which case all notation elements contained there are alternate renderings of this prototype. If the notations element does not contain a prototype, its children notation elements should each have at least one. The notation-document, notations, and notation elements all accept a context child as defined above.

Conforming rendering-agents use a series of notation-documents to render arbitrary content-MathML-expressions within a given rendering context as follows:

starting from the root of the expression, identify the set of notations that have the most specialized prototypes and still match the root element among them choose the one whose context matches the rendering context under consideration
if two notations are still eligible, the one in the furthest notation-document in the list should be used
a notation is used by assigning to variables of the prototype the necessary sub-terms, by outputting the rendering of the notation with mi elements replaced with the rendering of the content-MathML-expressions of the variables of the same name.

A simple example is provided below, it describes the notations for the open real interval in English and other languages:

       <notations target="basic_content_elements#interval-oo">

            <math>

              <apply>

                <csymbol uri="basic_content_elements#interval-oo"/>

                <ci>a</ci>

                <ci>b</ci>

              </apply>

            </math>

            <notation>

              <context xml:lang="en"/>

              <math>

                <mrow>

                  <mo>(</mo>

                  <mi>a</mi>

                  <mo>,</mo>

                  <mi>b</mi>

                  <mo>)</mo>

                </mrow>

              </math>

            </notation>

            <notation>

              <context/>

              <math>

                <mrow>

                  <mo>]</mo>

                  <mi>a</mi>

                  <mo>,</mo>

                  <mi>b</mi>

                  <mo>[</mo>

                </mrow>

              </math>

            </notation>

          </notations>

Supposing a renderer would be working in an environment in French, had to render the following expression:

       <math><apply>

           <interval type="open"/>

           <apply><minus/><ci>a</ci><ci>ε</ci></apply>

           <apply><plus/><ci>a</ci><ci>ε</ci></apply>

         </apply></math>

It would be first converting this expression to canonical MathML, replacing, interval, plus, and minus, to the corresponding csymbol elements. Then it would choose the second notation above, since the english-language context does not match, would output:

                 <math>

                   <mrow>

                     <mo>]</mo>

                     <mo>,</mo>

                     <mo>[</mo>

                   </mrow>

                 </math>

then would replace the * with the rendering of <apply><minus/><ci>a</ci><ci>ε</ci></apply> and <apply><plus/><ci>a</ci><ci>ε</ci></apply>. Using the notation elements provided in basic_symbols.mcd (TODO: identify the proper relation), it could render, finally:

                 <math>

                   <mrow>

                     <mo>]</mo>

                     <mrow>a-ε</mrow>

                     <mo>,</mo>

                     <mrow>a+ε</mrow>

                     <mo>[</mo>

                   </mrow>

                 </math>

5.4.4 Precedence Rules and Bracket Output

In the process described above, no brackets have been necessary to disambiguate the expression. There are many cases, however, where brackets really appear to be needed in a presented formula and such a decision depends, not only, on the notation of an operation but on the relation between this notation and its child arguments.

MathML-3 adds precedence attributes to the notation elements (the parent precedence and to the mi elements (the child precedence), both of which are expected to be numbers between 0 and 1000. This allows rendering agents, rendering using a notation and starting to render a child term, represented by an mi element, to decide on fencing the term output if the two following conditions hold:

the mi element in the notation is child of row-like MathML-presentation element (see section 3.1.3, about inferred mrow)
the term is an application of an operation whose parent precedence is smaller than the child-precedence of the variable we are currently rendering

Terms that are not applications, for example ci or csymbol elements never require a bracket, and as such can be considered to have the highest precedence, 1000. mi elements that have no precedence element within a notation attribute.

For example, the following notation element could be used for the factorial (algebra-logic#factorial) operation:

     <notation target="algebra-logic#factorial" precedence="500">

          <math>

            <apply>

              <csymbol uri="algebra-logic#factorial"/>

              <ci>x</ci>

            </apply>

          </math>

          <math>

           <mrow><mi precedence="500">x</mi><mo>!</mo></mrow>

          </math>

        </notation>

rendering:

     <apply><factorial/><apply><plus><ci>x</ci><ci>y</ci></apply></apply>

would thus yield the application of the above notation composed with the application of the plus notation, of precedence 50, thus should output a bracket. But rendering:

    <apply><factorial/><apply><ci>x</ci></apply>

would apply the notation above but would not need to output a bracket to output the rendering of the x variable.

5.4.5 Support for Functions with Arbitrary Number of Arguments

Many operations take an arbitrary number of arguments. A special matching symbol is introduced as well as a special presentation element to iterate over such ranges.

The nary symbol, of the content-dictionary ntn is used with an application to match any number of elements where the apply element appears. It accepts an arbitrary number of arguments: if only one argument is provided, it should be a variable, a ci element, the name of the nary-matcher; if several arguments, are provided, they should all be applications of the nary-alt symbol to arbitrary expressions.

Variable-names within a notation element are expected to be distinct for each nary symbol application.

The nary symbol is best used in conjunction with the nary presentation element. The latter accepts two children, the first is a rendering of the argument and the second is a separator, a node that is copied between each of the multiple occurrences.

Rendering agents are expected to process nary presentation elements by finding the corresponding nary symbol application, i.e. that with the same variable name, and iterating over the matching terms, rendering them, interleaved with the separator.

A complex example is the plus symbol which, in many occidental languages, could have the following notation:

        <notation precedence="100">

          <math>

            <apply>

              <plus/>

              <apply>

                <csymbol uri="ntn#nary"/>

                <ci>term</ci>

              </apply>

            </apply>

          </math>

          <math>

            <nary>

              <mi>a</mi>

              <mo>+</mo>

            </nary>

          </math>

        </notation>

This method can be combined with extension matchers, for example matching single positive real-numbers in order to provide such notations as the rendering of a polynomial where the ⋅ operator is not visible between the coefficient and the monomial. Such extensions are out of scope of this specification, thus far.

5.5 Tools, Style Sheets and Macros for Combined Markup

The interaction of presentation and content markup can be greatly enhanced through the use of various tools. While the set of tools and standards for working with XML applications is rapidly evolving at ~~the~~ present, we can already outline some specific techniques.

In general, the interaction of content and presentation is handled via transformation rules on MathML trees. These transformation rules are sometimes called "macros". In principle, these rules can be expressed using any one of a number of mechanisms, including Document Style Semantics and Specification Language [DSSSL], Java programs operating on a DOM, etc. We anticipate, however, that the principal mechanism for these transformations in most applications ~~shall~~ will be XSLT.

In this section we discuss transformation rules for two specific purposes: for notational style sheets, and to simplify parallel markup.

5.5.1 Notational Style Sheets

Authors who make use of content markup may be required to deploy their documents in locales with notational conventions different than the default content rendering. It is therefore expected that transformation tools will be used to determine notations for content elements in different settings. Certain elements, e.g. lambda, mean and transpose, have widely varying common notations and will often require notational selection. Some examples of notational variations are given below.

· $\mathbf{V}$ versus $\vec{V}$

· tan x versus tg x

· ${n \choose m}$ versus ${}_nC^m$ versus versus

· $a_0 + \frac{ ~1 ~ |}{| ~a_1 ~} + \ldots + \frac{~1 ~ |}{| ~ a_k~}$ versus $[a_0, a_1, \ldots, a_k]$

Other elements, for example plus and cos, are less likely to require these features.

Selection of notational style is sometimes necessary for correct understanding of documents by locale. For instance, the binomial coefficient in French notation is equivalent to in Russian notation.

A natural way for a MathML application to bind a particular notation to the set of content tags is with an XSLT style sheet [XSLT]. The examples of this section ~~shall~~ will assume this is the mechanism to express style choices. (Other choices are equally possible, for example an application program may provide menus offering a number of rendering choices for all content tags.)

When writing XSLT style sheets for mathematical notation, some transformation rules can be purely local, while others will require multi-node context to determine the correct output notation. The following example gives a local transformation rule that could be included in a notational style sheet displaying open intervals as ]a,b[ rather than as (a,b).

<xsl:template match="m:interval">

  <m:mrow>

    <xsl:choose>

      <xsl:when test="@closure='closed'">

        <m:mfenced open="[" close="]" separators=",">

          <xsl:apply-templates/>

        </m:mfenced>

      </xsl:when>

      <xsl:when test="@closure='open'">

        <m:mfenced open="]" close="[" separators=",">

          <xsl:apply-templates/>

        </m:mfenced>

      </xsl:when>

      <xsl:when test="@closure='open-closed'">

        <m:mfenced open="]" close="]" separators=",">

          <xsl:apply-templates/>

        </m:mfenced>

      </xsl:when>

      <xsl:when test="@closure='closed-open'">

        <m:mfenced open="[" close="[" separators=",">

          <xsl:apply-templates/>

        </m:mfenced>

      </xsl:when>

      <xsl:otherwise>

        <m:mfenced open="[" close="]" separators=",">

          <xsl:apply-templates/>

        </m:mfenced>

      </xsl:otherwise>

    </xsl:choose>

  </m:mrow>

</xsl:template>

Here m is established as the MathML namespace.

An example of a rule requiring context information would be:

<xsl:template match="m:apply[m:factorial]">

  <m:mrow>

    <xsl:choose>

      <xsl:when test="not(*[2]=m:ci) and not(*[2]=m:cn)">

        <m:mrow>

          <m:mo>(</m:mo>

          <xsl:apply-templates select="*[2]" />

          <m:mo>)</m:mo>

        </m:mrow>

      </xsl:when>

      <xsl:otherwise>

        <xsl:apply-templates select="*[2]" />

      </xsl:otherwise>

    </xsl:choose>

    <m:mo>!</m:mo>

  </m:mrow>

</xsl:template>

Other examples of context-dependent transformations would be, e.g. for the apply of a plus to render a-b+c, rather than a+ -b+c, or for the apply of a power to render sin²x, rather than sin x².

Notational variation will occur both for built-in content elements as well as extensions. Notational style for extensions can be handled as described above, with rules matching the names of any extension tags, and with the content handling (in a content-faithful style sheet) proceeding as described in Section 5.5.3 Style Sheets for Extensions.

5.5.2 Content-Faithful Transformations

There may be a temptation to view notational style sheets as a transformation from content markup to equivalent presentation markup. This viewpoint is explicitly discouraged, since information will be lost and content-oriented applications will not function properly.

We define a "content-faithful" transformation to be a transformation that retains the original content in parallel markup (Section 5.3 Parallel Markup).

Tools that support MathML should be "content-faithful", and not gratuitously convert content elements to presentation elements in their processing. Notational style sheets should be content-faithful whenever they may be used in interactive applications.

It is possible to write content-faithful style sheets in a number of ways. Top-level parallel markup can be achieved by incorporating the following rules in an XSLT style sheet:

<xsl:template match="m:math">

   <m:semantics>

      <xsl:apply-templates/>

      <m:annotation-xml m:encoding="MathML-Content">

         <xsl:copy-of select="."/>

      </m:annotation-xml>

   </m:semantics>

</xsl:template>

The notation would be generated by additional rules for producing presentation from content, such as those in Section 5.5.1 Notational Style Sheets. Fine-grained parallel markup can be achieved with additional rules treating id attributes. A detailed example is given in [RodWatt2000].

5.5.3 Style Sheets for Extensions

The presentation tags of MathML form a closed vocabulary of notational structures, but are quite rich and can be used to express a rendering of most mathematical notations. Complex notations can be composed from the basic elements provided for presentation markup. In this sense, the presentation ability of MathML is open-ended. It is often useful, however, to give a name to new notational schemas if they are going to be used often. For example, we can shorten and clarify the ascending factorial example of Section 5.2.1 Reasons to Mix Markup, with a rule which replaces

<mx:a-factorial>X</mx:a-factorial>

with

<semantics>

   <apply> <factorial/> <ci>X</ci> </apply>

   <annotation-xml encoding="MathML-Presentation">

      <msup>

         <mn>1</mn>

         <mover accent="true">

            <mi>X</mi>

            <mo>&OverBar;</mo>

         </mover>

      </msup>

   </annotation-xml>

</semantics>

Then the example would be more clearly written as:

<apply>

  <equivalent/>

  <ci>n</ci>

  <apply>

     <divide/>

     <mx:a-factorial><ci>n</ci></mx:a-factorial>

     <mx:a-factorial>

        <apply><minus/><ci>n</ci><cn>1</cn></apply>

     </mx:a-factorial>

   </apply>

</apply>

Likewise, the content tags form a fixed vocabulary of concepts covering the types of mathematics seen in most common applications. It is not reasonable to expect users to ~~compose~~ use? existing MathML content tags to construct new content concepts. (This approach is fraught with technical difficulties even for professional mathematicians.) Instead, it is anticipated that applications whose mathematical content concepts extend beyond what is offered by MathML will use annotations and attributes within semantics and csymbol elements, and that these annotations will use content description languages outside of MathML.

Often the naming of a notation and the identification of a new semantic concept are related. This allows a single transformation rule to capture both a presentation and a content markup for an expression. This is one of the areas of MathML that benefits most ~~strongly~~ from the use of macro processing. For example,

<mx:rank/>

and

<mx:tr>X</mx:tr>

and respectively transform them to

<semantics>

   <ci><mo>rank</mo></ci>

   <annotation-xml encoding="OpenMath">

      <OMS name="rank" cd="linalg4" xmlns="http://www.openmath.org/OpenMath"/>

   </annotation-xml>

</semantics>

and

<apply>

 <transpose/>

 <ci>X</ci>

</apply>

The lengthy sample encoding of rank(u^Tv)=1, from Section 5.2.1 Reasons to Mix Markup could then be condensed to

<apply>

  <eq/>

  <apply>

    <mx:rank/>

    <apply> <times/> <mx:tr>u</mx:tr> <ci>v</ci> </apply>

   </apply>

  <cn>1</cn>

</apply>

From this example, we see how the combination of presentation and content markup could become much simpler and more effective to generate as standard style sheet libraries become available.

5.6 Combining MathML and Other Formats

5.6.1 Invoking MathML Processors: namespace and mime-types

Within an XML-based workflow, the preferred method to trigger the invocation of MathML markup is by the identification of the math element in the appropriate namespace, i.e that of URI http://www.w3.org/1998/Math/MathML.

This is the recommended method to embed MathML within [XHTML] documents. Some user-agents' setup may require supplementary information to be available, such as the MicroSoft behaviour specification (TODO: quote) used in the MathType browser-extension (TODO:quote).

Markup-language specification that ~~wish~~ wishes to embed MathML may provide special conditions independent of this recommendation. The conditions should be equivalent and the element local-names should remain the same.

MIME types [RFC2045], [RFC2046] offer an alternative strategy that can also be used in current user agents to invoke a MathML ~~processors~~ processor. This is primarily useful when referencing separate files containing MathML markup from an embed or object element, or within a desktop environment. [RFC3023] assigns MathML the MIME type application/mathml+xml. The W3C Math Working Group recommends the standard file extension .mml within a registry associating file-extension to mime-types.

Although rendering MathML expressions typically occurs in place in a Web browser, other MathML processing functions take place more naturally in other applications. Particularly common tasks include opening a MathML expression in an equation editor or computer algebra system.

(TODO: think, following two obsolete?) In MathML 1.0, text/mathml was given as the suggested MIME type. This has been superceded by RFC3023.

At present, there is no standard way of selecting between various applications which might be used to render or process embedded MathML. As work progresses on coordination between browsers and embedded elements and the Document Object Model [DOM], providing this kind of functionality should be a priority. Both authors and readers should be able to indicate a preference about what MathML application to use in a given context. For example, one might imagine that some mouse gesture over a MathML expression causes a browser to present the reader with a pop-up menu, showing the various kinds of MathML processing available on the system, and the MathML processors recommended by the author.

Since MathML is most often generated by authoring tools, it is particularly important that opening a MathML expression in an editor should be easy to do and to implement. In many cases, it will be desirable for an authoring tool to record some information about its internal state along with a MathML expression, so that an author can pick up editing where he or she left off. The following markup is proposed:

For any extra information that is expected to be semantically equivalent MathML-3 proposes the usage of the semantics element presented in Section 4.2.8 Semantic Mapping.
For ay extra information that cannot be declared as such, and is, expectedly private to the application. MathML-3 suggests to use the maction, see Section 3.6.1 Bind Action to Sub-Expression (maction)

Interested readers are encouraged to consult the W3C Metadata Activity for current information about metadata and resource definition.

Regardless of the methodology, implementors of embedded MathML processing applications are encouraged to ~~try to~~ allow for the following kinds of functionality:

· An author wishing to reach an audience as wide as possible might want MathML to be rendered by any available processor.

· An author targeting a specific audience might want to indicate that a particular MathML processor be used.

· A reader might wish to specify which of several available processors installed locally should be used.

5.6.2 Mixing MathML and HTML

In order to fully integrate MathML into XHTML, it should be possible not only to embed MathML in XHTML, but also to embed XHTML in MathML. However, the problem of supporting XHTML in MathML presents many difficulties. Therefore, at present, the MathML specification does not permit any XHTML elements within a MathML expression, although this may be subject to change in a future revision of MathML.

In most cases, XHTML elements (headings, paragraphs, lists, etc.) either do not apply in mathematical contexts, or MathML already provides equivalent or better functionality specifically tailored to mathematical content (tables, mathematics style changes, etc.). However, there are two notable exceptions, the XHTML anchor and image elements. For this functionality, MathML relies on the general XML linking and graphics mechanisms being developed by other W3C Activities.

5.6.3 Linking

Issue Linking-and-marking-ids	`wiki (member only)`
Linking and Marking IDs
We wish to stop using xlink for links since it seems unimplemented and add the necessary attributes at presentation elements.
Resolution	None recorded

MathML has no element that corresponds to the XHTML anchor element a. In XHTML, anchors are used both to make links, and to provide locations to which a link can be made. MathML, as an XML application, defines links by the use of the mechanism described in the W3C Recommendation "XML Linking Language" [XLink].

A MathML element is designated as a link by the presence of the attribute xlink:href. To use the attribute xlink:href, it is also necessary to declare the appropriate namespace. Thus, a typical MathML link might look like:

<mrow xmlns:xlink="http://www.w3.org/1999/xlink"

      xlink:href="sample.xml">

...

</mrow>

MathML designates that almost all elements can be used as XML linking elements. The only elements that cannot serve as linking elements are those such as the sep element, which exist primarily to disambiguate other MathML constructs and in general do not correspond to any part of a typical visual rendering. The full list of exceptional elements that cannot be used as linking elements is given in the table below.

MathML elements that cannot be linking elements
`mprescripts`	`none`	`sep`
`malignmark`	`maligngroup`

Note that the XML Linking [XLink] and XML Pointer Language [XPointer] specifications also define how to link into a MathML expressions. Be aware, however, that such links may or may not be properly interpreted in current software.

5.6.4 Images

The img element has no MathML equivalent. The decision to omit a general mechanism for image inclusion from MathML was based on several factors. However, the main reason for not providing an image facility is that MathML takes great pains to make the notational structure and mathematical content it encodes easily available to processors, whereas information contained in images is only available to a human reader looking at a visual representation. Thus, for example, in the MathML paradigm, it would be preferable to introduce new glyphs via the mglyph element which at a minimum identifies them as glyphs, rather than simply including them as images.

5.6.5 MathML and Graphical Markup

Apart from the introduction of new glyphs, many of the situations where one might be inclined to use an image amount to displaying labeled diagrams. For example, knot diagrams, Venn diagrams, Dynkin diagrams, Feynman diagrams and commutative diagrams all fall into this category. As such, their content would be better encoded via some combination of structured graphics and MathML markup. However, at the time of this writing, it is beyond the scope of the W3C Math Activity to define a markup language to encode such a general concept as "labeled diagrams." (See http://www.w3.org/Math for current W3C activity in mathematics and http://www.w3.org/Graphics for the W3C graphics activity.)

One mechanism for embedding additional graphical content is via the semantics element, as in the following example:

<semantics>

  <apply>

    <intersect/>

    <ci>A</ci>

    <ci>B</ci>

  </apply>

  <annotation-xml encoding="SVG1.1">

    <svg xmlns="http://www.w3.org/2000/svg"  viewBox="0 0 290 180">

      <clipPath id="a">

      <circle cy="90" cx="100" r="60"/>

      </clipPath>

      <circle fill="#AAAAAA" cy="90" cx="190"

              r="60" style="clip-path:url(#a)"/>

      <circle stroke="black" fill="none" cy="90" cx="100" r="60"/>

      <circle stroke="black" fill="none" cy="90" cx="190" r="60"/>

    </svg>

  </annotation-xml>

  <annotation-xml encoding="application/xhtml+xml">

    <img xmlns="http://www.w3.org/1999/xhtml" src="intersect.gif" alt="A intersect B"/>

  </annotation-xml>

</semantics>

Here, the annotation-xml elements are used to indicate alternative representations of the Content MathML depiction of the intersection of two sets. The first one is in the "Scalable Vector Graphics" format [SVG1.1] (see [XHTML-MathML-SVG] for the definition of an XHTML profile integrating MathML and SVG), the second one uses the XHTML img element embedded as an XHTML fragment. In this situation, a MathML processor can use any of these representations for display, perhaps producing a graphical format such as the image below.

$\includegraphics{intersect}$

Note that the semantics representation of this example is given in the Content MathML markup, as the first child of the semantics element. In this regard, it is the representation most analogous to the alt attribute of the img element in XHTML, and would likely be the best choice for non-visual rendering.

5.7 Using CSS with MathML

When MathML is rendered in an environment that supports [CSS], controlling mathematics style properties with a CSS stylesheet is obviously desirable. MathML 2.0 has significantly redesigned the way presentation element style properties are organized to facilitate better interaction between MathML renderers and CSS style mechanisms. It introduces four new mathematics style attributes with logical values. Roughly speaking, these attributes can be viewed as the proper selectors for CSS rules that affect MathML.

Controlling mathematics styling is not as simple as it might first appear because mathematics styling and text styling are quite different in character. In text, meaning is primarily carried by the relative positioning of characters next to one another to form words. Thus, although the font used to render text may impart nuances to the meaning, transforming the typographic properties of the individual characters leaves the meaning of text basically intact. By contrast, in mathematical expressions, individual characters in specific typefaces tend to function as atomic symbols. Thus, in the same equation, a bold italic 'x' and a normal italic 'x' are almost always intended to be two distinct symbols that mean different things. In traditional usage, there are eight basic typographical categories of symbols. These categories are described by mathematics style attributes, primarily the mathvariant attribute.

Text and mathematics layout also obviously differ in that mathematics uses 2-dimensional layout. As a result, many of the style parameters that affect mathematics layout have no textual analogs. Even in cases where there are analogous properties, the sensible values for these properties may not correspond. For example, traditional mathematical typography usually uses italic fonts for single character identifiers, and upright fonts for multicharacter identifier. In text, italicization does not usually depend on the number of letters in a word. Thus although a font-slant property makes sense for both mathematics and text, the natural default values are quite different.

Because of the difference between text and mathematics styling, only the styling aspects that do not affect layout are good candidates for CSS control. MathML 3.0 captures the most important properties with the new mathematics style attributes, and users should try to use them whenever possible over more direct, but less robust, approaches. A sample CSS stylesheet illustrating the use of the mathematical style attributes is available in Appendix E Sample CSS Style Sheet for MathML. Users should not count on MathML implementations to implement any other properties than those in the Font, Colors, and Outlines families of properties described in [CSS2] and implementations should only implement these properties within MathML-elements. Note that these prohibitions do not apply to CSS stylesheets that implement the MathML-CSS profile. (TODO: quote).

TODO: add equivalence statements and conflict resolution and stress that CSS changes should not be considered meaningful.

Generally speaking, the model for CSS interaction with the math style attributes runs as follows. A CSS style sheet might provide a style rule such as:

math *.[mathsize="small"] {

  font-size: 80%

This rule sets the CSS font-size properties for all children of the math element that have the mathsize attribute set to small. A MathML renderer would then query the style engine for the CSS environment, and use the values returned as input to its own layout algorithms. MathML does not specify the mechanism by which style information is inherited from the environment. However, some suggested rendering rules for the interaction between properties of the ambient style environment and MathML-specific rendering rules are discussed in Section 3.2.2 Mathematics style attributes common to token elements, and more generally throughout Chapter 3 Presentation Markup.

It should be stressed, however, that some caution is required in writing CSS stylesheets for MathML. Because changing typographic properties of mathematics symbols can change the meaning of an equation, stylesheet should be written in a way such that changes to document-wide typographic styles do not affect embedded MathML expressions. By using the MathML 2.0 mathematics style attributes as selectors for CSS rules, this danger is minimized.

Another pitfall to be avoided is using CSS to provide typographic style information necessary to the proper understanding of an expression. Expressions dependent on CSS for meaning will not be portable to non-CSS environments such as computer algebra systems. By using Un the logical values of the new MathML 3.0 mathematics style attributes as selectors for CSS rules, it can be assured that style information necessary to the sense of an expression is encoded directly in the MathML.

MathML 3.0 does not specify how a user agent should process style information, because there are many non-CSS MathML environments, and because different users agents and renderers have widely varying degrees of access to CSS information. In general, however, developers are urged to provide as much CSS support for MathML as possible.

Overview: Mathematical Markup Language (MathML) Version 3.0
Previous: 4 Content Markup
Next: 6 Characters, Entities and Fonts