XMLがもたらす夢と現実

インフォテリア株式会社
吉松 史彰
2003/03/20


 XMLがIT業界の流行語となって久しい。XMLを利用していることを宣伝する製品やソリューションも増えてきた。だが、一方ですでにある種のあきらめのような感覚を持つ技術者も増えている。いわく、

「XMLって何の役に立つの?」

 確かに、XMLでできるといわれていることは、実はこれまでだってできていたことがほとんどだ。データをプラットフォーム非依存の形式で送受信する仕組みなど、昔からCSVや固定長テキスト・フォーマットで作られてきた。全銀手順や業界VANを見れば、これらが一定の成功を勝ち取った技術であり、いまそこにある、動いているシステムであることは明らかだ。XMLの方がこれらの形式に比べて柔軟性に富むといわれるが、実際にその柔軟性を活用したシステムにお目にかかったことはまだない。EAIやBtoBもまたしかり。乱立する自社システムを連携させようとする試みは、筆者が業界に入ったころにはすでに行われていたし、業界VANは立派なBtoBの例だ。確かにこれらは価格が高い、システムが硬直的である、という批判を浴びているが、XMLだけが価格を下げ、システムの柔軟性を向上させる要因かといえば、そんなことはない。つまり、技術者の目から見れば、「XMLなんてまた1つ新しく作られたデータ・フォーマットにすぎないんでしょ?」ということになる。

 実際、XMLが業界に浸透し始めた初期の段階に宣伝されたXMLの長所を見てみると、その多くはいま考えれば単純に誤っているか、あるいはXML自体がその長所を生み出しているわけではないものが多い。例えば、「XMLではデータをタグで囲める。タグはHTMLと違って種類に制限がない。だからXMLではデータに意味を付加できる」などだ。実際には、タグに何を記述したところで、データに「意味」は付加できない。あるいはこんな例もある。「XMLで、プラットフォームに依存せずにデータが交換できるようになる」。この項目の解説を読んでみると、大抵の場合それはXMLが理由ではなく、XMLが「テキストで記述されていること」が理由であることが分かる。つまり、この長所はテキストで記述されたフォーマットなら何にでも当てはまるものなわけだ。このあたりが、技術者が「XMLって何なんだろう?」という疑問を持ち始める理由の1つであろう。

 ずいぶん暗いトーンになってしまったが、筆者は必ずしもXMLの将来を悲観しているわけではない。実は、最近筆者はある種のパラダイムシフトを経験した。いや、正確には、そういうものがあるらしいことをのぞき見ただけで、それを自分のものとして確立したわけではないのだが、少なくとも新しい技術の領域を見たのだ。それは、@ITのサイトに掲示されていたニュース「XML 1.1を巡る『ボヘミアン』と『貴族』の階級闘争」に書いてあった。

 「文字列を最重要視し、XMLを従来のようにテキスト処理中心のままにしておき、スキーマがなくとも処理可能で、必要ならバインディング・ツールを使用すればよいとする人々の陣営を村田氏は『ボヘミアン』と名付ける。一方で、型情報を最重要視し、スキーマがなくてはデータに意味はないとする陣営がある。XPathやXSLT 2.0も型情報ありきで動作すべきだとする意見を持つ彼らを、村田氏は『貴族』と呼ぶ」

