===================================================================
RCS file: /home/cvs/OpenXM/doc/Attic/genkou19991125.tex,v
retrieving revision 1.32
retrieving revision 1.67
diff -u -p -r1.32 -r1.67
--- OpenXM/doc/Attic/genkou19991125.tex	1999/12/21 10:02:03	1.32
+++ OpenXM/doc/Attic/genkou19991125.tex	1999/12/24 08:08:48	1.67
@@ -1,163 +1,160 @@
 \documentclass{jarticle}
 
-\title{タイトル未定}
-\author{
-前川 将秀,
-野呂 正行,
-小原 功任, \\
-奥谷 幸夫,
-高山 信毅,
-田村 恭士
+%% $OpenXM: OpenXM/doc/genkou19991125.tex,v 1.66 1999/12/24 00:01:21 tam Exp $
+
+\usepackage{jssac}
+\title{タイのトル}
+\title{意味もない修飾過剰な語句は排除しましょう。}
+
+\author{奥 谷 　 行 央\affil{神戸大学大学院自然科学研究科}
+		\mail{okutani@math.sci.kobe-u.ac.jp}
+  \and	小 原 　 功 任\affil{金沢大学理学部}
+		\mail{ohara@kappa.s.kanazawa-u.ac.jp}
+  \and	高 山 　 信 毅\affil{神戸大学理学部}
+		\mail{takayama@math.sci.kobe-u.ac.jp}
+  \and	田 村 　 恭 士\affil{神戸大学大学院自然科学研究科}
+		\mail{tamura@math.sci.kobe-u.ac.jp}
+  \and	野 呂 　 正 行\affil{富士通研究所}
+		\mail{noro@para.flab.fujitsu.co.jp}
+  \and	前 川 　 将 秀\affil{神戸大学理学部}
+		\mail{maekawa@math.sci.kobe-u.ac.jp}
 }
-\date{1999年11月25日}
-%\pagestyle{empty}
+\art{}
 
 \begin{document}
 \maketitle
 
 \section{OpenXMとは}
 
-OpenXM は数学プロセス間でメッセージを交換するための規約である。数学プロ
-セス間でメッセージをやりとりさせることにより、ある数学プロセスから他の数
-学プロセスを呼び出して計算を行なったり、他のマシンで計算を行なわせたりす
-ることが目的である。なお、 OpenXM とは Open message eXchange protocol
-for Mathematics の略である。
-OpenXM の開発の発端は野呂正行と高山信毅により、 asir と kan/sm1 を
-相互に呼び出す機能を実装したことである。
-%\footnote{この段落必要?}
+OpenXM は数学プロセス間でメッセージを交換するための規約である。
+数学プロセス間でメッセージをやりとりすることにより、
+ある数学プロセスから他の数学プロセスを呼び出して計算を行なったり、
+他のマシンで計算を行なわせたりすることが目的である。
+なお、 OpenXM とは Open message eXchange protocol for Mathematics の略である。
+OpenXM の開発の発端は野呂と高山により、
+asir と kan/sm1 を相互に呼び出す機能を実装したことである。
 
-発端となった asir と kan/sm1 での実装時には、
-お互いに相手側のコマンド文字列を送っていた。
-この方法は現在の OpenXM 規約でも形を変えて可能ではあるが、
-使いやすい反面、効率的であるとはいい難い。
-さらに、この方法では相手側のソフトが asir なのか kan/sm1 なのかを
-判別して、相手側に合わせてコマンド文字列を作成する必要がある。
+初期の実装では、相手側のローカル言語の文法に従った文字列を送っていた。
+この方法では相手側のソフトが asir なのか kan/sm1 なのかを判別するなどして、
+相手側のローカル言語の文法に合わせた文字列を作成しなければならない。
+このローカル言語の文法に従った文字列を送る方法は、
+効率的であるとはいい難いが、使いやすいとも言える。
 
-これ以外の方法として、
-OpenXM 規約では共通表現形式によるメッセージも用意している。
-OpenXM 規約独自のデータ形式である CMO 形式(Common Mathematical Object format)
-以外にも、 MP や OpenMath の XML, binary 表現形式といった他の形式をも
-扱えるようにしてある。
-なお、現在の OpenXM 規約では、
-前述のコマンド文字列も CMO 形式などの何らかのデータ形式の中の
-文字列として表現して送る必要がある。
+現在の OpenXM 規約では共通表現形式によるメッセージを用いている。
+上記の文字列を送る方法の利点を生かすため、
+OpenXM 規約では共通表現形式の中の文字列として、
+ローカル言語の文法に従った文字列を用いたメッセージの交換も可能となっている。
 
-\section{OpenXM の計算モデル}
+OpenXM 規約では通信の方法に幾らかの自由度があるが、
+現在のところは TCP/IP を用いた通信しか実装されていない。
+そこで、この論文では具体的な実装は TCP/IP を用いていると仮定する。
 
-{\Huge この節では計算モデルの話をしなければいけませんよ、田村君}
+\section{OpenXM のメッセージの構造}
 
-OpenXM 規約でのメッセージの交換はサーバとクライアントの間で行なわれる。
-クライアントからサーバへメッセージを送り、
-メッセージに対する返答を
+通信の方法によってメッセージの構造は変わる。
+前節で仮定したとおり、この論文では TCP/IP の場合についてのみ説明を行なう。
 
-サーバはスタックマシンであると仮定されており、
-サーバがクライアントから受け取ったメッセージはすべてスタックに積まれる。
-OpenXM のメッセージの中にはサーバに行なわせたい動作に対応するデータがあり、
-このメッセージを受け取ったサーバはそれに対応する動作を
-行なうことが期待されている。
-ただし、サーバは命令されない限り何も動作を行なおうとはしない。
-このため、クライアントはサーバへ送ったメッセージの結果を
-サーバから
+OpenXM 規約で規定されているメッセージはバイトストリームとなっており、
+次のような構造になっている。
 
-これはクライアントがサーバへ一旦メッセージを送付し終えると、
-あとはサーバ側の状態を気にせずにクライアントは
-クライアント自身の仕事に戻れることを意味する。
+\begin{tabular}{|c|c|}
+\hline
+ヘッダ	& \hspace{10mm} ボディ \hspace{10mm} \\ 
+\hline
+\end{tabular}
 
+ヘッダの長さは 8 バイトであると定められている。
+ボディの長さはメッセージごとに異なっているが、
+長さは $0$ でもよい。
 
-\section{OpenXM のメッセージの構造}
+ヘッダは次の二つの情報を持っている。
+\begin{enumerate}
+\item	前半の 4 バイト。メッセージの種類を表わす識別子であり、
+	タグと呼ばれる。
+\item	後半の 4 バイト。メッセージにつけられた通し番号である。
+\end{enumerate}
+それぞれの 4 バイトは 32 ビット整数とみなされて扱われる。
+この場合に用いられる整数の表現方法については後述するが、
+基本的に表現方法はいくつかの選択肢から選ぶことが可能となっており、
+またその選択は通信路の確立時に一度だけなされることに注意しなければならない。
+現在のOpenXM 規約では、タグ(整数値)として
+以下のものが定義されている。
 
-{\Huge この節では構造の話をしなければいけませんよ、田村君}
-
-OpenXM のメッセージはバイトストリームであり、次のような構造を持つ。
 \begin{verbatim}
-ヘッダ  ボディ
+#define	OX_COMMAND              513
+#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}
-ヘッダの長さは8バイトであると定められている。ボディの長さはメッセージご
-とに異なる($0$でもよい)。
-ヘッダは次の二つの情報を持つ。
-\begin{enumerate}
-\item 前半の4バイト。タグと呼ばれ、メッセージの種類を表わす識別子である。
-\item 後半の4バイト。メッセージにつけられた通し番号である。
-\end{enumerate}
 
-それぞれの4バイトは32ビット整数とみなされて処理される。
-この場合に用いられる整数の表現方法については後述するが、基本的に
-表現方法はいくつかの選択肢から選ぶことが可能であり、
-また選択は通信路の確立時に一度だけなされることに注意しておこう。
+ボディの構造はメッセージの種類によって異なる。
+この論文では OX\_DATA と \\
+OX\_COMMAND で識別されるメッセージについてのみ、説明する。
 
-{\Huge 以下、書き直してね。}
+既存のメッセージでは対応できない場合は、新しい識別子を定義することで新し
+い種類のメッセージを作成することができる。この方法は各数学ソフトウェアの
+固有の表現を含むメッセージを作成したい場合などに有効である。新しい識別子
+の定義方法については、\cite{OpenXM-1999} を参照すること。
 
-ボディの中のデータがどのように格納されているかは
-各データ形式がそれぞれ独立に決められるようになっている。
-もし、 OpenXM 規約でメッセージのやりとりを行ないたいが、
-まだ規約で定義されていないデータ形式を使いたい場合は、
-タグをまだ使われてなさそうな値
-(システム固有の表現のために推奨されている値がある)
-に設定し、 ボディの部分にデータを埋め込めばよい。
-なお、すべてのメッセージに ボディが必要というわけではなく、
-ボディのないメッセージも OpenXM 規約には存在することに
-注意しなければならない。
+\section{OpenXM の計算モデル}
 
-サーバに対する動作に対応したデータは SM 形式として定義されている。
-SM 形式以外のデータでは、サーバは受け取ったデータをスタックに積む
-以外の動作をしないことになっている。
-つまり、 SM 形式のデータがデータを受け取る以外の動作を
-サーバに行なわせる唯一のデータ形式である。
-このデータを受け取る以外の動作の中には、
-データになんらかの加工を施す動作も入っている。
-このデータになんらかの加工を施す動作の中には
-数学的な演算を行なう動作も含まれている。
-以後、データになんらかの加工を施す動作のことを計算と呼ぶことにする。
+OpenXM 規約での計算とはメッセージを交換することである。また、 OpenXM 規
+約ではクライアント・サーバモデルを採用しているので、メッセージの交換はサー
+バとクライアントの間で行なわれる。クライアントからサーバへメッセージを送
+り、クライアントがサーバからメッセージを受け取ることによって計算の結果が
+得られる。
 
-\section{OpenXM の計算の進行方法}
+サーバはスタックマシンである。サーバがクライアントから受け取ったメッセー
+ジは、タグが OX\_COMMAND でなければすべてスタックに積まれる。タグが 
+OX\_COMMAND となっているメッセージはスタックマシンへの命令であり、このメッ
+セージを受け取ったサーバはそれに対応する動作を行なうことが期待されている。
 
-OpenXM における計算とはメッセージの交換のことである。既に計算モデルの節
-で説明したが(説明されているはずである)、OpenXM はサーバ・クライアントモ
-デルを採用していて、サーバはスタックマシンの構造を持つ。サーバが行うのは
-基本的に次の事柄に限られる。クライアントからメッセージを送られるとサーバ
-は、まずメッセージの識別子を調べ、OX\_COMMAND でなければスタックに積む。
-OX\_COMMAND であればメッセージのボディからスタックマシンのオペコードを取
-りだし、あらかじめ規約で定められたアクションを起こす。
+%{\large\bf 意味不明な書き方だけど、}
+サーバはメッセージを受け取らない限り、自ら何か動作を行なおうとはしない。
+これはクライアントが毎回サーバへメッセージを送るたびに、
+いつもサーバからのメッセージを待つ必要がないことを意味する。
+このため、クライアントはサーバの状態を気にせずにメッセージを送り、
+一旦メッセージを送付し終えた後、
+送ったメッセージの結果をサーバから待つことなしに次の動作に移ることができる。
 
-上の説明でわかるように、サーバはクライアントからの指示なしに、自らメッセー
-ジを送ることはない(例外? ox\_asir の mathcap)。
+\section{OpenXM の計算の進行方法}
 
-{\Huge 以下、書き直してね、田村君}
+%前の節と重複しているのでもう少しちゃんと考えて欲しいのだけれど、
 
+前節の説明でわかるように、
+サーバはクライアントからの指示なしに、
+自らメッセージを送らない。
+%(例外? ox\_asir の mathcap)。
 
-% クライアントがサーバへなんらかの計算を行なわせる場合、
-% クライアントからサーバへ計算させたいデータをメッセージとして送り、
-% そしてその結果をサーバからメッセージで受け取ることによって計算は行なわれる。
-% ただし、サーバは結果の送信すらも命令されなければ行なうことはなく、
-% クライアントは結果を受け取らずにサーバに次々と
-% 計算を行なわせることも可能である。
-
-サーバがクライアントから受け取ったメッセージはすべてスタックに積まれる。
-ただし、このままでは受け取ったメッセージに含まれるデータを
-スタックに積み上げていくだけで、サーバは計算を行なおうとはしない。
-次いでサーバに行なわせたい動作に対応したデータを送ると、
-初めてサーバは計算などの、なんらかの動作を行なう。
+サーバがクライアントから受け取ったオブジェクトはすべてスタックに積まれている。
+次いでサーバにスタックマシンへの命令を送ると、
+初めてサーバはデータをスタックに積む以外のなんらかの動作を行なう。
 このとき、必要があればサーバはスタックから必要なだけデータを取り出す。
 ここで、クライアントからの命令による動作中にたとえエラーが発生したとしても
 サーバはエラーオブジェクトをスタックに積むだけで、
-明示されない限りエラーを返さないことに注意しなければならない。
+明示されない限りエラーすらもクライアントへ返さないことに
+注意しなければならない。
 
 結果が生じる動作をサーバが行なった場合、
-サーバは動作の結果をスタックに積んでいる。
+サーバは動作の結果をスタックに積む。
 サーバに行なわせた動作の結果をクライアントが知りたい場合、
-スタックからデータを取り出し送信を行なう命令に対応した SM 形式のデータを
-サーバ側へ送ればよい。
+スタックからデータを取り出し送信を行なう命令をサーバ側へ送ればよい。
 
-クライアントがサーバへ計算を行なわせ、結果を得るという手順を追っていくと、
-次のようになる。
+%{\Huge 以下、書き直し}
 
+クライアントがサーバへメッセージを送り、
+計算の結果を得るという手順を追っていくと次のようになる。
+
 \begin{enumerate}
-\item	まず、クライアントがサーバへ計算させたいデータを送る。
-	サーバは送られてきたデータをスタックに積む。
-\item	クライアントがサーバに「計算を行なう動作に対応したデータ」を
-	送ると、サーバは必要なだけスタックからデータを取り出し、
-	実行した計算の結果をスタックに積む。
-\item	最後に「データを取り出し送信を行なう命令に対応したデータ」を
+\item	まず、クライアントがサーバへメッセージを送る。
+	サーバは送られてきたメッセージをスタックに積む。
+\item	クライアントがサーバにスタックマシンへの命令を送ると、
+	サーバは必要なだけスタックからデータを取り出し、
+	実行した結果をスタックに積む。
+\item	最後に「スタックからデータを取り出し送信を行なう命令」を
 	サーバへ送ると、サーバはスタックから計算結果の入っている
 	データを取り出し、クライアントへ送出する。
 \end{enumerate}
@@ -165,48 +162,70 @@ OX\_COMMAND であればメッセージのボディからスタックマシ
 
 \section{CMO のデータ構造}
 
-OpenXM 間でやりとりされるメッセージを実際に作成する場合、
+OpenXM 規約では、数学的オブジェクトを表現する方法として
+CMO 形式(Common Mathematical Object format)を定義している。
+この CMO 形式を使ってメッセージを送るには、
+タグを OX\_DATA にすればよい。
+CMO 形式におけるデータ構造について以下で説明するが、
+%OpenXM 規約で定義されているメッセージを実際に作成する場合、
 CMO 形式で定義されている多倍長整数を理解しておくと、
-CMO 形式の他のデータ構造だけでなく、 OX 形式、 SM 形式のデータを
-理解する助けになると思えるので、 CMO 形式の多倍長整数の
-データ構造について説明する。
+CMO 形式の他のデータ構造だけでなく、
+OpenXM 規約で定義されている様々なデータ構造を理解する助けになると思えるので、
+ここでは CMO 形式の多倍長整数のデータ構造についてのみ説明する。
 
 CMO 形式で定義されているデータは多倍長整数以外にも
 文字列やリスト構造などがある。どのようなデータであるかは
-データの先頭にあるタグを見れば判別できるようになっている。
-これはメッセージのデータの判別の仕方とおなじである。
+データの先頭 4 バイトにある(メッセージの識別子とは別にある)タグを見れば
+判別できるようになっている。
+これはメッセージの種類の判別の仕方とおなじである。
 なお、タグは各データ毎に 32 bit の整数で表されており、
 多倍長整数は 20 となっている。
+よく使われると思われる CMO 形式のタグをあげておく。
+\begin{verbatim}
+#define CMO_INT32    2 /* 32 ビット整数 */
+#define CMO_STRING   4 /* 文字列        */
+#define CMO_MATHCAP  5 /* mathcap(後述) */
+#define CMO_LIST    17 /* リスト構造    */
+#define CMO_ZZ      20 /* 多倍長整数    */
+\end{verbatim}
+
 ここで 32 bit の整数の表現方法について説明する必要がある。
-OpenXM ではバイト列で 32 bit の整数 20 を
+OpenXM 規約ではバイトストリームで 32 bit の整数 20 を
 {\tt 00 00 00 14} と表す方法と {\tt 14 00 00 00} と表す方法がある。
 この表現方法の違いはクライアントとサーバの最初の接続時に
 双方の合意で決定することになっている。
-なお、合意がない場合には
-前者の表現方法(以後、この表現方法を network byte order と呼ぶ)を
+なお、合意がない場合には前者の表現方法
+(以後、この表現方法をネットワークバイトオーダーと呼ぶ)を
 使うことになっている。
 また、負の数を表現する必要があるときには、
 2 の補数表現を使うことになっている。
 
-表現したい多倍長整数の絶対値を 2 進数で表した場合の桁数を $n$ と
-したとき、次にくるデータは $[(n+31)/32]$ を 32 bit の整数となる。
-これは多倍長整数の絶対値を $2^{32}$ 進数で表した場合の桁数ととってもよい。
-ただし、表現したい数が負の場合は $[(n+31)/32]$ を 32 bit の整数で表した値を
- 2 の補数表現で負にして、正の場合と区別する。
+CMO 形式の多倍長整数は、 Gnu MPライブラリ等を参考にしており、
+符合付き絶対値表現を用いている。
+タグ以降の形式は次のようになる。
 
-表現したい多倍長整数の絶対値が $2^{32}$ 進数で $(b_0 b_1 ... b_k)_{2^{32}}$
-と表せるとき、次にくるデータは $b_0$, $b_1$, $\cdots$, $b_k$ を
-それぞれ 32 bit の整数で表現した値となる。
-%以下は書き直しの必要があるかも...
-なお、 GNU MP LIBRARY を用いると、
-C 言語から多倍長整数や任意精度浮動小数を扱うことができる。
-$b_0$, $b_1$, $\cdots$, $b_k$ をそれぞれ 32 bit 整数で表現した値は
-この GNU MP LIBRARY で用いられている多倍長整数で使われている形式を
-参考にして合わせてある。
+\begin{tabular}{|c|c|c|c|c|} \hline
+$f$ & $b_0$ & $b_1$ & $\cdots$ & $b_{n-1}$ \\ \hline
+\end{tabular}
 
+ここで、 1 つの枠は 4 バイトを表し、
+$f$ は符合付き 32 ビット整数を、
+$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.	\]
+である。
+
 ここで具体例をだそう。
