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