Entity

Entity (DOM)

Entity 節・Entity 界面 (DOM)

[2] DOM 1 によれば、 Entity実体をモデル化したものであり、 ENTITY 宣言をモデル化したものではありません。 将来の水準の DOM で実体宣言をモデル化したものを規定するかもしれないとしています。

実体は解析実体でも非解析実体でもあり得ます。

[3] 置換値 (実体参照置換文に当たるもの。) がある場合は、実体節の子節としてそれを得ることが出来ます。 (外部非解析実体の場合や、外部解析実体を読んでいない場合などには置換値が存在しないかもしれません。)

置換値の設定 (実体の評価) は、文書木が作られるときではなく、 実際に必要になった (実体節の置換値が参照された) ときに行われるかもしれません (怠惰評価)。

[4] DOM 1 では、実体節は常に読取専用で、編集できません。

[5] Node 界面を継承して:

読取専用属性notationName記法名[DOM1]
読取専用属性publicId公開識別子[DOM1]
読取専用属性systemIdシステム識別子[DOM1]

[1] DOM1 では、実体節 (Entity node) は次の種類の子を持つことが出来ます。

[7] この界面は拡張界面です。 DOM 1 HTML では、この界面は実装しなくて構いません。

[9] Entity既知の実体を表すという。また、実体は読んで処理されるとは限らないので、置換文が入手できない場合があり、その場合Entity子供だという。

これは、未展開実体参照に対応する実体節点を (その宣言を読んでいなくても) 作ることを想定しているのか??

(名無しさん)

[10] >>9 非検証処理器外部実体への参照を認識しても読んで処理する必要はないについていっているのかも。

(名無しさん)

[11] Opera 9 は XML 文書DTD に含まれる (有効な) 実体宣言から Entity 節点を作り、 DocumentType 節点entities に含めます。

(名無しさん)

[12] >>11 最初の5つは、必ず ampltgtaposquot (この順) の Entity になります。

(名無しさん)

[13] >>12 その後、DTD で明示的に宣言されている実体が続きます。 宣言された順序で並びます。 重複している実体宣言処理されなかった実体宣言に相当する Entity 節点は作られません。 (名無しさん)

[14] >>11 実体値Entity子孫となるのですが、 Entity子供となるべき節点は、 なぜか EntitychildNodes に含まれません。 また、子供となるべき節点parentNode はなぜか Document 節点になっています。

一方で、 firstChildlastChildtextContenttext 的には正しく子供であるかのように見えています。 (名無しさん)

[15] 実体値が (XML としては正しくても) 構文解析に失敗するような値の時には、 子供は作られないようです。 amplt もこのケースに該当するようで、子供なしになります。 (名無しさん)

[16] XMLSerializer を使って Entity 節点直列化しようとすると、子孫を順に直列化したものが返されるようです。

DocumentType直列化しようとしても空文字列が返されるようです。
Document直列化すると内部部分集合には internalSubset の値が使われるようで、 Entity木構造は反映されません。

(名無しさん)

[17] ちなみに、 Opera 9 の HTML 文書entitiesNamedNodeMap が入ってはいますが、常に空のようです。 (名無しさん)

[18] >>15 いや、 amplt がそうなのはおかしいですね。 二重に escape されているはずですから。 (名無しさん)

[19] >>15 いや、 amplt がそうなのはおかしいですね。 二重に escape されているはずですから。 (名無しさん)

[20] >>15 いや、 amplt がそうなのはおかしいですね。 二重に escape されているはずですから。 (名無しさん)

メモ