Here we provide a condensed description of the current design of OpenMath. We believe this design to be fairly close to final, but stress that it may change in the light of experimental results.
When two processes wish to collaborate using OpenMath as the communications language, this is what they do: firstly they establish an interprocess link capable of acting as an OpenMath transport layer; then they hold one or more ``conversations'' over this link before finally closing it. A conversation is an environment in which to send and receive ``messages''. Each conversation comprises an initial negotiation period followed by an exchange of messages (not necessarily alternating in direction); and each message is a single OpenMath Tree normally containing one command. If only uni-directional communication is possible then the negotiation phase at the start of a conversation is omitted, and the entire transmission will be a conversation.
Meaning is conveyed by OpenMath ``symbols'' and their arrangement in an Object. The symbols themselves get their ``meanings'' from namespaces which are collections of definitions of related mathematical concepts usually from some specific area of mathematics. Each OpenMath symbol refers to exactly one of these definitions; the definitions themselves are for people rather than machines to understand.
The conversion between an Object and an application specific representation of that object is performed by an application dependent ``phrase book''. The phrase book also defines the commands the application makes available via its OpenMath interface, and the commands the application may ask other processes to perform.