Operator Dictionary

B. Operator Dictionary

Mathematical Markup Language (MathML) Version 2.0
A Parsing MathML
B Operator Dictionary
B.1 Format of operator dictionary entries
B.2 Indexing of operator dictionary
B.3 Choice of entity names
B.4 Notes on lspace and rspace attributes
B.5 Operator dictionary entries
C Content Markup Validation Grammar

The following table gives the suggested dictionary of rendering properties for operators, fences, separators, and accents in MathML, all of which are represented by mo elements. For brevity, all such elements will be called simply `operators' in this Appendix.

B.1. Format of operator dictionary entries

The operators are divided into groups, which are separated by blank lines in the listing below. The grouping, and the order of the groups, is significant for the proper grouping of subexpressions using <mrow> (Section 3.3.1); the rule described there is especially relevant to the automatic generation of MathML by conversion from other formats for displayed mathematics, such as T_EX, which do not always specify how subexpressions nest.

The format of the table entries is: the <mo> element content between double quotes (start and end tags not shown), followed by the attribute list in XML format, starting with the form attribute, followed by the default rendering attributes which should be used for mo elements with the given content and form attribute.

Any attribute not listed for some entry has its default value, which is given in parentheses in the table of attributes in section 3.2.4 [Operator, Fence, Separator or Accent].

Note that the characters & and < are represented in the following table entries by the entity references & and < respectively, as would be necessary if they appeared in the content of an actual mo element (or any other MathML or XML element).

For example, the first entry,

"(" form="prefix" fence="true" stretchy="true" lspace="0em" rspace="0em"

could be expressed as an mo element by:

<mo form="prefix" fence="true" stretchy="true" lspace="0em" rspace="0em"> ( </mo>

(note the lack of double quotes around the content, and the whitespace added around the content for readability, which is optional in MathML).

This entry means that, for MathML renderers which use this suggested operator dictionary, giving the element <mo form="prefix"> ( </mo> alone, or simply <mo> ( </mo> in a position for which form="prefix" would be inferred (see below), is equivalent to giving the element with all attributes as shown above.

B.2. Indexing of operator dictionary

Note that the dictionary is indexed not just by the element content, but by the element content and form attribute value, together. Operators with more than one possible form have more than one entry. The MathML specification describes how the renderer chooses (`infers') which form to use when no form attribute is given; see `Default value of form attribute' in Section 3.2.4.

Having made that choice, or with the form attribute explicitly specified in the <mo> element's start tag, the MathML renderer uses the remaining attributes from the dictionary entry for the appropriate single form of that operator, ignoring the entries for the other possible forms.

B.3. Choice of entity names

Extended characters in MathML (and in the operator dictionary below) are represented by XML-style entity references using the syntax &character-name; the complete list of characters and character names is given in Chapter 6. Many characters can be referred to by more than one name; often, memorable names composed of full words have been provided in MathML, as well as one or more names used in other standards, such as Unicode. The characters in the operators in this dictionary are generally listed under their full-word names when these exist. For example, the integral operator is named below by the one-character sequence &Integral;, but could equally well be named ∫. The choice of name for a given character in MathML has no effect on its rendering.

It is intended that every entity named below appears somewhere in Chapter 6. If this is not true, it is an error in this specification. If such an error exists, Chapter 6 should be taken as definitive, rather than this appendix.

B.4. Notes on `lspace` and `rspace` attributes

The values for lspace and rspace given here range from 0 to 6/18 em in units of 1/18 em. For the invisible operators whose content is ⁢ or ⁡, it is suggested that MathML renderers choose spacing in a context-sensitive way (which is an exception to the static values given in the following table). For <mo>⁡</mo>, the total spacing (lspace+rspace) in expressions such as `sin x' (where the right operand doesn't start with a fence) should be greater than zero; for <mo>⁢</mo>, the total spacing should be greater than zero when both operands (or the nearest tokens on either side, if on the baseline) are identifiers displayed in a non-slanted font (i.e. under the suggested rules, when both operands are multi-character identifiers).

Some renderers may wish to use no spacing for most operators appearing in scripts (i.e. when scriptlevel is greater than 0; see section 3.3.4 [Style Change]), as is the case in T_EX.

B.5. Operator dictionary entries