注目の言語「RELAX」の最新事情

日本発のXML標準になるか、
RELAXが目指しているもの

XMLの構文を記述する新しい言語「RELAX」が注目を集めようとしている。W3Cが制定作業をすすめているものの、いまだに姿の見えないXML Schema。RELAXの登場はこうした状況の中、XML業界の各方面から好意を持って迎えられつつある。
XMLの制定機関であるW3Cを差し置いて、まねき猫をシンボルにした日本発のXML標準が生まれるかもしれない。

川俣 晶
株式会社ピーデー
2000/5/23

RELAXとは何か?

　RELAXとはXMLの構文を記述する言語である。構文を記述するというのは、要素や属性を記述するルールを定め、あるXML文書がそのルールに合致しているかどうかをソフトウェアでチェックできるようにすることを意味する。XML 1.0仕様に含まれるDTDにほぼ相当するものと考えればよい。XML文書の妥当性を自動的にチェックする機構は、文書やデータ処理の自動化を行っている多くのユーザーの期待するところでもある。

　RELAXの仕様を作成しているのは、日本のINSTAC（情報技術標準化研究センター） XML SWGである。このワーキンググループはJSA（財団法人 日本規格協会）から委託を受けてXML関連の標準化を行っている。主査は、W3CのXMLワーキンググループにも所属し、XMLを生み出すことに尽力したことで知られる村田真氏である。RELAXは、村田真氏のライフワークのようなものであり、国内外から幅広い支援を受けている。全世界的なボランティア協力者の支援の上に成り立っていると言っても過言ではない。

　RELAXで最も特徴的と言えるのは、XMLに関する標準の提案でありながら、それがXMLを生み出した本家W3C以外の場所から生まれたことだろう。実はこのような標準には、SAXという前例がある。SAXは、W3Cが定めたDOMが複雑で大きいことに不満をもつ者達が、これとは別に、草の根レベルでAPIを定めたものだ。現在ではDOMと並んでデファクトスタンダードとなっている。だが、日本発、という仕様でXML関連デファクトスタンダードを目指すのは、RELAXが初めてではないだろうか。

その仕様は2つのパートに分かれている

　RELAXの仕様は、2つのパートに分かれている。

　1つは、「RELAX Core」と呼ばれ、すでに最終調整の段階に達している。機能的にはDTDのスーパーセットと言うことができ、基本的な構文記述能力を提供するものである。また、データ型として「XML Schema Part 2」と同等と規定されており、非常に強力なデータの表現能力を持っている。RELAX Coreは、2つの実装水準が存在する。「classic」は、DTD相当の機能だけを備えたシンプルなものであり、小型軽量な実装が可能である。「fully」はRELAX Coreのすべての機能を実装したものである。

　もう1つのパートは「RELAX Namespace」と呼ばれ、RELAX Coreの完成後に次の段階として取り組むスケジュールになっている。これは、RELAX Coreに対して、名前空間の機能を付け加えると共に、複数の構文定義を組み合わせて使用するモジュール化機能を提供する計画である。

なぜRELAXは生まれる必要があったのか?

　当然のことながら、ニーズがない仕様をいくら普及させようとしても、それは不可能だ。多くの人達に「それが欲しい」と思わせるものでなければ、普及することはない。

　RELAXが国内外から注目されると言うのは、それが必要となる状況が存在するということである。

　まず、構文記述言語の歴史をざっと振り返ってみよう。

　XMLの母体となったSGMLでは、DTD（Document Type Definition）という構文記述文法を備えており、これを用いて構文を記述した。SGMLでは構文を記述せずに文書を処理することはできないため、DTDの表現力が、SGMLの表現力の限界を規定したと言える。SGMLから派生して誕生したXMLでは、SGMLのサブセットのDTDを持っていたが、それと同時にDTDを持たない文書を「整形式(well-formed)」と呼び、許容するようになった。この時点では、それほど深刻な問題が生じていたわけではない。

強化が混乱を産み始めた

　大きな問題が発生したのは、XMLの強化技術として登場した「Namespace in XML」の出現後である。Namespace in XMLは、複数の異なる文法定義によって規定された要素や属性を、1つのXML文書の中に矛盾なく混在させる仕様である。同じ名前のタグがあっても、それが所属する名前空間を区別することによって、混乱を回避させるのである。

