8 MathML3 Content Dictionaries

8.6.1 Notation Specifications

MathML specifies notations using a template-based mechanism. In essence, a notation specification is a pair consisting of schematic content MathML expression (called the prototype) together with a schematic presentation MathML expression (called the rendering). Schematic MathML expressions are expressions that can contain metavariables, and thus stand for a set of MathML expressions. A prototype/rendering pair directly specifies a correspondence between a set of content MathML expressions (those that match the prototype) and presentation MathML expressions (the result of instantiating the metavariables in the rendering with the pMathML expressions corresponding to the values of the matcher). Consider, for instance the following prototype/rendering pair:

<apply>                                       <mrow>
  <csymbol cd="algebra_logic" name="minus"/>    <mcd:render name="left"/>
  <mcd:expr name="left"/>                            <mo>-</mo>
  <mcd:expr name="right"/>                           <mcd:render name="right"/>      
</apply>                                      </mrow>

This specifies that any application expression whose first child is a "minus" symbol will correspond to an mrow with an infix "-" operator. The meta-variables in the prototype are represented by expr elements and by mcd:render elements in the rendering, they correspond if they share the value of the name attribute. Thus the content MathML expression

<apply><csymbol cd="algebra_logic" name="minus"/><cn>2</cn><cn>1</cn></apply>

corresponds to the presentation MathML expression

<mrow><mn>2</cn><mo>-</moL<mn>1</mn></mrow>

assuming a suitable correspondence for numbers.

MathML3 uses four elements for representing metavariables, i.e. named variables that stand for arbitrary MathML expression trees or tree lists: expr, exprlist, mcd:render, and iterate. The first two are called content metavariables and the latter two rendering metavariables. The expr and mcd:render elements are called element metavariables and stand for single MathML expressions, while the exprlist iterate elements are called sequence metavariables and stand for possibly empty sequences of MathML expressions. Content metavariables stand for (lists of) cMathML expressions whereas rendering metavariables stand for (lists of) pMathML expressions. Finally, we call a MathML expression schematic, if it contains one or more metavariables.

All metavariables carry the required name attribute, whose value is an XML name. The expr el is empty, and the exprlist can contain an arbitrary schematic cMathML expression. The mcd:rendering element contains an arbitrary sequence of schematic pMathML expressions. The iterate element carries the optional reverse attribute, whose values can be "yes" and "no". The body of the iterate element consists of a separator element arbitrary sequence of schematic pMathML expressions. Finally, the content of the separator element is a arbitrary sequence of schematic pMathML expressions.

Prototypes and renderings are represented by the mcd:prototype and mcd:rendering elements in notation specification. The former contains schematic content MathML expression with input metavariables, and the latter contains a schematic presentation MathML expression with rendering metavariables. A prototype may not contain two sibling exprlist elements and no two content metavariables may have the same name attribute. The mcd:prototype element carries the optional priority attribute whose value is a natural number; if the attribute is missing, the priority of the prototype defaults to 0. The mcd:rendering element carries the optional xml:lang, context, and variant attributes. The values of the xml:lang attribute are ISO 639 language specifiers. The values of the context and variant attribute are currently not specified and left to applications.

Intuitively, a cMathML expression E matches a prototype P, iff there is a mapping σ from metavariables in P to (lists of) cMathML expressions, such that if σ is applied to P, then the result is E. The formal definition of matching schematic content MathML expressions below is somewhat more complicated, since we need to take sequence metavariables into account, and the semantics elements have a built-in notion of flattening. For given E and P, we know that if E matches P, then σ is unique; it is called the matcher for E and P.

Let σ be a mapping from metavariable names to lists of MathML expressions. We say that a sequence E of cMathML expressions matches a sequence of prototypes P via σ, iff one of the following holds

1. P is a single expr metavariable with name n and σ(n)=E

2. P and E are flattened semantics elements, P' and E', their first children and the Q=Q(1) ... Q(n) and C=C(1)...C(n+k) are the sequences of those annotation-xml children of P and E whose keys have the role "semantic-annotation", sorted lexicographically via their cdbase cd, and name attributes. Then E matches P via σ, iff Q(i) match C(i+k) for 1⋜i⋜n, and <semantics>E' C(1) ... C(k-1)</semantics> matches P' σ.

