1. Document Object Model Core

1.1.1. DOM 構造モデル

DOM は、より特化した他インターフェイスも実装する Node オブジェクトの階層として文書を表現する。様々な型の 子 を持てるノード型もあるし、文書構造中で下位に何も持つことの出来ない葉ノードもある。 XML および HTML において、ノード型、そして子に持てるノード型は、次のとおりである:

• Document -- Element (最大一個), ProcessingInstruction, Comment, DocumentType (最大一個)
• DocumentFragment -- Element, ProcessingInstruction, Comment, Text, CDATASection, EntityReference
• DocumentType -- 子を持たない
• EntityReference -- Element, ProcessingInstruction, Comment, Text, CDATASection, EntityReference
• Element -- Element, Text, Comment, ProcessingInstruction, CDATASection, EntityReference
• Attr -- Text, EntityReference
• ProcessingInstruction -- 子を持たない
• Comment -- 子を持たない
• Text -- 子を持たない
• CDATASection -- 子を持たない
• Entity -- Element, ProcessingInstruction, Comment, Text, CDATASection, EntityReference
• Notation -- 子を持たない

DOM はまた、 Node の子, また Element インターフェイスの getElementsByTagName メソッドが返す 要素 のような、順序のある Node のリストを操作する NodeList インターフェイス、 そして Element の属性のような、名前で参照される順序のないノードの集合を操作する NamedNodeMap インターフェイスも規定する。 NodeList オブジェクトおよび NamedNodeMap オブジェクトは、 DOM において 活きて いる; つまり、元の文書構造の変更は NodeList そして NamedNodeMap オブジェクトに適切に反映する。例えば、 Element の子を保持する NodeList オブジェクトを DOM ユーザが取得する場合、後からその 要素 へ子を追加 (あるいはこの削除・変更)すると、それらの変更はユーザ側での追加アクションがなくても自動的に NodeList に反映される。同様に、ツリー内の Node への変更は、 NodeList オブジェクトおよび NamedNodeMap オブジェクト内のその Node への全ての参照内に反映される。

最後に、インターフェイス Text, Comment, CDATASection は、 CharacterData インターフェイスから全てを継承する。

1.1.2. メモリ管理

本仕様で定義されるほとんどの API は、クラスではなく インターフェイス である。つまり実装は定義された名前と規定された操作を伴うメソッドの表出だけを要し、インターフェイスに直接対応するクラスの実装は必要ないことを意味する。このことは、独自のデータ構造をもつ遺産アプリケーションや異なるクラス階層を持つ新しいアプリケーションの上にかぶせる化粧板としての DOM API 実装を許可する。これはまた、構築される元のオブジェクトと DOM インターフェイスがほとんど関係ないかもしれないことから、 DOM オブジェクトの生成に、いわゆる (Java や C++ でいう) コンストラクタを使用できないことをも意味する。オブジェクト指向設計におけるこのことの伝統的な解決は、様々なインターフェイスを実装するオブジェクトのインスタンスを生成する factory メソッドを定義することである。あるインターフェイス "X" を実装するオブジェクトは、 Document インターフェイス上の "createX()" メソッドによって生成される; これは DOM オブジェクト全てが特定の Document のコンテキストにおいて活きているからである。

DOM Level 2 API は、 DOMImplementation オブジェクトを生成する標準的な方法は定義 しない; DOM 実装は、これら DOM インターフェイスを起動する独占的な方法を提供しなければならず、そして他の全オブジェクトはそこから構築できる。

コア DOM API は、一般利用者向けスクリプティング言語と、より本格的な主に本職のプログラマが用いる言語の、両方を含む広範囲の言語と互換であるように設計される。したがって DOM API は、明示的コンストラクタを提供するが自動ガベージコレクション機構を提供して未使用メモリの自動的復元するもの (特に Java) にみられる、全くユーザにメモリ管理を表出しない言語バインディングから、オブジェクトへの明示的なメモリ配分・使用箇所の追跡・再利用のための明示的な開放をプログラマに要求するもの (とりわけ C/C++) まで、様々なメモリ管理哲学を跨ぐ操作を必要とする。これらのプラットフォームを跨ぐ矛盾のない API を保証するため、 DOM はメモリ管理の問題を一切扱わず、そのことは実装に任せる。 DOM API に定義される明示的な言語バインディング (ECMAScript および Java について) のいずれもメモリ管理メソッドを要求しないが、他の言語の DOM バインディング (特に C や C++) はそのサポートを要求してよい。それらの拡張は規定の言語に DOM API を適合させる側の義務であり、 DOM 作業班の義務ではない。

1.1.3. 命名の慣習

アトリビュート名とメソッド名は、短く、覚えやすく、本質的矛盾のなく、同様の API のユーザに馴染みやすいものがよいが、一方 DOM 実装によりサポートされる従来の API における名前と衝突するべきではない。さらに、短く馴染みやすい名前との命名の衝突の回避を難しくする、異なる名前空間から来る名前を区別する能力における重大な制約が、 OMG IDL と ECMAScript の両方にある。したがって, DOM の名前は全ての環境をまたいで一意的であるために長く説明的になる傾向がある。