-$4294967298 = 1 \times 2^{32} + 2$ を network byte order の多倍長整数で
-表現すると、
+$4294967298 = 1 \times 2^{32} + 2$ を CMO 形式の
+ネットワークバイトオーダー、多倍長整数で表現すると、
 \begin{center}
 	{\tt 00 00 00 14 00 00 00 02 00 00 00 02 00 00 00 01}
 \end{center}
@@ -217,82 +236,132 @@ $4294967298 = 1 \times 2^{32} + 2$ を network byte ord
 となる。
 
 
-\section{MathCap について}
+\section{mathcap について}
 
-サーバおよびクライアント双方ともに OpenXM で規定されている
-メッセージの中のデータ形式をすべて受け取れるわけではない。
-しかも、 OpenXM 規約で規定されているデータ形式だけが
-受渡しに使われるというわけではない。
-そこで、 OpenXM では相手側が受け取ることができるデータ形式を
-収得する方法を用意している。
+OpenXM 規約では、通信時に用いられるメッセージの種類を
+各ソフトウェアが制限する方法を用意している。
+これは各ソフトウェアの実装によってはすべてのメッセージを
+サポートするのが困難な場合があるからである。
+また、各ソフトウェアでメッセージの種類を拡張したい場合にも有効である。
+この制限(あるいは拡張)は CMO 形式で定義されている mathcap と
+呼ばれるデータ構造によって行われる。
+この節では mathcap のデータ構造と、
+具体的なメッセージの制限の手続きについて説明する。
 
