At OM2013, the author suggested and sketched a system that would use LATEX documents as Literate Programming sources for content dictionaries. This paper reports on the progress that has since been made with this system. One important milestone that has been reached is that valid .ocd les with CDDefinitions, FMPs, CMPs, and Examples are being generated.
generate every kind of element allowed in an .ocd le, generate FMPs and Examples with embedded OpenMath objects, typeset OpenMath objects (with or without simultaneously writing them to le). Some envisioned things it cannot yet do, but which would only take a small amount of programming, are: generate OME, OMB, OMF, OMSTR, OMR, or OMFOREIGN elements (so far, there has been no need for them in the content dictionaries generated), generate .sts les.
generate le(s) de ning notation for symbols.
One envisioned thing which may require a bit more thought, mostly to design a sensible user interface, is: 2
A le archive containing the current state as of 2014-06-07 of the openmathcd package|.dtx sources as well as a ready-to-use .sty les|can be downloaded from This archive also contains an example document (list4.tex) and the content dictionary generated from it (list4.ocd), which is the submitted original content dictionary mentioned above. 2.1
The openmathcd markup for objects is patterned after the XML encoding for these, but with some basic adjustments to t LATEX syntax. Markup for compound objects are environments, whereas basic objects are expressed as commands. The base grammar for an homel i may be stated as homeli ! \OMV{hnamei} j \OMI{hoptional signihdigitsi} j \OMS[hcdbasei]{hcdi}{hnamei} j \begin{OMA} homeli+ \end{OMA} j \begin{OMBIND} homeli \begin{OMBVAR} homeli++\\eenndd{{OOMMBAVTAPR}} hhoommeellii \\eenndd{{OOMMABTITNRD}} j \begin{OMATTR} \begin{OMATP} homeli homeli which is fewer characters than the XML encoding for the leaf homel is, but a few more for the compound ones; the primary gain is not in providing a signi cantly more compact encoding, but rather in switching from a format known chie y by computer scientists (XML) to a format known by most mathematicians (LATEX).
The LATEX code fragments conforming to this grammar for an homel i may be used to two ends, which typically happen in parallel: they may be transformed to valid XML encoding OpenMath objects written to a generated le, and they may be typeset to become part of the printed material in the document. For typesetting, there are currently two styles available: XML code style, which will be used inside an OMOBJ environment, and a \semiformula" style, which will be used inside sfOMOBJ and semiformulae environments. The OMOBJ and sfOMOBJ will cause the homel i to be written to a generated le (where appropriate), whereas the semiformulae environment is more for facilitating discussions of OpenMath objects. Examples of such `discussions' can be nonformalised proofs of mathematical theorems where details in the formal encoding of something as an OpenMath object are important.
A practical extension of the markup, which saves quite some typing, is the OMAS environment. Technically, it extends the above grammar for homel i with the alternative
\begin{OMAS}[hcdbasei]{hcdi}{hnamei} homeli \end{OMAS} that (as far as encoding an OpenMath object is concerned) is equivalent to
\begin{OMA} \OMS[hcdbasei]{hcdi}{hnamei} homeli \end{OMA} Using this, the formula 2 + 2 = 4 may be encoded as the homel i and an OMOBJ environment typesets that as <OMOBJ> <OMA> <OMS cd="relation1" name="eq"/> <OMA> <OMS cd="arith1" name="plus"/> <OMI>2</OMI> <OMI>2</OMI> </OMA> <OMI>4</OMI> </OMA> </OMOBJ> whereas the sfOMOBJ environment may typeset it as application(relation1.eq; application(arith1.plus; 2; 2); 4) (although what should be the defaults in this latter style is at the time of writing very much in ux). The generated XML code is in both cases the same as that typeset by the OMOBJ environment, except that the generated code also has an xmlns="http://www.openmath.org/ OpenMath" attribute on the OMOBJ element.
LATEX parses homel is by executing them, so the standard range of LATEX programming tricks are available for further streamlining of markup. 2.2
One of the great challenges when generating code, especially code that may embed arbitrary strings (as is the case with for example CMPs), is to make sure that all characters are correctly encoded. The di culty level increases even more when the source format has its own syntax rules that are di erent from those of the target format; an incomplete translation could result in a situation where users would have to know and counteract idiosyncracies of both the source and the target format. But thanks to using the harmless LATEX package (included in the above archive) for handling character strings, users of openmathcd need only worry about handling LATEX syntax, and may even use LATEX markup for accented letters (which for mathematicians may be less confusing than locating them on the keyboard).
Generated XML les are always pure ASCII because that is all TEX can do portably, but the character set supported by openmathcd is full Unicode; numerical character entities are used extensively in the generated XML les, which will be well-formed. (Getting LATEX to typeset unusual characters as appropriate glyphs can however be nontrivial.) openmathcd does not check that names only contain valid characters, but that is a trivial matter to verify using XML validation. 2.3
One design goal has been that users should not have to write long strings that are anyway xed beforehand. One class of such strings are the XML namespaces, which are inserted automatically where needed. The longest canned string is however the copyright licence; the single command \StandardOMLicence will insert the full 29 lines of the standard licence (wrapped up in a CDComment element) into the generated le(s).
It would be a minor modi cation to also put cdbase and/or version attributes on each generated OMOBJ. The author would be interested to hear arguments for or against. 3 3.1
The XML encoding of an OpenMath object can be hard to read because the information is very spread out; there can be a lot of text between the name of a function and the name of the variable it is being applied to. The semiformula style is much closer to ordinary mathematical formulae, but they too do not achieve the same togetherness of formula elements as ordinary mathematical formulae do. One reason for this might be that many of the tokens in semiformulae are still too long to allow the eye to behold groups of them as units; reducing common tokens to single glyphs could overcome this.
Changing the long application token to a simple @ makes a signi cant di erence (because
it is very common), but then it is instead the names of the symbols which stand out as being
long. When written semiformulae (or something very similar to them) have been hand-crafted,
such as for example in [
In several cases, it is hard to tell exactly how to further develop the openmathcd markup, because the correct direction depends on how the OpenMath standard will evolve. Some open tickets in the OpenMath Trac database,1 and aspects of openmathcd they would a ect, are: title FMP type=de ning Make CDSignatures or Signature use cdbase CD's CDBase declaration is mandatory Symbol's default cdbase not speci ed correctly Add Notation De nitions to OpenMath Revising the Simple Type System a ects FMP environment arguments STS generation \CDBase command OMOBJ attributes Notation speci cation STS generation It should however be observed that even a partial resolution of some of these issues|for example de ning a partial notation de nition system, or de ning a system abstractly even if not with a formal syntax|would be a great help, as it could allow development to take a few steps forward.