新しいXMLプログラミングを実現するDOM 2

DOM Level 2がW3Cより勧告された。この新しい仕様は以前に比べ大幅に強化されており、動的なスタイルの変更などのダイナミックコンテンツが容易になり、トラバーサル機能やイベントの対応など、プログラマーが望んでいた機能が幾つも含まれている。 DOM2でなにが変わるのか、その中身に迫る。

株式会社ピーデー
川俣 晶

主な内容 DOM経由でXMLとHTMLへアクセス 激増したDOM 2の仕様 CSSをオブジェクトとして扱える 　DOMツリーのアクセスが簡単になる マウスの操作に反応するXML/HTML文書も CoreのLevel 1からの変更点 DOM 2で世界はどう変わるか?

DOM経由でXMLとHTMLへアクセス

　2000年11月13日、DOM Level 2（以下、場合によってはDOM2と略す）がW3Cより勧告された。DOMとは、Document Object Modelの略であり、文書をオブジェクトとしてアクセスする手段を規定するAPIである。XMLの利用者であれば、DOMの名前を知っていたり、実際に利用している人も多いと思う。DOMは、SAXと並んで、XML文書にアクセスする標準APIの1つである。

　しかし、DOMはXML専用のものと考えてしまうと、それは正しい認識ではない。DOMは、HTMLのためのものでもあるのだ。例えば、Dynamic HTMLで作成されたWebページにおいては、埋め込まれたスクリプトによってHTMLの要素や属性を書き換えていく、というテクニックがある。動的にHTMLが変化することによって、それに応じて実際に画面に表示される内容も変化する。ここで、要素や属性を書き換えるために使用されているオブジェクトも、DOMなのである。

　実は、W3C標準ではないDOM Level 0と通称されるものが存在する。これは、Netscape Navigator version 3.0とMicrosoft Internet Explorer version 3.0に組み込まれた文書オブジェクトを示す言葉である。その後、これらのWebブラウザは、W3CのDOM Level 1を実装するようになった。おそらく、これらのWebブラウザの将来のバージョンは、今回のDOM Level 2を実装することになるだろう。

激増したDOM 2の仕様

　それでは最初に、DOM Level 2の仕様書がどのような構成になっているかを見てみよう。DOM Level 1の仕様書は、基本的に1本の仕様書で内容は主に2つの章に分けられた。

• Chapter 1: Document Object Model (Core) Level 1
• Chapter 2: Document Object Model (HTML) Level 1

　第1章のCoreは、DOMの基本機能を規定するものである。XMLの世界でDOMという場合は、このCoreの部分を示していた。それに対して、第2章のHTMLは、DOMをHTML文書の操作に使用する場合の規定を記述したものである。

　Level 2では、この構成が大幅に変化している。まず、もともと1本であった仕様書が、6本の仕様書に増えた。それぞれの仕様書の名前は以下のとおりである。

• DOM Level 2 Core Specification
• DOM Level 2 Views Specification
• DOM Level 2 Style Specification
• DOM Level 2 Events Specification
• DOM Level 2 Traversal and Range Specification
• DOM Level 2 HTML Specification (注：これのみまだ勧告になっていない)

　見てのとおり、まさに激増といってよい。しかも、一番上のCoreと、一番下のHTMLは、Level 1の2つの章から分かれたものだということは推測できるが、残りの4つは、まったく新規に生まれ出たもののように見える。

　実際に、個々の仕様書の持つ意義に関しては、この後で個別に説明する。それを通して分かることは、無駄な仕様が増えたわけではないことである。つまり、従来のDOM Level 1は、決して十分な機能を持っていなかったことを示している。

■DOMは単純な1つの機能ではなく、利用者ごとに姿が違う

　しかし、これまでDOM利用者は、過去のLevel 1をDOMだと理解して、それで納得していた人も多いはずである。にもかかわらず、はたと気付いてみれば、確かに足りない機能が多くあり、それがLevel 2では満たされている。これは、DOMという存在が、単純な1つの機能ではなく、見る角度によって、いろいろと姿を変えてみせる、多次元的な存在であることを示している。つまり、あるDOM利用者にとってのDOMと、別のDOM利用者にとってのDOMは、同じ姿に見えていないかもしれない、ということを意味する。これは、DOM Level 2を理解するための最初の前提といえるだろう。

　なお、DOM Level 2 HTML Specificationは、まだ勧告になることができず、ワーキング・ドラフトレベルに差し戻されている。そのため、今回は解説を割愛する。

CSSをオブジェクトとして扱える

