- 7.1 Embedding MathML in HTML
- 7.2 Interacting with Renderers
- 7.2.1 MathML Compliance
- 7.2.2 Handling Of Errors
- 7.2.3 XML Extensions to the MathML
- 7.2.4 An Attribute for Unspecified Data
- 7.3 Future Extensions

Embedded MathML notation must interact with a variety of renderers and processors. The MathML core specification given in this document is designed to be a "fullform" markup, capable of encoding very complex presentational and semantic structure. Therefore, much of the future potential for MathML lies in its ability to smoothly interface with more specialized, more user-friendly input and output models.

In this section, we describe the basic interface mechanisms that are part of the MathML core specification. We also describe some of the future extensions planned by the HTML Math working group.

The most fundamental interface mechanism provided by the MathML core specification governs the embedding of MathML markup in an HTML document. MathML proposes two sets of top level tags, which surround all other MathML markup in an HTML document.

Since MathML is a verbose language designed to be explicit and complete for automatic processing, many authors will likely choose to use terser notations which may be filtered into MathML markup. Indeed, many renderers will probably transparently accept several input syntaxes, while returning MathML when queried for cut and paste, or searching operations.

In order to accommodate alternative syntaxes, MathML provides one set of top-level tags for pure MathML XML markup, and one for other input syntax intended for processing by a specific renderer. More specifically the content model is explicitly declared to be XML MathML markup for one tag set, while the content model for the second tag set is PCDATA.

One consequence is that special markup characters such as '<' and '&' must be escaped in alternative input syntaxes. Alternatively, the XML-lang specification provides a mechanism for marking a block of input as CDATA, which eliminates the need of escaping individual markup characters. To mark a block of text as CDATA, surrounded it by the character sequence <![CDATA[ ... ]]>.

Each tag set contains a tag for block level notation, and another for character level notation. In typesetting terminology, these are typically called display and in-line notation respectively.

MATH XML/character level (inline) MATHDISP XML/block level (display) F CDATA/character level (inline) FD CDATA/block level (display)

**Note:** The tag names F and FD are meant to be mnemonic for
"formula" and "formula display" in analogy with math and math
display. Since we anticipate that the XML full form mark up will
typically be written with the aid of authoring tools, and that
authors writing mark up by hand are more likely to use an alternative
input syntax, we have elected to propose the short tag names for the
PCDATA content model.

**Note:** The MathML DTD does not currently permit F and FD
elements embedded within MATH or MATHDISP elements. However, issues
concerning embedding other data in MathML are still under discussion
by the HTML-Math working group, especially as they pertain to other
input syntax, and this is subject to change in later working draft
revisions.

- TYPE="
*mime type*" - The type attribute assigns a MIME type to the tag content. This
attribute is used to invoke an embedded element, such as a Java
applet, plug-in or ActiveX control, to render the tag
content as described in the next section.
- NAME="
*value*" - Provided for scripting.
- CLASS="
*value*"

STYLE="*value*" - Provided for Cascading Style Sheet compatibility.
- HEIGHT=
*nn*

WIDTH=*nn*

BASELINE=*nn*

- It is our hope and belief that embedded elements will soon be able
to dynamically negotiate height, width and baseline alignment with
browsers. However, these optional attributes are suggested as an
interim solution for browser makers that want to support Math, but are
unable to provide dynamic resizing and alignment.
- OVERFLOW="
*pan|scroll|elide|truncate|scale*" - In cases where size negotiation is not possible or fails (for example in the case of an extremely long equation), this attribute is provided to suggest an alternative processing method to the renderer.
*pan*- The window provides a viewport into the larger complete display of the mathematical expression. The viewport can be moved by clicking and holding down the primary mouse button, and then dragging the mouse cursor in the desired direction.
*scroll*- Again the window provides a viewport into the larger complete display of the mathematical expression. Horizontal or vertical scrollbars 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.
- ALTIMG=
*URL*

ALTTEXT="*value*" - These attributes provide graceful fallbacks for browsers that do
not support embedded elements, or images respectively.
- MACROS="
*URL**URL*..." - This attribute provides a way of pointing to external macro
definition files. Macros are not part of the MathML core
specification, but we anticipate defining a macro mechanism in a
subsequent proposal. Macros may also be utilized by alternative input
syntaxes.

Ideally, Math will be supported natively by browsers. However, until that happens, we anticipate that Math will be implemented via embedded elements. Automatically invoking an embedded element to process the content of the MATH/MATHDISP or F/FD elements is a two step process. First, the Web browser must determine which embedded element renderer to use, and second, the embedded element must determine what input syntax it has been given.

We propose using the TYPE attribute to provide the necessary information for both steps. More specifically, the TYPE attribute is used to associate a MIME type with the content of the top-level MathML elements, and we suggest a MIME type naming scheme which encodes both the renderer to be used, and the input syntax.

In addition, there are two practical considerations which facilitate the use of the TYPE attribute in this way.

- The mechanisms for assigning MIME types already exist in HTML. In
particular, the TYPE attribute provides a way of specifying a MIME
type for a particular instance, and the META tag is proposed as a way
of defining a document wide default MIME type for a tag.
- The mechanisms for registering and automatically invoking embedded elements such as plug-ins based on MIME type already exist in Web browser.

