8. Document Object Model for MathML

Mathematical Markup Language (MathML) Version 2.0
7 The MathML Interface
8 Document Object Model for MathML
8.1 Introduction
   8.1.1 Scope of Level 1 and Level 2
A Parsing MathML

Issue (questions): The following is provided as a first draft approximation. There are a number of issues on which we would solicit input. Some of these are:
  1. Is a MathMLRowElement desirable? This would (presumably) provide no additional interface beyond MathMLElement, but could be useful as a return value for various methods on other objects. Methods which are defined below to return NodeLists could return MathMLRowElements instead. The advantage would be in retrieval of the children for further processing, as they could be retrieved directly as MathMLElements. In other words, the object would give us a generic container object to be used wherever appropriate/convenient.
  2. Contrariwise (to quote TweedleDum), is the MathMLElement::getMathElement() method sufficiently useful to justify its existence?
  3. 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 a MathMLPresentationElement / MathMLContentElement dichotomy. In fact, there seem to be no interface considerations (in Level 1, at any rate) which are appropriate to these hypothetical elements. (The nature of potential applications might suggest that we separate content elements from presentation elements in an optional module (would vice-versa really be workable?); this would follow the lead of the W3 DOM WG's structuring of Level 2. But it doesn't seem an undue burden to place on a DOM-compliant application to support both sets of elements.)
  4. The MathMLMultiScriptsElement interface will probably elicit some comment. There may easily be methods deemed unnecessary here, or methods missing but deemed necessary. Please take a look.

8.1. Introduction

This document extends the Level 1 Core API 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:

This document includes the following specializations for MathML:

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.

8.1.1. Scope of Level 1 and Level 2

Issue (level-scopes): Two levels of the MathML DOM have been specified. Unadorned interface names are part of level 1, while those whose names end in the digit 2 are part of level 2. The two levels have been specified to aid impementors. 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 (level 1) interfaces (the `get'/`set' pairs) is only to access explicitly specified attributes of the elements, and specifically not to access implicit values which may be application-specific. Calls to the level 1 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 <mo> element's interface, 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 the level 1 MathML DOM. The level 2 interfaces provide methods that supply values for all attributes that have defaults or have values obtained from an operator dictionary.