[8] [[W3C DOM]] 時代には[DFN[DOM実装]]を表す[[オブジェクト]]がありました。
その名の通り、 [[DOM]] の[[実装]]の全体を表すことを意図したもので、
複数の [[DOM]] の[[実装]]が混在することが想定されていました。

[9] 現在は[[後方互換性]]のため形骸化した [CODE(DOMi)@en[DOMImplementation]]
[[オブジェクト]]のみ残っています。

* DOM インターフェイス

[4] [[DOM実装]]の名を持つ[[インターフェイス]]や[[オブジェクト]]には、
次のものがありました。

[FIG(middle list)[ [13] [[DOM実装]]の[[インターフェイス]]
- [CODE(DOMi)@en[[[DOMImplementation]]]]
- [CODE(DOMi)@en[[[DOMImplementationList]]]]
- [CODE(DOMi)@en[[[DOMImplementationRegistry]]]]
- [CODE(DOMi)@en[[[DOMImplementationSource]]]]
]FIG]

[5] [CODE(DOMi)@en[[[DOMImplementation]]]] は [[DOM1]] で追加されました。
元々[[DOM実装]]を表す[[文書]]によらない共通オブジェクトを意図していた節がありますが、
実際の [[Webブラウザー]]ではそのように扱われず、 [[DOM Standard]]
では [CODE(DOMi)@en[[[Document]]]] の付属オブジェクトとして定義されています。

[6] それ以外は [[DOM3]] で追加され、 [[Java]] で複数の [[DOM実装]]が混在する環境で直接
[[DOM実装]]の名前を[[ハードコード]]せずに選択 ([[発見]]) するために使うことが想定されていたようです。
しかし [[Web]] では実装されなかったため、現在の [[DOM Standard]] では[[廃止]]されています。

* DOM実装と DOM木

[10] [[W3C DOM]] はまず [[DOM実装]] ([CODE(DOMi)@en[DOMImplementation]])
があって、その[[メソッド]]を使って [[DOM木]]を作成するような構造となっていました。

[11] 現在の [[DOM]] は、 [CODE(DOMi)@en[Document]] に付属する補助的な[[オブジェクト]]として
[CODE(DOMi)@en[DOMImplementation]] が存在する形になっています。
[CODE(DOMi)@en[DOMImplementation]] [[オブジェクト]]は、 [CODE(DOMi)@en[Document]]
ごとに存在します。

[12] [CODE(DOMi)@en[DOMImplementation]] は元の [[JavaScript]] には存在せず、
[[W3C DOM]] で追加されたものですが、それが [[Webブラウザー]]に実装された時に、
[[Web]] の[[同一起源ポリシー]]や複数の[[大域オブジェクト]]の存在する構成に馴染む形として、
現在の仕様に落ち着きました。 [[W3C DOM]] は [[Java]] を優先してそれと矛盾した進化を進めていきましたが、
[[WHATWG]] の [[Web DOM Core]] (現在の [CITE[DOM Standard]]) は
[[Webブラウザー]]に実装された形のまま[[標準化]]しました。

* 歴史

** 混合

[1] [[DOM実装]]の混合について。

[2] 仕様書:
-[DOM 3] 1.3.5 Mixed DOM Implementations
<IW:DOM3:"Core/core.html#Embedded-DOM">

[3] XML 語彙を開発するとその語彙の XML 実現値を操作するために特化した
API を定義することがよく行われていまして、 [[MathML]] や [[SVG]]
のように通常は DOM を拡張することで実現しています。

SVG や MathML の実現値はしばしば XHTML など他の語彙の文書に埋込まれます。
構文的には [[XML名前空間]]を使って語彙を統合できるのですが、
DOM 2 では異なる DOM 実装を一つの応用から同時に使うには問題があることがわかりました。
DOM 3 ではこの点が改良されています。

DOM 3 を実装する DOM 実装は、特定の DOM を実装する部分部品と DOM
界面を通じてシームレスに探索・操作することができるように協調することができるべきです。

物体に関する通常の[RUBYB[型変換][typecast]]操作は与えられた文書型について遺物 code
が期待する界面に対応するべきです。実行時に結合された物体の複数の DOM
特別化から選択するためには型変換技術は適当ではないかもしれません。
すべてが束縛の物体模型で定義された通り同じ物体の一部ではないかもしれないからです。

[7] 衝突が一番はっきりしているのは [CODE(DOM)[Document]] 物体で、
同じ種類の語彙で構成される文書では、どの要素も [CODE(DOM)[Document]]
物体と所有者が同じですから、特別化サービスや特別化節の構築を
[CODE(DOM)[Document]] に気兼ねなく頼むことができます。
ところが、異なる種類の語彙が混ざっている場合は、
それぞれの要素が異なる特別化サービスや API
を期待するのですが、文書階層の所有者や[[根]]はあくまで1つしかないのです。