3. P and E are single elements that have the same name, and the attributes of P is a subset of those of E and their values coincide, and the sequence of children of E matches that of P via σ.

4. P and E are sequences of the form P(1) ... P(n) and E(1) ... E(m) and

   1. none of the Pi is a sequence metavariable and n=m and

   2. all the E(i) match P(i) via σ.

5. P and E are sequences of the form P(1) ... P(n) and E(1) ... E(m) and

   1. P(j) is a exprlist element with name ν for some 1⋜j⋜n (thus none of the P(i) are by the no-sibling-constraint above).

   2. E(i) match P(i) via σ for i<j.

   3. E(n-i) match P(m-i) via σ for 1⋜i<n-j.

   4. σ(ν)=E(j) ... E(m-j)

   5. P(j) has children C=C(1) ... C(l) and m-n=kl

   6. σ(ν) matches the sequence given by the k-fold concatenation of C with itself via σ.

For given prototype P and expression E, we know that there is at most one mapping σ such that E matches P via σ.

A notation element usually occurs as part of a MMLdefinition element for its top symbol (i.e. the highest token or csymbol in the pattern expression trees). If it appears in some other context (e.g. as part of a user's notation preferences file), then it should reference the top symbol via the cd, name, and possibly cdbase attributes to ensure that it can be found by the rendering process.

For representation conciseness and manageability, MathML3 groups prototypes and renderings in notation elements. We call a list of mcd:rendering elements in a notation element a rendering block, iff it is delimited by mcd:prototype elements or the end tag of the notation element itself. No two mcd:rendering elements in a rendering block may have the same values for all three of the xml:lang, context, and variant attributes. We say that a cMathML expression selects the rendering block following the prototype with the highest priority among those that it matches.

Multiple mcd:prototype elements can be used e.g. to make a notation specification applicable to both strict and pragmatic cMathML expressions e.g. by adding a prototype involving the element <plus/> element. Multiple mcd:rendering elements in a rendering block can be used to model different notations or language conventions; they are differentiated by their xml:lang, context, and variant attributes. The xml:lang and context attributes allows to select a rendering variant via a global context. The former by language context to enable multilingual rendering. The selection mechanism of the context attribute is currently unspecified and left to applications. The variant attribute allows to select a notation variant locally on a cMathML element via its variant attribute. If a content element carries a class attribute and matches one of the prototypes of a notation element, then the mcd:rendering element whose variant attribute value has the same value will be chosen for rendering. (see Section 8.6.4 General Rules)

The intended meaning of a notation element is that a cMathML expression corresponds to that rendering in the selected rendering block that is suitable in the current context.

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

<notation cd="basic_content_elements" name="interval-oo">
  <mcd:prototype>
    <apply><interval type="open"/>
      <mcd:expr name="a"/>
      <mcd:expr name="b"/>
    </apply>
  </mcd:prototype>
  <mcd:prototype>
    <apply>
      <csymbol cd="basic_content_elements" name="interval-oo"/>
      <mcd:expr name="a"/>
      <mcd:expr name="b"/>
    </apply>
  </mcd:prototype>
  <mcd:rendering xml:lang="en">
    <math>
      <mrow>
        <mo>(</mo><mcd:render name="a"/><mo>,</mo><mcd:render name="b"/><mo>)</mo>
      </mrow>
    </math>
  </mcd:rendering>
  <mcd:rendering>
    <math>
      <mrow>
        <mo>]</mo><mcd:render name="a"/><mo>,</mo><mcd:render name="b"/><mo>[</mo>
      </mrow>
    </math>
  </mcd:rendering>
</notation>

The cMathML expression

<apply>
  <interval type="open"/>
  <apply><minus/><ci>n</ci><ci>ε</ci></apply>
  <apply><plus/><ci>n</ci><ci>ε</ci></apply>
</math>

matches the first prototype in the notation specification above. The matcher σ maps <arg name="a"/> to <apply><minus/><ci>n</ci><ci>ε</ci></apply> and <arg name="b"/> to <apply><minus/><ci>n</ci><ci>ε</ci></apply>. In a French language environment, the second mcd:rendering is selected, since the English notation in the first target does not apply. Therefore the cMathML expression renders to

<mrow><mo>]</mo><mrow>a-ε</mrow><mo>,</mo><mrow>a+ε</mrow><mo>[</mo></mrow>

assuming suitable notation specifications for plus and minus elements.

Multiple notation specifications per symbol are explicitly allowed, they can be used e.g. when writing a notation specification for the derivative which would be presented differently if applied on a simple function or a function defined using the lambda binding which indicates explicitly the variable of derivation. Thus the following notation specification with two rendering blocks is used:

<notation cd="calculus_veccalc" name="diff">
  <mcd:prototype>
    <apply>
      <csymbol cd="calculus_veccalc" name="diff"/>
      <bind>
        <csymbol name="basic_content_elements" name="lambda"/>
        <bvar><mcd:expr name="x"/></<bvar>
        <mcd:expr name="f"/>
      </bind>
    </apply>
  </mcd:prototype>
  <mcd:rendering>
    <mfrac>
      <mrow><mo>d</mo><mcd:render name="f"/></mrow>
      <mrow><mod>d</mod><mcd:render name="x"/></mrow>
    </mfrac>
  </mcd:rendering>
  <mcd:prototype>
    <apply>
      <csymbol cd="calculus_veccalc" name="diff"/>
      <mcd:expr name="f"/>
    </apply>
  </mcd:prototype>
  <mcd:rendering><mrow><mcd:render name="f"/><mo>'</mo></mrow></mcd:rendering>
</notation>

Many operations take an arbitrary number of arguments. These are modeled using schematic MathML expressions containing the exprlist metavariable, which matches a list of cMathML expressions in a prototype. In a mcd:rendering element, an exprlist element can contain arbitrary pMathML content. Consider for instance the notation specification for addition:

<notation cd="algebra_logic" name="plus">
  <mcd:prototype>
    <apply>
      <plus/>
      <mcd:exprlist name="summands">
	<mcd:expr name="sumand"/>
      </mcd:exprlist>
    </apply>
  </mcd:prototype>
  <mcd:rendering>
    <mcd:iterate name="summands">
      <separator><mo>+</mo></separator>
      <render name="summand"/>
    </iterate>
  </mcd:rendering>
</notation>

If we apply this notation specification to the cMathML expression

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

then the metavariable summands matches the list <ci>a</ci><ci>b</ci><ci>c</ci>. In this situation, rendering of the corresponding exprlist is the list of rendered elements interleaved by the content of the exprlist. In our case we obtain

<mi>a</mi><mo>+</mo><mi>b</mi><mo>+</mo><mi>c</mi>

To further fortify our intuition, let us consider a complex example. We want to render a content representation of a multiple integral expression e.g.:

<bind>
  <apply><int/><ci>P</ci><ci>Q</ci><ci>R</ci></apply>
  <bvar><ci>x</ci><ci>y</ci><ci>z</ci></bvar>
  <condition>
    <apply><and/>
      <apply><gt/><ci>x</ci><cn>1</cn></apply>
      <apply><gt/><ci>y</ci><cn>0</cn></apply>
      <apply><gt/><ci>z</ci><cn>-1</cn></apply>
    </apply>
  </condition>
  <apply><plus/>
    <ci>x</ci>
    <apply><times/>
      <cn>2</cn>
      <apply><power/><ci>y</ci><cn>2</cn></apply>
    </apply>
    <apply><times/>
      <cn>3</cn>
      <apply><power/><ci>z</ci><cn>3</cn></apply>
    </apply>
  </apply>
</bind>

The intended rendering

<mrow>
   <mtable rowalign="center">
     <mtr><mo>&#x222B;<!--INTEGRAL-->&#x222B;<!--INTEGRAL-->&#x222B;<!--INTEGRAL--></mo></mtr>
     <mtr><mi>P</mi><mi>Q</mi><mi>R</mi></mtr>
     <mrow>
       <mrow><mi>x</mi><mo>&#x3E;<!--GREATER-THAN SIGN--></mo><mn>1</mn></mrow> 
       <mo>&#x2227;<!--LOGICAL AND--></mo>
       <mrow><mi>y</mi><mo>&#x3E;<!--GREATER-THAN SIGN--></mo><mn>0</mn></mrow>
       <mo>&#x2227;<!--LOGICAL AND--></mo>
       <mrow><mi>z</mi><mo>&#x3E;<!--GREATER-THAN SIGN--></mo><mn>-1</mn></mrow>
    </mrow>
  </mtable>
  <mrow>
    <mi>x</mi>
    <mo>+</mo>
    <mrow><mn>2</mn><mo>&#x2062;<!--INVISIBLE TIMES--></mo><msup><mi>y</mi><mn>2</mn></msup></mrow>
    <mo>+</mo>
    <mrow><mn>3</mn><mo>&#x2062;<!--INVISIBLE TIMES--></mo><msup><mi>z</mi><mn>3</mn></msup></mrow>
  </mrow>
  <mrow><mo>d</mo><mi>x</mi><mo>d</mo><mi>y</mi><mo>d</mo><mi>z</mi></mrow>
</mrow>

can be obtained with the following notation specification:

<notation for="int">
  <mcd:prototype>
    <bind>
      <apply><int/>
	<mcd:exprlist name="sets"><mcd:expr name="set"/></mcd:exprlist>
      </apply>
      <bvar>
	<mcd:exprlist name="bvars"><mcd:expr name="bvar"/></mcd:exprlist>
      </bvar>
      <condition><mcd:expr="cond"/></condition>
      <mcd:expr name="scope"/>
    </bind>
  </mcd:prototype>
  <mcd:rendering>
    <mrow>
      <mtable rowalign="center">
        <mtr><mo><iterate name="sets"><separator>&#x222B;<!--INTEGRAL--></separator></iterate></mo></mtr>
        <mtr>
	  <iterate name="sets">
	    <separator><mo>&#xD7;<!--MULTIPLICATION SIGN--></mo></separator>
	    <mcd:render name="set"/>
	  </iterate>
	</mtr>
        <mcd:render name="cond"/>
      </mtable>
      <mcd:render name="scope"/>
      <iterate name="bvars"><mo>d</mo><mcd:render name="bvar"/></iterate>
    </mrow>
  </mcd:rendering>
</notation>

Note that the prototype picks up the structural backbone of the integral expression in the mcd:prototype element, and introduces metavariables for the variable parts of integral expressions. While matching the example, the meta variable sets is bound to the list P, Q, R of sets that are integrated over. This list is used twice in the rendering: once for generating the three integral glyphs in the integration operator (here we do not have a mcd:render element so the sets themselves are not rendered) and once in the cartesian product under the integration operator. The list of bound variables is picked up in the end of the rendering to generate the dx dy dz postfix.

The final example shows the use of non-empty exprlist metavariables

<mcd:notation>
  <mcd:prototype>
    <bind>
      <apply mcd:cr="multint"><int/>
        <mcd:exprlist name="domains">
          <apply>
            <interval mcd:cr="int"/>
            <mcd:expr name="lower_bound"/>
            <mcd:expr name="upper_bound"/>
          </apply>
        </mcd:exprlist>
      </apply>
      <bvars>
	<mcd:exprlist name="variables"><mcd:expr name="var"/></mcd:exprlist>
      </bvars>
      <condition><mcd:expr name="condition"/></condition>
      <mcd:expr name="body"/>
    </bind>
  </mcd:prototype>
  <mcd:rendering>
    <mrow>
      <msub mcd:cr="multint">
        <mrow>
          <mcd:iterate name="domains">
            <msubsup>
              <mo mcd:cr="int">&#x222B;<!--INTEGRAL--></mo>
      	      <mcd:render name="lower_bound"/>
    	      <mcd:render name="upper_bound"/>
            </msubsup>
          </mcd:iterate>
	</mrow>
        <mcd:render name="condition"/>
      </msub>
      <mcd:render name="body"/>
      <mcd:iterate name="variables" reverse="yes">
        <mo>d</mo>
        <mcd:render name="var"/>
      </mcd:iterate>
    </mrow>
  </mcd:rendering>
<mcd:notation>

This notation renders the cMathML expression

<bind>
  <apply><int/>
    <apply><interval/><ci>a</ci><ci>b</ci></apply>
    <apply><interval/><ci>c</ci><ci>d</ci></apply>
  </apply>
  <bvars><ci>x</ci><ci>y</ci></bvars>
  <condition><apply><gt/><ci>x</ci><ci>y</ci></apply></condition>
  <apply><ci>f</ci><ci>x</ci><ci>y</ci></apply>
</bind>

as

<mrow>
  <msub>
    <mrow>
      <msubsup><mo>&#x222B;<!--INTEGRAL--></mo><mi>a</mi><mi>b</mi></msubsup>
      <msubsup><mo>&#x222B;<!--INTEGRAL--></mo><mi>c</mi><mi>d</mi></msubsup>
    </mrow>
    <mrow><mi>x</mi><mo>&#x3E;<!--GREATER-THAN SIGN--></mo><mi>y</mi></mrow>
  </msub>
  <mrow><mi>f</mi><mo>(</mo><mi>x</mi><mi>y</mi><mo>)</mo></mrow>
  <mo>d</mo><mi>y</mi>
  <mo>d</mo><mi>x</mi>
</mrow>

Note that the matcher here consists of two mappings, one binds the top-level metavariables domain, variables, condition, and body, and the second one is indexed by the sequence variable domain and binds the metavariables lower_bound and upper_bound in its scope. The latter two can only be used in the rendering inside the iterate element that renders domains.

8.6.2 Precedence-based Elisions

In content MathML expressions, the function/argument relation is fully specified by the prefix notation in expression trees. In traditional mathematical notation, operator placement is much less restricted and brackets are used sparingly to disambiguate the functional structure. However, the use of brackets is usually restricted to cases, where the functional structure cannot be derived from the two-dimensional structure of the notations and conventions about binding strength of operators. This distribution of brackets has to be re-created to obtain high-quality renderings for cMathML expressions, and therefore the binding strengths have to be modeled in notation specifications.

To account for this MathML3 add an precedence attributes to the mcd:rendering element (to specify the the operator precedence) and the mcd:render and iterate elements (to specify the the argument precedence). The value of this attribute is an integer or +∞ or -∞. If the precedence attribute is not present on a mcd:rendering element, its operator precedence the default value 0. If the precedence attribute is not present on a mcd:render or iterate element the respective argument precedence is the same as the operator precedence.

The operator precedence allows rendering agents to decide on fencing the constructed rendering. Intuitively operators with larger precedence bind more strongly, so need not be fenced. Correspondingly, the rendering of an expression is enclosed in fences, iff the operator precedence is greater than the current precedence. For the next level of rendering this is set to the respective argument precedence of the rendering metavariable that triggers the recursive rendering. For top-level formulae renderings the current precedence has the default value 0. This ensures that outer brackets are usually elided, since most operators have positive operator precedence.

In MathML, fences are considered as a special case of semantic components that are subject to elision, i.e. components that can be left out of the presentation in certain situations. Even though brackets are the prime examples other components of mathematical formulae, e.g. bases of logarithms, are also commonly elided, if they can be derived from the context with little effort. In MathML, a component of a rendering is marked to be elidable by adding the mcd:egroup attribute. This attribute specifies the elision group. MathML reserves the values "fence" and "separator" for fences and separators in correpsondence to the attributes fence and separator (see Section 3.2.5 Operator, Fence, Separator or Accent (mo)). In a situation, where the current precedence is c and the operator precedence of the fence (i.e. the value of the precedence attribute on the notation element that contains it) is o, then the fence is given a visibility level of o-c (we take ∞-∞ to be ∞ to make fences visible for safety in this degenerate case). Rendering applications can specify other elision groups and give elidable components an explicit visibility level as integers using the mcd:elevel attribute. If none is given it defaults to the value 0.

Elision can take various forms in print and digital media. In static media like traditional print on paper or the PostScript format, we have to fix the elision level, and can decide at presentation time which elidable tokens will be printed and which will not. In this case, the presentation algorithm will take visibility thresholds T(g) for every elision group g as a user parameter and then elide (i.e. not render) all tokens in visibility group g with level l>T(g).

In an output format that is capable of interactively changing its appearance, e.g. dynamic XHTML+MathML (i.e. XHTML with embedded Presentation MathML formulae, which can be manipulated via JavaScript in browsers), an application can export the the information about elision groups and levels to the target format, and can then dynamically change the visibility thresholds by user interaction.

For example, the following notation element could be used for the factorial operator:

<notation cd="algebra-logic" name="factorial">
  <mcd:prototype>
    <apply><factorial/><mcd:expr name="arg"/></apply>
  </mcd:prototype>
  <mcd:rendering precedence="500">
    <mrow>
      <mo mcd:egroup="fence">(</mo>
        <mcd:render name="arg"/>
      <mo mcd:egroup="fence">)</mo>
      <mo>!</mo>
    </mrow>
  </mcd:rendering>
</notation>

In a situation with a current precedence (c) of 800 and a threshold T(fence)=0 the following cMathML expression

<apply>
  <csymbol cd="algebra-logic" name="#factorial"/>
  <apply><csymbol cd="algebra-logic" name="plus"/><ci>x</ci><ci>y</ci></apply>
</apply>

would be rendered by a static renderer as

<mrow>
  <mo>(</mo>
    <mrow><mi>x</mi><mo>+</mo><mi>y</mi></mrow>
  <mo>)</mo>
  <mo>!</mo>
</mrow>

assuming an operator precedence of 100 for the addition operator (the argument precedences do not matter here, since identifiers are never fenced): 500-800=-300<0, so the outer fences are elided, and 500-100=400>0, so the factorial fences are rendered. In a situation with a smaller current precedence e.g. 400, the outer fences would be rendered as well.

A dynamic renderer would pass the computed visibility levels to the rendering. In our situation with a current precedence of 800 we would obtain

<mo mcd:egroup="fence" mcd:elevel="-300">(</mo>
<mrow>
  <mo mcd:egroup="fence" mcd:elevel="400">(</mo>
    <mrow><mi>x</mi><mo>+</mo><mi>y</mi></mrow>
  <mo mcd:egroup="fence" mcd:elevel="400">)</mo>
  <mo>!</mo>
</mrow>
<mo mcd:egroup="fence" mcd:elevel="-300">)</mo>

Thus for a fencing threshold of 0 we would get the same result. With a user-given threshold larger than 400 (only components of a high visibility level are not elided) all fences would be elided, and with a threshold smaller than -300, all brackets would be made visible.

The requirement to have operator and argument precedences is probably most clearly seen in the case of binary associative operators we would use the following notation specification:

<notation cd="binary" name="plus">
  <mcd:prototype>
    <apply><csymbol cd="binary" name="plus"/>
      <mcd:expr name="left"/>
      <mcd:expr name="right"/>
    </apply>
  </mcd:prototype>
  <mcd:rendering  precedence="500">
    <mrow mcd:egroup="fence">
      <mo mcd:egroup="fence">(</mo>
        <mcd:render name="left" precedence="501"/>
	<mo>+</mo>
        <mcd:render name="right" precedence="501"/>
      <mo mcd:egroup="fence">)</mo>
    </mrow mcd:egroup="fence">
  </mcd:rendering>
</notation>

In fact the content MathML expression

 <apply><csymbol cd="binary" name="plus"/>
  <apply><csymbol cd="binary" name="plus"/>
    <ci>x</ci>
    <ci>y</ci>
    </apply>
  <apply><csymbol cd="binary" name="plus"/>
    <ci>z</ci>
    <ci>w</ci>
  </apply>
</apply>

would be rendered as

<mrow>
  <mi>x</mi>
  <mo>+</mo>
  <mi>y</mi>
  <mo>+</mo>
  <mi>z</mi>
  <mo>+</mo>
  <mi>w</mi>
</mrow>

Left- or right-associative binary operators (i.e. operators like the function space constructor that only elide parentheses in one of their arguments) are simply constructed by decreasing only one of their argument precedences.

8.6.3 Rendering Cross-References for Parallel Markup

The metavariable correspondence in notation elements is a good source for crossreferences in parallel markup with crossreferences (see Section 5.5.2 Parallel Markup via Cross-References: xml:id and xref): If the rendering application constructs parallel markup, then it can crossreference the top-level elements in corresponding prototype and rendering elements, as well as the metavariables that have the name value of the name element. If this is not enough, then additional crossreferencing opportunities can be specified by adding mcd:cr attributes with equal values to corresponding elements in the prototypes and renderings in a notation declaration. For instance, in above example we add cross-references for the multiple integral operator and for the integrals operators it is made up of. Note that mcd:cr attributes can be added to all MathML elements, but their values have to be unique in any prototype and rendering elements.

8.6.4 General Rules

In this section we will specify the default rendering of cMathML expressions that do not match any of the notation definitions given to the rendering function. The default renderings of pragmatic content MathML are given by the default rendering of the corresponding strict ones. We will go over the cases for strict MathML expressions in turn:

<apply>f a1 ... an</apply>

<mrow>
    F
    <mo mcd:egroup="fence" fence="true">(</mo>
    A1
    <mo mcd:egroup="separator" separator="true">,</mo>
    ...
    <mo mcd:egroup="separator" separator="true">,</mo>
    An
    <mo  mcd:egroup="fence" fence="true">)</mo>
</mrow>

<mcd:notation>
 <mcd:prototype>
    <apply>
       <mcd:expr name="fun"/>
       <mcd:exprlist name="args"><mcd:expr name="arg"/></mcd:exprlist>
    </apply>
 <mcd:prototype>
 <mcd:rendering>
    <mrow>
       <mcd:render name="fun"/>
       <mo fence="true">(</mo>
       <mcd:iterate name="args"/>
         <mcd:separator><mo separator="true">,</mo></mcd:separator>
	 <mcd:render name="arg"/>
       </mcd:iterate>
       <mo fence="true">)</mo>
   </mrow>
 <mcd:rendering>
</mcd:notation>

<bind>b<bvar>x1 ... xn</bvar>C S</bind>

<mrow>
  B
  x1
  <mo mcd:egroup="separator" separator="true">,</mo>
  ...
  <mo mcd:egroup="separator" separator="true">,</mo>
  xn
  <mo mcd:egroup="separator" separator="true">:</mo>
  C
  <mo mcd:egroup="separator" separator="true">.</mo>
  S
</mrow>

<mcd:notation>
 <mcd:prototype>
    <bind>
       <mcd:expr name="bex"/>
       <bvar><exprlist name="bvars"><expr name="bvar"/></mcd:exprlist>
       <condition><mcd:expr name="condition"/></condition>
       <mcd:expr name="body"/>
    </bind>
 <mcd:prototype>
 <mcd:rendering>
   <mrow>
     <mcd:render name="bex"/>
     <mcd:iterate name="bvars"/>
       <mcd:separator><mo mcd:egroup="separator" separator="true">,</mo></mcd:separator>
       <mcd:render name="bvar"/>
     </mcd:iterate>
     <mo mcd:egroup="separator" separator="true">:</mo>
     <mcd:render name="condition"/>
     <mo mcd:egroup="separator" separator="true">.</mo>
     <mcd:render name="body"/>
   </mrow>
 <mcd:rendering>
 <mcd:prototype>

       <mcd:expr name="bex"/>
       <bvar><exprlist name="bvars"><expr name="bvar"/></mcd:exprlist>
       <mcd:expr name="body"/>
    </bind>
 <mcd:prototype>
 <mcd:rendering>
   <mrow>
     <mcd:render name="bex"/>
     <mcd:iterate name="bvars"/>
       <mcd:separator><mo mcd:egroup="separator" separator="true">,</mo></mcd:separator>
       <mcd:render name="bvar"/>
     </mcd:iterate>
     <mo mcd:egroup="separator" separator="true">.</mo>
     <mcd:render name="body"/>
   </mrow>
 <mcd:rendering>
</mcd:notation>

8.6.5 Limitations and Extensions of Notation Documents

The elements proposed in this section provide a basis for exchangeable notation-documents which can be processed by rendering agents for the conversion of content-elements, to presentation MathML.

There is a great wealth of conversion tools from content to presentation. Compared to hand-written XSLT stylesheets, such as ctop.xsl (TODO: quote), the expression matching is quite poor and the programming facilities are almost nonexistent (thus it seems not possible, yet, to specify that the 7 in is computed automatically), the approach of notation-documents is more declarative and opens the door to exchangeability, moreover, it has the potential to respect user and language-dependent notations.

For the many more dynamic rendering agents, which includes all content-oriented input-editors, notation-documents may be a good way to render dynamically symbols just found on the web.