第30回 実体参照における「振る舞い」とは何か Page 2
川俣 晶
株式会社ピーデー
2005/2/5
4.4.3 Included If Validating(検証のために取り込み)
When an XML processor recognizes a reference to a parsed entity, in order to validate the document, the processor MUST include its replacement text. If the entity is external, and the processor is not attempting to validate the XML document, the processor MAY, but need not, include the entity's replacement text. If a non-validating processor does not include the replacement text, it MUST inform the application that it recognized, but did not read, the entity. |
(第1段落) |
次は、「4.4.3 Included If Validating(4.4.3 検証のために取り込み)」である。これは2段落もあってやや長いが、それは条件によって処理内容が変化するためである。条件の違いを把握しつつ読んでいこう。
第1段落冒頭の文章での条件は「文書の妥当性を検証するには」である。妥当性を検証しない場合はこの文章の対象外である。そして、解析対象実体への参照に対しては、必ず(MUST)その置換テキストを取り込まなければならないとしている。取り込まないという選択はあり得ない。
次の文章の条件は、「XML文書の妥当性を検証しないとき」である。その際、外部実体への参照に対して、置換テキストを取り込んでもよい(MAY)が、義務づけられてはいないのである。非常に悩ましいことではあるが、この条件の場合、処理結果は1つに決まらない。外部実体を活用する場合は、XMLパーサを交換すると結果が異なるケースがあることを知っておく価値があるだろう。
第1段落最後の文章の条件は「妥当性を検証しないプロセッサが置換テキストを取り込まない場合」である。その場合は、XMLプロセッサは読み込まなかったことを応用プログラムに通知する義務を持つ。応用プログラムは、その通知を得ることによって、結果が不完全であるかもしれない事実を知ることができる。それを知った応用プログラムが、どのように対処するかは、応用プログラム次第である。XML勧告が求めるのは通知するところまでである。
話はさらに第2段落に続く。そこでは、このような規定になっている理由を説明している。
This rule is based on the recognition that the automatic inclusion provided by the SGML and XML entity mechanism, primarily designed to support modularity in authoring, is not necessarily appropriate for other applications, in particular document browsing. Browsers, for example, when encountering an external parsed entity reference, might choose to provide a visual indication of the entity's presence and retrieve it for display only on demand. |
(第2段落) |
第2段落冒頭の文章では、実体の2つの用途が具体的に示されている。1つは、文書作成時のモジュール化であり、もう1つは文書のブラウジングを一例とするほかの応用プログラムである。文書作成時のモジュール化というのは、例えば、大きな文書を作成する際、各章をそれぞれ独立した外部実体として作成しておき、それらを実体参照で統合することで1つの大きな書籍原稿にするような使い方である。このような使い方の場合、参照できない、あるいは参照しない外部実体が1つでもあれば、致命的なエラーとして認識される必要がある。章を1つでも欠いてしまえば、それは書籍原稿として不完全である。しかし、ほかの用途ではそうともいえない事例があることが次の文章で示されている。
次の文章で例として示された事例の場合、XML文書の解析時には、ある実体への参照が存在するということが分かるだけでよく、それを置換する必要はないし、むしろ置換すべきではない。例えば、全体として巨大な文書がある場合、各章は外部実体として分離しておき、指定された章だけを読み込んで表示するようなシステムはあり得るだろう。指定されない章は処理しないようにできれば、より少ない資源で迅速に文書を閲覧できる。このようなシステムを実現するには、外部実体の取り込みを必須にしないことと、置換しなかった場合に通知することが必須の要件として求められる。
とはいえ、この2つだけあれば、ここで例示されたようなシステムが実現できるかといえば、そうではない。このようなシステムを実現するには、確実に外部実体を取り込まないオプションの提供と、特定の外部実体だけを単位にした解析の機能が必要とされる。ここで、これらを組み合わせて例として書かれたような機能を実現することを考えてみよう。それは、かなり高度かつ複雑な処理になると思われるが、不幸にして筆者は実現された事例を知らない。もしご存じの読者がいればご教示願いたい。
The following are forbidden, and constitute fatal errors:
|
次のものは禁止されており、致命的な誤りとする。
|
次は、「4.4.4 Forbidden(4.4.4 禁止)」である。ここは少々分かりにくい。なぜなら、表がすでに条件を限定しているにもかかわらず、ここで「次のものは禁止」として再び条件が記述されているためである。そして、両者の条件は厳密には一致していない。例えば、横がInternal General(内部一般)、縦がOccurs as Attribute Value(属性値として出現)の項目がForbiddenになっているが、これは「次のものは禁止」とされた3条件に該当しないが、誤りにするのが妥当だろう。ちなみに、これは内部一般実体の名前を属性値に書いた場合となるが、もちろんCDATA型の実体に書いてもForbiddenになるわけではない。これはENTITY型ないしENTITIES型として宣言された属性値として、内部一般実体の名前を記述することがForbidden(禁止)であるという趣旨である。かなりややこしいので注意しよう。
3つの条件は、じっくりと表と照らし合わせると、Forbiddenと書かれたかなりの範囲を網羅していることが分かる。これらの条件を満たす場合は、致命的な誤りである。
4.4.5 Included in Literal(リテラル内での取り込み)
When an entity reference appears in an attribute value, or a parameter entity reference appears in a literal entity value, its replacement text MUST be processed in place of the reference itself as though it were part of the document at the location the reference was recognized, except that a single or double quote character in the replacement text MUST always be treated as a normal data character and MUST NOT terminate the literal. For example, this is well-formed:
<!ENTITY % YN '"Yes"' >
<!ENTITY WhatHeSaid "He said %YN;" > while this is not:
<!ENTITY EndAttr "27'" > <element attribute='a-&EndAttr;> |
実体参照が属性値の中で現れたとき、または、パラメタ実体への参照がリテラル実体値の中で現れたとき、置換テキストは、参照自体の代わりに、参照があった位置に文書の一部としてあったものとして処理されるが、例外として置換テキストの中の一重引用符または二重引用符文字は、常に通常の文字データとして扱われ、リテラルを終了させることはない。これは整形式である。 <!ENTITY % YN
'"Yes"' >
<!ENTITY WhatHeSaid "He said %YN;" > 一方、これは整形式ではない。 <!ENTITY EndAttr "27'" > <element attribute='a-&EndAttr;> |
次は、「4.4.5 Included in Literal(4.4.5 リテラル内での取り込み)」である。この文章で述べているのは、Included(取り込み)の特殊な事例である。通常のIncluded(取り込み)とどこが違うのかといえば、「置換テキストの中の一重引用符または二重引用符文字は、常に通常の文字データとして扱われ、リテラルを終了させることはない」という部分である。XML勧告には引用符でくくる構文はいくつかあるが、実体を置換した結果に引用符が含まれていた場合、その引用符が「引用符でくくる」ための引用符として認識される可能性があり得る。しかし、それは実体参照と引用符のネスト関係が崩れることを意味し、さまざまな問題を引き起こす可能性が生じる。しかし、この規定によって、そのような問題は発生しないように抑止される。
次に、整形式と整形式ではない2つの例が掲載されている。
上の例は、二重引用符を含む値「"Yes"」がパラメタ実体YNの値となる。これを、「He said %YN;」として実体値の中で参照することは問題ない。この実体の値は取り込みの結果「He said "Yes"」となる。引用符がそのまま実体の値の一部となるのは、Included in Literal(リテラル内での取り込み)ならではの動作である。
一方、下の例は整形式ではない。「'a-&EndAttr;」を置換すると確かに「'a-27'」になるのだが、Included in Literal(リテラル内での取り込み)の規定により、置換テキスト中の「'」記号はリテラルを終了させる機能を持たないため、このリテラルは閉じ引用符がなく構文的に正しくないと見なされてしまう。(次ページへ続く)
2/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勧告」 |
- QAフレームワーク:仕様ガイドラインが勧告に昇格 (2005/10/21)
データベースの急速なXML対応に後押しされてか、9月に入って「XQuery」や「XPath」に関係したドラフトが一気に11本も更新された - XML勧告を記述するXMLspecとは何か (2005/10/12)
「XML 1.0勧告」はXMLspec DTDで記述され、XSLTによって生成されている。これはXMLが本当に役立っている具体的な証である - 文字符号化方式にまつわるジレンマ (2005/9/13)
文字符号化方式(UTF-8、シフトJISなど)を自動検出するには、ニワトリと卵の関係にあるジレンマを解消する仕組みが必要となる - XMLキー管理仕様(XKMS 2.0)が勧告に昇格 (2005/8/16)
セキュリティ関連のXML仕様に進展あり。また、日本発の新しいXMLソフトウェアアーキテクチャ「xfy technology」の詳細も紹介する
|
|