REC-DOM-Level-1-19981001

標準情報(TR) TR X 0019:1999

文書オブジェクトモデル(DOM)水準1 規定

Document Object Model (DOM) Level 1 Specification

序文

この標準情報(TR)は，1998年10月にWorld Wide Web Consortium(W3C)から公表された Document Object Model (DOM) Level 1 Specification, version 1.0 勧告を翻訳し，技術的内容を変更することなく作成した標準情報(TR)である。

0. 適用範囲 (文書オブジェクトモデル)

0.1. はじめに

文書オブジェクトモデル(Document Object Model，以降DOM)は，HTML文書及びXML文書のためのアプリケーションプログラムインタフェース(Application Programming Interface，以降API)とする。これは，文書の論理構造及び文書にアクセスし操作する方法を定義する。 DOM規定では，"文書"という用語を広義の意味で使用する。 XMLは，日増しに，多様なシステムに格納される数多くの異なる種類の情報を表現する方法として使われるようになっており，その多くが，従来は文書というよりもデータとみなされてきたものである。それにも関わらず，XMLは，このデータを文書として表現し，DOMをこのデータの管理のために使用してもよい。

文書オブジェクトモデルがあれば，プログラマは文書を作成し，その構造をたどり，要素及び内容の追加，修正又は削除を行うことができる。 HTML文書又はXML文書にあるものはすべて，文書オブジェクトモデルを使用して，アクセス，変更，削除又は追加が可能となる。ただし，いくつかの例外もある。特に，XMLの内部サブセット及び外部サブセットに対するDOMインタフェースは，まだ規定されていない。

W3C の規定として，文書オブジェクトモデルの重要な目的の一つは，幅広い環境及びアプリケーションにおいて使用可能な標準プログラムインタフェースを提供することにある。 DOMは，任意のプログラム言語と共に使用する設計となっている。 DOMインタフェースの正確な言語に依存しない仕様を提供するために， CORBA 2.2規定が定義するOMG IDLで規定を定義することにした。 OMG IDL規定に加えて，Java及びECMAScript(JavaScript及びJscriptに基づく業界標準スクリプト言語)への言語結合を提供する。

備考　OMG IDLは，インタフェースを規定する，言語非依存及び実装非依存な方法としてだけ使用する。一般に，IDLは，特定の計算機環境に対して設計される。文書オブジェクトモデルは，任意の計算機環境で実装可能で，一般にそれらIDLに関連付けられる実行時を束縛するオブジェクトを要求しない。

0.2. 文書オブジェクトモデル

DOMは，文書のためのプログラムAPIとする。それは，DOMがモデル化する文書の構造と非常に似ている。 HTML文書から取った次の表を例に示す。


      <TABLE>
      <TBODY> 
      <TR> 
      <TD>Shady Grove</TD>
      <TD>Aeolian</TD> 
      </TR> 
      <TR>
      <TD>Over the River, Charlie</TD>        
      <TD>Dorian</TD> 
      </TR> 
      </TBODY>
      </TABLE>

DOMは，この表を図1のとおりに表現する。

図1 例示した表のDOM表現

DOMにおいては，文書は，木によく似た論理構造をもつ。より正確には，二つ以上の木を含むことのできる"森"あるいは"グローブ"に似ている。しかし，DOMは，文書を木又はグローブとして実装しなければならないと規定しないし，オブジェクト間の関係を実装する方法を規定もしない。 DOMは，任意の簡便な方法で実装してよい論理モデルとする。この規定では，構造モデルという用語を文書の木に類似した表現を示すために使用する。特に，特定の実装を示唆することを避けるために，"木"又は"グローブ"に類似した用語を使用しない。 DOM構造モデルの重要な特性の一つは，構造同型にある。すなわち，任意の二つの文書オブジェクトモデル実装を同じ文書の一つの表現を生成するために使用する場合，それらは，正確に同じオブジェクト及び関係をもつ同じ構造モデルを生成する。

