XMLフロンティア探訪
第9回 XHTMLモジュールを利用した言語開発
（中編）
前回、上司から呼び出されて、自社の情報システム用に新しい言語をXMLで作ることを決心したA君。しかもA君はわずか1週間でその言語を開発したのだが、そのカギは、「モジュール」にあった。前回に引き続きXHTMLモジュールの解説だ。（編集局）
というわけで、前回からXHTMLの持つモジュールについて解説をしている。今回も早速、便利なモジュールの宝庫であるModularization of XHTMLを見てみよう。以下の要素のリストは、先頭が要素名で、それに続く名前が属性または属性のコレクションの名前である。これらの解説は今回で終わり、次回からはこれらを応用した言語作りの解説に入るが、まずは個々の機能を見てほしい。
|
画像を文書に挿入するimg要素のみを含むモジュールである。このモジュールは単純に画像を表示する機能だけを含み、イメージマップなどは後述の別のモジュールに含まれる。表示だけできればよい、というニーズも意外と多いので、このモジュールの出番は多いと思われる。
|
クライアント側で処理されるイメージマップを実現するモジュールである。上記リストの中で、名前に&記号の付いたものがあるが、これはほかのモジュールで定義された要素である。例えば、“img&”と書かれているのは、Image Moduleで定義されているimg要素に当たる。つまり、このモジュールを使用するには、Image Moduleかあるいはimg要素を定義する何らかのモジュールとの併用が必要とされるのである。
|
サーバ側で処理されるイメージマップを実現するモジュールである。実はこのモジュールに固有の要素は存在しない。img要素は&記号が付いていることから分かるとおり、Image Moduleで定義されているimg要素に当たる。しかし、何も付け加えていないわけではない。ismap属性は、Image Moduleでは定義されておらず、このServer-side Image Map Moduleを利用したときのみ存在するものである。モジュール選択により、利用可能な属性が増減する場合も存在するのである。
|
汎用のオブジェクトを文書に埋め込む手段を提供するモジュールである。ほかのプログラム言語で作成されたモジュールを取り込んで、何らかの処理を実行させることができる。具体的に何を実行させるかは、何も規定されていない。
| Frames Module |
|
フレーム機能を実現するモジュールである。複数文書を組み合わせて1つの画面を構成する言語なら、HTMLのほかの機能を利用しない場合でも、このモジュールだけ利用する価値があるかもしれない。
| Target Module |
|
名前に&記号が付いていることから分かるとおり、これらの要素を定義するモジュールではない。これは、これらの要素にtarget属性を付け加えるためのモジュールである。なお、targetはフレームの名前を指定する属性なので、必然的にFrames Moduleを補佐するために使われることになるだろう。
| Iframe Module |
|
インラインフレームを扱うモジュールである。
|
イベントについての情報を記述するモジュールである。要素名に&が付いていることから分かるとおり、このモジュールは、それぞれの要素に属性を付け加える機能を持つ。このモジュールを使うと、例えばbody要素にonload属性を付けることが可能になる。onload属性では文書が読み込まれた時点で処理すべき内容を指定できる。当然、スクリプト言語なども併用することが前提になるだろう。
|
ヘッダ内に記述するメタ情報を記述するモジュールである。独自言語を作っているなら、メタ情報に相当する情報を、独自の要素を定義して表現することも検討する価値があるだろう。XMLでは、文字のエンコーディングの指定はXML宣言などを用いるので、その目的では使う必要がないかもしれない。
| Scripting Module |
|
スクリプト言語を利用するためのモジュールである。このモジュールは特定のスクリプト言語に限定されずに使用できるので、ただ単にこのモジュールを取り込むだけでは何でもありの仕様になりかねない。実際に記述するスクリプト言語を限定したいなら、このモジュールを使用すると宣言するだけでなく、制限に関する指定も明示的に付け加える必要がある。
|
スタイルシートを指定するモジュールである。XMLには、処理命令（PI）を用いてスタイルシートを指定する方法（Associating Style Sheets with XML documents）が別途存在するので、このモジュールを取り入れる前に、どちらが適しているかを検討すべきだろう。従来のWebブラウザでHTML文書として扱うことを意識するなら、このモジュールを使うべきだが、XSLTスクリプトでHTMLへ変換後にWebブラウザで表示させるなら、処理命令を使う方法が適しているだろう。
実はこのモジュールには、要素と属性のリストが与えられていない。このモジュールが取り込まれると、Commonと名付けている属性の集合に、style属性が追加される。もちろん、style属性はスタイル指定を書き込むための属性である。これにより、多くの要素にスタイル指定を直接付加することが可能になる。
|
文書そのものに関連する情報をリンクする手段を提供するモジュールである。link要素は、例えばある文書に対して目次として機能するページを指定する、といった目的で使われる。
|
ベースURIを指定するモジュールである。Webサーバなどに文書群を展開して使う場合に、文書の相対してのベースになるURIを指定するために使用できる。
|
名前に&記号が付いていることから分かるとおり、このモジュールはそれぞれの要素にname属性を付け加える機能を提供する。name属性は古いHTML文書との互換性のために存在するものなので、まったく新規に作成する言語にこのモジュールを使う必要はないだろう。通常はid属性だけあれば十分である。
|
互換のための機能を集めたもので、新しい言語を作る場合には使う必要はないだろう。
HTMLの上位互換の言語を作ろうという意図を持って、古いHTML文書もすべて受け入れられるように設計する場合はこのモジュールを利用する必要があるかもしれない。しかし、古いHTML文書はXMLパーサをまず通らないので、事前に適正なXML文書の条件を満たすように修正するプログラムを作成しなければならない。できればそのプログラム内で、これらのレガシーな要素や属性を、推奨される要素や属性に置き換えてしまい、言語そのものにはこのモジュールを含めない方が、コ ンパクトで分かりやすい言語になるだろう。
さて、XHTMLのモジュールについて、概要を説明した。実際にこれらを使うと何が達成できるのだろうか。一例として、XHTML Basicを見てみよう。
XHTML Basicは、XHTMLの中でごく基本的な機能だけをサポートしたコンパクトなコンテンツ記述言語である。これは、容量の小さいモバイル機器などで使うのに適しており、実際に携帯電話向けコンテンツ言語として、XHTML Basicを採用する例もある。
では、XHTML Basicという新しい言語を作る手間はどれぐらいのものだろうか。その仕様書はどれぐらいの厚みになるだろうか。その答は、W3CのサイトにあるXHTML Basicの仕様書を見れば分かる。事実上、言語の定義に当たるのは、3. The XHTML Basic Document Typeの部分だが、だいたい30行ぐらいで終わっている。その記述内容の多くは、XHTML Basicで使用するモジュールの名前を列挙することに費やされている。要点だけ凝縮するなら、XHTML Basicとは以下のモジュールの集合体だといえる。
|
たったこれだけである。これで1つの言語として成立し、利用可能になる。仕様書は極めて短くなるし、多くの定義をプロの書いた文書に依存することになるので、間違いも入り込みにくい。仕様が短いことは、それだけで多くのメリットを生む。関係者に「読んでみてください」と配った場合、長い仕様は長いというだけで読んでもらえないことがある。しかし短ければそのリスクを軽減できる。読み手だけでなく、書き手の労力も少なくて済む。労力が少なければ、文書を書くだけで力尽きたりせず、ほかのいろいろなことに注意を払う余裕ができるのである。
XHTMLのモジュールだけで構成される言語なら、上記のように簡単に作れる。しかし、多くの場合それだけでは機能が不十分であり、XHTMLには含まれない機能を取り込む必要が生じる。ここでは、人名のために込み入った文字を記述する必要があるとしよう。そこで、本連載の第2回目で紹介した「JIS TR X 0047 XMLによる画像参照交換方式」をXHTML Basicと併用して利用したいと考えたとしよう。このXMLによる画像参照交換方式も、モジュールとして利用されることを前提とした仕様なので、実現することは決して難しくはない。
というわけで、次回は異言語モジュールの組み合わせについての詳しい解説を行いたいと思う。請うご期待。
 |
「連載 XMLフロンティア探訪」 |
- QAフレームワーク：仕様ガイドラインが勧告に昇格 （2005/10/21）
データベースの急速なXML対応に後押しされてか、9月に入って「XQuery」や「XPath」に関係したドラフトが一気に11本も更新された - XML勧告を記述するXMLspecとは何か （2005/10/12）
「XML 1.0勧告」はXMLspec DTDで記述され、XSLTによって生成されている。これはXMLが本当に役立っている具体的な証である - 文字符号化方式にまつわるジレンマ （2005/9/13）
文字符号化方式（UTF-8、シフトJISなど）を自動検出するには、ニワトリと卵の関係にあるジレンマを解消する仕組みが必要となる - XMLキー管理仕様（XKMS 2.0）が勧告に昇格 （2005/8/16）
セキュリティ関連のXML仕様に進展あり。また、日本発の新しいXMLソフトウェアアーキテクチャ「xfy technology」の詳細も紹介する
 |
|
|
|
|
