XMLフロンティア探訪
第1回 スキーマ戦争最前線

今月から川俣氏の新連載「XMLフロンティア探訪」が始まります。動きの激しいXML関連の技術を、川俣氏独自の鋭く深い切り口で解説。第1回は、W3CからXML Schemaが勧告されて注目度が高まっている「スキーマ言語」について、 その現状と、W3Cの仕様に対する新たな対立軸の登場を解説します。（編集局）

川俣 晶
Advanced IT School 学長
2001/5/29

今回のおもな内容
なぜスキーマ言語が熱いのか
大規模なシステムほどスキーマが不可欠
熱しすぎたXML Schema
お墨付きを巡る争い
明確になる対立軸
モジュール化を進めるRELAX Namespace
スキーマ戦争の行方は？
■なぜスキーマ言語が熱いのか

　おそらく、XMLのスキーマ言語といっても、ピンとくる人は少数はではないだろうか。さらに、XMLのスキーマ言語が業界の秩序を左右するほど重要だとか、それを巡って熱い戦いが繰り広げられている、ということも理解できない人が多いだろう。そもそもXMLという技術そのものが地味で分かりにくい面を持つ。さらにXMLのスキーマ言語となると、それに輪を掛けて地味で分かりにくいといえる。

　しかしマイクロソフトやIBMが、この分野を「重要な技術」と断言して本気を出している以上、分かりにくいから分からなくてもいいや、ともいっていられない。これから出てくる多くの技術がこれから解説するスキーマ言語という技術を前提としている以上、これを飛ばして新しい技術に飛びつくこともできない。

　では、なぜスキーマ言語はそれほどまでに重要なのだろうか。それは、XMLがメタ言語、つまり言語を作る言語であるという性質と深く関係している。XMLを用いて、XHTMLやSVGなど多くの言語が作られていて、これからも電子商取引や電子政府のために、多くの言語が作られていくだろう。その際に重要なことは、言語の定義をどうやって記述するか、ということである。もし、言語を定義する方法が幾つもあり、しかもそれらに互換性がなかったら、世の中は混乱してしまう。例えば、2つの言語を持ってきて合わせれば欲しい言語になる、ということが分かっていても、言語の定義方法に互換性がなければ、合わせて1つの言語の定義を作ることも面倒な作業になってしまう。つまり、言語を標準化するだけでなく、言語を定義する手段も標準化しなければ、XML時代を幸福に過ごすことはできないのである。

■大規模なシステムほどスキーマが不可欠

　このような理由から、言語を定義する手段が何種類も用意されることは、あまり意味がないし、新しい手段を自分で考えようという人も多くはなかった。SGMLの時代はDTDが言語を定義する役割を担っていて、これに変わる別のものを作ろう、という動きは大きなものではなかった。

　ところが、XML時代になると、DTDの表現力がXML時代に即応しなくなってしまった。そこで、DTDを拡張するよりも、もっと洗練された良い言語を作る方がよいという考え方が大勢を占めた。だが、そのための具体的な言語像はバラバラであり、さまざまなスキーマ言語が試作された。すでに述べたように、言語を定義する手段がバラバラでは不便なので、W3Cの場でたった1つのスキーマ言語を開発することになり、これがXML Schemaとして実現した。

　ここで注意すべきことは、スキーマ言語の表現力が、XMLによって生み出される言語の機能にまで影響を及ぼすということである。もちろん、XMLにはDTDがなくても扱える整形式というものもあるわけで、スキーマ言語とはまったく無関係に運用することもできる。だが、大規模なシステムになれば、変なXML文書や壊れたXML文書が紛れ込んでトラブルを起こすことを避けるために、スキーマを用いた自動チェックの機能は不可欠である。それを前提に考えれば、スキーマ言語の記述能力の良し悪しは、実際に運用されるすべてのXML文書に影響するほどの重要度を持つ、といえる。

　そのような背景から考えれば、スキーマ言語の設計に熱が入るのも当然といえる。それに優れた表現力を与えることができれば、それを用いて定義されるあらゆる言語の表現力に影響を及ぼすのである。

■熱しすぎたXML Schema

　似て非なるスキーマ言語が幾つも横行するのは不便なので、標準化すべき、という意見は正しい。そして、スキーマ言語に熱意を持って取り組むという姿勢も正しい。その意味で、XML Schemaは正しい方針の上に開発されたといえる。ところが、正しい部品を組み合わせて作られたメカニズムがすべて正しいという理屈は成り立たないのである。XML Schemaに関していえば、まず機能が増えすぎて全体を把握できる人間が誰もいない、という問題が生じている。また、実際に検証プログラムを書いてみようと思っても、工数が大きいので、マニアが気軽に試みることもできない。そして、高度化された機能がかえって応用範囲を狭めている、という問題もある。さらに、複雑高度であるため、本当にXML Schemaが矛盾なく完璧な言語であるか、だれも保証できていない。