-CMO 形式で定義されている MathCap データは
-%理解可能なメッセージの
-受け取ることができるデータ形式を表すデータであり、
-要求されればサーバはサーバ自身の MathCap データをスタックに積む。
-また、クライアントから MathCap データをサーバへ送ることもでき、
-MathCap データをサーバとクライアントの間で交換することによって、
-お互いに相手側が受け取ることができないデータ形式で
-メッセージを送ってしまうのを防ぐことができる。
-なお、 MathCap データの中では CMO 形式で定義されている
-32 bit 整数、文字列、リスト構造が使われており、
-MathCap データに含まれている内容を理解できるためには
-必然的にこれらも理解できる必要がある。
+まず、手続きについて説明しよう。
+クライアント側の mathcap をサーバへ送ると、
+すでに説明したように、サーバは受け取った mathcap をスタックに積み上げる。
+次にクライアントはスタックマシンへの命令をサーバへ送ることにより、
+サーバはスタックに積まれている mathcap を取り出し、
+mathcap で設定されていないメッセージをクライアント側へ
+送らないように設定する。
+サーバ側の mathcap が欲しい場合には以下のようにする。
+クライアントがサーバに mathcap を要求すると、
+サーバはサーバ自身の mathcap をスタックに積む。
+さらにサーバにスタックからデータを取り出し送信を行なう命令を送れば、
+サーバはスタックにある mathcap をクライアントへ送出する。
+このようにしてクライアントはサーバ側の mathcap を受け取れるわけである。
 