　だが、Namespace in XMLは、名前空間を定める方法は規定するが、それを検証する方法は規定しなかった。つまり、Namespace in XMLの導入によってXML文書本体の文法が拡張されたにもかかわらず、DTDの文法はそれに対応して拡張されていないため、文書を検証する手段に問題が生じてしまったのだ。その内容を簡単に言えば、Namespace in XMLは名前に付加する接頭辞に自由なキーワードを使うことを許しているが、DTDを用いて検証する場合は接頭辞も名前の一部と見なすしかないため、DTD記述時と異なる名前を使うと検証不能になってしまうのである。詳しい内容は「JIS TR X 0023:1999 XML名前空間」の解説で指摘されているので、興味のある方はこれをお読みいただきたい（このテクニカルレポートも、村田真氏が主査を務めるINSTAC XML SWGが翻訳を手がけたものである）。

　かつて、SGMLの時代には、わずかでも検証できない要素が入り込めば、その文書は使用できなかった。しかし、XMLには、整形式という検証なしで使用する方式が明示されているため、検証できなくても利用はできるという状況になっていた。しかし、やはり、自動検証ができたほうが、いろいろな意味でよいのは当然のことだ。自動検証したい、というニーズは深く溜まっていったのである。

構造的な機能不足も現れてきた

　これとは別に、モジュール化という問題も発生していた。別個に作られた複数の構文定義を同時に利用して1個のXML文書を書きたい、というのは、XMLの生まれた背景から考えて当然の要求である。しかし、DTDは、あらかじめ想定されていない文書定義との混用を適切に処理するためのメカニズムを欠いていた。それは根本的な構造面での機能不足であって、DTDを多少拡張するぐらいでは、解決できない問題であった。

　ここまできたら、DTDと互換性のない新しい構文定義言語を作るしかない。これが世界的なコンセンサスとなっていた。この結果、世界の各所で10を超える新しい構文定義言語の開発ブームが発生した。

　これらの言語の共通の結論は、構文定義言語そのものもXMLで記述されるべき、ということだ。たとえ構文定義言語であろうと、新しい文法を別個に覚えるのは、ばかばかしい。DTDはXML文書本体とは異なる文法で記述されていたが、これらの新しい構文定義言語は、XMLの1つの構文定義として作成されていたのである。XMLの構文定義を記述するためにXMLの構文定義を使うというのは一見自己矛盾のようにも思えるが、コンピュータの言語の世界ではよくあることである。有名なところでは、C言語コンパイラはC言語で記述されている、という例がある。

　さて、このような経緯から、W3CはXMLで使用するための唯一かつ標準となる構文定義言語の開発を始めた。これが、XML Schemaである。

　このXML Schemaが順調であれば、何の問題もなかった。

期待されていたXML Schemaはまだ登場していない

　ところが、これほど長い時間が経過したにも関わらず、まだXMLSchemaは作業中であり、勧告（Recommendation）になっていない。また、実際にXML Schemaを実装したサンプルもほとんど見あたらない。

　XML Schemaのスケジュール遅延にはいくつかの理由があると言われている。1つは、文書系とデータベース系のユーザーの確執であるといわれる。本来、XMLとその母体であるSGMLは文書処理用の言語であり、文書処理を意図した機能を備えている。そのことが、データベース系のユーザーから見ると欠陥であると映ったらしい。逆にデータベースの常識をXMLに適用することは、文書系ユーザーから見れば、XMLをねじ曲げて使い勝手を悪化させることになる。現在XML Schemaはデータベース色が濃い仕様になっているが、これが万人に歓迎されているわけではない。

　また、XML Schemaは唯一の標準を目指したために、各方面からのさまざまな要求を盛り込まざるを得ない立場にある。そのため、XML Schemaの仕様は大きくふくらんでいる。大きな仕様というのは、ただ大きいというだけで、制定に時間がかかるものである。

　これらの推測から言えることは、XML Schemaの制定にはまだまだ時間がかかりそうだ、ということだ。構造的に、そうならざるを得ない状況に陥っているように思える。

　だが、このドッグイヤーのスピードで変化するこの世界だ。

　そんなに待てないよ、という人も多い。

　そこでRELAXなのである。

RELAXの実現スピードの秘密

　なぜ、RELAXはXML Schemaと違って、驚くほどす早く実現できるのだろうか。

　もちろん、村田真氏が、この種の分野に関する第一人者であり、十分な知識とノウハウを持っている、という事実はある。だが、XML Schemaのスタッフにも優秀な人材はいるだろう。

　RELAXとXML Schemaを分ける理由を理解するにためには、「8割2割の法則」を知る必要がある。8割2割の法則とは以下のような経験則を示した言葉だ。

「8割の機能は2割の手間で実現できる。残り2割の機能を実現するために8割の手間を必要とする」

　このことは裏を返せば、8割の機能で十分と考えれば、必要な手間は2割で済む、ということを示している。

　ひとことで言えば、RELAXは8割を目指し、XML Schemaは10割を目指しているという状況の差が、仕様作りに要する時間の圧倒的な差に現れていると言える。