"文書オブジェクトモデル"という名前は，伝統的なオブジェクト指向設計の意味でそれが"オブジェクトモデル"であるという理由で選択した。すなわち，文書をオブジェクトを使ってモデル化し，そのモデルが，文書の構造だけでなく文書及びそれを構成するオブジェクトの振る舞いも含む。換言すると，図1の中のノードは，データ構造を表現するのではなく，機能及び識別性をもつオブジェクトを表現する。オブジェクトモデルとして，DOMは次を識別する。

文書を表現及び操作するために使用するインタフェース及びオブジェクト。
これらのインタフェース及びオブジェクトのセマンティクス。これは，振る舞い及び属性の両方を含む。
これらのインタフェース及びオブジェクトの間の関係及び協調。

SGML文書の構造は，伝統的に，オブジェクトモデルではなく抽象データモデルによって表現されてきた。抽象データモデルでは，モデルが中心になり，そのまわりにデータが存在する。オブジェクト指向プログラム言語では，データを隠し，それを直接的な外部操作から保護するオブジェクトの中に，データそれ自体をカプセル化する。これらオブジェクトに関連付けられた機能は，オブジェクトが操作される方法及びオブジェクトがオブジェクトモデルの一部となる方法を決定する。

文書オブジェクトモデルは，現在，DOMコア及びDOM HTMLの二つの部分から構成される。 DOMコアは，XML文書に対して使用する機能を表現し，DOM HTMLのための基本としての役割も果たす。 DOMに準拠する実装では，コアの部分の基礎インタフェースのすべてを，定義するとおりのセマンティクスで実装しなければならない。さらに，少なくとも，HTML DOM及び拡張(XML)インタフェースの一つを，定義するとおりのセマンティクスで実装しなければならない。

0.3. 文書オブジェクトモデルの適用範囲外

0.3.では，DOMとDOMに類似するかもしれない他のシステムとを区別することによって，DOMをより正確に理解することを目指す。

文書オブジェクトモデルは，水準1では"動的HTML"に強く影響されているが，"動的HTML"のすべてを実装はしない。特に，イベントはまだ定義していない。水準1は，文書それ自体の頑健で柔軟なモデルを提供することによって，この種の機能に対する堅固なプラットフォームを据えるために設計する。
文書オブジェクトモデルは，バイナリ規定ではない。同じ言語で書いた DOMプログラムは，様々なプラットフォームを横断してソースコード互換だが， DOMは，バイナリ相互運用性のいかなる形式も定義しない。
文書オブジェクトモデルは，オブジェクトをXML又はHTMLで表す方法ではない。オブジェクトをXMLで表現する方法を規定する代わりに，DOMは，XML文書及びHTML文書をオブジェクトとして表現する方法を規定する。その結果，それらをオブジェクト指向プログラムで使用できる。
文書オブジェクトモデルは，データ構造の集合ではなく，インタフェースを指定するオブジェクトモデルとする。この規定には，親子関係を示す図が存在するが，これらはプログラムインタフェースが定義する論理的関係であって，特定の内部データ構造の表現ではない。
文書オブジェクトモデルは，XML又はHTMLの"正しい内部的なセマンティクス"を定義しない。それらの言語のセマンティクスは，それらの言語に対するW3C勧告が定義する。 DOMは，これらのセマンティクスを尊重して設計したプログラムモデルとする。 DOMは，XML文書及びHTML文書を書く方法の分派ではない。これらの言語で書くことのできる任意の文書は，DOMで表現できる。
文書オブジェクトモデルは，その名前にもかかわらず，Component Object Model(以降COM)と競合するものではない。 CORBAと同様に，COMは，インタフェース及びオブジェクトを規定する援護に依存しない方法である。 DOMは，HTML文書及びXML文書を管理するために設計されたインタフェース及びオブジェクトの集合とする。 DOMは，COM又はCORBAに類似する言語非依存のシステムを使って実装してよい。この規定で規定するJava結合又はECMAScript結合に類似する言語固有な結合を使用して実装してもよい。

0.4. 文書オブジェクトモデルの経緯

