The presentation of this document has been augmented to
use HTML5 rather than HTML4, and to include all MathML
examples as inlined MathML markup that should be rendered by
a MathML enabled browser. The MathML examples that have
been added, and which should be displayed in your browser,
are marked like this.

Note:Most symbol characters in examples may be shown in one of three forms:
Entity reference (&sum;),
Numeric character reference (&#x2211;)
or as the character data directly (∑).
By default, numeric references are used but you may alter the display by selecting an appropriate button below:Entity Reference Numeric Character Reference Character

Note:
Your browser may be able to display Presentation MathML but not Content MathML.
You may convert the inline Content MathML to a Presentation MathML rendering using an XSLT transfomation.

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
[HTML5] specifies the syntax for MathML in HTML. Unless explictly 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. Other documents may supersede this document. A
list of current W3C publications and the latest revision of this
technical report can be found in the W3C technical reports index at
http://www.w3.org/TR/.

Publication as a Proposed Edited Recommendation does not imply endorsement by the W3C Membership. 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.

W3C asks members of the Advisory Committee to review this document
and fill in the
review form. The deadline for this is 11 March 2014. The document did not
undergo Candidate Recommendation review, because no normative changes were made other
than minor fixes to reported problems with the MathML schema. All reported errata to
the first edition have been addressed in this addition, and a full change log appears in
Appendix F Changes. The diff-marked version linked in the frontmatter highlights all changes between the first and second editions. In addition
to incorporating errata, the main change in this addition is to recognise that MathML parsing is also specified in [HTML5] and where necessary to note where HTML and XML usage differ.

The Working Group maintains a comprehensive
Test Suite. This
is publicly available and developers are encouraged to submit their results for display.
The Test Results
are public. They show at least two interoperable implementations for each
essential test. Further details may be found in the
Implementation Report.

Closely associated with the MathML 3.0 specification is
A MathML for CSS Profile
which was simultaneously published as a Recommendation. This
describes a profile of MathML 3.0 that can be well formatted with Cascading Style Sheets. No revision of the CSS Profile
is being made.

The MathML 2.0 (Second Edition) specification has been a W3C
Recommendation since 2001. After its
recommendation, a W3C Math Interest Group collected
reports of experience
with the deployment of MathML and identified issues with MathML that
might be ameliorated. The rechartering of a Math Working Group
did not signal any change in the overall design of MathML.
The major additions in MathML 3 are support for
bidirectional layout, better linebreaking and explicit positioning,
elementary math notations, and a new strict content MathML vocabulary
with well-defined semantics. The MathML 3 Specification has also been
restructured.

The basic chapter structure of this document is based on the earlier
MathML 2.0 Recommendation [MathML2]. That MathML 2.0
itself was a revision of the earlier W3C Recommendation MathML 1.01
[MathML1]; MathML 3.0 is a revision of the W3C
Recommendation MathML 2.0. It differs from it in that all previous
chapters have been updated, some new
elements and attributes added and some
deprecated.
Much has been moved to separate documents containing explanatory
material, material on characters and entities and on the MathML DOM.
The discussion of character entities has led to the document
XML Entity Definitions for Characters[Entities],
which is now a W3C Recommendation. The concern with
use of CSS with MathML has led to the document A MathML for CSS Profile[MathMLforCSS], which was a W3C Recommendation
accompanying MathML 3.0.

The biggest differences from MathML 2.0 (Second Edition) are in Chapters 4 and 5, although there have been
smaller improvements throughout the specification. A more detailed
description of changes from the previous Recommendation follows.

Much of the non-normative explication
that formerly was found in Chapters 1 and 2, and many examples from
elsewhere in the previous MathML specifications, were removed
from the MathML3 specification and planned to be incorporated into a MathML Primer
to be prepared as a separate document. It is expected this will help
the use of this formal MathML3 specification as a reference document
in implementations, and offer the new user better help in
understanding MathML's deployment. The remaining content of Chapters 1
and 2 has been edited to reflect the changes elsewhere in the
document, and in the rapidly evolving Web environment. Some of the
text in them went back to early days of the Web and XML, and its
explanations are now commonplace.

Chapter 3, on presentation-oriented markup, adds new material on linebreaking,
and on markup for elementary math notations used in many
countries (mstack, mlongdiv and other
associated elements). Other changes include revisions to
the mglyph, mpadded and maction
elements and significant unification and cleanup of attribute
values.
Earlier work, as recorded in the W3C Note Arabic
mathematical notation, has allowed clarification of the
relationship with bidirectional text and examples
with RTL text have been added.

Chapter 4, on content-oriented markup, contains major changes and additions.
The meaning of the actual content remains as before in principle,
but a lot of work has been done on expressing it better. A few new elements have been added.

Chapter 5 has been refined as its purpose has been further
clarified to deal with the mixing of markup languages. This chapter deals,
in particular, with interrelations of parts of the
MathML specification, especially with presentation and content
markup.

Chapter 6 is a new addition which deals with the issues of interaction
of MathML with a host environment. This chapter deals with interrelations
of the MathML specification with XML and HTML, but in the context of deployment
on the Web. In particular there is a discussion of the interaction of CSS
with MathML.

Chapter 7 replaces the previous Chapter 6, and has been rewritten
and reorganized to reflect the new
situation in regard to Unicode, and the changed
W3C context with regard to named character entities. The
new W3C specification XML Entity Definitions for
Characters, which incorporates those used for mathematics has
become a a W3C Recommendation, [Entities].

The Appendices, of which there are eight shown, have been
reworked.
Appendix A now contains the new RelaxNG schema
for MathML3 as well as discussion of MathML3 DTD issues.
Appendix B addresses media types associated with MathML and
implicitly constitutes a request for the registration of three new ones,
as is now standard for work from the W3C.
Appendix C contains a new simplified and reconsidered Operator Dictionary.
Appendices D, E, F, G and H contain similar non-normative material to
that in the previous specification, now appropriately updated.

1 Introduction

1.1 Mathematics and its Notation

A distinguishing feature of mathematics is the use of a complex and
highly evolved system of two-dimensional symbolic notation. As
J. R. Pierce writes in his book on communication theory,
mathematics and its notation should not be viewed as one and the same
thing [Pierce1961]. Mathematical ideas can exist independently of
the notation that represents them. However, the relation between meaning
and notation is subtle, and part of the power of mathematics to describe
and analyze derives from its ability to represent and manipulate ideas in
symbolic form. The challenge before a Mathematical Markup Language (MathML)
in enabling mathematics on the World Wide Web
is to capture both notation and content (that is, its meaning) in such a way
that documents can utilize the highly evolved notation of written
and printed mathematics as well as the new potential for interconnectivity in
electronic media.

Mathematical notation evolves constantly as people continue
to innovate in ways of approaching and expressing ideas. Even
the common notation of arithmetic has gone through an amazing
variety of styles, including many defunct ones advocated by leading
mathematical figures of their day [Cajori1928]. Modern
mathematical notation is the product of centuries of refinement, and
the notational conventions for high-quality typesetting are quite
complicated and subtle. For example, variables and letters which stand for
numbers are usually typeset today in a special mathematical italic
font subtly distinct from the usual text italic; this seems to have been
introduced in Europe in the late sixteenth century. Spacing around
symbols for operations such as +, -, × and / is slightly
different from that of text, to reflect conventions about operator
precedence that have evolved over centuries.
Entire books have been devoted to the conventions of
mathematical typesetting, from the alignment of superscripts and
subscripts, to rules for choosing parenthesis sizes, and on to
specialized notational practices for subfields of mathematics. The
manuals describing the nuances of present-day computer typesetting and
composition systems can run to hundreds of pages.

Notational conventions in mathematics, and in printed text in general,
guide the eye and make printed expressions much easier to read and
understand. Though we usually take them for granted, we, as modern readers,
rely on
numerous conventions such as paragraphs, capital letters, font
families and cases, and even the device of decimal-like numbering of
sections such as is used in this document.
Such notational conventions are perhaps even more important
for electronic media, where one must contend with the difficulties of
on-screen reading. Appropriate standards coupled with computers
enable a broadening of access to mathematics beyond the world of
print. The markup methods for mathematics in use
just before the Web rose to prominence importantly included TEX
(also written TeX) [Knuth1986]
and approaches based on SGML ([AAP-math], [Poppelier1992] and [ISO-12083]).

It is remarkable how widespread the current
conventions of mathematical notation have become. The general
two-dimensional layout, and most of the same symbols, are used
in all modern mathematical communications,
whether the participants are, say, European, writing left-to-right,
or Middle-Eastern, writing right-to-left. Of course, conventions
for the symbols used, particularly those naming functions and
variables, may tend to favor a local language and script.
The largest variation from the most common is a form used in
some Arabic-speaking communities which lays out the entire
mathematical notation from right-to-left, roughly in mirror image
of the European tradition.

However, there is more to putting mathematics on the Web
than merely finding ways of displaying traditional
mathematical notation in a Web browser. The Web represents a
fundamental change in the underlying metaphor for knowledge
storage, a change in which interconnection
plays a central role. It has become important to
find ways of communicating mathematics which facilitate
automatic processing, searching and indexing, and reuse in
other mathematical applications and contexts. With this
advance in communication technology, there is an opportunity
to expand our ability to represent, encode, and ultimately to
communicate our mathematical insights and understanding with
each other. We believe that MathML as specified below is an important step in
developing mathematics on the Web.

1.2 Origins and Goals

1.2.1 Design Goals of MathML

MathML has been designed from the beginning with the following
ultimate goals in mind.

MathML should ideally:

Encode mathematical material suitable for all educational
and scientific communication.

Encode both mathematical notation and mathematical meaning.

Facilitate conversion to and from other mathematical
formats, both presentational and semantic. Output formats should include:

graphical displays

speech synthesizers

input for computer algebra systems

other mathematics typesetting languages, such as TEX

plain text displays, e.g. VT100 emulators

international print media, including braille

It is recognized that conversion to and from other notational
systems or media may entail loss of information in the process.

Allow the passing of information intended for
specific renderers and applications.

Support efficient browsing of lengthy expressions.

Provide for extensibility.

Be well suited to templates and other common techniques for editing formulas.

Be legible to humans, and simple for software to generate and process.

No matter how successfully MathML achieves its goals as
a markup language, it is clear that MathML is useful only
if it is implemented well. The W3C Math Working
Group has identified a short list of additional implementation
goals. These goals attempt to describe concisely the minimal
functionality MathML rendering and processing software should
try to provide.

MathML expressions in HTML (and XHTML) pages should render
properly in popular Web browsers, in accordance with reader and author
viewing preferences, and at the highest quality possible given the
capabilities of the platform.

MathML expressions in Web pages should be able to react to
user gestures, such those as with a mouse, and to coordinate
communication with other applications through the
browser.

Mathematical expression editors and converters should be developed
to facilitate the creation of Web pages containing MathML
expressions.

The extent to which these goals are ultimately met depends on the
cooperation and support of browser vendors and other developers. The W3C
Math Working Group has continued to work with other working groups of the W3C,
and outside the W3C, to ensure that the
needs of the scientific community will be met.
MathML 2 and its implementations showed considerable progress in this area
over the situation that obtained at
the time of the MathML 1.0 Recommendation (April 1998) [MathML1]. MathML3 and the developing Web are expected to
allow much more.

1.3 Overview

MathML is a markup language for describing mathematics.
It is usually expressed in XML syntax, although HTML and other syntaxes are possible.
A special aspect of MathML is that there are two main strains of markup:
Presentation markup, discussed in Chapter 3 Presentation Markup,
is used to display mathematical expressions;
and Content markup, discussed in Chapter 4 Content Markup,
is used to convey mathematical meaning.
Content markup is specified in particular detail.
This specification makes use of
an XML
format called Content Dictionaries
This format has been developed by the
OpenMath Society, [OpenMath2004] with the dictionaries being used by this specification involving joint development by the OpenMath Society and the W3C Math
Working Group.

1.4 A First Example

The quadratic formula provides a
simple but instructive illustration of MathML markup.

MathML offers two flavors of markup of this formula. The first is
the style which emphasizes the actual presentation of a formula, the
two-dimensional layout in which the symbols are arranged. An example
of this type is given just below. The second flavor
emphasizes the mathematical content and an example of it follows the first one.

Consider the superscript 2 in this formula. It represents the squaring operation
here, but the meaning of a superscript in other situations depends on
the context. A letter with a superscript can be used to signify a particular
component of a vector, or maybe the superscript just labels a different
type of some structure. Similarly two letters written one just after the
other could signify two variables multiplied together, as they do in the
quadratic formula, or they could be two letters making up the name of a
single variable. What is called Content Markup in MathML allows closer
specification of the mathematical meaning of many common formulas. The
quadratic formula given in this style of markup is as follows.

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 [RELAX-NG].
The RelaxNG Schema is normative, but a DTD (Document Type Definition)
and an XML Schema [XMLSchemas] are provided
for continuity (they were normative for MathML2).
See Appendix A Parsing MathML.

MathML's character set
consists
of legal characters
as specified by Unicode [Unicode], further restricted
by the characters not allowed in XML.
The use of Unicode characters for mathematics is
discussed in Chapter 7 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.
When the xmlns attribute is used alone, it sets
the default namespace for the element on which it
appears, and for any child elements. For example:

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 XHTML, one might use:

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,
which always places math elements and its descendents in the MathML namespace
(other than special rules described in Appendix A Parsing MathMLfor invalid input, and for annotation-xml.
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

Most MathML elements act as ‘containers’; such an element's
children are not distinguished from each other except as individual members of the
list of children. Commonly there is no limit imposed on the number of children
an element may have. This is the case for most presentation
elements and some content elements such as set.
But many
MathML elements require a specific number of children, or
attach a particular meaning to children in certain positions.
Such elements are best considered to represent constructors of mathematical
objects, and hence thought of as functions of their children. Therefore
children of such a MathML element
will often be referred to as its arguments instead of merely as children.
Examples of this can be found, say, in Section 3.1.3 Required 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 Section 3.1.3.1 Inferred <mrow>s.

In the detailed discussions of element syntax given with each
element throughout the MathML specification, the correspondence
of children with arguments, 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 Section 3.1.3 Required Arguments.

2.1.4 MathML and Rendering

MathML presentation elements only recommend (i.e., do not require)
specific ways of rendering; this is in order to allow for medium-dependent
rendering and for individual preferences of style.

Nevertheless, some parts of this specification describe these
recommended visual rendering rules in detail; in those
descriptions it is often assumed that the model of rendering
used supports the concepts of a well-defined 'current rendering
environment' which, in particular, specifies a 'current font',
a 'current display' (for pixel size) and a 'current baseline'.
The 'current font' provides certain metric properties and an
encoding of glyphs.

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.

Except when explicitly forbidden by the specification for an attribute,
MathML attribute values may contain any legal characters specified by
the XML recommendation. See Chapter 7 Characters, Entities and Fonts for further
clarification.

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.
We use below the notation
beginning with U+ that is recommended by Unicode
for referring to Unicode characters [see [Unicode], page
xxviii].

Notation

What it matches

decimal-digit

a decimal digit from the range U+0030 to U+0039

hexadecimal-digit

a hexadecimal (base 16) digit from the ranges U+0030 to U+0039, U+0041 to
U+0046 and U+0061 to U+0066

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].

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 as 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

f1 f2 ... 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, Appendix 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.
The syntax of a length is specified as

The possible units and namedspaces, along with their interpretations, are
shown below. Note that although the units and their meanings are taken from
CSS, the syntax of lengths is not identical. A few MathML elements
have length attributes that accept additional keywords; these are termed pseudo-units
and specified
in the description of those particular elements; see, for instance, Section 3.3.6 Adjust Space Around Content
<mpadded>.

A trailing "%" represents a percent of
a reference value; unless otherwise stated,
the reference value is
the default value.
The default value, or how it is obtained,
is listed in the table of attributes for each element
along with the reference value when
it differs from the default.
(See also Section 2.1.5.4 Default values of attributes.)
A number without a unit is intepreted as a multiple of the
reference value.
This form is primarily for backward compatibility and should be avoided,
prefering explicit units for clarity.

In some cases, the range of acceptable values for a particular attribute may be restricted;
implementations are free to round up or down to the closest allowable value.

The following constants, namedspaces,
may also be used where a length is needed; they are typically used for
spacing or padding between tokens.
Recommended default values for these constants are shown;
the actual spacing used is implementation specific.

namedspace

Recommended default

"veryverythinmathspace"

1/18em

"verythinmathspace"

2/18em

"thinmathspace"

3/18em

"mediummathspace"

4/18em

"thickmathspace"

5/18em

"verythickmathspace"

6/18em

"veryverythickmathspace"

7/18em

"negativeveryverythinmathspace"

-1/18em

"negativeverythinmathspace"

-2/18em

"negativethinmathspace"

-3/18em

"negativemediummathspace"

-4/18em

"negativethickmathspace"

-5/18em

"negativeverythickmathspace"

-6/18em

"negativeveryverythickmathspace"

-7/18em

2.1.5.2.1 Additional notes about units

Lengths are only used in MathML for presentation, and presentation
will ultimately involve rendering in or on some medium. For visual media,
the display context is assumed to have certain properties available to
the rendering agent. A px corresponds to a pixel on the display, to
the extent that is meaningful. The resolution of the display device
will affect the correspondence of pixels to the units
in, cm, mm, pt and pc.

Moreover, the display context will also provide a default for the font size;
the parameters of this font determine the initial values used to interpret
the units em and ex, and thus indirectly the sizes
of namedspaces. Since these units track the display context, and in particular,
the user's preferences for display, the relative units em and ex
are generally to be preferred over absolute units such as px or cm.

Two additional aspects of relative units must be clarified, however.
First, some elements such as Section 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 Color Valued Attributes

A color is specified either by "#" followed
by hexadecimal values for the red, green, and blue components,
with no intervening whitespace, or by an html-color-name.
The color components can be either 1-digit or 2-digit, but
must all have the same number of digits; the component
ranges from 0 (component not present) to FF (component fully present).
Note that, for example, by the digit-doubling rule specified under Colors in
[CSS21]#123 is a short form for #112233.

Color values can also be specified as an html-color-name,
one of the color-name keywords defined in [HTML4]
("aqua",
"black",
"blue",
"fuchsia",
"gray",
"green",
"lime",
"maroon",
"navy",
"olive",
"purple",
"red",
"silver",
"teal",
"white", and
"yellow").
Note that the color name keywords are not case-sensitive, unlike most
keywords in MathML attribute values, for compatibility with CSS and HTML.

When a color is applied to an element,
it is the color in which the content of tokens is rendered.
Additionally, when inherited from a surrounding element or from the environment in which the complete MathML expression is
embedded, it controls the color of
all other drawing due to MathML elements, including the lines
or radical signs that can be drawn in rendering mfrac, mtable, or
msqrt.

When used to specify a background color, the keyword "transparent"
is also allowed.
The recommended MathML visual rendering rules do not define the
precise extent of the region whose background is affected by using the
background attribute on an element,
except that, when the element's content does not have
negative dimensions and its drawing region is not overlapped by other
drawing due to surrounding negative spacing, this region should lie
behind all the drawing done to render the content of the
element, but 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 background attribute is not
defined by these rules.

2.1.5.4 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 Section 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 (Section 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.

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.

Associates the element with a set of style classes for use with
[XSLT] and [CSS21].
Typically this would be a space separated sequence of words,
but this is not specified by MathML.
See Section 6.5 Using CSS with MathML for discussion of the interaction of MathML and CSS.

Associates style information with the element for use with
[XSLT] and [CSS21].
This typically would be an inline CSS style,
but this is not specified by MathML.
See Section 6.5 Using CSS with MathML for discussion of the interaction
of MathML and CSS.

Can be used to establish the element as a hyperlink to the specfied URI.

Note that MathML 2 had no direct support for linking, and instead
followed the W3C Recommendation "XML Linking Language"
[XLink] in defining links using the
xlink:href attribute. This has changed, and MathML 3 now
uses an href attribute. However, particular compound
document formats may specify the use of XML linking with MathML
elements, so user agents that support XML linking should continue to
support the use of the xlink:href attribute with MathML 3
as well.

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 &nbsp; (U+00A0)
or other non-marking characters that are not trimmed.
For example, compare the above use of an mtext element
with

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 Section 6.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.

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 Section 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.

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.

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.

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.

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 Section 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:

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.

2.2.2 Deprecated Attributes

intended to provide a way of pointing to external macro definition files.
Macros are not part of the MathML specification.

mode

"display" | "inline"

inline

specified whether the enclosed MathML expression should be rendered in
a display style or an inline style.
This attribute is deprecated in
favor of the display attribute.

2.3 Conformance

Information nowadays is commonly
generated, processed and rendered by
software tools. The exponential growth of the Web is fueling the
development of advanced systems for automatically searching,
categorizing, and interconnecting information.
In addition, there are increasing numbers of
Web services, some of which offer technically based materials
and activities. Thus, although MathML
can be written by hand and read by humans,
whether machine-aided or just with much concentration,
the future of MathML is
largely tied to the ability to process it with software tools.

There are many different kinds of MathML
processors: editors for authoring MathML expressions, translators for
converting to and from other encodings, validators for checking MathML
expressions, computation engines that evaluate, manipulate, or compare
MathML expressions, and rendering engines that produce visual, aural,
or tactile representations of mathematical notation. What it
means to support MathML varies widely between applications. For
example, the issues that arise with a validating
parser are very different from those for an equation
editor.

This section gives guidelines that describe different types
of MathML support and make clear the extent of MathML support in
a given application. Developers, users, and reviewers are encouraged
to use these guidelines in characterizing products. The intention
behind these guidelines is to facilitate reuse by
and interoperability
of MathML applications by accurately setting out their
capabilities in quantifiable terms.

The W3C Math Working Group maintains MathML Compliance
Guidelines. Consult this document for future updates on
conformance activities and resources.

2.3.1 MathML Conformance

A valid MathML expression is an XML construct determined by the MathML
RelaxNG Schema together with the additional requirements given in this specification.

We shall use the phrase "a MathML processor"
to mean any application that
can accept or produce a valid MathML
expression. A MathML processor that both accepts and produces valid
MathML expressions may be able to "round-trip" MathML.
Perhaps the simplest example of an
application that might round-trip a MathML
expression would be an editor that writes it to a new file without
modifications.

Three forms of MathML conformance are specified:

A MathML-input-conformant processor must
accept all valid MathML expressions; it should appropriately translate all
MathML expressions into application-specific form allowing native
application operations to be performed.

A MathML-round-trip-conformant processor must
preserve MathML equivalence. Two MathML expressions are
"equivalent" if and only if both expressions have the
same interpretation (as stated by the MathML
Schema and specification)
under any relevant circumstances, by any MathML processor. Equivalence on an
element-by-element basis is discussed elsewhere in this document.

Beyond the above definitions, the MathML specification makes no
demands of individual processors. In order to guide developers, the
MathML specification includes advisory material; for example, there
are many recommended rendering rules throughout Chapter 3 Presentation Markup.
However, in general, developers are given wide latitude to
interpret what kind of MathML implementation is meaningful for
their own particular application.

To clarify the difference between conformance and
interpretation of what is meaningful, consider some examples:

In order
to be MathML-input-conformant, a
validating parser needs only to accept expressions, and return
"true" for expressions that are valid MathML. In
particular, it need not render or interpret the MathML expressions at
all.

A MathML computer-algebra interface based on content markup
might choose to ignore all presentation markup. Provided the interface
accepts all valid MathML expressions including those containing
presentation markup, it would be technically correct to characterize
the application as MathML-input-conformant.

An equation editor might have an internal data representation
that makes it easy to export some equations as MathML but not
others. If the editor exports the simple equations as valid MathML,
and merely displays an error message to the effect that conversion
failed for the others, it is still technically
MathML-output-conformant.

2.3.1.1 MathML Test Suite and Validator

As the previous examples show, to be useful, the concept of MathML
conformance frequently involves a judgment about what parts of the
language are meaningfully implemented, as opposed to parts that are
merely processed in a technically correct way with respect to the
definitions of conformance. This requires some mechanism for giving a
quantitative statement about which parts of MathML are meaningfully
implemented by a given application. To this end, the W3C Math Working
Group has provided a test
suite.

The test suite consists of a large number of MathML expressions
categorized by markup category and dominant MathML element being
tested. The existence of this test suite makes it possible, for example,
to characterize quantitatively the hypothetical computer algebra interface
mentioned above by saying that it is a MathML-input-conformant processor
which meaningfully implements MathML content markup, including all of
the expressions in the content markup section of the test suite.

Developers who choose not to implement parts of the MathML
specification in a meaningful way are encouraged to itemize the parts
they leave out by referring to specific categories in the test suite.

For MathML-output-conformant processors, information about currently
available tools to validate MathML is
maintained at the W3C MathML Validator.
Developers of MathML-output-conformant processors are encouraged to verify
their output using this
validator.

Customers of MathML applications who wish to verify claims as to which
parts of the MathML specification are implemented by an application are
encouraged to use the test suites as a part of their decision
processes.

2.3.1.2 Deprecated MathML 1.x and MathML 2.x Features

MathML 3.0 contains a number of features of earlier MathML
which are now deprecated. The following points define what it means for a
feature to be deprecated, and clarify the relation between
deprecated features and current MathML conformance.

In order to be MathML-output-conformant, authoring tools may not
generate MathML markup containing deprecated features.

In order to be MathML-input-conformant, rendering and reading
tools must support deprecated features if they are to be
in conformance with MathML 1.x or MathML 2.x. They do not have to support deprecated
features to be considered in conformance with MathML 3.0. However, all tools
are encouraged to support the old forms as much as
possible.

In order to be MathML-round-trip-conformant, a processor need
only preserve MathML equivalence on expressions containing no
deprecated features.

2.3.1.3 MathML
Extension Mechanisms and Conformance

MathML 3.0 defines three basic extension mechanisms: the mglyph
element provides a way of displaying glyphs for non-Unicode
characters, and glyph variants for existing Unicode characters; the
maction element uses attributes from other namespaces to obtain
implementation-specific parameters; and content markup makes use of
the definitionURL attribute, as well as
Content Dictionaries and the cd attribute, to point to external
definitions of mathematical semantics.

These extension mechanisms are important because they provide a way
of encoding concepts that are beyond the scope of MathML 3.0 as presently
explicitly specified, which
allows MathML to be used for exploring new ideas not yet susceptible
to standardization. However, as new ideas take hold, they may become
part of future standards. For example, an emerging character that
must be represented by an mglyph element today may be
assigned a Unicode code point in the future. At that time,
representing the character directly by its Unicode code point would be
preferable. This transition into Unicode has
already taken place for hundreds of characters used for mathematics.

Because the possibility of future obsolescence is inherent in the
use of extension mechanisms to facilitate the discussion of new ideas,
MathML can reasonably make
no conformance requirements concerning the use of
extension mechanisms, even when alternative standard markup is
available. For example, using an mglyph element to represent
an 'x' is permitted. However, authors and implementers are
strongly encouraged to use standard markup whenever possible.
Similarly, maintainers of documents employing MathML 3.0 extension
mechanisms are encouraged to monitor relevant standards activity
(e.g., Unicode, OpenMath, etc.) and to update documents as more
standardized markup becomes available.

2.3.2 Handling of Errors

If a MathML-input-conformant application receives
input containing one or more elements with an illegal number or type
of attributes or child schemata, it should nonetheless attempt to
render all the input in an intelligible way, i.e., to render normally
those parts of the input that were valid, and to render error messages
(rendered as if enclosed in an merror element) in place of
invalid expressions.

MathML-output-conformant applications such as
editors and translators may choose to generate merror
expressions to signal errors in their input. This is usually
preferable to generating valid, but possibly erroneous, MathML.

2.3.3 Attributes for unspecified data

The MathML attributes described in the MathML specification are
intended to allow for good presentation and content markup. However
it is never possible to cover all users' needs for markup. Ideally, the MathML
attributes should be an open-ended list so that users can add specific
attributes for specific renderers. However, this cannot be done within
the confines of a single XML DTD or in a Schema.
Although it can be done using extensions of the standard DTD, say,
some authors will wish to use non-standard
attributes to take advantage of renderer-specific capabilities while
remaining strictly in conformance with the standard
DTD.

To allow this, the MathML 1.0 specification [MathML1]
allowed the attribute other on all elements, for use as a hook to pass
on renderer-specific information. In particular, it was intended as a hook for
passing information to audio renderers, computer algebra systems, and for pattern
matching in future macro/extension mechanisms. The motivation for this approach to
the problem was historical, looking to PostScript, for example, where comments are
widely used to pass information that is not part of PostScript.

In the next period of evolution of MathML the
development of a general XML namespace mechanism
seemed to make the use of the other
attribute obsolete. In MathML 2.0, the other attribute is
deprecated in favor of the use of
namespace prefixes to identify non-MathML attributes. The
other attribute remains deprecated in MathML 3.0.

For example, in MathML 1.0, it was recommended that if additional information
was used in a renderer-specific implementation for the maction element
(Section 3.7.1 Bind Action to Sub-Expression
<maction>),
that information should be passed in using the other attribute:

Note that the intent of allowing non-standard attributes is
not to encourage software developers to use this as a
loophole for circumventing the core conventions for MathML markup.
Authors and applications should use non-standard attributes
judiciously.

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.

3.1.1 What Presentation Elements Represent

Presentation elements correspond to the "constructors"
of traditional mathematical notation — that is, to the basic
kinds of symbols and expression-building structures out of which any
particular piece of traditional mathematical notation is built.
Because of the importance of traditional visual notation, the
descriptions of the notational constructs the elements represent are
usually given here in visual terms. However, the elements are
medium-independent in the sense that they have been designed to
contain enough information for good spoken renderings as well. Some
attributes of these elements may make sense only for visual media, but
most attributes can be treated in an analogous way in audio as well
(for example, by a correspondence between time duration and horizontal
extent).

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. This specification
describes suggested visual rendering rules in some detail, but a
particular MathML renderer is free to use its own rules as long as its
renderings are intelligible.

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:

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 usually rendered invisibly. For example, the entities
&DifferentialD;, &ExponentialE;, and
&ImaginaryI; denote notational symbols semantically distinct from visually
identical letters used as simple variables.
Likewise, the entities
&InvisibleTimes;,
&ApplyFunction;,
&InvisibleComma; and the character U+2064
(INVISIBLE PLUS) usually render invisibly but represent significant information.
These entities have distinct spoken renderings, may influence visual linebreaking and spacing,
and may effect the evaluation or meaning of particular expressions.
Accordingly, authors should use these entities wherever they are applicable.
For instance, the expression represented visually as
"f(x)" would usually be spoken in English as
"f of x" rather than just
"fx". MathML conveys this meaning by using
the &ApplyFunction; operator after the
"f", which, in this case, can be aurally rendered as
"of".

The remainder of this section introduces MathML-specific
terminology and conventions used in this chapter.

3.1.2.1 Types of presentation elements

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 (except for whitespace, which they ignore).
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. The primary MathML token element
types are identifiers (e.g. variables or function names), numbers, and
operators (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. Note that although a token element
represents a single meaningful "symbol" (name, number, label,
mathematical symbol, etc.), such symbols may be comprised of more than
one character. For example sin and 24 are
represented by the single tokens <mi>sin</mi>
and <mn>24</mn> respectively.

In traditional mathematical notation, expressions are recursively
constructed out of smaller expressions, and ultimately out of single
symbols, with the parts grouped and positioned using one of a small
set of notational structures, which can be thought of as "expression
constructors". In MathML, expressions are constructed in the same way,
with the layout schemata playing the role of the expression
constructors. The layout schemata specify the way in which
sub-expressions are built into larger expressions. The terminology
derives from the fact that each layout schema corresponds to a
different way of "laying out" its sub-expressions to form a larger
expression in traditional mathematical typesetting.

3.1.2.2 Terminology for other classes of elements and their relationships

The terminology used in this chapter for special classes of elements, and for
relationships between elements, is as follows: The presentation elements are
the MathML elements defined in this chapter.
These elements are listed in Section 3.1.9 Summary of Presentation Elements.
The content elements are the MathML elements defined
in Chapter 4 Content Markup.

A MathML expression is a single instance of any of the
presentation elements with the exception of the empty elements
none or mprescripts,
or is a single instance of any of the content elements which are allowed as
content of presentation elements (described in Section 5.3.2 Content Markup in Presentation Markup).
A sub-expression of an expression
E is any MathML expression that is part of the content of
E, whether directly or indirectly,
i.e. whether it is a "child" of E or not.

Since 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 Section 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 inferredmrow formed from all their children,
and treat this mrow as the argument.

For example,

<mtd>
</mtd>

is treated as if it were

<mtd>
<mrow>
</mrow>
</mtd>

and

<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.

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, e.g. msup, are able to
embellish operators that are their first argument. These elements are
listed in Section 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.

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 Section 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 behaviour 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; ie. 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 individual subformula 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 used, such as RTL Arabic
and LTR numbers, the Unicode bidirectional algorithm [Bidi]
is 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 (Section 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 an 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.

Please 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.
These 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 Section 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 Section 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 Section 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.

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 Section 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 render 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 a 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.

Forced linebreaks are specified by using
linebreak="newline"
on a 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 Section 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 Section 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 Section 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 Section 2.2.1 Attributes.)

3.1.7.2 Automatic Linebreaking Algorithm (Informative)

One method of linebreaking that works reasonably well is sometimes referred
to as a "best-fit" algorithm. It works by computing a "penalty" for
each potential break point on a line. The break point with the smallest
penalty is chosen and the algorithm then works on the next line. Three
useful factors in a penalty calculation are:

How much of the line width (after subtracting of the indent) is unused?
The more unused, the higher the penalty.

How deeply nested is the breakpoint in the expression tree? The expression
tree's depth is roughly similar to the nesting depth of mrows.
The more deeply nested the break point, the higher the penalty.

Does a linebreak here make layout of the next line difficult?
If the next line is not the last line and if the indentingstyle uses
information about the linebreak point to determine how much to indent,
then the amount of room left for linebreaking on the next line must be considered;
i.e., linebreaks that leave very little room to draw the next line
result in a higher penalty.

Whether "linebreak" has been specified:
"nobreak" effectively sets the penalty to infinity,
"badbreak" increases the penalty
"goodbreak" decreases the penalty,
and "newline" effectively sets the penalty to 0.

This algorithm takes time proportional to the number of token elements times the number of lines.

3.1.7.3 Linebreaking Algorithm for Inline Expressions (Informative)

A common method for breaking inline expressions that are too long for the
space remaining on the current line is to pick an appropriate break point
for the expression and place the expression up to that point on the current line
and place the remainder of the expression on the following line.
This can be done by:

Querying the text processing engine for the
minimum and maximum amount of space available on the current line.

Using a variation of the automatic linebreaking algorithm
given above),
and/or using hints provided by linebreak attributes
on mo or mspace elements, to choose a line break.
The goal is that the first part of the formula fits "comfortably" on the current line
while breaking at a point that results in keeping related
parts of an expression on the same line.

The remainder of the formula begins on the next line,
positioned both vertically and horizontally according
to the paragraph flow;
MathML's indentation attributes
are ignored in this algorithm.

If the remainder does not fit on a line,
steps 1 - 3 are repeated for the second and subsequent lines.
Unlike the for the first line,
some part of the expression must be placed these lines so that the algorithm terminates.

3.1.8 Warning about fine-tuning of presentation

Some use-cases require precise control of the math layout and presentation.
Several MathML elements and attributes expressly support such fine-tuning of the
rendering. However, MathML rendering agents exhibit wide variability in their
presentation of the the same MathML expression due to difference in platforms,
font availability, and requirements particular to the agent itself
(see Section 3.1 Introduction).
The overuse of explicit rendering control may yield a ‘perfect’ layout on one platform,
but give much worse presentation on others.
The following sections clarify the kinds of problems that can occur.

3.1.8.1 Warning: non-portability of "tweaking"

For particular expressions, authors may be tempted to use the
mpadded,
mspace,
mphantom, and
mtext elements to improve
("tweak") the spacing generated by a specific renderer.

Without explicit spacing rules, various MathML renders may use different spacing
algorithms. Consequently, different MathML renderers may position symbols in different
locations relative to each other. Say that renderer B, for example, provides improved
spacing for a particular expression over renderer A. Authors are strongly warned that
"tweaking" the layout for renderer A may produce very poor results in renderer B,
very likely worse than without any explicit adjustment at all.

Even when a specific choice of renderer can be assumed, its spacing
rules may be improved in successive versions, so that the effect of
tweaking in a given MathML document may grow worse with time. Also,
when style sheet mechanisms are extended to MathML, even one version
of a renderer may use different spacing rules for users with different
style sheets.

Therefore, it is suggested that MathML markup never use
mpadded or mspace elements
to tweak the rendering of specific expressions, unless the MathML is
generated solely to be viewed using one specific version of one MathML
renderer, using one specific style sheet (if style sheets are
available in that renderer).

In cases where the temptation to improve spacing proves too strong,
careful use of mpadded,
mphantom, or the alignment elements (Section 3.5.5 Alignment Markers
<maligngroup/>, <malignmark/>) may give more portable results than the
direct insertion of extra space using mspace or
mtext. Advice given to the implementers of MathML
renderers might be still more productive, in the long run.

3.1.8.2 Warning: spacing should not be used to convey meaning

MathML elements that permit "negative spacing", namely
mspace, mpadded, and
mo, could in theory be used to simulate new
notations or "overstruck" characters by the visual overlap of the
renderings of more than one MathML sub-expression.

This practice is strongly discouraged in all situations,
for the following reasons:

it will give different results in different MathML renderers
(so the warning about "tweaking" applies), especially
if attempts are made to render glyphs outside the bounding box of
the MathML expression;

it is likely to appear much worse than a more standard construct
supported by good renderers;

such expressions are almost certain to be uninterpretable
by audio renderers, computer algebra systems,
text searches for standard symbols,
or other processors of MathML input.

More generally, any construct that uses spacing to convey
mathematical meaning, rather than simply as an aid to viewing
expression structure, is discouraged. That is, the constructs that
are discouraged are those that would be interpreted differently by a
human viewer of rendered MathML if all explicit spacing was
removed.

Consider using the mglyph element
for cases such as this. If such spacing constructs are used in spite of this warning, they should
be enclosed in a semantics element that also
provides an additional MathML expression that can be interpreted in a
standard way. See Section 5.1 Annotation Framework for further discussion.

The above warning also applies to most uses of rendering
attributes to alter the meaning conveyed by an expression, with the
exception of attributes on mi (such as mathvariant)
used to distinguish one variable from another.

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.

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.

These style attributes 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 (See Section 3.2.2 Mathematics style attributes common to token elements).

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 doesn't specify the mechanism by which
style information is inherited from the rendering environment.
See Section 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 is not overlapped by other
drawing due to surrounding negative spacing, this region should lie
behind all the drawing done to render the content, but 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.

Frequently, tokens consist of a single character denoting a
mathematical symbol. Other cases, e.g. function names, involve
multi-character tokens. Further, because traditional mathematical
notation makes wide use of symbols distinguished by their
typographical properties (e.g. a Fraktur 'g' for a Lie algebra, or a
bold 'x' for a vector), care must be taken to insure that styling
mechanisms respect typographical properties which carry meaning.
Consequently, characters, tokens, and typographical properties of
symbols are closely related to one another in MathML.

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 Section 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. See Chapter 7 Characters, Entities and Fonts for a
discussion of the advantages and disadvantages of numeric
character references versus
entity references, and [Entities] for a full list of the entity names available.
Also, see Section 7.7 Anomalous Mathematical Characters for a discussion of the
appropriate character content to choose for certain applications.

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 Section 3.1.5.2 Bidirectional Layout in Token Elements).

3.2.1.1 Alphanumeric symbol characters

A large class of mathematical symbols are single letter identifiers
typically used as variable names in formulas. Different font variants
of a letter are treated as separate symbols. For example, a Fraktur
'g' might denote a Lie algebra, while a Roman 'g' denotes the
corresponding Lie group. These letter-like symbols are traditionally
typeset differently than the same characters appearing in text, using
different spacing and ligature conventions. These characters must
also be treated specially by style mechanisms, since arbitrary style
transformations can change meaning in an expression.

For these reasons, Unicode contains
more than nine hundred Math Alphanumeric Symbol characters
corresponding to letter-like symbols. These characters are in the
Secondary Multilingual Plane (SMP). See [Entities] for
more information. As valid Unicode data, these characters are
permitted in MathML and, as tools and fonts for them become widely
available, we anticipate they will be the predominant way of denoting
letter-like symbols.

MathML also provides an alternative encoding
for these characters using only Basic Multilingual Plane
(BMP) characters together with markup. MathML defines a
correspondence between token elements with certain combinations of BMP
character data and the mathvariant attribute and tokens
containing SMP Math Alphanumeric Symbol characters. Processing
applications that accept SMP characters are required to treat the
corresponding BMP and attribute combinations identically. This is particularly important for applications that
support searching and/or equality testing.

3.2.1.2 Using images to represent
symbols <mglyph/>

3.2.1.2.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.

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.

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.

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.

Note that the src and alt attributes are required for correct usage in MathML 3, however this is not enforced by the schema due to the deprecated usage described below.

3.2.1.2.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.

3.2.1.2.4 Deprecated Attributes

Originally, mglyph was designed to provide access to non-standard
fonts. Since this functionality was seldom implemented, nor were downloadable
web fonts widely available, this use of mglyph has been deprecated.
For reference, the following attributes were previously defined:

In MathML 1 and 2, both were required attributes; they are now optional
and should be ignored unless the src attribute is missing.

Additionally, in MathML 2, mglyph accepted the attributes described in
Section 3.2.2 Mathematics style attributes common to token elements
(mathvariant and mathsize, along with the attributes deprecated there);
to make clear that mglyph is not a token element, and since
these attributes have no effect in any case, these attributes have been deprecated.

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 Section 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 Section 6.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 to 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 Section 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 Section 7.5 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 XHTML, 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 Section 3.1.6 Displaystyle and Scriptlevel.

3.2.2.1 Deprecated style attributes on token elements

The MathML 1.01 style attributes listed below
are deprecated in MathML 2 and 3.
These attributes were aligned to CSS but, in rendering environments that support CSS,
it is preferable to use CSS directly to control the rendering properties
corresponding to these attributes, rather than the attributes themselves.
However as explained above, direct manipulation of these
rendering properties by whatever means should usually be avoided.
As a general rule, whenever there is a conflict between these
deprecated attributes and the corresponding attributes (Section 3.2.2 Mathematics style attributes common to token elements),
the former attributes should be ignored.

Should be the name of a font that may be available to a MathML renderer,
or a CSS font specification; See Section 6.5 Using CSS with MathML
and CSS [CSS21] for more information.
Deprecated in favor of mathvariant.

fontweight

"normal" | "bold"

inherited

Specified the font weight for the token.
Deprecated in favor of mathvariant.

fontstyle

"normal" | "italic"

normal (except on<mi>)

Specified the font style to use for the token.
Deprecated in favor of mathvariant.

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 Section 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)
can be represented using an mi element, as shown
in an example in Section 3.2.6.4 Mixing text and mathematics.

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
Chapter 4 Content Markup.

