ＸＥＡＤのＸは、ＸＭＬのＸ

ＸＭＬ(eXtensible Markup Language)が鳴り物入りで登場してから７年たつが、いまだに筆者には、ちまたで言われるようなＸＭＬの利点がもうひとつピンとこない。とくに「データがその意味とセットで保管されている」とか「データ様式の設計や変更が容易」といった「利点」がわからない。その疑問を説明した後で、ＸＥＡＤにＸＭＬが組み込まれるきっかけになった、あまり意識されない別の利点を示そうと思う。読者がＸＭＬを理解するための参考になればうれしい。

◆データがその「意味」とセットで保管されている？

ＸＭＬの特長として最初に紹介されるのが、「データがその意味とセットになって保管されているゆえに、データの検索や交換がしやすい」という点だ。たとえば、次のようなＸＭＬデータがあったとする（ブログページ上でＸＭＬと認識されないようにカッコやスラッシュを全角にしてある）。

＜注文＞
　＜得意先名＞サイトウ電器＜／得意先名＞
　＜得意先住所＞ＸＸ市○○１２－３４△△ビル５Ｆ＜／得意先住所＞
　＜受注日＞20050531＜／受注日＞
　＜相手先注文番号＞J25443857＜／相手先注文番号＞
　＜商品明細＞
　　＜商品名＞Ｍ３２０＜／商品名＞
　　＜数量＞10＜／数量＞
　　＜納期＞20050601＜／納期＞
　＜／商品明細＞
　<商品明細>
　　＜商品名＞Ｔ１２０＜／商品名＞
　　＜数量＞5＜／数量＞
　　＜納期＞20050605＜／納期＞
　＜／商品明細＞
＜／注文＞

確かに、”サイトウ電器”というデータが「得意先名」という「意味」とセットになっているように見える。実際、文書全体から「得意先名が”サイトウ電器”であるような注文の一覧」を取り出すこともできるし、このデータを渡すだけで”サイトウ電器”が「得意先名」であることを受信側はただちに理解できる。

しかし、このことを以って「得意先名」を「データの意味」と言ってしまうのは正確ではないような気がする。たとえば、文書の送信側が「得意先名」と呼ぶ項目と同じ「意味」の項目を、受信側でも「得意先名」と呼んでいるとは限らない。「顧客名」とか、「客先名」などと呼んでいるかもしれない。これは「異名同義」の問題だが、「同名異義」の問題もある。たとえば、あるシステムで「納期」と表現されているデータ項目があったとして、これをＸＭＬで受け取って、受け手側の「納期」の項目にマッピングしていたとする。ところが、どうもシステムの動きが変なので調べてみたら、「納期」の意味が、片や「希望納期」で、片や「約束納期」だったなんてことがある。データ交換を伴わなくても、単一文書内でこれらの問題が生じている可能性もある（＊１）。

つまり、「得意先名」だの「納期」などというのは「データの意味」ではなく「データのラベル」にすぎない。たかだかデータのラベルをデータといっしょに送っても、異なるシステム間でデータを正しくマッピングできるようになるなんて期待はできない。けっきょくのところ、「意味」はデータの利用者全員にとっての共通なルールとして別途まとめられなければならない。その地道な作業の結果として、規定様式のＸＭＬデータが活躍できるのであって、ＸＭＬを導入するだけでルール策定の作業がいきなり楽になるなんて話ではない。

＊１．この問題に対処するため、有効な要素名やその位置づけをＤＴＤやＲＥＬＡＸと呼ばれる形式であらかじめ規定しておくことも可能だ。しかしこの規定を厳密にすればするほど、データ様式のダイナミックな変更が可能というＸＭＬのもうひとつの特長が損なわれて、ＲＤＢと比較した場合の特長が薄れる。

◆データ様式の設計や変更が容易？

また、ＸＭＬではデータ様式に自由度があり、使いながらの様式変更にも強いという説明がされることがある。たとえば上記の注文データについて、その後に客先から「商品Ｍ３２０の色は黒にしておいてください」と要望されたとして、アプリ上から次のように「色」の要素を伴う形（変更後１、または２）に編集することも難なくできてしまう。

（変更前）
＜商品名＞Ｍ３２０＜／商品名＞
＜数量＞10＜／数量＞
＜納期＞20050601＜／納期＞

（変更後１）
＜商品名＞Ｍ３２０＜／商品名＞
＜色＞黒＜／色＞
＜数量＞10＜／数量＞
＜納期＞20050601＜／納期＞

（変更後２）
＜商品＞
　＜商品ID＞Ｍ３２０＜／商品ID＞
　＜色＞黒＜／色＞
＜／商品＞
＜数量＞10＜／数量＞
＜納期＞20050601＜／納期＞

しかし、「これが可能であるゆえにＸＭＬは便利」とも言いがたい。けっきょくのところ、そのデータを処理するすべてのアプリがそのような形式に対応できないのであれば、何の意味もないからだ。たとえば、注文データを処理する出荷指示用アプリが「色」を扱うことを想定していないのであれば、その情報はさっくりと無視されてしまう。

