Mathematical Markup Language (MathML) Version 4.0

W3C Editor's Draft

More details about this document
This version:
https://w3c.github.io/mathml/
Latest published version:
https://www.w3.org/TR/mathml4/
Latest editor's draft:
https://w3c.github.io/mathml/
History:
https://www.w3.org/standards/history/mathml4/
Commit history
Editor:
David Carlisle (NAG)
Former editors:
Patrick Ion
Robert Miner (deceased)
Feedback:
GitHub w3c/mathml (pull requests, new issue, open issues)
Latest MathML Recommendation
https://www.w3.org/TR/MathML/

Abstract

This specification defines the Mathematical Markup Language, or MathML. MathML is a markup language for describing mathematical notation and capturing both its structure and content. The goal of MathML is to enable mathematics to be served, received, and processed on the World Wide Web, just as [HTML] has enabled this functionality for text.

This specification of the markup language MathML is intended primarily for a readership consisting of those who will be developing or implementing renderers or editors using it, or software that will communicate using MathML as a protocol for input or output. It is not a User's Guide but rather a reference document.

MathML can be used to encode both mathematical notation and mathematical content. About thirty-eight of the MathML tags describe abstract notational structures, while another about one hundred and seventy provide a way of unambiguously specifying the intended meaning of an expression. Additional chapters discuss how the MathML content and presentation elements interact, and how MathML renderers might be implemented and should interact with browsers. Finally, this document addresses the issue of special characters used for mathematics, their handling in MathML, their presence in Unicode, and their relation to fonts.

While MathML is human-readable, authors typically will use equation editors, conversion programs, and other specialized software tools to generate MathML. Several versions of such MathML tools exist, both freely available software and commercial products, and more are under development.

MathML was originally specified as an XML application and most of the examples in this specification assume that syntax. Other syntaxes are possible, most notably [HTML] specifies the syntax for MathML in HTML. Unless explicitly noted, the examples in this specification are also valid HTML syntax.

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

Public discussion of MathML and issues of support through the W3C for mathematics on the Web takes place on the public mailing list of the Math Working Group (list archives). To subscribe send an email to www-math-request@w3.org with the word subscribe in the subject line. Alternatively, report an issue at this specification's GitHub repository.

A fuller discussion of the document's evolution can be found in I. Changes.

Some sections are collapsed and may be expanded to reveal more details. The following button may be used to expand all such sections.

This document was published by the Math Working Group as an Editor's Draft.

Publication as an Editor's Draft does not imply endorsement by W3C and its Members.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 12 June 2023 W3C Process Document.

Issue summary

1. Introduction

This section is non-normative.

1.1 Mathematics and its Notation

Mathematics and its notations have evolved over several centuries, or even millennia. To the experienced reader, mathematical notation conveys a large amount of information quickly and compactly. And yet, while the symbols and arrangements of the notations have a deep correspondence to the semantic structure and meaning of the mathematics being represented, the notation and semantics are not the same. The semantic symbols and structures are subtly distinct from those of the notation.

Thus, there is a need for a markup language which can represent both the traditional displayed notations of mathematics, as well as its semantic content. While the traditional rendering is useful to sighted readers, the markup language must also support accessibility. The semantic forms must support a variety of computational purposes. Both forms should be appropriate to all educational levels from elementary to research.

1.2 Overview

MathML is a markup language for describing mathematics. It uses XML syntax when used standalone or within other XML, or HTML syntax when used within HTML documents. Conceptually, MathML consists of two main strains of markup: Presentation markup is used to display mathematical expressions; and Content markup is used to convey mathematical meaning. These two strains, along with other external representations, can be combined using parallel markup.

This specification is organized as follows: 2. MathML Fundamentals discusses Fundamentals common to Presentation and Content markup; 3. Presentation Markup and 4. Content Markup cover Presentation and Content markup, respectively; 5. Annotating MathML: intent discusses how markup may be annotated, particularly for accessibility; 6. Annotating MathML: semantics discusses how markup may be annotated so that Presentation, Content and other formats may be combined; 7. Interactions with the Host Environment addresses how MathML interacts with applications; Finally, a discussion of special symbols, and issues regarding characters, entities and fonts, is given in 8. Characters, Entities and Fonts.

1.3 Relation to MathML Core

The specification of MathML is developed in two layers. MathML Core ([MathML-Core]) covers (most of) Presentation Markup, with the focus being the precise details of displaying mathematics in web browsers. MathML Full, this specification, extends MathML Core primarily by defining Content MathML, in 4. Content Markup. It also defines extensions to Presentation MathML consisting of additional attributes, elements or enhanced syntax of attributes. These are defined for compatibility with legacy MathML, as well as to cover 3.1.7 Linebreaking of Expressions, 3.6 Elementary Math and other aspects not included in level 1 of MathML Core but which may be incorporated into future versions of MathML Core.

This specification covers both MathML Core and its extensions; features common to both are indicated with , whereas extensions are indicated with .

It is intended that MathML Full is a proper superset of MathML Core. Moreover, it is intended that any valid Core Markup be considered as valid Full Markup as well. It is also intended that an otherwise conforming implementation of MathML Core, which also implements parts or all of the extensions of MathML Full, should continue to be considered a conforming implementation of MathML Core.

1.4 MathML Notes

In addition to these two specifications, the Math WG group has developed the non-normative Notes on MathML that contains additional examples and information to help understand best practices when using MathML.

2. MathML Fundamentals

2.1 MathML Syntax and Grammar

2.1.1 General Considerations

The basic ‘syntax’ of MathML is defined using XML syntax, but other syntaxes that can encode labeled trees are possible. Notably the HTML parser may also be used with MathML. Upon this, we layer a ‘grammar’, being the rules for allowed elements, the order in which they can appear, and how they may be contained within each other, as well as additional syntactic rules for the values of attributes. These rules are defined by this specification, and formalized by a RelaxNG schema [RELAXNG-SCHEMA] in A. Parsing MathML. Derived schema in other formats, DTD (Document Type Definition) and XML Schema [XMLSchemas] are also provided.

MathML's character set consists of any Unicode characters [Unicode] allowed by the syntax being used. (See for example [XML] or [HTML].) The use of Unicode characters for mathematics is discussed in 8. Characters, Entities and Fonts.

The following sections discuss the general aspects of the MathML grammar as well as describe the syntaxes used for attribute values.

2.1.2 MathML and Namespaces

An XML namespace [Namespaces] is a collection of names identified by a URI. The URI for the MathML namespace is:

http://www.w3.org/1998/Math/MathML

To declare a namespace when using the XML serialisation of MathML, one uses an xmlns attribute, or an attribute with an xmlns prefix.

<math xmlns="http://www.w3.org/1998/Math/MathML">
  <mrow>...</mrow>
</math>

When the xmlns attribute is used as a prefix, it declares a prefix which can then be used to explicitly associate other elements and attributes with a particular namespace. When embedding MathML within HTML using XML syntax, one might use:

<body xmlns:m="http://www.w3.org/1998/Math/MathML">
  ...
  <m:math><m:mrow>...</m:mrow></m:math>
  ...
</body>

HTML does not support namespace extensibility in the same way. The HTML parser has in-built knowledge of the HTML, SVG, and MathML namespaces. xmlns attributes are just treated as normal attributes. Thus, when using the HTML serialisation of MathML, prefixed element names must not be used. xmlns=http://www.w3.org/1998/Math/MathML may be used on the math element; it will be ignored by the HTML parser. If a MathML expression is likely to be in contexts where it may be parsed by an XML parser or an HTML parser, it SHOULD use the following form to ensure maximum compatibility:

<math xmlns="http://www.w3.org/1998/Math/MathML">
  ...
</math>

2.1.3 Children versus Arguments

There are presentation elements that conceptually accept only a single argument, but which for convenience have been written to accept any number of children; then we infer an mrow containing those children which acts as the argument to the element in question; see 3.1.3.1 Inferred <mrow>s.

In the detailed discussions of element syntax given with each element throughout the MathML specification, the number of arguments required and their order, as well as other constraints on the content, are specified. This information is also tabulated for the presentation elements in 3.1.3 Required Arguments.

2.1.4 MathML and Rendering

Web Platform implementations of [MathML-Core] should follow the detailed layout rules specified in that document.

This document only recommends (i.e., does not require) specific ways of rendering Presentation MathML; this is in order to allow for medium-dependent rendering and for implementations not using the CSS based Web Platform.

2.1.5 MathML Attribute Values

MathML elements take attributes with values that further specialize the meaning or effect of the element. Attribute names are shown in a monospaced font throughout this document. The meanings of attributes and their allowed values are described within the specification of each element. The syntax notation explained in this section is used in specifying allowed values.

2.1.5.1 Syntax notation used in the MathML specification

To describe the MathML-specific syntax of attribute values, the following conventions and notations are used for most attributes in the present document.

Notation What it matches
unsigned-integer As defined in [MathML-Core], an integer, whose first character is neither U+002D HYPHEN-MINUS character (-) nor U+002B PLUS SIGN (+).
positive-integer An unsigned-integer not consisting solely of "0"s (U+0030), representing a positive integer
integer an optional "-" (U+002D), followed by an unsigned-integer, and representing an integer
unsigned-number value as defined in [CSS-VALUES-3] number, whose first character is neither U+002D HYPHEN-MINUS character (-) nor U+002B PLUS SIGN (+), representing a non-negative terminating decimal number (a type of rational number)
number an optional prefix of "-" (U+002D), followed by an unsigned number, representing a terminating decimal number (a type of rational number)
character a single non-whitespace character
string an arbitrary, nonempty and finite, string of characters
length a length, as explained below, 2.1.5.2 Length Valued Attributes
namedspace a named length, namedspace, as explained in 2.1.5.2 Length Valued Attributes
color a color, using the syntax specified by [CSS-Color-3]
id an identifier, unique within the document; must satisfy the NAME syntax of the XML recommendation [XML]
idref an identifier referring to another element within the document; must satisfy the NAME syntax of the XML recommendation [XML]
URI a Uniform Resource Identifier [RFC3986]. Note that the attribute value is typed in the schema as anyURI which allows any sequence of XML characters. Systems needing to use this string as a URI must encode the bytes of the UTF-8 encoding of any characters not allowed in URI using %HH encoding where HH are the byte value in hexadecimal. This ensures that such an attribute value may be interpreted as an IRI, or more generally a LEIRI; see [IRI].
italicized word values as explained in the text for each attribute; see 2.1.5.3 Default values of attributes
"literal" quoted symbol, literally present in the attribute value (e.g. "+" or '+')

