前回の内容を絵にまとめると以下のようになる。
さらに詳しくみてみよう。下の図は４つの分類を並べてみたものである。
すると以下の３つの軸が見えてくる。
１．データとプログラム
２．ロジックとインターフェイス
３．意味が確定しているか否か
１．データとプログラム
メッセージ系とドキュメント系は普通の意味でデータであり、設定系とレイアウト系はデータの形をしたプログラムだといえる。
データの形をしたプログラムというのは分かりにくいかもしれないが、CやJavaなどのプログラムと呼ばれるモノも一定の構文をもったデータにしかすぎないことは、プログラムを見たことがある人なら納得できるだろう。設定やレイアウト定義をXML化することによって、これらのXMLデータはフレームワークに読み込まれプログラムの一部として実質的に動作するのだ。
当然、プログラム言語全体をXMLにすることも可能だが、かえって可読性が低くなる。実際、DataSpiderやAsteriaは内部的な言語はXMLだが、使いやすいビジュアル開発環境を用意することによってこの問題を解決している。
プログラムはデータ化しうるという簡単な話だが、計算機の起源に戻ると、フォン･ノイマン型コンピュータの必然である。フォン･ノイマン型では、データとプログラムの対等性がメモリ空間で実現されたが、現代ではXML空間の上でもう一度データとプログラムの対等性が実現されようとしている。
では、メモリ空間とXML空間に違いはあるのだろうか。それについては、チューリング、フォン･ノイマンから池上・橋本まで、計算の概念の変遷を見ることによって、次回のエントリーで答えてみたい。
２．ロジックとインターフェイス
UIのあるアプリケーションを作るときに必ず言われるのが、アプリケーションロジック（モデル）とインターフェイス（ビュー）の分離である。
プログラムとしてのXMLのうち、設定系はモデルであり、レイアウト系はビュー(とユーザーとのインタラクション)を定義する。ビューといっても視覚を使う必要もなく、voice XMLのような音声のインターフェイスを定義するXMLも立派なビューである。
実際にアプリケーションを開発すると、モデルとビューはきれいに分離しないことがたびたびある。だからこそ、「モデルとビューを分離せよ」といわれるわけだが、モデルとビューが混同したXMLは非常に多い。
その混同の原因には、モデルとビューの判断基準が、データの永続性に依存していることにもある。時間という連続的なパラメータを使っているのでグレーゾーンが残るのだ。このグレーゾーンは、コミュニケーションウェアの開発においてはさらに拡大する。
そのため、ロジックとインターフェイスの分離は、規範としての分離であると同時に、理念型としての分離でもあるので、現実にそれを求めるよりは、本論においては理解のために用いるべきである。
ロジックとインターフェイスを分離するもうひとつの視点は、インターフェイスを身体とメディアの間に入るものとし、ロジックをメディアとメディアの間に入るものと定義することである。この点については、ハイパーメディアをめぐるこの６０年の歴史を振り返らなくてはならない。
ご存知のとおり、HTMLはHyperText Markup Languageの略であり、HTMLはXMLの子供という関係だ。XMLとハイパーメディアが関係ないわけがない。
XMLがモデルとビューを分離することによって、我々にどのような福音をもたらすかは、FTEXTについての論考で紹介することにしよう。
３．意味が確定しているか否か
この３つの軸の中でもっとも重要なのが、意味が確定しているかどうか、という違いである。
ロジックとインターフェイスの分離(すなわち設定系とレイアウト系の違い)が、永続性に強く依存しているのに対して、メッセージ系とドキュメント系の違いにとって、永続性は見せ掛けに過ぎない。
現実的には、ドキュメント系のXMLは永続的で、メッセージ系のXMLは瞬間的であることは多い。しかし、商取引などのメッセージ系のXMLは永続的に保存されることもあるし、ドキュメント系のXMLがメッセージとしてやりとりされることもある。
多くの人が気づいていないことだが、メッセージ系とドキュメント系のもっとも大きな違いは、インラインタグを許容するかどうかなのだ。
インラインタグとは、例えばリンクを張るときのほげのようなものである。
メッセージ系のデータとは、RDBに保存することが可能なデータであり、ドキュメント系のデータとはRDBに保存できないデータを含む。RDBにスキーマとして保存できないデータがインラインである。
RDBに保存することが可能なデータは、すでに意味が確定している。例えば、住所と名前というカラム名に入ったデータは住所と名前に他ならない。しかし、ドキュメント系のデータ（例えばこの論考全体）は、相対的に非常にあいまいな意味しかメタデータから与えられていない。
では、インラインとはなんだろうか。それは、意味が確定していないデータを部分的に確定化することに他ならない。
XMLのタグにはインラインとアウトラインの２種類がある。アウトラインはRDBにマッピング可能だが、インラインはそうではない。
ちなみに、table(表)は、インラインとアウトラインの中間に位置するため、ドキュメント系のXMLの仕様を考えるときにいつも困る。
意味の確定については、semantic webについての論考で、詳しく述べることになるだろう。おそらく、アリストテレス、フレーゲ、パース、フッサールの意味論を振り返ることになる。
さて、今回のエントリーはこれくらいにして、次回は「計算とデータ」の関係を振り返ってみたい。
