Tweet

4.4.6 Notify（通知）

　次は「4.4.6 Notify（4.4.6 通知）」である。これは解析対象外実体の名前が指定された場合の動作にしか使われない。さて、話としては複雑ではないのだが、文章はやや長いので、分解して確認しておこう。ここでは「解析対象外実体の名前が、ENTITY型またはENTITIES型の属性値においてトークンとして現れたとき」という条件が付けられているが、これは多少冗長である。Notifyが書かれたOccurs as Attribute Valueは、そもそもすでに「型として宣言した属性の値として出現するか、またはENTITIES型として宣言した属性の値におけるスペースで区切られたトークンの1つとして出現する」と限定されているためである。

　さて、その後は、システム識別子と公開識別子を応用プログラムに通知しなければならないとしている。解析対象外実体はその名のとおり解析の対象外であるから、それを処理する方法をXML勧告内ではまったく示すことができない。ただ、応用プログラムに通知することだけを要求している。通知さえされれば、後は応用プログラムが責任を持ってどのようにでも処理ができるのである。なお、公開識別子に「存在すれば」という限定が付いているのは、システム識別子だけが指定され、公開識別子が指定されないケースが存在するためである。

4.4.7 Bypassed（処理しない）

　次は「4.4.7 Bypassed（4.4.7 処理しない）」である。これは、置換テキストを取り込むことなく、そのまま参照を残すということである。しかし、参照をそのまま残すという方法などにどのような意味があるのだろうか。

　Bypassedは、表中でReference in EntityValueにのみ出現することに注目してみよう。つまり、実体値として記述する場合にのみ存在する。実体値は実体を宣言するために使われるものであり、後からこれが処理されるチャンスが訪れる。つまり、この段階で処理を行わず、参照をそのまま残しても問題ないのである。むしろ、実体の値を上書きして入れ替えるような使い方があることを考えれば（本連載「第11回　XMLの外部参照と非依存文書宣言」のDTDカスタマイズの話題参照）、実際に実体が参照されるまで、処理を保留することは価値があるといえるだろう。そうすれば、後から定義された実体によって置換することができるようになる。

4.4.8 Included as PE（PEとして取り込み）

　次は「4.4.8 Included as PE（4.4.8 PEとして取り込み）」である。外部解析対象実体を処理する条件はすでに「XML文書の妥当性を検証しないときは、実体の置換テキストを取り込んでもよいが、取り込むことを義務づけられてはいない」と述べた。パラメタ実体も条件が同様であることが冒頭の文章で示されている。つまり「XML文書の妥当性を検証しないときは、パラメタ実体の置換テキストを取り込んでもよいが、取り込むことを義務づけられてはいない」と読み替えてよいことになる。ちなみに、妥当性を検証しないことと、DTDを処理しないことはイコールではないことにあらためて注意を払っておこう。妥当性を検証しない場合でも実体を処理することはでき、その場合にはDTDの情報が使われる。そして、DTDの内部ではパラメタ実体を記述できる以上、パラメタ実体の処理を行う価値があるケースがあり得る。

　次の文章は、重要な規定である。パラメタ実体を使ってトークンを組み立てることはできないことを示しているためである。例えば、ENTITYという文字列を得るために、以下のように記述してみたとしよう。

<!ENTITY % ent "ENT" >

%ent;ITY

　書き手の意図は、「%ent;」がENTに置き換えられて、結果は「ENTITY」という1トークンになるというものであった。しかし、取り込み時に「前後に1つのスペース文字（#x20）の付加」という規定によって、ENTの前後にはスペース文字が追加される。その結果は「ENTITY」ではなく、「 ENT ITY」という2トークンに置き換えられる。この規定は、実は制約を与えるものというよりは、便利に使えるものである。パラメタ実体を多用してDTDを組み上げる際、うっかり個別のパラメタ実体が連結してしまって、意図しないトークンが発生することを避けることができる。

　次の文章で述べているのは、DTDの構文は、トークンと記号の集合体と見ることができるが、実体値の中は「トークン」という概念のない普通の文字列であるかもしれない、ということである。そのような文字列を扱う際、自動的にスペース文字を挿入することは文字列の改変になってしまい、明らかに不適切である。区切りの空白が増えてもトークンは不変であるが、普通の文字列は違うものになってしまう。つまり、スペース文字の挿入はDTDの構文（Reference in DTD）においてのみ行ってよいことであり、実体値（Reference in EntityValue）においては改変となるため行ってはならないことになる。

4.4.9 Error（誤り）

　次は「4.4.9 Error（4.4.9 誤り）」である。これは、XML 1.0勧告のThird Editionより追加されたものである。もともとForbiddenであったものが、1つErrorに置き換えられている。Forbiddenは「致命的な誤り」であるが、Errorの追加はそれよりも弱い「誤り」を記述可能にするためといえる。致命的な誤りは必ず報告しなければならないが、誤りは「報告してもよく、誤りから回復してもよい」という相違がある。errataによれば、誤りの度合いを弱めたのは、既存の実装を追認するためであったらしい。

◇

　さて、以上で「4.4 XML Processor Treatment of Entities and References（4.4 XMLプロセッサによる実体および参照の扱い）」を読み終わった。実体は文脈によって振る舞いが変わるので、特にDTD内で使用した場合などに扱いが分かりにくくなることがある。それ故に表形式で振る舞いが分かるのはよいのだが、表を読むために多くの説明を読まねばならないのは、ややハードルが高い。とはいえ、表の読み方さえ分かってしまえば、必要な個所だけ読めばよいので、さほど面倒ではないだろう、すべてを暗記する必要はないが、表の読み方だけ把握しておくと価値があるだろう。

　次回は、「4.5 Construction of Internal Entity Replacement Text（4.5 実体置換テキストの構築）」を読んでいこう。これは、実体の参照を、置換テキストに置き換えていく際の規定について説明している。とはいえ、すでに多くは規定し尽くされているので、残った量は多くはない。XML 1.0勧告の本文を読み切るのは、そう遠いことではない。（次回に続く）

3/3

Index
やさしく読む「XML 1.0勧告」 第30回 実体参照における「振る舞い」とは何か
	Page 1 ・XMLプロセッサによる実体および参照の「振る舞い」 ・文脈別に見る実体と参照の表 ・振る舞いの内容 　‐4.4.1 Not Recognized（認識しない） 　‐4.4.2 Included（取り込み）
	Page 2 　‐4.4.3 Included If Validating（検証のために取り込み） 　‐4.4.4 Forbidden（禁止） 　‐4.4.5 Included in Literal（ リテラル内での取り込み）
	Page 3 　‐4.4.6 Notify（通知） 　‐4.4.7 Bypassed（処理しない） 　‐4.4.8 Included as PE（PEとして取り込み） 　‐4.4.9 Error（誤り）

連載　やさしく読む「XML 1.0勧告」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）