[8] W3C DOM 時代にはDOM実装を表すオブジェクトがありました。 その名の通り、 DOM の実装の全体を表すことを意図したもので、 複数の DOM の実装が混在することが想定されていました。
[9] 現在は後方互換性のため形骸化した DOMImplementation
オブジェクトのみ残っています。
[4] DOM実装の名を持つインターフェイスやオブジェクトには、 次のものがありました。
[5] DOMImplementation は DOM1 で追加されました。
元々DOM実装を表す文書によらない共通オブジェクトを意図していた節がありますが、
実際の Webブラウザーではそのように扱われず、 DOM Standard
では Document の付属オブジェクトとして定義されています。
[6] それ以外は DOM3 で追加され、 Java で複数の DOM実装が混在する環境で直接 DOM実装の名前をハードコードせずに選択 (発見) するために使うことが想定されていたようです。 しかし Web では実装されなかったため、現在の DOM Standard では廃止されています。
[10] W3C DOM はまず DOM実装 (DOMImplementation)
があって、そのメソッドを使って DOM木を作成するような構造となっていました。
[11] 現在の DOM は、 Document に付属する補助的なオブジェクトとして
DOMImplementation が存在する形になっています。
DOMImplementation オブジェクトは、 Document
ごとに存在します。
[12] DOMImplementation は元の JavaScript には存在せず、
W3C DOM で追加されたものですが、それが Webブラウザーに実装された時に、
Web の同一起源ポリシーや複数の大域オブジェクトの存在する構成に馴染む形として、
現在の仕様に落ち着きました。 W3C DOM は Java を優先してそれと矛盾した進化を進めていきましたが、
WHATWG の Web DOM Core (現在の DOM Standard) は
Webブラウザーに実装された形のまま標準化しました。
[2] 仕様書:
[3] XML 語彙を開発するとその語彙の XML 実現値を操作するために特化した API を定義することがよく行われていまして、 MathML や SVG のように通常は DOM を拡張することで実現しています。
SVG や MathML の実現値はしばしば XHTML など他の語彙の文書に埋込まれます。 構文的には XML名前空間を使って語彙を統合できるのですが、 DOM 2 では異なる DOM 実装を一つの応用から同時に使うには問題があることがわかりました。 DOM 3 ではこの点が改良されています。
DOM 3 を実装する DOM 実装は、特定の DOM を実装する部分部品と DOM 界面を通じてシームレスに探索・操作することができるように協調することができるべきです。
物体に関する通常の型変換操作は与えられた文書型について遺物 code が期待する界面に対応するべきです。実行時に結合された物体の複数の DOM 特別化から選択するためには型変換技術は適当ではないかもしれません。 すべてが束縛の物体模型で定義された通り同じ物体の一部ではないかもしれないからです。
[7] 衝突が一番はっきりしているのは Document 物体で、
同じ種類の語彙で構成される文書では、どの要素も Document
物体と所有者が同じですから、特別化サービスや特別化節の構築を
Document に気兼ねなく頼むことができます。
ところが、異なる種類の語彙が混ざっている場合は、
それぞれの要素が異なる特別化サービスや API
を期待するのですが、文書階層の所有者や根はあくまで1つしかないのです。