To address the issues raised in this section, as well as to provide a common base on which to address the problems described in the following sections, we propose to create a software bus [94] specially designed for mathematical objects, which we call the MathBus. Conceptually the MathBus is similar to Polylith [93], but our concerns about persistence, mathematical soundness and special needs of mathematical computations lead to some important differences.
The MathBus consists of four components. First, there is a transport mechanism that enables efficient transmission of mathematical data structures from one process to another regardless of the machines on which the processes reside. A number of transport mechanisms are currently available from which we can choose, e.g., ToolTalk, OLE and OpenDoc. Due to the large size of some objects these mechanims may need to be extended or enhanced. On top of the chosen transport mechanism we will specify a reference set of data formats for dealing with common mathematical structures---real and complex numbers, vectors, matrices, polynomials, asymptotic expansions, differential equations, manifolds, simplices, graphs, trees, etc.
The MathBus is used to communicate mathematical information between two tools. In order to ensure that the parties to a communication understand each other we will provide ``customs houses'' at the entrance ramps to the MathBus. These customs houses will be responsible for translating data between the applications' data formats. In the simplest scenario, the customs house on the ``on ramp'' will translate an application's data format into the MathBus reference standard data format, while the customs house on the ``exit ramp'' will translate from the reference standard to the applications data format. (The customs house's specifications will given in a formal manner as described in Section 4 .)
To avoid the cost of constantly translating data from one format to another, the ``customs inspectors'' can negotiate ``free trade zones,'' through which data can be transmitted without inspection or translation. Once a free trade channel has been negotiated between two applications data can be transmitted at the underlying transport substrate's data rate.
Finally, we plan to develop a generic mathematics substrate that has the flexibility and fidelity of Weyl, but which is efficient and light weight enough for general use. This substrate will have easy access onto and off of the MathBus since its data formats will closely match the reference standard data formats. It will probably be easiest to write the customs house software in this substrate.