　DOM Level 1は基本的に、要素や属性のツリーに対して作用するものであった。XMLによるスタイルシートであるXSL（T）は、変換言語を使うという構造の性質上、内容をリアルタイムに変化させるには適していないが、DOM Level 1でもスタイルシートを操作するに足る機能を持っていたといえる。

　それに対してHTMLではスタイルシートとしてCascading Style Sheet（CSS）を用いるが、CSSはCSS独自の文法で記述するものであり、要素や属性を用いて記述するわけではなかった。つまり、その結果として、Level 1ではCSSをオブジェクトとして扱うことはできなかった。もちろん、CSSがまったく使えないというわけではなく、style属性にCSSを指定するという方法はあった。だが、この方法では、CSSをオブジェクトではなく、文字列として扱うことになり、効率が良いとはいえない。

　オブジェクトなら、直接メソッドを呼び出して、スタイルを変更できるのだが、文字列として扱う場合は、スタイルを指定する文字列を作成して、属性の値として設定することになる。もちろん、スタイル変更を処理するためには、CSSの構文解析を行う必要がある。同じプログラム内部なのに、文字列の生成と解析をいちいち行わねばならないのは無駄である。直接、メソッドを呼び出して変更させれば、その無駄を省くことができる。

■XMLのスタイルもオブジェクトモデルに

　Document Object Model (DOM) Level 2 Style Specificationは、まさに、これを行うための仕様である。この仕様は、大きく分けて、2つの機能に分かれる。

• Chapter 1: Document Object Model Style Sheets
• Chapter 2: Document Object Model CSS

　Chapter 1は、スタイルシートと文書の関連づけの情報を扱う。HTMLからはLINK要素やSTYLE属性で指定するものに対応する。XMLでは、Associating Style Sheets with XML documentsでスタイルシートを指定する機能に相当する。

　Chapter 2は、CSSそのもののオブジェクトモデルである。各種ルールを扱うインターフェイスが定義されている。出力メディアのルール(CSSMediaRule)、フォントの名前に関するルール(CSSFontFaceRule)、ページに関するルール(CSSStyleSheet)などのインターフェイスがある。

　これらを活用することにより、表示中に動的にスタイルシートを入れ替えたり、スタイルシートの設定を変化させるダイナミックなコンテンツの作成が容易になると同時に、処理の効率もアップすることが予測される。

DOMツリーのアクセスが簡単になる

　Document Object Model (DOM) Level 2 Traversal and Range Specificationは、直接関係のない2つの機能を定義している。

■DOMツリーをより便利に渡り歩くTraversal

　トラバーサル（Traversal）は、DOM Coreで規定されるツリーに対してアクセスするインターフェイスである。もちろん、DOM CoreはアプリケーションプログラムからアクセスできるAPIを規定しており、理論的にはそれだけでどんな処理も実現できる。実際にこれまでは、そのようにしてさまざまなプログラムが作られてきた。

注：XML文書を処理する場合、通常はDOMツリーを生成し、それに対して要素の追加や変更などの操作を行う。こうした場合、まずDOMツリーの根（ルート）からたどって、ツリーを上ったり下りたりしながらさまざまな処理を行うことになる。この移動をトラバースという。

　しかし、それが便利であったかどうかは別問題だ。よく使われるプログラム言語であるJavaやC++は、ツリー構造を効率良くアクセスする手段を持っていない。そのため、ただ単にDOMツリー全体を巡回するだけでも、再帰呼び出しなどのテクニックを用いる必要があった。しかし、このような、よく使われる処理をいちいち記述することは無駄である。効率よくDOMツリーを巡回する手段として、Traversal機能が用意されたのである。

　Traversal機能は、より具体的に見ると、NodeIterator、NodeFilter、TreeWalkerの3つに分けられる。NodeIteratorは、いわゆるイテレータである。つまり、DOMツリー全体を順番にアクセスする、という機能を提供する。NodeIteratorに任せておけば、自分で親子兄弟のすべてを巡回するように注意しながらプログラムを書く必要がなくなる。イテレータが、親子兄弟のすべてをまんべんなく巡回させてくれる。

　NodeFilterは、NodeIteratorで巡回する際に、巡回する対象とすべきかどうか判断する機能を提供する。判断するための条件を提供するには、NodeFilterのインターフェイスを持つオブジェクトを作成して、NodeIteratorにセットすれば良い。もちろん、NodeFilterのインターフェイスを実装するのはプログラマ自身なので、どのような条件でも自由に実装できる。

