If the breakdown of the system into separate modules is to be effective, we need a clean interface between all parts. An intermediate representation representing expressions in a generic way accomplishes this task. For an intermediate representation to be useful, it is important that it conveys and preserves all the information MathML and OpenMath objects are capable of representing. Let us look at the requirements such an intermediate representation must satisfy for use in our OpenMath/MathML interface.
Both OpenMath and MathML build expressions by using prefix operators. REDUCE's symbolic representation of expressions also uses prefix operators to construct expressions. This connection motivates us to use prefix operators in our intermediate representation, thus allowing an uncomplicated mapping between the intermediate representation, OpenMath, MathML and REDUCE's representation of expressions. Subsequently the intermediate representation is closely related to the parse trees of each language.
Given that MathML elements may take attributes changing their semantic meaning, it is necessary that attribute values are represented by the intermediate representation. Thus permitting MathML elements mapping to different OpenMath symbols (depending on their attribute values) to be correctly translated from one standard to the other. The attributes conveyed by the intermediate representation are then interpreted differently by the various modules according to the context they appear in.
Considering that OpenMath extensibility is a key issue, our intermediate representation must be able to encode objects without MathML equivalent. The unsupported OpenMath symbol and its CD will be passed on from the OpenMath to IR module to the IR to MathML module so that the MathML extension mechanism is employed.
Moreover, the intermediate representation will need to be simple to manipulate. Since RLISP is the programming language in which this interface is written, we must keep in mind the possibilities and limitations this language offers. Therefore the intermediate representation expressions will be structured as lists. Lists are the basic data structures in RLISP and there exist many commands permitting very easy and efficient manipulation of them.
Because our intermediate representation is designed in terms of the syntactic structure of both OpenMath and MathML, and certain subroutines are attached to the MathML and OpenMath production rules to produce proper intermediate encoding, we can classify our methodology as syntax-directed translation [11]. Basically, the actions of the syntax analysis phase guide the translation. Thus the intermediate code is generated as syntax analysis takes place.