-OpenXM 対応版の asir サーバである ox\_asir が返す MathCap を以下に示す。
+次に mathcap のデータ構造について説明する。
+mathcap は CMO 形式で定義されており、
+1 つの CMO 形式のオブジェクトを持つ。
 
-%なお、 $a_1$, $a_2$, $\cdots$, $a_n$ を要素に
-%持つリスト構造を {\tt [$a_1$, $a_2$, $\cdots$, $a_n$]} 、
-%文字列 ``string'' を {\tt "string"} 、 32 bit 整数を
-%それに対応する 10 進数の整数で示す。
+そのオブジェクトは以下で説明する 3 つの要素からなるリストでなければならない。
 
-%↓手で作ったので間違えている可能性あり。
-%%古いバージョン。差し替えの必要あり。
-\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}
+\[	\begin{tabular}{|c|c|c|} \hline
+	$A$ & $B$ & $C$	\\ \hline
+	\end{tabular}	\]
 
-<<<<<<< genkou19991125.tex
-この MathCap データのリスト構造は大きく分けて 3 つの部分に分かれる。
-最初の {\tt [199901160,"ox\_asir"]} の部分にはサーバの情報が入っている。
-%この最初の要素がまたリスト構造となっており、
-最初の要素はバージョンナンバーを、次の要素はサーバの名前を表している。
+最初の要素 $A$ の部分は以下の図のようなリスト構造をしており、
+$a_1$ は 32 ビット整数でバージョンナンバーを、
+$a_2$ は文字列でシステムの名前を表すことになっている。
 
