第052回_EntityDecl_文字参照_参照方法

[Definition: A character reference refers to a specific character in the ISO/IEC 10646 character set, for example one not directly accessible from available input devices.]

Character Reference

[66] CharRef ::= '&#' [0-9]+ ';'
　　　　　　　　| '&#x' [0-9a-fA-F]+ ';' [WFC: Legal Character]

Well-formedness constraint: Legal Character
　Characters referred to using character references must match the production for Char.

文字参照

[66] CharRef ::= '&#' [0-9]+ ';'
　　　　　　　　| '&#x' [0-9a-fA-F]+ ';' [WFC: Legal Character]

整形式性制約: 正当な文字
　文字参照を使って参照する文字は生成規則Charにマッチしなければならない。

Entity Reference

[67] Reference ::= EntityRef | CharRef
[68] EntityRef ::= '&' Name ';' [WFC: Entity Declared]
　　　　　　　　　　　　　　　[VC: Entity Declared]
　　　　　　　　　　　　　　　[WFC: Parsed Entity]
　　　　　　　　　　　　　　　[WFC: No Recursion]
[69] PEReference ::= '%' Name ';' [VC: Entity Declared]
　　　　　　　　　　　　　　　　　[WFC: No Recursion]
　　　　　　　　　　　　　　　　　[WFC: In DTD]

Well-formedness constraint: Entity Declared
　In a document without any DTD, a document with only an internal DTD subset which contains no parameter entity references, or a document with "standalone='yes'", for an entity reference that does not occur within the external subset or a parameter entity, the Name given in the entity reference must match that in an entity declaration that does not occur within the external subset or a parameter entity, except that well-formed documents need not declare any of the following entities: amp, lt, gt, apos, quot. The declaration of a general entity must precede any
reference to it which appears in a default value in an attribute-list declaration.

Note that non-validating processors are not obligated to to read and process entity declarations occurring in parameter entities or in the external subset; for such documents, the rule that an entity must be declared is a well-formedness constraint only if standalone='yes'.

Validity constraint: Entity Declared
　In a document with an external subset or parameter entity references with "standalone='no'", the Name given in the entity reference must match that in an entity declaration. For interoperability, valid documents should declare the entities amp, lt, gt, apos, quot, in the form specified in 4.6 Predefined Entities. The declaration of a parameter entity must precede any reference to it. Similarly, the declaration of a general entity must precede any attribute-list declaration containing a default value with a direct or indirect reference to that general entity.

Well-formedness constraint: Parsed Entity
　An entity reference must not contain the name of an unparsed entity. Unparsed entities may be referred to only in attribute values declared to be of type ENTITY or ENTITIES.

Well-formedness constraint: No Recursion
　A parsed entity must not contain a recursive reference to itself, either directly or indirectly.

Well-formedness constraint: In DTD
　Parameter-entity references must not appear outside the DTD.

[定義: パラメータ実体の参照は、パーセント(%)とセミコロン(;)を区切り子として使う。]

実体参照

[67] Reference ::= EntityRef | CharRef
[68] EntityRef ::= '&' Name ';' [WFC: 宣言した実体]
　　　　　　　　　　　　　　　[VC: 宣言した実体]
　　　　　　　　　　　　　　　[WFC: 解析実体]
　　　　　　　　　　　　　　　[WFC: 再帰しない]
[69] PEReference ::= '%' Name ';' [VC: 宣言した実体]
　　　　　　　　　　　　　　　　　[WFC: 再帰しない]
　　　　　　　　　　　　　　　　　[WFC: DTDの中]

妥当性制約: 宣言した実体

整形式性制約: 解析実体

整形式性制約: 再帰しない

妥当性制約: DTDの中

■適合性による、妥当性を検証しないプロセッサの仕様

よって注意書きの論旨は、
　妥当性を検証しないプロセッサはXML文書の一部を読み飛ばした可能性があるので、
　　DTDが記述したとおりに構築できないかもしれない。
　　そのため、読み飛ばした可能性のあるDTDを元に整形式性制約を適用してはいけない
という点と、
　スタンドアロン文書宣言がyesならば、DTDは記述したとおりに構築できたとして良い。
　もし、DTDが記述したとおりに構築できていないならば、それはスタンドアロン文書宣言の指定ミスである。
　そのため、読み飛ばした可能性があったとしてもスタンドアロン文書宣言がyesならば、整形式性制約を適用する
という点です。

一方、空かどうかを考慮にいれないで作成した表は次のようになります。

表2.

これらの2つの表においてプロセッサの読み飛ばしが無いのは、
　パターンA、B、E(表1のみ)、H
です。

次にW3Cの勧告
　# 整形式性制約: 宣言した実体
　# DTDを持たない文書、パラメータ実体の参照を1つも持たない内部サブセットだけを持つ文書
とあり、指定する条件で分けると、
　DTDを持たない文書：パターンA、B、C(表1のみ)、E(表1のみ)、F(表1のみ)
　パラメータ実体参照を1つも持たない内部サブセットだけを持つ文書：パターンH
です。

読み飛ばしがないパターンとW3Cの勧告が指定する条件の違いはパターンC、Fです。
そしてパターンC、Fは表1にしかありません。このことから、
　「妥当性を検証しないプロセッサはDTDを構築するときに読み飛ばしを行ったかどうかを認識しない」
→
　「妥当性を検証しないプロセッサは構築したDTDが空だったとしてもそれは読み飛ばした可能性があり、DTDが無いとは言えない」
　→
　「DTDが無いという場合、内部サブセットと外部サブセットの出現が無いことと同一視して良い」
ということが推測できます。
#
# こうなると、46回で議論した「DTDはマークアップ宣言から成る」
# という記述に表現の問題がありそうです。
#

一般実体が記載できる位置は構文

AttValueについては、

2-2.contentに現れるAttValueの中と 3.contentで一般実体の参照を認識した場合、
すべての実体宣言を読み込み済みなので"宣言より先に"の制限は必要ありません。

次に、1.EntityValueの中で一般実体の参照を認識した場合（後の説明でわかりますが）「バイパス」します。
つまり、実体宣言をテーブルに登録する時点では展開せず、置換テキストとして登録します。
よって、参照名をキーにテーブルを検索しないので"宣言より先に"の制限は必要ありません。

最後に、2-1.属性リスト宣言のデフォルト値のAttValueの中で一般実体の参照を認識した場合、
デフォルト値の正規化処理をするので「リテラルの中でインクルード」します。
この際、参照名をキーにテーブルを検索するので"宣言より先に"の制限が必要になります。

W3Cの勧告が"宣言より先に"と明記することで、属性リスト宣言の1つで一般実体の参照を見つけた時、
ただちに展開処理しないといけない(DTDをすべて読み込んでから処理してはいけない)ということが
明確になります。

▼記載位置

▼パターン表

▼パラメータ実体名と定義済み実体名の名前空間

▼妥当性を検証しないプロセッサの参照名に対する展開処理

▼妥当性を検証するプロセッサの参照名に対する展開処理