OpenXM は, おなじタイプまたは異なるタイプの数学プロセス間の メッセージのやりとりの規約である. 開発の動機は, 手作り(または研究的な)数学ソフトの相互乗り入れの実現 および分散計算の実装が 第一であったが, もちろん数学ソフト間だけでなく, ワープロソフトや, インタラクティブな数学本, さらには数学デジタル博物館用のソフトがこの規約に従い, 数学ソフトを呼び出すことなどにも利用できる. 当面の目標は OpenXM 数学ソフトパッケージを作ることである. これはさまざまな数学ソフトを一つのパッケージとして 簡単に好きな言語より使えるようにするプロジェクトである. 現在 OpenXM.tar.gz には, asir, sm1, phc, gnuplot, tigers が入っている. OpenXM 数学ソフトパッケージプロジェクトに 参加できるように CMO の 規約を拡張していくための規約も定めるものとする.
現在専門的な数学ソフトが多数開発 されているが, 次世代の数学ソフトは他のソフトよりサブルーチンとして 呼び出せる機能をもつべきである. このように協調機能にすぐれたプログラムを書くための設計の ガイドライン, プログラム作法のようなものを提案するのも, このプロジェクトの目的である. このようなガイドラインにそってプログラムすることにより, 数学アルゴリズム自体に集中できる環境が実現できることを 期待している.
設計の方針として, (1) 単純 (2) 拡張性 (3) 実装の簡便さ (4) 実用性(5) 高信頼性(robustness),に重きをおいている.
OpenXM はなにも考えずに簡単に接続できるシステムを作ろう,というまで野心 的ではない. 数学的な object は一筋縄ではいかないし, 完全な統一規格を つくるというのは気が遠くなる仕事である. そのかわり, 今よりすこしだけこ ういったデータ交換や分散システム構築の仕事を楽にしたいというのがささや かな第1目標である. また, Mathematica や Maple といった巨大な統合ソフ トを, Free Mathematical Softwares としてわれわれ自身の手でつくっていく ための基礎でもある.
数学的な Object をどのように表現するのか, どう伝えるのかを考えることは
決してつまらない問題ではない.
このような問題は, 新しい数学記号を創造する問題と似ているかもしれない.
我々は, 数字を 0 を含んだ10進数で表記し,
微分を dx と書き, 写像を
であらわす.
これらの記号法からどれだけ多くの利益を得ているか, 思いをはせて欲しい.
OpenXM は論理的には OX 層, SM 層, CMO 層にわかれる. OX Object は, データ, コマンドに大別できる. データはこのプロジェクトのオリジナルのデータ形式 である CMO (Common Mathematical Object Format) で 送出してもよいし, MP や Open MATH などの形式を用いてもよい. SM 層は (スタックマシン)サーバを制御するための命令の あつまりであり, サーバは非同期的に動作させることが可能である. 柔軟性が高いので, IMC などのリモートプロシージャコール系の プロトコルもエミュレートできる.
OpenXM に準拠したシステム xxx を, open xxx とよぶ. たとえば, OpenXM 対応の asir は open asir であり, OpenXM 対応の kan/sm1 は open sm1 である.
OpenXM は, データ型をきめている部分と, 共通スタック言語を定めている部分にわかれる. よいたとえかどうか自信がないが, OpenXM を定義する作業は, unicode を定める作業に似ている部分もある. たとえば, 漢字は東アジアで共通に使用されているが, 国や地方単位で 形がすこしづつ違うものがある. unicode では, 似た漢字を同じ code におしこんだ. OpenXM でも, システム毎にことなるが似ているデータ型を 同じ型としてあつかう. たとえば, ``分散多項式'' の意味は, asir と kan/sm1 で異なるが, OpenXM では, 同じ型としてあつかわれる. ただしこれでは不十分な場合があるので,システム固有のデータ型も扱える ような仕組みも用意している. (さっきのたとえでは, こちらは, unicode でなく, ISO の文字符号系に対応するか.) 共通スタック言語は, ごく小数の共通コマンドをのぞき 基本的にシステム毎に固有の関数により実行される. これにより, open xxx のサーバの実装およびマニュアルの記述は いちじるしく簡単になる. システム毎に固有の関数を共通の関数名にするプロジェクトも 考えているが, 共通の関数名は OpenMath のものを利用する予定である.