　だが、はたして8割の機能だけしか持たないRELAXは実用的と言えるのだろうか。

　もちろん、RELAXでは満足できないユーザーもいるだろう。だが、多くのユーザーはそれほど複雑高度な機能を必要とはしていない。多数派のユーザーは、8割の機能で満足できるだろう。

　それに重要なことは、XML Schemaを待てないユーザーも多いことだ。

　彼らには選択の余地はない。RELAXが存在することそのものが朗報なのである。

　逆に立場から見ると、RELAXに10割の機能を期待することは、意味がないといえる。それはXML Schemaの同等品を作るということを意味するからである。同程度に複雑なものを作るためには、同程度の長期間を要するだろう。それだけの時間を待つぐらいなら、XML Schemaを待つほうが得策といえる。

　RELAXは将来的にXML Schemaへの変換を視野に入れているので、とりあえずRELAXを採用し、XML Schemaの時代になったら、それに移行することも容易である。

生け垣（hedge）というもう1つの特徴

　RELAXは、ただ単にXML Schemaの遅れに対する不満だけから生まれた言語ではない。それを理解するための重要なキーワードが「生け垣（hedge）」である。

　生け垣とは、木が沢山並んでいる状況を示す言葉だ。木とは、XMLの構文が木のように次々と枝分かれする構造として描けることを指す。そして、生け垣とは、木が1つではなく、複数存在することを示している。

　もともと、DTDは、構文を1本の木として表現するものである。これがどういう意味かというと、どのような構文の断片であろうと、木のどの位置に位置づけられるかがつねに明確に決まっているということである。

　それに対して生け垣というのは、どういう状況を意味するのか。

　生け垣というのは木が複数ある状況である。木が複数あるということは、構文の解釈に複数の選択肢が存在するということだ。これによって、従来のDTDでは記述できないきめ細かい構文定義が記述できる。

　たとえば、書籍の構文を規定するとしよう。本文の段落要素の中には、脚注要素を持てるようになっている。しかし、コラムの中の段落要素の中では、脚注要素は禁止したいとする。従来のDTDの場合、これを実現するためには、「本文の段落要素」と「コラムの段落要素」は異なる名前の要素として定義しなければならなかった。しかし、どちらも段落なのだから、<p>のような同じ名前で書く方が分かりやすい。これを実現するために、RELAXは、生け垣の概念を採用したのである。

　これは、構文定義言語の表現力を拡大する大きな前進と言える。

RELAXは普及するか?

　どんなに素晴らしい言語であろうと、ニーズがなければ普及することはない。だが、XMLの構文定義言語に関しては、世界的に強いニーズが存在するのが現実である。

　では次に、RELAXが彼らのニーズに応えられるのかが問題になる。これに関しては、すでに説明したように、すべてのユーザーを満足させるものではないが、大多数のユーザーを満足させる水準に達していることを説明した通りである。さらに、生け垣などの特徴的な機能もあるため、機能面では、十分利用するに値するものと言える。

　すると、次に問題になるのが安心感だ。XML Schemaは天下のW3Cのお墨付きの構文定義言語だ。それに対してRELAXには、どんなお墨付きが付くのか。

　結論から言えば、JSAがRELAXをJISテクニカルレポートとして発行する予定である。JISテクニカルレポートとは、JIS規格ではないものの有益な情報をす早く提供するために発行される情報のことである。規格ほどの強制力はないにせよ、公的な組織から出版されるということは事実である。これが、RELAXに対して信用の裏付けを得るものと期待される。

　さて、これとは別に気になるのは、RELAXを利用するためには、それに対応したソフトウェアが必要になることだ。しかし、すでにボランティアの開発したソフトウェアが何種類も公開されており、また商品としてのソフトウェアでRELAXをサポートする例も出ている。国内外の多くがRELAXに好意的であることから、この傾向は拡大していくものと思われる。

　さらに、単なる構文チェックを超えた応用ソフトウェアも出始めている。浅海智晴氏が作成したRelaxerは、RELAXの構文定義ファイルを読み込んで、その構文に従ったクラス構造を持つJavaソースコードを生成する。もちろん、生成されたソースコードは完全なアプリケーションソフトウェアではない。しかし、情報の整理分類と、それを処理するコードをすべて自分の手で記述することに比べれば、大きな手間の軽減となる。

　これまでは、XMLを使うとプログラミングの手間が増えるという事態も発生していたが、Relaxerのようなソフトウェアが出現したことにより、XMLを使うことで手間を軽減できるという状況に変化しつつある。このような有用なソフトウェアが存在することが、RELAXを利用する強力な動機の1つとなるかもしれない。

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