DOM仕様書はXMLの強力さの好例として機能する。HTML文書、Java バインディング、OMG IDL バインディング、ECMAScript バインディングのすべてが、単一のセットのXMLソースファイルから生成されるのである。この節は、この仕様書がXMLでどのように書かれ、さまざまな派生的な文書がどのように作成されるのかの輪郭を描く。
この仕様書は、XML仕様書用にXMLワーキンググループによって使われているDTDに大きな基礎をもつDTDを使い、完全にXMLで書かれている。XMLワーキンググループが使っているDTDとこの仕様書で使われているDTDとの大きな違いは、インターフェイス指定のためのDTDモジュールの追加である。
インターフェイス指定のためのDTDモジュールは、OMG IDL文法のEBNF (Extended Backus-Naur Form) 版仕様書を、きわめてずぼらにXMT DTD文法へ翻訳したものである。翻訳に加えて、インターフェイスを記述する機能が追加され、それに関して、インターフェイス定義用に、読んでわかるプログラミングの制限形態を作成した。
DTDモジュールは、DOMワーキンググループの目的にとっては充分であるが、タイプ化がきわめて緩やかである。これは、型指定について課された制約がきわめて少ないという意味である(型情報は実効的には非透過文字列として扱われる)。オブジェクトコミュニケーションへのオブジェクトのためのDTDでは、データ型にもっと厳格な強制があった方がおそらく有益だったであろう。
DOM仕様書はXMLを使ってかかれている。すべての文書は妥当なXMLである。HTML版の仕様書やオブジェクト索引、Java ソースコード、OMG IDLや ECMAScript 定義を生成するためには、XML版仕様書が変換される。
変換のために現在使われているツールは、Joe English の手になる COST である。COST
は nsgmls
の ESIS 出力をとり、内部的表現を作成して、スクリプトやイベントハンドラがその内部的データ構造上で動作できるようにする。イベントハンドラは、文書パターンやそれに結びつけられる処理を指定できるようにする。文書サブツリーの命令前トラバーサルの間にパターンがマッチするときには、結びつけられたアクションが実行されるのである。これが変換処理の心臓部である。多様なコンポーネントをひとつにつなぎあわせるためにはスクリプトが使われている。たとえば、主要な派生的データソース(Java コードなど)のそれぞれはスクリプトの実行により作成され、それが今度は1つまたはそれ以上のイベントハンドラを実行するのである。スクリプトやイベントハンドラはTCLを使って指定されている。
現行バージョンの COST
は、広く入手可能なバージョンから幾分修正されている。とりわけ、現在では32ビット版 Windows の下で正しく動作し、TCL 8.0 を使い、(ネイティブ言語のマークアップは多分正しく扱えないだろうが)XMLの大文字小文字の区別の有無を正しく扱う。
我々は、James Clark の手による Jade
を使うこともできた。Jade
は COST
のようにパターンやアクションを指定できるようにするが、COST
が国際規格である DSSSL に基づいていないのに対し、Jade
はそれに基づいている。Jade
は COST
よりも多くの点で強力なのであるが、編集者は以前から COST の経験があったことから、こちらの方が Jade
よりも使いやすかったのである。将来のバージョンや水準のDOM仕様書は Jade
やXSL
プロセッサを使って生成されるかもしれない。
完全なXMLソースファイルは http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/xml-source.zip で入手可能である。
先に述べたように、オブジェクト定義はすべてXMLで指定されている。Java バインディング、OMG IDLバインディング、ECMAScript バインディングはすべて、そのXMLソースコードから自動的に生成されるのである。
これが可能なのは、XMLで指定された情報は、これらの他の文法が必要としているものの上位セットだからである。これは一般的に見られることであり、同じ種類のテクニックを他の多くの領域に適用することができる。リッチな構造が与えられるから、リッチな処理や変換が可能なのである。Java やOMG IDLについては、それは基本的に単なる文法上のキーワードの改名の問題である。ECMAScript については、処理はこれより幾分込み入っている。
XMLでの典型的なオブジェクト定義はこのようなものに見える。
<interface name="foo"> <descr><p>Description goes here...</p></descr> <method name="bar"> <descr><p>Description goes here...</p></descr> <parameters> <param name="baz" type="DOMString" attr="in"> <descr><p>Description goes here...</p></descr> </param> </parameters> <returns type="void"> <descr><p>Description goes here...</p></descr> </returns> <raises> <!-- Throws no exceptions --> </raises> </method> </interface>
簡単に見て取れるように、これはとてもうるさいが、OMG IDLに似ていないわけではない。実際に、仕様書が最初にXMLを使うよう変換されたとき、ありふれたUnixのテキスト操作ツールを使って自動的に、OMG IDL定義が対応するXMLソースに変換されたのである。