One weakness of this scheme is that it requires embedded element renderer vendors and authors to adopt consistent MIME type conventions. In the long run, we anticipate that widely used input syntaxes will be assigned official MIME types. In the short run, however, authors using alternative input syntaxes will have to assign MIME types with specific renderers in mind.

We suggest the following convention:

```
````application/x-`*encoding[-renderer]*

Thus, for generic MathML markup, the MIME type is
`application/x-mathml`

. For browser registry, we also
suggest the standard file extension `.mml`

be used.
**Example:**

A user downloads and installs renderer A, and
registers it with the browser for the
`application/x-mathml`

MIME type to process generic MathML.
However renderer A also accepts TeX as an input syntax, and therefore
during the installation process, it requests to be registered for
`application/x-tex`

as well. Later, the user discovers
renderer B provides additional features, such as
cut and paste capability. Therefore, the user downloads,
installs and registers renderer B for the
`application/x-mathml-rendererB`

MIME type.

An author then creates a document that contains the the following lines in the document header:

```
````<META Content-Math-Type="application/x-mathml">`

<META Content-MathDisp-Type="application/x-mathml">

Later, the document contains the following three expressions:
```
<MATH><MSUP><MI>x</MI><MN>2</MN></MSUP></MATH>
```

```
<MATH TYPE="application/x-mathml-rendererB"><MI>α<MI><MO>=</MO>
```0.4436733</MN></MATH>

```
<F TYPE="application/x-tex">x^2</F>
```

When our hypothetical user views this document, renderer A is invoked
to process the first and third expressions, while renderer B is invoked
for the second.
Ideally, any HTML tag which makes sense in a math context should be permitted within the scope of a MathML expression. However, given what is currently possible by way of interaction between browsers and embedded elements, the burden of supporting arbitrary HTML tags in a MathML renderer is unrealistically heavy.

Moreover, the problem of supporting HTML tags in XML applications is not specific to MathML. Since other groups are working on solutions to this problem, the MathML core standard does not specify which HTML tags must be permitted within a MathML expression.

At the same time, there are a number of HTML tags that have an obvious, natural interpretation within a MathML expression. MathML renderers are strongly encouraged to support these tags if possible.

The list of recommended tags includes:

- <A HREF="..."> ... </A>
- <FONT SIZE="..." COLOR="...">
- <IMG SRC="..." ALIGN="..." ALT="...">
- <BIG>
- <SMALL>
- <B>
- <I>
- <U>
- <BR>

Eventually, one hopes many different MathML renderers will be implemented. In addition to supporting the MathML core language, it is reasonable to assume that some of these renderers will provide additional specialized capabilities. Consequently, the MathML core specification provides mechanisms for passing additional information directly to renderers that can take advantage of it.

It is important to clearly specify what it means to be a MathML compliant renderer. This serves two purposes. First, authors can be assured that their documents will be generally accessible if they refrain from using proprietary extensions. Second, software developers can be assured of the criteria for interoperability.

**Definition:** An MathML compliant renderer must:

- Accept and give an intelligible rendering for all well-formed MathML expressions, as specified by the MathML DTD together with the additional requirements given in the text of this document.
- An embedded MathML-compliant renderer must return a MathML
expression encoding the expression currently being rendered, when
queried by a document object model API.
- If the input expression was a well-formed MathML expression, it must return this expression.
- If the input was some alternative input syntax (e.g. the renderer was invoked via <F> or <FD> tags), it must return a well-formed MathML expression which encodes the rendering it gave.

- A MathML-compliant renderer must also return a MathML expression when needed for cut-and-paste or drag-and-drop operations, if these operations are implemented by the renderer. The same conditions on the expression returned which apply for document object model queries also apply in this case.

Beyond this, the MathML core specification makes no demands of individual renderers. However, in order to guide developers, the MathML specification includes advisory material; for example, there are suggested rendering rules included in section 3. In addition, the remainder of this section makes suggestions about a number of interface issues a renderer should address in some fashion

If a MathML compliant renderer receives input containing one or more elements with an illegal number or type of arguments, it should nonetheless attempt to render all the input in an intelligible way, i.e. to render normally those parts of the input which were well-formed, and to render an error message (rendered as if enclosed in an <MERROR> element) explaining what was wrong with the incorrect expression, in the same place as a correct rendering would have appeared, and perhaps including normal renderings of the correctly formed argument elements.

Note that the <MERROR> element is provided for the
convenience of other mathematical software applications which
*generate* MathML expressions from possibly invalid input.

The set of elements and attributes specified in the MathML core proposal are necessary for rendering common math expressions. It is recognized that not all mathematical notation is covered by this set of elements, that new notations are continually invented, and that sub-communities within mathematics often have specialized notations; and furthermore that the explicit extension of a standard is a necessarily slow and conservative process; this implies that the MathML standard could never explicitly cover all the presentational forms used by every sub-community of authors and readers of mathematics.