3.2.3.3 Examples

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
(which also has the entity names &af; and &ApplyFunction;) as shown below;
see also the discussion of invisible operators in Section 3.2.5 Operator, Fence, Separator or Accent
<mo>.

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 Section 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
Chapter 4 Content Markup.

3.2.4.3 Examples

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, ratios of numbers shown as fractions, and
names of numeric constants. Examples of MathML representations of
such numbers include:

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 Section 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> &le; </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> &le; </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
Section 3.2.6 Text <mtext>. See also Chapter 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
Section 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
the a linebreak is made at that operator.

Most attributes get their default values from an enclosing
mstyle element, math element,
from the containing document,
or from the
Section 3.2.5.7.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 anmrow

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 Section 3.2.5.7.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.

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 &int;
and &prod;.
See Section 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 &sum;, &prod;, and lim.
See Section 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.

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.

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 linebreaks occur on this operator; or whether the operator is duplicated.
"before" causes the operator to appears 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).

Specifies the character used to make an &InvisibleTimes; operator visible at a linebreak.
For example, linebreakmultchar="&#xB7;" would make the
multiplication visible as a center dot.

linebreak values on adjacent mo and mspaceelements do
not interact; linebreak="nobreak" on a 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 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 available the width and current font,
is not always available to the author of the MathML,
a render 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.

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.

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.

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.

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.

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> &#x2264;<!--LESS-THAN OR EQUAL TO--> </mo>