-次の {\tt [276,275,$\cdots$,271]} の部分は
-サーバに対する動作に対応した理解可能なデータの種類を表している。
-サーバの動作に対するデータはすべて 32 bit の整数で表しており、
-このリストは理解可能なデータに対応する 32 bit 整数のリストとなっている。
+\[	\begin{tabular}{|c|c|} \hline
+	$a_1$ & $a_2$	\\ \hline
+	\end{tabular}	\]
 
-最後の {\tt [ [514,[1,2,3,$\cdots$,60]],[2144202544,[0,1]] ]} の部分は
-理解可能なデータの形式を表している。
-この部分はさらに {\tt [514,[1,2,3,$\cdots$,60]]} と
-{\tt [2144202544,[0,1]]} にの部分に分けることができ、
-それぞれが一つのデータ形式についての情報となっている。
-どのデータ形式についての情報かは最初の要素にある整数値をみれば
-分かるようになっている。
-この整数値は CMO 形式では 514 となっている。
-最初のデータ形式を区別する整数値以後の要素は
-各データ形式によってどのように使われるか定まっている。
-CMO 形式では理解可能なデータの tag がリストの中に収まっている。
-前節で CMO 形式では多倍長整数を表す tag が 20 であることを述べたが、
-このリストに 20 が含まれているので、
-ox\_asir は CMO 形式の多倍長整数を受け取れることがわかる。
+2 番目の要素 $B$ の部分は次のようなリスト構造をしている。
+この $b_1$, $b_2$, $\cdots$, $b_n$ はすべて 32 ビットの整数である。
+スタックマシンへの命令はすべて 32 ビットの整数で表しており、
+各 $b_i$ は利用可能な命令に対応する 32 ビットの整数となっている。
 
