Although there are surely many ways to tackle the translation problem, there are a few requirements which must be respected by any OpenMath/MathML translator. Mainly that content dictionaries and symbols are dealt with correctly during translation in both directions.
In OpenMath, symbols always appear next to the content
dictionary they belong to. The <OMS>
element always takes two attributes: the symbol's name and the
symbol's corresponding CD. Two symbols with the same name coming from
different CDs are considered to be different.
When parsing OpenMath, a translator must ensure that the symbols read
belong to the correct CDs, if not it should conclude the symbol has a
meaning it does not understand and deal with it accordingly. Because
an OpenMath/MathML translator will understand all MathML related CDs,
symbols encountered are considered valid if they come from this CD
group. Symbols with the same name, but from unknown CDs should be
enclosed within <semantic> tags when possible.
We face the same requirement when generating OpenMath. All OpenMath
symbols output from the translator must appear next to their correct
CDs. If we are translating the MathML element <plus/>, the
corresponding OpenMath symbol plus must appear next to the
arith1 CD.
This requires a translator to keep a database relating each understood
symbol with its CD. This database must allow the translator to detect
unknown symbols, or to accept some symbols from different CDs with the
same name which have MathML equivalents. This is the case of
matrix which belongs to various CDs (linalg1, linalg2) as do
the symbols in, inverse, setdiff, vector,
arcsinh to name a few.
These symbols belonging to various CDs pose a problem when translating from MathML to OpenMath. Which CD do we choose? inverse for instance belongs to fns1 and arith2. Priority should be given to the CD belonging to the MathML CD group. If both CDs belong to the MathML then common sense should guide which CD to place. It is up to the designer.
An OpenMath/MathML interface must be very rigorous when dealing with content dictionaries. Any mistake may produce invalid OpenMath or reject valid OpenMath expressions.