作業班は、他の API に共通の区別でないかもしれないとしても、様々な用語の使用における本質的矛盾がないことを試みる。例えば、 DOM API は、 メソッドが構造モデルを変更する時にメソッド名 "remove" を使い、メソッドが構造モデル内部のものを取り除く時にはメソッド名 "delete" を使う。 delete されるものは返されない。 返す意図がある時、 remove されるのもは返される。

1.1.4. API の継承 vs. 平面的ビュー

DOM Core API は、 XML/HTML 文書に対して幾分異なる２つのインターフェイス集合を表現する: 一つは 継承 の階層を持つ "オブジェクト指向" アプローチ、そして (Java と他の C の類似言語における) キャスト要求や COM 環境におけるクエリインターフェイス呼出し無しに、全ての操作を Node インターフェイス経由で行うことを許可する、 "単純化" ビューである。これらの操作は Java と COM では実に高価で、 DOM は致命的パフォーマンス環境下で使用されるかもしれない, だからこそ Node インターフェイスを使う重要な機能性を許可する。他の多くのユーザは "全てのものは Node である" という DOM アプローチよりも 継承 階層の方が容易に理解できるだろうから、よりオブジェクト指向 API を好む人のために完全な高レベルインターフェイスもサポートする。

実際、これは API にある程度の冗長性があることを意味する。作業班は "継承" アプローチを API の基礎的ビューと考え、ユーザが用いる "拡張" 機能性である Node 上の機能性のフルセットと考えるが、 しかしそれはオブジェクト指向分析が影響する他のインターフェイス上のメソッドの必要性を無視しない。 (もちろん O-O 分析が Node インターフェイス上のアトリビュートやメソッドと同一のものを生ずるときは, 全く冗長なものを規定はしない。) したがって、 Node インターフェイス上に汎用の nodeName アトリビュートが存在するとしても、 Element インターフェイス上の tagName アトリビュートは依然として存在する; これら2つのアトリビュートは同じ値でなければならないが、 DOM API に与えられた異なる支援者両方をサポートすることは無駄ではない。

1.1.5. DOMString 型

相互運用性を保証するため, DOM は次を規定する:

• • Type Definition DOMString
• アプリケーションは、 DOMString を UTF-16 ( [Unicode] と [ISO/IEC 10646] の修正案１で定義される) を用いて符号化しなければならない。
  UTF-16 符号化は、その広範囲にわたる業界慣習を理由に選択された。 HTML ・ XML の両方について、文書文字集合 (とその結果数値文字参照記法) は UCS [ISO-10646] を基にする。したがってソース文書中の数値文字参照一つが、 DOMString の (上位サロゲートと下位サロゲート) の 2 個の 16ビット単位に該当するケースも有り得ることに注意。

  Note: DOM が文字列型の名前を DOMString と定義するとしても、 バインディングは異なる名前を使ってよい。例えば Java では, String 型も符号化方法に UTF-16 を使用するため、 DOMString は String 型にバインドされる。

Note: 2000 年 8 月には、 OMG IDL 仕様 ([OMGIDL]) は wstring 型を含んでいた。だが、その定義は、文字の幅および符号化法の判定に依存することから DOM API の相互運用性の判定基準を満たさなかった。

1.1.6. DOMTimeStamp 型

相互運用性を保証するために、 DOM は、次を定義する:

• • Type Definition DOMTimeStamp

• Note: DOMTimeStamp 型を用いるとしても、バインディングは異なる型を用いてよい。例えば Java については、 DOMTimeStamp は long 型にバインドされる。 ECMAScript においては、 integer 型の範囲がとても小さいために、 TimeStamp は Date 型にバインドされる。

1.1.7. DOM における文字列比較

DOM は、文字列マッチングを意味する多くのインターフェイスを持つ。 XML が明示的に文字ケースを区別するのと対照的に、 HTML プロセッサは一般に、 要素 のような物の名前に大文字の正規化を想定する(小文字の場合はほとんどない)。 DOM の目的のために、文字列マッチングは、 DOMString の 16ビット単位 の純粋なバイナリ 比較 によって行われる。 加えて、 DOM は、プロセッサにおける DOM 構造の構築 前 の任意の文字ケースの正規化を想定する。

Note: 文字ケース折り込みの他に、テキストに適用可能な正規化を追加する。W3C国際化作業班は、正規化の必要なものとその適用対象の厳密な定義を策定中である。W3C国際化作業班は初期の正規化を要求し、これはDOMに渡されるデータが既に正規化済みであるとみなすことを意味する。この場合DOMおよびその上で構築されるアプリケーションは、テキストの変更時に正規化された状態あることを保証した方がよい。さらに詳しいことは [Charmod] を参照。

1.1.8. XML名前空間