　最後に残ったTreeWalkerは、NodeIteratorに似ているが、やや異なる特徴を持つ。これは、DOMツリー全体を巡回するためのものではなく、DOMツリーを上下左右に移動しながら処理を行うためのものだ。つまり、TreeWalkerのオブジェクトは、自分がDOMツリー上のどこを指し示しているかの情報を持っている。そして、TreeWalkerオブジェクトに対して、親の方向に上がれとか、弟の方向に進め、という指示を出すことで、TreeWalkerオブジェクトが指し示すノードが変化する。DOMツリー全体を見る必要はないが、DOMツリーの中を移動しながら処理する場合に適する機能である。

■選択範囲を示すRange

　さて、もう1つのRangeの機能は、DOMツリー内の選択範囲を示すことである。文書を処理する場合には、処理したい場所を、点として指し示すだけでは不十分で、「ここからここまで」と範囲を指定する場合がよくある。この範囲を指定するという機能を提供するのが、Rangeである。

　通常、ツリーを処理するプログラムでは、ある点から下のツリー全体、と指定するのは容易である。しかし、実際にはそのような単純な指定で済むことは多くなく、ツリーの途中のある場所から、それとはまったく別の階層にある別の場所まで、という指定を行うには、少しややこしい情報を持つ必要がある。しかも、文字列の途中から別の文字列の途中まで、といった、ノード単位ですら割り切れない指定が要求されたりする。このような指定を反映可能にすると、少々複雑なデータ構造になる。そこで、ここではDOM Level 2の付帯仕様として標準化を行ってしまうというわけだ。DOMプロセッサがRangeの機能を提供してくれれば、範囲指定を必要とするプログラムが書きやすくなるのである。

マウスの操作に反応するXML/HTML文書も

　Document Object Model (DOM) Level 2 Views Specificationは、非常に短い仕様書である。だが、短すぎて機能を理解するのは難しい。この仕様書が示しているのは、DOMツリーはCSSなどの情報によって、実際に表示される情報（view）の形となって表示されるということである。つまり、DOMツリーには、関連づけられたviewが存在するということだけである。だが、これは単体では何の意味も持たない。これが意味を持つのは、もう1つの、Document Object Model (DOM) Level 2 Events Specificationと組み合わさったときである。これは、DOMにおけるイベントに関する仕様を定めたものである。

■イベントに反応する

　イベントとは、マウスボタンが押された、といった出来事をつかまえて、指定したスクリプトを実行させる機能である。イベントは、viewで発生するという考え方を取るので、イベントとDOMツリーを関連づけるために、viewという概念が必要とされるわけである。

　さて、イベントの機能は、Internet ExplorerやNetscape NavigatorなどのWebブラウザにはすでに組み込まれているものである。Level 1では、これに関する標準は定められていなかったが、Level 2になり、ようやく標準化にこぎ着けた、という感じだろう。イベントの機能としては、まず、イベント発生時に実行すべき機能を登録するメカニズムがあるのは当然として、マウス操作、DOMツリーの編集を通知するイベント、それから、HTML文書に関連して発生するイベントなどのカテゴリーがサポートされている。しかし、キーボードに関するイベントは、将来のバージョンでなすべきものとして、定義されていない。

■XMLパーサの機能をチェック

　Level 2ではすべての機能が必須というわけではない。ある機能が実装されているかどうかはDOMImplementationインターフェイスのhasFeatureメソッドを使用して確認することができる。例えば、DOM2 Viewsがサポートされているかどうかは、hasFeature("Views", "2.0")というメソッド呼び出しで判定できる。

CoreのLevel 1からの変更点

　Document Object Model (DOM) Level 2 Core Specificationの機能は、Level 1のCoreと、それほど変わってはいない。それぞれのインターフェイスに、これまで不足していた幾つかの機能が追加されている程度である。基本的な考え方は変わっていない。

　追加されたのは、Attrインターフェイスで、その属性のオーナーとなる要素を知るためのownerElementメソッドや、名前空間を明示的に扱う機能などである。また、DOMTimeStampというデータ型が追加されている。

DOM 2で世界はどう変わるか?

　Level 2の出現によって、劇的にWebの世界が変わる、ということはないだろう。しかし、Level 2の内容は確実にLevel 1より進化しており、プログラマーから見た使い勝手は良い方向に変化していると考えられる。ダイナミックなHTMLコンテンツを開発している利用者なら、Level 2を利用することで、よりコンパクトで強力なページを開発可能になるだろう。しかし、そう簡単にWebブラウザが世代交代してくれない現状で、Level 2を前提にしたページが書けるかというと、もしかしたら難しいかもしれない。

　XML文書を処理するためのAPIという観点から見れば、Level 2対応のXMLパーサが増えてくれば、利用する機会も多くなるだろう。しかし、その場合に意味を持つのは、Coreと、もしかしたらTraversalとRangeのみで、ほかの仕様書を利用する機会は少ないかもしれない。

　

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