Mathematical Markup Language (MathML) Version 2.0

7 The MathML Interface

8 Document Object Model for MathML

8.1 Introduction

8.1.1 MathML DOM Extensions

A Parsing MathML

Issue (questions):Certain issues previously identified have now been given tentative solutions. Again, we would solicit any input regarding these solutions - particularly any strong disagreement!

Is aThe major intent of this hypothetical element is now answered by the`MathMLRowElement`

desirable?`MathMLDocumentFragment`

interface. This interface is essentially the`DocumentFragment`

interface, with the convenience of assuming all child nodes are`MathMLElement`

s.Is theThe answer here appears to be`MathMLElement::getMathElement()`

method sufficiently useful to justify its existence?No! Also, the`MathMLElement::insertMathElement()`

method is felt to be inappropriate. These potential methods have been omitted, not so much in favor of the base`Node`

class's get and insert methods, but in favor of more specific methods which have been added throughout the MathML DOM interfaces. The sense is that getting and setting child elements of MathML elements by index can be misleading, depending on the type of element being represented. It is still possible to obtain the child`Node`

s of a`MathMLElement`

as`NodeList`

, and to operate on those in the way indicated by`getMathElement()`

and`insertMathElement()`

. To provide more specific methods on`MathMLElement`

would imply a preference for these methods, whereas in fact use of such a general solution should probably be avoided.Some potential layers of object hierarchy have not been stipulated here, in view of the limited scope of the Level 1 DOM. Particularly glaring is the absence of aOn further reflection, we feel that it is wise to include these interfaces now to emphasize the heirarchy of objects, and the differing behaviors they may have.`MathMLPresentationElement`

/`MathMLContentElement`

dichotomy.TheThis has been by now blessed by a total absence of controversy or comment.`MathMLMultiScriptsElement`

interface.

This document extends the Core API of the DOM Level 1 to describe objects and methods specific to MathML elements in documents. The functionality needed to manipulate hierarchical document structures, elements, and attributes will be found in the core document; functionality that depends on the specific elements defined in MathML will be found in this document.

The goals of the MathML-specific DOM API are:

- To specialize and add functionality that relates specifically to MathML elements.
- To provide convenience mechanisms, where appropriate, for common and frequent operations on MathML elements.

This document includes the following specializations for MathML:

- A
`MathMLElement`

interface derived from the core interface`Element`

. MathMLElement specifies the operations and queries that can be made on any MathML element. Methods on`MathMLElement`

include those for the retrieval and modification of attributes that apply to all MathML elements. - Specializations for all MathML elements that have attributes that
extend beyond those specified in the
`MathMLElement`

interface. For all such attributes, the derived interface for the element contains explicit methods for setting and getting the values. - Special methods for insertion and retrieval of children of MathML
elements. While the basic methods available from the
`Node`

and`Element`

interfaces must clearly remain available, it is felt that in many cases they may be misleading. Thus, for instance, the`MathMLFractionElement`

interface provides for access to`numerator`

and`denominator`

attributes; a call to`getDenominator()`

is less ambiguous from a calling application's perspective than a call to`Node::replaceNode(newNode, Node::childNodes().item(2))`

.

MathML specifies rules that are invisible to generic XML processors and validators. The fact that MathML DOM objects are required to respect these rules, and to throw exceptions when those rules are violated, is an important reason for providing a MathML-specific DOM extension.

There are basically two kinds of additional MathML grammar and syntax rules. One kind involves placing additional criteria on attribute values. For example, it is not possible in pure XML to require that an attribute value be a positive integer. The second kind of rule specifies more detailed restrictions on the child elements (for example on ordering) than are given in the DTD. For example, it is not possible in XML to specify that the first child be interpreted one way, and the second in another. The MathML DOM objects are required to provide this interpretation.

MathML ignores whitespace occurring outside token elements. Non-whitespace characters are not allowed there. Whitespace occurring within the content of token elements is `trimmed' from the ends (i.e. all whitespace at the beginning and end of the content is removed), and `collapsed' internally (i.e. each sequence of 1 or more whitespace characters is replaced with one blank character). The MathML DOM elements perform this whitespace trimming as necessary. In MathML, as in XML, `whitespace' means blanks, tabs, newlines, or carriage returns, i.e. characters with hexadecimal Unicode codes U+0020, U+0009, U+000a, or U+000d, respectively.

It is expected that a future version of the MathML DOM may deal with issues which are not resolved here. Some of these are described here.

Issue (level-scopes):The interfaces described to represent MathML elements include access to a number of attributes (in the sense of XML) belonging to those elements. The intent of these methods in the core MathML interfaces (the `get'/ `set' pairs) is only to access

explicitly specifiedattributes of the elements, and specificallynotto access implicit values which may be application-specific. Calls to these interfaces to get attributes that have not been explicitly specified should return nothing (an empty`DOMString`

).It seems important to belabor this distinction in light of the nature of the MathML elements and their attributes; all of the attributes defined for MathML presentation elements are declared in the DTD with a default value of

`#IMPLIED`

, for instance. This is particularly relevant for the interface of the`mo`

element, where the`form`

attribute may be inferred from context if not given explicitly, but other attributes are normally collected from an operator dictionary available to a renderer. The variety of applications which may need to implement the MathML DOM may sometimes be concerned with validation, computation or other aspects of the document to the exclusion of rendering or editing; such applications do not need to resolve`#IMPLIED`

attributes, and thus there is no access to such resolution implied in this version of the MathML DOM.Methods for obtaining the current actual values of certain style attributes are considered desirable due to the need to make frequent calls to discover style information and the current script level and display style. Mathematics is characterized by recursive nesting of objects, frequently with implications for the calculation of style parameters such as font size. As anyone who's implemented math rendering knows, there's a constant need for this information, and it must be obtained very quickly. However, we feel that introducing methods now for dealing with these issues would be premature. CSS and XSL support for mathematics is still evolving, and the mechanisms for handling style issues in MathML documents may well evolve with them. Additionally, these issues also apply to the core XML DOM. Thus far (XML DOM level 2), issues such as privacy with regard to user-side style sheets have resulted in no core DOM methods being defined for obtaining the cascaded, computed or actual style values for a specific element, with DOM access being limited to providing the style declarations which are in effect. If a future iteration of the XML DOM were to expand this access, the methods used there would apply to the MathML DOM as well, and render any specifications we might make now obsolete.