**NOTE - MathML Compliance 20001217**

This version: | http://www.w3.org/Math/iandi/compliance20001217.html |

Latest version: | http://www.w3.org/Math/iandi/compliance |

Previous version: | None |

Editors: | Patrick Ion (MR / AMS) <ion@ams.org> |

Robert Miner (Design Science) <RobertM@mathtype.com> |

Copyright
©2000 W3C^{®} (MIT, INRIA,
Keio), All Rights Reserved. W3C liability,
trademark,
document
use and software
licensing rules apply.

This is a draft report setting out the views of the W3C Math Working Group on issues of compliance arising from the specification of MathML 2.0. This draft is part of the submission by the W3C Math Working Group to the W3C Direction requesting Proposed Recommendation status for the MathML 2 specification. This is a W3C document for public distribution.

As the long process of development of MathML 2 as a revision to MathML 1.01 draws to a close, a good number of implementation efforts using MathML have been started. There are shipping products and a government agency deploying MathML. Issues of how far a given implementation may be said to comply with a specification as rich as one for much of mathematics are complex. MathML is a markup language with two clear complementary parts, and possibilities for extensions. In addition, mathematics is used to employing a very large character set and conventions for display are not universally accepted. MathML is intended to facilitate mathematics on the Web, not to constrain it. It is very different from a low-level engineering protocol where what compliance means is fairly obvious; in that case everyone has to do very much the same or the protocol is of no use. This document explains the issues involved and gives the position of the W3C Math Working Group on them.

1 Introduction

2 Guidelines for Compliance

2.1
MathML Compliance Types

2.1.1 MathML Test Suite

2.1.2 MathML Validation

2.1.3 Deprecated MathML 1.x Features

2.2
Handling of Errors

There are already many software developments that have begun to make use of MathML, and MathML 2 in particular. The W3C Math Working Group has posted a report, first written during the Candidate Recommendation review period, on Implementations and Interoperability. It is expected that this will be updated from time to time as the adoption of MathML spreads. The Math Working Group has also made available a public Test Suite of examples of MathML and how they are expected to be handled. In addition, verification of MathML has been added to the options available under the W3C's public Validator service.

With all these resources and a well-written specification of MathML 2 what difficulties can there be in recognizing compliance? This note, which is largely based on parts of the MathML 2 specification's Chapter 7 is intended to explain why the matter is worth considering a little and to help understand the natural but different levels of compliance that will be found in different contexts where MathML is used.

MathML has two obvious parts that are both countervailing and cooperative. They are mark-up for Presentation and mark-up for mathematical Content. The Presentation mark-up (Chapter 3) uses about thirty elements, and Content (Chapter 4) about one hundred and fifty. It is readily possible to undertake an implementation, especially a first one, using MathML that concentrates on one type of mark-up or the other. Then there input and output considerations, display and editing aspects, and so on.

There are many different kinds of software employing MathML: editors, translators, processors and renderers. What it means to support MathML varies widely between applications. For example, the issues that arise with a MathML-compliant validating parser are very different from those for a MathML-compliant equation editor.

In this section, guidelines are given for describing different types of MathML support, and for quantifying 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 of implementations and interoperability between MathML applications by accurately characterizing their capabilities.

A valid MathML expression is an XML construct determined by the MathML DTD together with the additional requirements given in the MathML2 specification. The syntactical constraints set out in the DTD do not adequately capture all the constraints of the specification, which often involve additional contextual information not expressible at the level of a DTD. It is hoped that in due course a MathML Schema, making use of the developing W3C Schema technology will be able capture more of the intended MathML semantics in a formal way. But even then there will be no alternative sometimes but to look at the relevant part of the specification. Another resource for concrete examples of proper usage is the MathML Test Suite.

Define a `MathML processor' to mean any application that can accept, produce, or `round-trip' a valid MathML expression. An example of an application that might round-trip a MathML expression could be an editor that writes a new file even though no modifications are made.

Three forms of MathML compliance are defined in the MathML 2 specification:

- A MathML-input-compliant processor must accept all valid MathML expressions, and faithfully translate all MathML expressions into application-specific form allowing native application operations to be performed.
- A MathML-output-compliant processor must generate valid MathML, faithfully representing all application-specific data.
- A MathML-round-trip-compliant processor must preserve MathML equivalence. Two MathML expressions are `equivalent' if and only if both expressions are required to be processed identically in all situations by the MathML 2 specification.

The precise definitions governing when two MathML expressions are equivalent are embedded in context throughout the specification, and are cannot easily be extracted in a self-contained form. However, the main cases can be summarized:

- The
`mfenced`

element and a certain corresponding`mrow`

structure are equivalent. - An
`menclose`

element with the`notation`

attribute set to 'radical' is equivalent to the`msqrt`

element. - An
`mi`

element with certain combinations of character data and`mathvariant`

attribute values is equivalent to an`mi`

element with a single Unicode character from the Secondary Multilingual Plane. - An
`mspace`

element with certain line-breaking attributes set is equivalent to a line-breaking character entity defined in the Unicode Private Use Area in MathML 1.01. - An expression with a redundant
`mrow`

wrapper is equivalent to the expression without the wrapper.

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 suggested rendering rules throughout Chapter 3 [Presentation Markup]. However, in general, developers are given wide latitude in interpreting what kind of MathML implementation is meaningful for their own particular application. In particular, no attempt is made to define what is meant by faithful representation of application specific data. Since the precise meaning of mathematical expressions is often a subject of debate, the notion of faithful representation is, of necessity, imprecise in borderline cases. In the majority of cases, however, what constitutes a faithful representation will be obvious.

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

- In order to be MathML-input-compliant, 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-compliant.
- 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-compliant.

As the previous examples show, to be useful, the concept of MathML compliance 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 compliance. 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 MathML Test Suite.

The test suite consists of a large number of MathML expressions categorized by markup category and the 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 compliant 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.

To test MathML-output-compliant processors, there is also MathML validation accessible over the Web as an option under the W3C Validation Service. Developers of MathML-output-compliant 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 MathML Test Suite as a part of their decision processes.

MathML 2.0 contains a number of MathML 1.x features 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 MathML 2.0 compliance.

- In order to be MathML-output-compliant, authoring tools may not generate MathML markup containing deprecated features.
- In order to be MathML-input-compliant, rendering and reading tools must support deprecated features if they are to be MathML 1.x compliant. They do not have to support deprecated features to be considered MathML 2.0 compliant. However, all tools are encouraged to support the old forms as much as possible.
- In order to be MathML-round-trip-compliant, a processor need only preserve MathML equivalence on expressions containing no deprecated features.

If a MathML-input-compliant 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
are valid, and to render error messages (rendered as if enclosed in
an `merror`

element) in place of invalid expressions.

MathML-output-compliant 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.