　要約すれば、XML Schemaは学習が難しすぎ、資金力のある大手ベンダにしか開発に取り組むことは難しい、ということなのである。しかも、それだけのハードルを越えると桃源郷があるのかと思いきや、分野によって相性があったり、事実上使えない機能があったりする（これに関しては、このあたりの文章を参考にしていただきたい「XML Schema: やるべきこと、やってはいけないこと」Kohsuke KAWAGUCHI 著 なんばりょうすけ 訳）。

　このような状況に対して、反旗を翻した男が2人いる。最初に反旗を翻したのは、日本XML界のナンバーワンであると同時にW3CのXMLワーキンググループのメンバーであった村田真氏である。氏は、スキーマに関する独自の研究の成果として、新しい言語RELAXを送り出した。

　そしてもう1人の男は、James Clark氏である。氏はSGMLやXMLの世界の第一人者の1人であり、W3CのXMLワーキンググループのメンバーとしてXMLを世に送り出した者たちの一人である。仕様作りだけでなく、幾つもの標準技術を実際に動くプログラムとして実装することでも知られている。XML初期の時代に最も使われたXMLパーサのexpatや、XSLTプロセッサのxtなどが氏の実績である。その彼が自ら作り出したスキーマ言語がTREX（Tree Regular Expressions for XML）である。

　RELAXとTREXは、近いコンセプトに基づいて開発されている。いずれも、コンパクトで覚えやすく、表現力の柔軟性に優れ、巨大化しすぎたXML Schemaに対するアンチテーゼという立場をとる。そして、深くW3CのXMLワーキンググループにかかわる者たちの造反という意味でも、2人は共通している。

　それでも、W3CはXML Schemaが唯一のXMLのスキーマ言語であるという立場を崩さない。また、マイクロソフトやIBMといった大手ベンダも、XML Schemaの支持を続けるという一貫した態度をとっている。

　これがスキーマ戦争ともいわれる状況なのである。

■お墨付きを巡る争い

　最初は、いかに大物であろうと、個人が勝手に作ったスキーマ言語など、しょせんはゲリラ的な活動にすぎないという雰囲気もあった。つまり、たとえ欠点があろうと、正規にW3Cという権威によって裏付けられたXML Schemaが標準になることに疑いはない、という考え方が多かった。

　だが、この状況も大きく変化しつつある。RELAXはRELAX CoreとRELAX Namespace（詳しくは後述）の2つの仕様から構成されるが、これらの仕様に対して、公的な「お墨付き」が付加されつつある。まず、日本国内では、この2つの仕様がすでにJISテクニカルレポートとして承認されている。出版済みのRELAX Coreだけでなく、後発のRELAX Namespaceも、4月26日の情報部会でテクニカルレポートとして承認された。テクニカルレポートはJIS規格ほどの権威はないが、公的に認められないものが承認されるほど安易なものではない。ただ個人が主張するだけの仕様ではなく、ある程度安心して使えるレベルに達していることが保証されていると考えてよいだろう。

　だが、これは日本国内でしか意味を持たない。世界という場ではJISのブランド力は小さなものである。RELAXはさらに世界の場にも進み始めている。RELAX Coreは、2000年5月にISO/IECの国際投票を通過し、テクニカルレポートとして成立した。RELAX Namespaceは、2001年7月ごろにISOに提出されることが予定されている。つまり、すでにRELAXは背後に国際標準組織（ISO）のお墨付きを持つスキーマ言語になりつつあるのである。

　問題はW3Cと個人の対立ではなく、W3CとISOという力のあるブランドの対立に変化したのである。

　さて、もう1つのスキーマ言語、TREXはというと、活動の場をOASIS(Organization for the Advancement of Structured Information Standards)に移した。OASISも、XML界では非常に権威と重要度の高い団体である。W3Cが基礎技術を主に扱うのに対して、OASISはもっと応用よりの技術を扱う。また、各種スキーマの登録公開なども行い、多くのスキーマを直接扱う立場の団体でもある。もちろん、現時点でOASISがTREXを標準として承認したり、採用したという段階ではない。だが、少なくともOASISで開発が進んでいるということは、W3Cの権威が唯一ではない証拠といえよう。

■明確になる対立軸

　XML Schemaは、すでにW3Cで勧告となった。勧告となった以上は後戻りはできない。これを標準として尊重するか、それとも採用しないか、という選択しかない。意見を述べてXML Schemaの仕様を変えるということはもうできない（やるとすれば次のバージョンで、ということになる）。

　では、XML Schemaの対抗馬の方はどうか。XML Schemaに好感を持たない多くの利用者にとって、その対抗馬としてRELAXとTREXという異なる言語が存在することは好ましくない。対抗馬も1つに絞られれば、ずっと採用しやすくなる。そこで、村田真氏とJames Clark氏が協議を行い、RELAXとTREXを統一する方針が決まった。名称はRELAX NGとなる。仕様に関する議論はOASISの委員会で行われ、OASISの規格とすることを目指す。もちろん、それだけでなく、すでにRELAXがISOの場に出ている以上、ISOという場所に出ていくことも予測される。

