連載　XML雑記帳 （3）

XML地域紛争を読み解く〜その2

江島健太郎 インフォテリア株式会社の事業開発部に所属。B2Bの電子商取引を実現する手法としてのXMLの啓蒙活動と、事例の発掘にいそしむ。 電子ガジェットを大量に保有するサイバー魔人。 XML eXpert eXchangeフォーラムのガイドとして、記事の執筆や監修などを行う

江島健太郎
インフォテリア株式会社
2000/6/12

　前回は、XMLの混乱が企業対企業の対立ではなく、アプリケーション対アプリケーションとでも言うべき新しい対立構造を持っているという点について触れました。そしてそれは、文書系（SGML）、Web系（HTML）といったXMLの原点とも言える用途に対し、データ系とeコマース系という新しい用途が新たに加わってきたからである、ということを説明しました。

　今回はこの点について、少し掘り下げて考えてみましょう。

データ系、文書系の文書

　XMLのデータ系への応用とは、いままで独自のファイルフォーマットを利用していたアプリケーションのデータ形式を、XML化していこうとする動きのことを指します。というと、例えばマイクロソフトがWordやExcelのデータをXML化するというのに似ています。しかしここでは、保存したXMLファイルをXSLなどで加工して、人間の目で見ることを意識したXML応用は文書系のほうに分類しておきたいと思います（非定型な要素を多く含む蓄積型文書、ナレッジマネジメントなども文書系に該当します）。

　したがって、ここで言うデータ系とは、もう少し正規化されたデータを表現するもの、例えば「アプリケーション統合（EAI）」「メタデータ管理」「オブジェクトを永続化させる手法としてのXML」「コンポーネントモデル記述」などの用途を想定しています。

eコマース系の文書は揮発する

　eコマース系とは、Web系とデータ系を合わせたようなもので、典型的なケースとしては企業間システム接続があげられます。従来、異なる企業間では採用しているシステムが異なるために、コンピュータ同士が自動的に連携する仕組みを効率的に構築できませんでした。それを、お互いのシステムの入出力をXMLで抽象化することにより解決しようというアプローチがこれです。

　eコマース系のアプリケーションが他の分野のXMLアプリケーションと異なる特徴的な点は、「メッセージ指向（プッシュ型）」「XMLファイルの揮発性が高い」という2点です。

　企業間システム接続では、取引企業同士でビジネスプロトコルを規定し、これに沿った形でお互いのワークフローを定義するのが一般的です。しかし、例えば見積書をXMLで表現したとしてもそれを承認するのは一般に人間であり、相手に見積書が一瞬で届いたからといっても返答は1分や2分では返ってきません。そのため、このようなケースでのデータ転送方法は非同期メッセージングを使うのが適切です。つまり、まず相手のシステムに電子メールやHTTPフォームを使ってXMLの見積書を渡します。その後、相手側のワークフローを経て発注書が戻ってきたら、自社側の受注システムにデータを渡し、処理を再開する。といった流れになります。このとき、見積書や発注書として使われたXMLファイルは、一般には対応する基幹システムのデータベースに入力された後、その役割を終えて消滅します。こうした文書の流れから、eコマース系アプリケーションで利用されるXMLの持つ特徴である「メッセージ指向（プッシュ型）」「揮発性が高い」がお分かりいただけるでしょう。

　上述のようにさまざまな領域でXMLが使われる中で、特にeコマース系の「メッセージ指向（プッシュ型）」という特徴はWeb系の「パブリッシュ指向（プル型）」モデルと根本的に異なりますし、「揮発性が高い」という性質は文書系の「永久保存指向」と相反します。これほど性質が異なるものを、我々はXMLという枠組みの中で均一に扱おうとしているのです。

　では、なぜデータ系とeコマース系がXMLの世界に登場してきたのでしょうか？ それは必然性を伴っているものでしょうか？ そして、どうしてこんなに混沌としてしまったのでしょうか？ これを読み解くキーワードは「XMLは万能すぎる」ということです。

XMLは次世代のプレーンテキストである

　XMLは、それ自体は「高級な次世代プレーンテキスト」とでも言うべきものです。皆さんは、プレーンテキストが最も安全なフォーマットであることはご存じと思います。電子メール、ワープロ、表計算、データベース、プログラミング言語など、多くの分野の製品がテキスト形式と縁を切れないのは、プレーンテキストがそれらの製品の扱えるフォーマットの最大公約数だからです。プログラムの相互運用性を考慮すると、プレーンテキストをサポートしないわけにはいかないのです。

　ところが、XMLがオープン標準として認知されるにつれ「XMLならプレーンテキストに代わる最大公約数になれるんじゃないか？」という意見が多数派になってきました。XMLは構造表現能力、文字コードの扱い、インターネット対応など、すべての点においてプレーンテキストのスーパーセットであることは事実です。このため、あらあゆるアプリケーションがXMLに何らかの形で対応していくことは自明と思われたのです。