≤

<mo> &lt;= </mo>

<=

<mo> ++ </mo>

++

<mo> &#x2211;<!--N-ARY SUMMATION--> </mo>

∑

<mo> .NOT. </mo>

.NOT.

<mo> and </mo>

and

<mo> &#x2062;<!--INVISIBLE TIMES--> </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
Section 3.3.8 Expression Inside Pair of Fences
<mfenced>.

3.2.5.5 Invisible operators

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

The reasons for using specific mo elements for
invisible operators include:

such operators should often have specific effects on visual
rendering (particularly spacing and linebreaking rules) that are not
the same as either the lack of any operator, or spacing represented by
mspace or mtext
elements;

these operators should often have specific audio renderings
different than that of the lack of any operator;

automatic semantic interpretation of MathML presentation elements
is made easier by the explicit specification of such operators.

For example, an audio renderer might render f(x)
(represented as in the above examples) by speaking "f of x", but use
the word "times" in its rendering of xy.
Although its rendering must still be different depending on the structure
of neighboring elements (sometimes leaving out "of" or
"times" entirely), its task is made much easier by the use of
a different mo element for each invisible
operator.

3.2.5.6 Names for other special operators

MathML also includes &DifferentialD; (U+2146) for use
in an mo element representing the differential
operator symbol usually denoted by "d". The reasons for
explicitly using this special character are similar to those for using
the special characters for invisible operators described in the
preceding section.