DOMは，JavaScriptスクリプト及びJavaプログラムがウェブブラウザ間で移植可能とするための規定として生じた。 "動的HTML"は，文書オブジェクトモデルの直接の先祖であって，それは，元々は主にブラウザの観点から考えられた。しかし，DOM作業グループがW3Cで形成された時，HTML又はXMLのエディタ及び文書リポジトリを含む他の領域のベンダも参加した。これらのベンダの中には，XMLが開発される以前は，SGMLの仕事をしてきたものがいた。その結果，DOMは，SGMLグローブ及びHyTime規格の影響を受けた。これらのベンダの中には，SGML/XMLエディタ又は文書リポジトリのためのAPIを提供するために，独自の文書オブジェクトモデルを開発したものもいた。これらのオブジェクトモデルも，DOMに影響を与えた。

0.5. 実体及びDOMコア

基礎DOMインタフェースには，実体を表現するオブジェクトは存在しない。数値文字参照並びにHTML及びXMLでの定義済み実体への参照は，実体の置換を行う単一の文字によって置き換えられる。次に例を示す。


        <p>This is a dog &amp; a cat</p>

"&"は，文字"&"に置き換えられ， P要素におけるテキストは，一つのの連続した文字列を構成する。数値文字参照及び定義済み実体は，CDATAセクション又はHTMLのSCRIPT 要素及びSTYLE要素では，このとおりには認識されないので，それらが参照する単一の文字によっては置き換えられない。この例がCDATAセクションで囲まれた場合，"&"は"&" では置き換えられない。 <p>が開始タグとして認識されることもない。一般実体の表現は，内部及び外部の両方とも水準1規定の拡張(XML)インタフェース内で定義する。

備考　文書のDOM表現がXML又はHTMLのテキストとして直列化される場合，アプリケーションは，テキストデータ内の個々の文字が数値実体又は定義済み実体を使用して別扱いする必要があるかどうかを確かめるために，それらの個々の文字を検査する必要がある。これに失敗すると，妥当ではないHTML又はXMLを生じる可能性がある。 ISO 10646に完全には対応していない文字符号化("charset")への直列化は，マーク付けの中に又はCDATAセクションの中にその符号化に存在しない文字がある場合には，失敗するかもしれないという事実を，実装は認識しているほうがよい。

0.6. DOMインタフェース及びDOM実装

DOMは，XML文書又はHTML文書を管理するために使用してもよいインタフェースを規定する。これらのインタフェースは，C++の"抽象基底クラス"とよく似た抽象であって，アプリケーションにおける文書の内部表現をアクセス及び操作する方法を規定する手段となることを理解するのは重要である。インタフェースは，特定の具体的な実装を示唆しない。 DOMアプリケーションは，この規定が示すインタフェースをサポートする限りにおいて，任意の簡便な表現で文書を保持して構わない。 DOM実装の中には，DOM規定が存在するずっと以前に書かれたソフトウェアにアクセスするために， DOMインタフェースを使用する既存のプログラムもある。そこで，DOMは，特に次の点で，実装依存を避ける設計がなされている。

a)	IDLで定義する属性は，特定のデータメンバをもたなければならない具象オブジェクトを示唆しない。言語結合において，それらは，データメンバではなくget()及びset()関数の対に変換される。 (読込み専用関数は，言語結合においてget()関数だけをもつ。)
b)	DOMアプリケーションは，この規定には存在しない付加的なインタフェース及びオブジェクトを提供してもよく，それでもDOM準拠とみなす。
c)	インタフェースは規定するが，生成する実際のオブジェクトは規定しないので，DOMは，ある実装に対してどのコンストラクタを呼び出すのが望ましいかを知ることはできない。一般にDOMユーザは，文書構造を生成するためにDocumentクラスのcreateXXX()メソッドを呼び出し，DOM実装が，createXXX()関数の実装の中にこれら構造のそれ自体の内部表現を生成する。

0.7. 水準1の制限

DOM水準1規定は，意図的に，文書構造及び内容を表現し操作するために必要なメソッドに制限されている。 DOM規定の将来の水準が，次を提供する予定である。

a)	内部サブセット及び外部サブセットに対する構造モデル。
b)	スキーマに対する妥当性検証。
c)	スタイルシートを介した文書のレンダリングの制御。
d)	アクセス制御。
e)	スレッド安全性。
f)	イベント。