ちなみに、ボヘミアンや貴族というレッテルは、村田氏が作ったわけではない。恐らく最初にこの言葉を使ったのは、Uche Ogbuji氏(Co-Founder & CEO, FourThought Consulting)であろう(http://www.adtmag.com/article.asp?id=6965)。

 ボヘミアン。彼らはXMLをまずインスタンスありきで考えている。データ・モデル、スキーマ、型は後から適用したい人が適用すればいいというのだ。インスタンスはスキーマから作られる実体ではない。スキーマはインスタンスに対する「見方」にすぎないというのだ。

 この考え方は現在のシステム開発の方向性とは正反対である。現在のシステム開発では、まず顧客が利用しているデータを洗い出し、それを一般化してデータベース・スキーマを作成する。あるいは、顧客とシステムとの間のやりとりを抽出し、UMLでモデル化する。いずれも、インスタンスをスキーマにする作業だ。スキーマを作る作業が設計であり、その設計を実装したシステムから再び出力されるのがインスタンスである。現在のシステム開発では、システムが最初のインスタンスを出力する前に、まずそのスキーマを作らなければならない。現代の技術者から見れば当然だろう。スキーマを定義せずにデータを入力できる関係データベースなど存在しないではないか。クラスを定義せずにオブジェクトを作成できるオブジェクト指向プログラミング言語も存在しないではないか。

 ところが、XMLの世界ではそうではない。XML 1.0仕様では、DTDはオプション機能にすぎない。スキーマがなくてもデータは存在できる。XSLTを使えば、スキーマがなくてもインスタンスをキャスト(型変換)できるし、SAXを使えば、スキーマがなくてもインスタンスが意味ある振る舞いを行えるのだ。このような仕組みは、従来型のプログラミング言語を実装技術とするシステムの考え方を大きく逸脱している。XMLには、UMLのクラス図は必要ない。UMLのクラス図は静的構造を表すが、XMLのインスタンスには静的構造が存在しないからだ。

 当然このような見方は、XMLを現在のシステム開発に応用しようとする陣営(「貴族」の大多数)からは拒絶される。考えてみてほしい。オフィス文具のサプライヤに対して、こちらで一方的に作成したXML文書を送信して、先方のシステムが受け取ってくれることがあり得るだろうか。あるいは、こちらが送信した発注文書を、サプライヤが独自に定義したスキーマで検証し、独自に型情報を適用することなど想像できない。

 例えば、Webサービスのクライアントから送信されたXMLのメッセージを、受け取ったWebサービス側で処理するためには、クライアントとサービスの双方がそのメッセージの意味について相互に同意していなければならないはずだ。次のようなメッセージが送信されたときに、

  <draw>$1</draw>

 これが1ドル紙幣の画像データを送信しろという意味なのか、それとも銀行口座から1ドルを引き出すトランザクションを行えという意味なのかは、あらかじめ送信側と受信側の双方が同意しているべきことであり、インスタンスを見て初めて判断するようなことではない。そこで、WebサービスではW3C XML Schemaで定義したスキーマと、WSDLで定義したメッセージの処理モデルを使って、この同意を表現しようとしている。

  <definitions>
    <message name="drawInput">
      <part name="kind" type="xs:string"/>
    </message>
    <message name="drawOutput">
      <part name="image" type="xs:base64Binary"/>
    </message>
    <portType name="drawPort">
      <operation name="drawBogusBill">
        <input message="drawInput"/>
        <output message="drawOutput"/>
      </operation>
    </portType>
  </definitions>

 これにより、受信されるデータがバイナリをエンコードしたものであることが分かる。これでようやく、前掲のXMLインスタンスが、紙幣のイメージ(画像データ)を得るためのものだったことが分かる。……。

 分かる? 本当に? 上記のWSDLで、XMLを送ると紙幣のイメージが返ってくるかどうか本当に分かるだろうか。技術者ではない普通の人に聞いてみればすぐに答えは出る。こんなもので、「紙幣のイメージが返ってくる」などという意味情報は伝わりっこないのだ。私たち技術者がこれを見て「分かった」と思っているのは、実はこれ以外の背景情報をいろいろと入手しているからである。つまりインスタンスを見ても分からないことは、スキーマを見ても実は分からないのだ。XMLのスキーマにしろ、関係データベースのスキーマにしろ、現在の技術は構造から意味を推論しやすくする技術にすぎない。「OrderIdという名前の文字列データだけが入力される場所」という構造上の制限を設けて、それを「受注番号」という意味だと思い込んでいるにすぎない。「OrderIdとDueDateとOrderItemsがたくさんある、ひとかたまりのデータ」という構造を見て、それが「発注伝票」というビジネス上の意味を表すと見なしているにすぎないのだ。これが現在のスキーマの限界である。

 そしてXMLの場合は、構造から何かを「思い込む」だけでいいのなら、要素や属性の名前を見られれば十分なのだ。その背後にXMLのスキーマを配置しても、どうせその意味までは分からないのだから。だったらXMLのスキーマは何のために使われるのだろうか。

 ボヘミアンと貴族の闘争とは、一言で要約すると、「スキーマが重要か、それともインスタンスが重要か」ということだ。オブジェクト指向プログラミング言語でクラスの定義に慣れ、UMLやER図で静的構造の定義に慣れている私たち現代の技術者にとっては、インスタンスはスキーマなしには存在し得ない。インスタンスの解釈は厳密にスキーマに依存する。ところが、現実を見てみると、実はスキーマなしでも立派にデータが流通し、運用できているシステムが世の中にはたくさん存在する。その代表例がWebだ。Web上のドキュメントには決められたスキーマがほとんどないのに、GoogleはSQL ServerやOracleと同じように、私たちが求めるデータを検索できる。そして、いまW3Cが取り組んでいるSemantic Webも、スキーマなど使わずにインスタンスとインスタンスを意味的にリンクさせようとする試みである。まずインスタンスありきで世界をつなぐシステムを構築する。それがXMLの挑戦であり、パラダイムシフトなのだ。

 いま現在もシステムの開発に悪戦苦闘している私たちにとって、XMLの挑戦は夢物語に聞こえる。だが筆者は、XMLが持つ最も重要な長所はその懐の深さにあると考えている。従来型の技術者も、世界を変えるかもしれない革命家も、みんながあの「不等号の記述」だけは信じている。どんなに対立が根深くても、結局はXMLをどのように使おうと自由だ。JavaやC#のように、決められた命令だけしか実行できないような硬直した仕組みではない。XMLのタグは、それをデータとして解釈しようと、命令として解釈しようと自由なのだ。だから、いまからXMLに触れておいて早すぎるということはない。あなたが感じ取ったそのXMLの使い方が、もしかしたら数年後にはみんなの仕事のやり方を根本から変えているかもしれないのだから。End of Article


吉松 史彰(よしまつ ふみあき)
 インフォテリアにおいて、.NET FrameworkやXMLを活用したシステムの開発とコンサルティングを行っている。また、個人でも執筆や講演活動を通して.NET Frameworkの啓蒙活動をマイクロソフトに黙って勝手に行っている。

 「Insider.NET - Opinion」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間