第29回 実体を参照する文脈=コンテキスト Page 3
川俣 晶
株式会社ピーデー
2005/1/13
さて、次は表に先立って文脈の種類の説明を行っている。ここで使われる「文脈」という言葉の意味は、上記の余談のような意味ではなく、構文上のどのような場所を対象とするかの相違を意味する。例えば要素の内容と属性値では、そこに記述可能なものに違いがあることをすでに読んできた。しかし、開始タグと終了タグの間が要素の内容になるのであって、ここからが要素の内容ですというような明示的な情報を書き込んでいるわけではない。つまり、要素の内容という対象は、情報というよりは「文脈=コンテキスト」である。ここでは、そのような意味での「文脈」を扱う。
まず、Reference in Content(内容における参照)である。非終端記号とは、EBNFで表記する生成規則の一種である(EBNFの詳細については、第2回「XML勧告読解に必須のEBNF」を参照)。つまり、非終端記号contentとは、生成規則[43] contentを示す。この生成規則の内容は以下のようなものであった。
|
この生成規則は本連載の第13回「論理構造と開始タグ、終了タグ、空要素タグ」で解説済みなので、詳しい説明は繰り返さない。
非終端記号contentという言葉が出てきて説明が複雑化しているが、要するに「要素の開始タグおよび終了タグの間の任意の場所での参照」ということである。
|
次は、Reference in Attribute Value(属性値における参照)である。非終端記号AttValueは、生成規則[10] AttValueに当たる。この生成規則の内容は以下のようなものであった。
|
この生成規則は本連載の第6回「XMLにおける名前、トークン、リテラルデータ」で解説済みなので、詳しい説明は繰り返さない。
これも非終端記号AttValueという言葉が出てきて説明が複雑化しているが、要するに「属性の値、または属性宣言におけるデフォルト値のいずれかでの参照」ということである。
|
|
次はOccurs as Attribute Value(属性値として出現)である。この定義は、Reference in Attribute Value(属性値における参照)との区別が付きにくい。どちらも属性値を使う場合の規定だからである。この2つは、属性値の中に実体の参照を記述するか、それとも属性値に実体名を記述するか、という相違である。つまり、実体の名前がentityNameのとき、Reference in Attribute Value(属性値における参照)は、attribute="&entityName;"と記述する場合であり、Occurs as Attribute Value(属性値として出現)はattribute="entityName"と記述する場合である。これについての詳しい話は、本連載の第21回「物理構造の基本、「実体」の種類と意味を理解する」に書いている。
|
|
次はReference in Entity Value(実体値における参照)である。非終端記号EntityValueは、生成規則[9] EntityValueに当たる。この生成規則の内容は以下のようなものであった。
|
この生成規則は本連載の第6回「XMLにおける名前、トークン、リテラルデータ」で解説済みなので、詳しい説明は繰り返さない。
これも分かりにくくなっているが、要するに実体の宣言中での「パラメタ実体または内部実体のリテラル実体値の中での参照」である。つまり、実体宣言に記述する実体値の中での参照である。
|
|
次は、Reference in DTD(DTDにおける参照)である。この文章は、前半と後半を分けて考えると分かりやすいだろう。前半は基本的な規定で、後半は例外規定である。
前半は、「DTDの内部または外部サブセットのいずれかの中に現れる参照」としている。これは「DTDの内部」または「外部サブセット」ではなく、DTDの「内部または外部」サブセットと読む。つまり、DTDの内部サブセットまたはDTDの外部サブセットということである。そこに現れる参照を対象としている。
後半はその例外規定である。これは、以下の対象の外側にある場合が対象外であるとしている。その対象とは、EntityValue、AttValue、PI、Comment、SystemLiteral、PubidLiteral、無視される条件付きセクションである。
EntityValueとは生成規則[9] EntityValueで内部実体の内容を表現するもの、AttValueとは生成規則[10] AttValueで属性値を表現するもの、PIとは生成規則[16] PIで処理命令を表現するもの、Commentとは生成規則[15] Commentでコメントを表現するもの 、SystemLiteralとは生成規則[11] SystemLiteralで外部識別子を表現するもの、PubidLiteralとは生成規則[12] PubidLiteralのことで公開識別子を表現するものである。生成規則[15] Commentは本連載第7回「XMLで使ってもいい文字データとコメント」で、生成規則[16] PIは本連載第8回「XML文書中の処理命令とCDATAセクション」で、ほかは本連載第6回「XMLにおける名前、トークン、リテラルデータ」で解説している。また、「無視される条件付きセクション」は条件付きセクションが無視される場合だが、条件付きセクションは本連載の第20回「DTDで指定範囲の有効/無効を切り替える」に解説しているので、詳しくは各記事を参照してほしい。
次に、いよいよ表の本体がくる。
Entity Type | Character | ||||
Parameter | Internal General | External Parsed General | Unparsed | ||
Reference in Content | Not recognized | Included | Included if validating | Forbidden | Included |
Reference in Attribute Value | Not recognized | Included in literal | Forbidden | Forbidden | Included |
Occurs as Attribute Value | Not recognized | Forbidden | Forbidden | Notify | Not recognized |
Reference in EntityValue | Included in literal | Bypassed | Bypassed | Error | Included |
Reference in DTD | Included as PE | Forbidden | Forbidden | Forbidden | Forbidden |
これで、参照の種類(横)と文脈(縦)を見ることで、特定の文脈、特定の型の実体に対応する振る舞いが何かを読み取ることが可能となった。例えば、Entity Type(実体の型)がParameter(パラメタ)つまり、パラメタ実体をReference in Content(内容における参照)という場所(文脈)に記述した場合の振る舞いは、「Not recognized」であることが読み取れる。しかし、これではまだ十分ではない。「Not recognized」という名前が分かっても、それがどう振る舞うのかが分からないためである。
◇
さて、まだ「4.4 XML Processor Treatment of Entities and References(4.4 XMLプロセサによる実体および参照の扱い)」は終わってはいないが、今回はここまでである。この表は、個人的にはXML勧告最大の山場だと思うのだが、それだけ内容が厚い。続きは次回をお待ちいただきたい。次回は、振る舞いの種類である「Not Recognized」や「Included」の詳しい意味を読んでいく予定である。(次回に続く)
3/3 |
Index | |
やさしく読む「XML
1.0勧告」 第29回 実体を参照する文脈=コンテキスト |
|
Page
1 ・XMLプロセサによる実体および参照の扱い ・文脈別に見る実体と参照 |
|
Page
2 ・余談:文脈の重要性とXML |
|
Page 3 ・文脈の種類 |
連載 やさしく読む「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」の詳細も紹介する
|
|