3.2.5.7 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. Furthermore, no attempt is made
to specify the rendering completely; rather, enough information is
given to make the intended effect of the various rendering attributes
as clear as possible.

3.2.5.7.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 Appendix C 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.7.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 Section 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 Section 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.

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.7.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
(Section 5.1 Annotation Framework), 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.7.4 Rationale for definition of embellished operators

The following notes are included as a rationale for certain aspects
of the above definitions, but should not be important for most users
of MathML.

An mfrac is included as an
"embellisher" because of the common notation for a
differential operator:

Since the definition of embellished operator affects the use of the
attributes related to stretching, it is important that it includes
embellished fences as well as ordinary operators; thus it applies to
any mo element.

Note that an mrow containing a single argument
is an embellished operator if and only if its argument is an embellished
operator. This is because an mrow with a single
argument must be equivalent in all respects to that argument alone (as
discussed in Section 3.3.1 Horizontally Group Sub-Expressions
<mrow>).
This means that an mo element that is the sole argument of an mrow
will determine its default form attribute based on that
mrow's position in a surrounding, perhaps inferred,
mrow (if there is one), rather than based on its own
position in the mrow in which it is the sole argument.

Note that the above definition defines every
mo element to be "embellished" — that is,
"embellished operator" can be considered (and implemented in
renderers) as a special class of MathML expressions, of which
mo is a specific case.

3.2.5.7.5 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.8 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:

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

3.2.5.8.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:

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.

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

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
Section 3.5.4.2 Attributes for details about the rowspan attribute.

3.2.5.8.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 Section 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:

3.2.5.8.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.5.9 Examples of Linebreaking

The following example demonstrates forced linebreaks and forced alignment:

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.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 some text with a clearly defined notational role might be
more appropriately marked up using mi or
mo; this is discussed further below.

An mtext element can be used to 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. This is not related to any whitespace in the source MathML
consisting of blanks, newlines, tabs, or carriage returns; whitespace
present directly in the source is trimmed and collapsed, as described in
Section 2.1.7 Collapsing Whitespace in Input. Whitespace that is intended to be rendered
as part of an element's content must be represented by entity references
or mspace elements
(unless it consists only of single blanks between non-whitespace
characters).

3.2.6.4 Mixing text and mathematics

In some cases, text embedded in mathematics could be more appropriately
represented using mo or mi elements.
For example, the expression 'there exists
such that f(x) <1' is equivalent to
and could be represented as:

An example involving an mi element is:
x+x2+···+xn.
In this example, ellipsis should be represented using an mi element, since it takes the place of a term in the
sum; (see Section 3.2.3 Identifier <mi>).

On the other hand, expository text within MathML is best
represented with an mtext element. An example
of this is:

Theorem 1: if x > 1, then
x2 > x.

However, when MathML is
embedded in HTML, or another document markup language, the example is
probably best rendered with only the two inequalities represented as
MathML at all, letting the text be part of the surrounding HTML.

Another factor to consider in deciding how to mark up text is the
effect on rendering. Text enclosed in an mo
element is unlikely to be found in a renderer's operator dictionary,
so it will be rendered with the format and spacing appropriate for an
"unrecognized operator", which may or may not be better than the
format and spacing for "text" obtained by using an
mtext element. An ellipsis entity in an
mi element is apt to be spaced more appropriately
for taking the place of a term within a series than if it appeared in
an mtext element.

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 Section 3.1.8 Warning about fine-tuning of presentation.
See also the other elements that can render as
whitespace, namely mtext, mphantom, and
maligngroup.

Specifies the desirability of a linebreak at this space.
This attribute should be ignored if any dimensional attribute is set.

Linebreaking was originally specified on mspace in MathML2,
but controlling linebreaking on mo
is to be preferred starting with MathML 3.
MathML 3 adds new linebreaking attributes only to mo, not mspace.
However, because a linebreak can be specified on mspace,
control over the indentation that follows that break can be specified using the attributes listed in
Section 3.2.5.2.3 Indentation attributes.

The value "indentingnewline" was defined in MathML2 for mspace;
it is now deprecated. Its meaning is the same as newline, which is compatible with its earlier use when no other linebreaking attributes are specified.
Note that linebreak values on adjacent mo and mspace elements do
not interact; a "nobreak" on an mspace will
not, in itself, inhibit a break on an adjacent mo element.

3.2.7.3 Examples

In the last example, mspace will cause the line to end after the "b" and the following line to be indented so that the "+" that follows will align with
the "+" with id="firstop".

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 Section 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;

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.7.5 Legal grouping of space-like elements

Authors who insert space-like elements or
mphantom elements into an existing MathML
expression should note that such elements are counted as
arguments, in elements that require a specific number of arguments,
or that interpret different argument positions differently.

Therefore, space-like elements inserted into such a MathML element
should be grouped with a neighboring argument of that element by
introducing an mrow for that purpose. For example,
to allow for vertical alignment on the right edge of the base of a
superscript, the expression

<msup>
<mi> x </mi>
<malignmark edge="right"/>
<mn> 2 </mn>
</msup>