The ‘types’ described above, except for string, may be combined into composite patterns using the following operators. The whole attribute value must be delimited by single (') or double (") quotation marks in the marked up document. Note that double quotation marks are often used in this specification to mark up literal expressions; an example is the "-" in line 5 of the table above.

In the table below a form f means an instance of a type described in the table above. The combining operators are shown in order of precedence from highest to lowest:

Notation What it matches
(f) same f
f? an optional instance of f
f* zero or more instances of f, with separating whitespace characters
f+ one or more instances of f, with separating whitespace characters
f1f2 fn one instance of each form fi, in sequence, with no separating whitespace
f1,f2, ,fn one instance of each form fi, in sequence, with separating whitespace characters (but no commas)
f1|f2| |fn any one of the specified forms fi

The notation we have chosen here is in the style of the syntactical notation of the RelaxNG used for MathML's basic schema, A. Parsing MathML.

Since some applications are inconsistent about normalization of whitespace, for maximum interoperability it is advisable to use only a single whitespace character for separating parts of a value. Moreover, leading and trailing whitespace in attribute values should be avoided.

For most numerical attributes, only those in a subset of the expressible values are sensible; values outside this subset are not errors, unless otherwise specified, but rather are rounded up or down (at the discretion of the renderer) to the closest value within the allowed subset. The set of allowed values may depend on the renderer, and is not specified by MathML.

If a numerical value within an attribute value syntax description is declared to allow a minus sign ('-'), e.g., number or integer, it is not a syntax error when one is provided in cases where a negative value is not sensible. Instead, the value should be handled by the processing application as described in the preceding paragraph. An explicit plus sign ('+') is not allowed as part of a numerical value except when it is specifically listed in the syntax (as a quoted '+' or "+"), and its presence can change the meaning of the attribute value (as documented with each attribute which permits it).

2.1.5.2 Length Valued Attributes

Most presentation elements have attributes that accept values representing lengths to be used for size, spacing or similar properties. [MathML-Core] accepts lengths only in the <length-percentage> syntax defined in [CSS-VALUES-3]. MathML Full extends length syntax by accepting also a namedspace being one of:

Positive spaceNegative spaceValue
veryverythinmathspace negativeveryverythinmathspace ±1/18 em
verythinmathspace negativeverythinmathspace ±2/18 em
thinmathspace negativethinmathspace ±3/18 em
mediummathspace negativemediummathspace ±4/18 em
thickmathspace negativethickmathspace ±5/18 em
verythickmathspace negativeverythickmathspace ±6/18 em
veryverythickmathspace negativeveryverythickmathspace ±7/18 em

In addition, the attributes on mpadded allow three pseudo-units, height, depth, and width (taking the place of one of the usual CSS units) denoting the original dimensions of the content.

MathML 3 also allowed a deprecated usage with lengths specified as a number without a unit. This was interpreted as a multiple of the reference value. This form is considered invalid in MathML 4.

2.1.5.2.1 Additional notes about units

Two additional aspects of relative units must be clarified, however. First, some elements such as 3.4 Script and Limit Schemata or mfrac implicitly switch to smaller font sizes for some of their arguments. Similarly, mstyle can be used to explicitly change the current font size. In such cases, the effective values of an em or ex inside those contexts will be different than outside. The second point is that the effective value of an em or ex used for an attribute value can be affected by changes to the current font size. Thus, attributes that affect the current font size, such as mathsize and scriptlevel, must be processed before evaluating other length valued attributes.

2.1.5.3 Default values of attributes

Default values for MathML attributes are, in general, given along with the detailed descriptions of specific elements in the text. Default values shown in plain text in the tables of attributes for an element are literal, but when italicized are descriptions of how default values can be computed.

Default values described as inherited are taken from the rendering environment, as described in 3.3.4 Style Change <mstyle>, or in some cases (which are described individually) taken from the values of other attributes of surrounding elements, or from certain parts of those values. The value used will always be one which could have been specified explicitly, had it been known; it will never depend on the content or attributes of the same element, only on its environment. (What it means when used may, however, depend on those attributes or the content.)

Default values described as automatic should be computed by a MathML renderer in a way which will produce a high-quality rendering; how to do this is not usually specified by the MathML specification. The value computed will always be one which could have been specified explicitly, had it been known, but it will usually depend on the element content and possibly on the context in which the element is rendered.

Other italicized descriptions of default values which appear in the tables of attributes are explained individually for each attribute.

The single or double quotes which are required around attribute values in an XML start tag are not shown in the tables of attribute value syntax for each element, but are around attribute values in examples in the text, so that the pieces of code shown are correct.

Note that, in general, there is no mechanism in MathML to simulate the effect of not specifying attributes which are inherited or automatic. Giving the words inherited or automatic explicitly will not work, and is not generally allowed. Furthermore, the mstyle element (3.3.4 Style Change <mstyle>) can even be used to change the default values of presentation attributes for its children.

Note also that these defaults describe the behavior of MathML applications when an attribute is not supplied; they do not indicate a value that will be filled in by an XML parser, as is sometimes mandated by DTD-based specifications.

In general, there are a number of properties of MathML rendering that may be thought of as overall properties of a document, or at least of sections of a large document. Examples might be mathsize (the math font size: see 3.2.2 Mathematics style attributes common to token elements), or the behavior in setting limits on operators such as integrals or sums (e.g., movablelimits or displaystyle), or upon breaking formulas over lines (e.g. linebreakstyle); for such attributes see several elements in 3.2 Token Elements. These may be thought to be inherited from some such containing scope. Just above we have mentioned the setting of default values of MathML attributes as inherited or automatic; there is a third source of global default values for behavior in rendering MathML, a MathML operator dictionary. A default example is provided in B. Operator Dictionary. This is also discussed in 3.2.5.6.1 The operator dictionary and examples are given in 3.2.5.2.1 Dictionary-based attributes.

2.1.6 Attributes Shared by all MathML Elements

In addition to the attributes described specifically for each element, the attributes in the following table are allowed on every MathML element. Also allowed are attributes from the xml namespace, such as xml:lang, and attributes from namespaces other than MathML, which are ignored by default.

Name values default
id id none
Establishes a unique identifier associated with the element to support linking, cross-references and parallel markup. See xref and 6.9 Parallel Markup.
xref idref none
References another element within the document. See id and 6.9 Parallel Markup.
class string none
Associates the element with a set of style classes for use with [CSS21]. See 7.5 Using CSS with MathML for discussion of the interaction of MathML and CSS.
style string none
Associates style information with the element for use with [CSS21]. See 7.5 Using CSS with MathML for discussion of the interaction of MathML and CSS.
href URI none
Can be used to establish the element as a hyperlink to the specified URI.

All MathML presentation elements accept intent and arg attributes to support specifying intent. These are more fully described in 5. Annotating MathML: intent.

Name values default
intent intent expression none
The intent attribute is more fully described in 5. Annotating MathML: intent. It may be used on presentation elements to give information about the intended meaning of the expression, mainly for guiding audio or braille accessible renderings.
arg name none
The arg attribute is more fully described in 5. Annotating MathML: intent. It may be used to name an element to be referenced from an intent expression on an ancestor element.

See also 3.2.2 Mathematics style attributes common to token elements for a list of MathML attributes which can be used on most presentation token elements.

The attribute other is deprecated (D.3 Attributes for unspecified data) in favor of the use of attributes from other namespaces.

Name values default
other string none
DEPRECATED but in MathML 1.0.

2.1.7 Collapsing Whitespace in Input

In MathML, as in XML, whitespace means simple spaces, tabs, newlines, or carriage returns, i.e., characters with hexadecimal Unicode codes U+0020, U+0009, U+000A, or U+000D, respectively; see also the discussion of whitespace in Section 2.3 of [XML].

MathML ignores whitespace occurring outside token elements. Non-whitespace characters are not allowed there. Whitespace occurring within the content of token elements, except for <cs>, is normalized as follows. All whitespace at the beginning and end of the content is removed, and whitespace internal to content of the element is collapsed canonically, i.e., each sequence of 1 or more whitespace characters is replaced with one space character (U+0020, sometimes called a blank character).

For example, <mo> ( </mo> is equivalent to <mo>(</mo>, and

 <mtext>
Theorem
1:
 </mtext>
Theorem 1:

is equivalent to <mtext>Theorem 1:</mtext> or <mtext>Theorem&#x20;1:</mtext>.

Authors wishing to encode white space characters at the start or end of the content of a token, or in sequences other than a single space, without having them ignored, must use non-breaking space U+00A0 (or nbsp) or other non-marking characters that are not trimmed. For example, compare the above use of an mtext element with

 <mtext>
&#x00A0;<!--nbsp-->Theorem &#x00A0;<!--nbsp-->1:
 </mtext>
 Theorem  1:

When the first example is rendered, there is nothing before Theorem, one Unicode space character between Theorem and 1:, and nothing after 1:. In the second example, a single space character is to be rendered before Theorem; two spaces, one a Unicode space character and one a Unicode no-break space character, are to be rendered before 1:; and there is nothing after the 1:.

Note that the value of the xml:space attribute is not relevant in this situation since XML processors pass whitespace in tokens to a MathML processor; it is the requirements of MathML processing which specify that whitespace is trimmed and collapsed.

For whitespace occurring outside the content of the token elements mi, mn, mo, ms, mtext, ci, cn, cs, csymbol and annotation, an mspace element should be used, as opposed to an mtext element containing only whitespace entities.

2.2 The Top-Level <math> Element

MathML specifies a single top-level or root math element, which encapsulates each instance of MathML markup within a document. All other MathML content must be contained in a math element; in other words, every valid MathML expression is wrapped in outer <math> tags. The math element must always be the outermost element in a MathML expression; it is an error for one math element to contain another. These considerations also apply when sub-expressions are passed between applications, such as for cut-and-paste operations; see 7.3 Transferring MathML.

The math element can contain an arbitrary number of child elements. They render by default as if they were contained in an mrow element.

2.2.1 Attributes

The math element accepts any of the attributes that can be set on 3.3.4 Style Change <mstyle>, including the common attributes specified in 2.1.6 Attributes Shared by all MathML Elements. In particular, it accepts the dir attribute for setting the overall directionality; the math element is usually the most useful place to specify the directionality (see 3.1.5 Directionality for further discussion). Note that the dir attribute defaults to ltr on the math element (but inherits on all other elements which accept the dir attribute); this provides for backward compatibility with MathML 2.0 which had no notion of directionality. Also, it accepts the mathbackground attribute in the same sense as mstyle and other presentation elements to set the background color of the bounding box, rather than specifying a default for the attribute (see 3.1.9 Mathematics attributes common to presentation elements).

In addition to those attributes, the math element accepts:

Name values default
display "block" | "inline" inline
specifies whether the enclosed MathML expression should be rendered as a separate vertical block (in display style) or inline, aligned with adjacent text. When display=block, displaystyle is initialized to true, whereas when display=inline, displaystyle is initialized to false; in both cases scriptlevel is initialized to 0 (see 3.1.6 Displaystyle and Scriptlevel). Moreover, when the math element is embedded in a larger document, a block math element should be treated as a block element as appropriate for the document type (typically as a new vertical block), whereas an inline math element should be treated as inline (typically exactly as if it were a sequence of words in normal text). In particular, this applies to spacing and linebreaking: for instance, there should not be spaces or line breaks inserted between inline math and any immediately following punctuation. When the display attribute is missing, a rendering agent is free to initialize as appropriate to the context.
maxwidth length available width
specifies the maximum width to be used for linebreaking. The default is the maximum width available in the surrounding environment. If that value cannot be determined, the renderer should assume an infinite rendering width.
overflow "linebreak" | "scroll" | "elide" | "truncate" | "scale" linebreak
specifies the preferred handing in cases where an expression is too long to fit in the allowed width. See the discussion below.
altimg URI none
provides a URI referring to an image to display as a fall-back for user agents that do not support embedded MathML.
altimg-width length width of altimg
specifies the width to display altimg, scaling the image if necessary; see altimg-height.
altimg-height length height of altimg
specifies the height to display altimg, scaling the image if necessary; if only one of the attributes altimg-width and altimg-height are given, the scaling should preserve the image's aspect ratio; if neither attribute is given, the image should be shown at its natural size.
altimg-valign length | "top" | "middle" | "bottom" 0ex
specifies the vertical alignment of the image with respect to adjacent inline material. A positive value of altimg-valign shifts the bottom of the image above the current baseline, while a negative value lowers it. The keyword "top" aligns the top of the image with the top of adjacent inline material; "center" aligns the middle of the image to the middle of adjacent material; "bottom" aligns the bottom of the image to the bottom of adjacent material (not necessarily the baseline). This attribute only has effect when display=inline. By default, the bottom of the image aligns to the baseline.
alttext string none
provides a textual alternative as a fall-back for user agents that do not support embedded MathML or images.
cdgroup URI none
specifies a CD group file that acts as a catalogue of CD bases for locating OpenMath content dictionaries of csymbol, annotation, and annotation-xml elements in this math element; see 4.2.3 Content Symbols <csymbol>. When no cdgroup attribute is explicitly specified, the document format embedding this math element may provide a method for determining CD bases. Otherwise the system must determine a CD base; in the absence of specific information http://www.openmath.org/cd is assumed as the CD base for all csymbol, annotation, and annotation-xml elements. This is the CD base for the collection of standard CDs maintained by the OpenMath Society.

In cases where size negotiation is not possible or fails (for example in the case of an expression that is too long to fit in the allowed width), the overflow attribute is provided to suggest a processing method to the renderer. Allowed values are:

Value Meaning
"linebreak" The expression will be broken across several lines. See 3.1.7 Linebreaking of Expressions for further discussion.
"scroll" The window provides a viewport into the larger complete display of the mathematical expression. Horizontal or vertical scroll bars are added to the window as necessary to allow the viewport to be moved to a different position.
"elide" The display is abbreviated by removing enough of it so that the remainder fits into the window. For example, a large polynomial might have the first and last terms displayed with + ... + between them. Advanced renderers may provide a facility to zoom in on elided areas.
"truncate" The display is abbreviated by simply truncating it at the right and bottom borders. It is recommended that some indication of truncation is made to the viewer.
"scale" The fonts used to display the mathematical expression are chosen so that the full expression fits in the window. Note that this only happens if the expression is too large. In the case of a window larger than necessary, the expression is shown at its normal size within the larger window.

3. Presentation Markup

3.1 Introduction

This chapter specifies the presentation elements of MathML, which can be used to describe the layout structure of mathematical notation.

Most of Presentation Markup is included in [MathML-Core]. That specification should be consulted for the precise details of displaying the elements and attributes that are part of core when displayed in web browsers. Outside of web browsers, MathML presentation elements only suggest (i.e. do not require) specific ways of rendering in order to allow for medium-dependent rendering and for individual preferences of style. Non browser-based renderers are free to use their own layout rules as long as the renderings are intelligible.

The names used for presentation elements are suggestive of their visual layout. However, mathematical notation has a long history of being reused as new concepts are developed. Because of this, an element such as mfrac may not actually be a fraction and the intent attribute should be used to provide information for auditory renderings.

This chapter describes all of the presentation elements and attributes of MathML along with examples that might clarify usage.

3.1.1 Presentation MathML Structure

The presentation elements are meant to express the syntactic structure of mathematical notation in much the same way as titles, sections, and paragraphs capture the higher-level syntactic structure of a textual document. Because of this, a single row of identifiers and operators will often be represented by multiple nested mrow elements rather than a single mrow. For example, x+a/b typically is represented as:

<mrow>
  <mi> x </mi>
  <mo> + </mo>
  <mrow>
    <mi> a </mi>
    <mo> / </mo>
    <mi> b </mi>
  </mrow>
</mrow>
x + a / b

Similarly, superscripts are attached to the full expression constituting their base rather than to the just preceding character. This structure permits better-quality rendering of mathematics, especially when details of the rendering environment, such as display widths, are not known ahead of time to the document author. It also greatly eases automatic interpretation of the represented mathematical structures.

Certain characters are used to name identifiers or operators that in traditional notation render the same as other symbols or are rendered invisibly. For example, the characters U+2146, U+2147 and U+2148 represent differential d, exponential e and imaginary i, respectively and are semantically distinct from the same letters used as simple variables. Likewise, the characters U+2061, U+2062, U+2063 and U+2064 represent function application, invisible times, invisible comma and invisible plus . These usually render invisibly but represent significant information that may influence visual spacing and linebreaking, and may have distinct spoken renderings. Accordingly, authors should use these characters (or corresponding entities) wherever applicable.

The complete list of MathML entities is described in [Entities].

3.1.2 Terminology Used In This Chapter

The presentation elements are divided into two classes. Token elements represent individual symbols, names, numbers, labels, etc. Layout schemata build expressions out of parts and can have only elements as content. These are subdivided into General Layout, Script and Limit, Tabular Math and Elementary Math schemata. There are also a few empty elements used only in conjunction with certain layout schemata.

All individual symbols in a mathematical expression should be represented by MathML token elements (e.g., <mn>24</mn>). The primary MathML token element types are identifiers (mi, e.g. variables or function names), numbers (mn), and operators (mo, including fences, such as parentheses, and separators, such as commas). There are also token elements used to represent text or whitespace that has more aesthetic than mathematical significance and other elements representing string literals for compatibility with computer algebra systems.

The layout schemata specify the way in which sub-expressions are built into larger expressions such as fraction and scripted expressions. Layout schemata attach special meaning to the number and/or positions of their children. A child of a layout schema is also called an argument of that element. As a consequence of the above definitions, the content of a layout schema consists exactly of a sequence of zero or more elements that are its arguments.

3.1.3 Required Arguments

Many of the elements described herein require a specific number of arguments (always 1, 2, or 3). In the detailed descriptions of element syntax given below, the number of required arguments is implicitly indicated by giving names for the arguments at various positions. A few elements have additional requirements on the number or type of arguments, which are described with the individual element. For example, some elements accept sequences of zero or more arguments — that is, they are allowed to occur with no arguments at all.

Note that MathML elements encoding rendered space do count as arguments of the elements in which they appear. See 3.2.7 Space <mspace/> for a discussion of the proper use of such space-like elements.

3.1.3.1 Inferred <mrow>s

The elements listed in the following table as requiring 1* argument (msqrt, mstyle, merror, mpadded, mphantom, menclose, mtd, mscarry, and math) conceptually accept a single argument, but actually accept any number of children. If the number of children is 0 or is more than 1, they treat their contents as a single inferred mrow formed from all their children, and treat this mrow as the argument.

For example,

<msqrt>
  <mo> - </mo>
  <mn> 1 </mn>
</msqrt>
- 1

is treated as if it were

<msqrt>
  <mrow>
    <mo> - </mo>
    <mn> 1 </mn>
  </mrow>
</msqrt>
- 1

This feature allows MathML data not to contain (and its authors to leave out) many mrow elements that would otherwise be necessary.

3.1.3.2 Table of argument requirements

For convenience, here is a table of each element's argument count requirements and the roles of individual arguments when these are distinguished. An argument count of 1* indicates an inferred mrow as described above. Although the math element is not a presentation element, it is listed below for completeness.

Element Required argument count Argument roles (when these differ by position)
mrow 0 or more
mfrac 2 numerator denominator
msqrt 1*
mroot 2 base index
mstyle 1*
merror 1*
mpadded 1*
mphantom 1*
mfenced 0 or more
menclose 1*
msub 2 base subscript
msup 2 base superscript
msubsup 3 base subscript superscript
munder 2 base underscript
mover 2 base overscript
munderover 3 base underscript overscript
mmultiscripts 1 or more base (subscript superscript)* [<mprescripts/> (presubscript presuperscript)*]
mtable 0 or more rows 0 or more mtr or mlabeledtr elements
mlabeledtr 1 or more a label and 0 or more mtd elements
mtr 0 or more 0 or more mtd elements
mtd 1*
mstack 0 or more
mlongdiv 3 or more divisor result dividend (msrow | msgroup | mscarries | msline)*
msgroup 0 or more
msrow 0 or more
mscarries 0 or more
mscarry 1*
maction 1 or more depend on actiontype attribute
math 1*

3.1.4 Elements with Special Behaviors

Certain MathML presentation elements exhibit special behaviors in certain contexts. Such special behaviors are discussed in the detailed element descriptions below. However, for convenience, some of the most important classes of special behavior are listed here.

Certain elements are considered space-like; these are defined in 3.2.7 Space <mspace/>. This definition affects some of the suggested rendering rules for mo elements (3.2.5 Operator, Fence, Separator or Accent <mo>).

Certain elements, e.g. msup, are able to embellish operators that are their first argument. These elements are listed in 3.2.5 Operator, Fence, Separator or Accent <mo>, which precisely defines an embellished operator and explains how this affects the suggested rendering rules for stretchy operators.

3.1.5 Directionality

In the notations familiar to most readers, both the overall layout and the textual symbols are arranged from left to right (LTR). Yet, as alluded to in the introduction, mathematics written in Hebrew or in locales such as Morocco or Persia, the overall layout is used unchanged, but the embedded symbols (often Hebrew or Arabic) are written right to left (RTL). Moreover, in most of the Arabic speaking world, the notation is arranged entirely RTL; thus a superscript is still raised, but it follows the base on the left rather than the right.

MathML 3.0 therefore recognizes two distinct directionalities: the directionality of the text and symbols within token elements and the overall directionality represented by Layout Schemata. These two facets are discussed below.

Note

Probably need to add a little discussion of vertical languages here (and their current lack of support)

3.1.5.1 Overall Directionality of Mathematics Formulas

The overall directionality for a formula, basically the direction of the Layout Schemata, is specified by the dir attribute on the containing math element (see 2.2 The Top-Level <math> Element). The default is ltr. When dir=rtl is used, the layout is simply the mirror image of the conventional European layout. That is, shifts up or down are unchanged, but the progression in laying out is from right to left.

For example, in a RTL layout, sub- and superscripts appear to the left of the base; the surd for a root appears at the right, with the bar continuing over the base to the left. The layout details for elements whose behavior depends on directionality are given in the discussion of the element. In those discussions, the terms leading and trailing are used to specify a side of an object when which side to use depends on the directionality; i.e. leading means left in LTR but right in RTL. The terms left and right may otherwise be safely assumed to mean left and right.

The overall directionality is usually set on the math, but may also be switched for an individual subexpression by using the dir attribute on mrow or mstyle elements. When not specified, all elements inherit the directionality of their container.

3.1.5.2 Bidirectional Layout in Token Elements

The text directionality comes into play for the MathML token elements that can contain text (mtext, mo, mi, mn and ms) and is determined by the Unicode properties of that text. A token element containing exclusively LTR or RTL characters is displayed straightforwardly in the given direction. When a mixture of directions is involved, such as RTL Arabic and LTR numbers, the Unicode bidirectional algorithm [Bidi] should be applied. This algorithm specifies how runs of characters with the same direction are processed and how the runs are (re)ordered. The base, or initial, direction is given by the overall directionality described above (3.1.5.1 Overall Directionality of Mathematics Formulas) and affects how weakly directional characters are treated and how runs are nested. (The dir attribute is thus allowed on token elements to specify the initial directionality that may be needed in rare cases.) Any mglyph or malignmark elements appearing within a token element are effectively neutral and have no effect on ordering.

The important thing to notice is that the bidirectional algorithm is applied independently to the contents of each token element; each token element is an independent run of characters.

Other features of Unicode and scripts that should be respected are ‘mirroring’ and ‘glyph shaping’. Some Unicode characters are marked as being mirrored when presented in a RTL context; that is, the character is drawn as if it were mirrored or replaced by a corresponding character. Thus an opening parenthesis, ‘(’, in RTL will display as ‘)’. Conversely, the solidus (/ U+002F) is not marked as mirrored. Thus, an Arabic author that desires the slash to be reversed in an inline division should explicitly use reverse solidus (\ U+005C) or an alternative such as the mirroring DIVISION SLASH (U+2215).

Additionally, calligraphic scripts such as Arabic blend, or connect sequences of characters together, changing their appearance. As this can have a significant impact on readability, as well as aesthetics, it is important to apply such shaping if possible. Glyph shaping, like directionality, applies to each token element's contents individually.

Note that for the transfinite cardinals represented by Hebrew characters, the code points U+2135-U+2138 (ALEF SYMBOL, BET SYMBOL, GIMEL SYMBOL, DALET SYMBOL) should be used in MathML, not the alphabetic look-alike code points. These code points are strong left-to-right.

3.1.6 Displaystyle and Scriptlevel

So-called ‘displayed’ formulas, those appearing on a line by themselves, typically make more generous use of vertical space than inline formulas, which should blend into the adjacent text without intruding into neighboring lines. For example, in a displayed summation, the limits are placed above and below the summation symbol, while when it appears inline the limits would appear in the sub- and superscript position. For similar reasons, sub- and superscripts, nested fractions and other constructs typically display in a smaller size than the main part of the formula. MathML implicitly associates with every presentation node a displaystyle and scriptlevel reflecting whether a more expansive vertical layout applies and the level of scripting in the current context.

These values are initialized by the math element according to the display attribute. They are automatically adjusted by the various script and limit schemata elements, and the elements mfrac and mroot, which typically set displaystyle false and increment scriptlevel for some or all of their arguments. (See the description for each element for the specific rules used.) They also may be set explicitly via the displaystyle and scriptlevel attributes on the mstyle element or the displaystyle attribute of mtable. In all other cases, they are inherited from the node's parent.

The displaystyle affects the amount of vertical space used to lay out a formula: when true, the more spacious layout of displayed equations is used, whereas when false a more compact layout of inline formula is used. This primarily affects the interpretation of the largeop and movablelimits attributes of the mo element. However, more sophisticated renderers are free to use this attribute to render more or less compactly.

The main effect of scriptlevel is to control the font size. Typically, the higher the scriptlevel, the smaller the font size. (Non-visual renderers can respond to the font size in an analogous way for their medium.) Whenever the scriptlevel is changed, whether automatically or explicitly, the current font size is multiplied by the value of scriptsizemultiplier to the power of the change in scriptlevel. However, changes to the font size due to scriptlevel changes should never reduce the size below scriptminsize to prevent scripts becoming unreadably small. The default scriptsizemultiplier is approximately the square root of 1/2 whereas scriptminsize defaults to 8 points; these values may be changed on mstyle; see 3.3.4 Style Change <mstyle>. Note that the scriptlevel attribute of mstyle allows arbitrary values of scriptlevel to be obtained, including negative values which result in increased font sizes.

The changes to the font size due to scriptlevel should be viewed as being imposed from ‘outside’ the node. This means that the effect of scriptlevel is applied before an explicit mathsize (see 3.2.2 Mathematics style attributes common to token elements) on a token child of mfrac. Thus, the mathsize effectively overrides the effect of scriptlevel. However, that change to scriptlevel changes the current font size, which affects the meaning of an em length (see 2.1.5.2 Length Valued Attributes) and so the scriptlevel still may have an effect in such cases. Note also that since mathsize is not constrained by scriptminsize, such direct changes to font size can result in scripts smaller than scriptminsize.

Note that direct changes to current font size, whether by CSS or by the mathsize attribute (see 3.2.2 Mathematics style attributes common to token elements), have no effect on the value of scriptlevel.

TeX's \displaystyle, \textstyle, \scriptstyle, and \scriptscriptstyle correspond to displaystyle and scriptlevel as true and 0, false and 0, false and 1, and false and 2, respectively. Thus, math's display=block corresponds to \displaystyle, while display=inline corresponds to \textstyle.

3.1.7 Linebreaking of Expressions

3.1.7.1 Control of Linebreaks

MathML provides support for both automatic and manual (forced) linebreaking of expressions to break excessively long expressions into several lines. All such linebreaks take place within mrow (including inferred mrow; see 3.1.3.1 Inferred <mrow>s) or mfenced. The breaks typically take place at mo elements and also, for backwards compatibility, at mspace. Renderers may also choose to place automatic linebreaks at other points such as between adjacent mi elements or even within a token element such as a very long mn element. MathML does not provide a means to specify such linebreaks, but if a renderer chooses to linebreak at such a point, it should indent the following line according to the indentation attributes that are in effect at that point.

Automatic linebreaking occurs when the containing math element has overflow=linebreak and the display engine determines that there is not enough space available to display the entire formula. The available width must therefore be known to the renderer. Like font properties, one is assumed to be inherited from the environment in which the MathML element lives. If no width can be determined, an infinite width should be assumed. Inside of an mtable, each column has some width. This width may be specified as an attribute or determined by the contents. This width should be used as the line wrapping width for linebreaking, and each entry in an mtable is linewrapped as needed.

Issue 304: Potential presentation MathML items to deprecate in MathML 4
(mspace's @linebreak)

Forced linebreaks are specified by using linebreak=newline on an mo or mspace element. Both automatic and manual linebreaking can occur within the same formula.

Automatic linebreaking of subexpressions of mfrac, msqrt, mroot and menclose and the various script elements is not required. Renderers are free to ignore forced breaks within those elements if they choose.

Attributes on mo and possibly on mspace elements control linebreaking and indentation of the following line. The aspects of linebreaking that can be controlled are:

  • Where — attributes determine the desirability of a linebreak at a specific operator or space, in particular whether a break is required or inhibited. These can only be set on mo and mspace elements. (See 3.2.5.2.2 Linebreaking attributes.)

  • Operator Display/Position — when a linebreak occurs, determines whether the operator will appear at the end of the line, at the beginning of the next line, or in both positions; and how much vertical space should be added after the linebreak. These attributes can be set on mo elements or inherited from mstyle or math elements. (See 3.2.5.2.2 Linebreaking attributes.)

  • Indentation — determines the indentation of the line following a linebreak, including indenting so that the next line aligns with some point in a previous line. These attributes can be set on mo elements or inherited from mstyle or math elements. (See 3.2.5.2.3 Indentation attributes.)

When a math element appears in an inline context, it may obey whatever paragraph flow rules are employed by the document's text rendering engine. Such rules are necessarily outside of the scope of this specification. Alternatively, it may use the value of the math element's overflow attribute. (See 2.2.1 Attributes.)

3.1.7.2 Examples of Linebreaking

The following example demonstrates forced linebreaks and forced alignment:

<mrow>
 <mrow> <mi>f</mi> <mo>&#x2061;<!--ApplyFunction--></mo> <mo>(</mo> <mi>x</mi> <mo>)</mo> </mrow>
 <mo id='eq1-equals'>=</mo>
 <mrow>
  <msup>
   <mrow> <mo>(</mo> <mrow> <mi>x</mi> <mo>+</mo> <mn>1</mn> </mrow> <mo>)</mo> </mrow>
   <mn>4</mn>
  </msup>
  <mo linebreak='newline' linebreakstyle='before'
      indentalign='id' indenttarget='eq1-equals'>=</mo>
  <mrow>
   <msup> <mi>x</mi> <mn>4</mn> </msup>
   <mo id='eq1-plus'>+</mo>
   <mrow> <mn>4</mn> <mo>&#x2062;<!--InvisibleTimes--></mo> <msup> <mi>x</mi> <mn>3</mn> </msup> </mrow>
   <mo>+</mo>
   <mrow> <mn>6</mn> <mo>&#x2062;<!--InvisibleTimes--></mo> <msup> <mi>x</mi> <mn>2</mn> </msup> </mrow>
   <mo linebreak='newline' linebreakstyle='before'
       indentalignlast='id' indenttarget='eq1-plus'>+</mo>
   <mrow> <mn>4</mn> <mo>&#x2062;<!--InvisibleTimes--></mo> <mi>x</mi> </mrow>
   <mo>+</mo>
   <mn>1</mn>
  </mrow>
 </mrow>
</mrow>

This displays as

example with equal and plus signs aligned

Note that because indentalignlast defaults to indentalign, in the above example indentalign could have been used in place of indentalignlast. Also, the specifying linebreakstyle='before' is not needed because that is the default value.

3.1.8 Summary of Presentation Elements

3.1.8.1 Token Elements
mi identifier
mn number
mo operator, fence, or separator
mtext text
mspace space
ms string literal

Additionally, the mglyph element may be used within Token elements to represent non-standard symbols as images.

3.1.8.2 General Layout Schemata
mrow group any number of sub-expressions horizontally
mfrac form a fraction from two sub-expressions
msqrt form a square root (radical without an index)
mroot form a radical with specified index
mstyle style change
merror enclose a syntax error message from a preprocessor
mpadded adjust space around content
mphantom make content invisible but preserve its size
mfenced surround content with a pair of fences
menclose enclose content with a stretching symbol such as a long division sign
3.1.8.3 Script and Limit Schemata
msub attach a subscript to a base
msup attach a superscript to a base
msubsup attach a subscript-superscript pair to a base
munder attach an underscript to a base
mover attach an overscript to a base
munderover attach an underscript-overscript pair to a base
mmultiscripts attach prescripts and tensor indices to a base
3.1.8.4 Tables and Matrices
mtable table or matrix
mlabeledtr row in a table or matrix with a label or equation number
mtr row in a table or matrix
mtd one entry in a table or matrix
maligngroup and malignmark alignment markers
3.1.8.5 Elementary Math Layout
mstack columns of aligned characters
mlongdiv similar to msgroup, with the addition of a divisor and result
msgroup a group of rows in an mstack that are shifted by similar amounts
msrow a row in an mstack
mscarries row in an mstack whose contents represent carries or borrows
mscarry one entry in an mscarries
msline horizontal line inside of mstack
3.1.8.6 Enlivening Expressions
maction bind actions to a sub-expression

3.1.9 Mathematics attributes common to presentation elements

In addition to the attributes listed in 2.1.6 Attributes Shared by all MathML Elements, all MathML presentation elements accept the following classes of attribute.

3.1.9.1 MathML Core Attributes

Presentation elements also accept all the Global Attributes specified by [MathML-Core].

These attributes include the following two attributes that are primarily intended for visual media. They are not expected to affect the intended semantics of displayed expressions, but are for use in highlighting or drawing attention to the affected subexpressions. For example, a red "x" is not assumed to be semantically different than a black "x", in contrast to variables with different mathvariant values (see 3.2.2 Mathematics style attributes common to token elements).

Name values default
mathcolor color inherited
Specifies the foreground color to use when drawing the components of this element, such as the content for token elements or any lines, surds, or other decorations. It also establishes the default mathcolor used for child elements when used on a layout element.
mathbackground color | "transparent" transparent
Specifies the background color to be used to fill in the bounding box of the element and its children. The default, "transparent", lets the background color, if any, used in the current rendering context to show through.

Since MathML expressions are often embedded in a textual data format such as HTML, the MathML renderer should inherit the foreground color used in the context in which the MathML appears. Note, however, that MathML (in contrast to [MathML-Core]) doesn't specify the mechanism by which style information is inherited from the rendering environment. See 3.2.2 Mathematics style attributes common to token elements for more details.

Note that the suggested MathML visual rendering rules do not define the precise extent of the region whose background is affected by the mathbackground attribute, except that, when the content does not have negative dimensions and its drawing region should not overlap with other drawing due to surrounding negative spacing, should lie behind all the drawing done to render the content, and should not lie behind any of the drawing done to render surrounding expressions. The effect of overlap of drawing regions caused by negative spacing on the extent of the region affected by the mathbackground attribute is not defined by these rules.

3.2 Token Elements

Token elements in presentation markup are broadly intended to represent the smallest units of mathematical notation which carry meaning. Tokens are roughly analogous to words in text. However, because of the precise, symbolic nature of mathematical notation, the various categories and properties of token elements figure prominently in MathML markup. By contrast, in textual data, individual words rarely need to be marked up or styled specially.

Token elements represent identifiers (mi), numbers (mn), operators (mo), text (mtext), strings (ms) and spacing (mspace). The mglyph element may be used within token elements to represent non-standard symbols by images. Preceding detailed discussion of the individual elements, the next two subsections discuss the allowable content of token elements and the attributes common to them.

3.2.1 Token Element Content Characters, <mglyph/>

Character data in MathML markup is only allowed to occur as part of the content of token elements. Whitespace between elements is ignored. With the exception of the empty mspace element, token elements can contain any sequence of zero or more Unicode characters, or mglyph or malignmark elements. The mglyph element is used to represent non-standard characters or symbols by images; the malignmark element establishes an alignment point for use within table constructs, and is otherwise invisible (see 3.5.5 Alignment Markers <maligngroup/>, <malignmark/>).

Characters can be either represented directly as Unicode character data, or indirectly via numeric or character entity references. Unicode contains a number of look-alike characters. See [MathML-Notes] for a discussion of which characters are appropriate to use in which circumstance.

Token elements (other than mspace) should be rendered as their content, if any (i.e. in the visual case, as a closely-spaced horizontal row of standard glyphs for the characters or images for the mglyphs in their content). An mspace element is rendered as a blank space of a width determined by its attributes. Rendering algorithms should also take into account the mathematics style attributes as described below, and modify surrounding spacing by rules or attributes specific to each type of token element. The directional characteristics of the content must also be respected (see 3.1.5.2 Bidirectional Layout in Token Elements).

3.2.1.1 Using images to represent symbols <mglyph/>
3.2.1.1.1 Description

The mglyph element provides a mechanism for displaying images to represent non-standard symbols. It may be used within the content of the token elements mi, mn, mo, mtext or ms where existing Unicode characters are not adequate.

Unicode defines a large number of characters used in mathematics and, in most cases, glyphs representing these characters are widely available in a variety of fonts. Although these characters should meet almost all users needs, MathML recognizes that mathematics is not static and that new characters and symbols are added when convenient. Characters that become well accepted will likely be eventually incorporated by the Unicode Consortium or other standards bodies, but that is often a lengthy process.

Note that the glyph's src attribute uniquely identifies the mglyph; two mglyphs with the same values for src should be considered identical by applications that must determine whether two characters/glyphs are identical.

3.2.1.1.2 Attributes

The mglyph element accepts the attributes listed in 3.1.9 Mathematics attributes common to presentation elements, but note that mathcolor has no effect. The background color, mathbackground, should show through if the specified image has transparency.

mglyph also accepts the additional attributes listed here.

Name values default
src URI required
Specifies the location of the image resource; it may be a URI relative to the base-URI of the source of the MathML, if any.
width length from image
Specifies the desired width of the glyph; see height.
height length from image
Specifies the desired height of the glyph. If only one of width and height are given, the image should be scaled to preserve the aspect ratio; if neither are given, the image should be displayed at its natural size.
valign length 0ex
Specifies the baseline alignment point of the image with respect to the current baseline. A positive value shifts the bottom of the image above the current baseline while a negative value lowers it. A value of 0 (the default) means that the baseline of the image is at the bottom of the image.
alt string required
Provides an alternate name for the glyph. If the specified image can't be found or displayed, the renderer may use this name in a warning message or some unknown glyph notation. The name might also be used by an audio renderer or symbol processing system and should be chosen to be descriptive.
3.2.1.1.3 Example

The following example illustrates how a researcher might use the mglyph construct with a set of images to work with braid group notation.

<mrow>
  <mi><mglyph src="my-braid-23" alt="2 3 braid"/></mi>
  <mo>+</mo>
  <mi><mglyph src="my-braid-132" alt="1 3 2 braid"/></mi>
  <mo>=</mo>
  <mi><mglyph src="my-braid-13" alt="1 3 braid"/></mi>
</mrow>

This might render as:

\includegraphics{image/braids}

3.2.2 Mathematics style attributes common to token elements

In addition to the attributes defined for all presentation elements (3.1.9 Mathematics attributes common to presentation elements), MathML includes two mathematics style attributes as well as a directionality attribute valid on all presentation token elements, as well as the math and mstyle elements; dir is also valid on mrow elements. The attributes are:

Name values default
mathvariant "normal" | "bold" | "italic" | "bold-italic" | "double-struck" | "bold-fraktur" | "script" | "bold-script" | "fraktur" | "sans-serif" | "bold-sans-serif" | "sans-serif-italic" | "sans-serif-bold-italic" | "monospace" | "initial" | "tailed" | "looped" | "stretched" normal (except on <mi>)
Specifies the logical class of the token. Note that this class is more than styling, it typically conveys semantic intent; see the discussion below.
mathsize "small" | "normal" | "big" | length inherited
Specifies the size to display the token content. The values small and big choose a size smaller or larger than the current font size, but leave the exact proportions unspecified; normal is allowed for completeness, but since it is equivalent to 100% or 1em, it has no effect.
dir "ltr" | "rtl" inherited
specifies the initial directionality for text within the token: ltr (Left To Right) or rtl (Right To Left). This attribute should only be needed in rare cases involving weak or neutral characters; see 3.1.5.1 Overall Directionality of Mathematics Formulas for further discussion. It has no effect on mspace.

The mathvariant attribute defines logical classes of token elements. Each class provides a collection of typographically-related symbolic tokens. Each token has a specific meaning within a given mathematical expression and, therefore, needs to be visually distinguished and protected from inadvertent document-wide style changes which might change its meaning. Each token is identified by the combination of the mathvariant attribute value and the character data in the token element.

When MathML rendering takes place in an environment where CSS is available, the mathematics style attributes can be viewed as predefined selectors for CSS style rules. See 7.5 Using CSS with MathML for discussion of the interaction of MathML and CSS. Also, see [MathMLforCSS] for discussion of rendering MathML by CSS and a sample CSS style sheet. When CSS is not available, it is up to the internal style mechanism of the rendering application to visually distinguish the different logical classes. Most MathML renderers will probably want to rely on some degree on additional, internal style processing algorithms. In particular, the mathvariant attribute does not follow the CSS inheritance model; the default value is normal (non-slanted) for all tokens except for mi with single-character content. See 3.2.3 Identifier <mi> for details.

Renderers have complete freedom in mapping mathematics style attributes to specific rendering properties. However, in practice, the mathematics style attribute names and values suggest obvious typographical properties, and renderers should attempt to respect these natural interpretations as far as possible. For example, it is reasonable to render a token with the mathvariant attribute set to sans-serif in Helvetica or Arial. However, rendering the token in a Times Roman font could be seriously misleading and should be avoided.

In principle, any mathvariant value may be used with any character data to define a specific symbolic token. In practice, only certain combinations of character data and mathvariant values will be visually distinguished by a given renderer. For example, there is no clear-cut rendering for a "fraktur alpha" or a "bold italic Kanji" character, and the mathvariant values "initial", "tailed", "looped", and "stretched" are appropriate only for Arabic characters.

Certain combinations of character data and mathvariant values are equivalent to assigned Unicode code points that encode mathematical alphanumeric symbols. These Unicode code points are the ones in the Arabic Mathematical Alphabetic Symbols block U+1EE00 to U+1EEFF, Mathematical Alphanumeric Symbols block U+1D400 to U+1D7FF, listed in the Unicode standard, and the ones in the Letterlike Symbols range U+2100 to U+214F that represent "holes" in the alphabets in the SMP, listed in 8.2 Mathematical Alphanumeric Symbols. These characters are described in detail in section 2.2 of UTR #25. The description of each such character in the Unicode standard provides an unstyled character to which it would be equivalent except for a font change that corresponds to a mathvariant value. A token element that uses the unstyled character in combination with the corresponding mathvariant value is equivalent to a token element that uses the mathematical alphanumeric symbol character without the mathvariant attribute. Note that the appearance of a mathematical alphanumeric symbol character should not be altered by surrounding mathvariant or other style declarations.

Renderers should support those combinations of character data and mathvariant values that correspond to Unicode characters, and that they can visually distinguish using available font characters. Renderers may ignore or support those combinations of character data and mathvariant values that do not correspond to an assigned Unicode code point, and authors should recognize that support for mathematical symbols that do not correspond to assigned Unicode code points may vary widely from one renderer to another.

Since MathML expressions are often embedded in a textual data format such as HTML, the surrounding text and the MathML must share rendering attributes such as font size, so that the renderings will be compatible in style. For this reason, most attribute values affecting text rendering are inherited from the rendering environment, as shown in the default column in the table above. (In cases where the surrounding text and the MathML are being rendered by separate software, e.g. a browser and a plug-in, it is also important for the rendering environment to provide the MathML renderer with additional information, such as the baseline position of surrounding text, which is not specified by any MathML attributes.) Note, however, that MathML doesn't specify the mechanism by which style information is inherited from the rendering environment.

If the requested mathsize of the current font is not available, the renderer should approximate it in the manner likely to lead to the most intelligible, highest quality rendering. Note that many MathML elements automatically change the font size in some of their children; see the discussion in 3.1.6 Displaystyle and Scriptlevel.

3.2.2.1 Embedding HTML in MathML

MathML can be combined with other formats as described in 7.4 Combining MathML and Other Formats. The recommendation is to embed other formats in MathML by extending the MathML schema to allow additional elements to be children of the mtext element or other leaf elements as appropriate to the role they serve in the expression (see 3.2.3 Identifier <mi>, 3.2.4 Number <mn>, and 3.2.5 Operator, Fence, Separator or Accent <mo>). The directionality, font size, and other font attributes should inherit from those that would be used for characters of the containing leaf element (see 3.2.2 Mathematics style attributes common to token elements).

Here is an example of embedding SVG inside of mtext in an HTML context:

<mtable>
 <mtr>
  <mtd>
   <mtext><input type="text" placeholder="what shape is this?"/></mtext>
  </mtd>
 </mtr>
 <mtr>
  <mtd>
   <mtext>
    <svg xmlns="http://www.w3.org/2000/svg" width="4cm" height="4cm" viewBox="0 0 400 400">
     <rect x="1" y="1" width="398" height="398" style="fill:none; stroke:blue"/>
     <path d="M 100 100 L 300 100 L 200 300 z" style="fill:red; stroke:blue; stroke-width:3"/>
    </svg>
   </mtext>
  </mtd>
 </mtr>
</mtable>

3.2.3 Identifier <mi>

3.2.3.1 Description

An mi element represents a symbolic name or arbitrary text that should be rendered as an identifier. Identifiers can include variables, function names, and symbolic constants. A typical graphical renderer would render an mi element as its content (see 3.2.1 Token Element Content Characters, <mglyph/>), with no extra spacing around it (except spacing associated with neighboring elements).

Not all mathematical identifiers are represented by mi elements — for example, subscripted or primed variables should be represented using msub or msup respectively. Conversely, arbitrary text playing the role of a term (such as an ellipsis in a summed series) should be represented using an mi element.

It should be stressed that mi is a presentation element, and as such, it only indicates that its content should be rendered as an identifier. In the majority of cases, the contents of an mi will actually represent a mathematical identifier such as a variable or function name. However, as the preceding paragraph indicates, the correspondence between notations that should render as identifiers and notations that are actually intended to represent mathematical identifiers is not perfect. For an element whose semantics is guaranteed to be that of an identifier, see the description of ci in 4. Content Markup.

3.2.3.2 Attributes

mi elements accept the attributes listed in 3.2.2 Mathematics style attributes common to token elements, but in one case with a different default value:

Name values default
mathvariant "normal" | "bold" | "italic" | "bold-italic" | "double-struck" | "bold-fraktur" | "script" | "bold-script" | "fraktur" | "sans-serif" | "bold-sans-serif" | "sans-serif-italic" | "sans-serif-bold-italic" | "monospace" | "initial" | "tailed" | "looped" | "stretched" (depends on content; described below)
Specifies the logical class of the token. The default is normal (non-slanted) unless the content is a single character, in which case it would be italic.

Note that for purposes of determining equivalences of Math Alphanumeric Symbol characters (see 8.2 Mathematical Alphanumeric Symbols) the value of the mathvariant attribute should be resolved first, including the special defaulting behavior described above.

3.2.3.3 Examples
<mi>x</mi>
x
<mi>D</mi>
D
<mi>sin</mi>
sin
<mi mathvariant='script'>L</mi>
L
<mi></mi>

An mi element with no content is allowed; <mi></mi> might, for example, be used by an expression editor to represent a location in a MathML expression which requires a term (according to conventional syntax for mathematics) but does not yet contain one.

Identifiers include function names such as sin. Expressions such as sin x should be written using the character U+2061 (entity af or ApplyFunction) as shown below; see also the discussion of invisible operators in 3.2.5 Operator, Fence, Separator or Accent <mo>.

<mrow>
  <mi> sin </mi>
  <mo> &#x2061;<!--ApplyFunction--> </mo>
  <mi> x </mi>
</mrow>
sin x

Miscellaneous text that should be treated as a term can also be represented by an mi element, as in:

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

When an mi is used in such exceptional situations, explicitly setting the mathvariant attribute may give better results than the default behavior of some renderers.

The names of symbolic constants should be represented as mi elements:

<mi> π </mi>
<mi></mi>
<mi></mi>
π

3.2.4 Number <mn>

3.2.4.1 Description

An mn element represents a numeric literal or other data that should be rendered as a numeric literal. Generally speaking, a numeric literal is a sequence of digits, perhaps including a decimal point, representing an unsigned integer or real number. A typical graphical renderer would render an mn element as its content (see 3.2.1 Token Element Content Characters, <mglyph/>), with no extra spacing around them (except spacing from neighboring elements such as mo). mn elements are typically rendered in an unslanted font.

The mathematical concept of a number can be quite subtle and involved, depending on the context. As a consequence, not all mathematical numbers should be represented using mn; examples of mathematical numbers that should be represented differently are shown below, and include complex numbers, ratios of numbers shown as fractions, and names of numeric constants.

Conversely, since mn is a presentation element, there are a few situations where it may be desirable to include arbitrary text in the content of an mn that should merely render as a numeric literal, even though that content may not be unambiguously interpretable as a number according to any particular standard encoding of numbers as character sequences. As a general rule, however, the mn element should be reserved for situations where its content is actually intended to represent a numeric quantity in some fashion. For an element whose semantics are guaranteed to be that of a particular kind of mathematical number, see the description of cn in 4. Content Markup.

3.2.4.2 Attributes

mn elements accept the attributes listed in 3.2.2 Mathematics style attributes common to token elements.

3.2.4.3 Examples
<mn> 2 </mn>
2
<mn> 0.123 </mn>
0.123
<mn> 1,000,000 </mn>
1,000,000
<mn> 2.1e10 </mn>
2.1e10
<mn> 0xFFEF </mn>
0xFFEF
<mn> MCMLXIX </mn>
MCMLXIX
<mn> twenty-one </mn>
twenty-one
3.2.4.4 Numbers that should not be written using <mn> alone

Many mathematical numbers should be represented using presentation elements other than mn alone; this includes complex numbers, negative numbers, ratios of numbers shown as fractions, and names of numeric constants.

3.2.4.4.1 Examples of complex representations of numbers
<mrow>
  <mn> 2 </mn>
  <mo> + </mo>
  <mrow>
    <mn> 3 </mn>
    <mo> &#x2062;<!--InvisibleTimes--> </mo>
    <mi></mi>
  </mrow>
</mrow>
2 + 3
<mfrac> <mn> 1 </mn> <mn> 2 </mn> </mfrac>
1 2
<mrow><mo>-</mo><mn>2</mn></mrow>
-2
<mi> π </mi>
π
<mi></mi>

3.2.5 Operator, Fence, Separator or Accent <mo>

3.2.5.1 Description

An mo element represents an operator or anything that should be rendered as an operator. In general, the notational conventions for mathematical operators are quite complicated, and therefore MathML provides a relatively sophisticated mechanism for specifying the rendering behavior of an mo element. As a consequence, in MathML the list of things that should render as an operator includes a number of notations that are not mathematical operators in the ordinary sense. Besides ordinary operators with infix, prefix, or postfix forms, these include fence characters such as braces, parentheses, and absolute value bars; separators such as comma and semicolon; and mathematical accents such as a bar or tilde over a symbol. We will use the term "operator" in this chapter to refer to operators in this broad sense.

Typical graphical renderers show all mo elements as the content (see 3.2.1 Token Element Content Characters, <mglyph/>), with additional spacing around the element determined by its attributes and further described below. Renderers without access to complete fonts for the MathML character set may choose to render an mo element as not precisely the characters in its content in some cases. For example, <mo> ≤ </mo> might be rendered as <= to a terminal. However, as a general rule, renderers should attempt to render the content of an mo element as literally as possible. That is, <mo> ≤ </mo> and <mo> &lt;= </mo> should render differently. The first one should render as a single character representing a less-than-or-equal-to sign, and the second one as the two-character sequence <=.

All operators, in the general sense used here, are subject to essentially the same rendering attributes and rules. Subtle distinctions in the rendering of these classes of symbols, when they exist, are supported using the Boolean attributes fence, separator and accent, which can be used to distinguish these cases.

A key feature of the mo element is that its default attribute values are set on a case-by-case basis from an operator dictionary as explained below. In particular, default values for fence, separator and accent can usually be found in the operator dictionary and therefore need not be specified on each mo element.

Note that some mathematical operators are represented not by mo elements alone, but by mo elements embellished with (for example) surrounding superscripts; this is further described below. Conversely, as presentation elements, mo elements can contain arbitrary text, even when that text has no standard interpretation as an operator; for an example, see the discussion Mixing text and mathematics in 3.2.6 Text <mtext>. See also 4. Content Markup for definitions of MathML content elements that are guaranteed to have the semantics of specific mathematical operators.

Note also that linebreaking, as discussed in 3.1.7 Linebreaking of Expressions, usually takes place at operators (either before or after, depending on local conventions). Thus, mo accepts attributes to encode the desirability of breaking at a particular operator, as well as attributes describing the treatment of the operator and indentation in case a linebreak is made at that operator.

3.2.5.2 Attributes

mo elements accept the attributes listed in 3.2.2 Mathematics style attributes common to token elements and the additional attributes listed here. Since the display of operators is so critical in mathematics, the mo element accepts a large number of attributes; these are described in the next three subsections.

Most attributes get their default values from an enclosing mstyle element, math element, from the containing document, or from 3.2.5.6.1 The operator dictionary. When a value that is listed as inherited is not explicitly given on an mo, mstyle element, math element, or found in the operator dictionary for a given mo element, the default value shown in parentheses is used.

3.2.5.2.1 Dictionary-based attributes
Name values default
form "prefix" | "infix" | "postfix" set by position of operator in an mrow
Specifies the role of the operator in the enclosing expression. This role and the operator content affect the lookup of the operator in the operator dictionary which affects the spacing and other default properties; see 3.2.5.6.2 Default value of the form attribute.
fence "true" | "false" set by dictionary (false)
Specifies whether the operator represents a ‘fence’, such as a parenthesis. This attribute generally has no direct effect on the visual rendering, but may be useful in specific cases, such as non-visual renderers.
separator "true" | "false" set by dictionary (false)
Specifies whether the operator represents a ‘separator’, or punctuation. This attribute generally has no direct effect on the visual rendering, but may be useful in specific cases, such as non-visual renderers.
lspace length set by dictionary (thickmathspace)
Specifies the leading space appearing before the operator; see 3.2.5.6.4 Spacing around an operator. (Note that before is on the right in a RTL context; see 3.1.5 Directionality.)
rspace length set by dictionary (thickmathspace)
Specifies the trailing space appearing after the operator; see 3.2.5.6.4 Spacing around an operator. (Note that after is on the left in a RTL context; see 3.1.5 Directionality.)
stretchy "true" | "false" set by dictionary (false)
Specifies whether the operator should stretch to the size of adjacent material; see 3.2.5.7 Stretching of operators, fences and accents.
symmetric "true" | "false" set by dictionary (false)
Specifies whether the operator should be kept symmetric around the math axis when stretchy. Note this property only applies to vertically stretched symbols. See 3.2.5.7 Stretching of operators, fences and accents.
maxsize length set by dictionary (unbounded)
Specifies the maximum size of the operator when stretchy; see 3.2.5.7 Stretching of operators, fences and accents. If not given, the maximum size is unbounded. Unitless or percentage values indicate a multiple of the reference size, being the size of the unstretched glyph. MathML 4 deprecates "infinity" as possible value as it is the same as not providing a value.
minsize length set by dictionary (100%)
Specifies the minimum size of the operator when stretchy; see 3.2.5.7 Stretching of operators, fences and accents. Unitless or percentage values indicate a multiple of the reference size, being the size of the unstretched glyph.
largeop "true" | "false" set by dictionary (false)
Specifies whether the operator is considered a ‘large’ operator, that is, whether it should be drawn larger than normal when displaystyle=true (similar to using TeX's \displaystyle). Examples of large operators include U+222B and U+220F (entities int and prod). See 3.1.6 Displaystyle and Scriptlevel for more discussion.
movablelimits "true" | "false" set by dictionary (false)
Specifies whether under- and overscripts attached to this operator ‘move’ to the more compact sub- and superscript positions when displaystyle is false. Examples of operators that typically have movablelimits=true are U+2211 and U+220F (entitites sum, prod), as well as lim. See 3.1.6 Displaystyle and Scriptlevel for more discussion.
accent "true" | "false" set by dictionary (false)
Specifies whether this operator should be treated as an accent (diacritical mark) when used as an underscript or overscript; see munder, mover and munderover.
Note: for compatibility with MathML Core, use accent=true on the enclosing mover and munderover in place of this attribute.
3.2.5.2.2 Linebreaking attributes

The following attributes affect when a linebreak does or does not occur, and the appearance of the linebreak when it does occur.

Name values default
linebreak "auto" | "newline" | "nobreak" | "goodbreak" | "badbreak" auto
Specifies the desirability of a linebreak occurring at this operator: the default auto indicates the renderer should use its default linebreaking algorithm to determine whether to break; newline is used to force a linebreak; for automatic linebreaking, nobreak forbids a break; goodbreak suggests a good position; badbreak suggests a poor position.
lineleading length inherited (100%)
Specifies the amount of vertical space to use after a linebreak. For tall lines, it is often clearer to use more leading at linebreaks. Rendering agents are free to choose an appropriate default.
linebreakstyle "before" | "after" | "duplicate" | "infixlinebreakstyle" set by dictionary (before)
Specifies whether a linebreak occurs ‘before’ or ‘after’ the operator when a linebreak occurs on this operator; or whether the operator is duplicated. before causes the operator to appear at the beginning of the new line (but possibly indented); after causes it to appear at the end of the line before the break. duplicate places the operator at both positions. infixlinebreakstyle uses the value that has been specified for infix operators; this value (one of before, after or duplicate) can be specified by the application or bound by mstyle (before corresponds to the most common style of linebreaking).
linebreakmultchar string inherited (&InvisibleTimes;)
Specifies the character used to make an &InvisibleTimes; operator visible at a linebreak. For example, linebreakmultchar="·" would make the multiplication visible as a center dot.

linebreak values on adjacent mo and mspace elements do not interact; linebreak=nobreak on an mo does not, in itself, inhibit a break on a preceding or following (possibly nested) mo or mspace element and does not interact with the linebreakstyle attribute value of the preceding or following mo element. It does prevent breaks from occurring on either side of the mo element in all other situations.

3.2.5.2.3 Indentation attributes

The following attributes affect indentation of the lines making up a formula. Primarily these attributes control the positioning of new lines following a linebreak, whether automatic or manual. However, indentalignfirst and indentshiftfirst also control the positioning of a single line formula without any linebreaks. When these attributes appear on mo or mspace they apply if a linebreak occurs at that element. When they appear on mstyle or math elements, they determine defaults for the style to be used for any linebreaks occurring within. Note that except for cases where heavily marked-up manual linebreaking is desired, many of these attributes are most useful when bound on an mstyle or math element.

Note that since the rendering context, such as the available width and current font, is not always available to the author of the MathML, a renderer may ignore the values of these attributes if they result in a line in which the remaining width is too small to usefully display the expression or if they result in a line in which the remaining width exceeds the available linewrapping width.

Name values default
indentalign "left" | "center" | "right" | "auto" | "id" inherited (auto)
Specifies the positioning of lines when linebreaking takes place within an mrow; see below for discussion of the attribute values.
indentshift length inherited (0)
Specifies an additional indentation offset relative to the position determined by indentalign. When the value is a percentage value, the value is relative to the horizontal space that a MathML renderer has available, this is the current target width as used for linebreaking as specified in 3.1.7 Linebreaking of Expressions. Note: numbers without units were allowed in MathML 3 and treated similarly to percentage values, but unitless numbers are deprecated in MathML 4.
indenttarget idref inherited (none)
Specifies the id of another element whose horizontal position determines the position of indented lines when indentalign=id. Note that the identified element may be outside of the current math element, allowing for inter-expression alignment, or may be within invisible content such as mphantom; it must appear before being referenced, however. This may lead to an id being unavailable to a given renderer or in a position that does not allow for alignment. In such cases, the indentalign should revert to auto.
indentalignfirst "left" | "center" | "right" | "auto" | "id" | "indentalign" inherited (indentalign)
Specifies the indentation style to use for the first line of a formula; the value indentalign (the default) means to indent the same way as used for the general line.
indentshiftfirst length | "indentshift" inherited (indentshift)
Specifies the offset to use for the first line of a formula; the value indentshift (the default) means to use the same offset as used for the general line. Percentage values and numbers without unit are interpreted as described for indentshift.
indentalignlast "left" | "center" | "right" | "auto" | "id" | "indentalign" inherited (indentalign)
Specifies the indentation style to use for the last line when a linebreak occurs within a given mrow; the value indentalign (the default) means to indent the same way as used for the general line. When there are exactly two lines, the value of this attribute should be used for the second line in preference to indentalign.
indentshiftlast length | "indentshift" inherited (indentshift)
Specifies the offset to use for the last line when a linebreak occurs within a given mrow; the value indentshift (the default) means to indent the same way as used for the general line. When there are exactly two lines, the value of this attribute should be used for the second line in preference to indentshift. Percentage values and numbers without unit are interpreted as described for indentshift.

The legal values of indentalign are:

Value Meaning
left Align the left side of the next line to the left side of the line wrapping width
center Align the center of the next line to the center of the line wrapping width
right Align the right side of the next line to the right side of the line wrapping width
auto (default) indent using the renderer's default indenting style; this may be a fixed amount or one that varies with the depth of the element in the mrow nesting or some other similar method.
id Align the left side of the next line to the left side of the element referenced by the idref (given by indenttarget); if no such element exists, use auto as the indentalign value
3.2.5.3 Examples with ordinary operators
<mo> + </mo>
+
<mo> &lt; </mo>
<
<mo></mo>
<mo> &lt;= </mo>
<=
<mo> ++ </mo>
++
<mo></mo>
<mo> .NOT. </mo>
.NOT.
<mo> and </mo>
and
<mo> &#x2062;<!--InvisibleTimes--> </mo>
<mo mathvariant='bold'> + </mo>
+
3.2.5.4 Examples with fences and separators

Note that the mo elements in these examples don't need explicit fence or separator attributes, since these can be found using the operator dictionary as described below. Some of these examples could also be encoded using the mfenced element described in 3.3.8 Expression Inside Pair of Fences <mfenced>.

(a+b)

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

[0,1)

<mrow>
  <mo> [ </mo>
  <mrow>
    <mn> 0 </mn>
    <mo> , </mo>
    <mn> 1 </mn>
  </mrow>
  <mo> ) </mo>
</mrow>
[ 0 , 1 )

f(x,y)

<mrow>
  <mi> f </mi>
  <mo> &#x2061;<!--ApplyFunction--> </mo>
  <mrow>
    <mo> ( </mo>
    <mrow>
      <mi> x </mi>
      <mo> , </mo>
      <mi> y </mi>
    </mrow>
    <mo> ) </mo>
  </mrow>
</mrow>
f ( x , y )
3.2.5.5 Invisible operators

Certain operators that are invisible in traditional mathematical notation should be represented using specific characters (or entity references) within mo elements, rather than simply by nothing. The characters used for these invisible operators are:

Character Entity name Short name
U+2061 ApplyFunction af
U+2062 InvisibleTimes it
U+2063 InvisibleComma ic
U+2064
3.2.5.5.1 Examples

The MathML representations of the examples in the above table are:

<mrow>
  <mi> f </mi>
  <mo> &#x2061;<!--ApplyFunction--> </mo>
  <mrow>
    <mo> ( </mo>
    <mi> x </mi>
    <mo> ) </mo>
  </mrow>
</mrow>
f ( x )
<mrow>
  <mi> sin </mi>
  <mo> &#x2061;<!--ApplyFunction--> </mo>
  <mi> x </mi>
</mrow>
sin x
<mrow>
  <mi> x </mi>
  <mo> &#x2062;<!--InvisibleTimes--> </mo>
  <mi> y </mi>
</mrow>
x y
<msub>
  <mi> m </mi>
  <mrow>
    <mn> 1 </mn>
    <mo> &#x2063;<!--InvisibleComma--> </mo>
    <mn> 2 </mn>
  </mrow>
</msub>
m 1 2
<mrow>
  <mn> 2 </mn>
  <mo> &#x2064; </mo>
  <mfrac>
    <mn> 3 </mn>
    <mn> 4 </mn>
  </mfrac>
</mrow>
2 3 4
3.2.5.6 Detailed rendering rules for <mo> elements

Typical visual rendering behaviors for mo elements are more complex than for the other MathML token elements, so the rules for rendering them are described in this separate subsection.

Note that, like all rendering rules in MathML, these rules are suggestions rather than requirements. The description below is given to make the intended effect of the various rendering attributes as clear as possible. Detailed layout rules for browser implementations for operators are given in MathML Core.

3.2.5.6.1 The operator dictionary

Many mathematical symbols, such as an integral sign, a plus sign, or a parenthesis, have a well-established, predictable, traditional notational usage. Typically, this usage amounts to certain default attribute values for mo elements with specific contents and a specific form attribute. Since these defaults vary from symbol to symbol, MathML anticipates that renderers will have an operator dictionary of default attributes for mo elements (see B. Operator Dictionary) indexed by each mo element's content and form attribute. If an mo element is not listed in the dictionary, the default values shown in parentheses in the table of attributes for mo should be used, since these values are typically acceptable for a generic operator.

Some operators are overloaded, in the sense that they can occur in more than one form (prefix, infix, or postfix), with possibly different rendering properties for each form. For example, + can be either a prefix or an infix operator. Typically, a visual renderer would add space around both sides of an infix operator, while only in front of a prefix operator. The form attribute allows specification of which form to use, in case more than one form is possible according to the operator dictionary and the default value described below is not suitable.

3.2.5.6.2 Default value of the form attribute

The form attribute does not usually have to be specified explicitly, since there are effective heuristic rules for inferring the value of the form attribute from the context. If it is not specified, and there is more than one possible form in the dictionary for an mo element with given content, the renderer should choose which form to use as follows (but see the exception for embellished operators, described later):

  • If the operator is the first argument in an mrow with more than one argument (ignoring all space-like arguments (see 3.2.7 Space <mspace/>) in the determination of both the length and the first argument), the prefix form is used;

  • if it is the last argument in an mrow with more than one argument (ignoring all space-like arguments), the postfix form is used;

  • if it is the only element in an implicit or explicit mrow and if it is in a script position of one of the elements listed in 3.4 Script and Limit Schemata, the postfix form is used;

  • in all other cases, including when the operator is not part of an mrow, the infix form is used.

Note that the mrow discussed above may be inferred; see 3.1.3.1 Inferred <mrow>s.

Opening fences should have form="prefix", and closing fences should have form="postfix"; separators are usually infix, but not always, depending on their surroundings. As with ordinary operators, these values do not usually need to be specified explicitly.

If the operator does not occur in the dictionary with the specified form, the renderer should use one of the forms that is available there, in the order of preference: infix, postfix, prefix; if no forms are available for the given mo element content, the renderer should use the defaults given in parentheses in the table of attributes for mo.

3.2.5.6.3 Exception for embellished operators

There is one exception to the above rules for choosing an mo element's default form attribute. An mo element that is embellished by one or more nested subscripts, superscripts, surrounding text or whitespace, or style changes behaves differently. It is the embellished operator as a whole (this is defined precisely, below) whose position in an mrow is examined by the above rules and whose surrounding spacing is affected by its form, not the mo element at its core; however, the attributes influencing this surrounding spacing are taken from the mo element at the core (or from that element's dictionary entry).

For example, the +4 in a+4b should be considered an infix operator as a whole, due to its position in the middle of an mrow, but its rendering attributes should be taken from the mo element representing the +, or when those are not specified explicitly, from the operator dictionary entry for <mo form="infix"> + </mo>. The precise definition of an embellished operator is:

  • an mo element;

  • or one of the elements msub, msup, msubsup, munder, mover, munderover, mmultiscripts, mfrac, or semantics (6.5 The <semantics> element), whose first argument exists and is an embellished operator;

  • or one of the elements mstyle, mphantom, or mpadded, such that an mrow containing the same arguments would be an embellished operator;

  • or an maction element whose selected sub-expression exists and is an embellished operator;

  • or an mrow whose arguments consist (in any order) of one embellished operator and zero or more space-like elements.

Note that this definition permits nested embellishment only when there are no intervening enclosing elements not in the above list.

The above rules for choosing operator forms and defining embellished operators are chosen so that in all ordinary cases it will not be necessary for the author to specify a form attribute.

3.2.5.6.4 Spacing around an operator

The amount of horizontal space added around an operator (or embellished operator), when it occurs in an mrow, can be directly specified by the lspace and rspace attributes. Note that lspace and rspace should be interpreted as leading and trailing space, in the case of RTL direction. By convention, operators that tend to bind tightly to their arguments have smaller values for spacing than operators that tend to bind less tightly. This convention should be followed in the operator dictionary included with a MathML renderer.

Some renderers may choose to use no space around most operators appearing within subscripts or superscripts, as is done in TeX.

Non-graphical renderers should treat spacing attributes, and other rendering attributes described here, in analogous ways for their rendering medium. For example, more space might translate into a longer pause in an audio rendering.

3.2.5.7 Stretching of operators, fences and accents

Four attributes govern whether and how an operator (perhaps embellished) stretches so that it matches the size of other elements: stretchy, symmetric, maxsize, and minsize. If an operator has the attribute stretchy=true, then it (that is, each character in its content) obeys the stretching rules listed below, given the constraints imposed by the fonts and font rendering system. In practice, typical renderers will only be able to stretch a small set of characters, and quite possibly will only be able to generate a discrete set of character sizes.

There is no provision in MathML for specifying in which direction (horizontal or vertical) to stretch a specific character or operator; rather, when stretchy=true it should be stretched in each direction for which stretching is possible and reasonable for that character. It is up to the renderer to know in which directions it is reasonable to stretch a character, if it can stretch the character. Most characters can be stretched in at most one direction by typical renderers, but some renderers may be able to stretch certain characters, such as diagonal arrows, in both directions independently.

The minsize and maxsize attributes limit the amount of stretching (in either direction). These two attributes are given as multipliers of the operator's normal size in the direction or directions of stretching, or as absolute sizes using units. For example, if a character has maxsize=300%, then it can grow to be no more than three times its normal (unstretched) size.

The symmetric attribute governs whether the height and depth above and below the axis of the character are forced to be equal (by forcing both height and depth to become the maximum of the two). An example of a situation where one might set symmetric=false arises with parentheses around a matrix not aligned on the axis, which frequently occurs when multiplying non-square matrices. In this case, one wants the parentheses to stretch to cover the matrix, whereas stretching the parentheses symmetrically would cause them to protrude beyond one edge of the matrix. The symmetric attribute only applies to characters that stretch vertically (otherwise it is ignored).

If a stretchy mo element is embellished (as defined earlier in this section), the mo element at its core is stretched to a size based on the context of the embellished operator as a whole, i.e. to the same size as if the embellishments were not present. For example, the parentheses in the following example (which would typically be set to be stretchy by the operator dictionary) will be stretched to the same size as each other, and the same size they would have if they were not underlined and overlined, and furthermore will cover the same vertical interval:

<mrow>
  <munder>
    <mo> ( </mo>
    <mo> _ </mo>
  </munder>
  <mfrac>
    <mi> a </mi>
    <mi> b </mi>
  </mfrac>
  <mover>
    <mo> ) </mo>
    <mo></mo>
  </mover>
</mrow>
( _ a b )

Note that this means that the stretching rules given below must refer to the context of the embellished operator as a whole, not just to the mo element itself.

3.2.5.7.1 Example of stretchy attributes

This shows one way to set the maximum size of a parenthesis so that it does not grow, even though its default value is stretchy=true.

<mrow>
  <mo maxsize="100%">(</mo>
  <mfrac>
    <msup><mi>a</mi><mn>2</mn></msup>
    <msup><mi>b</mi><mn>2</mn></msup>
  </mfrac>
  <mo maxsize="100%">)</mo>
</mrow>
( a2 b2 )

The above should render as (\frac{a^2}{b^2}) as opposed to the default rendering \left(\frac{a^2}{b^2}\right).

Note that each parenthesis is sized independently; if only one of them had maxsize=100%, they would render with different sizes.

3.2.5.7.2 Vertical Stretching Rules

The general rules governing stretchy operators are:

  • If a stretchy operator is a direct sub-expression of an mrow element, or is the sole direct sub-expression of an mtd element in some row of a table, then it should stretch to cover the height and depth (above and below the axis) of the non-stretchy direct sub-expressions in the mrow element or table row, unless stretching is constrained by minsize or maxsize attributes.

  • In the case of an embellished stretchy operator, the preceding rule applies to the stretchy operator at its core.

  • The preceding rules also apply in situations where the mrow element is inferred.

  • The rules for symmetric stretching only apply if symmetric=true and if the stretching occurs in an mrow or in an mtr whose rowalign value is either baseline or axis.

The following algorithm specifies the height and depth of vertically stretched characters:

  1. Let maxheight and maxdepth be the maximum height and depth of the non-stretchy siblings within the same mrow or mtr. Let axis be the height of the math axis above the baseline.

    Note that even if a minsize or maxsize value is set on a stretchy operator, it is not used in the initial calculation of the maximum height and depth of an mrow.

  2. If symmetric=true, then the computed height and depth of the stretchy operator are:

    height=max(maxheight-axis, maxdepth+axis) + axis
    depth =max(maxheight-axis, maxdepth+axis) - axis

    Otherwise the height and depth are:

    height= maxheight
    depth = maxdepth
  3. If the total size = height+depth is less than minsize or greater than maxsize, increase or decrease both height and depth proportionately so that the effective size meets the constraint.

By default, most vertical arrows, along with most opening and closing fences are defined in the operator dictionary to stretch by default.

In the case of a stretchy operator in a table cell (i.e. within an mtd element), the above rules assume each cell of the table row containing the stretchy operator covers exactly one row. (Equivalently, the value of the rowspan attribute is assumed to be 1 for all the table cells in the table row, including the cell containing the operator.) When this is not the case, the operator should only be stretched vertically to cover those table cells that are entirely within the set of table rows that the operator's cell covers. Table cells that extend into rows not covered by the stretchy operator's table cell should be ignored. See 3.5.4.2 Attributes for details about the rowspan attribute.

3.2.5.7.3 Horizontal Stretching Rules
  • If a stretchy operator, or an embellished stretchy operator, is a direct sub-expression of an munder, mover, or munderover element, or if it is the sole direct sub-expression of an mtd element in some column of a table (see mtable), then it, or the mo element at its core, should stretch to cover the width of the other direct sub-expressions in the given element (or in the same table column), given the constraints mentioned above.

  • In the case of an embellished stretchy operator, the preceding rule applies to the stretchy operator at its core.

By default, most horizontal arrows and some accents stretch horizontally.

In the case of a stretchy operator in a table cell (i.e. within an mtd element), the above rules assume each cell of the table column containing the stretchy operator covers exactly one column. (Equivalently, the value of the columnspan attribute is assumed to be 1 for all the table cells in the table row, including the cell containing the operator.) When this is not the case, the operator should only be stretched horizontally to cover those table cells that are entirely within the set of table columns that the operator's cell covers. Table cells that extend into columns not covered by the stretchy operator's table cell should be ignored. See 3.5.4.2 Attributes for details about the rowspan attribute.

The rules for horizontal stretching include mtd elements to allow arrows to stretch for use in commutative diagrams laid out using mtable. The rules for the horizontal stretchiness include scripts to make examples such as the following work:

<mrow>
  <mi> x </mi>
  <munder>
    <mo></mo>
    <mtext> maps to </mtext>
  </munder>
  <mi> y </mi>
</mrow>
x maps to y
3.2.5.7.4 Rules Common to both Vertical and Horizontal Stretching

If a stretchy operator is not required to stretch (i.e. if it is not in one of the locations mentioned above, or if there are no other expressions whose size it should stretch to match), then it has the standard (unstretched) size determined by the font and current mathsize.

If a stretchy operator is required to stretch, but all other expressions in the containing element (as described above) are also stretchy, all elements that can stretch should grow to the maximum of the normal unstretched sizes of all elements in the containing object, if they can grow that large. If the value of minsize or maxsize prevents that, then the specified (min or max) size is used.

For example, in an mrow containing nothing but vertically stretchy operators, each of the operators should stretch to the maximum of all of their normal unstretched sizes, provided no other attributes are set that override this behavior. Of course, limitations in fonts or font rendering may result in the final, stretched sizes being only approximately the same.

3.2.6 Text <mtext>

3.2.6.1 Description

An mtext element is used to represent arbitrary text that should be rendered as itself. In general, the mtext element is intended to denote commentary text.

Note that text with a clearly defined notational role might be more appropriately marked up using mi or mo.

An mtext element can also contain renderable whitespace, i.e. invisible characters that are intended to alter the positioning of surrounding elements. In non-graphical media, such characters are intended to have an analogous effect, such as introducing positive or negative time delays or affecting rhythm in an audio renderer. However, see 2.1.7 Collapsing Whitespace in Input.

3.2.6.2 Attributes

mtext elements accept the attributes listed in 3.2.2 Mathematics style attributes common to token elements.

See also the warnings about the legal grouping of space-like elements in 3.2.7 Space <mspace/>, and about the use of such elements for tweaking in [MathML-Notes].

3.2.6.3 Examples
<mrow>
  <mtext> Theorem 1: </mtext>
  <mtext> &#x2009;<!--ThinSpace--> </mtext>
  <mtext> &#x205F;<!--ThickSpace-->&#x205F;<!--ThickSpace--> </mtext>
  <mtext> /* a comment */ </mtext>
</mrow>
Theorem 1:    /* a comment */

3.2.7 Space <mspace/>

3.2.7.1 Description

An mspace empty element represents a blank space of any desired size, as set by its attributes. It can also be used to make linebreaking suggestions to a visual renderer. Note that the default values for attributes have been chosen so that they typically will have no effect on rendering. Thus, the mspace element is generally used with one or more attribute values explicitly specified.

Note the warning about the legal grouping of space-like elements given below, and the warning about the use of such elements for tweaking in [MathML-Notes]. See also the other elements that can render as whitespace, namely mtext, mphantom, and maligngroup.

3.2.7.2 Attributes

In addition to the attributes listed below, mspace elements accept the attributes described in 3.2.2 Mathematics style attributes common to token elements, but note that mathvariant and mathcolor have no effect and that mathsize only affects the interpretation of units in sizing attributes (see 2.1.5.2 Length Valued Attributes). mspace also accepts the indentation attributes described in 3.2.5.2.3 Indentation attributes.

Name values default
width length 0em
Specifies the desired width of the space.
height length 0ex
Specifies the desired height (above the baseline) of the space.
depth length 0ex
Specifies the desired depth (below the baseline) of the space.

Linebreaking was originally specified on mspace in MathML2, but much greater control over linebreaking and indentation was add to mo in MathML 3. Linebreaking on mspace is deprecated in MathML 4.

3.2.7.3 Examples
<mspace height="3ex" depth="2ex"/>
3.2.7.4 Definition of space-like elements

A number of MathML presentation elements are space-like in the sense that they typically render as whitespace, and do not affect the mathematical meaning of the expressions in which they appear. As a consequence, these elements often function in somewhat exceptional ways in other MathML expressions. For example, space-like elements are handled specially in the suggested rendering rules for mo given in 3.2.5 Operator, Fence, Separator or Accent <mo>. The following MathML elements are defined to be space-like:

  • an mtext, mspace, maligngroup, or malignmark element;

  • an mstyle, mphantom, or mpadded element, all of whose direct sub-expressions are space-like;

  • a semantics element whose first argument exists and is space-like;

  • an maction element whose selected sub-expression exists and is space-like;

  • an mrow all of whose direct sub-expressions are space-like.

Note that an mphantom is not automatically defined to be space-like, unless its content is space-like. This is because operator spacing is affected by whether adjacent elements are space-like. Since the mphantom element is primarily intended as an aid in aligning expressions, operators adjacent to an mphantom should behave as if they were adjacent to the contents of the mphantom, rather than to an equivalently sized area of whitespace.

3.2.8 String Literal <ms>

3.2.8.1 Description

The ms element is used to represent string literals in expressions meant to be interpreted by computer algebra systems or other systems containing programming languages. By default, string literals are displayed surrounded by double quotes, with no extra spacing added around the string. As explained in 3.2.6 Text <mtext>, ordinary text embedded in a mathematical expression should be marked up with mtext, or in some cases mo or mi, but never with ms.

Note that the string literals encoded by ms are made up of characters, mglyphs and malignmarks rather than ASCII strings. For example, <ms>&amp;</ms> represents a string literal containing a single character, &, and <ms>&amp;amp;</ms> represents a string literal containing 5 characters, the first one of which is &.

The content of ms elements should be rendered with visible escaping of certain characters in the content, including at least the left and right quoting characters, and preferably whitespace other than individual space characters. The intent is for the viewer to see that the expression is a string literal, and to see exactly which characters form its content. For example, <ms>double quote is "</ms> might be rendered as "double quote is \"".

Like all token elements, ms does trim and collapse whitespace in its content according to the rules of 2.1.7 Collapsing Whitespace in Input, so whitespace intended to remain in the content should be encoded as described in that section.

3.2.8.2 Attributes

ms elements accept the attributes listed in 3.2.2 Mathematics style attributes common to token elements, and additionally:

Name values default
lquote string U+0022 (entity quot)
Specifies the opening quote to enclose the content (not necessarily ‘left quote’ in RTL context).
rquote string U+0022 (entity quot)
Specifies the closing quote to enclose the content (not necessarily ‘right quote’ in RTL context).

3.3 General Layout Schemata

Besides tokens there are several families of MathML presentation elements. One family of elements deals with various scripting notations, such as subscript and superscript. Another family is concerned with matrices and tables. The remainder of the elements, discussed in this section, describe other basic notations such as fractions and radicals, or deal with general functions such as setting style properties and error handling.

3.3.1 Horizontally Group Sub-Expressions <mrow>

3.3.1.1 Description

An mrow element is used to group together any number of sub-expressions, usually consisting of one or more mo elements acting as operators on one or more other expressions that are their operands.

Several elements automatically treat their arguments as if they were contained in an mrow element. See the discussion of inferred mrows in 3.1.3 Required Arguments. See also mfenced (3.3.8 Expression Inside Pair of Fences <mfenced>), which can effectively form an mrow containing its arguments separated by commas.

mrow elements are typically rendered visually as a horizontal row of their arguments, left to right in the order in which the arguments occur within a context with LTR directionality, or right to left within a context with RTL directionality. The dir attribute can be used to specify the directionality for a specific mrow, otherwise it inherits the directionality from the context. For aural agents, the arguments would be rendered audibly as a sequence of renderings of the arguments. The description in 3.2.5 Operator, Fence, Separator or Accent <mo> of suggested rendering rules for mo elements assumes that all horizontal spacing between operators and their operands is added by the rendering of mo elements (or, more generally, embellished operators), not by the rendering of the mrows they are contained in.

MathML provides support for both automatic and manual linebreaking of expressions (that is, to break excessively long expressions into several lines). All such linebreaks take place within mrows, whether they are explicitly marked up in the document, or inferred (see 3.1.3.1 Inferred <mrow>s), although the control of linebreaking is effected through attributes on other elements (see 3.1.7 Linebreaking of Expressions).

3.3.1.2 Attributes

mrow elements accept the attribute listed below in addition to those listed in 3.1.9 Mathematics attributes common to presentation elements.

Name values default
dir "ltr" | "rtl" inherited
specifies the overall directionality ltr (Left To Right) or rtl (Right To Left) to use to layout the children of the row. See 3.1.5.1 Overall Directionality of Mathematics Formulas for further discussion.
3.3.1.3 Proper grouping of sub-expressions using <mrow>

Sub-expressions should be grouped by the document author in the same way as they are grouped in the mathematical interpretation of the expression; that is, according to the underlying syntax tree of the expression. Specifically, operators and their mathematical arguments should occur in a single mrow; more than one operator should occur directly in one mrow only when they can be considered (in a syntactic sense) to act together on the interleaved arguments, e.g. for a single parenthesized term and its parentheses, for chains of relational operators, or for sequences of terms separated by + and -. A precise rule is given below.

Proper grouping has several purposes: it improves display by possibly affecting spacing; it allows for more intelligent linebreaking and indentation; and it simplifies possible semantic interpretation of presentation elements by computer algebra systems, and audio renderers.

Although improper grouping will sometimes result in suboptimal renderings, and will often make interpretation other than pure visual rendering difficult or impossible, any grouping of expressions using mrow is allowed in MathML syntax; that is, renderers should not assume the rules for proper grouping will be followed.

3.3.1.3.1 <mrow> of one argument

MathML renderers are required to treat an mrow element containing exactly one argument as equivalent in all ways to the single argument occurring alone, provided there are no attributes on the mrow element. If there are attributes on the mrow element, no requirement of equivalence is imposed. This equivalence condition is intended to simplify the implementation of MathML-generating software such as template-based authoring tools. It directly affects the definitions of embellished operator and space-like element and the rules for determining the default value of the form attribute of an mo element; see 3.2.5 Operator, Fence, Separator or Accent <mo> and 3.2.7 Space <mspace/>. See also the discussion of equivalence of MathML expressions in D.1 MathML Conformance.

3.3.1.3.2 Precise rule for proper grouping

A precise rule for when and how to nest sub-expressions using mrow is especially desirable when generating MathML automatically by conversion from other formats for displayed mathematics, such as TeX, which don't always specify how sub-expressions nest. When a precise rule for grouping is desired, the following rule should be used:

Two adjacent operators, possibly embellished, possibly separated by operands (i.e. anything other than operators), should occur in the same mrow only when the leading operator has an infix or prefix form (perhaps inferred), the following operator has an infix or postfix form, and the operators have the same priority in the operator dictionary (B. Operator Dictionary). In all other cases, nested mrows should be used.

When forming a nested mrow (during generation of MathML) that includes just one of two successive operators with the forms mentioned above (which means that either operator could in principle act on the intervening operand or operands), it is necessary to decide which operator acts on those operands directly (or would do so, if they were present). Ideally, this should be determined from the original expression; for example, in conversion from an operator-precedence-based format, it would be the operator with the higher precedence.

Note that the above rule has no effect on whether any MathML expression is valid, only on the recommended way of generating MathML from other formats for displayed mathematics or directly from written notation.

(Some of the terminology used in stating the above rule is defined in 3.2.5 Operator, Fence, Separator or Accent <mo>.)

3.3.1.4 Examples

As an example, 2x+y-z should be written as:

<mrow>
  <mrow>
    <mn> 2 </mn>
    <mo> &#x2062;<!--InvisibleTimes--> </mo>
    <mi> x </mi>
  </mrow>
  <mo> + </mo>
  <mi> y </mi>
  <mo> - </mo>
  <mi> z </mi>
</mrow>
2 x + y - z

The proper encoding of (x, y) furnishes a less obvious example of nesting mrows:

<mrow>
  <mo> ( </mo>
  <mrow>
    <mi> x </mi>
    <mo> , </mo>
    <mi> y </mi>
  </mrow>
  <mo> ) </mo>
</mrow>
( x , y )

In this case, a nested mrow is required inside the parentheses, since parentheses and commas, thought of as fence and separator operators, do not act together on their arguments.

3.3.2 Fractions <mfrac>

3.3.2.1 Description

The mfrac element is used for fractions. It can also be used to mark up fraction-like objects such as binomial coefficients and Legendre symbols. The syntax for mfrac is

<mfrac> numerator denominator </mfrac>

The mfrac element sets displaystyle to false, or if it was already false increments scriptlevel by 1, within numerator and denominator. (See 3.1.6 Displaystyle and Scriptlevel.)

3.3.2.2 Attributes

mfrac elements accept the attributes listed below in addition to those listed in 3.1.9 Mathematics attributes common to presentation elements. The fraction line, if any, should be drawn using the color specified by mathcolor.

Name values default
linethickness length | "thin" | "medium" | "thick" medium
Specifies the thickness of the horizontal fraction bar, or rule. The default value is medium; thin is thinner, but visible; thick is thicker. The exact thickness of these is left up to the rendering agent. However, if OpenType Math fonts are available then the renderer should set medium to the value MATH.MathConstants.fractionRuleThickness (the default in MathML-Core).
Note: MathML Core does only allow length-percentage values.
numalign "left" | "center" | "right" center
Specifies the alignment of the numerator over the fraction.
denomalign "left" | "center" | "right" center
Specifies the alignment of the denominator under the fraction.
bevelled "true" | "false" false
Specifies whether the fraction should be displayed in a beveled style (the numerator slightly raised, the denominator slightly lowered and both separated by a slash), rather than "build up" vertically. See below for an example.

Thicker lines (e.g. linethickness="thick") might be used with nested fractions; a value of "0" renders without the bar such as for binomial coefficients.

In a RTL directionality context, the numerator leads (on the right), the denominator follows (on the left) and the diagonal line slants upwards going from right to left (see 3.1.5.1 Overall Directionality of Mathematics Formulas for clarification). Although this format is an established convention, it is not universally followed; for situations where a forward slash is desired in a RTL context, alternative markup, such as an mo within an mrow should be used.

3.3.2.3 Examples

Here is an example which makes use of different values of linethickness:

<mfrac linethickness="3px">
  <mrow>
    <mo> ( </mo>
      <mfrac linethickness="0">
        <mi> a </mi>
        <mi> b </mi>
      </mfrac>
    <mo> ) </mo>
    <mfrac>
      <mi> a </mi>
      <mi> b </mi>
    </mfrac>
  </mrow>
  <mfrac>
    <mi> c </mi>
    <mi> d </mi>
  </mfrac>
</mfrac>
( a b ) a b c d

This example illustrates bevelled fractions:

<mfrac>
  <mn> 1 </mn>
  <mrow>
    <msup>
      <mi> x </mi>
      <mn> 3 </mn>
    </msup>
    <mo> + </mo>
    <mfrac>
      <mi> x </mi>
      <mn> 3 </mn>
    </mfrac>
  </mrow>
</mfrac>
<mo> = </mo>
<mfrac bevelled="true">
  <mn> 1 </mn>
  <mrow>
    <msup>
      <mi> x </mi>
      <mn> 3 </mn>
    </msup>
    <mo> + </mo>
    <mfrac>
      <mi> x </mi>
      <mn> 3 </mn>
    </mfrac>
  </mrow>
</mfrac>
\frac{{1}}{{x^3 + \frac{{x}}{{3}}}} = \raisebox{{1ex}}{{$1$}}\!\left/ \!\raisebox{{-1ex}}{{$x^3+\frac{{x}}{{3}}$}} \right.

A more generic example is:

<mfrac>
  <mrow>
    <mn> 1 </mn>
    <mo> + </mo>
    <msqrt>
      <mn> 5 </mn>
    </msqrt>
  </mrow>
  <mn> 2 </mn>
</mfrac>
1 + 5 2

3.3.3 Radicals <msqrt>, <mroot>

3.3.3.1 Description

These elements construct radicals. The msqrt element is used for square roots, while the mroot element is used to draw radicals with indices, e.g. a cube root. The syntax for these elements is:

<msqrt> base </msqrt>
<mroot> base index </mroot>

The mroot element requires exactly 2 arguments. However, msqrt accepts a single argument, possibly being an inferred mrow of multiple children; see 3.1.3 Required Arguments. The mroot element increments scriptlevel by 2, and sets displaystyle to false, within index, but leaves both attributes unchanged within base. The msqrt element leaves both attributes unchanged within its argument. (See 3.1.6 Displaystyle and Scriptlevel.)

Note that in a RTL directionality, the surd begins on the right, rather than the left, along with the index in the case of mroot.

3.3.3.2 Attributes

msqrt and mroot elements accept the attributes listed in 3.1.9 Mathematics attributes common to presentation elements. The surd and overbar should be drawn using the color specified by mathcolor.

3.3.3.3 Examples

Square roots and cube roots

<mrow>
  <mrow>
    <msqrt>
      <mi>x</mi>
    </msqrt>
    <mroot>
      <mi>x</mi>
      <mn>3</mn>
    </mroot>
  <mrow>
  <mo>=</mo>
  <msup>
    <mi>x</mi>
    <mrow>
      <mrow>
        <mn>1</mn>
        <mo>/</mo>
        <mn>2</mn>
      </mrow>
      <mo>+</mo>
      <mrow>
        <mn>1</mn>
        <mo>/</mo>
        <mn>3</mn>
      </mrow>
    </mrow>
  </msup>
</mrow>
x x 3 = x 1 / 2 + 1 / 3

3.3.4 Style Change <mstyle>

3.3.4.1 Description

The mstyle element is used to make style changes that affect the rendering of its contents. As a presentation element, it accepts the attributes described in 3.1.9 Mathematics attributes common to presentation elements. Additionally, it can be given any attribute accepted by any other presentation element, except for the attributes described below. Finally, the mstyle element can be given certain special attributes listed in the next subsection.

The mstyle element accepts a single argument, possibly being an inferred mrow of multiple children; see 3.1.3 Required Arguments.

Loosely speaking, the effect of the mstyle element is to change the default value of an attribute for the elements it contains. Style changes work in one of several ways, depending on the way in which default values are specified for an attribute. The cases are:

  • Some attributes, such as displaystyle or scriptlevel (explained below), are inherited from the surrounding context when they are not explicitly set. Specifying such an attribute on an mstyle element sets the value that will be inherited by its child elements. Unless a child element overrides this inherited value, it will pass it on to its children, and they will pass it to their children, and so on. But if a child element does override it, either by an explicit attribute setting or automatically (as is common for scriptlevel), the new (overriding) value will be passed on to that element's children, and then to their children, etc, unless it is again overridden.

  • Other attributes, such as linethickness on mfrac, have default values that are not normally inherited. That is, if the linethickness attribute is not set on the mfrac element, it will normally use the default value of medium, even if it was contained in a larger mfrac element that set this attribute to a different value. For attributes like this, specifying a value with an mstyle element has the effect of changing the default value for all elements within its scope. The net effect is that setting the attribute value with mstyle propagates the change to all the elements it contains directly or indirectly, except for the individual elements on which the value is overridden. Unlike in the case of inherited attributes, elements that explicitly override this attribute have no effect on this attribute's value in their children.

  • Another group of attributes, such as stretchy and form, are computed from operator dictionary information, position in the enclosing mrow, and other similar data. For these attributes, a value specified by an enclosing mstyle overrides the value that would normally be computed.

Note that attribute values inherited from an mstyle in any manner affect a descendant element in the mstyle's content only if that attribute is not given a value by the descendant element. On any element for which the attribute is set explicitly, the value specified overrides the inherited value. The only exception to this rule is when the attribute value is documented as specifying an incremental change to the value inherited from that element's context or rendering environment.

Note also that the difference between inherited and non-inherited attributes set by mstyle, explained above, only matters when the attribute is set on some element within the mstyle's contents that has descendants also setting it. Thus it never matters for attributes, such as mathsize, which can only be set on token elements (or on mstyle itself).

MathML specifies that when the attributes height, depth or width are specified on an mstyle element, they apply only to mspace elements, and not to the corresponding attributes of mglyph, mpadded, or mtable. Similarly, when rowalign or columnalign are specified on an mstyle element, they apply only to the mtable element, and not the mtr, mlabeledtr, mtd, and maligngroup elements. When the lspace attribute is set with mstyle, it applies only to the mo element and not to mpadded. To be consistent, the voffset attribute of the mpadded element can not be set on mstyle. When the align attribute is set with mstyle, it applies only to the munder, mover, and munderover elements, and not to the mtable and mstack elements. The required attributes src and alt on mglyph, and actiontype on maction, cannot be set on mstyle.

As a presentation element, mstyle directly accepts the mathcolor and mathbackground attributes. Thus, the mathbackground specifies the color to fill the bounding box of the mstyle element itself; it does not specify the default background color. This is an incompatible change from MathML 2, but it is more useful and intuitive. Since the default for mathcolor is inherited, this is no change in its behavior.

3.3.4.2 Attributes

As stated above, mstyle accepts all attributes of all MathML presentation elements which do not have required values. That is, all attributes which have an explicit default value or a default value which is inherited or computed are accepted by the mstyle element. This group of attributes is not accepted in MathML Core.

mstyle elements accept the attributes listed in 3.1.9 Mathematics attributes common to presentation elements.

Additionally, mstyle can be given the following special attributes that are implicitly inherited by every MathML element as part of its rendering environment:

Name values default
scriptlevel ( "+" | "-" )? unsigned-integer inherited
Changes the scriptlevel in effect for the children. When the value is given without a sign, it sets scriptlevel to the specified value; when a sign is given, it increments ("+") or decrements ("-") the current value. (Note that large decrements can result in negative values of scriptlevel, but these values are considered legal.) See 3.1.6 Displaystyle and Scriptlevel.
displaystyle "true" | "false" inherited
Changes the displaystyle in effect for the children. See 3.1.6 Displaystyle and Scriptlevel.
scriptsizemultiplier number 0.71
Specifies the multiplier to be used to adjust font size due to changes in scriptlevel. See 3.1.6 Displaystyle and Scriptlevel.
scriptminsize length 8pt
Specifies the minimum font size allowed due to changes in scriptlevel. Note that this does not limit the font size due to changes to mathsize. See 3.1.6 Displaystyle and Scriptlevel.
infixlinebreakstyle "before" | "after" | "duplicate" before
Specifies the default linebreakstyle to use for infix operators; see 3.2.5.2.2 Linebreaking attributes
decimalpoint character .
Specifies the character used to determine the alignment point within mstack and mtable columns when the "decimalpoint" value is used to specify the alignment. The default, ".", is the decimal separator used to separate the integral and decimal fractional parts of floating point numbers in many countries. (See 3.6 Elementary Math and 3.5.5 Alignment Markers <maligngroup/>, <malignmark/>).

If scriptlevel is changed incrementally by an mstyle element that also sets certain other attributes, the overall effect of the changes may depend on the order in which they are processed. In such cases, the attributes in the following list should be processed in the following order, regardless of the order in which they occur in the XML-format attribute list of the mstyle start tag: scriptsizemultiplier, scriptminsize, scriptlevel, mathsize.

3.3.4.3 Examples

In a continued fraction, the nested fractions should not shrink. Instead, they should remain the same size. This can be accomplished by resetting displaystyle and scriptlevel for the children of each mfrac using mstyle as shown below:

<mrow>
  <mi>π</mi>
  <mo>=</mo>
  <mfrac>
    <mstyle displaystyle="true" scriptlevel="0"> <mn>4</mn> </mstyle>
    <mstyle displaystyle="true" scriptlevel="0">
      <mn>1</mn>
      <mo>+</mo>
      <mfrac>
        <mstyle displaystyle="true" scriptlevel="0">
          <msup> <mn>1</mn> <mn>2</mn> </msup>
        </mstyle>
        <mstyle displaystyle="true" scriptlevel="0">
          <mn>2</mn>
          <mo>+</mo>
          <mfrac>
            <mstyle displaystyle="true" scriptlevel="0">
              <msup> <mn>3</mn> <mn>2</mn> </msup>
            </mstyle>
            <mstyle displaystyle="true" scriptlevel="0">
              <mn>2</mn>
              <mo>+</mo>
              <mfrac>
                <mstyle displaystyle="true" scriptlevel="0">
                  <msup> <mn>5</mn> <mn>2</mn> </msup>
                </mstyle>
                <mstyle displaystyle="true" scriptlevel="0">
                  <mn>2</mn>
                  <mo>+</mo>
                  <mfrac>
                    <mstyle displaystyle="true" scriptlevel="0">
                      <msup> <mn>7</mn> <mn>2</mn> </msup>
                    </mstyle>
                    <mstyle displaystyle="true" scriptlevel="0">
                      <mn>2</mn>
                      <mo>+</mo>
                      <mo></mo>
                    </mstyle>
                  </mfrac>
                </mstyle>
              </mfrac>
            </mstyle>
          </mfrac>
        </mstyle>
      </mfrac>
    </mstyle>
  </mfrac>
</mrow>
π = 4 1 + 1 2 2 + 3 2 2 + 5 2 2 + 7 2 2 +

3.3.5 Error Message <merror>

3.3.5.1 Description

The merror element displays its contents as an error message. This might be done, for example, by displaying the contents in red, flashing the contents, or changing the background color. The contents can be any expression or expression sequence.

merror accepts a single argument possibly being an inferred mrow of multiple children; see 3.1.3 Required Arguments.

The intent of this element is to provide a standard way for programs that generate MathML from other input to report syntax errors in their input. Since it is anticipated that preprocessors that parse input syntaxes designed for easy hand entry will be developed to generate MathML, it is important that they have the ability to indicate that a syntax error occurred at a certain point. See D.2 Handling of Errors.

The suggested use of merror for reporting syntax errors is for a preprocessor to replace the erroneous part of its input with an merror element containing a description of the error, while processing the surrounding expressions normally as far as possible. By this means, the error message will be rendered where the erroneous input would have appeared, had it been correct; this makes it easier for an author to determine from the rendered output what portion of the input was in error.

No specific error message format is suggested here, but as with error messages from any program, the format should be designed to make as clear as possible (to a human viewer of the rendered error message) what was wrong with the input and how it can be fixed. If the erroneous input contains correctly formatted subsections, it may be useful for these to be preprocessed normally and included in the error message (within the contents of the merror element), taking advantage of the ability of merror to contain arbitrary MathML expressions rather than only text.

3.3.5.2 Attributes

merror elements accept the attributes listed in 3.1.9 Mathematics attributes common to presentation elements.

3.3.5.3 Example

If a MathML syntax-checking preprocessor received the input

<mfraction>
  <mrow> <mn> 1 </mn> <mo> + </mo> <msqrt> <mn> 5 </mn> </msqrt> </mrow>
  <mn> 2 </mn>
</mfraction>

which contains the non-MathML element mfraction (presumably in place of the MathML element mfrac), it might generate the error message

<merror>
  <mtext> Unrecognized element: mfraction; arguments were:&#xa0;</mtext>
  <mrow> <mn> 1 </mn> <mo> + </mo> <msqrt> <mn> 5 </mn> </msqrt> </mrow>
  <mtext>&#xa0;and&#xa0;</mtext>
  <mn> 2 </mn>
</merror>
Unrecognized element: mfraction; arguments were:  1 + 5  and  2

Note that the preprocessor's input is not, in this case, valid MathML, but the error message it outputs is valid MathML.

3.3.6 Adjust Space Around Content <mpadded>

3.3.6.1 Description

An mpadded element renders the same as its child content, but with the size of the child's bounding box and the relative positioning point of its content modified according to mpadded's attributes. It does not rescale (stretch or shrink) its content. The name of the element reflects the typical use of mpadded to add padding, or extra space, around its content. However, mpadded can be used to make more general adjustments of size and positioning, and some combinations, e.g. negative padding, can cause the content of mpadded to overlap the rendering of neighboring content. See [MathML-Notes] for warnings about several potential pitfalls of this effect.

The mpadded element accepts a single argument which may be an inferred mrow of multiple children; see 3.1.3 Required Arguments.

It is suggested that audio renderers add (or shorten) time delays based on the attributes representing horizontal space (width and lspace).

3.3.6.2 Attributes

mpadded elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements.

Name values default
height ( "+" | "-" )? unsigned-number ( ("%" pseudo-unit?) | pseudo-unit | unit | namedspace )? same as content
Sets or increments the height of the mpadded element. See below for discussion.
depth ( "+" | "-" )? unsigned-number (("%" pseudo-unit?) | pseudo-unit | unit | namedspace )? same as content
Sets or increments the depth of the mpadded element. See below for discussion.
width ( "+" | "-" )? unsigned-number ( ("%" pseudo-unit?) | pseudo-unit | unit | namedspace )? same as content
Sets or increments the width of the mpadded element. See below for discussion.
lspace ( "+" | "-" )? unsigned-number ( ("%" pseudo-unit?) | pseudo-unit | unit | namedspace )? 0em
Sets the horizontal position of the child content. See below for discussion.
voffset ( "+" | "-" )? unsigned-number ( ("%" pseudo-unit?) | pseudo-unit | unit | namedspace )? 0em
Sets the vertical position of the child content. See below for discussion.

Note: while [MathML-Core] supports the above attributes, it only allows the value to be a valid length-percentage. Increments with the optional "+" or "-" signs are not supported in MathML Core nor are pseudo-units.

The pseudo-unit syntax symbol is described below. Also, height, depth and width attributes are referred to as size attributes, while lspace and voffset attributes are position attributes.

These attributes specify the size of the bounding box of the mpadded element relative to the size of the bounding box of its child content, and specify the position of the child content of the mpadded element relative to the natural positioning of the mpadded element. The typographical layout parameters determined by these attributes are described in the next subsection. Depending on the form of the attribute value, a dimension may be set to a new value, or specified relative to the child content's corresponding dimension. Values may be given as multiples or percentages of any of the dimensions of the normal rendering of the child content using so-called pseudo-units, or they can be set directly using standard units, see 2.1.5.2 Length Valued Attributes.

If the value of a size attribute begins with a + or - sign, it specifies an increment or decrement to the corresponding dimension by the following length value. Otherwise the corresponding dimension is set directly to the following length value. Note that since a leading minus sign indicates a decrement, the size attributes (height, depth, width) cannot be set directly to negative values. In addition, specifying a decrement that would produce a net negative value for these attributes has the same effect as setting the attribute to zero. In other words, the effective bounding box of an mpadded element always has non-negative dimensions. However, negative values are allowed for the relative positioning attributes lspace and voffset.

Length values (excluding any sign) can be specified in several formats. Each format begins with an unsigned-number, which may be followed by a % sign (effectively scaling the number) and an optional pseudo-unit, by a pseudo-unit alone, or by a unit (excepting %). The possible pseudo-units are the keywords height, depth, and width. They represent the length of the same-named dimension of the mpadded element's child content.

For any of these length formats, the resulting length is the product of the number (possibly including the %) and the following pseudo-unit, unit, namedspace or the default value for the attribute if no such unit or space is given.

Some examples of attribute formats using pseudo-units (explicit or default) are as follows: depth="100%height" and depth="1.0height" both set the depth of the mpadded element to the height of its content. depth="105%" sets the depth to 1.05 times the content's depth, and either depth="+100%" or depth="200%" sets the depth to twice the content's depth.

The rules given above imply that all of the following attribute settings have the same effect, which is to leave the content's dimensions unchanged:

<mpadded width="+0em"> ... </mpadded>
<mpadded width="+0%"> ... </mpadded>
<mpadded width="-0em"> ... </mpadded>
<mpadded width="-0height"> ... </mpadded>
<mpadded width="100%"> ... </mpadded>
<mpadded width="100%width"> ... </mpadded>
<mpadded width="1width"> ... </mpadded>
<mpadded width="1.0width"> ... </mpadded>
<mpadded> ... </mpadded>

Note that the examples in the Version 2 of the MathML specification showed spaces within the attribute values, suggesting that this was the intended format. Formally, spaces are not allowed within these values, but implementers may wish to ignore such spaces to maximize backward compatibility.

3.3.6.3 Meanings of size and position attributes

The content of an mpadded element defines a fragment of mathematical notation, such as a character, fraction, or expression, that can be regarded as a single typographical element with a natural positioning point relative to its natural bounding box.

The size of the bounding box of an mpadded element is defined as the size of the bounding box of its content, except as modified by the mpadded element's height, depth, and width attributes. The natural positioning point of the child content of the mpadded element is located to coincide with the natural positioning point of the mpadded element, except as modified by the lspace and voffset attributes. Thus, the size attributes of mpadded can be used to expand or shrink the apparent bounding box of its content, and the position attributes of mpadded can be used to move the content relative to the bounding box (and hence also neighboring elements). Note that MathML doesn't define the precise relationship between "ink", bounding boxes and positioning points, which are implementation specific. Thus, absolute values for mpadded attributes may not be portable between implementations.

The height attribute specifies the vertical extent of the bounding box of the mpadded element above its baseline. Increasing the height increases the space between the baseline of the mpadded element and the content above it, and introduces padding above the rendering of the child content. Decreasing the height reduces the space between the baseline of the mpadded element and the content above it, and removes space above the rendering of the child content. Decreasing the height may cause content above the mpadded element to overlap the rendering of the child content, and should generally be avoided.

The depth attribute specifies the vertical extent of the bounding box of the mpadded element below its baseline. Increasing the depth increases the space between the baseline of the mpadded element and the content below it, and introduces padding below the rendering of the child content. Decreasing the depth reduces the space between the baseline of the mpadded element and the content below it, and removes space below the rendering of the child content. Decreasing the depth may cause content below the mpadded element to overlap the rendering of the child content, and should generally be avoided.

The width attribute specifies the horizontal distance between the positioning point of the mpadded element and the positioning point of the following content. Increasing the width increases the space between the positioning point of the mpadded element and the content that follows it, and introduces padding after the rendering of the child content. Decreasing the width reduces the space between the positioning point of the mpadded element and the content that follows it, and removes space after the rendering of the child content. Setting the width to zero causes following content to be positioned at the positioning point of the mpadded element. Decreasing the width should generally be avoided, as it may cause overprinting of the following content.

The lspace attribute ("leading" space; see 3.1.5.1 Overall Directionality of Mathematics Formulas) specifies the horizontal location of the positioning point of the child content with respect to the positioning point of the mpadded element. By default they coincide, and therefore absolute values for lspace have the same effect as relative values. Positive values for the lspace attribute increase the space between the preceding content and the child content, and introduce padding before the rendering of the child content. Negative values for the lspace attributes reduce the space between the preceding content and the child content, and may cause overprinting of the preceding content, and should generally be avoided. Note that the lspace attribute does not affect the width of the mpadded element, and so the lspace attribute will also affect the space between the child content and following content, and may cause overprinting of the following content, unless the width is adjusted accordingly.

The voffset attribute specifies the vertical location of the positioning point of the child content with respect to the positioning point of the mpadded element. Positive values for the voffset attribute raise the rendering of the child content above the baseline. Negative values for the voffset attribute lower the rendering of the child content below the baseline. In either case, the voffset attribute may cause overprinting of neighboring content, which should generally be avoided. Note that the voffset attribute does not affect the height or depth of the mpadded element, and so the voffset attribute will also affect the space between the child content and neighboring content, and may cause overprinting of the neighboring content, unless the height or depth is adjusted accordingly.

MathML renderers should ensure that, except for the effects of the attributes, the relative spacing between the contents of the mpadded element and surrounding MathML elements would not be modified by replacing an mpadded element with an mrow element with the same content, even if linebreaking occurs within the mpadded element. MathML does not define how non-default attribute values of an mpadded element interact with the linebreaking algorithm.

3.3.6.4 Examples

The effects of the size and position attributes are illustrated below. The following diagram illustrates the use of lspace and voffset to shift the position of child content without modifying the mpadded bounding box.

illustration of the use of mpadded to shift the position of child content without modifying the bounding box

The corresponding MathML is:

<mrow>
  <mi>x</mi>
  <mpadded lspace="0.2em" voffset="0.3ex">
    <mi>y</mi>
  </mpadded>
  <mi>z</mi>
</mrow>
x y z

The next diagram illustrates the use of width, height and depth to modifying the mpadded bounding box without changing the relative position of the child content.

illustration of the use of mpadded to modifying its bounding box without shifting the relative location of its child content

The corresponding MathML is:

<mrow>
  <mi>x</mi>
  <mpadded width="+90%width" height="+0.3ex" depth="+0.3ex">
    <mi>y</mi>
  </mpadded>
  <mi>z</mi>
</mrow>

The final diagram illustrates the generic use of mpadded to modify both the bounding box and relative position of child content.

illustration of the use of mpadded to modify both the bounding box size and position of child content

The corresponding MathML is:

<mrow>
  <mi>x</mi>
  <mpadded lspace="0.3em" width="+0.6em">
    <mi>y</mi>
  </mpadded>
  <mi>z</mi>
</mrow>

3.3.7 Making Sub-Expressions Invisible <mphantom>

3.3.7.1 Description

The mphantom element renders invisibly, but with the same size and other dimensions, including baseline position, that its contents would have if they were rendered normally. mphantom can be used to align parts of an expression by invisibly duplicating sub-expressions.

The mphantom element accepts a single argument possibly being an inferred mrow of multiple children; see 3.1.3 Required Arguments.

Note that it is possible to wrap both an mphantom and an mpadded element around one MathML expression, as in <mphantom><mpadded attribute-settings> ... </mpadded></mphantom>, to change its size and make it invisible at the same time.

MathML renderers should ensure that the relative spacing between the contents of an mphantom element and the surrounding MathML elements is the same as it would be if the mphantom element were replaced by an mrow element with the same content. This holds even if linebreaking occurs within the mphantom element.

For the above reason, mphantom is not considered space-like (3.2.7 Space <mspace/>) unless its content is space-like, since the suggested rendering rules for operators are affected by whether nearby elements are space-like. Even so, the warning about the legal grouping of space-like elements may apply to uses of mphantom.

3.3.7.2 Attributes

mphantom elements accept the attributes listed in 3.1.9 Mathematics attributes common to presentation elements (the mathcolor has no effect).

3.3.7.3 Examples

There is one situation where the preceding rules for rendering an mphantom may not give the desired effect. When an mphantom is wrapped around a subsequence of the arguments of an mrow, the default determination of the form attribute for an mo element within the subsequence can change. (See the default value of the form attribute described in 3.2.5 Operator, Fence, Separator or Accent <mo>.) It may be necessary to add an explicit form attribute to such an mo in these cases. This is illustrated in the following example.

In this example, mphantom is used to ensure alignment of corresponding parts of the numerator and denominator of a fraction:

<mfrac>
  <mrow>
    <mi> x </mi>
    <mo> + </mo>
    <mi> y </mi>
    <mo> + </mo>
    <mi> z </mi>
  </mrow>
  <mrow>
    <mi> x </mi>
    <mphantom>
      <mo form="infix"> + </mo>
      <mi> y </mi>
    </mphantom>
    <mo> + </mo>
    <mi> z </mi>
  </mrow>
</mfrac>
x + y + z x + y + z

This would render as something like

\frac{x+y+x}{x\phantom{{}+y}+z}

rather than as

\frac{x+y+z}{x+z}

The explicit attribute setting form="infix" on the mo element inside the mphantom sets the form attribute to what it would have been in the absence of the surrounding mphantom. This is necessary since otherwise, the + sign would be interpreted as a prefix operator, which might have slightly different spacing.

Alternatively, this problem could be avoided without any explicit attribute settings, by wrapping each of the arguments <mo>+</mo> and <mi>y</mi> in its own mphantom element, i.e.

<mfrac>
  <mrow>
    <mi> x </mi>
    <mo> + </mo>
    <mi> y </mi>
    <mo> + </mo>
    <mi> z </mi>
  </mrow>
  <mrow>
    <mi> x </mi>
    <mphantom>
      <mo> + </mo>
    </mphantom>
    <mphantom>
      <mi> y </mi>
    </mphantom>
    <mo> + </mo>
    <mi> z </mi>
  </mrow>
</mfrac>
x + y + z x + y + z

3.3.8 Expression Inside Pair of Fences <mfenced>

3.3.8.1 Description

The mfenced element provides a convenient form in which to express common constructs involving fences (i.e. braces, brackets, and parentheses), possibly including separators (such as comma) between the arguments.

For example, <mfenced> <mi>x</mi> </mfenced> renders as (x) and is equivalent to

<mrow> <mo> ( </mo> <mi>x</mi> <mo> ) </mo> </mrow>
( x )

and <mfenced> <mi>x</mi> <mi>y</mi> </mfenced> renders as (x, y) and is equivalent to

<mrow>
  <mo> ( </mo>
  <mrow> <mi>x</mi> <mo>,</mo> <mi>y</mi> </mrow>
  <mo> ) </mo>
</mrow>
( x , y )

Individual fences or separators are represented using mo elements, as described in 3.2.5 Operator, Fence, Separator or Accent <mo>. Thus, any mfenced element is completely equivalent to an expanded form described below. While mfenced might be more convenient for authors or authoring software, only the expanded form is supported in [MathML-Core]. A renderer that supports this recommendation is required to render either of these forms in exactly the same way.

In general, an mfenced element can contain zero or more arguments, and will enclose them between fences in an mrow; if there is more than one argument, it will insert separators between adjacent arguments, using an additional nested mrow around the arguments and separators for proper grouping (3.3.1 Horizontally Group Sub-Expressions <mrow>). The general expanded form is shown below. The fences and separators will be parentheses and comma by default, but can be changed using attributes, as shown in the following table.

3.3.8.2 Attributes

mfenced elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements. The delimiters and separators should be drawn using the color specified by mathcolor.

Name values default
open string (
Specifies the opening delimiter. Since it is used as the content of an mo element, any whitespace will be trimmed and collapsed as described in 2.1.7 Collapsing Whitespace in Input.
close string )
Specifies the closing delimiter. Since it is used as the content of an mo element, any whitespace will be trimmed and collapsed as described in 2.1.7 Collapsing Whitespace in Input.
separators string ,
Specifies a sequence of zero or more separator characters, optionally separated by whitespace. Each pair of arguments is displayed separated by the corresponding separator (none appears after the last argument). If there are too many separators, the excess are ignored; if there are too few, the last separator is repeated. Any whitespace within separators is ignored.

A generic mfenced element, with all attributes explicit, looks as follows:

<mfenced open="opening-fence"
         close="closing-fence"
         separators="sep#1 sep#2 ... sep#(n-1)" >
  arg#1
  ...
  arg#n
</mfenced>

In an RTL directionality context, since the initial text direction is RTL, characters in the open and close attributes that have a mirroring counterpart will be rendered in that mirrored form. In particular, the default values will render correctly as a parenthesized sequence in both LTR and RTL contexts.

The general mfenced element shown above is equivalent to the following expanded form:

<mrow>
  <mo fence="true"> opening-fence </mo>
  <mrow>
    arg#1
    <mo separator="true"> sep#1 </mo>
    ...
    <mo separator="true"> sep#(n-1) </mo>
    arg#n
  </mrow>
  <mo fence="true"> closing-fence </mo>
</mrow>

Each argument except the last is followed by a separator. The inner mrow is added for proper grouping, as described in 3.3.1 Horizontally Group Sub-Expressions <mrow>.

When there is only one argument, the above form has no separators; since <mrow> arg#1 </mrow> is equivalent to arg#1 (as described in 3.3.1 Horizontally Group Sub-Expressions <mrow>), this case is also equivalent to:

<mrow>
  <mo fence="true"> opening-fence </mo>
    arg#1
  <mo fence="true"> closing-fence </mo>
</mrow>

If there are too many separator characters, the extra ones are ignored. If separator characters are given, but there are too few, the last one is repeated as necessary. Thus, the default value of separators="," is equivalent to separators=",,", separators=",,,", etc. If there are no separator characters provided but some are needed, for example if separators=" " or "" and there is more than one argument, then no separator elements are inserted at all — that is, the elements <mo separator="true"> sep#i </mo> are left out entirely. Note that this is different from inserting separators consisting of mo elements with empty content.

Finally, for the case with no arguments, i.e.

<mfenced open="opening-fence"
 close="closing-fence"
 separators="anything" >
</mfenced>

the equivalent expanded form is defined to include just the fences within an mrow:

<mrow>
  <mo fence="true"> opening-fence </mo>
  <mo fence="true"> closing-fence </mo>
</mrow>

Note that not all fenced expressions can be encoded by an mfenced element. Such exceptional expressions include those with an embellished separator or fence or one enclosed in an mstyle element, a missing or extra separator or fence, or a separator with multiple content characters. In these cases, it is necessary to encode the expression using an appropriately modified version of an expanded form. As discussed above, it is always permissible to use the expanded form directly, even when it is not necessary. In particular, authors cannot be guaranteed that MathML preprocessors won't replace occurrences of mfenced with equivalent expanded forms.

Note that the equivalent expanded forms shown above include attributes on the mo elements that identify them as fences or separators. Since the most common choices of fences and separators already occur in the operator dictionary with those attributes, authors would not normally need to specify those attributes explicitly when using the expanded form directly. Also, the rules for the default form attribute (3.2.5 Operator, Fence, Separator or Accent <mo>) cause the opening and closing fences to be effectively given the values form="prefix" and form="postfix" respectively, and the separators to be given the value form="infix".

Note that it would be incorrect to use mfenced with a separator of, for instance, +, as an abbreviation for an expression using + as an ordinary operator, e.g.

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

This is because the + signs would be treated as separators, not infix operators. That is, it would render as if they were marked up as <mo separator="true">+</mo>, which might therefore render inappropriately.

3.3.8.3 Examples
<mfenced>
  <mrow>
    <mi> a </mi>
    <mo> + </mo>
    <mi> b </mi>
  </mrow>
</mfenced>

Note that the above mrow is necessary so that the mfenced has just one argument. Without it, this would render incorrectly as (a, +, b).

<mfenced open="[">
  <mn> 0 </mn>
  <mn> 1 </mn>
</mfenced>
<mrow>
  <mi> f </mi>
  <mo> &#x2061;<!--ApplyFunction--> </mo>
  <mfenced>
    <mi> x </mi>
    <mi> y </mi>
  </mfenced>
</mrow>

3.3.9 Enclose Expression Inside Notation <menclose>

3.3.9.1 Description

The menclose element renders its content inside the enclosing notation specified by its notation attribute. menclose accepts a single argument possibly being an inferred mrow of multiple children; see 3.1.3 Required Arguments.

3.3.9.2 Attributes

menclose elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements. The notations should be drawn using the color specified by mathcolor.

The values allowed for notation are open-ended. Conforming renderers may ignore any value they do not handle, although renderers are encouraged to render as many of the values listed below as possible.

Name values default
notation (actuarial | phasorangle | box | roundedbox | circle | left | right | top | bottom | updiagonalstrike | downdiagonalstrike | verticalstrike | horizontalstrike | northeastarrow | madruwb | text ) + do nothing
Specifies a space separated list of notations to be used to enclose the children. See below for a description of each type of notation. MathML 4 deprecates the use of longdiv and radical. These notations duplicate functionality provided by mlongdiv and msqrt respectively; those elements should be used instead. The default has been changed so that if no notation is given, or if it is an empty string, then menclose should not draw.

Any number of values can be given for notation separated by whitespace; all of those given and understood by a MathML renderer should be rendered. Each should be rendered as if the others were not present; they should not nest one inside of the other. For example, notation="circle box" should result in circle and a box around the contents of menclose; the circle and box may overlap. This is shown in the first example below. Of the predefined notations, only phasorangle is affected by the directionality (see 3.1.5.1 Overall Directionality of Mathematics Formulas):

When notation is specified as actuarial, the contents are drawn enclosed by an actuarial symbol. A similar result can be achieved with the value top right.

The values box, roundedbox, and circle should enclose the contents as indicated by the values. The amount of distance between the box, roundedbox, or circle, and the contents are not specified by MathML, and left to the renderer. In practice, paddings on each side of 0.4em in the horizontal direction and .5ex in the vertical direction seem to work well.

The values left, right, top and bottom should result in lines drawn on those sides of the contents. The values northeastarrow, updiagonalstrike, downdiagonalstrike, verticalstrike and horizontalstrike should result in the indicated strikeout lines being superimposed over the content of the menclose, e.g. a strikeout that extends from the lower left corner to the upper right corner of the menclose element for updiagonalstrike, etc.

The value northeastarrow is a recommended value to implement because it can be used to implement TeX's \cancelto command. If a renderer implements other arrows for menclose, it is recommended that the arrow names are chosen from the following full set of names for consistency and standardization among renderers:

  • uparrow

  • rightarrow

  • downarrow

  • leftarrow

  • northwestarrow

  • southwestarrow

  • southeastarrow

  • northeastarrow

  • updownarrow

  • leftrightarrow

  • northwestsoutheastarrow

  • northeastsouthwestarrow

The value madruwb should generate an enclosure representing an Arabic factorial (‘madruwb’ is the transliteration of the Arabic مضروب for factorial). This is shown in the third example below.

The baseline of an menclose element is the baseline of its child (which might be an implied mrow).

3.3.9.3 Examples

An example of using multiple attributes is

<menclose notation='circle box'>
  <mi> x </mi><mo> + </mo><mi> y </mi>
</menclose>
[Image of a circle and box around x plus y]

An example of using menclose for actuarial notation is

<msub>
  <mi>a</mi>
  <mrow>
    <menclose notation='actuarial'>
      <mi>n</mi>
    </menclose>
    <mo>&#x2063;<!--InvisibleComma--></mo>
    <mi>i</mi>
  </mrow>
</msub>
[image of actuarial notation for a angle n at i]

An example of phasorangle, which is used in circuit analysis, is:

<mi>C</mi>
<mrow>
  <menclose notation='phasorangle'>
    <mrow>
      <mo></mo>
      <mfrac>
        <mi>π</mi>
        <mn>2</mn>
      </mfrac>
    </mrow>
  </menclose>
</mrow>
[image of phasorangle notation for the angle negative pi over 2]

An example of madruwb is:

<menclose notation="madruwb">
  <mn>12</mn>
</menclose>
[Image of 12 factorial in Arabic style]

3.4 Script and Limit Schemata

The elements described in this section position one or more scripts around a base. Attaching various kinds of scripts and embellishments to symbols is a very common notational device in mathematics. For purely visual layout, a single general-purpose element could suffice for positioning scripts and embellishments in any of the traditional script locations around a given base. However, in order to capture the abstract structure of common notation better, MathML provides several more specialized scripting elements.

In addition to sub-/superscript elements, MathML has overscript and underscript elements that place scripts above and below the base. These elements can be used to place limits on large operators, or for placing accents and lines above or below the base. The rules for rendering accents differ from those for overscripts and underscripts, and this difference can be controlled with the accent and accentunder attributes, as described in the appropriate sections below.

Rendering of scripts is affected by the scriptlevel and displaystyle attributes, which are part of the environment inherited by the rendering process of every MathML expression, and are described in 3.1.6 Displaystyle and Scriptlevel. These attributes cannot be given explicitly on a scripting element, but can be specified on the start tag of a surrounding mstyle element if desired.

MathML also provides an element for attachment of tensor indices. Tensor indices are distinct from ordinary subscripts and superscripts in that they must align in vertical columns. Also, all the upper scripts should be baseline-aligned and all the lower scripts should be baseline-aligned. Tensor indices can also occur in prescript positions. Note that ordinary scripts follow the base (on the right in LTR context, but on the left in RTL context); prescripts precede the base (on the left (right) in LTR (RTL) context).

Because presentation elements should be used to describe the abstract notational structure of expressions, it is important that the base expression in all scripting elements (i.e. the first argument expression) should be the entire expression that is being scripted, not just the trailing character. For example, (x+y)2 should be written as:

<msup>
  <mrow>
    <mo> ( </mo>
    <mrow>
      <mi> x </mi>
      <mo> + </mo>
      <mi> y </mi>
    </mrow>
    <mo> ) </mo>
  </mrow>
  <mn> 2 </mn>
</msup>
( x + y ) 2

3.4.1 Subscript <msub>

3.4.1.1 Description

The msub element attaches a subscript to a base using the syntax

<msub> base subscript </msub>

It increments scriptlevel by 1, and sets displaystyle to false, within subscript, but leaves both attributes unchanged within base. (See 3.1.6 Displaystyle and Scriptlevel.)

3.4.1.2 Attributes

msub elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements.

Name values default
subscriptshift length automatic
Specifies the minimum amount to shift the baseline of subscript down; the default is for the rendering agent to use its own positioning rules.

3.4.2 Superscript <msup>

3.4.2.1 Description

The msup element attaches a superscript to a base using the syntax

<msup> base superscript </msup>

It increments scriptlevel by 1, and sets displaystyle to false, within superscript, but leaves both attributes unchanged within base. (See 3.1.6 Displaystyle and Scriptlevel.)

3.4.2.2 Attributes

msup elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements.

Name values default
superscriptshift length automatic
Specifies the minimum amount to shift the baseline of superscript up; the default is for the rendering agent to use its own positioning rules.

3.4.3 Subscript-superscript Pair <msubsup>

3.4.3.1 Description

The msubsup element is used to attach both a subscript and superscript to a base expression.

<msubsup> base subscript superscript </msubsup>

It increments scriptlevel by 1, and sets displaystyle to false, within subscript and superscript, but leaves both attributes unchanged within base. (See 3.1.6 Displaystyle and Scriptlevel.)

Note that both scripts are positioned tight against the base as shown here x12 versus the staggered positioning of nested scripts as shown here x12; the latter can be achieved by nesting an msub inside an msup.

3.4.3.2 Attributes

msubsup elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements.

Name values default
subscriptshift length automatic
Specifies the minimum amount to shift the baseline of subscript down; the default is for the rendering agent to use its own positioning rules.
superscriptshift length automatic
Specifies the minimum amount to shift the baseline of superscript up; the default is for the rendering agent to use its own positioning rules.
3.4.3.3 Examples

The msubsup is most commonly used for adding sub-/superscript pairs to identifiers as illustrated above. However, another important use is placing limits on certain large operators whose limits are traditionally displayed in the script positions even when rendered in display style. The most common of these is the integral. For example,

\int\nolimits_0^1 \eulere^x \,\diffd x

would be represented as

<mrow>
  <msubsup>
    <mo></mo>
    <mn> 0 </mn>
    <mn> 1 </mn>
  </msubsup>
  <mrow>
    <msup>
      <mi></mi>
      <mi> x </mi>
    </msup>
    <mo> &#x2062;<!--InvisibleTimes--> </mo>
    <mrow>
      <mo></mo>
      <mi> x </mi>
    </mrow>
  </mrow>
</mrow>
0 1 x x

3.4.4 Underscript <munder>

3.4.4.1 Description

The munder element attaches an accent or limit placed under a base using the syntax

<munder> base underscript </munder>

It always sets displaystyle to false within the underscript, but increments scriptlevel by 1 only when accentunder is false. Within base, it always leaves both attributes unchanged. (See 3.1.6 Displaystyle and Scriptlevel.)

If base is an operator with movablelimits=true (or an embellished operator whose mo element core has movablelimits=true), and displaystyle=false, then underscript is drawn in a subscript position. In this case, the accentunder attribute is ignored. This is often used for limits on symbols such as U+2211 (entity sum).

3.4.4.2 Attributes

munder elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements.

Name values default
accentunder "true" | "false" automatic
Specifies whether underscript is drawn as an accent or as a limit. An accent is drawn the same size as the base (without incrementing scriptlevel) and is drawn closer to the base.
align "left" | "right" | "center" center
Specifies whether the script is aligned left, center, or right under/over the base. As specified in 3.2.5.7.3 Horizontal Stretching Rules, the core of underscripts that are embellished operators should stretch to cover the base, but the alignment is based on the entire underscript.

The default value of accentunder is false, unless underscript is an mo element or an embellished operator (see 3.2.5 Operator, Fence, Separator or Accent <mo>). If underscript is an mo element, the value of its accent attribute is used as the default value of accentunder. If underscript is an embellished operator, the accent attribute of the mo element at its core is used as the default value. As with all attributes, an explicitly given value overrides the default.

[MathML-Core] does not support the accent attribute on 3.2.5 Operator, Fence, Separator or Accent <mo>. For compatibility with MathML Core, the accentunder should be set on munder.

3.4.4.3 Examples

An example demonstrating how accentunder affects rendering:

<mrow>
  <munder accentunder="true">
    <mrow>
      <mi> x </mi>
      <mo> + </mo>
      <mi> y </mi>
      <mo> + </mo>
      <mi> z </mi>
    </mrow>
    <mo></mo>
  </munder>
  <mtext>&#x00A0;<!--nbsp-->versus&#x00A0;<!--nbsp--></mtext>
  <munder accentunder="false">
    <mrow>
      <mi> x </mi>
      <mo> + </mo>
      <mi> y </mi>
      <mo> + </mo>
      <mi> z </mi>
    </mrow>
    <mo></mo>
  </munder>
</mrow>
x + y + z  versus  x + y + z

3.4.5 Overscript <mover>

3.4.5.1 Description

The mover element attaches an accent or limit placed over a base using the syntax

<mover> base overscript </mover>

It always sets displaystyle to false within overscript, but increments scriptlevel by 1 only when accent is false. Within base, it always leaves both attributes unchanged. (See 3.1.6 Displaystyle and Scriptlevel.)

If base is an operator with movablelimits=true (or an embellished operator whose mo element core has movablelimits=true), and displaystyle=false, then overscript is drawn in a superscript position. In this case, the accent attribute is ignored. This is often used for limits on symbols such as U+2211 (entity sum).

3.4.5.2 Attributes

mover elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements.

Name values default
accent "true" | "false" automatic
Specifies whether overscript is drawn as an accent or as a limit. An accent is drawn the same size as the base (without incrementing scriptlevel) and is drawn closer to the base.
align "left" | "right" | "center" center
Specifies whether the script is aligned left, center, or right under/over the base. As specified in 3.2.5.7.3 Horizontal Stretching Rules, the core of overscripts that are embellished operators should stretch to cover the base, but the alignment is based on the entire overscript.

The difference between an accent versus limit is shown in the examples.

The default value of accent is false, unless overscript is an mo element or an embellished operator (see 3.2.5 Operator, Fence, Separator or Accent <mo>). If overscript is an mo element, the value of its accent attribute is used as the default value of accent for mover. If overscript is an embellished operator, the accent attribute of the mo element at its core is used as the default value.

[MathML-Core] does not support the accent attribute on 3.2.5 Operator, Fence, Separator or Accent <mo>. For compatibility with MathML Core, the accentunder should be set on munder.

3.4.5.3 Examples

Two examples demonstrating how accent affects rendering:

<mrow>
  <mover accent="true">
    <mi> x </mi>
    <mo> ^ </mo>
  </mover>
  <mtext>&#x00A0;<!--nbsp-->versus&#x00A0;<!--nbsp--></mtext>
  <mover accent="false">
    <mi> x </mi>
    <mo> ^ </mo>
  </mover>
</mrow>
x ^  versus  x ^
<mrow>
  <mover accent="true">
    <mrow>
      <mi> x </mi>
      <mo> + </mo>
      <mi> y </mi>
      <mo> + </mo>
      <mi> z </mi>
    </mrow>
    <mo></mo>
  </mover>
  <mtext>&#x00A0;<!--nbsp-->versus&#x00A0;<!--nbsp--></mtext>
  <mover accent="false">
    <mrow>
      <mi> x </mi>
      <mo> + </mo>
      <mi> y </mi>
      <mo> + </mo>
      <mi> z </mi>
    </mrow>
    <mo></mo>
  </mover>
</mrow>
x + y + z  versus  x + y + z

3.4.6 Underscript-overscript Pair <munderover>

3.4.6.1 Description

The munderover element attaches accents or limits placed both over and under a base using the syntax

<munderover> base underscript overscript </munderover>

It always sets displaystyle to false within underscript and overscript, but increments scriptlevel by 1 only when accentunder or accent, respectively, are false. Within base, it always leaves both attributes unchanged. (see 3.1.6 Displaystyle and Scriptlevel).

If base is an operator with movablelimits=true (or an embellished operator whose mo element core has movablelimits=true), and displaystyle=false, then underscript and overscript are drawn in a subscript and superscript position, respectively. In this case, the accentunder and accent attributes are ignored. This is often used for limits on symbols such as U+2211 (entity sum).

3.4.6.2 Attributes

munderover elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements.

Name values default
accent "true" | "false" automatic
Specifies whether overscript is drawn as an accent or as a limit. An accent is drawn the same size as the base (without incrementing scriptlevel) and is drawn closer to the base.
accentunder "true" | "false" automatic
Specifies whether underscript is drawn as an accent or as a limit. An accent is drawn the same size as the base (without incrementing scriptlevel) and is drawn closer to the base.
align "left" | "right" | "center" center
Specifies whether the scripts are aligned left, center, or right under/over the base. As specified in 3.2.5.7.3 Horizontal Stretching Rules, the core of underscripts and overscripts that are embellished operators should stretch to cover the base, but the alignment is based on the entire underscript or overscript.

The munderover element is used instead of separate munder and mover elements so that the underscript and overscript are vertically spaced equally in relation to the base and so that they follow the slant of the base as shown in the example.

The defaults for accent and accentunder are computed in the same way as for munder and mover, respectively.

3.4.6.3 Examples

This example shows the difference between nesting munder inside mover and using munderover when movablelimits=true and in displaystyle (which renders the same as msubsup).

<mstyle displaystyle="false">
  <mover>
    <munder>
      <mo></mo>
      <mi>i</mi>
    </munder>
    <mi>n</mi>
  </mover>
  <mo>+</mo>
  <munderover>
    <mo></mo>
    <mi>i</mi>
    <mi>n</mi>
  </munderover>
</mstyle>
i n + i n

3.4.7 Prescripts and Tensor Indices <mmultiscripts>, <mprescripts/>, <none/> <munder>

3.4.7.1 Description

Presubscripts and tensor notations are represented by a single element, mmultiscripts, using the syntax:

<mmultiscripts>
 base
 (subscript superscript)*
 [ <mprescripts/> (presubscript presuperscript)* ]
</mmultiscripts>

This element allows the representation of any number of vertically-aligned pairs of subscripts and superscripts, attached to one base expression. It supports both postscripts and prescripts. Missing scripts must be represented by the empty element none. All of the upper scripts should be baseline-aligned and all the lower scripts should be baseline-aligned.

The prescripts are optional, and when present are given after the postscripts. This order was chosen because prescripts are relatively rare compared to tensor notation.

The argument sequence consists of the base followed by zero or more pairs of vertically-aligned subscripts and superscripts (in that order) that represent all of the postscripts. This list is optionally followed by an empty element mprescripts and a list of zero or more pairs of vertically-aligned presubscripts and presuperscripts that represent all of the prescripts. The pair lists for postscripts and prescripts are displayed in the same order as the directional context (i.e. left-to-right order in LTR context). If no subscript or superscript should be rendered in a given position, then the empty element none should be used in that position. For each sub- and superscript pair, horizontal-alignment of the elements in the pair should be towards the base of the mmultiscripts. That is, pre-scripts should be right aligned, and post-scripts should be left aligned.

The base, subscripts, superscripts, the optional separator element mprescripts, the presubscripts, and the presuperscripts are all direct sub-expressions of the mmultiscripts element, i.e. they are all at the same level of the expression tree. Whether a script argument is a subscript or a superscript, or whether it is a presubscript or a presuperscript is determined by whether it occurs in an even-numbered or odd-numbered argument position, respectively, ignoring the empty element mprescripts itself when determining the position. The first argument, the base, is considered to be in position 1. The total number of arguments must be odd, if mprescripts is not given, or even, if it is.

The empty element mprescripts is only allowed as direct sub-expression of mmultiscripts.

3.4.7.2 Attributes

Same as the attributes of msubsup. See 3.4.3.2 Attributes.

The mmultiscripts element increments scriptlevel by 1, and sets displaystyle to false, within each of its arguments except base, but leaves both attributes unchanged within base. (See 3.1.6 Displaystyle and Scriptlevel.)

3.4.7.3 Examples

This example of a hypergeometric function demonstrates the use of pre and post subscripts:

<mrow>
  <mmultiscripts>
    <mi> F </mi>
    <mn> 1 </mn>
    <none/>
    <mprescripts/>
    <mn> 0 </mn>
    <none/>
  </mmultiscripts>
  <mo> &#x2061;<!--ApplyFunction--> </mo>
  <mrow>
    <mo> ( </mo>
    <mrow>
      <mo> ; </mo>
      <mi> a </mi>
      <mo> ; </mo>
      <mi> z </mi>
    </mrow>
    <mo> ) </mo>
  </mrow>
</mrow>
F 1 0 ( ; a ; z )

This example shows a tensor. In the example, k and l are different indices

<mmultiscripts>
  <mi> R </mi>
  <mi> i </mi>
  <none/>
  <none/>
  <mi> j </mi>
  <mi> k </mi>
  <none/>
  <mi> l </mi>
  <none/>
</mmultiscripts>
R i j k l

This example demonstrates alignment towards the base of the scripts:

<mmultiscripts>
  <mi>  X </mi>
  <mn> 123 </mn>
  <mn> 1 </mn>
  <mprescripts/>
  <mn> 123 </mn>
  <mn> 1 </mn>
</mmultiscripts>
X 123 1 123 1

This final example of mmultiscripts shows how the binomial coefficient can be displayed in Arabic style

<mstyle dir="rtl">
  <mmultiscripts><mo>&#x0644;</mo>
    <mn>12</mn><none/>
    <mprescripts/>
    <none/><mn>5</mn>
  </mmultiscripts>
</mstyle>
ل 12 5

3.5 Tabular Math

Matrices, arrays and other table-like mathematical notation are marked up using mtable, mtr, mlabeledtr and mtd elements. These elements are similar to the table, tr and td elements of HTML, except that they provide specialized attributes for the fine layout control necessary for commutative diagrams, block matrices and so on.

While the two-dimensional layouts used for elementary math such as addition and multiplication are somewhat similar to tables, they differ in important ways. For layout and for accessibility reasons, the mstack and mlongdiv elements discussed in 3.6 Elementary Math should be used for elementary math notations.

In addition to the table elements mentioned above, the mlabeledtr element is used for labeling rows of a table. This is useful for numbered equations. The first child of mlabeledtr is the label. A label is somewhat special in that it is not considered an expression in the matrix and is not counted when determining the number of columns in that row.

3.5.1 Table or Matrix <mtable>

3.5.1.1 Description

A matrix or table is specified using the mtable element. Inside of the mtable element, only mtr or mlabeledtr elements may appear.

Table rows that have fewer columns than other rows of the same table (whether the other rows precede or follow them) are effectively padded on the right (or left in RTL context) with empty mtd elements so that the number of columns in each row equals the maximum number of columns in any row of the table. Note that the use of mtd elements with non-default values of the rowspan or columnspan attributes may affect the number of mtd elements that should be given in subsequent mtr elements to cover a given number of columns. Note also that the label in an mlabeledtr element is not considered a column in the table.

MathML does not specify a table layout algorithm. In particular, it is the responsibility of a MathML renderer to resolve conflicts between the width attribute and other constraints on the width of a table, such as explicit values for columnwidth attributes, and minimum sizes for table cell contents. For a discussion of table layout algorithms, see Cascading Style Sheets, level 2.

3.5.1.2 Attributes

mtable elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements. Any rules drawn as part of the mtable should be drawn using the color specified by mathcolor.

Name values default
align ("top" | "bottom" | "center" | "baseline" | "axis"), rownumber? axis
specifies the vertical alignment of the table with respect to its environment. axis means to align the vertical center of the table on the environment's axis. (The axis of an equation is an alignment line used by typesetters. It is the line on which a minus sign typically lies.) center and baseline both mean to align the center of the table on the environment's baseline. top or bottom aligns the top or bottom of the table on the environment's baseline. If the align attribute value ends with a rownumber, the specified row (counting from 1 for the top row), rather than the table as a whole, is aligned in the way described above with the exceptions noted below. If rownumber is negative, it counts rows from the bottom. When the value of rownumber is out of range or not an integer, it is ignored. If a row number is specified and the alignment value is baseline or axis, the row's baseline or axis is used for alignment. Note this is only well defined when the rowalign value is baseline or axis; MathML does not specify how baseline or axis alignment should occur for other values of rowalign.
rowalign ("top" | "bottom" | "center" | "baseline" | "axis") + baseline
specifies the vertical alignment of the cells with respect to other cells within the same row: top aligns the tops of each entry across the row; bottom aligns the bottoms of the cells, center centers the cells; baseline aligns the baselines of the cells; axis aligns the axis of each cells. (See the note below about multiple values.)
columnalign ("left" | "center" | "right") + center
specifies the horizontal alignment of the cells with respect to other cells within the same column: left aligns the left side of the cells; center centers each cells; right aligns the right side of the cells. (See the note below about multiple values.)
alignmentscope ("true" | "false") + true
[this attribute is described with the alignment elements, maligngroup and malignmark, in 3.5.5 Alignment Markers <maligngroup/>, <malignmark/>.]
columnwidth ("auto" | length | "fit") + auto
specifies how wide a column should be: auto means that the column should be as wide as needed; an explicit length means that the column is exactly that wide and the contents of that column are made to fit by linewrapping or clipping at the discretion of the renderer; fit means that the page width remaining after subtracting the auto or fixed width columns is divided equally among the fit columns. If insufficient room remains to hold the contents of the fit columns, renderers may linewrap or clip the contents of the fit columns. Note that when the columnwidth is specified as a percentage, the value is relative to the width of the table, not as a percentage of the default (which is auto). That is, a renderer should try to adjust the width of the column so that it covers the specified percentage of the entire table width. (See the note below about multiple values.)
width "auto" | length auto
specifies the desired width of the entire table and is intended for visual user agents. When the value is a percentage value, the value is relative to the horizontal space that a MathML renderer has available, this is the current target width as used for linebreaking as specified in 3.1.7 Linebreaking of Expressions; this allows the author to specify, for example, a table being full width of the display. When the value is auto, the MathML renderer should calculate the table width from its contents using whatever layout algorithm it chooses. Note: numbers without units were allowed in MathML 3 and treated similarly to percentage values, but unitless numbers are deprecated in MathML 4.
rowspacing (length) + 1.0ex
specifies how much space to add between rows. (See the note below about multiple values.)
columnspacing (length) + 0.8em
specifies how much space to add between columns. (See the note below about multiple values.)
rowlines ("none" | "solid" | "dashed") + none
specifies whether and what kind of lines should be added between each row: none means no lines; solid means solid lines; dashed means dashed lines (how the dashes are spaced is implementation dependent). (See the note below about multiple values.)
columnlines ("none" | "solid" | "dashed") + none
specifies whether and what kind of lines should be added between each column: none means no lines; solid means solid lines; dashed means dashed lines (how the dashes are spaced is implementation dependent). (See the note below about multiple values.)
frame "none" | "solid" | "dashed" none
specifies whether and what kind of lines should be drawn around the table. none means no lines; solid means solid lines; dashed means dashed lines (how the dashes are spaced is implementation dependent).
framespacing length, length 0.4em 0.5ex
specifies the additional spacing added between the table and frame, if frame is not none. The first value specifies the spacing on the right and left; the second value specifies the spacing above and below.
equalrows "true" | "false" false
specifies whether to force all rows to have the same total height.
equalcolumns "true" | "false" false
specifies whether to force all columns to have the same total width.
displaystyle "true" | "false" false
specifies the value of displaystyle within each cell (scriptlevel is not changed); see 3.1.6 Displaystyle and Scriptlevel.
side "left" | "right" | "leftoverlap" | "rightoverlap" right
specifies on what side of the table labels from enclosed mlabeledtr (if any) should be placed. The variants leftoverlap and rightoverlap are useful when the table fits with the allowed width when the labels are omitted, but not when they are included: in such cases, the labels will overlap the row placed above it if the rowalign for that row is top, otherwise it is placed below it.
minlabelspacing length 0.8em
specifies the minimum space allowed between a label and the adjacent cell in the row.

In the above specifications for attributes affecting rows (respectively, columns, or the gaps between rows or columns), the notation (...)+ means that multiple values can be given for the attribute as a space separated list (see 2.1.5 MathML Attribute Values). In this context, a single value specifies the value to be used for all rows (resp., columns or gaps). A list of values are taken to apply to corresponding rows (resp., columns or gaps) in order, that is starting from the top row for rows or first column (left or right, depending on directionality) for columns. If there are more rows (resp., columns or gaps) than supplied values, the last value is repeated as needed. If there are too many values supplied, the excess are ignored.

Note that none of the areas occupied by lines frame, rowlines and columnlines, nor the spacing framespacing, rowspacing or columnspacing, nor the label in mlabeledtr are counted as rows or columns.

The displaystyle attribute is allowed on the mtable element to set the inherited value of the attribute. If the attribute is not present, the mtable element sets displaystyle to false within the table elements. (See 3.1.6 Displaystyle and Scriptlevel.)

3.5.1.3 Examples

A 3 by 3 identity matrix could be represented as follows:

<mrow>
  <mo> ( </mo>
  <mtable>
    <mtr>
      <mtd> <mn>1</mn> </mtd>
      <mtd> <mn>0</mn> </mtd>
      <mtd> <mn>0</mn> </mtd>
    </mtr>
    <mtr>
      <mtd> <mn>0</mn> </mtd>
      <mtd> <mn>1</mn> </mtd>
      <mtd> <mn>0</mn> </mtd>
    </mtr>
    <mtr>
      <mtd> <mn>0</mn> </mtd>
      <mtd> <mn>0</mn> </mtd>
      <mtd> <mn>1</mn> </mtd>
    </mtr>
  </mtable>
  <mo> ) </mo>
</mrow>
( 1 0 0 0 1 0 0 0 1 )

Note that the parentheses must be represented explicitly; they are not part of the mtable element's rendering. This allows use of other surrounding fences, such as brackets, or none at all.

3.5.2 Row in Table or Matrix <mtr>

3.5.2.1 Description

An mtr element represents one row in a table or matrix. An mtr element is only allowed as a direct sub-expression of an mtable element, and specifies that its contents should form one row of the table. Each argument of mtr is placed in a different column of the table, starting at the leftmost column in a LTR context or rightmost column in a RTL context.

As described in 3.5.1 Table or Matrix <mtable>, mtr elements are effectively padded with mtd elements when they are shorter than other rows in a table.

3.5.2.2 Attributes

mtr elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements.

Name values default
rowalign "top" | "bottom" | "center" | "baseline" | "axis" inherited
overrides, for this row, the vertical alignment of cells specified by the rowalign attribute on the mtable.
columnalign ("left" | "center" | "right") + inherited
overrides, for this row, the horizontal alignment of cells specified by the columnalign attribute on the mtable.

3.5.3 Labeled Row in Table or Matrix <mlabeledtr>

3.5.3.1 Description

An mlabeledtr element represents one row in a table that has a label on either the left or right side, as determined by the side attribute. The label is the first child of mlabeledtr, and should be enclosed in an mtd. The rest of the children represent the contents of the row and are treated identically to the children of mtr; consequently all of the children must be mtd elements.

An mlabeledtr element is only allowed as a direct sub-expression of an mtable element. Each argument of mlabeledtr except for the first argument (the label) is placed in a different column of the table, starting at the leftmost column.

Note that the label element is not considered to be a cell in the table row. In particular, the label element is not taken into consideration in the table layout for purposes of width and alignment calculations. For example, in the case of an mlabeledtr with a label and a single centered mtd child, the child is first centered in the enclosing mtable, and then the label is placed. Specifically, the child is not centered in the space that remains in the table after placing the label.

While MathML does not specify an algorithm for placing labels, implementers of visual renderers may find the following formatting model useful. To place a label, an implementor might think in terms of creating a larger table, with an extra column on both ends. The columnwidth attributes of both these border columns would be set to fit so that they expand to fill whatever space remains after the inner columns have been laid out. Finally, depending on the values of side and minlabelspacing, the label is placed in whatever border column is appropriate, possibly shifted down if necessary, and aligned according to columnalignment.

3.5.3.2 Attributes

The attributes for mlabeledtr are the same as for mtr. Unlike the attributes for the mtable element, attributes of mlabeledtr that apply to column elements also apply to the label. For example, in a one column table,

<mlabeledtr rowalign='top'>

means that the label and other entries in the row are vertically aligned along their top. To force a particular alignment on the label, the appropriate attribute would normally be set on the mtd element that surrounds the label content.

3.5.3.3 Equation Numbering

One of the important uses of mlabeledtr is for numbered equations. In an mlabeledtr, the label represents the equation number and the elements in the row are the equation being numbered. The side and minlabelspacing attributes of mtable determine the placement of the equation number.

In larger documents with many numbered equations, automatic numbering becomes important. While automatic equation numbering and automatically resolving references to equation numbers is outside the scope of MathML, these problems can be addressed by the use of style sheets or other means. The mlabeledtr construction provides support for both of these functions in a way that is intended to facilitate XSLT processing. The mlabeledtr element can be used to indicate the presence of a numbered equation, and the first child can be changed to the current equation number, along with incrementing the global equation number. For cross references, an id on either the mlabeledtr element or on the first element itself could be used as a target of any link. Alternatively, in a CSS context, one could use an empty mtd as the first child of mlabeledtr and use CSS counters and generated content to fill in the equation number using a CSS style such as

body {counter-reset: eqnum;}
mtd.eqnum {counter-increment: eqnum;}
mtd.eqnum:before {content: "(" counter(eqnum) ")"}
3.5.3.4 Example
<mtable>
  <mlabeledtr id='e-is-m-c-square'>
    <mtd>
      <mtext> (2.1) </mtext>
    </mtd>
    <mtd>
      <mrow>
        <mi>E</mi>
        <mo>=</mo>
        <mrow>
          <mi>m</mi>
          <mo>&#x2062;<!--InvisibleTimes--></mo>
          <msup>
            <mi>c</mi>
            <mn>2</mn>
          </msup>
        </mrow>
      </mrow>
    </mtd>
  </mlabeledtr>
</mtable>
mlabeledtr example

3.5.4 Entry in Table or Matrix <mtd>

3.5.4.1 Description

An mtd element represents one entry, or cell, in a table or matrix. An mtd element is only allowed as a direct sub-expression of an mtr or an mlabeledtr element.

The mtd element accepts a single argument possibly being an inferred mrow of multiple children; see 3.1.3 Required Arguments.

3.5.4.2 Attributes

mtd elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements.

Name values default
rowspan positive-integer 1
causes the cell to be treated as if it occupied the number of rows specified. The corresponding mtd in the following rowspan-1 rows must be omitted. The interpretation corresponds with the similar attributes for HTML tables.
columnspan positive-integer 1
causes the cell to be treated as if it occupied the number of columns specified. The following rowspan-1 mtds must be omitted. The interpretation corresponds with the similar attributes for HTML tables.
rowalign "top" | "bottom" | "center" | "baseline" | "axis" inherited
specifies the vertical alignment of this cell, overriding any value specified on the containing mrow and mtable. See the rowalign attribute of mtable.
columnalign "left" | "center" | "right" inherited
specifies the horizontal alignment of this cell, overriding any value specified on the containing mrow and mtable. See the columnalign attribute of mtable.

The rowspan and columnspan attributes can be used around an mtd element that represents the label in an mlabeledtr element. Also, the label of an mlabeledtr element is not considered to be part of a previous rowspan and columnspan.

3.5.5 Alignment Markers <maligngroup/>, <malignmark/>

3.5.5.1 Removal Notice

With one significant exception, <maligngroup/> and <malignmark/> have had minimal adoption and implementation. The one exception only uses the basics of alignment. Because of this, alignment in MathML is significantly simplified to align with the current usage and make future implementation simplier. In particular, the following simplifications are made:

  • the attributes for <maligngroup/> and <malignmark/> have been removed.
  • The groupalign attribute previously allowed on mtable, mtr, and mtr is removed
  • <malignmark/> used to be allowed anywhere, including inside of token elements; it is now allowed in only the locations that <maligngroup/> is allowed (see below)
3.5.5.2 Description

Alignment markers are space-like elements (see 3.2.7 Space <mspace/>) that can be used to vertically align specified points within a column of MathML expressions by the automatic insertion of the necessary amount of horizontal space between specified sub-expressions.

The discussion that follows will use the example of a set of simultaneous equations that should be rendered with vertical alignment of the coefficients and variables of each term, by inserting spacing somewhat like that shown here:

8.44x + 55.7y = -0
3.14x 50.7y = −1.1

If the example expressions shown above were arranged in a column but not aligned, they would appear as:

8.44x + 55.7y = 0
3.1x 50.7y = −1.1

The expressions whose parts are to be aligned (each equation, in the example above) must be given as the table elements (i.e. as the mtd elements) of one column of an mtable. To avoid confusion, the term table cell rather than table element will be used in the remainder of this section.

All interactions between alignment elements are limited to the mtable column they arise in. That is, every column of a table specified by an mtable element acts as an alignment scope that contains within it all alignment effects arising from its contents. It also excludes any interaction between its own alignment elements and the alignment elements inside any nested alignment scopes it might contain.

If there is only one alignment point, an alternative is to use linebreaking and indentation attributes on mo elements as described in 3.1.7 Linebreaking of Expressions.

An mtable element can be given the attribute alignmentscope=false to cause its columns not to act as alignment scopes. This is discussed further at the end of this section. Otherwise, the discussion in this section assumes that this attribute has its default value of true.

3.5.5.3 Specifying alignment groups

Each part of expression to be aligned should be in an maligngroup. The point of alignment is the left edge (right edge if for RTL) of the element that follows an maligngroup element unless an malignmark element is between maligngroup elements. In that case, the left edge (right edge if for RTL) of the element that follows the malignmark is the point of alignment for that group.

If maligngroup or maligngroup occurs outside of an mtable, they are rendered with zero width.

In the example above, each equation would have one maligngroup element before each coefficient, variable, and operator on the left-hand side, one before the = sign, and one before the constant on the right-hand side because these are the parts that should be aligned.

In general, a table cell containing n maligngroup elements contains n alignment groups, with the ith group consisting of the elements entirely after the ith maligngroup element and before the (i+1)-th; no element within the table cell's content should occur entirely before its first maligngroup element.

Note that the division into alignment groups does not necessarily fit the nested expression structure of the MathML expression containing the groups — that is, it is permissible for one alignment group to consist of the end of one mrow, all of another one, and the beginning of a third one, for example. This can be seen in the MathML markup for the example given at the end of this section.

Although alignment groups need not coincide with the nested expression structure of layout schemata, there are nonetheless restrictions on where maligngroup and malignmark elements are allowed within a table cell. These elements may only be contained within elements (directly or indirectly) of the following types (which are themselves contained in the table cell):

  • an mrow element, including an inferred mrow such as the one formed by a multi-child mtd element, but excluding mrow which contains a change of direction using the dir attribute;

  • an mstyle element , but excluding those which change direction using the dir attribute;

  • an mphantom element;

  • an mfenced element;

  • an maction element, though only its selected sub-expression is checked;

  • a semantics element.

These restrictions are intended to ensure that alignment can be unambiguously specified, while avoiding complexities involving things like overscripts, radical signs and fraction bars. They also ensure that a simple algorithm suffices to accomplish the desired alignment.

For the table cells that are divided into alignment groups, every element in their content must be part of exactly one alignment group, except for the elements from the above list that contain maligngroup elements inside them and the maligngroup elements themselves. This means that, within any table cell containing alignment groups, the first complete element must be an maligngroup element, though this may be preceded by the start tags of other elements. This requirement removes a potential confusion about how to align elements before the first maligngroup element, and makes it easy to identify table cells that are left out of their column's alignment process entirely.

It is not required that the table cells in a column that are divided into alignment groups each contain the same number of groups. If they don't, zero-width alignment groups are effectively added on the right side (or left side, in a RTL context) of each table cell that has fewer groups than other table cells in the same column.

Note

Do we want to tighten this so that all rows have the same number of maligngroup elements?

3.5.5.4 Table cells that are not divided into alignment groups
Note

Do we still want to allow rows without maligngroup as described in this section?

Expressions in a column that are to have no alignment groups should contain no maligngroup elements. Expressions with no alignment groups are aligned using only the columnalign attribute that applies to the table column as a whole. If such an expression is wider than the column width needed for the table cells containing alignment groups, all the table cells containing alignment groups will be shifted as a unit within the column as described by the columnalign attribute for that column. For example, a column heading with no internal alignment could be added to the column of two equations given above by preceding them with another table row containing an mtext element for the heading, and using the default columnalign="center" for the table, to produce:

equations with aligned variables
      8.44x + 55.7y = -0      
3.14x 50.7y = −1.1

or, with a shorter heading,

some equations
8.44x + 55.7y = -0
3.14x 50.7y = −1.1
3.5.5.5 Specifying alignment points using <malignmark/>

An malignmark element anywhere within the alignment group (except within another alignment scope wholly contained inside it) overrides alignment at the start of an maligngroup element.

The malignmark element indicates that the alignment point should occur on the left edge (right edge in a RTL context) of the following element.

Note

Can malignmark elements occur inside of tokens?

When an malignmark element is provided within an alignment group, it should only occur within the elements allowed for maligngroup (see 3.5.5.3 Specifying alignment groups). If there is more than one malignmark element in an alignment group, all but the first one will be ignored. MathML applications may wish to provide a mode in which they will warn about this situation, but it is not an error, and should trigger no warnings by default. The rationale for this is that it would be inconvenient to have to remove all unnecessary malignmark elements from automatically generated data.

3.5.5.6 MathML representation of an alignment example

The above rules are sufficient to explain the MathML representation of the example given near the start of this section.

issue 180

One way to represent that in MathML is:

<mtable groupalign="{decimalpoint left left decimalpoint left left decimalpoint}">
  <mtr>
    <mtd>
      <mrow>
        <mrow>
          <mrow>
            <maligngroup/>
            <mn> 8.44 </mn>
            <mo> &#x2062;<!--InvisibleTimes--> </mo>
            <maligngroup/>
            <mi> x </mi>
          </mrow>
          <maligngroup/>
          <mo> + </mo>
          <mrow>
            <maligngroup/>
            <mn> 55 </mn>
            <mo> &#x2062;<!--InvisibleTimes--> </mo>
            <maligngroup/>
            <mi> y </mi>
          </mrow>
        </mrow>
        <maligngroup/>
        <mo> = </mo>
        <maligngroup/>
        <mn> 0 </mn>
      </mrow>
    </mtd>
    </mtr>
    <mtr>
      <mtd>
        <mrow>
          <mrow>
            <mrow>
              <maligngroup/>
              <mn> 3.1 </mn>
              <mo> &#x2062;<!--InvisibleTimes--> </mo>
              <maligngroup/>
              <mi> x </mi>
            </mrow>
            <maligngroup/>
            <mo> - </mo>
            <mrow>
              <maligngroup/>
              <mn> 0.7 </mn>
              <mo> &#x2062;<!--InvisibleTimes--> </mo>
              <maligngroup/>
              <mi> y </mi>
            </mrow>
          </mrow>
          <maligngroup/>
          <mo> = </mo>
          <maligngroup/>
          <mrow>
            <mo> - </mo>
            <mn> 1.1 </mn>
          </mrow>
        </mrow>
      </mtd>
    </mtr>
  </mtable>
alignat example
3.5.5.7 A simple alignment algorithm

A simple algorithm by which a MathML renderer can perform the alignment specified in this section is given here. Since the alignment specification is deterministic (except for the definition of the left and right edges of a character), any correct MathML alignment algorithm will have the same behavior as this one. Each mtable column (alignment scope) can be treated independently; the algorithm given here applies to one mtable column, and takes into account the alignment elements and the columnalign attribute described under mtable (3.5.1 Table or Matrix <mtable>). In an RTL context, switch left and right edges in the algorithm.

Note

This algorithm should be verified by an implementation.

  1. A rendering is computed for the contents of each table cell in the column, using zero width for all maligngroup and malignmark elements. The final rendering will be identical except for horizontal shifts applied to each alignment group and/or table cell.
  2. For each alignment group, the horizontal positions of the left edge, alignment point (if specified by malignmark, otherwise the left edge), and right edge are noted, allowing the width of the group on each side of the alignment point (left and right) to be determined. The sum of these two side-widths, i.e. the sum of the widths to the left and right of the alignment point, will equal the width of the alignment group.
  3. Each column of alignment groups is scanned. The ith scan covers the ith alignment group in each table cell containing any alignment groups. Table cells with no alignment groups, or with fewer than i alignment groups, are ignored. Each scan computes two maximums over the alignment groups scanned: the maximum width to the left of the alignment point, and the maximum width to the right of the alignment point, of any alignment group scanned.
  4. The sum of all the maximum widths computed (two for each column of alignment groups) gives one total width, which will be the width of each table cell containing alignment groups. Call the maximum number of alignment groups in one cell n; each such cell is divided into 2n horizontally adjacent sections, called L(i) and R(i) for i from 1 to n, using the 2n maximum side-widths computed above; for each i, the width of all sections called L(i) is the maximum width of any cell's ith alignment group to the left of its alignment point, and the width of all sections called R(i) is the maximum width of any cell's ith alignment group to the right of its alignment point.
  5. Each alignment group is then shifted horizontally as a block to a unique position that places: in the section called L(i) that part of the ith group to the left of its alignment point; in the section called R(i) that part of the ith group to the right of its alignment point. This results in the alignment point of each ith group being on the boundary between adjacent sections L(i) and R(i), so that all alignment points of ith groups have the same horizontal position.

The widths of the table cells that contain no alignment groups were computed as part of the initial rendering, and may be different for each cell, and different from the single width used for cells containing alignment groups. The maximum of all the cell widths (for both kinds of cells) gives the width of the table column as a whole.

The position of each cell in the column is determined by the applicable part of the value of the columnalign attribute of the innermost surrounding mtable, mtr, or mtd element that has an explicit value for it, as described in the sections on those elements. This may mean that the cells containing alignment groups will be shifted within their column, in addition to their alignment groups having been shifted within the cells as described above, but since each such cell has the same width, it will be shifted the same amount within the column, thus maintaining the vertical alignment of the alignment points of the corresponding alignment groups in each cell.

3.6 Elementary Math

Mathematics used in the lower grades such as two-dimensional addition, multiplication, and long division tends to be tabular in nature. However, the specific notations used varies among countries much more than for higher level math. Furthermore, elementary math often presents examples in some intermediate state and MathML must be able to capture these intermediate or intentionally missing partial forms. Indeed, these constructs represent memory aids or procedural guides, as much as they represent ‘mathematics’.

The elements used for basic alignments in elementary math are:

mstack

align rows of digits and operators

msgroup

groups rows with similar alignment

msrow

groups digits and operators into a row

msline

draws lines between rows of the stack

mscarries

annotates the following row with optional borrows/carries and/or crossouts

mscarry

a borrow/carry and/or crossout for a single digit

mlongdiv

specifies a divisor and a quotient for long division, along with a stack of the intermediate computations

mstack and mlongdiv are the parent elements for all elementary math layout. Any children of mstack, mlongdiv, and msgroup, besides msrow, msgroup, mscarries and msline, are treated as if implicitly surrounded by an msrow (see 3.6.4 Rows in Elementary Math <msrow> for more details about rows).

Since the primary use of these stacking constructs is to stack rows of numbers aligned on their digits, and since numbers are always formatted left-to-right, the columns of an mstack are always processed left-to-right; the overall directionality in effect (i.e. the dir attribute) does not affect to the ordering of display of columns or carries in rows and, in particular, does not affect the ordering of any operators within a row (see 3.1.5 Directionality).

These elements are described in this section followed by examples of their use. In addition to two-dimensional addition, subtraction, multiplication, and long division, these elements can be used to represent several notations used for repeating decimals.

A very simple example of two-dimensional addition is shown below:

<mstack>
  <mn>424</mn>
  <msrow> <mo>+</mo> <mn>33</mn> </msrow>
  <msline/>
</mstack>
\begin{array}{r}   424 \\   +33 \\   \hline \end{array}

Many more examples are given in 3.6.8 Elementary Math Examples.

3.6.1 Stacks of Characters <mstack>

3.6.1.1 Description

mstack is used to lay out rows of numbers that are aligned on each digit. This is common in many elementary math notations such as 2D addition, subtraction, and multiplication.

The children of an mstack represent rows, or groups of them, to be stacked each below the previous row; there can be any number of rows. An msrow represents a row; an msgroup groups a set of rows together so that their horizontal alignment can be adjusted together; an mscarries represents a set of carries to be applied to the following row; an msline represents a line separating rows. Any other element is treated as if implicitly surrounded by msrow.

Each row contains ‘digits’ that are placed into columns. (see 3.6.4 Rows in Elementary Math <msrow> for further details). The stackalign attribute together with the position and shift attributes of msgroup, mscarries, and msrow determine to which column a character belongs.

The width of a column is the maximum of the widths of each ‘digit’ in that column — carries do not participate in the width calculation; they are treated as having zero width. If an element is too wide to fit into a column, it overflows into the adjacent column(s) as determined by the charalign attribute. If there is no character in a column, its width is taken to be the width of a 0 in the current language (in many fonts, all digits have the same width).

The method for laying out an mstack is:

  1. The ‘digits’ in a row are determined.

  2. All of the digits in a row are initially aligned according to the stackalign value.

  3. Each row is positioned relative to that alignment based on the position attribute (if any) that controls that row.

  4. The maximum width of the digits in a column are determined and shorter and wider entries in that column are aligned according to the charalign attribute.

  5. The width and height of the mstack element are computed based on the rows and columns. Any overflow from a column is not used as part of that computation.

  6. The baseline of the mstack element is determined by the align attribute.

3.6.1.2 Attributes

mstack elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements.

Name values default
align ("top" | "bottom" | "center" | "baseline" | "axis"), rownumber? baseline
specifies the vertical alignment of the mstack with respect to its environment. The legal values and their meanings are the same as that for mtable's align attribute.
stackalign "left" | "center" | "right" | "decimalpoint" decimalpoint
specifies which column is used to horizontally align the rows. For left, rows are aligned flush on the left; similarly for right, rows are flush on the right; for center, the middle column (or to the right of the middle, for an even number of columns) is used for alignment. Rows with non-zero position, or affected by a shift, are treated as if the requisite number of empty columns were added on the appropriate side; see 3.6.3 Group Rows with Similar Positions <msgroup> and 3.6.4 Rows in Elementary Math <msrow>. For decimalpoint, the column used is the left-most column in each row that contains the decimalpoint character specified using the decimalpoint attribute of mstyle (default "."). If there is no decimalpoint character in the row, an implied decimal is assumed on the right of the first number in the row; see decimalpoint for a discussion of decimalpoint.
charalign "left" | "center" | "right" right
specifies the horizontal alignment of digits within a column. If the content is larger than the column width, then it overflows the opposite side from the alignment. For example, for right, the content will overflow on the left side; for center, it overflows on both sides. This excess does not participate in the column width calculation, nor does it participate in the overall width of the mstack. In these cases, authors should take care to avoid collisions between column overflows.
charspacing length | "loose" | "medium" | "tight" medium
specifies the amount of space to put between each column. Larger spacing might be useful if carries are not placed above or are particularly wide. The keywords loose, medium, and tight automatically adjust spacing to when carries or other entries in a column are wide. The three values allow authors to some flexibility in choosing what the layout looks like without having to figure out what values work well. In all cases, the spacing between columns is a fixed amount and does not vary between different columns.

3.6.2 Long Division <mlongdiv>

3.6.2.1 Description

Long division notation varies quite a bit around the world, although the heart of the notation is often similar. mlongdiv is similar to mstack and used to layout long division. The first two children of mlongdiv are the divisor and the result of the division, in that order. The remaining children are treated as if they were children of mstack. The placement of these and the lines and separators used to display long division are controlled by the longdivstyle attribute.

The result or divisor may be an elementary math element or may be none. In particular, if msgroup is used, the elements in that group may or may not form their own mstack or be part of the dividend's mstack, depending upon the value of the longdivstyle attribute. For example, in the US style for division, the result is treated as part of the dividend's mstack, but divisor is not. MathML does not specify when the result and divisor form their own mstack, nor does it specify what should happen if msline or other elementary math elements are used for the result or divisor and they do not participate in the dividend's mstack layout.

In the remainder of this section on elementary math, anything that is said about mstack applies to mlongdiv unless stated otherwise.

3.6.2.2 Attributes

mlongdiv elements accept all of the attributes that mstack elements accept (including those specified in 3.1.9 Mathematics attributes common to presentation elements), along with the attribute listed below.

The values allowed for longdivstyle are open-ended. Conforming renderers may ignore any value they do not handle, although renderers are encouraged to render as many of the values listed below as possible. Any rules drawn as part of division layout should be drawn using the color specified by mathcolor.

Name values default
longdivstyle "lefttop" | "stackedrightright" | "mediumstackedrightright" | "shortstackedrightright" | "righttop" | "left/\right" | "left)(right" | ":right=right" | "stackedleftleft" | "stackedleftlinetop" lefttop
Controls the style of the long division layout. The names are meant as a rough mnemonic that describes the position of the divisor and result in relation to the dividend.

See 3.6.8.3 Long Division for examples of how these notations are drawn. The values listed above are used for long division notations in different countries around the world:

lefttop

a notation that is commonly used in the United States, Great Britain, and elsewhere

stackedrightright

a notation that is commonly used in France and elsewhere

mediumrightright

a notation that is commonly used in Russia and elsewhere

shortstackedrightright

a notation that is commonly used in Brazil and elsewhere

righttop

a notation that is commonly used in China, Sweden, and elsewhere

left/\right

a notation that is commonly used in Netherlands

left)(right

a notation that is commonly used in India

:right=right

a notation that is commonly used in Germany

stackedleftleft

a notation that is commonly used in Arabic countries

stackedleftlinetop

a notation that is commonly used in Arabic countries

3.6.3 Group Rows with Similar Positions <msgroup>

3.6.3.1 Description

msgroup is used to group rows inside of the mstack and mlongdiv elements that have a similar position relative to the alignment of stack. If not explicitly given, the children representing the stack in mstack and mlongdiv are treated as if they are implicitly surrounded by an msgroup element.

3.6.3.2 Attributes

msgroup elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements.

Name values default
position integer 0
specifies the horizontal position of the rows within this group relative to the position determined by the containing msgroup (according to its position and shift attributes). The resulting position value is relative to the column specified by stackalign of the containing mstack or mlongdiv. Positive values move each row towards the tens digit, like multiplying by a power of 10, effectively padding with empty columns on the right; negative values move towards the ones digit, effectively padding on the left. The decimal point is counted as a column and should be taken into account for negative values.
shift integer 0
specifies an incremental shift of position for successive children (rows or groups) within this group. The value is interpreted as with position, but specifies the position of each child (except the first) with respect to the previous child in the group.

3.6.4 Rows in Elementary Math <msrow>

3.6.4.1 Description

An msrow represents a row in an mstack. In most cases it is implied by the context, but is useful explicitly for putting multiple elements in a single row, such as when placing an operator "+" or "-" alongside a number within an addition or subtraction.

If an mn element is a child of msrow (whether implicit or not), then the number is split into its digits and the digits are placed into successive columns. Any other element, with the exception of mstyle is treated effectively as a single digit occupying the next column. An mstyle is treated as if its children were directly the children of the msrow, but with their style affected by the attributes of the mstyle. The empty element none may be used to create an empty column.

Note that a row is considered primarily as if it were a number, which is always displayed left-to-right, and so the directionality used to display the columns is always left-to-right; textual bidirectionality within token elements (other than mn) still applies, as does the overall directionality within any children of the msrow (which end up treated as single digits); see 3.1.5 Directionality.

3.6.4.2 Attributes

msrow elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements.

Name values default
position integer 0
specifies the horizontal position of the rows within this group relative to the position determined by the containing msgroup (according to its position and shift attributes). The resulting position value is relative to the column specified by stackalign of the containing mstack or mlongdiv. Positive values move each row towards the tens digit, like multiplying by a power of 10, effectively padding with empty columns on the right; negative values move towards the ones digit, effectively padding on the left. The decimal point is counted as a column and should be taken into account for negative values.

3.6.5 Carries, Borrows, and Crossouts <mscarries>

3.6.5.1 Description

The mscarries element is used for various annotations such as carries, borrows, and crossouts that occur in elementary math. The children are associated with elements in the following row of the mstack. It is an error for mscarries to be the last element of an mstack or mlongdiv element. Each child of the mscarries applies to the same column in the following row. As these annotations are used to adorn what are treated as numbers, the attachment of carries to columns proceeds from left to right; the overall directionality does not apply to the ordering of the carries, although it may apply to the contents of each carry; see 3.1.5 Directionality.

Each child of mscarries other than mscarry or none is treated as if implicitly surrounded by mscarry; the element none is used when no carry for a particular column is needed. The mscarries element sets displaystyle to false, and increments scriptlevel by 1, so the children are typically displayed in a smaller font. (See 3.1.6 Displaystyle and Scriptlevel.) It also changes the default value of scriptsizemultiplier. The effect is that the inherited value of scriptsizemultiplier should still override the default value, but the default value, inside mscarries, should be 0.6. scriptsizemultiplier can be set on the mscarries element, and the value should override the inherited value as usual.

If two rows of carries are adjacent to each other, the first row of carries annotates the second (following) row as if the second row had location=n. This means that the second row, even if it does not draw, visually uses some (undefined by this specification) amount of space when displayed.

3.6.5.2 Attributes

mscarries elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements.

Name values default
position integer 0
specifies the horizontal position of the rows within this group relative to the position determined by the containing msgroup (according to its position and shift attributes). The resulting position value is relative to the column specified by stackalign of the containing mstack or mlongdiv. The interpretation of the value is the same as position for msgroup or msrow, but it alters the association of each carry with the column below. For example, position=1 would cause the rightmost carry to be associated with the second digit column from the right.
location "w" | "nw" | "n" | "ne" | "e" | "se" | "s" | "sw" n
specifies the location of the carry or borrow relative to the character below it in the associated column. Compass directions are used for the values; the default is to place the carry above the character.
crossout ("none" | "updiagonalstrike" | "downdiagonalstrike" | "verticalstrike" | "horizontalstrike")* none
specifies how the column content below each carry is "crossed out"; one or more values may be given and all values are drawn. If none is given with other values, it is ignored. See 3.6.8 Elementary Math Examples for examples of the different values. The crossout is only applied for columns which have a corresponding mscarry. The crossouts should be drawn using the color specified by mathcolor.
scriptsizemultiplier number inherited (0.6)
specifies the factor to change the font size by. See 3.1.6 Displaystyle and Scriptlevel for a description of how this works with the scriptsize attribute.

3.6.6 A Single Carry <mscarry>

3.6.6.1 Description

mscarry is used inside of mscarries to represent the carry for an individual column. A carry is treated as if its width were zero; it does not participate in the calculation of the width of its corresponding column; as such, it may extend beyond the column boundaries. Although it is usually implied, the element may be used explicitly to override the location and/or crossout attributes of the containing mscarries. It may also be useful with none as its content in order to display no actual carry, but still enable a crossout due to the enclosing mscarries to be drawn for the given column.

3.6.6.2 Attributes

The mscarry element accepts the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements.

Name values default
location "w" | "nw" | "n" | "ne" | "e" | "se" | "s" | "sw" inherited
specifies the location of the carry or borrow relative to the character in the corresponding column in the row below it. Compass directions are used for the values.
crossout ("none" | "updiagonalstrike" | "downdiagonalstrike" | "verticalstrike" | "horizontalstrike")* inherited
specifies how the column content associated with the carry is "crossed out"; one or more values may be given and all values are drawn. If none is given with other values, it is essentially ignored. The crossout should be drawn using the color specified by mathcolor.

3.6.7 Horizontal Line <msline/>

3.6.7.1 Description

msline draws a horizontal line inside of an mstack element. The position, length, and thickness of the line are specified as attributes. If the length is specified, the line is positioned and drawn as if it were a number with the given number of digits.

3.6.7.2 Attributes

msline elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements. The line should be drawn using the color specified by mathcolor.

Name values default
position integer 0
specifies the horizontal position of the rows within this group relative to the position determined by the containing msgroup (according to its position and shift attributes). The resulting position value is relative to the column specified by stackalign of the containing mstack or mlongdiv. Positive values move towards the tens digit (like multiplying by a power of 10); negative values move towards the ones digit. The decimal point is counted as a column and should be taken into account for negative values. Note that since the default line length spans the entire mstack, the position has no effect unless the length is specified as non-zero.
length unsigned-integer 0
Specifies the number of columns that should be spanned by the line. A value of '0' (the default) means that all columns in the row are spanned (in which case position and stackalign have no effect).
leftoverhang length 0
Specifies an extra amount that the line should overhang on the left of the leftmost column spanned by the line.
rightoverhang length 0
Specifies an extra amount that the line should overhang on the right of the rightmost column spanned by the line.
mslinethickness length | "thin" | "medium" | "thick" medium
Specifies how thick the line should be drawn. The line should have height=0, and depth=mslinethickness so that the top of the msline is on the baseline of the surrounding context (if any). (See 3.3.2 Fractions <mfrac> for discussion of the thickness keywords medium, thin and thick.)

3.6.8 Elementary Math Examples

3.6.8.1 Addition and Subtraction

Two-dimensional addition, subtraction, and multiplication typically involve numbers, carries/borrows, lines, and the sign of the operation.

Below is the example shown at the start of the section: the digits inside the mn elements each occupy a column as does the "+". none is used to fill in the column under the "4" and make the "+" appear to the left of all of the operands. Notice that no attributes are given on msline causing it to span all of the columns.

<mstack>
  <mn>424</mn>
  <msrow> <mo>+</mo> <none/> <mn>33</mn> </msrow>
  <msline/>
</mstack>
\begin{array}{@{}r@{}}    424 \\   +\phantom0 33 \\   \hline \end{array}

The next example illustrates how to put an operator on the right. Placing the operator on the right is standard in the Netherlands and some other countries. Notice that although there are a total of four columns in the example, because the default alignment is on the implied decimal point to the right of the numbers, it is not necessary to pad or shift any row.

<mstack>
  <mn>123</mn>
  <msrow> <mn>456</mn> <mo>+</mo> </msrow>
  <msline/>
  <mn>579</mn>
</mstack>
\begin{array}{l}   123 \\   456+ \\   \hline   579 \end{array}

The following two examples illustrate the use of mscarries, mscarry and using none to fill in a column. The examples also illustrate two different ways of displaying a borrow.

<mstack>
  <mscarries crossout='updiagonalstrike'>
    <mn>2</mn>  <mn>12</mn>  <mscarry crossout='none'> <none/> </mscarry>
  </mscarries>
  <mn>2,327</mn>
  <msrow> <mo>-</mo> <mn> 1,156</mn> </msrow>
  <msline/>
  <mn>1,171</mn>
</mstack>
<mstack>
  <mscarries location='nw'>
    <none/>
    <mscarry crossout='updiagonalstrike' location='n'> <mn>2</mn> </mscarry>
    <mn>1</mn>
    <none/>
  </mscarries>
  <mn>2,327</mn>
  <msrow> <mo>-</mo> <mn> 1,156</mn> </msrow>
  <msline/>
  <mn>1,171</mn>
</mstack>

The MathML for the second example uses mscarry because a crossout should only happen on a single column:

The next example of subtraction shows a borrowed amount that is underlined (the example is from a Swedish source). There are two things to notice: an menclose is used in the carry, and none is used for the empty element so that mscarry can be used to create a crossout.

<mstack>
  <mscarries>
    <mscarry crossout='updiagonalstrike'><none/></mscarry>
    <menclose notation='bottom'> <mn>10</mn> </menclose>
  </mscarries>
  <mn>52</mn>
  <msrow> <mo>-</mo> <mn> 7</mn> </msrow>
  <msline/>
  <mn>45</mn>
</mstack>
\begin{array}{r} \underbar{\scriptsize 10}\!\\ 5\llap{$/$}2\\ {}-{}7\\ \hline 45 \end{array}
3.6.8.2 Multiplication

Below is a simple multiplication example that illustrates the use of msgroup and the shift attribute. The first msgroup is implied and doesn't change the layout. The second msgroup could also be removed, but msrow would be needed for last two children. They msrow would need to set the position or shift attributes, or would add none elements to pad the digits on the right.

<mstack>
  <msgroup>
    <mn>123</mn>
    <msrow><mo>×</mo><mn>321</mn></msrow>
  </msgroup>
  <msline/>
  <msgroup shift="1">
    <mn>123</mn>
    <mn>246</mn>
    <mn>369</mn>
  </msgroup>
  <msline/>
</mstack>

The following is a more complicated example of multiplication that has multiple rows of carries. It also (somewhat artificially) includes commas (",") as digit separators. The encoding includes these separators in the spacing attribute value, along non-ASCII values.

<mstack>
  <mscarries><mn>1</mn><mn>1</mn><none/></mscarries>
  <mscarries><mn>1</mn><mn>1</mn><none/></mscarries>
  <mn>1,234</mn>
  <msrow><mo>×</mo><mn>4,321</mn></msrow>
  <msline/>

  <mscarries position='2'>
    <mn>1</mn>
    <none/>
    <mn>1</mn>
    <mn>1</mn>
    <mn>1</mn>
    <none/>
    <mn>1</mn>
  </mscarries>
  <msgroup shift="1">
    <mn>1,234</mn>
    <mn>24,68</mn>
    <mn>370,2</mn>
    <msrow position="1"> <mn>4,936</mn> </msrow>
  </msgroup>
  <msline/>

  <mn>5,332,114</mn>
</mstack>
\begin{array}{r}  {}_1 {\hspace{0.05em}}_1\phantom{0} \\  {}_1 {\hspace{0.05em}}_1\phantom{0} \\   1,234 \\   \times 4,321 \\   \hline  {}_1 \phantom{,} {\hspace{0.05em \,}}_1 {\hspace{0.05em}}_1  {\hspace{0.05em}}_1 \phantom{,} {\hspace{0.05em \,}}_1 \phantom{00} \\   1,234 \\   24,68\phantom{0} \\   370,2\phantom{00} \\   4,936\phantom{,000} \\   \hline   5,332,114 \end{array}
3.6.8.3 Long Division

The notation used for long division varies considerably among countries. Most notations share the common characteristics of aligning intermediate results and drawing lines for the operands to be subtracted. Minus signs are sometimes shown for the intermediate calculations, and sometimes they are not. The line that is drawn varies in length depending upon the notation. The most apparent difference among the notations is that the position of the divisor varies, as does the location of the quotient, remainder, and intermediate terms.

The layout used is controlled by the longdivstyle attribute. Below are examples for the values listed in 3.6.2.2 Attributes.

lefttop stackedrightright mediumstackedrightright shortstackedrightright righttop
left/\right left)(right :right=right stackedleftleft stackedleftlinetop

The MathML for the first example is shown below. It illustrates the use of nested msgroups and how the position is calculated in those usages.

<mlongdiv longdivstyle="lefttop">
  <mn> 3 </mn>
  <mn> 435.3</mn>

  <mn> 1306</mn>

  <msgroup position="2" shift="-1">
    <msgroup>
      <mn> 12</mn>
      <msline length="2"/>
    </msgroup>
    <msgroup>
      <mn> 10</mn>
      <mn> 9</mn>
      <msline length="2"/>
    </msgroup>
    <msgroup>
      <mn> 16</mn>
      <mn> 15</mn>
      <msline length="2"/>
      <mn> 1.0</mn>           <!-- aligns on '.', not the right edge ('0') -->
    </msgroup>
    <msgroup position='-1'>   <!-- extra shift to move to the right of the "." -->
      <mn> 9</mn>
      <msline length="3"/>
      <mn> 1</mn>
    </msgroup>
  </msgroup>
</mlongdiv>

With the exception of the last example, the encodings for the other examples are the same except that the values for longdivstyle differ and that a "," is used instead of a "." for the decimal point. For the last example, the only difference from the other examples besides a different value for longdivstyle is that Arabic numerals have been used in place of Latin numerals, as shown below.

<mstyle decimalpoint="٫">
  <mlongdiv longdivstyle="stackedleftlinetop">
    <mn> ٣ </mn>
    <mn> ٤٣٥٫٣</mn>

    <mn> ١٣٠٦</mn>
    <msgroup position="2" shift="-1">
      <msgroup>
        <mn> ١٢</mn>
        <msline length="2"/>
      </msgroup>
      <msgroup>
        <mn> ١٠</mn>
        <mn> ٩</mn>
        <msline length="2"/>
      </msgroup>
      <msgroup>
        <mn> ١٦</mn>
        <mn> ١٥</mn>
        <msline length="2"/>
        <mn> ١٫٠</mn>
      </msgroup>
      <msgroup position='-1'>
        <mn> ٩</mn>
        <msline length="3"/>
        <mn> ١</mn>
      </msgroup>
    </msgroup>
  </mlongdiv>
</mstyle>
3.6.8.4 Repeating decimal

Decimal numbers that have digits that repeat infinitely such as 1/3 (.3333...) are represented using several notations. One common notation is to put a horizontal line over the digits that repeat (in Portugal an underline is used). Another notation involves putting dots over the digits that repeat. The MathML for these involves using mstack, msrow, and msline in a straightforward manner. These notations are shown below:

<mstack stackalign="right">
  <msline length="1"/>
  <mn> 0.3333 </mn>
</mstack>
0.33333 \overline{3}
<mstack stackalign="right">
  <msline length="6"/>
  <mn> 0.142857 </mn>
</mstack>
0.\overline{142857}
<mstack stackalign="right">
  <mn> 0.142857 </mn>
  <msline length="6"/>
</mstack>
0.\underline{142857}
<mstack stackalign="right">
  <msrow> <mo>.</mo> <none/><none/><none/><none/> <mo>.</mo> </msrow>
  <mn> 0.142857 </mn>
</mstack>
0.\dot{1}4285\dot{7}

3.7 Enlivening Expressions

3.7.1 Bind Action to Sub-Expression

The maction element provides a mechanism for binding actions to expressions. This element accepts any number of sub-expressions as arguments and the type of action that should happen is controlled by the actiontype attribute. MathML 3 predefined the four actions: toggle, statusline, statusline, and input. However, because the ability to implement any action depends very strongly on the platform, MathML 4 no longer predefines what these actions do. Furthermore, in the web environment events connected to javascript to perform actions are a more powerful solution, although maction provides a convenient wrapper element on which to attach such an event.

Linking to other elements, either locally within the math element or to some URL, is not handled by maction. Instead, it is handled by adding a link directly on a MathML element as specified in 7.4.4 Linking.

3.7.1.1 Attributes

maction elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements.

By default, MathML applications that do not recognize the specified actiontype should render the selected sub-expression as defined below. If no selected sub-expression exists, it is a MathML error; the appropriate rendering in that case is as described in D.2 Handling of Errors.

Name values default
actiontype string required
Specifies what should happen for this element. The values allowed are open-ended. Conforming renderers may ignore any value they do not handle, although renderers are encouraged to render the values listed below.
selection positive-integer 1
Specifies which child should be used for viewing. Its value should be between 1 and the number of children of the element. The specified child is referred to as the selected sub-expression of the maction element. If the value specified is out of range, it is an error. When the selection attribute is not specified (including for action types for which it makes no sense), its default value is 1, so the selected sub-expression will be the first sub-expression.

If a MathML application responds to a user command to copy a MathML sub-expression to the environment's clipboard (see 7.3 Transferring MathML), any maction elements present in what is copied should be given selection values that correspond to their selection state in the MathML rendering at the time of the copy command.

When a MathML application receives a mouse event that may be processed by two or more nested maction elements, the innermost maction element of each action type should respond to the event.

The actiontype values are open-ended. If another value is given and it requires additional attributes, the attributes must be in a different namespace in XML; in HTML the attributes must begin with "data-". An XML example is shown below:

<maction actiontype="highlight" my:color="red" my:background="yellow"> expression </maction>

In the example, non-standard attributes from another namespace are being used to pass additional information to renderers that support them, without violating the MathML Schema (see D.3 Attributes for unspecified data). The my:color attributes might change the color of the characters in the presentation, while the my:background attribute might change the color of the background behind the characters.

3.8 Semantics and Presentation

MathML uses the semantics element to allow specifying semantic annotations to presentation MathML elements; these can be content MathML or other notations. As such, semantics should be considered part of both presentation MathML and content MathML. All MathML processors should process the semantics element, even if they only process one of those subsets.

In semantic annotations a presentation MathML expression is typically the first child of the semantics element. However, it can also be given inside of an annotation-xml element inside the semantics element. If it is part of an annotation-xml element, then encoding=application/mathml-presentation+xml or encoding=MathML-Presentation may be used and presentation MathML processors should use this value for the presentation.

See 6. Annotating MathML: semantics for more details about the semantics and annotation-xml elements.

4. Content Markup

Issue 284: Make the sample presentation of Strict Content use intent MathML 4need specification update

There are currently "sample" renderings. Let's make this use intent.

4.1 Introduction

4.1.1 The Purpose of Content Markup

The purpose of Content Markup is to provide an explicit encoding of the underlying mathematical meaning of an expression, rather than any particular notation for the expression. Mathematical notation is at times ambiguous, context-dependent, and varies from community to community. In many cases, it is preferable to work directly with the underlying, formal, mathematical objects. Content Markup provides a rigorous, extensible semantic framework and a markup language for this purpose.

By encoding the underlying mathematical structure explicitly, without regard to how it is presented, it is possible to interchange information more precisely between systems that semantically process mathematical objects. Important application areas include computer algebra systems, automatic reasoning systems, industrial and scientific applications, multi-lingual translation systems, mathematical search, automated scoring of online assessments, and interactive textbooks.

This chapter presents an overview of basic concepts used to define Content Markup, describes a core collection of elements that comprise Strict Content Markup, and defines a full collection of elements to support common mathematical idioms. Strict Content Markup encodes general expression trees in a semantically rigorous way, while the full set of Content MathML elements provides backward-compatibility with previous versions of Content Markup. The correspondence between full Content Markup and Strict Content Markup is defined in F. The Strict Content MathML Transformation, which details an algorithm to translate arbitrary Content Markup into Strict Content Markup.

4.1.2 Content Expressions

Content MathML represents mathematical objects as expression trees. In general, an expression tree is constructed by applying an operator to a sequence of sub-expressions. For example, the sum x+y can be constructed as the application of the addition operator to two arguments x and y, and the expression cos(π) as the application of the cosine function to the number π.

The terminal nodes in an expression tree represent basic mathematical objects such as numbers, variables, arithmetic operations, and so on. The internal nodes in the tree represent function application or other mathematical constructions that build up compound objects.

MathML defines a relatively small number of commonplace mathematical constructs, chosen to be sufficient in a wide range of applications. In addition, it provides a mechanism to refer to concepts outside of the collection it defines, allowing them to be represented as well.

The defined set of content elements is designed to be adequate for simple coding of formulas typically used from kindergarten through the first two years of college in the United States, that is, up to A-Level or Baccalaureate level in Europe.

The primary role of the MathML content element set is to encode the mathematical structure of an expression independent of the notation used to present it. However, rendering issues cannot be ignored. There are many different approaches to render Content MathML formulae, ranging from native implementations of the MathML elements, to declarative notation definitions, to XSLT style sheets. Because rendering requirements for Content MathML vary widely, MathML does not provide a normative rendering specification. Instead, typical renderings are suggested by way of examples given using presentation markup.

4.1.3 Expression Concepts

The basic building blocks of Content MathML expressions are numbers, identifiers, and symbols. These building blocks are combined using function application and binding operators.

In the expression x+2, the numeral 2 represents a number with a fixed value. Content MathML uses the cn element to represent numerical quantities. The identifier x is a mathematical variable, that is, an identifier that represents a quantity with no predetermined value. Content MathML uses the ci element to represent variable identifiers.

The plus sign is an identifier that represents a fixed, externally defined object, namely, the addition function. Such an identifier is called a symbol, to distinguish it from a variable. Common elementary functions and operators are all symbols in this sense. Content MathML uses the csymbol element to represent symbols.

The fundamental way to combine numbers, variables, and symbols is function application. Content MathML distinguishes between the function itself (which may be a symbol such as the sine function, a variable such as f, or some other expression) and the result of applying the function to its arguments. The apply element groups the function with its arguments syntactically, and represents the expression that results from applying the function to its arguments.

4.1.4 Variable Binding

In an expression, variables may be described as bound or free variables. Bound variables have a special role within the scope of a binding expression, and may be renamed consistently within that scope without changing the meaning of the expression. Free variables are those that are not bound within an expression. Content MathML differentiates between the application of a function to a free variable (e.g. f(x)) and an operation that binds a variable within a binding scope. The bind element is used to delineate the binding scope of a bound variable and to group the binding operator with its bound variables, which are supplied using the bvar element.

In Strict Content markup, the only way to perform variable binding is to use the bind element. In non-Strict Content markup, other markup elements are provided that more closely resemble well-known idiomatic notations, such as limit-style notations for sums and integrals. These constructs may implicitly bind variables, such as the variable of integration, or the index variable in a sum. MathML uses the term qualifier element to refer to those elements used to represent the auxiliary data required by these constructs.

Expressions involving qualifiers follow one of a small number of idiomatic patterns, each of which applies to a class of similar binding operators. For example, sums and products are in the same class because they use index variables following the same pattern. The Content MathML operator classes are described in detail in 4.3.4 Operator Classes.

4.1.5 Strict Content MathML

Beginning in MathML 3, Strict Content MathML is defined as a minimal subset of Content MathML that is sufficient to represent the meaning of mathematical expressions using a uniform structure. The full Content MathML element set retains backward compatibility with MathML 2, and strikes a pragmatic balance between verbosity and formality.

Content MathML provides a considerable number of predefined functions encoded as empty elements (e.g. sin, log, etc.) and a variety of constructs for forming compound objects (e.g. set, interval, etc.). In contrast, Strict Content MathML represents all known functions using a single element (csymbol) with an attribute that points to its definition in an extensible content dictionary, and uses only apply and bind elements to build up compound expressions. Token elements such as cn and ci are considered part of Strict Content MathML, but with a more restricted set of attributes and with content restricted to text.

The formal semantics of Content MathML expressions are given by specifying equivalent Strict Content MathML expressions, which all have formal semantics defined in terms of content dictionaries. The exact correspondence between each non-Strict Content MathML structure and its Strict Content MathML equivalent is described in terms of rewrite rules that are used as part of the transformation algorithm given in F. The Strict Content MathML Transformation.

The algorithm described in F. The Strict Content MathML Transformation is complete in the sense that it gives every Content MathML expression a specific meaning in terms of a Strict Content MathML expression. In some cases, it gives a specific strict interpretation to an expression whose meaning was not sufficiently specified in MathML 2. The goal of this algorithm is to be faithful to natural mathematical intuitions, however, some edge cases may remain where the specific interpretation given by the algorithm may be inconsistent with earlier expectations.

A conformant MathML processor need not implement this algorithm. The existence of these transformation rules does not imply that a system must treat equivalent expressions identically. In particular, systems may give different presentation renderings for expressions that the transformation rules imply are mathematically equivalent. In general, Content MathML does not define any expectations for the computational behavior of the expressions it encodes, including, but not limited to, the equivalence of any specific expressions.

Strict Content MathML is designed to be compatible with OpenMath, a standard for representing formal mathematical objects and semantics. Strict Content MathML is an XML encoding of OpenMath Objects in the sense of [OpenMath]. The following table gives the correspondence between Strict Content MathML elements and their OpenMath equivalents.

Strict Content MathML OpenMath
cn OMI, OMF
csymbol OMS
ci OMV
cs OMSTR
apply OMA
bind OMBIND
bvar OMBVAR
share OMR
semantics OMATTR
annotation, annotation-xml OMATP, OMFOREIGN
cerror OME
cbytes OMB

4.1.6 Content Dictionaries

Any method to formalize the meaning of mathematical expressions must be extensible, that is, it must provide the ability to define new functions and symbols to expand the domain of discourse. Content MathML uses the csymbol element to represent new symbols, and uses Content Dictionaries to describe their mathematical semantics. The association between a symbol and its semantic description is accomplished using the attributes of the csymbol element to point to the definition of the symbol in a Content Dictionary.

The correspondence between operator elements in Content MathML and symbol definitions in Content Dictionaries is given in E.3 The Content MathML Operators. These definitions for predefined MathML operator symbols refer to Content Dictionaries developed by the OpenMath Society [OpenMath] in conjunction with the W3C Math Working Group. It is important to note that this information is informative, not normative. In general, the precise mathematical semantics of predefined symbols are not fully specified by the MathML Recommendation, and the only normative statements about symbol semantics are those present in the text of this chapter. The semantic definitions provided by the OpenMath Content Dictionaries are intended to be sufficient for most applications, and are generally compatible with the semantics specified for analogous constructs in this Recommendation. However, in contexts where highly precise semantics are required (e.g. communication between computer algebra systems, within formal systems such as theorem provers, etc.) it is the responsibility of the relevant community of practice to verify, extend or replace definitions provided by OpenMath Content Dictionaries as appropriate.

4.2 Content MathML Elements Encoding Expression Structure

In this section we will present the elements for encoding the structure of content MathML expressions. These elements are the only ones used for the Strict Content MathML encoding. Concretely, we have

Full Content MathML allows further elements presented in 4.3 Content MathML for Specific Structures and 4.3 Content MathML for Specific Structures, and allows a richer content model presented in this section. Differences in Strict and non-Strict usage of are highlighted in the sections discussing each of the Strict element below.

4.2.1 Numbers <cn>

Schema Fragment (Strict) Schema Fragment (Full)
Class Cn Cn
Attributes CommonAtt, type CommonAtt, DefEncAtt, type?, base?
type Attribute Values integer | real | double | hexdouble     integer | real | double | hexdouble | e-notation | rational | complex-cartesian | complex-polar | constant | text default is real
base Attribute Values integer default is 10
Content text (text | mglyph | sep | PresentationExpression)*

The cn element is the Content MathML element used to represent numbers. Strict Content MathML supports integers, real numbers, and double precision floating point numbers. In these types of numbers, the content of cn is text. Additionally, cn supports rational numbers and complex numbers in which the different parts are separated by use of the sep element. Constructs using sep may be rewritten in Strict Content MathML as constructs using apply as described below.

The type attribute specifies which kind of number is represented in the cn element. The default value is real. Each type implies that the content be of a certain form, as detailed below.

4.2.1.1 Rendering <cn>,<sep/>-Represented Numbers

The default rendering of the text content of cn is the same as that of the Presentation element mn, with suggested variants in the case of attributes or sep being used, as listed below.

4.2.1.2 Strict uses of <cn>

In Strict Content MathML, the type attribute is mandatory, and may only take the values integer, real, hexdouble or double:

integer

An integer is represented by an optional sign followed by a string of one or more decimal digits.

real

A real number is presented in radix notation. Radix notation consists of an optional sign (+ or -) followed by a string of digits possibly separated into an integer and a fractional part by a decimal point. Some examples are 0.3, 1, and -31.56.

double

This type is used to mark up those double-precision floating point numbers that can be represented in the IEEE 754 standard format [IEEE754]. This includes a subset of the (mathematical) real numbers, negative zero, positive and negative real infinity and a set of not a number values. The lexical rules for interpreting the text content of a cn as an IEEE double are specified by Section 3.1.2.5 of XML Schema Part 2: Datatypes Second Edition [XMLSchemaDatatypes]. For example, -1E4, 1267.43233E12, 12.78e-2, 12, -0, 0 and INF are all valid doubles in this format.

hexdouble

This type is used to directly represent the 64 bits of an IEEE 754 double-precision floating point number as a 16 digit hexadecimal number. Thus the number represents mantissa, exponent, and sign from lowest to highest bits using a least significant byte ordering. This consists of a string of 16 digits 0-9, A-F. The following example represents a NaN value. Note that certain IEEE doubles, such as the NaN in the example, cannot be represented in the lexical format for the double type.

<cn type="hexdouble">7F800000</cn>

Sample Presentation

<mn>0x7F800000</mn>
0x7F800000
4.2.1.3 Non-Strict uses of <cn>

The base attribute is used to specify how the content is to be parsed. The attribute value is a base 10 positive integer giving the value of base in which the text content of the cn is to be interpreted. The base attribute should only be used on elements with type integer or real. Its use on cn elements of other type is deprecated. The default value for base is 10.

Additional values for the type attribute element for supporting e-notations for real numbers, rational numbers, complex numbers and selected important constants. As with the integer, real, double and hexdouble types, each of these types implies that the content be of a certain form. If the type attribute is omitted, it defaults to real.

integer

Integers can be represented with respect to a base different from 10: If base is present, it specifies (in base 10) the base for the digit encoding. Thus base='16' specifies a hexadecimal encoding. When base > 10, Latin letters (A-Z, a-z) are used in alphabetical order as digits. The case of letters used as digits is not significant. The following example encodes the base 10 number 32736.

<cn base="16">7FE0</cn>

Sample Presentation

<msub><mn>7FE0</mn><mn>16</mn></msub>
7FE016

When base > 36, some integers cannot be represented using numbers and letters alone. For example, while

<cn base="1000">10F</cn>

arguably represents the number written in base 10 as 1,000,015, the number written in base 10 as 1,000,037 cannot be represented using letters and numbers alone when base is 1000. Consequently, support for additional characters (if any) that may be used for digits when base > 36 is application specific.

real

Real numbers can be represented with respect to a base different than 10. If a base attribute is present, then the digits are interpreted as being digits computed relative to that base (in the same way as described for type integer).

e-notation

A real number may be presented in scientific notation using this type. Such numbers have two parts (a significand and an exponent) separated by a <sep/> element. The first part is a real number, while the second part is an integer exponent indicating a power of the base.

For example, <cn type="e-notation">12.3<sep/>5</cn> represents 12.3×105. The default presentation of this example is 12.3e5. Note that this type is primarily useful for backwards compatibility with MathML 2, and in most cases, it is preferable to use the double type, if the number to be represented is in the range of IEEE doubles:

rational

A rational number is given as two integers to be used as the numerator and denominator of a quotient. The numerator and denominator are separated by <sep/>.

<cn type="rational">22<sep/>7</cn>

Sample Presentation

<mrow><mn>22</mn><mo>/</mo><mn>7</mn></mrow>
22/7
complex-cartesian

A complex cartesian number is given as two numbers specifying the real and imaginary parts. The real and imaginary parts are separated by the <sep/> element, and each part has the format of a real number as described above.

<cn type="complex-cartesian"> 12.3 <sep/> 5 </cn>

Sample Presentation

<mrow>
  <mn>12.3</mn><mo>+</mo><mn>5</mn><mo>&#x2062;<!--InvisibleTimes--></mo><mi>i</mi>
</mrow>
12.3+5i
complex-polar

A complex polar number is given as two numbers specifying the magnitude and angle. The magnitude and angle are separated by the <sep/> element, and each part has the format of a real number as described above.

<cn type="complex-polar"> 2 <sep/> 3.1415 </cn>

Sample Presentation

<mrow>
  <mn>2</mn>
  <mo>&#x2062;<!--InvisibleTimes--></mo>
  <msup>
    <mi>e</mi>
    <mrow><mi>i</mi><mo>&#x2062;<!--InvisibleTimes--></mo><mn>3.1415</mn></mrow>
  </msup>
</mrow>
2 e i3.1415
<mrow>
  <mi>Polar</mi>
  <mo>&#x2061;<!--ApplyFunction--></mo>
  <mrow><mo>(</mo><mn>2</mn><mo>,</mo><mn>3.1415</mn><mo>)</mo></mrow>
</mrow>
Polar (2,3.1415)
constant

If the value type is constant, then the content should be a Unicode representation of a well-known constant. Some important constants and their common Unicode representations are listed below.

This cn type is primarily for backward compatibility with MathML 1.0. MathML 2.0 introduced many empty elements, such as <pi/> to represent constants, and using these representations or a Strict csymbol representation is preferred.

In addition to the additional values of the type attribute, the content of cn element can contain (in addition to the sep element allowed in Strict Content MathML) mglyph elements to refer to characters not currently available in Unicode, or a general presentation construct (see 3.1.8 Summary of Presentation Elements), which is used for rendering (see 4.1.2 Content Expressions).

If a base attribute is present, it specifies the base used for the digit encoding of both integers. The use of base with rational numbers is deprecated.

4.2.2 Content Identifiers <ci>

Schema Fragment (Strict) Schema Fragment (Full)
Class Ci Ci
Attributes CommonAtt, type? CommonAtt, DefEncAtt, type?
type Attribute Values integer| rational| real| complex| complex-polar| complex-cartesian| constant| function| vector| list| set| matrix string
Qualifiers BvarQ, DomainQ, degree, momentabout, logbase
Content text text | mglyph | PresentationExpression

Content MathML uses the ci element (mnemonic for content identifier) to construct a variable. Content identifiers represent mathematical variables which have properties, but no fixed value. For example, x and y are variables in the expression x+y, and the variable x would be represented as

<ci>x</ci>

In MathML, variables are distinguished from symbols, which have fixed, external definitions, and are represented by the csymbol element.

After white space normalization the content of a ci element is interpreted as a name that identifies it. Two variables are considered equal, if and only if their names are identical and in the same scope (see 4.2.6 Bindings and Bound Variables <bind> and <bvar> for a discussion).

4.2.2.1 Strict uses of <ci>

The ci element uses the type attribute to specify the basic type of object that it represents. In Strict Content MathML, the set of permissible values is integer, rational, real, complex, complex-polar, complex-cartesian, constant, function, vector, list, set, and matrix. These values correspond to the symbols integer_type, rational_type, real_type, complex_polar_type, complex_cartesian_type, constant_type, fn_type, vector_type, list_type, set_type, and matrix_type in the mathmltypes Content Dictionary: In this sense the following two expressions are considered equivalent:

<ci type="integer">n</ci>
<semantics>
  <ci>n</ci>
  <annotation-xml cd="mathmltypes" name="type" encoding="MathML-Content">
    <csymbol cd="mathmltypes">integer_type</csymbol>
  </annotation-xml>
</semantics>

Note that complex should be considered an alias for complex-cartesian and rewritten to the same complex_cartesian_type symbol. It is perhaps a more natural type name for use with ci as the distinction between cartesian and polar form really only affects the interpretation of literals encoded with cn.

4.2.2.2 Non-Strict uses of <ci>

The ci element allows any string value for the type attribute, in particular any of the names of the MathML container elements or their type values.

For a more advanced treatment of types, the type attribute is inappropriate. Advanced types require significant structure of their own (for example, vector(complex)) and are probably best constructed as mathematical objects and then associated with a MathML expression through use of the semantics element. See [MathML-Types] for more examples.

4.2.2.3 Rendering Content Identifiers

If the content of a ci element consists of Presentation MathML, that presentation is used. If no such tagging is supplied then the text content is rendered as if it were the content of an mi element. If an application supports bidirectional text rendering, then the rendering follows the Unicode bidirectional rendering.

The type attribute can be interpreted to provide rendering information. For example in

<ci type="vector">V</ci>

a renderer could display a bold V for the vector.

4.2.3 Content Symbols <csymbol>

Schema Fragment (Strict) Schema Fragment (Full)
Class Csymbol Csymbol
Attributes CommonAtt, cd CommonAtt, DefEncAtt, type?, cd?
Content SymbolName text | mglyph | PresentationExpression
Qualifiers BvarQ, DomainQ, degree, momentabout, logbase

A csymbol is used to refer to a specific, mathematically-defined concept with an external definition. In the expression x+y, the plus sign is a symbol since it has a specific, external definition, namely the addition function. MathML 3 calls such an identifier a symbol. Elementary functions and common mathematical operators are all examples of symbols. Note that the term symbol is used here in an abstract sense and has no connection with any particular presentation of the construct on screen or paper.

4.2.3.1 Strict uses of <csymbol>

The csymbol identifies the specific mathematical concept it represents by referencing its definition via attributes. Conceptually, a reference to an external definition is merely a URI, i.e. a label uniquely identifying the definition. However, to be useful for communication between user agents, external definitions must be shared.

For this reason, several longstanding efforts have been organized to develop systematic, public repositories of mathematical definitions. Most notable of these, the OpenMath Society repository of Content Dictionaries (CDs) is extensive, open and active. In MathML 3, OpenMath CDs are the preferred source of external definitions. In particular, the definitions of pre-defined MathML 3 operators and functions are given in terms of OpenMath CDs.

MathML 3 provides two mechanisms for referencing external definitions or content dictionaries. The first, using the cd attribute, follows conventions established by OpenMath specifically for referencing CDs. This is the form required in Strict Content MathML. The second, using the definitionURL attribute, is backward compatible with MathML 2, and can be used to reference CDs or any other source of definitions that can be identified by a URI. It is described in the following section.

When referencing OpenMath CDs, the preferred method is to use the cd attribute as follows. Abstractly, OpenMath symbol definitions are identified by a triple of values: a symbol name, a CD name, and a CD base, which is a URI that disambiguates CDs of the same name. To associate such a triple with a csymbol, the content of the csymbol specifies the symbol name, and the name of the Content Dictionary is given using the cd attribute. The CD base is determined either from the document embedding the math element which contains the csymbol by a mechanism given by the embedding document format, or by system defaults, or by the cdgroup attribute, which is optionally specified on the enclosing math element; see 2.2.1 Attributes. In the absence of specific information http://www.openmath.org/cd is assumed as the CD base for all csymbol elements annotation, and annotation-xml. This is the CD base for the collection of standard CDs maintained by the OpenMath Society.

The cdgroup specifies a URL to an OpenMath CD Group file. For a detailed description of the format of a CD Group file, see Section 4.4.2 (CDGroups) in [OpenMath]. Conceptually, a CD group file is a list of pairs consisting of a CD name, and a corresponding CD base. When a csymbol references a CD name using the cd attribute, the name is looked up in the CD Group file, and the associated CD base value is used for that csymbol. When a CD Group file is specified, but a referenced CD name does not appear in the group file, or there is an error in retrieving the group file, the referencing csymbol is not defined. However, the handling of the resulting error is not defined, and is the responsibility of the user agent.

While references to external definitions are URIs, it is strongly recommended that CD files be retrievable at the location obtained by interpreting the URI as a URL. In particular, other properties of the symbol being defined may be available by inspecting the Content Dictionary specified. These include not only the symbol definition, but also examples and other formal properties. Note, however, that there are multiple encodings for OpenMath Content Dictionaries, and it is up to the user agent to correctly determine the encoding when retrieving a CD.

4.2.3.2 Non-Strict uses of <csymbol>

In addition to the forms described above, the csymbol and element can contain mglyph elements to refer to characters not currently available in Unicode, or a general presentation construct (see 3.1.8 Summary of Presentation Elements), which is used for rendering (see 4.1.2 Content Expressions). In this case, when writing to Strict Content MathML, the csymbol should be treated as a ci element, and rewritten using Rewrite: ci presentation mathml.

External definitions (in OpenMath CDs or elsewhere) may also be specified directly for a csymbol using the definitionURL attribute. When used to reference OpenMath symbol definitions, the abstract triple of (symbol name, CD name, CD base) is mapped to a fully-qualified URI as follows:

URI = cdbase + '/' + cd-name + '#' + symbol-name

For example,

(plus, arith1, http://www.openmath.org/cd)

is mapped to

http://www.openmath.org/cd/arith1#plus

The resulting URI is specified as the value of the definitionURL attribute.

This form of reference is useful for backwards compatibility with MathML2 and to facilitate the use of Content MathML within URI-based frameworks (such as RDF [RDF] in the Semantic Web or OMDoc [OMDoc1.2]). Another benefit is that the symbol name in the CD does not need to correspond to the content of the csymbol element. However, in general, this method results in much longer MathML instances. Also, in situations where CDs are under development, the use of a CD Group file allows the locations of CDs to change without a change to the markup. A third drawback to definitionURL is that unlike the cd attribute, it is not limited to referencing symbol definitions in OpenMath content dictionaries. Hence, it is not in general possible for a user agent to automatically determine the proper interpretation for definitionURL values without further information about the context and community of practice in which the MathML instance occurs.

Both the cd and definitionURL mechanisms of external reference may be used within a single MathML instance. However, when both a cd and a definitionURL attribute are specified on a single csymbol, the cd attribute takes precedence.

4.2.3.3 Rendering Symbols

If the content of a csymbol element is tagged using presentation tags, that presentation is used. If no such tagging is supplied then the text content is rendered as if it were the content of an mi element. In particular if an application supports bidirectional text rendering, then the rendering follows the Unicode bidirectional rendering.

4.2.4 String Literals <cs>

Schema Fragment (Strict) Schema Fragment (Full)
Class Cs Cs
Attributes CommonAtt CommonAtt, DefEncAtt
Content text text

The cs element encodes string literals which may be used in Content MathML expressions.

The content of cs is text; no Presentation MathML constructs are allowed even when used in non-strict markup. Specifically, cs may not contain mglyph elements, and the content does not undergo white space normalization.

Content MathML

<set>
  <cs>A</cs><cs>B</cs><cs>  </cs>
</set>

Sample Presentation

<mrow>
  <mo>{</mo>
  <ms>A</ms>
  <mo>,</mo>
  <ms>B</ms>
  <mo>,</mo>
  <ms>&#xa0;&#xa0;</ms>
  <mo>}</mo>
</mrow>
{ A , B ,    }

4.2.5 Function Application <apply>

Schema Fragment (Strict) Schema Fragment (Full)
Class Apply Apply
Attributes CommonAtt CommonAtt, DefEncAtt
Content ContExp+ ContExp+ | (ContExp, BvarQ, Qualifier?, ContExp*)

The most fundamental way of building a compound object in mathematics is by applying a function or an operator to some arguments.

4.2.5.1 Strict Content MathML

In MathML, the apply element is used to build an expression tree that represents the application of a function or operator to its arguments. The resulting tree corresponds to a complete mathematical expression. Roughly speaking, this means a piece of mathematics that could be surrounded by parentheses or logical brackets without changing its meaning.

For example, (x + y) might be encoded as

<apply><csymbol cd="arith1">plus</csymbol><ci>x</ci><ci>y</ci></apply>

The opening and closing tags of apply specify exactly the scope of any operator or function. The most typical way of using apply is simple and recursive. Symbolically, the content model can be described as:

<apply> op [ a b ...] </apply>

where the operands a, b, ... are MathML expression trees themselves, and op is a MathML expression tree that represents an operator or function. Note that apply constructs can be nested to arbitrary depth.

An apply may in principle have any number of operands. For example, (x + y + z) can be encoded as

<apply><csymbol cd="arith1">plus</csymbol>
  <ci>x</ci>
  <ci>y</ci>
  <ci>z</ci>
</apply>

Note that MathML also allows applications without operands, e.g. to represent functions like random(), or current-date().

Mathematical expressions involving a mixture of operations result in nested occurrences of apply. For example, a x + b would be encoded as

<apply><csymbol cd="arith1">plus</csymbol>
  <apply><csymbol cd="arith1">times</csymbol>
    <ci>a</ci>
    <ci>x</ci>
  </apply>
  <ci>b</ci>
</apply>

There is no need to introduce parentheses or to resort to operator precedence in order to parse expressions correctly. The apply tags provide the proper grouping for the re-use of the expressions within other constructs. Any expression enclosed by an apply element is well-defined, coherent object whose interpretation does not depend on the surrounding context. This is in sharp contrast to presentation markup, where the same expression may have very different meanings in different contexts. For example, an expression with a visual rendering such as (F+G)(x) might be a product, as in

<apply><csymbol cd="arith1">times</csymbol>
  <apply><csymbol cd="arith1">plus</csymbol>
    <ci>F</ci>
    <ci>G</ci>
  </apply>
  <ci>x</ci>
</apply>

or it might indicate the application of the function F + G to the argument x. This is indicated by constructing the sum

<apply><csymbol cd="arith1">plus</csymbol><ci>F</ci><ci>G</ci></apply>

and applying it to the argument x as in

<apply>
  <apply><csymbol cd="arith1">plus</csymbol>
    <ci>F</ci>
    <ci>G</ci>
  </apply>
  <ci>x</ci>
</apply>

In both cases, the interpretation of the outer apply is explicit and unambiguous, and does not change regardless of where the expression is used.

The preceding example also illustrates that in an apply construct, both the function and the arguments may be simple identifiers or more complicated expressions.

The apply element is conceptually necessary in order to distinguish between a function or operator, and an instance of its use. The expression constructed by applying a function to 0 or more arguments is always an element from the codomain of the function. Proper usage depends on the operator that is being applied. For example, the plus operator may have zero or more arguments, while the minus operator requires one or two arguments in order to be properly formed.

4.2.5.2 Rendering Applications

Strict Content MathML applications are rendered as mathematical function applications. If <mi>F</mi> denotes the rendering of <ci>f</ci> and <mi>Ai</mi> the rendering of <ci>ai</ci>, the sample rendering of a simple application is as follows:

Content MathML

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

Sample Presentation

<mrow>
  <mi>F</mi>
  <mo>&#x2061;<!--ApplyFunction--></mo>
  <mrow>
    <mo fence="true">(</mo>
    <mi>A1</mi>
    <mo separator="true">,</mo>
    <mi>...</mi>
    <mo separator="true">,</mo>
    <mi>A2</mi>
    <mo separator="true">,</mo>
    <mi>An</mi>
    <mo fence="true">)</mo>
  </mrow>
</mrow>
F ( A1 , ... , A2 , An )

Non-Strict MathML applications may also be used with qualifiers. In the absence of any more specific rendering rules for well-known operators, rendering should follow the sample presentation below, motivated by the typical presentation for sum. Let <mi>Op</mi> denote the rendering of <ci>op</ci>, <mi>X</mi> the rendering of <ci>x</ci>, and so on. Then:

Content MathML

<apply><ci>op</ci>
  <bvar><ci>x</ci></bvar>
  <domainofapplication><ci>d</ci></domainofapplication>
  <ci>expression-in-x</ci>
</apply>

Sample Presentation

<mrow>
  <munder>
    <mi>Op</mi>
    <mrow><mi>X</mi><mo></mo><mi>D</mi></mrow>
  </munder>
  <mo>&#x2061;<!--ApplyFunction--></mo>
  <mrow>
    <mo fence="true">(</mo>
    <mi>Expression-in-X</mi>
    <mo fence="true">)</mo>
  </mrow>
</mrow>
Op XD ( Expression-in-X )

4.2.6 Bindings and Bound Variables <bind> and <bvar>

Many complex mathematical expressions are constructed with the use of bound variables, and bound variables are an important concept of logic and formal languages. Variables become bound in the scope of an expression through the use of a quantifier. Informally, they can be thought of as the dummy variables in expressions such as integrals, sums, products, and the logical quantifiers for all and there exists. A bound variable is characterized by the property that systematically renaming the variable (to a name not already appearing in the expression) does not change the meaning of the expression.

4.2.6.1 Bindings
Schema Fragment (Strict) Schema Fragment (Full)
Class Bind Bind
Attributes CommonAtt CommonAtt, DefEncAtt
Content ContExp, BvarQ*, ContExp ContExp, BvarQ*, Qualifier*, ContExp+

Binding expressions are represented as MathML expression trees using the bind element. Its first child is a MathML expression that represents a binding operator, for example integral operator. This is followed by a non-empty list of bvar elements denoting the bound variables, and then the final child which is a general Content MathML expression, known as the body of the binding.

4.2.6.2 Bound Variables
Schema Fragment (Strict) Schema Fragment (Full)
Class BVar BVar
Attributes CommonAtt CommonAtt, DefEncAtt
Content ci | semantics-ci (ci | semantics-ci), degree? | degree?, (ci | semantics-ci)

The bvar element is used to denote the bound variable of a binding expression, e.g. in sums, products, and quantifiers or user defined functions.

The content of a bvar element is an annotated variable, i.e. either a content identifier represented by a ci element or a semantics element whose first child is an annotated variable. The name of an annotated variable of the second kind is the name of its first child. The name of a bound variable is that of the annotated variable in the bvar element.

Bound variables are identified by comparing their names. Such identification can be made explicit by placing an id on the ci element in the bvar element and referring to it using the xref attribute on all other instances. An example of this approach is

<bind><csymbol cd="quant1">forall</csymbol>
  <bvar><ci id="var-x">x</ci></bvar>
  <apply><csymbol cd="relation1">lt</csymbol>
    <ci xref="var-x">x</ci>
    <cn>1</cn>
  </apply>
</bind>

This id based approach is especially helpful when constructions involving bound variables are nested.

It is sometimes necessary to associate additional information with a bound variable. The information might be something like a detailed mathematical type, an alternative presentation or encoding or a domain of application. Such associations are accomplished in the standard way by replacing a ci element (even inside the bvar element) by a semantics element containing both the ci and the additional information. Recognition of an instance of the bound variable is still based on the actual ci elements and not the semantics elements or anything else they may contain. The id-based approach outlined above may still be used.

The following example encodes x.x+y=y+x.

<bind><csymbol cd="quant1">forall</csymbol>
  <bvar><ci>x</ci></bvar>
  <apply><csymbol cd="relation1">eq</csymbol>
    <apply><csymbol cd="arith1">plus</csymbol><ci>x</ci><ci>y</ci></apply>
    <apply><csymbol cd="arith1">plus</csymbol><ci>y</ci><ci>x</ci></apply>
  </apply>
</bind>

In non-Strict Content markup, the bvar element is used in a number of idiomatic constructs. These are described in 4.3.3 Qualifiers and 4.3 Content MathML for Specific Structures.

4.2.6.3 Renaming Bound Variables

It is a defining property of bound variables that they can be renamed consistently in the scope of their parent bind element. This operation, sometimes known as α-conversion, preserves the semantics of the expression.

A bound variable x may be renamed to say y so long as y does not occur free in the body of the binding, or in any annotations of the bound variable, x to be renamed, or later bound variables.

If a bound variable x is renamed, all free occurrences of x in annotations in its bvar element, any following bvar children of the bind and in the expression in the body of the bind should be renamed.

In the example in the previous section, note how renaming x to z produces the equivalent expression z.z+y=y+z, whereas x may not be renamed to y, as y is free in the body of the binding and would be captured, producing the expression y.y+y=y+y which is not equivalent to the original expression.

4.2.6.4 Rendering Binding Constructions

If <ci>b</ci> and <ci>s</ci> are Content MathML expressions that render as the Presentation MathML expressions <mi>B</mi> and <mi>S</mi> then the sample rendering of a binding element is as follows:

Content MathML

<bind><ci>b</ci>
  <bvar><ci>x1</ci></bvar>
  <bvar><ci>...</ci></bvar>
  <bvar><ci>xn</ci></bvar>
  <ci>s</ci>
</bind>

Sample Presentation

<mrow>
  <mi>B</mi>
  <mrow>
    <mi>x1</mi>
    <mo separator="true">,</mo>
    <mi>...</mi>
    <mo separator="true">,</mo>
    <mi>xn</mi>
  </mrow>
  <mo separator="true">.</mo>
  <mi>S</mi>
</mrow>
B x1 , ... , xn . S

4.2.7 Structure Sharing <share>

To conserve space in the XML encoding, MathML expression trees can make use of structure sharing.

4.2.7.1 The share element
Schema Fragment
Class Share
Attributes CommonAtt, src
src Attribute Values URI
Content Empty

The share element has an src attribute used to reference a MathML expression tree. The value of the src attribute is a URI specifying the id attribute of the root node of the expression tree. When building a MathML expression tree, the share element is equivalent to a copy of the MathML expression tree referenced by the src attribute. Note that this copy is structurally equal, but not identical to the element referenced. The values of the share will often be relative URI references, in which case they are resolved using the base URI of the document containing the share element.

For instance, the mathematical object f(f(f(a,a),f(a,a)),f(f(a,a),f(a,a))) can be encoded as either one of the following representations (and some intermediate versions as well).

<apply><ci>f</ci>
  <apply><ci>f</ci>
    <apply><ci>f</ci>
      <ci>a</ci>
      <ci>a</ci>
    </apply>
    <apply><ci>f</ci>
      <ci>a</ci>
      <ci>a</ci>
    </apply>
  </apply>
  <apply><ci>f</ci>
    <apply><ci>f</ci>
      <ci>a</ci>
      <ci>a</ci>
    </apply>
    <apply><ci>f</ci>
      <ci>a</ci>
      <ci>a</ci>
    </apply>
  </apply>
</apply>
<apply><ci>f</ci>
  <apply id="t1"><ci>f</ci>
    <apply id="t11"><ci>f</ci>
      <ci>a</ci>
      <ci>a</ci>
    </apply>
    <share src="#t11"/>



  </apply>
  <share src="#t1"/>









</apply>
4.2.7.2 An Acyclicity Constraint

Say that an element dominates all its children and all elements they dominate. Say also that a share element dominates its target, i.e. the element that carries the id attribute pointed to by the src attribute. For instance in the representation on the right above, the apply element with id="t1" and also the second share (with src="t11") both dominate the apply element with id="t11".

The occurrences of the share element must obey the following global acyclicity constraint: An element may not dominate itself. For example, the following representation violates this constraint:

<apply id="badid1"><csymbol cd="arith1">divide</csymbol>
  <cn>1</cn>
  <apply><csymbol cd="arith1">plus</csymbol>
    <cn>1</cn>
    <share src="#badid1"/>
  </apply>
</apply>

Here, the apply element with id="badid1" dominates its third child, which dominates the share element, which dominates its target: the element with id="badid1". So by transitivity, this element dominates itself. By the acyclicity constraint, the example is not a valid MathML expression tree. It might be argued that such an expression could be given the interpretation of the continued fraction 1/(1+1/(1+ . However, the procedure of building an expression tree by replacing share element does not terminate for such an expression, and hence such expressions are not allowed by Content MathML.

Note that the acyclicity constraint is not restricted to such simple cases, as the following example shows:

<apply id="bar">                        <apply id="baz">
  <csymbol cd="arith1">plus</csymbol>     <csymbol cd="arith1">plus</csymbol>
  <cn>1</cn>                              <cn>1</cn>
  <share src="#baz"/>                    <share src="#bar"/>
</apply>                                </apply>

Here, the apply with id="bar" dominates its third child, the share with src="#baz". That element dominates its target apply (with id="baz"), which in turn dominates its third child, the share with src="#bar". Finally, the share with src="#bar" dominates its target, the original apply element with id="bar". So this pair of representations ultimately violates the acyclicity constraint.

4.2.7.3 Structure Sharing and Binding

Note that the share element is a syntactic referencing mechanism: a share element stands for the exact element it points to. In particular, referencing does not interact with binding in a semantically intuitive way, since it allows a phenomenon called variable capture to occur. Consider an example:

<bind id="outer"><csymbol cd="fns1">lambda</csymbol>
  <bvar><ci>x</ci></bvar>
  <apply><ci>f</ci>
    <bind id="inner"><csymbol cd="fns1">lambda</csymbol>
      <bvar><ci>x</ci></bvar>
      <share id="copy" src="#orig"/>
    </bind>
    <apply id="orig"><ci>g</ci><ci>x</ci></apply>
  </apply>
</bind>

This represents a term λx. f( λx.g(x) , g(x) ) which has two sub-terms of the form g(x) , one with id="orig" (the one explicitly represented) and one with id="copy", represented by the share element. In the original, explicitly-represented term, the variable x is bound by the outer bind element. However, in the copy, the variable x is bound by the inner bind element. One says that the inner bind has captured the variable x.

Using references that capture variables in this way can easily lead to representation errors, and is not recommended. For instance, using α-conversion to rename the inner occurrence of x into, say, y leads to the semantically equivalent expression λx. f( λy.g(y) , g(x) ) . However, in this form, it is no longer possible to share the expression g(x) . Replacing x with y in the inner bvar without replacing the share element results in a change in semantics.

4.2.7.4 Rendering Expressions with Structure Sharing

There are several acceptable renderings for the share element. These include rendering the element as a hypertext link to the referenced element and using the rendering of the element referenced by the src attribute.

4.2.8 Attribution via semantics

Content elements can be annotated with additional information via the semantics element. MathML uses the semantics element to wrap the annotated element and the annotation-xml and annotation elements used for representing the annotations themselves. The use of the semantics, annotation and annotation-xml is described in detail in 6. Annotating MathML: semantics.

The semantics element is considered part of both presentation MathML and Content MathML. MathML considers a semantics element (strict) Content MathML, if and only if its first child is (strict) Content MathML.

4.2.9 Error Markup <cerror>

Schema Fragment (Strict) Schema Fragment (Full)
Class Error Error
Attributes CommonAtt CommonAtt, DefEncAtt
Content csymbol, ContExp* csymbol, ContExp*

A content error expression is made up of a csymbol followed by a sequence of zero or more MathML expressions. The initial expression must be a csymbol indicating the kind of error. Subsequent children, if present, indicate the context in which the error occurred.

The cerror element has no direct mathematical meaning. Errors occur as the result of some action performed on an expression tree and are thus of real interest only when some sort of communication is taking place. Errors may occur inside other objects and also inside other errors.

As an example, to encode a division by zero error, one might employ a hypothetical aritherror Content Dictionary containing a DivisionByZero symbol, as in the following expression:

<cerror>
  <csymbol cd="aritherror">DivisionByZero</csymbol>
  <apply><csymbol cd="arith1">divide</csymbol><ci>x</ci><cn>0</cn></apply>
</cerror>

Note that error markup generally should enclose only the smallest erroneous sub-expression. Thus a cerror will often be a sub-expression of a bigger one, e.g.

<apply><csymbol cd="relation1">eq</csymbol>
  <cerror>
    <csymbol cd="aritherror">DivisionByZero</csymbol>
    <apply><csymbol cd="arith1">divide</csymbol><ci>x</ci><cn>0</cn></apply>
  </cerror>
  <cn>0</cn>
</apply>

The default presentation of a cerror element is an merror expression whose first child is a presentation of the error symbol, and whose subsequent children are the default presentations of the remaining children of the cerror. In particular, if one of the remaining children of the cerror is a presentation MathML expression, it is used literally in the corresponding merror.

<cerror>
  <csymbol cd="aritherror">DivisionByZero</csymbol>
  <apply><csymbol cd="arith1">divide</csymbol><ci>x</ci><cn>0</cn></apply>
</cerror>

Sample Presentation

<merror>
  <mtext>DivisionByZero:&#160;</mtext>
  <mfrac><mi>x</mi><mn>0</mn></mfrac>
</merror>
DivisionByZero:  x0

Note that when the context where an error occurs is so nonsensical that its default presentation would not be useful, an application may provide an alternative representation of the error context. For example:

<cerror>
  <csymbol cd="error">Illegal bound variable</csymbol>
  <cs> &lt;bvar&gt;&lt;plus/&gt;&lt;/bvar&gt; </cs>
</cerror>

4.2.10 Encoded Bytes <cbytes>

Schema Fragment (Strict) Schema Fragment (Full)
Class Cbytes Cbytes
Attributes CommonAtt CommonAtt, DefEncAtt
Content base64 base64

The content of cbytes represents a stream of bytes as a sequence of characters in Base64 encoding, that is it matches the base64Binary data type defined in [XMLSchemaDatatypes]. All white space is ignored.

The cbytes element is mainly used for OpenMath compatibility, but may be used, as in OpenMath, to encapsulate output from a system that may be hard to encode in MathML, such as binary data relating to the internal state of a system, or image data.

The rendering of cbytes is not expected to represent the content and the proposed rendering is that of an empty mrow. Typically cbytes is used in an annotation-xml or is itself annotated with Presentation MathML, so this default rendering should rarely be used.

4.3 Content MathML for Specific Structures

The elements of Strict Content MathML described in the previous section are sufficient to encode logical assertions and expression structure, and they do so in a way that closely models the standard constructions of mathematical logic that underlie the foundations of mathematics. As a consequence, Strict markup can be used to represent all of mathematics, and is ideal for providing consistent mathematical semantics for all Content MathML expressions.

At the same time, many notational idioms of mathematics are not straightforward to represent directly with Strict Content markup. For example, standard notations for sums, integrals, sets, piecewise functions and many other common constructions require non-obvious technical devices, such as the introduction of lambda functions, to rigorously encode them using Strict markup. Consequently, in order to make Content MathML easier to use, a range of additional elements have been provided for encoding such idiomatic constructs more directly. This section discusses the general approach for encoding such idiomatic constructs, and their Strict Content equivalents. Specific constructions are discussed in detail in 4.3 Content MathML for Specific Structures.

Most idiomatic constructions which Content markup addresses fall into about a dozen classes. Some of these classes, such as container elements, have their own syntax. Similarly, a small number of non-Strict constructions involve a single element with an exceptional syntax, for example partialdiff. These exceptional elements are discussed on a case-by-case basis in 4.3 Content MathML for Specific Structures. However, the majority of constructs consist of classes of operator elements which all share a particular usage of qualifiers. These classes of operators are described in 4.3.4 Operator Classes.

In all cases, non-Strict expressions may be rewritten using only Strict markup. In most cases, the transformation is completely algorithmic, and may be automated. Rewrite rules for classes of non-Strict constructions are introduced and discussed later in this section, and rewrite rules for exceptional constructs involving a single operator are given in 4.3 Content MathML for Specific Structures. The complete algorithm for rewriting arbitrary Content MathML as Strict Content markup is summarized at the end of the Chapter in F. The Strict Content MathML Transformation.

4.3.1 Container Markup

Many mathematical structures are constructed from subparts or parameters. For example, a set is a mathematical object that contains a collection of elements, so it is natural for the markup for a set to contain the markup for its constituent elements. The markup for a set may define the set of elements explicitly by enumerating them, or implicitly by rule that uses qualifier elements. In either case, the markup for the elements is contained in the markup for the set, and this style of representation is called container markup in MathML. By contrast, Strict markup represents an instance of a set as the result of applying a function or constructor symbol to arguments. In this style of markup, the markup for the set construction is a sibling of the markup for the set elements in an enclosing apply element.

MathML provides container markup for the following mathematical constructs: sets, lists, intervals, vectors, matrices (two elements), piecewise functions (three elements) and lambda functions. There are corresponding constructor symbols in Strict markup for each of these, with the exception of lambda functions, which correspond to binding symbols in Strict markup.

The rewrite rules for obtaining equivalent Strict Content markup from container markup depend on the operator class of the particular operator involved. For details about a specific container element, obtain its operator class (and any applicable special case information) by consulting the syntax table and discussion for that element in E. The Content MathML Operators. Then apply the rewrite rules for that specific operator class as described in F. The Strict Content MathML Transformation.

4.3.1.1 Container Markup for Constructor Symbols

The arguments to container elements that correspond to constructors may be explicitly given as a sequence of child elements, or implicitly given by a rule using qualifiers. The exceptions are the interval, piecewise, piece, and otherwise elements. The arguments of these elements must be specified explicitly.

Here is an example of container markup with explicitly specified arguments:

<set><ci>a</ci><ci>b</ci><ci>c</ci></set>

This is equivalent to the following Strict Content MathML expression:

<apply><csymbol cd="set1">set</csymbol><ci>a</ci><ci>b</ci><ci>c</ci></apply>

Another example of container markup, where the list of arguments is given indirectly as an expression with a bound variable. The container markup for the set of even integers is:

<set>
  <bvar><ci>x</ci></bvar>
  <domainofapplication><integers/></domainofapplication>
  <apply><times/><cn>2</cn><ci>x</ci></apply>
</set>

This may be written as follows in Strict Content MathML:

<apply><csymbol cd="set1">map</csymbol>
  <bind><csymbol cd="fns1">lambda</csymbol>
    <bvar><ci>x</ci></bvar>
    <apply><csymbol cd="arith1">times</csymbol>
      <cn>2</cn>
      <ci>x</ci>
    </apply>
  </bind>
  <csymbol cd="setname1">Z</csymbol>
</apply>
4.3.1.2 Container Markup for Binding Constructors

The lambda element is a container element corresponding to the lambda symbol in the fns1 Content Dictionary. However, unlike the container elements of the preceding section, which purely construct mathematical objects from arguments, the lambda element performs variable binding as well. Therefore, the child elements of lambda have distinguished roles. In particular, a lambda element must have at least one bvar child, optionally followed by qualifier elements, followed by a Content MathML element. This basic difference between the lambda container and the other constructor container elements is also reflected in the OpenMath symbols to which they correspond. The constructor symbols have an OpenMath role of application, while the lambda symbol has a role of bind.

This example shows the use of lambda container element and the equivalent use of bind in Strict Content MathML

<lambda><bvar><ci>x</ci></bvar><ci>x</ci></lambda>
<bind><csymbol cd="fns1">lambda</csymbol>
  <bvar><ci>x</ci></bvar><ci>x</ci>
</bind>

4.3.2 Bindings with <apply>

MathML allows the use of the apply element to perform variable binding in non-Strict constructions instead of the bind element. This usage conserves backwards compatibility with MathML 2. It also simplifies the encoding of several constructs involving bound variables with qualifiers as described below.

Use of the apply element to bind variables is allowed in two situations. First, when the operator to be applied is itself a binding operator, the apply element merely substitutes for the bind element. The logical quantifiers <forall/>, <exists/> and the container element lambda are the primary examples of this type.

The second situation arises when the operator being applied allows the use of bound variables with qualifiers. The most common examples are sums and integrals. In most of these cases, the variable binding is to some extent implicit in the notation, and the equivalent Strict representation requires the introduction of auxiliary constructs such as lambda expressions for formal correctness.

Because expressions using bound variables with qualifiers are idiomatic in nature, and do not always involve true variable binding, one cannot expect systematic renaming (alpha-conversion) of variables bound with apply to preserve meaning in all cases. An example for this is the diff element where the bvar term is technically not bound at all.

The following example illustrates the use of apply with a binding operator. In these cases, the corresponding Strict equivalent merely replaces the apply element with a bind element:

<apply><forall/>
  <bvar><ci>x</ci></bvar>
  <apply><geq/><ci>x</ci><ci>x</ci></apply>
</apply>

The equivalent Strict expression is:

<bind><csymbol cd="logic1">forall</csymbol>
  <bvar><ci>x</ci></bvar>
  <apply><csymbol cd="relation1">geq</csymbol><ci>x</ci><ci>x</ci></apply>
</bind>

In this example, the sum operator is not itself a binding operator, but bound variables with qualifiers are implicit in the standard notation, which is reflected in the non-Strict markup. In the equivalent Strict representation, it is necessary to convert the summand into a lambda expression, and recast the qualifiers as an argument expression:

<apply><sum/>
  <bvar><ci>i</ci></bvar>
  <lowlimit><cn>0</cn></lowlimit>
  <uplimit><cn>100</cn></uplimit>
  <apply><power/><ci>x</ci><ci>i</ci></apply>
</apply>

The equivalent Strict expression is:

<apply><csymbol cd="arith1">sum</csymbol>
  <apply><csymbol cd="interval1">integer_interval</csymbol>
    <cn>0</cn>
    <cn>100</cn>
  </apply>
  <bind><csymbol cd="fns1">lambda</csymbol>
    <bvar><ci>i</ci></bvar>
    <apply><csymbol cd="arith1">power</csymbol>
      <ci>x</ci>
      <ci>i</ci>
    </apply>
  </bind>
</apply>

4.3.3 Qualifiers

Many common mathematical constructs involve an operator together with some additional data. The additional data is either implicit in conventional notation, such as a bound variable, or thought of as part of the operator, as is the case with the limits of a definite integral. MathML 3 uses qualifier elements to represent the additional data in such cases.

Qualifier elements are always used in conjunction with operator or container elements. Their meaning is idiomatic, and depends on the context in which they are used. When used with an operator, qualifiers always follow the operator and precede any arguments that are present. In all cases, if more than one qualifier is present, they appear in the order bvar, lowlimit, uplimit, interval, condition, domainofapplication, degree, momentabout, logbase.

The precise function of qualifier elements depends on the operator or container that they modify. The majority of use cases fall into one of several categories, discussed below, and usage notes for specific operators and qualifiers are given in 4.3 Content MathML for Specific Structures.

4.3.3.1 Uses of <domainofapplication>, <interval>, <condition>, <lowlimit> and <uplimit>
Class qualifier
Attributes CommonAtt
Content ContExp

(For the syntax of interval see 4.3.10.3 Interval <interval>.)

The primary use of domainofapplication, interval, uplimit, lowlimit and condition is to restrict the values of a bound variable. The most general qualifier is domainofapplication. It is used to specify a set (perhaps with additional structure, such as an ordering or metric) over which an operation is to take place. The interval qualifier, and the pair lowlimit and uplimit also restrict a bound variable to a set in the special case where the set is an interval. Note that interval is only interpreted as a qualifier if it immediately follows bvar. The condition qualifier, like domainofapplication, is general, and can be used to restrict bound variables to arbitrary sets. However, unlike the other qualifiers, it restricts the bound variable by specifying a Boolean-valued function of the bound variable. Thus, condition qualifiers always contain instances of the bound variable, and thus require a preceding bvar, while the other qualifiers do not. The other qualifiers may even be used when no variables are being bound, e.g. to indicate the restriction of a function to a subdomain.

In most cases, any of the qualifiers capable of representing the domain of interest can be used interchangeably. The most general qualifier is domainofapplication, and therefore has a privileged role. It is the preferred form, unless there are particular idiomatic reasons to use one of the other qualifiers, e.g. limits for an integral. In MathML 3, the other forms are treated as shorthand notations for domainofapplication because they may all be rewritten as equivalent domainofapplication constructions. The rewrite rules to do this are given below. The other qualifier elements are provided because they correspond to common notations and map more easily to familiar presentations. Therefore, in the situations where they naturally arise, they may be more convenient and direct than domainofapplication.

To illustrate these ideas, consider the following examples showing alternative representations of a definite integral. Let C denote the interval from 0 to 1, and f(x) = x2. Then domainofapplication could be used to express the integral of a function f over C in this way:

<apply><int/>
  <domainofapplication>
    <ci type="set">C</ci>
  </domainofapplication>
  <ci type="function">f</ci>
</apply>

Note that no explicit bound variable is identified in this encoding, and the integrand is a function. Alternatively, the interval qualifier could be used with an explicit bound variable:

<apply><int/>
  <bvar><ci>x</ci></bvar>
  <interval><cn>0</cn><cn>1</cn></interval>
  <apply><power/><ci>x</ci><cn>2</cn></apply>
</apply>

The pair lowlimit and uplimit can also be used. This is perhaps the most standard representation of this integral:

<apply><int/>
  <bvar><ci>x</ci></bvar>
  <lowlimit><cn>0</cn></lowlimit>
  <uplimit><cn>1</cn></uplimit>
  <apply><power/><ci>x</ci><cn>2</cn></apply>
</apply>

Finally, here is the same integral, represented using a condition on the bound variable:

<apply><int/>
  <bvar><ci>x</ci></bvar>
  <condition>
    <apply><and/>
      <apply><leq/><cn>0</cn><ci>x</ci></apply>
      <apply><leq/><ci>x</ci><cn>1</cn></apply>
    </apply>
  </condition>
  <apply><power/><ci>x</ci><cn>2</cn></apply>
</apply>

Note the use of the explicit bound variable within the condition term. Note also that when a bound variable is used, the integrand is an expression in the bound variable, not a function.

The general technique of using a condition element together with domainofapplication is quite powerful. For example, to extend the previous example to a multivariate domain, one may use an extra bound variable and a domain of application corresponding to a cartesian product:

<apply><int/>
  <bvar><ci>x</ci></bvar>
  <bvar><ci>y</ci></bvar>
  <domainofapplication>
    <set>
      <bvar><ci>t</ci></bvar>
      <bvar><ci>u</ci></bvar>
      <condition>
        <apply><and/>
          <apply><leq/><cn>0</cn><ci>t</ci></apply>
          <apply><leq/><ci>t</ci><cn>1</cn></apply>
          <apply><leq/><cn>0</cn><ci>u</ci></apply>
          <apply><leq/><ci>u</ci><cn>1</cn></apply>
        </apply>
      </condition>
      <list><ci>t</ci><ci>u</ci></list>
    </set>
  </domainofapplication>
  <apply><times/>
    <apply><power/><ci>x</ci><cn>2</cn></apply>
    <apply><power/><ci>y</ci><cn>3</cn></apply>
  </apply>
</apply>

Note that the order of the inner and outer bound variables is significant.

4.3.3.2 Uses of <degree>
Class qualifier
Attributes CommonAtt
Content ContExp

The degree element is a qualifier used to specify the degree or order of an operation. MathML uses the degree element in this way in three contexts: to specify the degree of a root, a moment, and in various derivatives. Rather than introduce special elements for each of these families, MathML provides a single general construct, the degree element in all three cases.

Note that the degree qualifier is not used to restrict a bound variable in the same sense of the qualifiers discussed above. Indeed, with roots and moments, no bound variable is involved at all, either explicitly or implicitly. In the case of differentiation, the degree element is used in conjunction with a bvar, but even in these cases, the variable may not be genuinely bound.

For the usage of degree with the root and moment operators, see the discussion of those operators below. The usage of degree in differentiation is more complex. In general, the degree element indicates the order of the derivative with respect to that variable. The degree element is allowed as the second child of a bvar element identifying a variable with respect to which the derivative is being taken. Here is an example of a second derivative using the degree qualifier:

<apply><diff/>
  <bvar>
    <ci>x</ci>
    <degree><cn>2</cn></degree>
  </bvar>
  <apply><power/><ci>x</ci><cn>4</cn></apply>
</apply>

For details see 4.3.8.2 Differentiation <diff/> and 4.3.8.3 Partial Differentiation <partialdiff/>.

4.3.3.3 Uses of <momentabout> and <logbase>

The qualifiers momentabout and logbase are specialized elements specifically for use with the moment and log operators respectively. See the descriptions of those operators below for their usage.

4.3.4 Operator Classes

The Content MathML elements described in detail in the following sections may be broadly separated into classes. The class of each element is listed in the operator syntax table given in E.3 The Content MathML Operators. The class gives an indication of the general intended mathematical usage of the element, and also determines its usage as determined by the schema. Links to the operator syntax and schema class for each element are provided in the sections that introduce the elements.

The operator class also determines the applicable rewrite rules for mapping to Strict Content MathML. These rewrite rules are presented in detail in F. The Strict Content MathML Transformation. They include use cases applicable to specific operator classes, special-case rewrite rules for individual elements, and a generic rewrite rule F.8 Rewrite operators used by operators from almost all operator classes.

The following sections present elements representing a core set of mathematical operators, functions and constants. Most are empty elements, covering the subject matter of standard mathematics curricula up to the level of calculus. The remaining elements are container elements for sets, intervals, vectors and so on. For brevity, all elements defined in this section are sometimes called operator elements.

4.3.5 N-ary Operators

Many MathML operators may be used with an arbitrary number of arguments. The corresponding OpenMath symbols for elements in these classes also take an arbitrary number of arguments. In all such cases, either the arguments may be given explicitly as children of the apply or bind element, or the list may be specified implicitly via the use of qualifier elements.

4.3.5.1 N-ary Arithmetic Operators: <plus/>, <times/>, <gcd/>, <lcm/>

Operator Syntax, Schema Class

The plus and times elements represent the addition and multiplication operators. The arguments are normally specified explicitly in the enclosing apply element. As an n-ary commutative operator, they can be used with qualifiers to specify arguments, however, this is discouraged, and the sum or product operators should be used to represent such expressions instead.

4.3.5.1.1 Example

Content MathML

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

Sample Presentation

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

The gcd and lcm elements represent the n-ary operators which return the greatest common divisor, or least common multiple of their arguments. The arguments may be explicitly specified in the enclosing apply element, or specified by quantifiers.

This default renderings are English-language locale specific: other locales may have different default renderings.

4.3.5.1.2 Example

Content MathML

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

Sample Presentation

<mrow>
  <mi>gcd</mi>
  <mo>&#x2061;<!--ApplyFunction--></mo>
  <mrow><mo>(</mo><mi>a</mi><mo>,</mo><mi>b</mi><mo>,</mo><mi>c</mi><mo>)</mo></mrow>
</mrow>
gcd (a,b,c)
4.3.5.2 N-ary Sum <sum/>

Operator Syntax, Schema Class

The sum element represents the n-ary addition operator. The terms of the sum are normally specified by rule through the use of qualifiers. While it can be used with an explicit list of arguments, this is strongly discouraged, and the plus operator should be used instead in such situations.

The sum operator may be used either with or without explicit bound variables. When a bound variable is used, the sum element is followed by one or more bvar elements giving the index variables, followed by qualifiers giving the domain for the index variables. The final child in the enclosing apply is then an expression in the bound variables, and the terms of the sum are obtained by evaluating this expression at each point of the domain of the index variables. Depending on the structure of the domain, the domain of summation is often given by using uplimit and lowlimit to specify upper and lower limits for the sum.

When no bound variables are explicitly given, the final child of the enclosing apply element must be a function, and the terms of the sum are obtained by evaluating the function at each point of the domain specified by qualifiers.

4.3.5.2.1 Examples

Content MathML

<apply><sum/>
  <bvar><ci>x</ci></bvar>
  <lowlimit><ci>a</ci></lowlimit>
  <uplimit><ci>b</ci></uplimit>
  <apply><ci>f</ci><ci>x</ci></apply>
</apply>
<apply><sum/>
  <bvar><ci>x</ci></bvar>
  <condition>
    <apply><in/><ci>x</ci><ci type="set">B</ci></apply>
  </condition>
  <apply><ci type="function">f</ci><ci>x</ci></apply>
</apply>
<apply><sum/>
  <domainofapplication>
    <ci type="set">B</ci>
  </domainofapplication>
  <ci type="function">f</ci>
</apply>

Sample Presentation

<mrow>
  <munderover>
    <mo></mo>
    <mrow><mi>x</mi><mo>=</mo><mi>a</mi></mrow>
    <mi>b</mi>
  </munderover>
  <mrow><mi>f</mi><mo>&#x2061;<!--ApplyFunction--></mo><mrow><mo>(</mo><mi>x</mi><mo>)</mo></mrow></mrow>
</mrow>
x=a b f(x)
<mrow>
  <munder>
    <mo></mo>
    <mrow><mi>x</mi><mo></mo><mi>B</mi></mrow>
  </munder>
  <mrow><mi>f</mi><mo>&#x2061;<!--ApplyFunction--></mo><mrow><mo>(</mo><mi>x</mi><mo>)</mo></mrow></mrow>
</mrow>
xB f(x)
<mrow><munder><mo></mo><mi>B</mi></munder><mi>f</mi></mrow>
Bf
4.3.5.3 N-ary Product <product/>

Operator Syntax, Schema Class

The product element represents the n-ary multiplication operator. The terms of the product are normally specified by rule through the use of qualifiers. While it can be used with an explicit list of arguments, this is strongly discouraged, and the times operator should be used instead in such situations.

The product operator may be used either with or without explicit bound variables. When a bound variable is used, the product element is followed by one or more bvar elements giving the index variables, followed by qualifiers giving the domain for the index variables. The final child in the enclosing apply is then an expression in the bound variables, and the terms of the product are obtained by evaluating this expression at each point of the domain. Depending on the structure of the domain, it is commonly given using uplimit and lowlimit qualifiers.

When no bound variables are explicitly given, the final child of the enclosing apply element must be a function, and the terms of the product are obtained by evaluating the function at each point of the domain specified by qualifiers.

4.3.5.3.1 Examples

Content MathML

<apply><product/>
  <bvar><ci>x</ci></bvar>
  <lowlimit><ci>a</ci></lowlimit>
  <uplimit><ci>b</ci></uplimit>
  <apply><ci type="function">f</ci>
    <ci>x</ci>
  </apply>
</apply>
<apply><product/>
  <bvar><ci>x</ci></bvar>
  <condition>
    <apply><in/>
      <ci>x</ci>
      <ci type="set">B</ci>
    </apply>
  </condition>
  <apply><ci>f</ci><ci>x</ci></apply>
</apply>

Sample Presentation

<mrow>
  <munderover>
    <mo></mo>
    <mrow><mi>x</mi><mo>=</mo><mi>a</mi></mrow>
    <mi>b</mi>
  </munderover>
  <mrow><mi>f</mi><mo>&#x2061;<!--ApplyFunction--></mo><mrow><mo>(</mo><mi>x</mi><mo>)</mo></mrow></mrow>
</mrow>
x=a b f(x)
<mrow>
  <munder>
    <mo></mo>
    <mrow><mi>x</mi><mo></mo><mi>B</mi></mrow>
  </munder>
  <mrow><mi>f</mi><mo>&#x2061;<!--ApplyFunction--></mo><mrow><mo>(</mo><mi>x</mi><mo>)</mo></mrow></mrow>
</mrow>
xB f(x)
4.3.5.4 N-ary Functional Operators: <compose/>

Operator Syntax, Schema Class

The compose element represents the function composition operator. Note that MathML makes no assumption about the domain and codomain of the constituent functions in a composition; the domain of the resulting composition may be empty.

The compose element is a commutative n-ary operator. Consequently, it may be lifted to the induced operator defined on a collection of arguments indexed by a (possibly infinite) set by using qualifier elements as described in 4.3.5.4 N-ary Functional Operators: <compose/>.

4.3.5.4.1 Examples

Content MathML

<apply><compose/><ci>f</ci><ci>g</ci><ci>h</ci></apply>
<apply><eq/>
  <apply>
    <apply><compose/><ci>f</ci><ci>g</ci></apply>
    <ci>x</ci>
  </apply>
  <apply><ci>f</ci><apply><ci>g</ci><ci>x</ci></apply></apply>
</apply>

Sample Presentation

<mrow>
  <mi>f</mi><mo></mo><mi>g</mi><mo></mo><mi>h</mi>
</mrow>
fgh
<mrow>
  <mrow>
    <mrow><mo>(</mo><mi>f</mi><mo></mo><mi>g</mi><mo>)</mo></mrow>
    <mo>&#x2061;<!--ApplyFunction--></mo>
    <mrow><mo>(</mo><mi>x</mi><mo>)</mo></mrow>
  </mrow>
  <mo>=</mo>
  <mrow>
    <mi>f</mi>
    <mo>&#x2061;<!--ApplyFunction--></mo>
    <mrow>
     <mo>(</mo>
      <mrow>
        <mi>g</mi>
        <mo>&#x2061;<!--ApplyFunction--></mo>
        <mrow><mo>(</mo><mi>x</mi><mo>)</mo></mrow>
      </mrow>
      <mo>)</mo>
    </mrow>
  </mrow>
</mrow>
(fg) (x) = f ( g (x) )
4.3.5.5 N-ary Logical Operators: <and/>, <or/>, <xor/>

Operator Syntax, Schema Class

These elements represent n-ary functions taking Boolean arguments and returning a Boolean value. The arguments may be explicitly specified in the enclosing apply element, or specified via qualifier elements.

and is true if all arguments are true, and false otherwise.
or is true if any of the arguments are true, and false otherwise.
xor is the logical exclusive or function. It is true if there are an odd number of true arguments or false otherwise.

4.3.5.5.1 Examples

Content MathML

<apply><and/><ci>a</ci><ci>b</ci></apply>
<apply><and/>
  <bvar><ci>i</ci></bvar>
  <lowlimit><cn>0</cn></lowlimit>
  <uplimit><ci>n</ci></uplimit>
  <apply><gt/><apply><selector/><ci>a</ci><ci>i</ci></apply><cn>0</cn></apply>
</apply>

Strict Content MathML

<apply><csymbol cd="logic1">and</csymbol><ci>a</ci><ci>b</ci></apply>
<apply><csymbol cd="fns2">apply_to_list</csymbol>
  <csymbol cd="logic1">and</csymbol>
  <apply><csymbol cd="list1">map</csymbol>
    <bind><csymbol cd="fns1">lambda</csymbol>
      <bvar><ci>i</ci></bvar>
      <apply><csymbol cd="relation1">gt</csymbol>
        <apply><csymbol cd="linalg1">vector_selector</csymbol>
          <ci>i</ci>
          <ci>a</ci>
        </apply>
        <cn>0</cn>
      </apply>
    </bind>
    <apply><csymbol cd="interval1">integer_interval</csymbol>
      <cn type="integer">0</cn>
      <ci>n</ci>
    </apply>
  </apply>
</apply>

Sample Presentation

<mrow><mi>a</mi><mo></mo><mi>b</mi></mrow>
ab
<mrow>
  <munderover>
    <mo></mo>
    <mrow><mi>i</mi><mo>=</mo><mn>0</mn></mrow>
    <mi>n</mi>
  </munderover>
  <mrow>
    <mo>(</mo>
    <msub><mi>a</mi><mi>i</mi></msub>
    <mo>&gt;</mo>
    <mn>0</mn>
    <mo>)</mo>
  </mrow>
</mrow>
i=0 n ( ai > 0 )
4.3.5.6 N-ary Linear Algebra Operators: <selector/>

Operator Syntax, Schema Class

The selector element is the operator for indexing into vectors, matrices and lists. It accepts one or more arguments. The first argument identifies the vector, matrix or list from which the selection is taking place, and the second and subsequent arguments, if any, indicate the kind of selection taking place.

When selector is used with a single argument, it should be interpreted as giving the sequence of all elements in the list, vector or matrix given. The ordering of elements in the sequence for a matrix is understood to be first by column, then by row; so the resulting list is of matrix rows given entry by entry. That is, for a matrix (ai,j), where the indices denote row and column, respectively, the ordering would be a1,1, a1,2, …, a2,1, a2,2, … etc.

When two arguments are given, and the first is a vector or list, the second argument specifies the index of an entry in the list or vector. If the first argument is a matrix then the second argument specifies the index of a matrix row.

When three arguments are given, the last one is ignored for a list or vector, and in the case of a matrix, the second and third arguments specify the row and column indices of the selected element.

4.3.5.6.1 Examples

Content MathML

<apply><selector/><ci type="vector">V</ci><cn>1</cn></apply>
<apply><eq/>
  <apply><selector/>
    <matrix>
      <matrixrow><cn>1</cn><cn>2</cn></matrixrow>
      <matrixrow><cn>3</cn><cn>4</cn></matrixrow>
    </matrix>
    <cn>1</cn>
  </apply>
  <matrix>
    <matrixrow><cn>1</cn><cn>2</cn></matrixrow>
  </matrix>
</apply>

Sample Presentation

<msub><mi>V</mi><mn>1</mn></msub>
V1
<mrow>
  <msub>
    <mrow>
      <mo>(</mo>
      <mtable>
        <mtr><mtd><mn>1</mn></mtd><mtd><mn>2</mn></mtd></mtr>
        <mtr><mtd><mn>3</mn></mtd><mtd><mn>4</mn></mtd></mtr>
      </mtable>
      <mo>)</mo>
    </mrow>
    <mn>1</mn>
  </msub>
  <mo>=</mo>
  <mrow>
    <mo>(</mo>
    <mtable><mtr><mtd><mn>1</mn></mtd><mtd><mn>2</mn></mtd></mtr></mtable>
    <mo>)</mo>
  </mrow>
</mrow>
( 12 34 ) 1 = ( 12 )
4.3.5.7 N-ary Set Operators: <union/>, <intersect/>, <cartesianproduct/>

Operator Syntax, Schema Class

The union element is used to denote the n-ary union of sets. It takes sets as arguments, and denotes the set that contains all the elements that occur in any of them.

The intersect element is used to denote the n-ary union of sets. It takes sets as arguments, and denotes the set that contains all the elements that occur in all of them.

The cartesianproduct element is used to represent the Cartesian product operator.

Arguments may be explicitly specified in the enclosing apply element, or specified using qualifier elements as described in 4.3.5 N-ary Operators.

4.3.5.7.1 Examples

Content MathML

<apply><union/><ci>A</ci><ci>B</ci></apply>
<apply><intersect/><ci>A</ci><ci>B</ci><ci>C</ci></apply>
<apply><cartesianproduct/><ci>A</ci><ci>B</ci></apply>

Sample Presentation

<mrow><mi>A</mi><mo></mo><mi>B</mi></mrow>
AB
<mrow><mi>A</mi><mo></mo><mi>B</mi><mo></mo><mi>C</mi></mrow>
ABC
<mrow><mi>A</mi><mo>×</mo><mi>B</mi></mrow>
A×B
4.3.5.7.2 Examples (Qualifiers)

Content MathML

<apply><union/>
  <bvar><ci type="set">S</ci></bvar>
  <domainofapplication>
    <ci type="list">L</ci>
  </domainofapplication>
  <ci type="set"> S</ci>
</apply>
<apply><intersect/>
  <bvar><ci type="set">S</ci></bvar>
  <domainofapplication>
    <ci type="list">L</ci>
  </domainofapplication>
  <ci type="set"> S</ci>
</apply>

Sample Presentation

<mrow><munder><mo></mo><mi>L</mi></munder><mi>S</mi></mrow>
LS
<mrow><munder><mo></mo><mi>L</mi></munder><mi>S</mi></mrow>
LS
4.3.5.8 N-ary Matrix Constructors: <vector/>, <matrix/>, <matrixrow/>

Operator Syntax, Schema Class

A vector is an ordered n-tuple of values representing an element of an n-dimensional vector space.

For purposes of interaction with matrices and matrix multiplication, vectors are regarded as equivalent to a matrix consisting of a single column, and the transpose of a vector as a matrix consisting of a single row.

The components of a vector may be given explicitly as child elements, or specified by rule as described in 4.3.1.1 Container Markup for Constructor Symbols.

4.3.5.8.1 Examples

Content MathML

<vector>
  <apply><plus/><ci>x</ci><ci>y</ci></apply>
  <cn>3</cn>
  <cn>7</cn>
</vector>

Sample Presentation

<mrow>
  <mo>(</mo>
  <mtable>
    <mtr><mtd><mrow><mi>x</mi><mo>+</mo><mi>y</mi></mrow></mtd></mtr>
    <mtr><mtd><mn>3</mn></mtd></mtr>
    <mtr><mtd><mn>7</mn></mtd></mtr>
  </mtable>
  <mo>)</mo>
</mrow>
( x+y 3 7 )
<mrow>
  <mo>(</mo>
  <mrow><mi>x</mi><mo>+</mo><mi>y</mi></mrow>
  <mo>,</mo>
  <mn>3</mn>
  <mo>,</mo>
  <mn>7</mn>
  <mo>)</mo>
</mrow>
( x+y , 3 , 7 )

A matrix is regarded as made up of matrix rows, each of which can be thought of as a special type of vector.

Note that the behavior of the matrix and matrixrow elements is substantially different from the mtable and mtr presentation elements.

The matrix element is a constructor element, so the entries may be given explicitly as child elements, or specified by rule as described in 4.3.1.1 Container Markup for Constructor Symbols. In the latter case, the entries are specified by providing a function and a 2-dimensional domain of application. The entries of the matrix correspond to the values obtained by evaluating the function at the points of the domain.

Matrix rows are not directly rendered by themselves outside of the context of a matrix.

4.3.5.8.2 Example

Content MathML

<matrix>
  <bvar><ci type="integer">i</ci></bvar>
  <bvar><ci type="integer">j</ci></bvar>
  <condition>
    <apply><and/>
      <apply><in/>
        <ci>i</ci>
        <interval><ci>1</ci><ci>5</ci></interval>
      </apply>
      <apply><in/>
        <ci>j</ci>
        <interval><ci>5</ci><ci>9</ci></interval>
      </apply>
    </apply>
  </condition>
  <apply><power/><ci>i</ci><ci>j</ci></apply>
</matrix>

Sample Presentation

<mrow>
  <mo>[</mo>
  <msub><mi>m</mi><mrow><mi>i</mi><mo>,</mo><mi>j</mi></mrow></msub>
  <mo>|</mo>
  <mrow>
    <msub><mi>m</mi><mrow><mi>i</mi><mo>,</mo><mi>j</mi></mrow></msub>
    <mo>=</mo>
    <msup><mi>i</mi><mi>j</mi></msup>
  </mrow>
  <mo>;</mo>
  <mrow>
    <mrow>
      <mi>i</mi>
      <mo></mo>
      <mrow><mo>[</mo><mi>1</mi><mo>,</mo><mi>5</mi><mo>]</mo></mrow>
    </mrow>
    <mo></mo>
    <mrow>
      <mi>j</mi>
      <mo></mo>
      <mrow><mo>[</mo><mi>5</mi><mo>,</mo><mi>9</mi><mo>]</mo></mrow>
    </mrow>
  </mrow>
  <mo>]</mo>
</mrow>
[ mi,j | mi,j = ij ; i [1,5] j [5,9] ]
4.3.5.9 N-ary Set Theoretic Constructors: <set>, <list>

Operator Syntax, Schema Class

The set element represents the n-ary function which constructs a mathematical set from its arguments. The set element takes the attribute type which may have the values set and multiset. The members of the set to be constructed may be given explicitly as child elements of the constructor, or specified by rule as described in 4.3.1.1 Container Markup for Constructor Symbols. There is no implied ordering to the elements of a set.

The list element represents the n-ary function which constructs a list from its arguments. Lists differ from sets in that there is an explicit order to the elements. The list element takes the attribute order which may have the values numeric and lexicographic. The list entries and order may be given explicitly or specified by rule as described in 4.3.1.1 Container Markup for Constructor Symbols.