　このことは長期的には事実でしょう。問題は「どのくらいの時間をかけて対応を実現していくか」というコンセンサスが未成熟な点です。

どのくらい時間をかけてXML対応にするかが問題

　この議論がなされないまま、多くのITベンダーはXML化を急ぎ始めました。場合によってはMIME/RFC822形式（「名前：値」の書式でメタ情報をヘッダに記述し、本文と分離する形式）やCSV（Comma Separated Value）を用いるだけで、中期的に十分に役割を果たす可能性のある分野はあります。しかし、このようなケースでも「とりあえずXML」という前提があったりして、本当の意味でXML化に対する「フィージビリティ（実現可能性）」「コストパフォーマンス（費用対効果）」を評価できているケースはほとんど皆無だと思います。XMLが万能であるがゆえに、なにがなんでもXMLに対応する、という盲目的なプロジェクトが増加傾向にあるというのが現状です。

　繰り返しますが、確かにXMLは万能です。しかし、万能であるということは何にでも化けるカメレオンのようなものであるということの裏返しでもあります。次節では、そのことをスキーマ定義言語の話題から切り込んでみようと思います。

スキーマ定義言語に関する2つの立場

　そもそもXMLはその名の通り拡張性の高いことが特徴です。それでいて、階層などの構造を表現できるようになっています。つまり、半構造データであるという点で現代性を踏まえています。

　拡張性の高さはインターネット時代には必須で、スキーマの参照や検証を必須としないWell-FormedなXMLの存在は、XMLの利用価値を高めています。反面、構造を定義できるということは正規化とクラス化を促進し、人間とコンピュータの双方が扱いやすいデータ構成を実現します。この相反する要素を内包したXMLは、どちらに比重を置くかによって扱い方が変わるという性質があります。

　例えば、eコマース系では日本のCIIが、EDIのフラットなメッセージをそのままXMLに置き換えるというアプローチを取っています。データ系でも、オラクルはRDBMSからORDBMSへの道のりをたどる中でXMLと合流し、これをいかに自社ORDBMSの中に位置づけるべきか、最適な方法を模索している段階のようです。これらのアプローチでは、スキーマ定義言語はデータに対して厳格な定義と正規化が行えるほどよいというニーズがあります。しかし正規化・クラス化のバランス感覚の難しさは、RDBMSのシステム設計などで多くの読者が経験されたことでしょう。

　一方で文書系ではSGMLのDTDを軽量化し、Well-Formedを許容するに至った経緯からも推測できるように、そもそも暗黙知を含む情報を正確にモデリングすることは本質的に難しいという観点から、ある意味で割り切った半構造を認める方向できています。パーサは使いたいが、検証はあまり期待しない、という観点です。

　筆者の個人的な見解としては、現段階では後者に共感を覚えます。前者はどちらかというと規格が厳格かつ巨大だったがために普及できなかったSGMLのアナロジーに陥るように思えるのです。そしてW3Cが仕様策定中のXML Schemaはどちらかというと前者に近く、多様なニーズに対する最小公倍数的アプローチと言えます。XML SchemaはXML文書を利用するそれぞれのシステムがスキーマを参照できることを前提としていますが、この前提は実装が追いつかなければ破綻します。そしてXML Schemaは現時点で判断するに、破綻するに十分なほど実装の難しい仕様に育っているように思えるのです。

　そして、このXML Schemaへの問題意識が結実し、アンチテーゼとして日本から提案されているRELAXには、筆者もその思想面で非常に期待しています。

「スキーマ」と「アプリケーションの複雑さ」はトレードオフ

　そもそも、スキーマ仕様の高機能さとトレードオフの関係にあるのはアプリケーション開発の煩雑さです。スキーマの存在によってアプリケーション開発者の負担が減らないのなら、スキーマなどまったくなくてもよい（アプリケーションで書けばよい）、そういう割り切った使い方があってよいのがXMLだと思います。本当の意味でコーディングの量を減らしたければ、種々雑多な環境で簡単に組み込める、バラエティに富んだスキーマ検証ツールがどんどん出てくる必要があるのではないでしょうか。そのためにはスキーマ定義言語の仕様自体は必ずしも高機能・包括的である必要はないし、むしろ利用しやすいこと・軽量であること・多様性を許すことが必要条件であるように思います。

　とはいえ、筆者はeコマース系に属する職業に従事していますので、eコマースの領域でXMLを活用することの未成熟さと、反面その必然性も理解しているつもりです。

　次回以降は、もう少し別な角度からXMLの地域紛争について掘り下げ、読者の考えているアプリケーションにとって参考となるような考察をしたいと思います。

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）