As OpenMath does not currently contain members who are familiar with the
intricacies of communications in parallel computation we have not attempted
to create a design specifically suitable for such use. Instead, we shall
mostly assume that communication is point-to-point: i.e. just two processes
are talking to one another. The term process is used loosely, and
could mean two threads of the same process, for instance.
The basic situation we consider is that of two applications, 
and 
,
where wants to request that perform some processing on a
mathematical object currently residing inside . So that can do
's bidding, must send to two pieces of information: the object
and a command saying what to do with it. The command is specified by a
simple code, while the object generally contains a more complicated
structure; so our interest is mostly directed toward the latter. In
obeying the command is perfectly entitled to converse with other
applications in a similar manner.
Note that OpenMath does not require that know the identity of
(e.g. consider the scenario where the communications medium is email). The
interprocess link itself may be either uni-directional (e.g. email) or
bi-directional (e.g. socket); the design of OpenMath allows for either
possibility. If the link is bi-directional then the command itself
specifies whether should send back to a result of some sort, and,
if so, what this result means.
While OpenMath is concerned with almost every aspect of communication needed
between and , by far the hardest part has been finding a good way to
allow the transmission of a mathematical object which preserves its
meaning, and it is to this that most effort has been devoted. We observe
that the internal representations in applications and of a
particular mathematical object may be quite different from one another, and
that this change of representation must occur automatically when sending
data using OpenMath. Moreover, OpenMath has no control over what these internal
representations might be.
We stress that the OpenMath encoding of a mathematical object captures the
semantics of that object, unlike, for example, a 
representation
which is more concerned with the visual appearance of the printed form.
Whereas it is not too difficult to produce a representation given
the OpenMath encoding of an object, the reverse is generally impossible
without extra contextual information due to ambiguities in the usual
printed form: for example, 
could be an open interval in the real
line or a point on the plane, or various other things.
At the outset OpenMath was mostly concerned with handling the sort of data
which computer algebra systems typically deal with, but it quickly became
apparent that a much wider view was necessary. Currently the types of
system which we anticipate will make use of OpenMath include: (in no special
order)
- spreadsheets,
- databases such as mathematical formula archives,
- computer algebra systems,
- word processors, text formatters, and typesetters,
- email viewers and composers,
- specialized computation systems, and
- numerical solvers linked to graphical visualisation tools.
The OpenMath Project
Design Goals