-%%このリストの要素はまたリストとなっており、
-%この最後の部分もまたリストとなっており、
-%あるデータ形式で理解可能なものを表現したリストを要素としている。
-%{\tt [514,[1, 2, $\cdots$]]} の最初の 514 はこのリストが CMO 形式
-%での理解可能なデータを表していることを示しており、
-%その後のリストでは CMO 層で定義されているデータのうち、
-%理解可能なデータの tag が並んでいる。
+\[	\begin{tabular}{|c|c|c|c|} \hline
+	$b_1$ & $b_2$ & $\cdots$ & $b_n$	\\ \hline
+	\end{tabular}	\]
 
+3 番目の要素 $C$ は以下のようなリスト構造をしている。
+\[  \overbrace{
+	\begin{tabular}{|c|c|c|c|} \hline
+	$c_1$ & $c_2$ & $\cdots$ & $c_n$	\\ \hline
+	\end{tabular}
+   }^{C}	\]
+%$n$ は OX\_COMMAND 以外の受け取れるメッセージのタグの種類の数に等しい。
+%要素数は 1 でももちろん構わない。
+各 $c_i$ もまた以下のようなリスト構造となっており、
+どの $c_i$ も最初の要素が 32 ビットの整数となっている。
+\[  \overbrace{
+	\begin{tabular}{|c|c|c|c|c|} \hline
+	$c_{i1}$ (32 ビットの整数) & $c_{i2}$ & $c_{i3}$ &
+		$\cdots$ & $c_{im}$	\\ \hline
+	\end{tabular}
+   }^{c_i}	\]
+このリストの最初の整数値は受け取れるメッセージのタグが入っている。
+$c_{i2}$ 以降については最初の $c_{i1}$ の値によってそれぞれ異なる。
+ここでは、最初の要素が OX\_DATA の場合についてのみ説明する。
+この $c_{i1}$ が OX\_DATA の場合、
+リスト $c_i$ は CMO 形式についての情報を表しており、
+$m=2$ と決められている。
+$c_{i1}$ にはもちろんのこと OX\_DATA が入っており、
+$c_{i2}$ は以下の図のようなリスト構造になっている。
+各要素は 32 ビットの整数であり、
+受け取ることが可能な CMO 形式のタグが入る。
+\[  \overbrace{
+	\begin{tabular}{|c|c|c|c|c|} \hline
+	$c_{i21}$ & $c_{i22}$ & $\cdots$ & $c_{i2l}$	\\ \hline
+	\end{tabular}
+   }^{c_{i2}}	\]
+
+%なお、 mathcap データの中では CMO 形式で定義されている
+%32 bit 整数、文字列、リスト構造が使われており、
+%mathcap データに含まれている内容を理解できるためには
+%必然的にこれらも理解できる必要がある
+%(ってことは CMO 形式のところでこれらを
+%説明しなければならないってことです)。
+
+具体的な mathcap の例をあげよう。
+%なお、 $a_1$, $a_2$, $\cdots$, $a_n$ を要素に
+%持つリスト構造を {\tt [$a_1$, $a_2$, $\cdots$, $a_n$]} 、
+%文字列 ``string'' を {\tt "string"} 、 32 bit 整数を
+%それに対応する 10 進数の整数で示す。
+名前が ``ox\_test'' 、バージョンナンバーが 199911250 のサーバであれば、
+$A$ の部分は
+\begin{tabular}{|c|c|} \hline
+199911250 & "ox\_test" \\ \hline
+\end{tabular}
+となる。
+さらに、このサーバのスタックマシンが
+命令コード 2, 3, 5, 7, 11 番を利用可能
+(実際にはこのような命令コードは存在しない)であれば、 $B$ の部分は
+\begin{tabular}{|c|c|c|c|c|} \hline
+2 & 3 & 5 & 7 & 11 \\ \hline
+\end{tabular}
+となり、
+CMO 形式の 32 ビット整数、文字列、 mathcap 、リスト構造のみが
+受け取れるときには、 $C$ の部分は
+\begin{tabular}{|c|} \hline
+	\\[-5mm]
+	\begin{tabular}{|c|c|} \hline
+		& \\[-5mm]
+		OX\_DATA &
+		\begin{tabular}{|c|c|c|c|} \hline
+		CMO\_INT32 & CMO\_STRING & CMO\_MATHCAP & CMO\_LIST \\ \hline
+		\end{tabular} \\[0.8mm] \hline
+	\end{tabular} \\[1.4mm] \hline
+\end{tabular} \\
+となる。
+CMO\_ZZ がないので、このサーバは多倍長整数が
+送られてこないことを期待している。
+
 なお、データが受け取れることと、
 データの論理構造が理解できることとはまったく別物であるので
 注意する必要がある。
