Extensibility

OpenMath already possesses a set of CDs covering all of MathML's semantic scope. These CDs belong to the MathML CD Group. It is clear that these CDs must be understood by an OpenMath/MathML interface. There are as well a few other symbols from other CDs which are not in the MathML CD Group but can be mapped such as matrices defined in "linalg2".

But OpenMath has the capability of extending its semantic scope by defining new symbols within new content dictionaries. This facility affects the design of any OpenMath compliant application. When it comes to translating to MathML, it is necessary that newly defined symbols are properly dealt with. A translator should have the ability to recognise any symbol with no mapping to MathML.

But how do we deal with most symbols outside the MathML CD Group? Or with new symbols which will continue to appear as OpenMath evolves? How do we map them to MathML?

MathML, as any system of content markup, requires an extension mechanism which combines notation with semantics. Extensibility in MathML is not as efficient as in OpenMath, but it is possible to define and use functions which are not part of the MathML specification. MathML content markup specifies several ways of attaching an external semantic definition to content objects.

Because OpenMath contains many elements which have no equivalent in MathML, and because OpenMath can have new CDs amended to it, we will need to use these mechanisms of extension. The <semantic> element is used in MathML to bind a semantic definition with a symbol. An example taken from the MathML specification [3] section 5.2.1^3.3shows how the OpenMath `rank' operator (non existent in MathML) can be encoded using MathML. The MathML encoding of rank is shown in figure 3.5:

**Figure 3.5:** Encoding of OpenMath symbol `rank' in MathML
$\begin{figure} \begin{verbatim}<math> <apply><eq/> <apply><fn> <semantics... ...ci> </apply> </apply> <cn>1</cn> </apply> </math>\end{verbatim}\end{figure}$

It shows that an OpenMath operator without MathML equivalent is easily contained within <semantic> tags and can be applied on any number of arguments.

This method works well when dealing with operators constructed by application (between <OMA> tags), because MathML also constructs expressions by application (between <apply> tags). It is assumed they take any number of arguments. However, OpenMath can also construct expressions by binding symbols to their arguments. As we described earlier (section 3.1), this method has no equivalent in MathML.

So what happens when a new symbol is encountered which is constructed by binding in OpenMath? Enveloping the new symbol inside <semantic> tags will produce an incorrect translation.

It is first necessary to determine if the new symbol encountered is constructed by binding or not. In order to do so, a file describing the new symbol specifying these details could be read in by the translator. This file could be the CD where the symbol is defined. But unfortunately CDs are written in a human readable way, and there is no way a program could determine the construction method of a particular symbol or the number and type of arguments it takes.

One would need to read in the STS file of a symbol. But the best way would be by checking the tag preceding the new symbol given by the OpenMath input. If it was <OMBIND> then we are sure this symbol is constructed by binding. Nonetheless, accurate mapping would be impossible. As we have seen before, MathML only offers extensibility constructing operators by application. It is not possible to define new containers, new types, or new operators constructed differently such as those constructed by binding.

While it is possible to define certain new symbols in MathML, the advantages of OpenMath extensibility would create problems for a translator to MathML. This is why it is stated in the OpenMath standard in section 2.5 that `it is envisioned that a software application dealing with a specific area of mathematics declares which content dictionaries it understands'. A MathML translator deals with the area of mathematics defined by MathML and should understand all CDs within the MathML CD Group. Any other symbols will be properly translated if they are enclosed inside <OMA> tags.