Tweet

■記法宣言の妥当性制約

　さて、次は「妥当性制約：Unique Notation Name（記法名の一意性）」である。

　これは当たり前のにようにも見えるが、XML 1.0勧告においては当たり前ではないことに注意が必要である。例えば、実体宣言は同じ名前の実体宣言の重複が許されていて、重複した場合の優先順位も決まっている。これにより、既存DTDの宣言を上書きしてカスタマイズするというテクニックはこの連載でも紹介した。しかし、記法宣言はそれとは異なり、重複は許されず、既存のDTDの宣言をカスタマイズすることもできないことになる。

　次は、記法宣言についての説明が続く。

　冒頭の文章は、XMLプロセッサが行わねばならない動作について述べている。XMLプロセッサは、記法の名前および外部識別子を応用プログラム渡さなければならないのである。しかし、対象は限定されている。「属性値・属性定義・実体宣言で参照されているすべての記法」というのは「すべて」という言葉を含むことから「すべての記法か」という印象を与えるかもしれない。しかし、実際には「参照されているすべて」であって、参照されていない記法についての情報を渡す義務は存在しない。

　次の文章は、してもよい（MAY）という文章であり、任意選択であることを示す。さて、ここで棚上げにした「XMLプロセッサが外部識別子からプログラムを探すということが妥当なのだろうか」という疑問に戻ろう。この規定により、XMLプロセッサは応用プログラムが起動するために必要な情報を生成する役割を持ってもよいことになる。その場合、「XMLプロセッサが外部識別子からプログラムを探す」という作業を行うことになる。故に、上記の疑問の答えはYESとなる。もし、この規定を実現するには、外部識別子からプログラムを探す作業を行うことになる。もちろん、これは任意選択であるから、行うことは義務ではない。

　最後の文章では、これまでの説明から分かるとおり、ある記法が利用できるかどうかは、使用するソフトウェアやシステムや環境に依存することになる。もし、利用できない記法を使用したXML文書があるとした場合、それを誤りと見なすか、見なさないかには重大な意味がある。見なすとすれば、記法の利用は非常に窮屈なものになる。単に記法が利用できないというだけで、記法とは関係ない情報を知るためにXML文書を解析することができなくなってしまうからである。しかし、実際にはエラーとはしないというこの規定により、そのような状況は回避されている。

　これで、「4.7 Notation Declarations（4.7 記法宣言）」は終わりである。

■文書実体（Document Entity）

　さて、長く続いた「4 Physical Structures（4 物理構造）」もついに最後の「4.8 Document Entity（4.8 文書実体）」に到達した。これは非常に短いので、あと一息で「4 Physical Structures（4 物理構造）」を読み終えることができる。一気に読み切って、達成感を味わおう。

　それはさておき、文書実体とはXML文書に必ず含まれる最も重要な実体である。それにもかかわらず、わずか1段落で終わってしまうというのはなぜだろうか。その理由は、文書実体も実体の一種であるという理由による。つまり、これまで実体について膨大な言葉を費やして規定してきたことの多くが、文書実体の規定として機能するということである。そして、文書実体だけに適用される特殊事情だけを記した個所が、この「4.8 Document Entity（4.8 文書実体）」というわけである。

　では早速読んでいこう。

　最初の文は、Document Entity（文書実体）という用語の定義である。ここでいう木構造は、ドキュメントオブジェクトモデル（DOM）のツリーではなく、実体の構造を示していることに注意が必要である。実体はほかの実体を参照できるので、ほかの実体の参照を枝としてイメージするなら、木に例えることができる。そして、文書実体がすべての枝の大本となる幹になる。そして、この文書実体がXMLプロセッサが処理を開始する対象であると限定している。つまり、XMLプロセッサは、文書実体以外の実体を相手に作業を開始してはならない。

　もっとも、特定の実体を加工するようなプログラムを開発することは可能であるし、そのプログラムは文書実体以外の実体から処理を始めることになるだろう。このようなプログラムがあって悪いわけではない。ただ、それはXML 1.0勧告が定める意味でXMLプロセッサとは呼べないというだけである。これで用語定義は終わる。

　次は、文書実体の重要な特徴を記している。つまり、文書実体は名なしであるということである。ほかの実体は、すべて参照するための名前を与えられているが、文書実体には名前がない。いや、ファイルに保存したときのファイル名があるという人がいるかもしれないが、それはファイルの名前であって、文書実体の名前ではない。

　さて、名前がないことがそれほど価値あることなのだろうか。もちろん大きな価値がある。それは、名前を持たない手段を使って入力可能であるからだ。一般のパソコン利用者からすれば、何らかの情報を入力する対象を指定する方法として思い浮かべるのは、ファイル名を指定したり、URIを指定する行為だろう。ファイル名もURIも広い意味で名前の一種といえる。しかし、少しパソコンのシステムの奥に入ると、名前のない手段があちこちに存在することが分かるだろう。

　例えば、プログラムとプログラムが通信する手段として、パイプという機能がある。Linuxなどのシェル上で、「sort a.txt|head」と入力すれば、ファイルa.txtを行単位でソートし、その結果の先頭部分の行だけを出力する。ここで、「sort a.txt」がファイルa.txtを行単位でソートする機能を示し、「head」が結果の先頭部分の行だけを抜き出す機能を示す。そして、2つの中間にある「|」記号がパイプを使うことを示している。この場合、ソートの対象となるファイルは、a.txtとして名前を持っている。しかし、「head」がパイプから受け取るデータには名前がない。もちろんこのパイプはファイルではないから、ファイル名も付いていない。つまり名なしである。しかし、この名なしのデータは非常に便利であり、根強い利用愛好家が多く存在する。そして、文書実体には名前がないというこの規定により、文書実体をパイプで利用することがスムーズに可能となる。

　このような名なしの事例はほかにもいくらでもある。例えば、XMLプロセッサが入力を通信ポートのようなデバイス経由で受け取ることを考えてみよう。その場合、通信ポートには名前が付いているかもしれないが、受け取るデータそのものに名前が付いているとは限らない。無手順通信でただ文字だけが流れてくるようなシステムなら、名前などない方が多いだろう。文書実体は名なしであるので、そのようなシステムで受け渡すことに何の問題もない。

◇

　さて、これで「4.8 Document Entity（4.8 文書実体）」を読み終わるとともに、「4 Physical Structures（4 物理構造）」もついに読み終えた。お付き合いいただき、お疲れさまである。XML 1.0勧告最大の山場はこれで乗り越えたことになる。

　次回は、「5 Conformance（5 適合性）」を読んでいく。適合性とは、XML 1.0勧告に適合していると主張するために満たさねばならない条件である。例えば、XMLを使うプログラムを作りました、というのは簡単なのだが、厳密な意味でXML 1.0勧告に適合したプログラムを作りました、というのはなかなか難しい。また、利用する側から見て、どこまでがXMLとして期待してよい範囲で、どこまでがそうではないのかという境界を見極めるためにも有益である。XMLへの適合性について理解するためにも、ぜひ読んでいこう。（次回に続く）

3/3

Index
やさしく読む「XML 1.0勧告」 第32回 記法宣言の全容と文書実体の特殊事情
	Page 1 ・記法宣言と文書実体の概要 ・「語ってもよろしいですかな?」 ・記法宣言（Notation Declarations）
	Page 2 ・記法宣言の用語定義 ・記法宣言の生成規則
	Page 3 ・記法宣言の妥当性制約 ・文書実体（Document Entity）

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

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