@@ -300,47 +369,46 @@ ox\_asir は CMO 形式の多倍長整数を受け取れることがわか
 
 \section{セキュリティ対策}
 
-OpenXM では幾らかのセキュリティ対策を考えている。
-OpenXM に対応したソフトウェアをクラックしても
-大した利点はないと思えるが、それは設計上の話であって、
-予期せぬ手段で攻撃を受けた場合にどのような事態を
-招くかは想像し難い。
+OpenXM 規約は TCP/IP を用いて通信を行うことを考慮している。
+ネットワークによって接続される現代の多くのソフトウェアと同様、
+OpenXM 規約もまた通信時のセキュリティについて注意している。
+以下、このことについて説明しよう。
 
-そこで、 OpenXM では侵入者に攻撃の機会を
-できるだけ与えないようにしている。
-具体的には、接続が必要になった時のみ接続を待つようにし、
-常に接続に関与するといったことは避けている。
+{\large\bf 意味不明なことを書いているが、}
 
-しかし、これだけでは侵入者が接続を行なう一瞬のすきを
-狙ってくる可能性もある。
-そこで接続を行なう時に、
-接続を待つ port 番号をランダムに決めている。
-こうすることで、特定の port 番号を狙って接続を行なう
-瞬間を待つ手口を幾らか防ぐことができる。
+侵入者に攻撃の機会をできるだけ与えないようするた
+めに、接続が必要になった時のみ接続を待つようにし、
+常に接続に関与するといったことは避けている(やっぱり意味不明である)。
 
+また、侵入者が接続を行なう一瞬のすきを狙ってくる可能性もあるので、
+接続を行なう時に接続を待つポート番号をランダムに決めている(誰が決めてい
+るのかはやっぱり不明であるが)。
 さらにもう一段安全性を高めるために、
 接続時に 1 回だけ使用可能なパスワードを作成し、
-そのパスワードを使って認証を行なう。
+そのパスワードを使って認証を行なう(誰がパスワードを決めて誰が認証を行っ
+ているのかが不明だけど)。
 このパスワードは一旦使用されれば無効にするので、
-もし仮になんらかの手段でパスワードが洩れたとしても安全である。
+もし仮になんらかの手段でパスワードが洩れたとしても安全だと考えている。
 
-なお、上記の port 番号とパスワードは安全な手段で送られて
-いると仮定している。
-また、同一のコンピュータ上に悪意のあるユーザはいないと仮定している
-ことに注意しなければならない。
-なぜなら、現在の実装ではサーバ、およびクライアントの動作している
-コンピュータ上ではこの port 番号とパスワードがわかってしまうためである。
+%なお、上記のポート番号とパスワードは安全な手段で送られて
+%いると仮定している。
+%また、同一のコンピュータ上に悪意のあるユーザはいないと仮定している
+%ことに注意しなければならない。
+%なぜなら、現在の実装ではサーバ、およびクライアントの動作している
+%コンピュータ上ではこのポート番号とパスワードがわかってしまうためである。
 
 なお、接続が確立した後のメッセージの送受信に関しては、
-特に暗号化などの処置が行なわれているわけではない。
+特に暗号化などの処置を行っているわけではない。
 もし必要があれば、通信路の暗号化を行なう機能がある
-ソフトウェアを使うことを考えている。
+ソフトウェア ssh を使うことを考えている。
 
-
 \section{他のプロジェクト}
 
 他のプロジェクトについても触れておこう。
 
+\begin{itemize}
+\item OpenMath
+
 OpenMath プロジェクトは数学的なオブジェクトを
 コンピュータ上で表現する方法を決定している。
 各ソフトウェア間でオブジェクトを交換する際の
@@ -352,21 +420,20 @@ OpenMath プロジェクトは数学的なオブジェクトを
 http://www.openmath.org/omsoc/index.html A.M.Cohen
 
 
-以下は書いてる途中。
+\item NetSolve
 
-NetSolve
-
 http://www.cs.utk.edu/netsolve/
 
 
-MP
+\item MP
 
 http://symbolicNet.mcs.kent.edu/SN/areas/protocols/mp.html
 
 
-MCP
+\item MCP
 
 http://horse.mcs.kent.edu/~pwang/
+\end{itemize}
 
 
 \section{現在提供されているソフトウェア}
@@ -377,110 +444,20 @@ asir, sm1, Mathematica がある。
 OpenXM 規格に対応したサーバを呼び出すことができる。
 現在 OpenXM 規約に対応しているサーバソフトウェアには、
  asir, sm1, gnuplot, Mathematica などがあり、
-それぞれ ox\_asir, ox\_sm1, ox\_math という名前で提供されている。
-また、 OpenMath 規格の XML 表現で表現されたデータと CMO 形式の
-データを変換するソフトウェアが JAVA によって実装されており、
+それぞれ ox\_asir, ox\_sm1, ox\_sm1\_gnuplot, ox\_math
+という名前で提供されている。
+また、 OpenMath 規格の XML 表現で表現されたオブジェクトと CMO 形式の
+オブジェクトを変換するソフトウェアが JAVA によって実装されており、
 OMproxy という名前で提供されている。