In order to facilitate the use of MathML by the widest possible audience, and to enable its smooth evolution to encompass more notational forms (perhaps eventually covered by explicit extensions to the standard), the set of tags and attributes is open-ended, in the sense described in this section.

The MathML tag set is described by an XML-compliant DTD, which necessarily limits the tags and attributes to those which occur in the DTD. Renderers desiring to accept nonstandard elements or attributes, and authors desiring to include these in documents, should accept or produce documents which conform to an appropriately extended XML-compliant DTD which has the standard MathML DTD as a subset.

MathML compliant renderers are allowed, but not required, to accept nonstandard tags and attributes, and to render them in any way. If a renderer does not accept some or all nonstandard tags, it is encouraged to either handle them as errors as described above for elements with the wrong number of arguments, or to render their arguments as if they were arguments to an <MROW>, in either case rendering all standard parts of the input normally.

The MathML attributes described in the MathML core proposal are necessary for display and content markup. Ideally, the MathML attributes should be an open-ended list so that users could add specific attributes for specific renderers. However, this can't be done within the confines of a single XML DTD. Although it can be done using extensions of the standard DTD, as described earlier, some authors will wish to use nonstandard attributes while remaining strictly in compliance with the standard DTD.

To allow this, this proposal also allows the attribute
**other**="..." for all elements, for use as a hook to
pass on renderer-specific information. In particular, it can be used
as a hook for passing information to audio renderers, computer algebra
systems, and for pattern matching in any future macro/extension
mechanism. This idea is used in other languages. For example,
Postscript comments are widely used to pass information that is not
part of Postscript.

At the same time, the intent of the "other" attribute is not to encourage software developers to use this as a loophole for circumventing the MathML core markup conventions. We trust both renderers and authors will use the "other" attribute judiciously.

The value of the **other** attribute should be a string containing
an attribute list in valid XML format (i.e., attr1="val1"
attr2="val2" ..., with appropriate escaping of the
double quotes). Renderers which accept nonstandard attributes
directly should also accept them when they occur within the
string value of the **other** attribute. This is not required for
attributes specifically documented by the MathML standard.

The MathML core specification is designed to encode complex notational and semantic structure in an explicit and flexible way. The price for such expressive power is that MathML is verbose compared to markup languages like TeX.

To some extent, authoring tools can address this issue; MathML is designed to be easy to generate and process. At the same time, electronic documents are written by authors, not machines, and most authors of technical documents are already comfortable and efficient with other editors, authoring tools and markup languages.

In order to help authors bridge the gap over the coming years, it is vital for MathML to accommodate the present conventions for human authoring of technical material. This is also important for the conversion of existing legacy documents

The HTML Math working group charter specifies that the group will make a proposal on extension protocols for MathML to help accommodate hand authoring, among other things, in May, 1998. The proposal will address at least two such extensions: macros, and alternative input syntaxes.

Macros can play a very useful role in encoding mathematical content and meaning, since symbolic manipulation is so pervasive in mathematics. At the same time, it is difficult to devise a coherent, general macro system for MathML, because there are so many distinct applications for macros:

**Abbreviation:**One common use of macros is for abbreviation. Authors needing to repeat some complicated but constant notation can define a macro. This greatly facilitates hand authoring. Macros that allow for substitution of parameters facilitate such usage even further.**Extension of Content Markup:**By defining macros for semantic objects, for example a binomial coefficient, or a Bessel function, one can in effect extend the content markup for MathML. Such a macro could include an explicit semantic binding, or such a binding could be easily added by an external applications. Narrowly defined disciplines should be able to easily introduce standardize content markup by using standard macro packages. For example, the OpenMath project could release macro packages for attaching OpenMath content markup up.**Rendering and Style Control:**Another basic way in which macros are often used is to provide a way of controlling style and rendering behavior by replacing high level macro definitions. This is especially important for controlling the rendering behavior of HTML Math content tags in a context sensitive way. Such a macroing capability is also necessary to provide a way of attaching renderings to user defined XML extensions to the MathML core.**Accessibility:**Reader controlled style sheets are important in providing accessibility to MathML. For example, a reader listening to a voice renderer might by default hear a bit of MathML presentation markup read as "D sub x super 2 of f". Knowing the context to be multivariable calculus, the reader may wish to use a style sheet or macro package which instructs the renderer to render this MSUBSUP element as "second derivative with respect to x of f".

Authors who write electronic documents by hand need terse and easy to type input syntaxes. Many will want to continue to use TeX, for example. Others, who are not already users of TeX, or wish to take advantage of the ability of MathML to carry semantic meaning, might be expected to learn new languages which require only a minimal amount of additional information, and which are then parsed by correspondingly more sophisticated software.

The HTML Math working group will investigate several alternative input syntaxes. In particular, the group will study augmented operator precedence based languages, such as that proposed by Wolfram Research, an SGML-based syntax, variants of TeX, and very simple syntaxes for easy input of common notations.

The group will also consider the issues surrounding the implementation of filters from existing markup languages like TeX and ISO12083.

It is worth noting that the <F> and <FD> tags in the MathML core specification provide a mechanism for using an alternative input syntax. Developers interested in implementing renderers which process an alternative input syntax can do so independently of the HTML Math working group activity.