データ様式の変更容易性が「設計容易性」と混同されて説明されることもある。「必要に応じてデータ様式をダイナミックに変更できるので、漸進的にデータ様式を発展させられます」などと語られるが、それは企業システムがどういうものかをわかっている技術者にとっては噴飯モノだ。フリーフォーマットだろうが、ＸＭＬだろうが、データを保管したり交換したりする際には、one fact in one place の原則にしたがって事前にレイアウトを決めておかないと遅かれ早かれ悲惨なことになる。少なくとも企業の帳簿組織に載るような情報を扱うためにＸＭＬを使うのなら、データ様式の変更容易性とは無関係に、データの正規化くらいされていないと話にならない。

言い方を換えれば、データモデリングに精通していればＸＭＬ様式の設計など容易だ。じっさいＸＥＡＤのコンテンツは複雑だったが１日でＸＭＬの様式を設計できた。ＲＤＢＭＳでの実装を前提にしなくても、データモデリングは有用な技術なのである。

◆「無料の組込みＤＢＭＳ付きの保管形式」としてのＸＭＬ

ＸＭＬに関する風評についてこのような疑問はあるものの、ＸＭＬの技術そのものへの感謝の気持ちについて筆者は人後に落ちない。この気持ちを理解してもらうにはＸＥＡＤの前身となったモデリングツールのことを語らねばならない。

それは筆者が８年前に、Delphiを使って最初に組んだパソコンのプログラムだった。自分の独特な図法にもとづいて描かれた設計情報を管理するために、仕事で忙殺されながらも１年半の間、毎晩２時間自宅でコツコツとプログラミングして完成させた労作だった。

そのツールは目ざましい活躍をしたものだが、何年も使っているうちに不満がたまっていった。仕様レベルの使いにくさもあったが、いちばんイライラさせられたのが、コンテンツデータの保管形式だった。Delphi付属の無償のＲＤＢＭＳを使っていたのだが、なにしろ複雑な構造をとっているコンテンツなので、インデックスも合わせると１００個近いファイルとして保管される。コンテンツを持ち運ぶときに、１個でもファイルが抜けると動かないのだ（フォルダごと持ち運べばいいだけのことだが、それにしてもイケてない）。それに、データソースをＲＤＢＭＳに接続する手続きが面倒だったし、たまたま別バージョンのDelphiがインストールされているＰＣでＲＤＢＭＳのバージョンが違うから動かないなんて泣くに泣けないこともあった。

後継ツールを開発しようと思い立ったとき、まず意識したのがコンテンツの保管形式の簡素化と、ＤＢＭＳとバンドルさせる際のわずらわしさからの解放だった。そのような課題を考えた場合、Ｊａｖａ＋ＸＭＬは都合のいい組み合わせだった。結果的に、コンテンツは１個のファイルにまとまった。また、ＤＢＭＳへの接続のややこしさがなくなったうえにバージョンにも影響されなくなった。これはＤＢＭＳがアプリに関数として組み込まれているおかげだ。xerces（ApacheのＸＭＬパーサ）をimportして、

DOMParser parser = new DOMParser();

とやるだけで、ＸＭＬデータを処理するためのＤＢＭＳが手に入る。（厳密にはＤＢＭＳとは呼べないものかもしれないが、少なくともＸＥＡＤでのＤＯＭの位置づけとしては、そうみなしてかまわない）

いっぽう、ＲＤＢをあきらめたことで失ったものもある。まず、データアクセスの手順が複雑になった点だ。特定の要素にアクセスするためには、同じ要素名を持つ要素配列をまず手に入れてから、それらの内容を調べて望みの要素であるかどうかを確認するといった手順を踏まねばならない。しかし、これもアプリ内部で関数化してしまえばすぐに慣れるし、データをメモリに展開するタイプのパーサであるゆえの処理の高速さで十分おつりが来ている。

また、複数ユーザによる利用も断念せざるを得なかった。パーサにトランザクションとかロックのような機構がないためだ。しかし、これもあきらめがつく。シングルユーザでの利用を前提としているおかげで、ツール上でＵＮＤＯ／ＲＥＤＯができるようになったからだ。この種の設計情報は試行錯誤的に編集されることが多いので、モデリングツールにはＵＮＤＯ／ＲＥＤＯ機能が欠かせない。もし多人数での同時更新を前提にすれば、それを組み込むことはほとんど不可能だ。

というわけで、筆者はＸＭＬを「複雑なデータ形式を扱えて、しかもアプリにライブラリとして組込めるＤＢＭＳが無償提供されている保管形式」として大いに活用させてもらっている。もちろん、この使い方が唯一の正解などではない。ＸＭＬは各人が置かれた状況に応じて活用方法が見出されてゆく、そのような要素技術なのだと思う。ＸＭＬのＸは、利用者にとって都合のいい値を受け入れてくれる変数でもある。