-=======
-この MathCap データのリスト構造は大きく分けて 3 つの部分に分かれる。
-最初の {\tt [199901160,"ox\_asir"]} の部分にはサーバの情報が入っている。
-%この最初の要素がまたリスト構造となっており、
-最初の要素はバージョンナンバーを、次の要素はサーバの名前を表している。
 
-次の {\tt [276,275,$\cdots$,271]} の部分は
-サーバに対する動作に対応した理解可能なデータの種類を表している。
-サーバの動作に対するデータはすべて 32 bit の整数で表しており、
-このリストは理解可能なデータに対応する 32 bit 整数のリストとなっている。
-
-最後の {\tt [ [514,[1,2,3,$\cdots$,60]],[2144202544,[0,1]] ]} の部分は
-理解可能なデータの形式を表している。
-この部分はさらに {\tt [514,[1,2,3,$\cdots$,60]]} と
-{\tt [2144202544,[0,1]]} にの部分に分けることができ、
-それぞれが一つのデータ形式についての情報となっている。
-どのデータ形式についての情報かは最初の要素にある整数値をみれば
-分かるようになっている。
-この整数値は CMO 形式では 514 となっている。
-最初のデータ形式を区別する整数値以後の要素は
-各データ形式によってどのように使われるか定まっている。
-CMO 形式では理解可能なデータのタグがリストの中に収まっている。
-前節で CMO 形式では多倍長整数を表すタグが 20 であることを述べたが、
-このリストに 20 が含まれているので、
-ox\_asir は CMO 形式の多倍長整数を受け取れることがわかる。
-
-なお、データが受け取れることと、
-データの論理構造が理解できることとはまったく別物であるので
-注意する必要がある。
-
-
-\section{セキュリティ対策}
-
-OpenXM では幾らかのセキュリティ対策を考えている。
-OpenXM に対応したソフトウェアをクラックしても
-大した利点はないと思えるが、それは設計上の話であって、
-予期せぬ手段で攻撃を受けた場合にどのような事態を
-招くかは想像し難い。
-
-そこで、 OpenXM では侵入者に攻撃の機会を
-できるだけ与えないようにしている。
-具体的には、接続が必要になった時のみ接続を待つようにし、
-常に接続に関与するといったことは避けている。
-
-しかし、これだけでは侵入者が接続を行なう一瞬のすきを
-狙ってくる可能性もある。
-そこで接続を行なう時に、
-接続を待つ port 番号をランダムに決めている。
-こうすることで、特定の port 番号を狙って接続を行なう
-瞬間を待つ手口を幾らか防ぐことができる。
-
-さらにもう一段安全性を高めるために、
-接続時に 1 回だけ使用可能なパスワードを作成し、
-そのパスワードを使って認証を行なう。
-このパスワードは一旦使用されれば無効にするので、
-もし仮になんらかの手段でパスワードが洩れたとしても安全である。
-
-なお、上記の port 番号とパスワードは安全な手段で送られて
-いると仮定している。
-また、同一のコンピュータ上に悪意のあるユーザはいないと仮定している
-ことに注意しなければならない。
-なぜなら、現在の実装ではサーバ、およびクライアントの動作している
-コンピュータ上ではこの port 番号とパスワードがわかってしまうためである。
-
-なお、接続が確立した後のメッセージの送受信に関しては、
-特に暗号化などの処置が行なわれているわけではない。
-もし必要があれば、通信路の暗号化を行なう機能がある
-ソフトウェアを使うことを考えている。
-
-
-\section{他のプロジェクト}
-
-他のプロジェクトについて幾つか紹介する。
-
-OpenMath プロジェクトは数学的なオブジェクトを
-コンピュータ上で表現する方法を決定している。
-各ソフトウェア間でオブジェクトを交換する際の
-オブジェクトの変換手順についても述べられている。
-表現方法は一つだけでなく、 XML 表現や binary 表現などが
-用意されている。
-
-%以下、調べる必要あり。
-%NetSolve
-
-%MP
-
-%MCP
-
-\section{現在提供されているソフトウェア}
-
-現在 OpenXM 規格に対応しているクライアントソフトウェアには
-asir, sm1, Mathematica がある。
-これらのクライアントソフトウェアから
-OpenXM 規格に対応したサーバを呼び出すことができる。
-現在 OpenXM 規約に対応しているサーバソフトウェアには、
- asir, sm1, gnuplot, Mathematica などがあり、
-それぞれ ox\_asir, ox\_sm1, ox\_math という名前で提供されている。
-また、 OpenMath 規格の XML 表現で表現されたデータと CMO 形式の
-データを変換するソフトウェアが JAVA によって実装されており、
-OMproxy という名前で提供されている。
->>>>>>> 1.30
+\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}
+野呂正行, 高山信毅:
+{Open XM の設計と実装 --- Open message eXchange protocol for Mathematics},
+1999/11/22
+\end{thebibliography}
 
 \end{document}