[BACK]Return to genkou19991125.tex CVS log [TXT][DIR] Up to [local] / OpenXM / doc

Diff for /OpenXM/doc/Attic/genkou19991125.tex between version 1.50 and 1.83

version 1.50, 1999/12/23 03:59:44 version 1.83, 1999/12/25 08:03:16
Line 1 
Line 1 
   
 \documentclass{jarticle}  \documentclass{jarticle}
   
   %% $OpenXM: OpenXM/doc/genkou19991125.tex,v 1.82 1999/12/25 07:00:57 tam Exp $
   
   \usepackage{jssac}
 \title{  \title{
 1. いいかげんスタイルファイルをかえよう。\\  1. 意味もない修飾過剰な語句は排除しましょう. \\
 2. 意味もない修飾過剰な語句は排除しましょう。  2. せっかく fill しているのをいじらないでくれ. \\
 TCP/IP ソケットとか、TCP/IP 実装とか何のこっちゃと思いました。  3. 田村が遊んでばかりでおればかり仕事をしているのはどう考えても不公平だ.
   なんで仕事をしないのか, いい加減仕事をしろ, 田村. \\
   3.5 そういうご飯とかつまらない話じゃなくて, commit の情報をみれば田村が
   如何に仕事をしていないのかよくわかるよ. \\
   4. いい加減, Section 8 を書け.
 }  }
 \author{  
 前川 将秀\thanks{神戸大学理学部数学科},  \author{奥 谷 　 行 央\affil{神戸大学大学院自然科学研究科}
 野呂 正行\thanks{富士通研究所},                  \mail{okutani@math.sci.kobe-u.ac.jp}
 小原 功任\thanks{金沢大学理学部計算科学教室}, \\    \and  小 原 　 功 任\affil{金沢大学理学部}
 奥谷 行央                  \mail{ohara@kappa.s.kanazawa-u.ac.jp}
 %\thanks{神戸大学大学院自然科学研究科博士課程前期課程数学専攻},    \and  高 山 　 信 毅\affil{神戸大学理学部}
 \thanks{神戸大学大学院自然科学研究科数学専攻},                  \mail{takayama@math.sci.kobe-u.ac.jp}
 高山 信毅\thanks{神戸大学理学部数学教室},    \and  田 村 　 恭 士\affil{神戸大学大学院自然科学研究科}
 田村 恭士                  \mail{tamura@math.sci.kobe-u.ac.jp}
 %\thanks{神戸大学大学院自然科学研究科博士課程後期課程情報メディア科学専攻計算システム講座}    \and  野 呂 　 正 行\affil{富士通研究所}
 \thanks{神戸大学大学院自然科学研究科情報メディア科学専攻}                  \mail{noro@para.flab.fujitsu.co.jp}
     \and  前 川 　 将 秀\affil{神戸大学理学部}
                   \mail{maekawa@math.sci.kobe-u.ac.jp}
 }  }
 \date{1999年11月25日}  %\art{}
 %\pagestyle{empty}  
   
 \begin{document}  \begin{document}
 \maketitle  \maketitle
   
 \section{OpenXMとは}  \section{OpenXMとは}
   
 OpenXM は数学プロセス間でメッセージを交換するための規約である。  OpenXM は数学プロセス間でメッセージを交換するための規約である.
 数学プロセス間でメッセージをやりとりすることにより、  数学プロセス間でメッセージをやりとりすることにより,
 ある数学プロセスから他の数学プロセスを呼び出して計算を行なったり、  ある数学プロセスから他の数学プロセスを呼び出して計算を行なったり,
 他のマシンで計算を行なわせたりすることが目的である。  他のマシンで計算を行なわせたりすることが目的である.
 なお、 OpenXM とは Open message eXchange protocol for Mathematics の略である。  なお, OpenXM とは Open message eXchange protocol for Mathematics の略である.
 OpenXM の開発の発端は野呂と高山により、  OpenXM の開発の発端は野呂と高山により,
 asir と kan/sm1 を相互に呼び出す機能を実装したことである。  asir と kan/sm1 を相互に呼び出す機能を実装したことである.
   
 {\bf\large 以下の説明がなぜ必要なのかは全然分からないけれど、}  初期の実装では, 相手側のローカル言語の文法に従った文字列を送っていた.
 初期の実装では、相手側のローカル言語の文法に従った文字列を送っていた。こ  この方法では相手側のソフトが asir なのか kan/sm1 なのかを判別するなどして,
 の方法では相手側のソフトが asir なのか kan/sm1 なのかを判別するなどして、  相手側のローカル言語の文法に合わせた文字列を作成しなければならない.
 相手側のローカル言語の文法に合わせた文字列を作成しなければならない。この  このローカル言語の文法に従った文字列を送る方法は,
 ローカル言語の文法に従った文字列を送る方法は、効率的であるとはいい難いが、  効率的であるとはいい難いが, 使いやすいとも言える.
 使いやすいとも言える。  
   
 現在の OpenXM 規約では共通表現形式によるメッセージを用いている。上記の文  現在の OpenXM 規約では共通表現形式によるメッセージを用いている.
 字列を送る方法の利点を生かすため、OpenXM 規約では共通表現形式の中の文字  上記の文字列を送る方法の利点を生かすため,
 列として、ローカル言語の文法に従った文字列を用いたメッセージの交換も可能  OpenXM 規約では共通表現形式の中の文字列として,
 となっている。{\large\bf しかし、こんな細かいことをここで説明しなければ  ローカル言語の文法に従った文字列を用いたメッセージの交換も可能となっている.
 ならない理由がやっぱり分からないなぁ。構成的におかしいと思うけどなぁ。意  
 味不明。}  
   
 OpenXM 規約では通信の方法に幾らかの自由度があるが、現在のところは TCP/IP  OpenXM 規約では通信の方法に幾らかの自由度があるが,
 を用いた通信しか実装されていない。そこで、この論文では具体的な実装は  現在のところは TCP/IP を用いた通信しか実装されていない.
 TCP/IP を用いていると仮定する。  そこで, この論文では具体的な実装は TCP/IP を用いていると仮定する.
   
 \section{OpenXM のメッセージの構造}  \section{OpenXM のメッセージの構造}
   
 OpenXM で規定されている TCP/IP 実装によるメッセージはバイトストリームと  通信の方法によってメッセージの構造は変わる.
 なっており、次のような構造になっている。  前節で仮定したとおり, この論文では TCP/IP の場合についてのみ説明を行なう.
   
   OpenXM 規約で規定されているメッセージはバイトストリームとなっており,
   次のような構造になっている.
   
 \begin{tabular}{|c|c|}  \begin{tabular}{|c|c|}
 \hline  \hline
 ヘッダ  & \hspace{10mm} ボディ \hspace{10mm} \\  ヘッダ  & \hspace{10mm} ボディ \hspace{10mm} \\
 \hline  \hline
 \end{tabular}  \end{tabular}
   
 ヘッダの長さは 8 バイトであると定められている。  ヘッダの長さは 8 バイトであると定められている.
 ボディの長さはメッセージごとに異なっているが、  ボディの長さはメッセージごとに異なっているが,
 長さは $0$ でもよい。  長さは $0$ でもよい.
   
 ヘッダは次の二つの情報を持っている。  ヘッダは次の二つの情報を持っている.
 \begin{enumerate}  \begin{enumerate}
 \item   前半の 4 バイト。メッセージの種類を表わす識別子であり、  \item   前半の 4 バイト. メッセージの種類を表わす識別子であり,
         タグと呼ばれる。          タグと呼ばれる.
 \item   後半の 4 バイト。メッセージにつけられた通し番号である。  \item   後半の 4 バイト. メッセージにつけられた通し番号である.
 \end{enumerate}  \end{enumerate}
 それぞれの 4 バイトは 32 ビット整数とみなされて扱われる。  それぞれの 4 バイトは 32 ビット整数とみなされて扱われる.
 この場合に用いられる整数の表現方法の説明については後述するが、  この場合に用いられる整数の表現方法については後述するが,
 基本的に表現方法はいくつかの選択肢から選ぶことが可能となっており、  基本的に表現方法はいくつかの選択肢から選ぶことが可能となっており,
 またその選択は通信路の確立時に一度だけなされることに注意しなければならない。  またその選択は通信路の確立時に一度だけなされることに注意しなければならない.
 現在のOpenXM 規約では、タグ(整数値)として  現在のOpenXM 規約では, タグ(整数値)として
 以下のものが定義されている。  以下のものが定義されている.
   
 \begin{verbatim}  \begin{verbatim}
   #define OX_COMMAND              513
 #define OX_COMMAND      513  #define OX_DATA                 514
 #define OX_DATA     514  #define OX_SYNC_BALL            515
 足りないものは追加しましょう。怠けてはダメよ。  #define OX_DATA_WITH_LENGTH     521
   #define OX_DATA_OPENMATH_XML    523
   #define OX_DATA_OPENMATH_BINARY 524
   #define OX_DATA_MP              525
 \end{verbatim}  \end{verbatim}
   
 ボディの構造はメッセージの種類によって異なる。  ボディの構造はメッセージの種類によって異なる.
 この論文では、OX\_DATA と OX\_COMMAND で識別されるメッセージについてのみ、  タグが OX\_COMMAND となっているメッセージはスタックマシンへの命令であり,
 説明する。  それ以外のメッセージは何らかのオブジェクトを表している.
   この論文では OX\_DATA と OX\_COMMAND で識別される
   メッセージについてのみ, 説明する.
   
 既存のメッセージでは対応できない場合は、新しい識別子を定義することで新し  既存のメッセージでは対応できない場合は, 新しい識別子を定義することで新し
 い種類のメッセージを作成することができる。この方法は各数学ソフトウェアの  い種類のメッセージを作成することができる. この方法は各数学ソフトウェアの
 固有の表現を含むメッセージを作成したい場合などに有効である。新しい識別子  固有の表現を含むメッセージを作成したい場合などに有効である. 新しい識別子
 の定義方法については、\cite{OpenXM-1999} を参照すること。  の定義方法については, \cite{OpenXM-1999} を参照すること.
   
 \section{OpenXM の計算モデル}  \section{OpenXM の計算モデル}
   
 %{\Huge この節では計算モデルの話をしなければいけません}  OpenXM 規約での計算とはメッセージを交換することである. また, OpenXM 規
   約ではクライアント・サーバモデルを採用しているので, メッセージの交換はサー
   バとクライアントの間で行なわれる. クライアントからサーバへメッセージを送
   り, クライアントがサーバからメッセージを受け取ることによって計算の結果が
   得られる. このメッセージのやりとりはクライアントの主導で行われる. つまり,
   クライアントは自由にメッセージをサーバに送付してもよいが, サーバからは自
   発的にメッセージが送付されることはない. この原理はサーバはスタックマシン
   であることで実現される. スタックマシンの構造については \ref{sec:oxsm} 節
   で述べる.
   
 OpenXM 規約での計算とはメッセージを交換することである。また、 OpenXM 規  サーバがクライアントから受け取ったオブジェクト(つまり OX\_COMMAND でない
 約ではクライアント・サーバモデルを採用しているので、メッセージの交換はサー  メッセージのボディ)はすべてスタックに積まれる. スタックマシンへの命令
 バとクライアントの間で行なわれる。クライアントからサーバへメッセージを送  (OX\_COMMAND で識別されるメッセージのボディ)を受け取ったサーバは命令に対
 り、クライアントがサーバからメッセージを受け取ることによって計算の結果が  応する動作を行なう. このとき, 命令によってはスタックからオブジェクトを取
 得られる。  り出すことがあり, また(各数学システムでの)計算結果をスタックに積むことが
   ある. もし, 与えられたデータが正しくないなどの理由でエラーが生じた場合に
   はサーバはエラーオブジェクトをスタックに積む. 計算結果をクライアントが得
   る場合にはスタックマシンの命令 SM\_popCMO または SM\_popString をサーバ
   に送らなければならない. これらの命令を受け取ってはじめて, サーバからクラ
   イアントへメッセージが送られる.
   
 サーバはスタックマシンである。サーバがクライアントから受け取ったメッセー  %{\Huge 以下, 書き直し}
 ジは、タグが OX\_COMMAND でなければすべてスタックに積まれる。タグが  
 OX\_COMMAND となっているメッセージはスタックマシンへの命令であり、このメッ  
 セージを受け取ったサーバはそれに対応する動作を行なうことが期待されている。  
 サーバはメッセージを受け取らない限り、自ら何か動作をおこなわない。  
   
 {\large\bf 意味不明な書き方だけど、} これは毎回サーバへメッセージを送る  まとめると, クライアントがサーバへメッセージを送り,
 たびに、いつもサーバからのメッセージをクライアントが待つ必要がないことを  計算の結果を得るという手順は以下のようになる.
 意味する。このため、クライアントはサーバの状態を気にせずにメッセージを送  
 り、一旦メッセージを送付し終えた後、サーバへ送ったメッセージの結果をサー  
 バから待つことなしに次の動作に移ることができる。  
   
 \section{OpenXM の計算の進行方法}  \begin{enumerate}
   \item
   まず, クライアントがサーバへオブジェクトを送る. サーバは送られてきたオブ
   ジェクトをスタックに積む.
   \item
   クライアントがサーバに計算の命令を送ると, サーバはあらかじめ定めれらた
   動作を行う. 一部の命令はスタックの状態を変更する. 例えば SM\_executeFunction,
   SM\_executeStringByLocalParser などの命令は, スタック上のオブジェクトから
   計算を行う. SM\_popCMO もしくは SM\_popString は, スタックの最上位のオブ
   ジェクトを取りだし, クライアントに送り返す.
   \end{enumerate}
   
 前の節と重複しているのでもう少しちゃんと考えて欲しいのだけれど、  
   
 サーバが行うのは基本的に次の事柄だけである。  \section{OpenXM スタックマシン}\label{sec:oxsm}
 クライアントからメッセージを受け取ると、  
 サーバはまずメッセージの識別子を調べ、  
 タグが OX\_COMMAND のメッセージでなければスタックに積む。  
 タグが OX\_COMMAND のメッセージであればメッセージのボディから  
 スタックマシンの命令コードを取りだし、  
 あらかじめ規約で定められた動作を行なう。  
   
 上の説明でわかるように、  OpenXM 規約ではサーバはスタックマシンであると定義している. 以下, OpenXM
 サーバはクライアントからの指示なしに、  スタックマシンと呼ぶ. この節ではOpenXM スタックマシンの構造について説明
 自らメッセージを送らないことに注意する必要がある。  しよう.
 %(例外? ox\_asir の mathcap)。  
   
 サーバがクライアントから受け取ったメッセージはすべてスタックに積まれている。  まず, OpenXM 規約は通信時にやりとりされる共通のデータ形式については規定
 次いでサーバにスタックマシンへの命令を送ると、  するが, OpenXM スタックマシンがスタックに積む, オブジェクトの構造までは
 初めてサーバはデータをスタックに積む以外のなんらかの動作を行なう。  規定しない. つまり, オブジェクトの構造は各数学システムごとに異なっている
 このとき、必要があればサーバはスタックから必要なだけデータを取り出す。  ということである. このことは通信路からデータを受け取った際に, 各数学シス
 ここで、クライアントからの命令による動作中にたとえエラーが発生したとしても  テムが固有のデータ構造に変換してからスタックに積むことを意味する. この変
 サーバはエラーオブジェクトをスタックに積むだけで、  換は1対1対応である必要はない.
 明示されない限りエラーをクライアントへ返さないことに注意しなければならない。  
   
 結果が生じる動作をサーバが行なった場合、  次に OpenXM スタックマシンの命令コードについて説明する. OpenXM スタック
 サーバは動作の結果をスタックに積む。  マシンにおけるすべての命令は4バイトの長さを持つ. OpenXM 規約の他の規定と
 サーバに行なわせた動作の結果をクライアントが知りたい場合、  同様に, 4バイトのデータは32ビット整数と見なされるので, この論文でもその
 スタックからデータを取り出し送信を行なう命令をサーバ側へ送ればよい。  表記にしたがう. OpenXM スタックマシンに対する命令はスタックに積まれるこ
   とはない. 現在のところ, OpenXM 規約では以下の命令が定義されている.
   
 %{\Huge 以下、書き直し}  \begin{verbatim}
   #define SM_popSerializedLocalObject               258
   #define SM_popCMO                                 262
   #define SM_popString                              263
   
 クライアントがサーバへメッセージを送り、  #define SM_mathcap                                264
 計算の結果を得るという手順を追っていくと次のようになる。  #define SM_pops                                   265
   #define SM_setName                                266
   #define SM_evalName                               267
   #define SM_executeStringByLocalParser             268
   #define SM_executeFunction                        269
   #define SM_beginBlock                             270
   #define SM_endBlock                               271
   #define SM_shutdown                               272
   #define SM_setMathCap                             273
   #define SM_executeStringByLocalParserInBatchMode  274
   #define SM_getsp                                  275
   #define SM_dupErrors                              276
   
 \begin{enumerate}  #define SM_DUMMY_sendcmo                          280
 \item   まず、クライアントがサーバへメッセージを送る。  #define SM_sync_ball                              281
         サーバは送られてきたメッセージをスタックに積む。  
 \item   クライアントがサーバにスタックマシンへの命令を送ると、  
         サーバは必要なだけスタックからデータを取り出し、  
         実行した結果をスタックに積む。  
 \item   最後に「スタックからデータを取り出し送信を行なう命令」を  
         サーバへ送ると、サーバはスタックから計算結果の入っている  
         データを取り出し、クライアントへ送出する。  
 \end{enumerate}  
   
   #define SM_control_kill                          1024
   #define SM_control_to_debug_mode                 1025
   #define SM_control_exit_debug_mode               1026
   #define SM_control_ping                          1027
   #define SM_control_start_watch_thread            1028
   #define SM_control_stop_watch_thread             1029
   #define SM_control_reset_connection              1030
   \end{verbatim}
   
 \section{CMO のデータ構造}  %以下, どういうときに結果をスタックに積むかエラーの場合どうするかの説明が
   %必要であろう.
   
 OpenXM 規約では、数学的オブジェクトを表現する方法として  スタックマシンに対する命令の中には実行によって結果が返ってくるものがある.
 CMO 形式(Common Mathematical Object format)を定義している。  結果が返ってくる命令を実行した場合, サーバはその結果をスタックに積む.
 この CMO 形式を使ってメッセージを送るには、  たとえば, 命令 SM\_executeStringByLocalParser は
 タグを OX\_DATA にすればよい。  スタックに積まれているオブジェクトを
 CMO 形式におけるメッセージのボディ部分について以下で説明するが、  サーバ側のローカル言語の文法に従った文字列とみなして計算を行なうが,
 %OpenXM 規約で定義されているメッセージを実際に作成する場合、  行なった計算の結果はローカル言語で記述した文字列でスタックに積まれる.
 CMO 形式で定義されている多倍長整数を理解しておくと、  {\Large これ, 本当? 文字列で積まれるの? どこで決まってるの?}
 CMO 形式の他のデータ構造だけでなく、  
 OpenXM 規約で定義されている様々なデータ構造を理解する助けになると思えるので、  
 ここでは CMO 形式の多倍長整数のデータ構造についてのみ説明する。  
   
 CMO 形式で定義されているデータは多倍長整数以外にも  なお, 命令の実行中にエラーが起こり, 結果が得られなかった場合には,
 文字列やリスト構造などがある。どのようなデータであるかは  エラーオブジェクトがスタックに積まれる.
 データの先頭にある(メッセージの識別子とは別にある)タグを見れば  
 判別できるようになっている。  
 これはメッセージの種類の判別の仕方とおなじである。  
 なお、タグは各データ毎に 32 bit の整数で表されており、  
 多倍長整数は 20 となっている。  
 よく使われると思われる CMO 形式のタグをあげておく。  
 \begin{verbatim}  
 #define CMO_INT32  2  /* 32 ビット整数 */  
 #define CMO_STRING 4  /* 文字列        */  
 #define CMO_LIST   17 /* リスト構造    */  
 #define CMO_ZZ     20 /* 多倍長整数    */  
 \end{verbatim}  
   
 ここで TCP/IP 実装における 32 bit の整数の  
 表現方法について説明する必要がある。  
 OpenXM 規約の TCP/IP 実装ではバイトストリームで 32 bit の整数 20 を  
 {\tt 00 00 00 14} と表す方法と {\tt 14 00 00 00} と表す方法がある。  
 この表現方法の違いはクライアントとサーバの最初の接続時に  
 双方の合意で決定することになっている。  
 なお、合意がない場合には前者の表現方法  
 (以後、この表現方法をネットワークバイトオーダーと呼ぶ)を  
 使うことになっている。  
 また、負の数を表現する必要があるときには、  
 2 の補数表現を使うことになっている。  
   
 CMO 形式の多倍長整数は、 Gnu MPライブラリ等を参考にしており、  \section{CMO のデータ構造}\label{sec:cmo}
 符合付き絶対値表現を用いている。  
 タグ以降の形式は次のようになる。  
   
 \begin{tabular}{|c|c|c|c|c|} \hline  OpenXM 規約では, 数学的オブジェクトを表現する方法として CMO 形式(Common
 $f$ & $b_0$ & $b_1$ & $\cdots$ & $b_{n-1}$ \\ \hline  Mathematical Object format)を定義している. この CMO 形式にしたがったデー
   タは, 識別子が OX\_DATA であるようなメッセージのボディになることを想定し
   ている.
   
   CMO 形式におけるデータ構造は次のような構造をもつ.
   
   \begin{tabular}{|c|c|} \hline
   ヘッダ        & \hspace{10mm} ボディ \hspace{10mm} \\ \hline
 \end{tabular}  \end{tabular}
   
 ここで、 1 つの枠は 4 バイトを表し、  ヘッダは4バイトである. ボディの長さはそれぞれのデータによって異なるが,
 $f$ は符合付き 32 ビット整数を、  0でもよい.
 $b_0$, $b_1$, $\cdots$, $b_{n-1}$ は符合なし 32 ビット整数を表している。  
 さらに、 $|f| = n$ が成り立たなければならない。  
 このオブジェクトは  
 \[ \mbox{sgn}(f) \times \{ b_0 (2^{32})^0 + b_1 (2^{32})^1 + \cdots  
         + b_{n-1} (2^{32})^{n-1} \}     \]  
 という整数であると定義されている。  
 ただし、  
 \[ \mbox{sgn}(f) = \left\{ \begin{array}{ll}  
         1       & f>0 \\  
         0       & f=0 \\  
         -1      & f<0 \\ \end{array} \right.    \]  
 である。  
   
 ここで具体例をだそう。  メッセージと同様にヘッダは4バイト単位に管理される. すなわち, CMO ではヘッ
 $4294967298 = 1 \times 2^{32} + 2$ を CMO 形式の  ダは一つだけの情報を含む. この4バイトのヘッダのことをタグともいう. さて,
 ネットワークバイトオーダー、多倍長整数で表現すると、  CMO では, タグによってボディの論理的構造が決定する. すなわち, タグはそれ
 \begin{center}  ぞれのデータ構造と1対1に対応する識別子である. それぞれの論理的構造は
         {\tt 00 00 00 14 00 00 00 02 00 00 00 02 00 00 00 01}  \cite{OpenXM-1999} に詳述されている. 現在の OpenXM 規約では以下の CMO が
 \end{center}  定義されている.
 となる。また、同じ表現方法で $-1$ を表現すると、  
 \begin{center}  
         {\tt 00 00 00 14 ff ff ff ff 00 00 00 01}  
 \end{center}  
 となる。  
   
   \begin{verbatim}
   #define CMO_ERROR2  0x7f000002
   #define CMO_NULL    1
   #define CMO_INT32   2
   #define CMO_DATUM   3
   #define CMO_STRING  4
   #define CMO_MATHCAP 5
   
 \section{mathcap について}  #define CMO_START_SIGNATURE      0x7fabcd03
   #define CMO_ARRAY                16
   #define CMO_LIST                 17
   #define CMO_ATOM                 18
   #define CMO_MONOMIAL32           19
   #define CMO_ZZ                   20
   #define CMO_QQ                   21
   #define CMO_ZERO                 22
   #define CMO_DMS_GENERIC          24
   #define CMO_DMS_OF_N_VARIABLES   25
   #define CMO_RING_BY_NAME         26
   #define CMO_RECURSIVE_POLYNOMIAL 27
   #define CMO_LIST_R               28
   
 OpenXM 規約では、通信時に用いられるメッセージの種類を各ソフトウェアが制  #define CMO_INT32COEFF                 30
 限する方法を用意している。これは各ソフトウェアの実装によってはすべてのメッ  #define CMO_DISTRIBUTED_POLYNOMIAL     31
 セージをサポートするのが困難な場合があるからである。また、各ソフトウェア  #define CMO_POLYNOMIAL_IN_ONE_VARIABLE 33
 でメッセージの種類を拡張したい場合にも有効である。  #define CMO_RATIONAL                   34
 この制限(あるいは拡張)は mathcap と呼ばれるデータ構造によって行われる。  
 この節では mathcap のデータ構造と、具体的なメッセージの制限の手続きにつ  
 いて説明する。  
   
 まず、手続きについて説明しよう。  #define CMO_64BIT_MACHINE_DOUBLE           40
   #define CMO_ARRAY_OF_64BIT_MACHINE_DOUBLE  41
   #define CMO_128BIT_MACHINE_DOUBLE          42
   #define CMO_ARRAY_OF_128BIT_MACHINE_DOUBLE 43
   
   #define CMO_BIGFLOAT          50
   #define CMO_IEEE_DOUBLE_FLOAT 51
   
   #define CMO_INDETERMINATE 60
   #define CMO_TREE          61
   #define CMO_LAMBDA        62
   \end{verbatim}
   
   この中で CMO\_ERROR2, CMO\_NULL, CMO\_INT32, CMO\_DATUM, CMO\_STRING,
   CMO\_MATHCAP, CMO\_LIST で識別されるオブジェクトは最も基本的なオブジェ
   クトであって, すべての OpenXM 対応システムに実装されていなければならない.
   
   これらについての解説を行う前に記法について, 少し説明しておく.
   この論文では, 大文字で CMO\_INT32 と書いた場合には, 上記で定義した識別子
   を表わす. また CMO\_INT32 で識別されるオブジェクトのクラス(あるいはデー
   タ構造)を cmo\_int32 と小文字で表わすことにする.
   
   さて cmo を表現するための一つの記法を導入する. この記法は CMO expression
   と呼ばれている. その正確な形式的定義は \cite{OpenXM-1999} を参照すること.
   
   まず CMO expssion は Lisp 風表現の一種で, cmo を括弧で囲んだリストとし
   て表現する. それぞれの要素はカンマで区切る.
   例えば,
 \begin{quote}  \begin{quote}
 説明。説明。説明。説明。説明。  (17, {\sl int32}, (CMO\_NULL), (2, {\sl int32} $n$))
 説明。説明。説明。説明。説明。  
 説明。説明。説明。説明。説明。  
 説明。説明。説明。説明。説明。  
 \end{quote}  \end{quote}
   は CMO expression である. ここで, 小文字の斜体で表された``{\sl int32}''
   は 4バイトの任意のデータを表す記号であり, ``{\sl int32} $n$'' は同じく 4
   バイトのデータであるが以下の説明で $n$ と表すことを示す. また数字 17, 2
   などは 4バイトのデータで整数値としてみたときの値を意味する. CMO\_NULL は
   識別子(すなわち数字 1 と等価)である. この記法から上記のデータは 20 バイ
   トの大きさのデータであることが分かる.
   
 次に mathcap のデータ構造について説明する。  なお, データが CMO expression で表記できても、
   CMO であるとは限らないことに注意してほしい.
   
   {\Large
   って田村, いい加減なことを書いてるんじゃねぇよ.
   
   (CMO\_LIST, {\sl int32}, (CMO\_NULL), (CMO\_INT32, {\sl int32}))
   
   だから cmo に決まってるだろ. 少しは頭使えよな.
   }
   
   さて, この記法のもとで cmo\_int32 を次のデータ構造を持つと定義する.
 \begin{quote}  \begin{quote}
 説明。説明。説明。説明。説明。  cmo\_int32 := (CMO\_INT32,  {\sl int32})
 説明。説明。説明。説明。説明。  
 説明。説明。説明。説明。説明。  
 説明。説明。説明。説明。説明。  
 \end{quote}  \end{quote}
   同様に, cmo\_null, cmo\_string, cmo\_list, cmo\_mathcap のシンタッ
   クスは次のように定義される.
   \begin{quote}
   cmo\_null := (CMO\_NULL) \\
   cmo\_string := (CMO\_STRING, {\sl int32} $n$, {\sl string} $s$) \\
   cmo\_list := (CMO\_LIST, {\sl int32} $m$, {\sl cmo} $c_1$, $\ldots$,
   {\sl cmo} $c_m$) \\
   cmo\_mathcap := (CMO\_MATHCAP, {\sl cmo\_list})
   \end{quote}
   ただし, {\sl string}は適当な長さのバイト列を表す. $s$ のバイト長は $n$
   と一致することが要求される.
   
 具体的な mathcap の例をあげる。  %{\Huge 同様に cmo\_string, cmo\_list などを定義}
   
   {\Large 以下, 田村の書いた部分であるが, 問題外であることよ. \\
   こんないい加減なことばかり書くから, 信用されないんだよ.
   「CMO の 32 ビット整数」なんてどこで定義したんだよ. 規約にもそんな馬鹿な
   言葉はないぞ. まじめに書く気があるのか?
   }
   
   これは CMO の 32 ビット整数 $a$ を表す.
   
   他のオブジェクトも定義するために,
   ``{\sl string} $s$'' を文字列 $s$ ,
   ``{\sl cmo} $ob$'' を CMO の $ob$ とする.
   これを用いて, cmo\_string, cmo\_list を定義する.
   
   {\Large またいい加減なことを.... ``文字列'' の概念がはっきりしないでしょ
   うが. }
   
 \begin{quote}  \begin{quote}
 説明。説明。説明。説明。説明。  cmo\_string := (CMO\_STRING, {\sl int32} $len$, {\sl string} $str$) \\
 説明。説明。説明。説明。説明。  cmo\_list := (CMO\_LIST, {\sl int32} $n$, {\sl cmo} $ob_1$,
 説明。説明。説明。説明。説明。                  {\sl cmo} $ob_2$, $\cdots$,{\sl cmo} $ob_n$)
 説明。説明。説明。説明。説明。  
 \end{quote}  \end{quote}
   
   これはそれぞれ長さ $len$ の文字列 $str$ と,
   $ob_1$, $ob_2$, $\cdots$, $ob_n$ からなる長さ $n$ のリストを表す.
   
 {\large\bf これより以降は意味不明で私にはよく分かりませんでしたので、  
 たぶん読者も分からないでしょうね、というのはいいとして、}  
 CMO 形式で定義されている mathcap データは  
 受け取ることができるデータ形式を表すデータであり、  
 要求されればサーバはサーバ自身の mathcap データをスタックに積む。  
 また、クライアントから mathcap データをサーバへ送ることもでき、  
 mathcap データをサーバとクライアントの間で交換することによって、  
 お互いに相手側が受け取ることができないデータ形式で  
 メッセージを送ってしまうのを防ぐことができる。  
 なお、 mathcap データの中では CMO 形式で定義されている  
 32 bit 整数、文字列、リスト構造が使われており、  
 mathcap データに含まれている内容を理解できるためには  
 必然的にこれらも理解できる必要がある(ってことは CMO 形式のところでこれら  
 を説明しなければならないってことですね、田村君)。  
   
 OpenXM 対応版の asir サーバである ox\_asir が返す mathcap を以下に示す。  % ここで 32 bit の整数の表現方法について触れておく.
   % OpenXM 規約ではバイトストリームで 32 bit の整数 20 を
   % {\tt 00 00 00 14} と表す方法と {\tt 14 00 00 00} と表す方法がある.
   % この表現方法の違いはクライアントとサーバの最初の接続時に
   % 双方の合意で決定することになっている.
   % なお, 合意がない場合には前者の表現方法
   % (以後, この表現方法をネットワークバイトオーダーと呼ぶ)を
   % 使うことになっている.
   % また, 負の数を表現する必要があるときには,
   % 2 の補数表現を使うことになっている.
   
 なお、 $a_1$, $a_2$, $\cdots$, $a_n$ を要素に  % 先ほどの, (CMO\_INT32, 123456789) をネットワークバイトオーダーで
 持つリスト構造を {\tt [$a_1$, $a_2$, $\cdots$, $a_n$]} 、  % バイト列に直すと,
 文字列 ``string'' を {\tt "string"} 、 32 bit 整数を  % \begin{center}
 それに対応する 10 進数の整数で示す。  %       {\tt 00 00 00 02 07 5b cd 15}
   % \end{center}
   % となり,
   % (CMO\_STRING, 6, ``OpenXM'') は
   % \begin{center}
   %       {\tt 00 00 00 04 00 00 00 06 4f 70 65 6e 58 4d}
   % \end{center}
   % となる.
   
 %↓手で作ったので間違えている可能性あり。  % CMO 形式の多倍長整数は, Gnu MPライブラリ等を参考にしており,
 %%古いバージョン。差し替えの必要あり。  % 符号付き絶対値表現を用いている.
 \begin{verbatim}  % タグ以降の形式は次のようになる.
 [ [199901160,"ox_asir"],  
   [276,275,258,262,263,266,267,268,274  
     ,269,272,265,264,273,300,270,271],  
   [ [514,[1,2,3,4,5,2130706433,2130706434  
           ,17,19,20,21,22,24,25,26,31,27,33,60]],  
     [2144202544,[0,1]]  
   ]  
 ]  
 \end{verbatim}  
   
 この mathcap データのリスト構造は大きく分けて 3 つの部分に分かれる。  % \begin{tabular}{|c|c|c|c|c|} \hline
 最初の {\tt [199901160,"ox\_asir"]} の部分にはサーバの情報が入っている。  % $f$ & $b_0$ & $b_1$ & $\cdots$ & $b_{n-1}$ \\ \hline
 %この最初の要素がまたリスト構造となっており、  % \end{tabular}
 最初の要素はバージョンナンバーを、次の要素はサーバの名前を表している。  
   
 次の {\tt [276,275,$\cdots$,271]} の部分は  % ここで, 1 つの枠は 4 バイトを表し,
 スタックマシンに対する命令のうち、利用可能な命令の種類を表している。  % $f$ は符号付き 32 ビット整数を,
 スタックマシンへの命令はすべて 32 ビットの整数で表しており、  % $b_0$, $b_1$, $\cdots$, $b_{n-1}$ は符号なし 32 ビット整数を表している.
 このリストは利用可能な命令に対応する 32 ビットの整数のリストとなっている。  % さらに, $|f| = n$ が成り立たなければならない.
   % このオブジェクトは
   % \[ \mbox{sgn}(f) \times \{ b_0 (2^{32})^0 + b_1 (2^{32})^1 + \cdots
   %       + b_{n-1} (2^{32})^{n-1} \}     \]
   % という整数であると定義されている.
   % ただし,
   % \[ \mbox{sgn}(f) = \left\{ \begin{array}{ll}
   %         1       & f>0 \\
   %         0       & f=0 \\
   %         -1      & f<0 \\ \end{array} \right.  \]
   % である.
   
 最後の {\tt [ [514,[1,2,3,$\cdots$,60]],[2144202544,[0,1]] ]} の部分は  % ここで具体例をだそう.
 理解可能なデータの形式を表している。  % $4294967298 = 1 \times 2^{32} + 2$ を CMO 形式の
 この部分はさらに {\tt [514,[1,2,3,$\cdots$,60]]} と  % ネットワークバイトオーダー, 多倍長整数で表現すると,
 {\tt [2144202544,[0,1]]} にの部分に分けることができ、  % \begin{center}
 それぞれが一つのデータ形式についての情報となっている。  %       {\tt 00 00 00 14 00 00 00 02 00 00 00 02 00 00 00 01}
 どのデータ形式についての情報かは最初の要素にある整数値をみれば  % \end{center}
 分かるようになっている。  % となる. また, 同じ表現方法で $-1$ を表現すると,
 この整数値は CMO 形式では 514 となっている。  % \begin{center}
 最初のデータ形式を区別する整数値以後の要素は  %       {\tt 00 00 00 14 ff ff ff ff 00 00 00 01}
 各データ形式によってどのように使われるか定まっている。  % \end{center}
 CMO 形式では理解可能なデータのタグがリストの中に収まっている。  % となる.
 前節で CMO 形式では多倍長整数を表すタグが 20 であることを述べたが、  
 このリストに 20 が含まれているので、  
 ox\_asir は CMO 形式の多倍長整数を受け取れることがわかる。  
   
 なお、データが受け取れることと、  
 データの論理構造が理解できることとはまったく別物であるので  
 注意する必要がある。  
   
   \section{mathcap について}
   
   OpenXM 規約では, 通信時に用いられるメッセージの種類を各ソフトウェアが制
   限する方法を用意している. これは各ソフトウェアの実装によってはすべてのメッ
   セージをサポートするのが困難な場合があるからである. また, 各ソフトウェア
   でメッセージの種類を拡張したい場合にも有効である. この制限(あるいは拡張)
   は mathcap と呼ばれるデータ構造によって行われる. この節では mathcap のデー
   タ構造と, 具体的なメッセージの制限の手続きについて説明する.
   
   では, 手続きについて説明しよう.
   
   第一にサーバの機能を制限するには次のようにする. クライアントが mathcap
   オブジェクトをサーバへ送ると, サーバは受け取ったmathcap をスタックに積む.
   次にクライアントが命令 SM\_setMathCap を送ると, サーバはスタックの最上位
   に積まれている mathcap オブジェクトを取り出し, mathcap で設定されていな
   いメッセージをクライアントへ送らないように制限を行う.
   
   第二にクライアントを制限するには次のようにする. クライアントがサーバに命
   令 SM\_mathcap を送ると, サーバは mathcap オブジェクトをスタックに積む.
   さらに命令 SM\_popCMO を送ると, サーバはスタックの最上位のオブジェクト
   (すなわち mathcap オブジェクト)をボディとするメッセージをクライアントに
   送付する. クライアントはそのオブジェクトを解析して, 制限をかける.
   
   次に mathcap のデータ構造について説明する.
   mathcap は CMO の一種であるので, すでに説明したように \\
   \begin{tabular}{|c|c|} \hline
   ヘッダ        & \hspace{10mm} ボディ \hspace{10mm} \\ \hline
   \end{tabular} \\
   の構造を持ちヘッダの値は 5 である(\ref{sec:cmo} 節を参照のこと).
   ボディは cmo\_list オブジェクトでなければならない.
   
   %\begin{quote}
   %       cmo\_mathcap := (CMO\_MATHCAP,{\sl cmo} obj)
   %\end{quote}
   
   さて, mathcap オブジェクトのボディの cmo\_list オブジェクトは以下の条件を
   満たすことを要求される.
   
   まず, その cmo\_list オブジェクトは少なくともリスト長が 3 以上でなければ
   ならない.
   
   \begin{quote}
   (CMO\_LIST, {\sl int32}, {\sl cmo} $A$, {\sl cmo} $B$, {\sl cmo} $C$, $\ldots$)
   \end{quote}
   
   第一要素 $A$ はまた cmo\_list であり, リスト長は 4 以上,
   $a_1$ は 32 ビット整数でバージョンナンバーを,
   $a_2$, $a_3$, $a_4$ は文字列で
   それぞれシステムの名前, , HOSTTYPE を表すことになっている.
   \begin{quote}
   (CMO\_LIST, {\sl int32},
   {\sl cmo\_int32} $a_1$, {\sl cmo\_string} $a_2$, {\sl cmo\_string}
   $a_3$, {\sl cmo\_string} $a_4$, $\ldots$)
   \end{quote}
   
   第二要素 $B$ の部分は次のようなリスト構造をしている.
   この $b_1$, $b_2$, $\cdots$, $b_n$ はすべて cmo\_int32 である.
   \ref{sec:oxsm} 節で説明したが,
   スタックマシンへの命令はすべて {\sl int32} で表されていたことに注意しよ
   う. 各 $b_i$ は利用可能な命令をボディとした cmo\_int32 となっている.
   \begin{quote}
           (CMO\_LIST, {\sl int32} $n$,
                   {\sl cmo\_int32} $b_1$, {\sl cmo\_int32} $b_2$,
                   $\cdots$, {\sl cmo\_int32} $b_n$)
   \end{quote}
   
   第三要素 $C$ は以下のようなリスト構造をしている.
   \begin{quote}
     (CMO\_LIST, {\sl int32} $m$, \\
     \hspace{10mm} (CMO\_LIST, {\sl int32} $l_1$, {\sl cmo\_int32} $c_{11}$,
                   {\sl cmo} $c_{12}$, $\cdots$, {\sl cmo} $c_{1l_1}$) \\
     \hspace{10mm} (CMO\_LIST, {\sl int32} $l_2$, {\sl cmo\_int32} $c_{21}$,
                   {\sl cmo} $c_{22}$, $\cdots$, {\sl cmo} $c_{1l_2}$) \\
     \hspace{10mm} $\vdots$ \\
     \hspace{10mm} (CMO\_LIST, {\sl int32} $l_m$, {\sl cmo\_int32} $c_{m1}$,
                   {\sl cmo} $c_{m2}$, $\cdots$, {\sl cmo} $c_{1l_m}$))
   \end{quote}
   どの $c_{i1}$ にも 32 ビットの整数が入っており,
   OX\_COMMAND 以外の, 受け取れるメッセージのタグが入っている.
   $c_{i2}$ 以降については最初の $c_{i1}$ の値によってそれぞれ異なる.
   ここでは, 最初の要素が OX\_DATA の場合についてのみ説明する.
   この $c_{i1}$ が OX\_DATA の場合,
   $c_{i1}$, $c_{i2}$, $\cdots$, $c_{il_i}$ を要素とする cmo\_list は
   CMO 形式についての情報を表しており, $l_i=2$ と決められている.
   $c_{i1}$ にはもちろんのこと OX\_DATA が入っており,
   $c_{i2}$ は以下の図のような cmo\_list になっている.
   各要素は 32 ビットの整数であり,
   受け取ることが可能な CMO 形式のタグが入る.
   \begin{quote}
           (CMO\_LIST, {\sl int32} $k$,
                   {\sl cmo\_int32} $c_{i21}$, {\sl cmo\_int32} $c_{i22}$,
                           $\cdots$, {\sl cmo\_int32} $c_{i2k}$)
   \end{quote}
   
   具体的な mathcap の例をあげよう.
   名前が ``ox\_test'', バージョンナンバーが 199911250 のサーバで,
   PC-UNIX 上で動いていれば,
   $A$ の部分は
   \begin{quote}
   (CMO\_LIST, 4, (CMO\_INT32, $199911250$),
   {\sl cmo\_string} "ox\_test",
   {\sl cmo\_string} "199911250",
   (CMO\_STRING, 4, "i386"))
   \end{quote}
   となる. ({\Large 修正をみて, ただしく直すこと})
   
   さらに, このサーバのスタックマシンが
   命令コード 2, 3, 5, 7, 11 番を利用可能
   (実際にはこのような命令コードは存在しない)
   {\Large じゃあ書くな}
   であれば, $B$ の部分は
   \begin{quote}
           (CMO\_LIST, {\sl int32} $5$,
                   {\sl cmo\_int32} $2$, {\sl cmo\_int32} $3$,
                   {\sl cmo\_int32} $5$, {\sl cmo\_int32} $7$,
                   {\sl cmo\_int32} $11$)
   \end{quote}
   となり,
   CMO 形式の 32 ビット整数, 文字列, mathcap , リスト構造のみが
   受け取れるときには, $C$ の部分は
   \begin{quote}
     (CMO\_LIST, {\sl int32} $1$, \\
     \ \ (CMO\_LIST, {\sl int32} $2$, {\sl cmo\_int32} 514,
     \ \ \ \ (CMO\_LIST, {\sl int32} $4$,
               {\sl cmo\_int32} $2$, {\sl cmo\_int32} $4$,
               {\sl cmo\_int32} $5$, {\sl cmo\_int32} $17$)))
   \end{quote}
   となる.
   
   % なお, データが受け取れることと, データの論理構造が理解できることとはまっ
   % たく別物であるので注意する必要がある.
   %{\Huge ってなんででしょうか? データの論理構造を知らないと受け取れないと
   %思うんですが$\ldots$}
   
   % なお, この mathcap では, データの論理構造が理解できるかどうか
   % までは分からないので注意する必要がある.
   
 \section{セキュリティ対策}  \section{セキュリティ対策}
   
 OpenXM 規約は TCP/IP を用いて通信を行うことを考慮している規約である。  OpenXM 規約は TCP/IP を用いて通信を行うことを考慮している. ネットワーク
 ネットワークによって接続される現代の多くのソフトウェアと同様、  によって接続される現代の多くのソフトウェアと同様, OpenXM 規約もまた通信
 OpenXM 規約もまた通信時のセキュリティについて注意している。  時のセキュリティについて注意している. 以下, このことについて説明しよう.
 以下、このことについて説明しよう。  
   
 {\large\bf 意味不明なことを書いているが、}  {\large\bf 意味不明なことを書いているが, }
 侵入者に攻撃の機会をできるだけ与えないようするた  OpenXM では侵入者に攻撃の機会をできるだけ与えないようにするため, 接続が
 めに、接続が必要になった時のみ接続を待つようにし、  必要になった時のみ接続を待つようにし, 常に接続に関与するといったことは避
 常に接続に関与するといったことは避けている(やっぱり意味不明である)。  けている.
   (表現を少しかえただけではだめでしょう. 内容がわからないんだから. )
   
 また、侵入者が接続を行なう一瞬のすきを狙ってくる可能性もあるので、  しかし, これだけでは侵入者が接続を行なう一瞬のすきを狙ってくる可能性もあ
 接続を行なう時に接続を待つポート番号をランダムに決めている(誰が決めてい  る. そこで接続を行なう時に, 接続を待つ port 番号をランダムに決めている.
 るのかはやっぱり不明であるが)。  こうすることで, 特定の port 番号を狙って接続を行なう手口を幾ら
 さらにもう一段安全性を高めるために、  か防ぐことができる.
 接続時に 1 回だけ使用可能なパスワードを作成し、  
 そのパスワードを使って認証を行なう(誰がパスワードを決めて誰が認証を行っ  
 ているのかが不明だけど)。  
 このパスワードは一旦使用されれば無効にするので、  
 もし仮になんらかの手段でパスワードが洩れたとしても安全だと考えている。  
   
 %なお、上記のポート番号とパスワードは安全な手段で送られて  さらにもう一段安全性を高めるために, 接続時に 1 回だけ使用可能なパスワー
 %いると仮定している。  ドをクライアントが作成し, そのパスワードを使って認証を行なう. このパスワードは一旦使用
 %また、同一のコンピュータ上に悪意のあるユーザはいないと仮定している  されれば無効にするので, もし仮になんらかの手段でパスワードが洩れたとして
 %ことに注意しなければならない。  も安全である.
 %なぜなら、現在の実装ではサーバ、およびクライアントの動作している  
 %コンピュータ上ではこのポート番号とパスワードがわかってしまうためである。  
   
 なお、接続が確立した後のメッセージの送受信に関しては、  なお, 上記の port 番号とパスワードは安全な手段で送られていると仮定してい
 特に暗号化などの処置を行っているわけではない。  る. また, 同一のコンピュータ上に悪意のあるユーザはいないと仮定しているこ
 もし必要があれば、通信路の暗号化を行なう機能がある  とに注意しなければならない. なぜなら, 現在の実装ではサーバ, およびクライ
 ソフトウェア ssh を使うことを考えている。  アントの動作しているコンピュータ上ではこの port 番号とパスワードがわかっ
   てしまうためである.
   
 \section{他のプロジェクト}  なお, 接続が確立した後のメッセージの送受信に関しては, 特に暗号化などの処
   置を行っているわけではない. もし必要があれば, 通信路の暗号化を行なう機能
   があるソフトウェア ssh を使うことにしている。
   
 他のプロジェクトについても触れておこう。  
   
 OpenMath プロジェクトは数学的なオブジェクトを  \section{他のプロジェクト}
 コンピュータ上で表現する方法を決定している。  
 各ソフトウェア間でオブジェクトを交換する際の  
 オブジェクトの変換手順についても述べられている。  
 表現方法は一つだけでなく、 XML 表現や binary 表現などが  
 用意されている。  
 詳細は  
   
 http://www.openmath.org/omsoc/index.html A.M.Cohen  他のプロジェクトについても触れておこう.
   
   \begin{itemize}
   \item OpenMath\\
   OpenMath プロジェクトは数学的なオブジェクトをコンピュータ上で表現する方
   法を規定している. 各ソフトウェア間でオブジェクトを交換する際のオブジェク
   トの変換手順につても定められている. 表現方法は幾つかの段階で定められて
   いて, XML 表現やバイナリ表現などが用意されている. 詳細は
   
 以下は書いてる途中。  http://www.openmath.org/omsoc/   A.M.Cohen
   
 NetSolve  \item NetSolve
   
 http://www.cs.utk.edu/netsolve/  http://www.cs.utk.edu/netsolve/
   
   \item MP
   
 MP  
   
 http://symbolicNet.mcs.kent.edu/SN/areas/protocols/mp.html  http://symbolicNet.mcs.kent.edu/SN/areas/protocols/mp.html
   
   \item MCP
   
 MCP  
   
 http://horse.mcs.kent.edu/~pwang/  http://horse.mcs.kent.edu/~pwang/
   \end{itemize}
   
   
 \section{現在提供されているソフトウェア}  \section{現在提供されているソフトウェア}
   
 現在 OpenXM 規格に対応しているクライアントには  現在 OpenXM 規約に対応しているクライアントにはasir, sm1, Mathematica がある.
 asir, sm1, Mathematica がある。  これらのクライアントから OpenXM 規約に対応したサーバを呼び出すこと
 これらのクライアントから  ができる. 現在 OpenXM 規約に対応しているサーバソフトウェアには, asir,
 OpenXM 規格に対応したサーバを呼び出すことができる。  sm1, gnuplot, Mathematica, PHC pack などがあり,
 現在 OpenXM 規約に対応しているサーバソフトウェアには、  それぞれ ox\_asir, ox\_sm1, ox\_sm1\_gnuplot, ox\_math, ox\_sm1\_phc
  asir, sm1, gnuplot, Mathematica などがあり、  という名前で提供されている. また, OpenMath
 それぞれ ox\_asir, ox\_sm1, ox\_math という名前で提供されている。  規約の XML 表現で表現されたオブジェクトと CMO 形式のオブジェクトを変換す
 また、 OpenMath 規格の XML 表現で表現されたデータと CMO 形式の  るソフトウェアが JAVA によって実装されており, OMproxy という名前で提供さ
 データを変換するソフトウェアが JAVA によって実装されており、  れている.
 OMproxy という名前で提供されている。  
   
 \begin{thebibliography}{99}  \begin{thebibliography}{99}
   \bibitem{Ohara-Takayama-Noro-1999}
   小原功任, 高山信毅, 野呂正行:
   {Open asir 入門}, 1999, 数式処理, Vol 7, No 2, 2--17. (ISBN4-87243-086-7, SEG 出版, Tokyo).
 \bibitem{OpenXM-1999}  \bibitem{OpenXM-1999}
 野呂正行, 高山信毅.  野呂正行, 高山信毅:
 {Open XM の設計と実装 --- Open message eXchange protocol for Mathematics},  {Open XM の設計と実装 --- Open message eXchange protocol for Mathematics},
 1999/11/22  1999/11/22
 \bibitem{Ohara-Takayama-Noro-1999}  
 小原功任, 高山信毅, 野呂正行.  
 {Open asir 入門}, 1999, 数式処理, Vol 7, No 2, 2--17. (ISBN4-87243-086-7, SEG 出版, Tokyo).  
 \end{thebibliography}  \end{thebibliography}
   
 \end{document}  \end{document}
Legend:
Removed from v.1.50  
changed lines
  Added in v.1.83
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>