is illegal, because msup must have exactly 2 arguments;
the correct expression would be:

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 Section 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, msdoes trim and
collapse whitespace in its content according to the rules of
Section 2.1.7 Collapsing Whitespace in Input, so whitespace intended to remain in
the content should be encoded as described in that section.

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".

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 Section 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 Section 3.1.3.1 Inferred <mrow>s),
although the control of linebreaking is effected through attributes
on other elements (See Section 3.1.7 Linebreaking of Expressions).

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 Section 3.2.5 Operator, Fence, Separator or Accent
<mo> and Section 3.2.7 Space <mspace/>. See also the discussion of equivalence of MathML
expressions in Section 2.3 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 (Appendix C 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 mean 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.

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.

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.
These cases are shown below:

An example illustrating the bevelled form is shown below:

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 Section 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.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> baseindex </mroot>

The mroot element requires exactly 2 arguments.
However, msqrt accepts a single argument, possibly
being an inferred mrow of multiple children; see Section 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 Section 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.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.
Firstly, as a presentation element, it accepts
the attributes described in Section 3.1.10 Mathematics style 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.

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 "1", 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, columnalign, or groupalign
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 deprecated fontfamily attribute is specified on an
mstyle element, it does not apply to the mglyph element.
The deprecated index attribute cannot 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 we feel it is more useful
and intuitive. Since the default for mathcolor is inherited,
this is no change in its behaviour.

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.

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 Section 3.1.6 Displaystyle and Scriptlevel.

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.2.1 Deprecated Attributes

MathML2 allowed the binding of namedspaces
to new values.
It appears that this capability was never implemented, and is now deprecated;
namedspaces are now considered constants.
For backwards compatibility, the following attributes are accepted
on the mstyle element, but are expected to have no effect.

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.

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 Section 2.3.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.

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
Section 3.1.8 Warning about fine-tuning of presentation for warnings about several
potential pitfalls of this effect.

Sets the vertical position of the child content.
See below for discussion.

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 Section 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:

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 Section 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 t
he 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.

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.

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.

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 (Section 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

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 Section 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:

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.

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

Individual fences or separators are represented using
mo elements, as described in Section 3.2.5 Operator, Fence, Separator or Accent
<mo>. Thus, any mfenced
element is completely equivalent to an expanded form described below;
either form can be used in MathML, at the convenience of an author or
of a MathML-generating program. A MathML renderer 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 (Section 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.

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:

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:

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.

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 (Section 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.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 Section 3.1.3 Required Arguments.

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.

Specifies a space separated list of notations to be used to enclose the children.
See below for a description of each type of notation.

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 the following are
affected by the directionality (see Section 3.1.5.1 Overall Directionality of Mathematics Formulas):

"radical"

"phasorangle"

When notation has the value "longdiv",
the contents are drawn enclosed by a long division symbol.
MathML 3 adds the mlongdiv element
(Section 3.6.2 Long Division <mlongdiv>). This element supports notations for long division
used in several countries and can be used to create a complete example of
long division as shown in Section 3.6.8.3 Long Division.
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 case of
notation="radical" is equivalent to the
msqrt schema.

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 is 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 consistancy 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.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 Section 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. 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:

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

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,

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> baseunderscript </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 Section 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 &sum;.

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 specfied in Section 3.2.5.8.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 Section 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.

Here is an example (accent versus underscript):
versus
.
The MathML representation for this example is shown below.

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> baseoverscript </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 Section 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 &sum;.

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 specfied in Section 3.2.5.8.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 here:
versus
.
These differences also apply to "mathematical accents" such as
bars or braces over expressions:
versus
.
The MathML representation for each of these examples is shown below.

The default value of accent is false, unless
overscript is an mo element or an
embellished operator (see Section 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.

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> baseunderscriptoverscript </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 Section 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 &sum;.

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 specfied in Section 3.2.5.8.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 in the
second expression shown below:

versus
.
The MathML representation for this example is shown below.

The difference in the vertical spacing is too small to be noticed on a
low resolution display at a normal font size, but is noticeable on a higher
resolution device such as a printer and when using large font sizes. In
addition to the visual differences, attaching both the underscript and
overscript to the same base more accurately reflects the semantics of the
expression.

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

3.4.6.3 Examples

The MathML representation for the example shown above with the first
expression made using separate munder and
mover elements, and the second one using an
munderover element, is:

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 can be represented by the empty element
none.

The prescripts are optional, and when present are given
after the postscripts, 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 (ie. 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.

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

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 Section 3.1.6 Displaystyle and Scriptlevel.)

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 Section 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.
(In MathML 1.x, the mtable was allowed to ‘infer’ mtr elements around its arguments,
and the mtr element could infer mtd elements.
This behaviour is deprecated.)

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.

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).

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).

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 a MathML renderer has available for the math element.
When the value is "auto", the MathML
renderer should calculate the table width from its contents using
whatever layout algorithm it chooses.

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).

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.

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.

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 Section 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 Section 3.1.6 Displaystyle and Scriptlevel.)

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.

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 a 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

3.5.4.2 Attributes

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 4.01 tables.

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 4.01 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 a mlabeledtr element.
Also, the label of a 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 Description

Alignment markers are space-like elements (see Section 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 y = 0
3.1 x - 0.7y = -1.1

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

8.44x + 55y = 0
3.1x - 0.7y = -1.1

For audio renderers, it is suggested that the alignment elements
produce the analogous behavior of altering the rhythm of pronunciation
so that it is the same for several sub-expressions in a column, by the
insertion of the appropriate time delays in place of the extra
horizontal spacing described here.

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.

The reason mtable columns are used as
alignment scopes is that they are the only general way in MathML to
arrange expressions into vertical columns. Future versions of MathML
may provide an malignscope element that allows
an alignment scope to be created around any MathML element, but even
then, table columns would still sometimes need to act as alignment
scopes, and since they are not elements themselves, but rather are
made from corresponding parts of the content of several
mtr elements, they could not individually be the
content of an alignment scope element.

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.2 Specifying alignment groups

To cause alignment, it is necessary to specify, within each
expression to be aligned, the points to be aligned with corresponding
points in other expressions, and the beginning of each alignment
group of sub-expressions that can be horizontally shifted as a
unit to effect the alignment. Each alignment group must contain one
alignment point. It is also necessary to specify which expressions in
the column have no alignment groups at all, but are affected only by
the ordinary column alignment for that column of the table, i.e. by
the columnalign attribute, described elsewhere.

The alignment groups start at the locations of invisible
maligngroup elements, which are rendered with
zero width when they occur outside of an alignment scope, but within
an alignment scope are rendered with just enough horizontal space to
cause the desired alignment of the alignment group that follows
them. A simple algorithm by which a MathML application can achieve this is given
later. 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.

In general, a table cell containing nmaligngroup 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
present example, given at the end of this section.

The nested expression structure formed by mrows
and other layout schemata should reflect the mathematical structure of the
expression, not the alignment-group structure, to make possible optimal
renderings and better automatic interpretations; see the discussion of
proper grouping in section Section 3.3.1 Horizontally Group Sub-Expressions
<mrow>. Insertion of
alignment elements (or other space-like elements) should not alter the
correspondence between the structure of a MathML expression and the
structure of the mathematical expression it represents.

Although alignment groups need not
coincide with the nested expression structure of layout schemata,
there are nonetheless restrictions on where an maligngroup
element is allowed within a table cell. The maligngroup
element 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.

Note that some positions for an maligngroup
element, although legal, are not useful, such as an
maligngroup element that is an argument of an
mfenced element. Similarly, when inserting an maligngroup
element in an element whose arguments have positional significance, it
is necessary to introduce a new mrow element
containing just the maligngroup element and the child element
it precedes in order to preserve the proper expression structure. For
example, to insert an maligngroup before the denominator
child of an mfrac element, it is necessary to enclose the
maligngroup and the denominator in an mrow to
avoid introducing an illegal third child in the
mfrac. In general, this will be necessary except
when the maligngroup element is inserted directly into an
mrow or into an element that can form an inferred
mrow from its contents. See the warning about the legal
grouping of "space-like elements" in Section 3.2.7 Space <mspace/> for an analogous example
involving malignmark.

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.

Note that 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.

3.5.5.3 Table cells that are not divided into alignment groups

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, and are not affected by the groupalign
attribute described below. 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 y = 0
3.1 x - 0.7y = -1.1

or, with a shorter heading,

some equations
8.44x + 55 y = 0
3.1 x - 0.7y = -1.1

3.5.5.4 Specifying alignment points using <malignmark/>

Each alignment group's alignment point can either be specified by
an malignmark element anywhere within the
alignment group (except within another alignment scope wholly
contained inside it), or it is determined automatically from the
groupalign attribute. The groupalign
attribute can be specified on the group's preceding
maligngroup element or on its surrounding
mtd, mtr, or
mtable elements. In typical cases, using the
groupalign attribute is sufficient to describe the
desired alignment points, so no malignmark
elements need to be provided.

The malignmark element indicates that the
alignment point should occur on the right edge of the preceding
element, or the left edge of the following element or character,
depending on the edge attribute of
malignmark. Note that it may be necessary to
introduce an mrow to group an
malignmark element with a neighboring element,
in order not to alter the argument count of the containing
element. (See the warning about the legal grouping of "space-like
elements" in Section 3.2.7 Space <mspace/>).

When an malignmark element is provided within an
alignment group, it can occur in an arbitrarily deeply nested element
within the group, as long as it is not within a nested alignment scope. It
is not subject to the same restrictions on location as maligngroup elements. However, its immediate
surroundings need to be such that the element to its immediate right or
left (depending on its edge attribute) can be
unambiguously identified. If no such element is present, renderers should
behave as if a zero-width element had been inserted there.

For the purposes of alignment, an element X is considered to be to the
immediate left of an element Y, and Y to the immediate right of X, whenever
X and Y are successive arguments of one (possibly inferred) mrow element,
with X coming before Y (in a LTR context; with X coming after Y in a RTL context). In the case of
mfenced elements, MathML applications should evaluate this
relation as if the mfenced element had been
replaced by the equivalent expanded form involving mrow. Similarly, an maction
element should be treated as if it were replaced by its currently selected
sub-expression. In all other cases, no relation of "to the immediate
left or right" is defined for two elements X and Y. However, in the
case of content elements interspersed in presentation markup, MathML applications
should attempt to evaluate this relation in a sensible way. For example, if
a renderer maintains an internal presentation structure for rendering
content elements, the relation could be evaluated with respect to
that. (See Chapter 4 Content Markup and Chapter 5 Mixing Markup Languages for Mathematical Expressions for further
details about mixing presentation and content markup.)

malignmark elements are allowed to occur within
the content of token elements, such as mn,
mi, or mtext. When this
occurs, the character immediately before or after the
malignmark element will carry the alignment
point; in all other cases, the element to its immediate left or right
will carry the alignment point. The rationale for this is that it is
sometimes desirable to align on the edges of specific characters
within multi-character token elements.

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, in certain cases, such as when they are
used to specify alignment on "decimal points" other than the '.'
character.

The
edge attribute specifies whether the alignment point will be
found on the left or right edge of some element or character. The
precise location meant by "left edge" or "right edge" is discussed
below. If edge="right", the alignment point is the right
edge of the element or character to the immediate left of the
malignmark element. If edge="left",
the alignment point is the left edge of the element or character to
the immediate right of the malignmark
element. Note that the attribute refers to the choice of edge rather
than to the direction in which to look for the element whose edge will
be used.

For malignmark elements that occur within
the content of MathML token elements, the preceding or following
character in the token element's content is used; if there is no such
character, a zero-width character is effectively inserted for the
purpose of carrying the alignment point on its edge. For all other
malignmark elements, the preceding or following
element is used; if there is no such element, a zero-width element is
effectively inserted to carry the alignment point.

The precise definition of the "left edge" or "right edge" of a
character or glyph (e.g. whether it should coincide with an edge of
the character's bounding box) is not specified by MathML, but is at
the discretion of the renderer; the renderer is allowed to let the
edge position depend on the character's context as well as on the
character itself.

For proper alignment of columns of numbers (using groupalign values of "left", "right", or "decimalpoint"), it is
likely to be desirable for the effective width (i.e. the distance between
the left and right edges) of decimal digits to be constant, even if their
bounding box widths are not constant (e.g. if "1" is narrower
than other digits). For other characters, such as letters and operators, it
may be desirable for the aligned edges to coincide with the bounding
box.

The "left edge" of a MathML element or alignment group
refers to the left edge of the leftmost glyph drawn to render the element
or group, except that explicit space represented by mspace or mtext elements
should also count as "glyphs" in this context, as should
glyphs that would be drawn if not for mphantom
elements around them. The "right edge" of an element or
alignment group is defined similarly.

maligngroup has one attribute,
groupalign, which is used to determine the position of
its group's alignment point when no malignmark
element is present. The following discussion assumes that no
malignmark element is found within a group.

In the example given at the beginning of this section, there is one
column of 2 table cells, with 7 alignment groups in each table cell;
thus there are 7 columns of alignment groups, with 2 groups, one above
the other, in each column. These columns of alignment groups should be
given the 7 groupalign values "decimalpoint left left
decimalpoint left left decimalpoint", in that order. How to specify
this list of values for a table cell or table column as a whole, using
attributes on elements surrounding the
maligngroup element is described later.

If groupalign is "left",
"right", or "center", the alignment point is
defined to be at the group's left edge, at its right edge, or halfway
between these edges, respectively. The meanings of "left edge"
and "right edge" are as discussed above in relation to malignmark.

If groupalign is "decimalpoint",
the alignment point is the right edge of the character immediately before the
left-most 'decimal point', i.e. matching the character specified by
the decimalpoint attribute of mstyle (default ".", U+002E)
in the first mn element found along
the alignment group's baseline. More precisely, the alignment group is
scanned recursively, depth-first, for the first mn
element, descending into all arguments of each element of the types
mrow (including inferred
mrows), mstyle,
mpadded, mphantom, menclose,
mfenced, or msqrt,
descending into only the first argument of each "scripting" element
(msub, msup,
msubsup, munder,
mover, munderover,
mmultiscripts) or of each
mroot or semantics element,
descending into only the selected sub-expression of each
maction element, and skipping the content of all
other elements. The first mn so found always
contains the alignment point, which is the right edge of the last
character before the first decimal point in the content of the
mn element. If there is no decimal point in the
mn element, the alignment point is the right edge
of the last character in the content. If the decimal point is the
first character of the mn element's content, the
right edge of a zero-width character inserted before the decimal point
is used. If no mn element is found, the right
edge of the entire alignment group is used (as for
groupalign="right").

In order to permit alignment on decimal points in
cn elements, a MathML application can convert a
content expression into a presentation expression that renders the
same way before searching for decimal points as described above.

Characters other than "." can be used as
"decimal points" for alignment by using mstyle;
more arbitrary alignment points can chosen by embedding malignmark elements
within the mn token's content itself.

For any of the groupalign values, if an explicit
malignmark element is present anywhere within
the group, the position it specifies (described earlier) overrides the
automatic determination of alignment point from the
groupalign value.

3.5.5.7 Inheritance of groupalign values

It is not usually necessary to put a groupalign
attribute on every maligngroup element. Since
this attribute is usually the same for every group in a column of
alignment groups to be aligned, it can be inherited from an attribute
on the mtable that was used to set up the
alignment scope as a whole, or from the mtr or
mtd elements surrounding the alignment group. It
is inherited via an "inheritance path" that proceeds from
mtable through successively contained
mtr, mtd, and
maligngroup elements. There is exactly one
element of each of these kinds in this path from an
mtable to any alignment group inside it. In
general, the value of groupalign will be
inherited by any given alignment group from the innermost element
that surrounds the alignment group and provides an explicit
setting for this attribute. For example, if an
mtable element specifies values for groupalign and
a maligngroup element within the table also specifies an
explicit groupalign value, then then the value from the
maligngroup takes priority.

Note, however, that each mtd element needs, in
general, a list of groupalign values, one for each
maligngroup element inside it (from left to right, in an LTR context,
or from right to left in an RTL context), rather than just
a single value. Furthermore, an mtr or
mtable element needs, in general, a list of lists
of groupalign values, since it spans multiple
mtable columns, each potentially acting as an
alignment scope. Such lists of group-alignment values are specified
using the following syntax rules:

As described in Section 2.1.5 MathML Attribute Values, | separates
alternatives; + represents optional repetition (i.e. 1 or
more copies of what precedes it), with extra values ignored and the
last value repeated if necessary to cover additional table columns or
alignment group columns; '{' and '}'
represent literal braces; and ( and ) are
used for grouping, but do not literally appear in the attribute
value.

The permissible values of the groupalign attribute of the
elements that have this attribute are specified using the above
syntax definitions as follows:

In the example near the beginning of this section, the group
alignment values could be specified on every mtd
element using groupalign = "decimalpoint left left
decimalpoint left left decimalpoint", or on every
mtr element using groupalign =
"{decimalpoint left left decimalpoint left left decimalpoint}", or
(most conveniently) on the mtable as a whole
using groupalign = "{decimalpoint left left decimalpoint
left left decimalpoint}", which provides a single braced list of
group-alignment values for the single column of expressions to be
aligned.

3.5.5.8 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.
To repeat the example, the desired rendering is:

3.5.5.9 Further details of alignment elements

The alignment elements maligngroup and
malignmark can occur outside of alignment
scopes, where they are ignored. The rationale behind this is that in
situations in which MathML is generated, or copied from another
document, without knowing whether it will be placed inside an
alignment scope, it would be inconvenient for this to be an error.

An mtable element can be given the attribute alignmentscope="false" to cause its
columns not to act as alignment scopes. In general, this attribute has the
syntax ("true" | "false") +; if its value is a list of Boolean
values, each Boolean value applies to one column, with the last value
repeated if necessary to cover additional columns, or with extra values
ignored. Columns that are not alignment scopes are part of the alignment
scope surrounding the mtable element, if there is
one. Use of alignmentscope="false" allows nested tables to contain malignmark elements for aligning the inner table in the
surrounding alignment scope.

As discussed above, processing of alignment for content elements is
not well-defined, since MathML does not specify how content elements
should be rendered. However, many MathML applications are likely to find it
convenient to internally convert content elements to presentation
elements that render the same way. Thus, as a general rule, even if a
renderer does not perform such conversions internally, it is
recommended that the alignment elements should be processed as if it
did perform them.

A particularly important case for renderers to handle gracefully is the
interaction of alignment elements with the matrix
content element, since this element may or may not be internally converted
to an expression containing an mtable element for
rendering. To partially resolve this ambiguity, it is suggested, but not
required, that if the matrix element is converted
to an expression involving an mtable element, that
the mtable element be given the attribute alignmentscope="false", which will
make the interaction of the matrix element with the
alignment elements no different than that of a generic presentation element
(in particular, it will allow it to contain malignmark elements that operate within the alignment
scopes created by the columns of an mtable that
contains the matrix element in one of its table
cells).

The effect of alignment elements within table cells that have
non-default values of the columnspan or rowspan attributes is not specified, except that such
use of alignment elements is not an error. Future versions of MathML may
specify the behavior of alignment elements in such table cells.

The effect of possible linebreaking of an mtable
element on the alignment elements is not specified.

3.5.5.10 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, the groupalign attribute described in
this section, and the columnalign attribute described
under mtable (Section 3.5.1 Table or Matrix
<mtable>).

First, 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. The
positions of alignment points specified by any
malignmark elements are noted, and the remaining
alignment points are determined using groupalign
values.

For each alignment group, the horizontal positions of the left
edge, alignment point, 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.

Second, 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.

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.

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 Section 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 (ie. 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 Section 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.

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 Section 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:

The ‘digits’ in a row are determined.

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

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

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.

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.

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

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 Section 3.6.3 Group Rows with Similiar Positions <msgroup> and Section 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.

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 works 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.

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.

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 Section 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 Similiar 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

specifies the horizontal position of the rows within this group relative
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.

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 are 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 Section 3.1.5 Directionality.

3.6.4.2 Attributes

specifies the horizontal position of the rows within this group relative
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 Section 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 Section 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

specifies the horizontal position of the rows within this group relative
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.

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 Section 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.

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.

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 a 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.

specifies the horizontal position of the rows within this group relative
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 moves towards the tens digit (like multiplying by a power of 10);
negative values moves 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.

Specifies the 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).

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 Section 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, carrries/borrows, lines, and the sign of the
operation.

Notice that the msline spans all of the columns and that none is used to make the "+" appear to the left of all of the operands.

Here is an example with the 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 any row.

3.6.8.2 Multiplication

Below is a simple multiplication example that illustrates the use of msgroup and
the shift attribute. The first msgroup does nothing.
The second msgroup could also be removed, but msrow would be needed for its second and third children.
They would set the position or shift attributes, or would add none elements.

This example 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.

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 Section 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.

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.

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. These notations are shown below:

The MathML for these involves using mstack, msrow, and msline
in a straightforward manner. The MathML for the preceding examples above is given below.

3.7 Enlivening Expressions

3.7.1 Bind Action to Sub-Expression
<maction>

To provide a mechanism for binding actions to expressions, MathML
provides the maction element. This element accepts any
number of sub-expressions as arguments and the type of action that should happen
is controlled by the actiontype attribute.
Only three actions are predefined by MathML, but the list of possible actions is open.
Additional predefined actions may be added in future versions of MathML.

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
Section 6.4.4 Linking.

3.7.1.1 Attributes

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
Section 2.3.2 Handling of Errors.

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.

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 Section 6.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 meanings of the various actiontype values is given below.
Note that not all renderers support all of the actiontype values, and that the allowed values are open-ended.

The renderer alternately display the
selected subexpression, cycling through them when there is a click on the selected subexpression.
Each click increments the selection value,
wrapping back to 1 when it reaches the last child.
Typical uses would be for exercises in education, ellipses in long
computer algebra output, or to illustrate alternate notations. Note
that the expressions may be of significantly different size, so that
size negotiation with the browser may be desirable. If size
negotiation is not available, scrolling, elision, panning, or some
other method may be necessary to allow full viewing.

<maction actiontype="statusline"> (expression) (message) </maction>

The renderer displays the first child.
When a reader clicks on the expression or
moves the pointer over it, the renderer sends a rendering of the
message to the browser statusline. Because most browsers in the
foreseeable future are likely to be limited to displaying text on their
statusline, the second child should be an
mtext element in most circumstances.
For non-mtext messages, renderers might provide a
natural language translation of the markup, but this is not
required.

<maction actiontype="tooltip"> (expression) (message) </maction>

The renderer displays the first child.
When the pointer pauses over the expression for a long
enough delay time, the renderer displays a rendering of the message in
a pop-up "tooltip" box near the expression. Many systems may limit
the popup to be text, so the second child should be an
mtext element in most circumstances.
For non-mtext messages,
renderers may provide a natural language translation of the markup if
full MathML rendering is not practical, but this is not
required.

<maction actiontype="input"> (expression) </maction>

The renderer displays the expression.
For renderers that allow editing, when focus is passed to this element,
the maction is replaced by what is entered, pasted, etc.
MathML does not restrict what is allowed as input, nor does it require an editor to allow arbitrary input.
Some renderers/editors may restrict the input to simple (linear) text.

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:

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 Section 2.3.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.

4 Content Markup

4.1 Introduction

4.1.1 The Intent of Content Markup

The intent of Content Markup is to provide an explicit encoding of
the underlying mathematical meaning of an expression,
rather than any particular rendering for the expression. Mathematics
is distinguished both by its use of rigorous formal logic to define
and analyze mathematical concepts, and by the use of a (relatively)
formal notational system to represent and communicate those concepts.
However, mathematics and its presentation should not be viewed as one
and the same thing. Mathematical notation, though more rigorous than
natural language, is nonetheless at times ambiguous,
context-dependent, and varies from community to community. In some
cases, heuristics may adequately infer mathematical semantics from
mathematical notation. But in many others 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.

The difficulties in inferring semantics from a presentation stem
from the fact that there are many to one mappings from presentation to
semantics and vice versa. For example the mathematical construct
"H multiplied by e" is often
encoded using an explicit operator as in
H × e. In different
presentational contexts, the multiplication operator might be
invisible "He", or rendered
as the spoken word "times". Generally, many different
presentations are possible depending on the context and style
preferences of the author or reader. Thus, given
"He" out of context it may be
impossible to decide if this is the name of a chemical or a
mathematical product of two variables H and
e. Mathematical presentation also varies across cultures
and geographical regions. For example, many notations for long
division are in use in different parts of the world today. Notations
may lose currency, for example the use of musical sharp and flat
symbols to denote maxima and minima [Chaundy1954]. A
notation in use in 1644 for the multiplication mentioned above was
He[Cajori1928].

By encoding the underlying mathematical structure explicitly,
without regard to how it is presented aurally or visually, it is
possible to interchange information more precisely between systems
that semantically process mathematical objects. In the trivial example
above, such a system could substitute values for the variables
H and e and evaluate the result. Important
application areas include computer algebra systems, automatic
reasoning system, industrial and scientific applications,
multi-lingual translation systems, mathematical search, and
interactive textbooks.

The organization of this chapter is as follows. In Section 4.2 Content MathML Elements Encoding Expression Structure, a core collection of elements comprising Strict
Content Markup are described. Strict Content Markup is sufficient to
encode general expression trees in a semantically rigorous way. It is
in one-to-one correspondence with OpenMath element set. OpenMath is a
standard for representing formal mathematical objects and semantics
through the use of extensible Content Dictionaries. Strict Content
Markup defines a mechanism for associating precise mathematical
semantics with expression trees by referencing OpenMath Content
Dictionaries. The next two sections introduce markup that is more
convenient than Strict markup for some purposes, somewhat less formal
and verbose. In Section 4.3 Content MathML for Specific Structures, markup is
introduced for representing a small number of mathematical idioms,
such as limits on integrals, sums and product. These constructs may
all be rewritten as Strict Content Markup expressions, and rules for
doing so are given. In Section 4.4 Content MathML for Specific Operators and Constants, elements are
introduced for many common function, operators and constants. This
section contains many examples, including equivalent Strict Content
expressions. In Section 4.5 Deprecated Content Elements, elements from
MathML 1 and 2 whose use is now discouraged are listed.
Finally, Section 4.6 The Strict Content MathML Transformation summarizes the algorithm for
translating arbitrary Content Markup into Strict Content Markup. It
collects together in sequence all the rewrite rules introduced
throughout the rest of the chapter.

4.1.2 The Structure and Scope of Content MathML Expressions

Content MathML represents mathematical objects as expression trees. The
notion of constructing a general expression tree is e.g. that of applying an operator to
sub-objects. For example, the sum "x+y" can be
thought of as an 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 π.

As a general rule, the terminal nodes in the 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 a compound objects. Function application provides the most important example;
an internal node might represent the application of a function to several arguments,
which are themselves represented by the nodes underneath the internal node.

The semantics of general mathematical expressions is not a matter of consensus. It
would be an enormous job to systematically codify most of mathematics – a task
that can never be complete. Instead, MathML makes explicit a relatively small number of
commonplace mathematical constructs, chosen carefully to be sufficient in a large number
of applications. In addition, it provides a mechanism for referring
to mathematical concepts outside of the base collection, allowing
them to be represented, as well.

The base set of content elements is chosen to be adequate for simple coding of most
of the formulas used from kindergarten to the end of high school in the United States,
and probably beyond through the first two years of college, that is up to A-Level or
Baccalaureate level in Europe.

While the primary role of the MathML content element set is to directly encode the
mathematical structure of expressions independent of the notation used to present the
objects, rendering issues cannot be ignored. There are different approaches for
rendering 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 3 does not provide a normative specification for
rendering. Instead, typical renderings are suggested by way of examples.

4.1.3 Strict Content MathML

In MathML 3, a subset, or profile, of Content MathML is defined: Strict Content
MathML. This uses a minimal, but sufficient, set of elements to represent the meaning of a
mathematical expression in a uniform structure, while the full Content MathML grammar is
backward compatible with MathML 2.0, and generally tries to strike a more pragmatic
balance between verbosity and formality.

Content MathML provides a large 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.). By contrast, Strict
Content MathML uses a single element (csymbol) with an
attribute pointing to an external definition in extensible content
dictionaries to represent all functions, and uses only
apply and bind for building up compound
objects. The token elements such as ci and cn are
also considered part of Strict Content MathML, but with a more
restricted set of attributes and with content restricted to
text.

Strict Content MathML is designed to be compatible with OpenMath (in
fact it is an XML encoding of OpenMath Objects in the sense of [OpenMath2004]).
OpenMath is a standard for representing formal mathematical
objects and semantics through the use of extensible Content Dictionaries. The table below
gives an element-by-element correspondence between the OpenMath XML encoding of OpenMath
objects and Strict Content MathML.

In MathML 3, formal semantics Content MathML expressions are
given by specifying equivalent Strict Content MathML expressions.
Since Strict Content MathML expressions all have carefully-defined
semantics given in terms of OpenMath Content Dictionaries, all
Content MathML expressions inherit well-defined semantics in this
way. To make the correspondence exact, an algorithm is
given in terms of transformation rules that are applied to
rewrite non-Strict MathML constructs into a strict equivalents. The
individual rules are introduced in context throughout the chapter.
In Section 4.6 The Strict Content MathML Transformation, the algorithm as a whole is
described.

The full algorithm described inSection 4.6 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. This means
it has to give specific strict interpretations to some expressions
whose meaning was insufficiently specified in MathML2. The intention
of this algorithm is to be faithful to mathematical intuitions.
However edge cases may remain where the normative interpretation of
the algorithm may break earlier intuitions.

A conformant MathML processor need
not implement this transformation. 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.

4.1.4 Content Dictionaries

Due to the nature of mathematics, any method for formalizing
the meaning of the mathematical expressions must be
extensible. The key to extensibility is the ability to define
new functions and other symbols to expand the terrain of
mathematical discourse. To do this, two things are required: a
mechanism for representing symbols not already defined by
Content MathML, and a means of associating a specific
mathematical meaning with them in an unambiguous way. In MathML
3, the csymbol element provides the means to represent
new symbols, while Content Dictionaries are the way
in which mathematical semantics are described. The association
is accomplished via attributes of the csymbol element
that point at a definition in a CD. The syntax and usage of
these attributes are described in detail in Section 4.2.3 Content Symbols <csymbol>.

Content Dictionaries are structured documents for the
definition of mathematical concepts; see the OpenMath standard,
[OpenMath2004].
To maximize modularity and reuse, a
Content Dictionary typically contains a relatively small
collection of definitions for closely related concepts. The
OpenMath Society maintains a large set of public Content Dictionaries
including the MathML CD group that including contains definitions
for all pre-defined symbols in MathML.
There is a process for contributing privately
developed CDs to the OpenMath Society repository to facilitate
discovery and reuse. MathML 3 does not require CDs be publicly
available, though in most situations the goals of semantic
markup will be best served by referencing public CDs available
to all user agents.

In the text below, descriptions of semantics for predefined
MathML symbols refer to the Content Dictionaries developed by
the OpenMath Society in conjunction with the W3C Math Working
Group. It is important to note, however, that this information
is informative, and not normative. In general, the precise
mathematical semantics of predefined symbols are not not fully
specified by the MathML 3 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 CDs are intended to be sufficient for
most applications, and are generally compatible with the
semantics specified for analogous constructs in the MathML 2.0
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 CDs as appropriate.

4.1.5 Content MathML Concepts

The basic building blocks of Content MathML expressions are
numbers, identifiers and symbols. These building blocks are combined
using function applications and binding operators. It is important to
have a basic understanding of these key mathematical concepts, and how
they are reflected in the design of Content MathML. For the
convenience of the reader, these concepts are reviewed here.

In the expression "x+y",
x is a mathematical variable, meaning an identifier that
represents a quantity with no fixed value. It may have other
properties, such as being an integer, but its value is not a fixed
property. By contrast, the plus sign is an identifier that represents a
fixed and externally defined object, namely the addition function.
Such an identifier is termed a symbol, to distinguish it
from a variable. Common elementary functions and operators all have
fixed, external definitions, and are hence symbols. Content MathML
uses the ci element to represent variables, and the
csymbol to represent symbols.

The most fundamental way in which symbols and variables are
combined is function application. Content MathML makes a crucial
semantic distinction between a function itself (a symbol such as the
sine function, or a variable such as f) and the result of
applying the function to arguments. The apply element groups the function
with its arguments syntactically, and represents the expression
resulting from applying that function to its arguments.

Mathematically, variables are divided into bound and
free variables. Bound variables are variables that are
assigned a special role by a binding operator within a certain scope.
For example, the index variable within a summation is a bound
variable. They can be characterized as variables with the property
that they can be renamed consistently throughout the binding scope
without changing the underlying meaning of the expression. Variables
that are not bound are termed free variables.
Because the logical distinction between bound and free variables is
important for well-defined semantics, Content MathML differentiates
between the application of a function to a free variable,
e.g. f(x) and the operation of binding a
variable within a scope. The bind element is used the delineate
the binding scope, and group the binding operator with its bound
variables, which are indicated by the bvar element.

In Strict Content markup, the bind element is the only way
of performing variable binding. In non-Strict usage, however, markup
is provided that more closely resembles well-known idiomatic
notations, such as the "limit" notations for sums and
integrals. These constructs often implicitly bind variables, such as
the variable of integration, or the index variable in a sum. MathML
terms the elements used to represent the auxiliary data such as limits
required by these constructions qualifier elements.

Expressions involving qualifiers follow one of a small number of
idiomatic patterns, each of which applies to 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 Section 4.3.4 Operator Classes.

Each Content MathML element is described in a section below that
begins with a table summarizing the key information about the element.
For elements that have different Strict and non-Strict
usage, these syntax tables are divided to clearly separate the two cases. The element's content
model is given in the Content row, linked to the MathML
Schema in Appendix A Parsing MathML. The Attributes, and
Attribute Values rows similarly link to the schema. Where
applicable, the Class row specifies the operator class, which
indicate how many arguments the operator represented by this element
takes, and also in many cases determines the mapping to Strict Content
MathML, as described in Section 4.3.4 Operator Classes. Finally,
the Qualifiers row clarifies whether the operator takes
qualifiers and if so, which. Note Class
and Qualifiers specify how many siblings may follow
the operator element in an apply, or the children of the
element for container elements; see Section 4.2.5 Function Application <apply> and Section 4.3.3 Qualifiers for
details).

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

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>

7F800000

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>

7FE0

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>

10F

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 times 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>

227

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.

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.

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.

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.

Rewrite: cn sep

If there are sep children of the cn,
then intervening text may be rewritten as cn
elements. If the cn element containing sep
also has a base attribute, this is copied to each
of the cn arguments of the resulting symbol, as
shown below.

Note: In the case of bigfloat the symbol
takes three arguments, <cn type="integer">10</cn> should be inserted as the second argument, denoting the base of the exponent used.

If the type attribute has a different value,
or if there is more than one <sep/> element,
then the intervening expressions are converted as above,
but a system-dependent choice of symbol for the head of the application must be used.

If a base attribute has been used then the resulting expression is not Strict Content MathML, and each of the arguments needs
to be recursively processed.

Rewrite: cn based_integer

A cn element with a base attribute other than 10 is rewritten as follows. (A base attribute with value 10 is simply removed) .

If the original element specified type "integer"
or if there is no type attribute, but the content of the
element just consists of the characters [a-zA-Z0-9] and white space
then the symbol used as the head in the resulting application should
be based_integer as shown. Otherwise it
should be should be based_float.

Rewrite: cn constant

In Strict Content MathML, constants should be represented using
csymbol elements. A number of important constants are defined in the
nums1 content dictionary. An expression of the form

Rewrite: cn presentation mathml

If the cn contains Presentation MathML markup, then it may
be rewritten to Strict MathML using variants of the rules above where
the arguments of the constructor are ci elements annotated
with the supplied Presentation MathML.

Where the identifier names, p and q, (which have to be a text string) should be
determined from the presentation MathML content, in a system defined way, perhaps as
in the above example by taking the character data of the element ignoring any element
markup. Systems doing such rewriting should ensure that constructs using the same
Presentation MathML content are rewritten to semantics elements using the
same ci, and that conversely constructs that use different MathML should be
rewritten to different identifier names (even if the Presentation MathML has the same character data).

A related special case arises when a cn element
contains character data not permitted in Strict Content MathML
usage, e.g. non-digit, alphabetic characters. Conceptually, this is
analogous to a cn element containing a presentation
markup mtext element, and could be rewritten accordingly.
However, since the resulting annotation would contain no additional
rendering information, such instances should be rewritten directly
as ci elements, rather than as a semantics
construct.

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>

x

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

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 [MathMLTypes] for more examples.

Mapping to Strict Content MathML

Rewrite: ci type annotation

In Strict Content, type attributes are represented via
semantic attribution. An expression of the form

Where the identifier name, p, (which has to be a text string) should be
determined from the presentation MathML content, in a system defined way, perhaps as
in the above example by taking the character data of the element ignoring any element
markup. Systems doing such rewriting should ensure that constructs using the same
Presentation MathML content are rewritten to semantics elements using the
same ci, and that conversely constructs that use different MathML should be
rewritten to different identifier names (even if the Presentation MathML has the same character data).

The following example encodes an atomic
symbol that displays visually as C2 and that,
for purposes of content, is treated as a single symbol

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

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 Section 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 [OpenMath2004]. 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.

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.

Mapping to Strict Content MathML

In non-Strict usage csymbol allows the use of
a type attribute.

Rewrite: csymbol type annotation

In Strict Content, type attributes are represented via
semantic attribution. An expression of the form

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>

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.

4.2.5 Function Application <apply>

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 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.

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 [ ab ...] </apply>

where the operandsa, 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

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

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 the sample
rendering of a simple application is as follows:

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:

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

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

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

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.

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 forall
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 forall
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:

4.2.7.1 The share element

The share element has an href attribute used to
to reference a MathML expression tree. The value of the
href 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 href 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).

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 href attribute. For instance in the
representation on the right above, the apply element with id="t1" and also the
second share (with href="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:

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
.
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 constraints is not restricted to such simple cases, as the following
example shows:

Here, the apply with id="bar" dominates its third child, the
share with href="#baz". That element dominates its target apply
(with id="baz"), which in turn dominates its third child, the share
with href="#bar". Finally, the share with
href="#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:

This represents a term
which has two sub-terms of the form
,
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
outerbind element.
However, in the copy, the variable x is
bound by the innerbind 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
.
However, in this form, it is no longer possible to share the expression
.
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
href 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 Chapter 5 Mixing Markup Languages for Mathematical Expressions.

The semantics element is be 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>

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:

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.

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:

4.2.10 Encoded Bytes <cbytes>

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 Section 4.4 Content MathML for Specific Operators and Constants.

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 Section 4.4 Content MathML for Specific Operators and Constants. 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 Section 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 Section 4.4 Content MathML for Specific Operators and Constants. The
complete algorithm for rewriting arbitrary Content MathML as Strict
Content markup is summarized at the end of the Chapter in Section 4.6 The Strict Content MathML Transformation.

4.3.1 Container Markup

Many mathematical structures are constructed from subparts or
parameters. The motivating example is a set. Informally, one
thinks of a set as a certain kind of mathematical object that
contains a collection of elements. Thus, it is intuitively natural
for the markup for a set to contain, in the XML sense, the markup
for its constituent elements. The markup may define the set
elements explicitly by enumerating them, or implicitly by rule,
using qualifier elements. However, in either case, the markup for
the elements is contained in the markup for the set, and
consequently this style of representation is termed
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.

While the two approaches are formally equivalent, container
markup is generally more intuitive for non-expert authors to use, while
Strict markup is preferable is contexts where semantic rigor is
paramount. In addition, MathML 2 relied on container markup, and
thus container markup is necessary in cases where backward
compatibility is required.

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. Note that in
MathML 2, the term "container markup" was also taken to include
token elements, and the deprecated declare, fn
and reln elements, but MathML 3 limits usage of the term
to the above constructs.

4.3.1.1 Container Markup for Constructor Symbols

The arguments to container elements corresponding to
constructors may either be explicitly given as a sequence of child
elements, or they may be specified by a rule using qualifiers. The
only exceptions are the piecewise, piece, and
otherwise elements used for representing functions with
piecewise definitions. The
arguments of these elements must always be specified
explicitly.

Here is an example of container markup with explicitly specified arguments:

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

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:

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:

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 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. 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 express the integral of a
function f over
C in this way:

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:

Note that the order of the inner and outer bound variables is significant.

Mappings to Strict Content MathML

When rewriting expressions to Strict Content MathML, qualifier
elements are removed via a series of rules described in this section.
The general algorithm for rewriting a MathML expression involving
qualifiers proceeds in two steps. First, constructs using the
interval, condition, uplimit and
lowlimit qualifiers are converted to constructs using only
domainofapplication. Second, domainofapplication
expressions are then rewritten as Strict Content markup.

The symbol used in this translation depends on the head of the
application, denoted by <ci>H</ci>
here. By default interval should be
used, unless the semantics of the head term can be determined and
indicate a more specific interval symbols. In particular, several
predefined Content MathML element should be used with more specific
interval symbols. If the head is int then oriented_interval is used. When the head term
is sum or product, integer_interval should be used.

The above technique for replacing lowlimit and uplimit qualifiers
with a domainofapplication element is also used for replacing the
interval qualifier.

The condition qualifier restricts a bound variable by specifying a
Boolean-valued expression on a larger domain, specifying whether a given value is in the
restricted domain. The condition element contains a single child that represents
the truth condition. Compound conditions are formed by applying Boolean operators such as
and in the condition.

Rewrite: condition

To rewrite an expression using the condition
qualifier as one using domainofapplication,

If the apply has a domainofapplication (perhaps originally expressed as
interval or an uplimit/lowlimit pair) then that is used for
<ci>R</ci>. Otherwise <ci>R</ci> is a set determined by the type attribute
of the bound variable as specified in Section 4.2.2.2 Non-Strict uses of <ci>, if that is
present. If the type is unspecified, the translation introduces an unspecified domain via
content identifier <ci>R</ci>.

By applying the rules above, expression using the
interval, condition, uplimit and
lowlimit can be rewritten using only
domainofapplication. Once a domainofapplication has
been obtained, the final mapping to Strict markup is accomplished
using the following rules:

Rewrite: restriction

An application of a function that is qualified by the
domainofapplication qualifier (expressed by an apply element without
bound variables) is converted to an application of a function term constructed with the
restriction symbol.

In general, an application involving bound variables and (possibly)
domainofapplication is rewritten using the following rule,
which makes the domain the first positional argument of the application,
and uses the lambda symbol to encode the variable bindings.
Certain classes of operator have alternative rules, as described below.

Rewrite: apply bvar domainofapplication

A content MathML expression with bound variables and
domainofapplication

4.3.3.2 Uses of <degree>

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:

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 next section
may be broadly separated into classes. The class of each
element is shown in the syntax table that introduces the element in
Section 4.4 Content MathML for Specific Operators and Constants. The class gives an indication of the
general intended mathematical usage of the element, and also
determines its usage as determined by the schema. The class also
determines the applicable rewrite rules for mapping to Strict Content
MathML. This section presents the rewrite rules for each of the
operator classes.

The rules in this section cover the use cases applicable to
specific operator classes. Special-case rewrite rules for individual
elements are discussed in the sections below. However, the most
common usage pattern is generic, and is used by operators from almost all
operator classes. It consists of applying an operator to an explicit list
of arguments using an apply element. In these cases,
rewriting to Strict Content MathML is simply a matter of replacing the
empty element with an appropriate csymbol, as listed in the
syntax tables in Section 4.4 Content MathML for Specific Operators and Constants. This is summarized in
the following rule.

Rewrite: element

For example,

<plus/>

is equivalent to the Strict form

<csymbol cd="arith1">plus</csymbol>

plus

In MathML 2, the definitionURL attribute could be
used to redefine or modify the meaning of an operator element. When the definitionURL
attribute is present, the value for the cd attribute on the csymbol should be
determined by the definitionURL value if possible. The correspondence between cd and definitionURL values is described Section 4.2.3.2 Non-Strict uses of <csymbol>.

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 my 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.4.1.2 Rewriting to Strict Content MathML

Any use of qualifier elements is expressed in Strict Content
MathML, via explicitly applying the function to a list of arguments
using the apply_to_list symbol as shown
in the following rule. The rule only considers the
domainofapplication qualifier as other qualifiers may be
rewritten to domainofapplication as described earlier.

Rewrite: n-ary domainofapplication

An expression of the following form,
where <union/> represents any
element of the relevant class and
<ci>expression-in-x</ci>
is an arbitrary expression involving the bound variable(s)

The above rule applies to all symbols in the listed classes.
In the case of nary-set.class the choice of Content
Dictionary to use depends on the type attribute on the
arguments, defaulting to set1, but multiset1
should be used if type="multiset".

Note that the members of the nary-constructor.class, such
as vector, use constructor syntax where the arguments and
qualifiers are given as children of the element rather than as
children of a containing apply. In this case, the above rules apply
with the analogous syntactic modifications.

4.3.4.2 N-ary Constructors for set and list (class nary-setlist-constructor)

The use of set and list follows the same format
as other n-ary constructors, however when rewriting to Strict
Content MathML a variant of the above rule is used. This is because the map
symbol implicitly constructs the required set or list, and apply_to_list is
not needed in this case.

Note that
when <ci>D</ci> is already a set
or list of the appropriate type for the container element, and the lambda function created
from <ci>expression-in-x</ci> is
the identity, the entire container element should be rewritten
directly as <ci>D</ci>.

In the case of set, the choice of Content
Dictionary and symbol depends on the value of the type attribute of the arguments. By default the set symbol is used, but if one of the arguments has
type attribute with value "multiset", the multiset symbol is used.
If there is a type attribute with value other than "set" or "multiset"
the set symbol should be used, and the arguments should be annotated with their type
by rewriting the type attribute using the rule
Rewrite: attributes.

4.3.4.3 N-ary Relations (classes nary-reln, nary-set-reln)

MathML allows transitive relations to be used with multiple
arguments, to give a natural expression to "chains" of
relations such as a < b < c <
d. However unlike the case of the arithmetic operators, the
underlying symbols used in the Strict Content MathML are classed as
binary, so it is not possible to use
apply_to_list as in the previous
section, but instead a similar function
predicate_on_list is used, the
semantics of which is essentially to take the conjunction of applying
the predicate to elements of the domain two at a time.

The above rules apply to all symbols in classes nary-reln.class
and nary-set-reln.class. In the latter case the choice of Content
Dictionary to use depends on the type attribute on the
symbol, defaulting to set1, but multiset1
should be used if type="multiset".

4.3.4.4 N-ary/Unary Operators (classes nary-minmax, nary-stats)

The MathML elements, max, min and some statistical
elements such as mean may be used as a n-ary function as in
the above classes, however a special interpretation is given in the
case that a single argument is supplied. If a single argument is
supplied the function is applied to the elements represented by the
argument.

The underlying symbol used in Strict Content MathML for these
elements is Unary and so if the MathML is used with
0 or more than 1 arguments, the function is applied to the set
constructed from the explicitly supplied arguments according to the
following rule.

4.3.4.4.2 Rewriting to Strict Content MathML

Rewrite: n-ary unary set

When an element,
<max/>, of class nary-stats or nary-minmax
is applied to an explicit
list of 0 or 2 or more arguments,
<ci>a1</ci><ci>a2</ci><ci>an</ci>

<apply><max/><ci>a1</ci><ci>a2</ci><ci>an</ci></apply>

a1a2an

It is is translated to the unary application of the symbol
<csymbol cd="minmax1" name="max"/>
as specified in the syntax table for the element to the set of
arguments, constructed using the
<csymbol cd="set1" name="set"/>
symbol.

Like all MathML n-ary operators, The list of arguments may be
specified implicitly using qualifier elements. This is expressed in
Strict Content MathML using the following rule, which is similar to
the rule Rewrite: n-ary domainofapplication but differs in that the
symbol can be directly applied to the constructed set of arguments and
it is not necessary to use apply_to_list.

Rewrite: n-ary unary domainofapplication

An expression of the following form,
where <max/> represents any
element of the relevant class and
<ci>expression-in-x</ci>
is an arbitrary expression involving the bound variable(s)

Note that
when <ci>D</ci> is already a set
and the lambda function created from <ci>expression-in-x</ci> is
the identity, the domainofapplication term should should be
rewritten directly
as <ci>D</ci>.

If the element is applied to a single argument the
set symbol is not used and the symbol is
applied directly to the argument.

Rewrite: n-ary unary single

When an element,
<max/>, of class nary-stats or nary-minmax
is applied to a single argument,

<apply><max/><ci>a</ci></apply>

a

It is is translated to the unary application of the symbol
in the syntax table for the element.

<apply><csymbol cd="minmax1">max</csymbol> <ci>a</ci> </apply>

maxa

Note: Earlier versions of MathML were not explicit about the correct
interpretation of elements in this class, and left it undefined as to
whether an expression such as max(X) was a trivial application of max
to a singleton, or whether it should be interpreted as meaning the
maximum of values of the set X. Applications finding that the rule
Rewrite: n-ary unary single can not be applied as the
supplied argument is a scalar may wish to use the rule
Rewrite: n-ary unary set as an error recovery.
As a further complication, in the case of the statistical functions
the Content Dictionary to use in this case depends on the desired
interpretation of the argument as a set of explicit data or a random
variable representing a distribution.

Binary operators take two arguments and simply map to OpenMath
symbols via Rewrite: element
without the need of any special rewrite rules. The binary
constructor interval is similar but uses constructor syntax
in which the arguments are children of the element, and the symbol
used depends on the type element as described in Section 4.4.1.1 Interval <interval>

4.3.4.7 Constants (classes constant-arith, constant-set)

Constant symbols relate to mathematical constants such as e and true and
also to names of sets such as the Real Numbers, and Integers.
In Strict Content MathML, they rewrite simply to the corresponding
symbol listed in the syntax tables for these elements in Section 4.4.10 Constant and Symbol Elements.

4.3.4.7.1 Schema Patterns

4.3.4.8 Quantifiers (class quantifier)

The Quantifier class is used for the forall and exists quantifiers
of predicate calculus.

4.3.4.8.1 Schema Patterns

The elements representing quantifiers are
specified in the schema pattern quantifier.class.

4.3.4.8.2 Rewriting to Strict Content MathML

If used with bind and no qualifiers,
then the interpretation in Strict Content MathML is simple. In general
if used with apply or qualifiers, the interpretation in
Strict Content MathML is via the following rule.

Rewrite: quantifier

An expression of following form where
<exists/> denotes an element of
class quantifier and
<ci>expression-in-x</ci>
is an arbitrary expression involving the bound variable(s)

where the symbols
<csymbol cd="quant1">exists</csymbol>
and
<csymbol cd="logic1">and</csymbol>
are as specified in the syntax table of the element.
(The additional symbol being
and in the case of exists and
implies in the case of forall.) When no
domainofapplication is present, no logical conjunction is necessary, and the translation
is direct.

4.3.4.9.1 Schema Patterns

4.3.5 Non-strict Attributes

A number of content MathML elements such as cn and
interval allow attributes to specialize the semantics of the
objects they represent. For these cases, special rewrite rules are
given on a case-by-case basis in Section 4.4 Content MathML for Specific Operators and Constants. However,
content MathML elements also accept attributes shared all MathML elements, and
depending on the context, may also contain attributes from other XML
namespaces. Such attributes must be rewritten in alternative form in
Strict Content Markup.

For MathML attributes not allowed in Strict Content MathML the content
dictionary mathmlattr is referenced, which provides
symbols for all attributes allowed on content MathML
elements.

4.4 Content MathML for Specific Operators and Constants

This section presents 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.

Each subsection below discusses a specific operator element,
beginning with a syntax table, giving the elements operator class. Special case rules
for rewriting as Strict Markup are introduced as needed.
However, in most cases, the generic rewrite rules for the
appropriate operator class is sufficient. In particular, unless
otherwise indicated, elements are to be rewritten using the
default Rewrite: element
rule. Note, however, that all elements in this section must be rewritten in
some fashion, since they are not allowed in Strict Content markup.

In MathML 2, the definitionURL attribute could be
used to redefine or modify the meaning of an operator
element. This use of the definitionURL attribute is deprecated in MathML 3. Instead a
csymbol element should be used. In general, the value of
cd attribute on the csymbol will correspond to
the definitionURL value.