Testing of the interface has also revealed its limitations. Various aspects of the translation process have not been properly solved. It is important that we enumerate the areas where the translator performs poorly.
In section 3.3.2 we mentioned that some OpenMath operators encoded their bound variables within lambda expressions. We also said that this was not compulsory. The translator however only deals with expressions where the bound variable is within a lambda expression. Other cases cause the translator to abort promptly.
The analysis in section 3.2.1 discussed the importance of defining each operator's scope. The OpenMath/MathML translator gets confused when scopes are ambiguous and aborts.
MathML element partialdiff is not translated properly in most cases. Only when the variables of differentiation have an order of derivation equal to one. In all other cases the translator produces incorrect results or aborts.
The translator will reject MathML expressions containing operators
defined within <semantic> tags. This is clearly something which
will have to be implemented in the future, since the <semantic>
tags may contain OpenMath code.
Finally, there is an aspect of REDUCE which limits the interface. Contrary to XML, which is case sensitive as is stated in the XML standard [10], REDUCE is case insensitive. Consequently when translating an expression with variables or function names using capital letters, REDUCE will produce only small letters. This may in some occasions create confusion for the user or even distort the semantics.