　これが実現することによって、スキーマ戦争は、XML SchemaとRELAX NGの一騎打ちの様相を呈してきた。

■モジュール化を進めるRELAX Namespace

　ここでは、正式にJISテクニカルレポートとして承認されたRELAX Namespaceについても簡単に解説を加えよう。これは、正確にはXMLのスキーマ言語というよりも、XMLのスキーマ言語を扱うフレームワークと呼んだ方がよいかもしれない。

　RELAX Namespaceは、その名のとおり、名前空間（Namespace）を扱う。だが、ただ単に名前空間を扱えるようにRELAX Coreを拡張するものではない。名前空間はモジュールを識別するための名前として扱われる。それぞれの名前空間ごとに記述されたスキーマをモジュールと呼び、RELAX Namespaceからは複数のモジュールを取り込んで利用する形になる。

　RELAX Namespaceでは、ある名前空間で記述された一群のデータを「島」と呼び、「島」を単位にして検証を行うことができる。つまり、知らない名前空間はさておき、知っている名前空間に関してだけ検証を行うということができる。これは、知らない部分は読み飛ばして知っている部分だけ処理する、というXMLでよくある方法論を実現するためには必須の機能といえる。

　さらに、RELAX Namespaceでは、RELAX Core以外のスキーマ言語で書かれたモジュールを扱うことも機能として持つ（それが実際に実行されるためには、ほかのスキーマ言語によるバリデータと連携するように、RELAX Namespaceバリデータが構成されている必要があるが）。

　以下に例を示そう。

 1:<grammar grammarVersion="1.0"
 2:  relaxNamespaceVersion="1.0"
 3:  xmlns="http://www.xml.gr.jp/xmlns/relaxNamespace">
 4:  <namespace name="http://www.foo.co.jp" moduleLocation="foo.rxm"/>
 5:  <namespace
 6:    name="http://www.bar.co.jp"
 7:    language="http://www.thaiopensource.com/trex"
 8:    moduleLocation="bar.trex"/>
 9:
10:  <topLevel>
11:    <ref label="doc" namespace="http://www.foo.co.jp"/>
12:  </topLevel>
13:</grammar>
1行目のgrammar要素は、RELAX Namespaceの構文全体を示す。grammarVersion属性は、この定義のバージョン番号を作成者が与える。
2行目のrelaxNamespaceVersionは、RELAX Namespaceのバージョン1.0で記述されていることを示す。
3行目は、RELAX Namesace自身の名前空間をデフォルト名前空間にしていることを示す。
4行目は、早速RELAX Coreで記述されたモジュールを1個使用することを指定している。ここでは、foo.rxmというファイル名で記述されたRELAX Core文書を、http://www.foo.co.jpという名前空間のものとして扱うことを示している。
5〜8行目も同様にモジュールの指定だが、ここではlanguage属性にTREXを示すURIを記述することで、bar.trexというファイル名のTREX文書をhttp://www.bar.co.jpという名前空間として扱うことを示している。
10〜12行目は、文書のトップレベルに出現できる条件を指定している。ここではhttp://www.foo.co.jpという名前空間に属し、docというラベルで定義されているもの（詳細はfoo.rxmに記述されている）が許されるということが示されている。

　以上のように、RELAX Namespaceが切り開こうとしている地平はただ単に名前空間の付いたXML文書を検証することではない。それより先の、これから来るべき新しい地平を切り開く第1歩になろうとしているのである。

■スキーマ戦争の行方は？

　いつ勧告になるか分からないといわれたXML Schemaが、この5月2日に勧告になった。その結果、「いつ出るか分からないXML SchemaよりもいまあるRELAX」という構図は崩れた。ところが、それでスキーマ戦争に決着がついたのかというと、そうでもない。XML Schemaは大きすぎて理解できないという声は相変わらず聞こえてくる。一方の反XML Schema勢力は、ISOやOASISという強力なお墨付きのブランドを身につけて、ゲリラ戦ではなく、正規戦で戦う土俵に上がってきた。ますますスキーマ戦争の行方は分からなくなってきたのである。

　この状況で1つだけ間違いなくいえることがある。それは、健全なる競争の存在は、利用者の利益になるということである。どちらが勝者になるにせよ、併存という結果に終わるにせよ、最終的な選択権は利用者にあることを忘れてはいけないだろう。どこかの権威が勝手に結論を出すのではない。利用者が利用したものがデファクト・スタンダードの地位を手に入れるのである。

「連載 XMLフロンティア探訪」


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

注目のテーマ

HTML5＋UX 記事ランキング

本日月間
＠IT