The design goals for OpenMath were determined and justified in the Objectives
Report, where they are described fully; below we summarize these goals.
Since the publication of the Objectives Report, we have not found cause to
modify the goals given there.
- faithful:
-
OpenMath must preserve all important or costly information during
transmission. This includes both structural and semantic information.
Here ``important'' means that the information is indispensable for correct
interpretation and ``costly'' means expensive in terms of computation costs.
- unrestricted:
-
OpenMath must be suitable for transmitting data from many different
areas of mathematics. Ideally, any mathematical entity which can be
represented in a computer can be transmitted using OpenMath.
- flexible:
-
OpenMath must be able to handle floating point and other data. Examples of
the latter are mathematical formulae, a variety of finite discrete
mathematical objects, formal proofs, algorithms, and integers of unlimited
size. Additionally, it must be able to transmit potentially large amounts
of (machine precision) numerical data reasonably efficiently.
- extensible:
-
The ability to extend the standardized core of OpenMath is vital since new
areas of mathematics will continually be implemented and applied.
Moreover, the mechanism for extending OpenMath should be sufficiently simple
and well-documented that extensions can be produced by reasonably competent
people outside the group of original OpenMath implementors.
- efficient:
-
Efficiency is important but must be tempered with concerns for flexibility
and extensibility. OpenMath should be efficient enough so that potential
users will not normally be forced to consider any alternative, highly
specialized uses excepted.
- medium independent:
-
One must be able to use OpenMath to transmit data using at least these forms
of transmission: email, cut-and-paste, local and non-local interprocess
links (for example, Unix sockets, OLE Automation, OLE Data Transfer), and
saving to and retrieving from files.
- simple:
-
OpenMath must permit fairly straight-forward implementation of
compliant senders and receivers so that authors of mathematical (or
other) packages can easily supply their own OpenMath interfaces.
The efficiency aspects to bear in mind are the size of the OpenMath encoding,
the cost of conversion from the sender's internal representation to the
OpenMath encoding, and the cost of conversion from the OpenMath encoding to the
receiver's internal representation. However, OpenMath has no control over the
internal representation used by applications, so the intention is that the
OpenMath object representation be sufficiently rich that conversion between it
and most reasonable application-specific representations will usually be
straight-forward and efficient. Furthermore, the extensibility of OpenMath
means that it can adapt to take advantage of new representations for
mathematical data.
The Basic Situation
The OpenMath Project
The OpenMath Layers