 |
 |
 |
|
|
|
文書オブジェクトにアクセスしそれらを操作するためのオブジェクト及びインタフェースの最小集合を，1.1.に規定する。
1.1.で規定する機能(コア機能)は，
ソフトウェア開発者及びWebスクリプト著者が，
適合製品中で解析済みHTML内容及びXML内容にアクセスしてそれらを操作することを可能にするのに充分なものとする。
DOMコアAPIは，DOM API呼び出しだけを使用した
Documentオブジェクトの生息を許す。
つまり，スケルトンDocumentを生成し，それを永続的に保存することは，DOM APIを実装する製品に委ねられている。
DOMは，Nodeオブジェクトの階層として文書を表現する。
そのオブジェクトは，ほかの特殊化したインタフェースをも実装する。
さまざまな型の子ノードをもつノードの型もあれば，
文書構造で下位のノードをもてない葉ノードの型もある。
ノード型及びそれが子としてどんなノード型をもつかを，次に示す。
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インタフェースも規定する。
また，DOMは，
Elementの属性などの，名前属性によって参照されるノードの順序なし集合を扱うための
NamedNodeMapインタフェースも規定する。
なお，DOMの
NodeList及び
NamedNodeMapは，"live"とする。
つまり，元文書の構造への変更は，
すべての関連する
NodeList及び
NamedNodeMapに反映される。
例えば，DOMユーザが
Elementの子を含む
NodeListを得た後，
その要素に子どもを更に追加(又は子を削除，子を修正)した場合，
それらの変更は，ユーザ側でそれ以上の操作をしなくとも，
自動的にNodeListに反映される。
同様に，
木中のNodeへの変更は，
NodeList及び
NamedNodeMapの中の
そのNodeへのすべての参照に反映される。
この規定が定義するAPIのほとんどは，クラスではなくインタフェースとする。
これは，実際の実装は，
定義された名前及び指定された動作をもつメソッドを開示するだけでよく，
インタフェースに直接対応するクラスを実装する必要はないことを意味する。
これによって，それ自体のデータ構造をもつ既存アプリケーションの上に，
又は異なるクラス階層をもつ新アプリケーションの上に，
薄い張り板としてDOM APIを実装することが可能になる。
これは，コンストラクタで生成される基本オブジェクトは，
DOMインタフェースとほとんど関連がなくてよいので，
Java又はC++の意味での通常のコンストラクタでは，
DOMオブジェクトを生成できないことを意味する。
オブジェクト指向設計におけるこの問題に対する従来の解は，
多様なインタフェースを実装するオブジェクトのインスタンスを生成するfactoryメソッドを定義することである。
DOM水準1においては，インタフェース"X"を実装するオブジェクトは，
Documentインタフェースの"createX()"メソッドによって生成される。
この理由は，すべてのDOMオブジェクトが特定文書の文脈中にあるからである。
DOM水準1のAPIは，
DOMImplementation又は
Documentのオブジェクトを生成するための標準的な方法を規定しない。
実際のDOM実装は，
これらのDOMインタフェースをブートストラップするベンダ独自の方法を提供しなければならない。
他のすべてのオブジェクトの生成は，
Documentの
createメソッドから，又は他のさまざまな簡便性メソッドによって
可能である。
コアDOM APIは，
一般ユーザのスクリプト言語，及び主としてプロのプログラマが利用するもっと挑戦的な言語の両方を含めた，
広範囲な言語との互換性をもつ設計がなされている。
従って，DOM APIは，多様なメモリ管理方式において動作する必要がある。
メモリ管理をユーザに全く見せない言語プラットフォーム，
明示的なコンストラクタを提供するが，
未使用メモリを自動回収するためのガベジコレクション機構を提供する言語プラットフォーム(特にJava)，
オブジェクトメモリを明示的に割り当て，
それが使用されているところに追跡し，
再使用のためにそれを明示的に解放することをプログラマに通常要求する言語プラットフォーム(特にC/C++)などで動作する必要がある。
これらのプラットフォームにわたって一貫性のあるAPIを保証するために，
DOMはメモリ管理の問題に言及することは決してないが，
代わりに，この問題を実装にまかせる。
DOM作業グループによって考案された(ECMAScript及びJavaに関する)明示的な言語結合はいずれも，
メモリ管理メソッドを必要としないが，
他の言語(特にC又はC++)に関するDOM結合は，そのサポートを必要とするであろう。
これらの拡張は，DOM APIを特定言語に適合させるものの責務であって，
DOM WGの責務ではない。
短く参考であって，内部的に一貫性があり，類似APIのユーザによく知られた属性名及びメソッド名をもつことはよいが，
それらの名前は，DOM実装によってサポートされる既存APIの名前と衝突するものであってもならない。
しかも，OMG IDL及びECMAScriptのどちらも，
異なる名前空間からの名前のあいまいさをなくす機能にかなりの制限があり，
それがよく知られた短い名前と名前が衝突することを回避するのを困難にしている。
それで，DOM名は，すべての環境にわたって一意であるため，長くて非常に記述的なものになる傾向がある。
作業グループは，他のAPIでは用語を共通に区別することがないとしても，
内部的に一貫性をもって様々な用語を使用することを試みてきた。
例えば，メソッドが構造モデルを変更するときにメソッド名"remove"を使用し，
メソッドが構造モデルの内部の何かを除くときにメソッド名"delete"を使用する。
deleteされたものは，返却しない。
removeされたものは，それを返却する意味があれば，返却してもよい。
DOMコアAPIは，XML及びHTML文書に対するインタフェースの幾分異なる二つの集合を与える。
一つは，継承の階層をもつ"オブジェクト指向"のアプローチを与え，もう一つは，"簡素化された"ビューを与える。
"簡素化された"ビューでは，すべての操作は，
Java及び他のCに類似の言語におけるキャスト，又はCOM環境における問合せインタフェースの呼出しを要求することなく，
Nodeインタフェースによって行うことができる。
これらの操作は，Java及びCOMにおいてかなり高価であり，DOMは，性能限界の環境において使用されることもある。
そこで，
Nodeインタフェースだけを用いる重要な機能を可能にする。
他の多くのユーザは，
"すべてがNodeである"DOMへのアプローチより
継承の階層が理解し易いと思うであろうから，よりオブジェクト指向なAPIを好む者のために，完全な高レベルインタフェースもサポートする。
実際これは，APIにある程度の冗長性があることを意味する。
作業グループは，"継承"アプローチをAPIの主ビューと考え，
Nodeのすべての機能を
ユーザが利用してよい"特別"機能と考える。
しかしその機能は，オブジェクト指向分析が要求する他のインタフェースのメソッドの必要性を削除しない。
もちろん，オブジェクト指向分析が
Nodeインタフェースのものと同じ属性又はメソッドをもたらすときは，
完全に冗長なものを指定しない。
Nodeインタフェースに包括的なnodeName属性が存在しても，
ElementインタフェースにtagName属性が存在する。
これらの二つの属性は，同じ値をもたなければならないが，
作業グループは，DOM APIが満たなければならない異なる要望があるので，
両方をサポートする価値があると考える。
DOMString型
相互運用性を確保するために，DOMは次に示すDOMString型を指定する。
DOMStringは，16ビット量の列とする。
これのIDL表現の例を，次に示す。
typedef sequence<unsigned short> DOMString;
DOMStringを符号化しなければならない。
UTF-16は，業界で広く利用されているために採用された。
HTML及びXMLのいずれについても，文書文字集合(したがって，数値による文字参照の記法)はUCS-4に基づくことに注意。
したがって，ソース文書における単一の数値による文字参照が，
DOMStringの二つの配列位置(一つの高位サロゲート及び一つの低位サロゲート)に対応する場合もある。
DOMStringと定義しているが，結合では別の名前を使用してよい。
Javaの例では，DOMStringは，それもその符号化にUTF-16を使うのでString型に結合している。
wstring型を含んでいた。
しかし，
その定義は，それが文字の幅を決定する符号化折衝に依存したため，
DOM APIの相互運用性の基準に適合しなかった。
DOMには，文字列の一致化を伴うインタフェースが多くある。
HTML処理系は，一般に，要素などの名前を大文字(まれに小文字)に正規化することを前提とする。
それに対して，XMLは，大文字・小文字を明示的に区別する。
DOMの目的では，DOMStringの16ビット値を単位として，文字符号毎に文字列の一致化を行う。
同様にDOMは，どんな正規化も，DOM構造が構築される前に，処理系が行うことを前提とする。
これは，まさにどんな正規化が行れるのかという問題を提起する。 W3CのI18N作業グループは，DOMを実装するアプリケーションにとってどんな正規化が必要かを厳密に定義しているところである。
1.2.に示すインタフェースは基礎的とし， HTML DOM実装を含むすべてのDOM適合実装によって，完全に実装されなければならない。
DOM操作は，"例外的な"状況においてだけ，
すなわち，(データが失われた，又は実装が不安定になった，という論理的な理由で，)
操作が実行不可能な場合だけ，例外を挙げる。
一般に，DOMメソッドは，通常の処理状態では，
NodeList
使用時の範囲外エラーなど，特定のエラー値を返す。
他の状況において，別の例外を挙げる実装があってもよい。
例えば，null引数が渡された場合，
実装依存の例外を挙げる実装があってもよい。
例外の概念をもたない言語及びオブジェクトシステムもある。 これらのシステムでは， 実装固有のエラー通知機構を使用してエラー状態を示してもよい。 例えば，対応するメソッド記述に上げられたものと同様のエラーコードを メソッドが返す言語結合があってもよい。
exception DOMException {
unsigned short code;
};
// ExceptionCode
const unsigned short INDEX_SIZE_ERR = 1;
const unsigned short DOMSTRING_SIZE_ERR = 2;
const unsigned short HIERARCHY_REQUEST_ERR = 3;
const unsigned short WRONG_DOCUMENT_ERR = 4;
const unsigned short INVALID_CHARACTER_ERR = 5;
const unsigned short NO_DATA_ALLOWED_ERR = 6;
const unsigned short NO_MODIFICATION_ALLOWED_ERR = 7;
const unsigned short NOT_FOUND_ERR = 8;
const unsigned short NOT_SUPPORTED_ERR = 9;
const unsigned short INUSE_ATTRIBUTE_ERR = 10;
生成されたエラーの型を示す整数。
| INDEX_SIZE_ERR |
インデクス若しくはサイズが負の場合，又はそれらが許された値より大きい場合。 |
| DOMSTRING_SIZE_ERR |
テキストの指定範囲がDOMStringに合わない場合。 |
| HIERARCHY_REQUEST_ERR |
ノードが属さない場所にそのノードが挿入された場合。 |
| WRONG_DOCUMENT_ERR |
ノードを生成した文書とは異なる(そのノードをサポートしない) 文書でそのノードが使用された場合。 |
| INVALID_CHARACTER_ERR |
名前などで妥当でない文字が指定された場合。 |
| NO_DATA_ALLOWED_ERR |
データをサポートしないノードに対してデータが指定された場合。 |
| NO_MODIFICATION_ALLOWED_ERR |
修正が許されていない所でオブジェクトを修正しようとした場合。 |
| NOT_FOUND_ERR |
ノードが存在しない文脈でそのノードを参照した場合。 |
| NOT_SUPPORTED_ERR |
要求されたオブジェクトの型を実装がサポートしない場合。 |
| INUSE_ATTRIBUTE_ERR |
すでにどこかで使用されている属性を追加しようとした場合。 |
DOMImplementationインタフェースは，
文書オブジェクトモデルの特定インスタンスとは独立した操作を実行するための多くのメソッドを提供する。
DOM水準1では，文書インスタンスを生成する方法を規定しないので， 文書生成は実装に固有な操作とする。 DOM規定の将来の水準では，文書を直接生成するためのメソッドを提供することが期待される。
interface DOMImplementation {
boolean hasFeature(in DOMString feature,
in DOMString version);
};
hasFeaturefeature |
テストする機能のパッケージ名。 水準1では，正しい値は"HTML"及び"XML"(ただし，大文字・小文字を区別しない。)とする。 | |
version |
テストするパッケージ名の版数。
水準1では，文字列"1.0"とする。
版の指定がない場合，機能の任意の版をサポートしていれば，
メソッドは |
trueとし，
それ以外の場合はfalseとする。
DocumentFragmentは，"軽量"又は"最小"の
Documentオブジェクトとする。
文書の木の一部を取り出すとか，
文書の新しい素片を生成するのを可能としたいということは，よくある。
切り取りのようなユーザコマンドを実装すること，
又は素片を移動して文書を再構成すること考えてみる。
これらの素片を保持できるオブジェクトをもつことは望ましく，
この目的のためにNodeを使用することは極めて自然となる。
Document
オブジェクトがこの役割を果たせることは確かだが，
土台となる実装に依存して，
Document
オブジェクトが，重量オブジェクトとなる可能性がある。
この目的で本当に必要なものは，非常に軽量なオブジェクトである。
DocumentFragmentは，そのようなオブジェクトとする。
更に，様々な操作，例えば，
他のNodeの
子どもとしてノードを挿入する操作などは，
DocumentFragmentオブジェクトを引数に取るかもしれない。
この結果として，DocumentFragmentのすべての子ノードが
そのノードの子リストへ移動する。
DocumentFragmentノードの子どもは，
文書構造を定義する部分木の最上位を表現する0個以上のノードとする。
DocumentFragmentノードは，整形式XML文書である必要はない。
(ただし，そのノードは，複数の最上位ノードをもつことができる
整形式のXML解析対象実体に課せられる規則に従う必要はある。)
例えば，DocumentFragmentが唯一の子をもち，
その子ノードがTextノードであってもよい。
この構造モデルは，HTML文書も整形式XML文書も表現しない。
DocumentFragmentが
Document
(又は，子どもをもつかもしれない真に他の
Node)
へ挿入される場合，
DocumentFragment自体でなく，
DocumentFragmentの子どもが
Node
へ挿入される。
このことによって，兄弟となるノードをユーザが生成したい場合，
DocumentFragmentは非常に有用となる。
つまり，DocumentFragmentはこれらのノードの親として活動するので，
ユーザは，insertBefore()，appendChild()などの
Node
インタフェースからの標準メソッドを使用できる。
interface DocumentFragment : Node {
};
Documentインタフェースは，
HTML文書又はXML文書の全体を表現する。
これは，概念的には文書木のルートであって，
文書データを最初にアクセスする手段を提供する。
要素，テキストノード，コメント，処理命令などは，
Document文脈以外では存在できないので，
Documentインタフェースは，
これらのオブジェクトを生成するために必要なファクトリメソッドも含む。
生成されたNode
オブジェクトは，ownerDocument属性をもつ。
この属性は，Nodeオブジェクトが生成された文脈内の
DocumentとNodeオブジェクトとを関連付ける。
interface Document : Node {
readonly attribute DocumentType doctype;
readonly attribute DOMImplementation implementation;
readonly attribute Element documentElement;
Element createElement(in DOMString tagName)
raises(DOMException);
DocumentFragment createDocumentFragment();
Text createTextNode(in DOMString data);
Comment createComment(in DOMString data);
CDATASection createCDATASection(in DOMString data)
raises(DOMException);
ProcessingInstruction createProcessingInstruction(in DOMString target,
in DOMString data)
raises(DOMException);
Attr createAttribute(in DOMString name)
raises(DOMException);
EntityReference createEntityReference(in DOMString name)
raises(DOMException);
NodeList getElementsByTagName(in DOMString tagname);
};
doctypeDocumentType参照)。
文書型宣言をもたないXML文書及びHTML文書に対しては，
このメソッドは，nullを返す。
DOM水準1では，文書型宣言の編集をサポートしない。
そこで，docTypeは，いかなる方法でも変更できない。
implementationDOMImplementation
オブジェクト。
DOMアプリケーションは，複数の実装からのオブジェクトを使用してもよい。
documentElement
createElementtagName |
実体化する要素型の名前。
XMLでは，大文字・小文字を区別する。
HTMLでは， |
Element
オブジェクト。
DOMExceptionINVALID_CHARACTER_ERR: 指定した名前が妥当でない文字を含む場合に挙げる。
createCDATASectionCDATASection
ノードを生成する。
data |
|
CDATASection
オブジェクト。
DOMExceptionNOT_SUPPORTED_ERR: 文書がHTML文書の場合に挙げる。
createProcessingInstructionProcessingInstruction
ノードを生成する。
target |
処理命令のターゲット部。 | |
data |
ノードのデータ。 |
ProcessingInstruction
オブジェクト。
DOMExceptionINVALID_CHARACTER_ERR: 妥当でない文字を指定した場合に挙げる。
NOT_SUPPORTED_ERR: 文書がHTML文書の場合に挙げる。
createAttributeAttrを生成する。
この後，setAttributeメソッドを使用して，
Attrインスタンスを
Elementに
設定できることに注意。
name |
属性の名前。 |
Attr
オブジェクト。
DOMExceptionINVALID_CHARACTER_ERR: 指定した名前が妥当でない文字を含む場合に挙げる。
createEntityReferencename |
参照する実体の名前。 |
EntityReference
オブジェクト。
DOMExceptionINVALID_CHARACTER_ERR: 指定した名前が妥当でない文字を含む場合に挙げる。
NOT_SUPPORTED_ERR: 文書がHTML文書の場合に挙げる。
Nodeインタフェースは，
文書オブジェクトモデル全体に対する主データ型とする。
それは，文書木の一つのノードを表現する。
Nodeインタフェースを実装するすべてのオブジェクトは，
子どもを扱うためのメソッドを開示するが，
Nodeインタフェースを実装するすべてのオブジェクトが，
子どもをもつとは限らない。
例えば，
Text
ノードは子どもをもたなくともよく，
こうしたノードへ子どもを追加した場合，その結果として
DOMException
が挙げられる。
nodeName属性，nodeValue属性及びattributes属性は，
特定の派生インタフェースへキャストダウンを行うことなく，
ノードに情報を取得する機構として含まれている。
特定のnodeTypeに対してこれらの属性の明らかな対応付け
(例えば，Elementに対するnodeValue，又はCommentに対するattributes)
がない場合には，nullを返す。
特殊化されたインタフェースは，関連情報を取得及び設定するために，
付加的でより簡便な機構を含んでもよいことに注意。
interface Node {
// NodeType
const unsigned short ELEMENT_NODE = 1;
const unsigned short ATTRIBUTE_NODE = 2;
const unsigned short TEXT_NODE = 3;
const unsigned short CDATA_SECTION_NODE = 4;
const unsigned short ENTITY_REFERENCE_NODE = 5;
const unsigned short ENTITY_NODE = 6;
const unsigned short PROCESSING_INSTRUCTION_NODE = 7;
const unsigned short COMMENT_NODE = 8;
const unsigned short DOCUMENT_NODE = 9;
const unsigned short DOCUMENT_TYPE_NODE = 10;
const unsigned short DOCUMENT_FRAGMENT_NODE = 11;
const unsigned short NOTATION_NODE = 12;
readonly attribute DOMString nodeName;
attribute DOMString nodeValue;
// raises(DOMException) on setting
// raises(DOMException) on retrieval
readonly attribute unsigned short nodeType;
readonly attribute Node parentNode;
readonly attribute NodeList childNodes;
readonly attribute Node firstChild;
readonly attribute Node lastChild;
readonly attribute Node previousSibling;
readonly attribute Node nextSibling;
readonly attribute NamedNodeMap attributes;
readonly attribute Document ownerDocument;
Node insertBefore(in Node newChild,
in Node refChild)
raises(DOMException);
Node replaceChild(in Node newChild,
in Node oldChild)
raises(DOMException);
Node removeChild(in Node oldChild)
raises(DOMException);
Node appendChild(in Node newChild)
raises(DOMException);
boolean hasChildNodes();
Node cloneNode(in boolean deep);
};
ノードの型を示す整数。
| ELEMENT_NODE |
ノードは， |
| ATTRIBUTE_NODE |
ノードは， |
| TEXT_NODE |
ノードは， |
| CDATA_SECTION_NODE |
ノードは， |
| ENTITY_REFERENCE_NODE |
ノードは， |
| ENTITY_NODE |
ノードは， |
| PROCESSING_INSTRUCTION_NODE |
ノードは， |
| COMMENT_NODE |
ノードは， |
| DOCUMENT_NODE |
ノードは， |
| DOCUMENT_TYPE_NODE |
ノードは， |
| DOCUMENT_FRAGMENT_NODE |
ノードは， |
| NOTATION_NODE |
ノードは， |
nodeName，nodeValue及び
attributesの値は，
ノードの型に従って次のとおりに変化する。
| nodeName | nodeValue | attributes | |
| Element | tagName | null | NamedNodeMap |
| Attr | 属性の名前 | 属性の値 | null |
| Text | #text | テキストノードの内容 | null |
| CDATASection | #cdata-section | CDATAセクションの内容 | null |
| EntityReference | 参照される実体の名前 | null | null |
| Entity | 実体名 | null | null |
| ProcessingInstruction | target | targetを除く内容全体 | null |
| Comment | #comment | コメントの内容 | null |
| Document | #document | null | null |
| DocumentType | 文書型名 | null | null |
| DocumentFragment | #document-fragment | null | null |
| Notation | 記法名 | null | null |
nodeName
nodeValueDOMExceptionNO_MODIFICATION_ALLOWED_ERR: このノードが読出し専用の場合に挙げる。
DOMException
DOMSTRING_SIZE_ERR:
実装プラットフォームのDOMString変数に収まるよりも多い文字数が返された場合に挙げる。
nodeType
parentNodeDocument，
DocumentFragment
及びAttrを除き，
すべてノードは親をもつ。
ただし，ノードが生成された直後であって，まだ木に追加されていない場合，
又はノードが木から削除された場合は，
この値はnullとする。
childNodesNodeList。
子どもが存在しない場合は，ノードを一つも含まない
NodeList
とする。
返却値の
NodeList
の内容は"live"とする。
その意味は，
例えば，NodeListが生成される基となったノードオブジェクトの子どもへの変更は，
NodeListの
アクセス機構によって返されるノードに直ちに反映されるということとする。
つまり，それは，ノード内容の静的なスナップショットではない。
このことは，getElementsByTagNameメソッドによって返されたものを含む
すべてのNodeListに
対して成立する。
firstChildnullを返す。
lastChildnullを返す。
previousSiblingnullを返す。
nextSiblingnullを返す。
attributesElementの場合は，
ノードの属性を含むNamedNodeMap。
それ以外の場合は，null。
ownerDocumentDocumentオブジェクト。
これは，新しいノードを生成するために使用される
Document
オブジェクトでもある。
このノードがDocumentの場合，
この値はnullとする。
insertBeforerefChildの前に，
ノードnewChildを挿入する。
refChildがnullの場合は，
子どものリストの最後にnewChildを挿入する。
newChildが
DocumentFragment
オブジェクトの場合は，
すべての子どもをrefChildの前に，同じ順序で挿入する。
newChildが既に木に存在する場合は，
最初にそれを削除する。
newChild |
挿入するノード。 | |
refChild |
参照ノード。すなわち，このノードの前に新しいノードを挿入する。 |
DOMException
HIERARCHY_REQUEST_ERR:
このノードが，
newChildノードの型の子どもを許さない型の場合に，
又は挿入するノードがこのノードの先祖の場合に挙げる。
WRONG_DOCUMENT_ERR:
このノードを生成した以外の文書から，
newChildが生成された場合に挙げる。
NO_MODIFICATION_ALLOWED_ERR: このノードが読出し専用の場合に挙げる。
NOT_FOUND_ERR:
refChildがこのノードの子ではない場合に挙げる。
replaceChildoldChildを
newChildに置換し，
oldChildノードを返す。
newChildが既に木に存在すれば，
最初にそのノードを削除する。
newChild |
子リストの中に置く新しいノード。 | |
oldChild |
リスト中で置換されるノード。 |
DOMException
HIERARCHY_REQUEST_ERR:
このノードが，
newChildノードの型の子どもを許さない型の場合，
又は置かれるノードがこのノードの先祖の場合に挙げる。
WRONG_DOCUMENT_ERR:
このノードを作成した以外の文書から，
newChildが生成された場合に挙げる。
NO_MODIFICATION_ALLOWED_ERR: このノードが読出し専用の場合に挙げる。
NOT_FOUND_ERR:
oldChildがこのノードの子ではない場合に挙げる。
removeChildoldChildで示される子ノードを，
子どものリストから削除し，それを返す。
oldChild |
削除されるノード。 |
DOMExceptionNO_MODIFICATION_ALLOWED_ERR: このノードが読出し専用の場合に挙げる。
NOT_FOUND_ERR:
oldChildがこのノードの子ではない場合に挙げる。
appendChildnewChildを追加する。
newChildが木に既に存在する場合は，
それを最初に削除する。
newChild |
追加するノード。
これが |
DOMException
HIERARCHY_REQUEST_ERR:
このノードが，
newChildノードの型の子どもを許さない型の場合，
又は追加されるノードがこのノードの祖先の場合に挙げる。
WRONG_DOCUMENT_ERR:
このノードを作成した以外の文書から，
newChildが生成された場合に挙げる。
NO_MODIFICATION_ALLOWED_ERR: このノードが読出し専用の場合に挙げる。
hasChildNodestrueとする。
ノードが子どもをもたない場合は，falseとする。
cloneNodeparentNodeは，nullを返す。)
Element
をクローン化するとは，
すべての属性及びその値を，
デフォルト属性を表現するためにXMLプロセッサによって生成されたものも含めて，
コピーすることとする。
ただし，このメソッドが深いクローン化でない限り，
Elementが含むテキストをコピーしない。
それは，テキストは，子のText
ノードに含まれることによる。
ノードの型がElement以外の場合，ノードのクローン化は，
ノードのコピーを単に返すこととする。
deep |
|
NodeListインタフェースは，
ノードの順序付きの集まりの抽象化を提供する。
ただし，この集まりを実装する方法を定義したり，制約したりしない。
NodeList中の項目は，0から始まる整数のインデクスを使ってアクセスできる。
interface NodeList {
Node item(in unsigned long index);
readonly attribute unsigned long length;
};
itemindex番目の項目を返す。
indexが，リスト中のノードの数以上の場合は，
nullを返す。
index |
集まりの中へのインデクス。 |
NodeList中のindex番目の位置にあるノード。
インデクスが妥当でない場合は，nullを返す。
lengthlength-1まで，
ただしlength-1を含む，とする。
NamedNodeMapインタフェースを実装するオブジェクトは，
名前によってアクセス可能なノードの集まりを表現するために使用する。
NamedNodeMapは，
NodeList
から継承されないことに注意。
すなわち，
NamedNodeMapは，いかなる特定の順序でも維持されない。
NamedNodeMapを実装するオブジェクトに含まれるオブジェクトは，
順序を示すインデクスによってアクセスしてもよいが，
これは，NamedNodeMapの内容を簡単に列挙することを可能にするだけであって，
DOMがこれらのNodeに順序を指定することを示唆しない。
interface NamedNodeMap {
Node getNamedItem(in DOMString name);
Node setNamedItem(in Node arg)
raises(DOMException);
Node removeNamedItem(in DOMString name)
raises(DOMException);
Node item(in unsigned long index);
readonly attribute unsigned long length;
};
getNamedItemname |
取得するノードの名前。 |
Node。
指定した名前がマップの中のノードを特定しない場合は，null。
setNamedItemnodeName属性を使用して，ノードを追加する。
ノードを格納しなければならない場所を示す名前を導出するために
nodeName属性を使用するので，
ある型("特別な"文字列値をもつ型)の複数のノードは，
名前が衝突するために，格納できない。
これは，ノードに別名を付けることを許すよりは望ましいように思える。
arg |
名前付きノードマップに格納するノード。
後に，ノードの |
DOMException
WRONG_DOCUMENT_ERR:
このNamedNodeMapを作成した以外の文書から，
argが生成された場合に挙げる。
NO_MODIFICATION_ALLOWED_ERR:
NamedNodeMapが読出し専用の場合に挙げる。
INUSE_ATTRIBUTE_ERR:
argが，
既に他のElement
オブジェクトの属性である
Attrになっている場合に
挙げる。
DOMユーザは，他の要素でAttr
ノードを再利用するためには，
それを明示的にクローン化しなければならない。
removeNamedItemAttrの場合，
直ちにデフォルト値に置換される。
name |
削除するノードの名前。 |
null。
DOMException
NOT_FOUND_ERR:
nameという名前のノードがマップにない場合に挙げる。
itemindex番目の項目を返す。
indexが
マップの中のノードの数以上の場合は，
nullを返す。
index |
マップへのインデクス。 |
NamedNodeMapのindex番目の位置にあるノード。
インデクスが妥当でない場合は，null。
lengthlength-1まで，
ただし，length-1を含む，とする。
CharacterDataインタフェースは，
DOMにおける文字データをアクセスするための属性及びメソッドの集合を用いて，Nodeを拡張する。
明確さのために，
この集合は，これら属性及びメソッドを使用する各オブジェクト上ではなく，
このインターフェースで定義する。
Textなどは
CharacterDataからインタフェースを継承するが，
CharacterDataに直接対応するDOMオブジェクトは存在しない。
このインタフェースのすべてのoffsetは，0から始まる。
interface CharacterData : Node {
attribute DOMString data;
// raises(DOMException) on setting
// raises(DOMException) on retrieval
readonly attribute unsigned long length;
DOMString substringData(in unsigned long offset,
in unsigned long count)
raises(DOMException);
void appendData(in DOMString arg)
raises(DOMException);
void insertData(in unsigned long offset,
in DOMString arg)
raises(DOMException);
void deleteData(in unsigned long offset,
in unsigned long count)
raises(DOMException);
void replaceData(in unsigned long offset,
in unsigned long count,
in DOMString arg)
raises(DOMException);
};
dataCharacterDataノードに格納されるデータの量に任意の制限を設けてはならない。
ただし，実装の制限によって，
ノードのデータ全体が一つのDOMStringに収まらなくともよい。
このような場合，ユーザは，適切な大きさの固まりでデータを取得するために，
substringDataを呼び出してもよい。
DOMExceptionNO_MODIFICATION_ALLOWED_ERR: このノードが読出し専用の場合に挙げる。
DOMException
DOMSTRING_SIZE_ERR:
実装プラットフォームのDOMString変数に収まるよりも多くの文字が返された場合に挙げる。
lengthdata及びsubstringDataメソッドによって利用可能な文字の数。
これは，値ゼロであってもよい。つまり，CharacterDataノードは空でもよい。
substringDataoffset |
抽出する部分文字列の開始オフセット。 | |
count |
抽出する文字の数。 |
offsetとcountとの合計が，
lengthを超えた場合，
データの最後までのすべての文字を返す。DOMException
INDEX_SIZE_ERR:
指定したoffsetが負数又はdataの中の文字の数よりも大きい場合に挙げる。
また，指定したcountが負数の場合にも挙げる。
DOMSTRING_SIZE_ERR: テキストの指定範囲がDOMStringに収まらない場合に挙げる。
appendDatadataによって，
指定したDOMStringとdataとを連結したものを
アクセスできる。
arg |
追加する |
DOMExceptionNO_MODIFICATION_ALLOWED_ERR: このノードが読出し専用の場合に挙げる。
insertDataoffset |
挿入する場所を示す文字オフセット。 | |
arg |
挿入する |
DOMException
INDEX_SIZE_ERR:
指定したオフセットが負数又はdataの中の文字の数よりも大きい場合に挙げる。
NO_MODIFICATION_ALLOWED_ERR: このノードが読出し専用の場合に挙げる。
deleteDatadata及びlengthに反映される。
offset |
文字を削除する場所を示すオフセット。 | |
count |
削除する文字の数。
|
DOMException
INDEX_SIZE_ERR:
指定したoffsetが負数又はdataの中の文字の数よりも大きい場合に挙げる。
また，指定したcountが負数の場合にも挙げる。
NO_MODIFICATION_ALLOWED_ERR: このノードが読出し専用の場合に挙げる。
replaceDataoffset |
置換を始める場所を示すオフセット。 | |
count |
置換する文字の数。
| |
arg |
その範囲が置換されなければならない |
DOMException
INDEX_SIZE_ERR:
指定したoffsetが負数又はdataの中の文字の数よりも大きい場合に挙げる。
また，指定したcountが負数の場合にも挙げる。
NO_MODIFICATION_ALLOWED_ERR: このノードが読出し専用の場合に挙げる。
Attrインタフェースは，一つの
Element
オブジェクトの一つの属性を表現する。
一般に，属性に対して許される値は，文書型定義で定義される。
Attrオブジェクトは
Node
インタフェースを継承する。しかし，Attrオブジェクトは，
実際にはそれが記述する要素の子ノードではないので，DOMは，Attr
を文書木の一部とみなさない。
そこで，
Nodeの
parentNode属性，previousSibling属性
及びnextSibling属性は，
Attrオブジェクトに対してnull値をもつ。
属性は，それが関連付けられた要素から独立した同一性をもつというよりも，
要素の特性であるという見方をDOMは取る。
このことによって，与えられた型のすべての要素に関連付けられたデフォルト属性などの機能を，
より効率的に実装できる。
更に，Attrノードは，
DocumentFragment
の直接の子どもであってはならない。
ただし，それは，
DocumentFragment
に含まれる
Element
ノードに関連付けることができる。
端的に言えば，Attrノードは，
Node
インタフェースを継承している他のオブジェクトと共通点はあるが，
全く違ってもいることを，
DOMのユーザ及び実装者は認識する必要がある。
属性の実効的な値は，次のとおりに決定する。
この属性がある値に明示的に割り当てられている場合，
その値を属性の実効的な値とする。
それ以外の場合で，この属性の宣言が存在し，
その宣言がデフォルト値を含む場合は，
そのデフォルト値を属性の実質的な値とする。
それ以外の場合は，属性は，
明示的に追加されない限り，構造モデルにおけるこの要素上には存在しない。
AttrインスタンスのnodeValue属性は，
属性値の文字列版を取得するために使用することも可能なことに注意。
XMLでは，属性の値が実体参照を含むことができるが，
Attrノードの子ノードは，実体参照を展開しない表現を提供する。
この子ノードは，
Text
又は
EntityReference
ノードのいずれかとする。
属性の型は未知であってもよいので，トークン化された属性値は存在しない。
interface Attr : Node {
readonly attribute DOMString name;
readonly attribute boolean specified;
attribute DOMString value;
};
name
specifiedtrueとする。
それ以外の場合は，falseとする。
ユーザではなく，実装がこの属性の責任をもつことに注意。
ユーザが属性の値を変更した場合，
(たとえ，変更の結果，デフォルト値と同じ値となっても，)
specifiedフラグは，自動的にtrueに変わる。
DTDのデフォルト値に属性を再指定するには，
ユーザは，属性を削除する必要がある。
デフォルト値が存在する場合，
実装は，デフォルト値をもつ新しい属性を利用可能にし，
そのspecifiedをfalseに設定する。
要約すると，次のとおり。
specifiedはtrueとし，
値は，その割当て値とする。
specifiedはfalseとし，
値は，DTDのデフォルト値とする。
文書をたどる場合に，
著者が出会うほとんど大多数の(text以外の)オブジェクトは，
Elementノードとなる。
次のXML文書を仮定する。
<elementExample id="demo"> <subelement1/> <subelement2><subsubelement/></subelement2> </elementExample>
DOMを使用して表現する場合，
最上位ノードは，"elementExample"に対応するElementノードとなる。
それは，二つの子Elementノードを含む。
一つは"subelement1"に対応するもので，もう一つは"subelement2"に対応するものとなる。
"subelement1"は，子ノードを含まない。
要素は，それに関連付けられた属性をもってもよい。
Elementインタフェースは，
Nodeから
継承するので，
要素のすべての属性の集合を取得するために，
包括的なNode
インタフェースメソッドgetAttributesを使用してもよい。
Elementインタフェースには，
名前によってAttr
オブジェクトを取得するか，
又は名前によって属性値を取得するかのいずれかのメソッドが存在する。
XMLでは，属性値は実体参照を含んでもよく，
属性値を表現するかなり複雑となることが可能な部分木の属性値を調べるために，
Attrオブジェクトを
取得することが望ましい。
一方，HTMLでは，すべての属性は単純な文字列値をもち，
属性値を直接アクセスするメソッドを，簡便なものとして安全に利用できる。
interface Element : Node {
readonly attribute DOMString tagName;
DOMString getAttribute(in DOMString name);
void setAttribute(in DOMString name,
in DOMString value)
raises(DOMException);
void removeAttribute(in DOMString name)
raises(DOMException);
Attr getAttributeNode(in DOMString name);
Attr setAttributeNode(in Attr newAttr)
raises(DOMException);
Attr removeAttributeNode(in Attr oldAttr)
raises(DOMException);
NodeList getElementsByTagName(in DOMString name);
void normalize();
};
tagNametagNameは，"elementExample"を値にもつ。
<elementExample id="demo">
...
</elementExample> ,
すべてのDOM操作と同様に，
XMLでは，大文字・小文字を保存していることに注意。
HTML DOMは，
ソースHTML文書での大文字・小文字の表記に関わらず，
正準的な大文字表記形式でHTML要素のtagNameを返す。
getAttributename |
取得する属性の名前。 |
Attrの値。
その属性が割当て値又はデフォルト値をもたない場合は，空の文字列。
setAttributeAttrノード，
Textノード
及び
EntityReference
ノードを生成し，適切な部分木を構築し，
setAttributeNodeを使用してそれを属性の値に割り当てなければならない。
name |
生成又は変更する属性の名前。 | |
value |
文字列の形式で設定する値。 |
DOMExceptionINVALID_CHARACTER_ERR: 指定した名前が妥当でない文字を含む場合に挙げる。
NO_MODIFICATION_ALLOWED_ERR: このノードが読出し専用の場合に挙げる。
removeAttributename |
削除する属性の名前。 |
DOMExceptionNO_MODIFICATION_ALLOWED_ERR: このノードが読出し専用の場合に挙げる。
setAttributeNodenewAttr |
属性リストへ追加する
|
newAttr属性が，同じ名前の既存属性を置換する場合，
以前に存在した
Attr
ノードを返す。
それ以外の場合は，nullを返す。DOMException
WRONG_DOCUMENT_ERR:
この要素を作成した以外の文書から，
newAttrが生成された場合に挙げる。
NO_MODIFICATION_ALLOWED_ERR: このノードが読出し専用の場合に挙げる。
INUSE_ATTRIBUTE_ERR:
newAttrが他のElementオブジェクトの属性であった場合に挙げる。
Attr
ノードを他の要素で再利用するためには，
DOMユーザはそれを明示的にクローン化しなければならない。
removeAttributeNodeAttr
ノード。DOMExceptionNO_MODIFICATION_ALLOWED_ERR: このノードが読出し専用の場合に挙げる。
NOT_FOUND_ERR:
oldAttrが要素の属性ではない場合に挙げる。
normalizeElementの下にある部分木において，一番深いところにあるすべての
Text
ノードを"正規化"形式に変換する。
ここで"正規化"形式とは，マーク付け
(例えば，タグ，コメント，処理命令，CDATAセクション及び実体参照)だけが
Text
ノードを分割する形式，すなわち，互いに隣接する
Text
ノードが存在しない形式とする。
これを使用することで，
文書のDOMビューが，
その文書を格納し再ロードした場合と同じと保証できる。
これは，特定文書の木構造に依存する(XPointerルックアップなどの)
操作を使用する場合に有用となる。
Textインタフェースは，
Element又は
Attr
のテキスト内容
(XMLでは，文字データ(character data)と呼ぶ。)
を表現する。
要素の内容中にマーク付けがない場合，
そのテキストは，その要素のただ一つの子となる，
Textインタフェースを実装する一つのオブジェクトに含まれる。
マーク付けがある場合，
要素の内容は，要素の子どものリストを構成する，要素及び
Textノードのリストへと構文解析される。
DOMを通じて文書が最初に利用可能になったとき，
テキストの各ブロックに対して，ただ一つのTextノードが存在する。
ユーザは，
与えられた要素の内容を表現する複数の隣接するTextノードを，
マーク付けを間に差し込むことなしに，
生成してもよい。
ただし，
XML又はHTMLでは，これらのノード間の区切りを表現する方法がなく，
そのために，それらはDOM編集セションの間では，(一般には，)永続的ではないことを
認識するほうがよい。
Elementに対して
normalizeメソッドを実行すると，
これら隣接するTextオブジェクトがマージされ，
テキストの各ブロックに対して単一のノードとなる。
すなわち，
XPointersを使用した誘導などの，
特定の文書構造に依存する操作を実行する前に，
normalizeメソッドを実行することを推奨する。
interface Text : CharacterData {
Text splitText(in unsigned long offset)
raises(DOMException);
};
splitTextTextノードを，
指定したオフセットで，二つのノードに分割する。
ただし，両者は木の兄弟として保持される。
その結果，このノードは，offset点までのすべての内容だけを含む。
このノードの弟として挿入された新しいTextノードは，
offset点及びそれ以降のすべての内容を含む。
offset |
分割する場所を示すオフセットで，0から始まる。 |
Textノード。DOMException
INDEX_SIZE_ERR:
指定したオフセットが負数又はdata中の文字の数よりも大きい場合に挙げる。
NO_MODIFICATION_ALLOWED_ERR: このノードが読出し専用の場合に挙げる。
これは，コメントの内容を表現する。
すなわち，開始の'<!--'と終了の'-->'
との間にあるすべての文字を表現する。
これは，XMLでのコメントの定義であって，
完全なSGMLコメント構造を実装しているHTMLツールも存在するが，
実際上は，HTMLでのコメントの定義でもあることに注意。
interface Comment : CharacterData {
};
1.3.で規定するインタフェースは，DOM水準1コア規定の一部を構成するが， これらのインタフェースを開示するオブジェクトに， HTMLだけを処理するDOM実装が出会うことはあり得ない。 そこで，HTMLだけのDOM実装は， これらのインタフェースを実装するオブジェクトをもつ必要はない。
CDATAセクションは， マーク付けとみなされる文字を含むテキストブロックを別扱いするために使用する。 CDATAセクションで認識される区切り子は， CDATAセクションを終了する"]]>"文字列だけとなる。 CDATAセクションは，入れ子にはできない。 主要な目的は，すべての区切り子を別扱いする必要なく， XML素片などの素材を含めることにある。
Textノードの
DOMString属性は，
CDATAセクションが含むテキストを保持する。
これは，
CDATAセクションの外側では別扱いする必要がある文字を含んでもよいことに注意。
直列化のために選択された文字符号化("charset")に依存して，
書き出すことが不可能な文字がCDATAセクションに存在するかもしれないことに注意。
CDATASectionインタフェースは，
Text
インタフェースを介して，
CharacterData
インタフェースを継承する。
ただし，隣接するCDATASectionsノードは，
Elementのnormalizeメソッドを使用することによってマージされない。
interface CDATASection : Text {
};
各Documentは，
null又はDocumentTypeオブジェクトを値とする
doctype属性をもつ。
DOM水準1コアのDocumentTypeインタフェースは，
文書で定義された実体のリストへのインタフェースを提供する。
それ以外へのインタフェースは，
名前空間の影響及びDTD表現における様々なXMLスキームの努力が，
この規格の作成時点では明確には分からないため，ほとんど提供しない。
DOM水準1では，DocumentTypeノードの編集をサポートしない。
interface DocumentType : Node {
readonly attribute DOMString name;
readonly attribute NamedNodeMap entities;
readonly attribute NamedNodeMap notations;
};
nameDOCTYPEキーワードの直後にある名前。
entitiesNamedNodeMap。
重複するものは捨てられる。
次に例を示す。
<!DOCTYPE ex SYSTEM "ex.dtd" [ <!ENTITY foo "foo"> <!ENTITY bar "bar"> <!ENTITY % baz "baz"> ]> <ex/>この例では，このインタフェースは，
foo及びbarへのアクセスを提供するが，
bazへのアクセスは提供しない。
このマップ中のすべてのノードは，
Entity
インタフェースも実装する。
DOM水準1では，実体の編集をサポートしないので，
entitiesは，いかなる方法でも変更できない。
notationsNamedNodeMap。
重複するものは捨てられる。
このマップ中の各ノードは，
Notation
インタフェースも実装する。
DOM水準1では，記法の編集をサポートしないので，
notationsは，いかなる方法でも変更できない。
このインタフェースは，DTDで宣言された記法を表現する。
記法は，名前によって，
解析対象外実体(XML 1.0規定の4.7を参照)のフォーマットを宣言するか，
又は処理命令ターゲットの形式的宣言(XML 1.0規定の2.6を参照)のために使用するかのいずれかとする。
Nodeから継承される
nodeName属性には，記法の宣言名を設定する。
DOM水準1では， Notationの編集をサポートしない。
そこで，記法は読出し専用とする。
Notationノードは，親をもたない。
interface Notation : Node {
readonly attribute DOMString publicId;
readonly attribute DOMString systemId;
};
このインタフェースは，XML文書中の解析対象実体又は解析対象外実体を表現する。 これは，実体宣言ではなく実体それ自体をモデル化することに注意。 実体宣言のモデル化は， DOM規定の今後の水準に延期された。
Nodeから
継承されたnodeName属性は，実体の名前を含む。
XML処理系は，構造モデルをDOMに渡す前に，
実体を完全に展開することを選択してもよい。
この場合は，
EntityReference
ノードは，文書木中に存在しないことになる。
XMLは，妥当性を検証しないXML処理系が，
外部サブセットで行われた実体宣言又は外部パラメタ実体で宣言された実体宣言を入力し処理することを
要求しない。
これは，アプリケーションのクラスの中には，
外部サブセットで宣言された解析対象実体を展開する必要がなく，
実体の置換え値が利用可能でなくともよいものがあることを意味する。
置換え値が利用可能な場合，
対応するEntityノードの子リストは，
その置換えテキストの構造を表現する。
それ以外の場合は，子リストは空とする。
Entityの子ども(つまり，置換え値)の解決は，遅延評価をしてもよい。
すなわち，
(Entityノード上でchildNodesメソッドを呼び出すなどの)
ユーザの動作が評価を引き起こすと仮定する。
DOM水準1では，Entityノードの編集をサポートしない。
そこで，
ユーザがEntityの内容を変更したい場合には，
すべての関連する
EntityReferenceノードを，
構造モデルの中で，
Entityの内容のクローンに置き換え，
直接変更する代わりに，それらのクローン化したものに希望の変更を行わなければならない。
Entityノードのすべての子孫は，読出し専用とする。
Entityノードは，親をもたない。
interface Entity : Node {
readonly attribute DOMString publicId;
readonly attribute DOMString systemId;
readonly attribute DOMString notationName;
};
publicIdnullとする。
systemIdnullとする。
notationNamenullとする。
実体参照がソース文書にある場合，
又はユーザが実体参照を挿入することを望む場合は，
EntityReferenceオブジェクトを構造モデルに挿入してもよい。
文字参照及び予め定義した実体の参照は，
HTML又はXML処理系によって展開されると考えられるので，
文字は，実体参照によってではなく，それと等価なUnicodeによって表現されることに注意。
更に，XML処理系は，
EntityReferenceオブジェクトを提供する代わりに，
構造モデルを構築する間に，
参照を実体へ完全に展開してもよい。
EntityReferenceオブジェクトを提供する場合は，
与えられたEntityReferenceノードに対して，
参照される実体を表現する
Entityノードが
存在しなくともよい。
ただし，このEntityが存在する場合は，
EntityReferenceノードの子リストは，
Entityノードの
子リストと同じとする。
Entityノードと同様に，
EntityReferenceのすべての子孫は，読出し専用とする。
EntityReferenceの子ども
(参照されたEntityの置換え値)
の解決は，遅延評価をしてもよい。
すなわち，
(EntityReferenceノードでchildNodesメソッドを呼び出すなどの)
ユーザの動作が評価を引き起こすと仮定する。
interface EntityReference : Node {
};
ProcessingInstructionインタフェースは，
処理系に固有情報を文書のテキスト中に保存する方法としてXMLで使用される"処理命令"を表現する。
interface ProcessingInstruction : Node {
readonly attribute DOMString target;
attribute DOMString data;
// raises(DOMException) on setting
};
target
data?>の直前の文字までとする。
DOMExceptionNO_MODIFICATION_ALLOWED_ERR: このノードが読出し専用の場合に挙げる。
|
|
|