DOMレベル2 は、名前空間に関連する 要素 及び属性の作成・操作を行う様々なインターフェイスを DOMレベル1 Core に増強し、 XML名前空間 [Namespaces] をサポートする。

DOMに関する限り、 XML名前空間 を宣言するための特殊属性は依然として展開され、他の属性と同様に操作可能である。しかし、生成時にノードは恒久的に 名前空間URI に結び付けられる。したがって、DOMを用いても、 名前空間接頭辞 または 名前空間URI の変更で文書内部でのノード移動が生じることはない。同様に、名前空間接頭辞及び名前空間URIを持つノードの生成、またノードの名前空間接頭辞の変更は、適切なXML名前空間を宣言する特殊属性の任意の追加・削除・変更を生じない。 名前空間の検証(validation)は強制されない; DOM アプリケーションの責任は重い。特に、接頭辞と名前空間URI間のマッピングを強制しないので、一般に、結果の文書は単純にシリアライズされえない。例えば、アプリケーションは文書のシリアライズ時に各名前空間使用において宣言しなければならないかもしれない。

DOMレベル2はいかなるURI正規化も正統化(canonicalization)も行わない。DOM に与えられるURIは有効なものである(例えば空白文字等は適切にエスケープされているなど)とみなされ、字句チェックは行わない。絶対URI参照は文字列として扱われ、 書いた通りに比較 される。相対名前空間URI参照をそのように扱うかは定義しない。相互運用性を保証するためには、絶対名前空間URI参照(つまりスキーム名とコロンで始まるURI参照)のみを用いるべきである。DOMは字句チェックをしないため、DOMレベル2の手法では空文字列が実際の名前空間URIとして扱われることに注意。アプリケーションは名前空間を持たないことを望むならば、namespaceURI パラメータとして値 null を用いなければならない。

Note: DOM において、全ての名前空間宣言属性は、 定義によって 名前空間URI "http://www.w3.org/2000/xmlns/" に結び付けられる。これらの属性は 名前空間接頭辞 または 修飾名 が "xmlns" である。尤も書いている時点では、これはXML名前空間仕様 [Namespaces] の一部ではなく、将来の版で具体化される予定である。

名前空間を持たない文書では、 EntityReference ノードの 子 のリストは、該当する Entity のそれと常に同じである。結合されていない 名前空間接頭辞 を実体が含んでいる文書ではそうならない。その場合、該当する EntityReference ノードの 子孫 は、実体参照のある場所によって異なる 名前空間URI に結合されるだろう。また、DOMにおいてはノードは常に同じ名前空間URIに結合されたままであるから、そういう EntityReference ノードの移動はシリアライズできない文書に lead? できる。 Document インターフェイスの DOMレベル1 メソッド createEntityReference がそういう実体に該当する実体参照の生成に用いられる時も、返される EntityReference の 子孫 は結合されていないので、このことが成立する。 DOMレベル2 は、名前空間接頭辞を解決するいかなるメカニズムもサポートしない。これら全ての理由のため、そういう実体また実体参照の使用は、控えるか、もしくは細心の注意を払うべきである。DOMの将来のレベルでは、これらを操作する追加サポートが含まれるだろう。

Document インターフェイスの createElementNS と createAttributeNS など新しいメソッドは、名前空間を知っているアプリケーションによる使用を意図している。名前空間を使用しない単純なアプリケーションは、 createElement や createAttribute のような DOMレベル1 メソッドを使用できる。この方法で生成した要素と属性は、名前空間接頭辞、名前空間URI、ローカル名を持たない。

Note: DOMレベル1 メソッドは名前空間を知らない。だから、名前空間を扱わない時にこれらのメソッドを安全に使えるとはいえ、これらと新しいメソッドの同時使用は避けるべきである。 DOMレベル1 メソッドは単にその nodeName によって属性ノードを識別するだけである。反対に、名前空間に関連する DOMレベル2 メソッドは、属性ノードをその namespaceURI と localName で識別する。この基本的な違いのため、両メソッド集合の混用は予測できない結果をもたらすかもしれない。特に setAttributeNS を使用すると、 要素 は namespaceURI が違っていれば 同じ nodeName の属性を2個(またはそれ以上)持つことができる。 getAttribute を nodeName で呼び出せば、それらの属性のうちのどれかが返されるだろう。結果は実装に依存する。同様に、 setAttributeNode の使用は、 prefix と namespaceURI が同じで nodeName が異なる 2 個(またはそれ以上)の属性を設定するかもしれない。この場合 getAttributeNodeNS は実装依存の方法でどちらか一方の属性を返すだろう。そういうケースでは、 nodeName で名前のついたアイテムにアクセスする全メソッドは同じアイテムにアクセスし、URIとローカル名でノードにアクセスする全メソッドは同じノードにアクセスすることだけを保証する。たとえば、 setAttribute と setAttributeNS は、それぞれ getAttribute と getAttributeNS が返すノードに影響を与える。