第32回 記法宣言の全容と文書実体の特殊事情 Page 1
XML 1.0は、1998年にW3Cから勧告として公開された。当然中身は英語で、しかもEBNFと呼ばれる式によって重要な部分が記述してある。この連載では、XML 1.0を深く理解するために、そのXML 1.0勧告の最新版「Extensible Markup Language (XML) 1.0 (Third Edition)」をだれでも分かるように、やさしく読み解きながら解説していくことを目指している。(編集局)
川俣 晶
株式会社ピーデー
2005/4/2
主な内容 --Page 1--
記法宣言と文書実体の概要「語ってもよろしいですかな?」 記法宣言(Notation Declarations) --Page 2--
記法宣言の用語定義記法宣言の生成規則 --Page 3--
記法宣言の妥当性制約文書実体(Document Entity) |
前回は、「4.5 Construction of Entity Replacement Text(4.5 実体置換テキストの構築)」と「4.6 Predefined Entities(4.6 定義済み実体)」を読んだ。実体置換テキストの構築では、実体を置換する際に使われる「実体置換テキスト」をどのように構築するかについて詳しい規定が記述されていた。さまざまな種類の参照を、どのタイミングで置換するかを理解できただろう。これを守ることで、相互運用性の高いXMLプロセッサを開発できる。一方、定義済み実体の方は、われわれが特別な文字を記述するためによく使う「<」や「&」などの実体について詳細な規定を行っている個所であった。初心者であっても必ず使う非常に基本的な機能だが、それを定義するには少々ややこしい問題もつきまとうので、注意を必要とすることも紹介した。
さて、今回は「4.7 Notation Declarations(4.7 記法宣言)」と「4.8 Document Entity(4.8 文書実体)」について読んでいく。これを読み切れば、XML 1.0勧告最大の山場ともいえる「4 Physical Structures(4 物理構造)」を読み終えることになる。あと一息、頑張ろう。「4.7 Notation Declarations(4.7 記法宣言)」では、これまで何回も本文に出てきていながら、後で説明するとして先送りしてきた記法についての詳しい説明を行う。利用頻度は低いが、たとえ使わないとしても好奇心を持って見ていただきたい。もう1つの「4.8 Document Entity(4.8 文書実体)」は、XML利用者ならだれでも必ず使う文書実体についての規定であり、すべてのXML利用者に関係あるといっても過言ではない。説明文が短いのは、各種実体に共通する特徴や規定は別の個所で行われており、ここには文書実体だけが持つ特徴や規定だけが記されているためである。短いものなので、一気に読み切って達成感を味わおう。
編集注:この連載では、XML 1.0勧告であるW3Cの「Extensible Markup Language (XML) 1.0 (Third Edition)」(英語)を参照し、その日本語訳として、日本工業規格 JIS X 4159:2002(Second Edition相当。リンク先は該当規格の原案ですが、最終版とほぼ同等の内容です)と追補1として出版予定の原稿(Third Edition対応)を参照しています。本文中のピンクの地の部分は、XML 1.0勧告の原文を示しています。 |
とあるゲームに、「語ってもよろしいですかな?」というせりふが口癖の、学者風のおっとりした老人が登場する。彼は、世界のあちこちに出没してはゲームの背景にある古い歴史などを語ってくれるのだが、ともかく話が長い。当然、プレーヤーには「語ってください」「やめてください」といった選択肢が与えられる。ここで「やめてください」を選ぶと、老人は「つまらんのう」とがっかりした態度を見せる。さて、ここでは、これから記法宣言について語っていこうとしているわけだが、語り始めるに当たって頭に浮かんだのは、上のせりふだった。つまり、記法宣言あるいは記法に関する知識とは、かの老人が語るゲームの歴史と同程度の価値しかないということになる。単にゲームをクリアするためなら、老人の長い蘊蓄(うんちく)など聞く必要はない。それと同様に、XMLを使ううえで記法の説明を読む必要性はほとんどない。例えばXMLの入門記事を書く場合など、事実上「語ってもよろしいですかな?」の同義語となる「本章は読み飛ばしても構わない」という言葉を記法に関する章に書くことになる。
しかし、本連載の場合は少々事情が異なる。本連載の目的は、XMLを使えるようになることではない。XML 1.0勧告を読むことにある。であるならば、そこに書かれた文字にはひととおり目を通す必要がある。それが、使われる可能性が極めて低い記述であっても、である。とはいえ、義務感で嫌々読むしかない、と思い込むのは好ましいことではない。だれかがぜひとも語らねばならないと思っていることには、たとえ使われる頻度が低くても、何かの理由、何かの主張が秘められているかもしれない。それを実際に自分の目で確かめるために読んでみたいと思うことは、好奇心を持つ生き物である人間であれば、決して間違いではないだろう。
そのような前提であえて読者のあなたに記法宣言について問おう。
「語ってもよろしいですかな?」
では早速「4.7 Notation Declarations(4.7 記法宣言)」を読み始めよう。この連載で何回も出現した記法(Notation)を宣言する構文についての話題が、ようやくここに出てくる。期待して待っていた方々(がいるのかどうかは分からないが)、お待たせした。ついにたぐいまれなる高い機能性を持ちつつ使われることがほとんどない記法、それを宣言する構文を知ることができるのである。
最初の段落は、記法(Notation)という用語の定義である。
[Definition: Notations identify by name the format of unparsed entities, the format of elements which bear a notation attribute, or the application to which a processing instruction is addressed.] |
[定義:記法は、解析対象外実体の形式、記法属性を持つ要素の形式または処理命令の対象とする応用プログラムを特定する名前とする。] |
ここには、記法が具体的に3つに分類されて示されている。それぞれを順に見ていこう。まず、「解析対象外実体の形式」である。解析対象外実体を宣言する際、これは、実体を宣言する際にNDATAキーワードを使う構文の対象となることを意味する。この連載の第23回「実体宣言の概要と内部実体宣言」に出てきたものである。直接関係のある生成規則を再掲すると、以下がそれに当たる。
[76] NDataDecl ::= S 'NDATA' S Name |
ここで、Nameに当たる名前を宣言するのが記法宣言である。
次は、「記法属性を持つ要素の形式」である。これは、混乱する可能性のある表現である。記法型の属性が存在することは、すでに連載の第17回「属性の型、列挙型を理解する」で読んだ。しかし、記法型というのは属性の型であって、要素の型ではなかったのではないか。それなのに、どうしてここでは、「記法属性の形式」ではなく「記法属性を持つ要素の形式」というのだろうか。
いま一度、本連載第17回の「3.3.1 属性の型」を振り返ってみよう。そこには、以下のような文章があった。
記法属性は、その属性が付与されている要素を解釈するのに使用する記法を特定し、記法は、DTD内で宣言され、システム識別子および/または公開識別子に関連付けられる。 |
この文章の前半部をじっくりと見ていただきたい。記法属性は、属性を解釈するのに使用する記法を特定するわけではなく、その属性が付与されている要素を解釈するのに使用する記法を特定するために使うものなのである。つまり、対象はあくまで要素である。それ故に、上記の「記法属性を持つ要素の形式」という表現は正しいことになる。
「要素の形式(format of elements)」とは何だろうか。実はこの用語には、定義が存在しないし、具体的な使い方も提示されていない。その理由は、上記引用文の「要素を解釈するのに使用する記法」という個所に注目すれば分かるだろう。つまり、要素を解釈するのは記法、より正確には記法によって発動させられる何らかのプログラムであって、XMLプロセッサではない。XMLプロセッサの動作については、XML 1.0勧告で記述される必要があるが、その外側のプログラムのことには言及していないのは正当な態度である。
3つに分類された記法の最後は、「処理命令」である。これについては、連載の第8回「XML文書中の処理命令とCDATAセクション」で解説している。そこでは「XMLの記法機構を、PIのターゲットを宣言するために使用してもよい」と書かれていた。つまり、処理命令(PI)のターゲットは、記法宣言を用いてもよく、用いなくてもよいということになる。例えば、よく使われる以下のようなスタイルシートを指定する処理命令では、記法宣言は使われていない。
<?xml-stylesheet href="mystyle.css" type="text/css"?>
しかし、記法宣言を使ってターゲットを示してもよいということである。
さて、これらの3つに分類された記法の正体とは何だろうか。それは「対象とする応用プログラムを特定する名前」という文章から分かるとおり「名前」であり、その目的は「対象とする応用プログラムを特定する」ことである。とはいえ、具体的に応用プログラムを特定する手段については何も記述されていない。システム識別子や公開識別子の内容が示す意味は、XML 1.0勧告の世界の外側で規定されるものであり、さらにそれらの名前(識別子)からプログラムを特定する手順は、特定システムや特定ソフトウェアの実装に依存することが多いだろう。(次ページへ続く)
1/3 |
Index | |
やさしく読む「XML
1.0勧告」 第32回 記法宣言の全容と文書実体の特殊事情 |
|
Page 1 ・記法宣言と文書実体の概要 ・「語ってもよろしいですかな?」 ・記法宣言(Notation Declarations) |
|
Page
2 ・記法宣言の用語定義 ・記法宣言の生成規則 |
|
Page
3 ・記法宣言の妥当性制約 ・文書実体(Document Entity) |
連載 やさしく読む「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」の詳細も紹介する
|
|