Tweet

■XMLとSGML、そして実体参照および文字参照の展開

主な内容 --Page 1-- XMLとSGML、そして実体参照および文字参照の展開 XMLとSGMLの関係 --Page 2-- 実体参照および文字参照の展開 実体参照および文字参照の展開のサンプル1 --Page 3-- 実体参照および文字参照の展開のサンプル2

　前回は「B Character Classes（附属書B（規定）文字クラス）」を読んだ。ここは、XMLの利用者であればだれでも関係ある名前文字の種類を規定していた。つまり、要素や属性の名前に使用してよい文字と、使用してはならない文字の区別を具体的に規定している部分であった。しかし、これは単なる文字の表ではなく、Unicodeの文字データベースと深いかかわりがある。それらについて、解説を行った。

　さて、今回は「C XML and SGML（Non-Normative）」と「D Expansion of Entity and Character References（Non-Normative）」を読んでいこう。JIS X 4159では「附属書C（参考）XMLおよびSGML」と「附属書D（参考）実体参照および文字参照の展開」である。前者は、XMLとSGMLの関係について記述されている。どちらかといえば好奇心で見るべき文書であり、歴史の一端を垣間見るのに有用だろう。逆に後者は、生々しい現在進行形のXMLのディープな領域を正しく理解するのに有益だろう。もちろん、ここまでDTDやパラメタ実体を含む参照を活用する利用者は多くないかもしれない。しかし、ある種のXMLの応用は、間違いなくこれらのディープな参照の挙動を活用して行われている。もちろん、ここに書かれているのは、規定ではなく、分かりやすくするための例にすぎない。しかし、それを見ることで、より深い正しい理解に到達する助けになるものであり、大変に有益である。

■XMLとSGMLの関係

　さて、「C XML and SGML（Non-Normative）」、JIS X 4159では「附属書C（参考）XMLおよびSGML」となる部分を読んでいこう。中身は1段落しかないし、内容もNon-Normative＝参考であり、規定ではない。気楽に読んでしまおう。

　よくいわれることだが、XMLはSGMLのサブセットである。それ故に、すべてのXML文書は、SGML文書にもなるということである。こう書くと単純な話に思えるかもしれないが、実はそうでもない。何も考えずにさらさらと書いたXML文書を、ただ単にSGMLプロセッサに入れて、それが必ず確実に処理されるのかというと、そうではないからだ。そのことは、次の文章が示している。「SGMLが文書に課す制限」のほかに「XMLが文書に課す制限」が存在することが示されている。詳細は［Clark］に書かれているというが、［Clark］とは、第34回「XML勧告を理解するために必要な外部の文書」に紹介した参考文献の中の以下を示している。

Clark

James Clark. Comparison of SGML and XML.(See http://www.w3.org/TR/NOTE-sgml-xml-971215.)

　［Clark］という表記は、文書を示すために著者の名前（もちろんJames ClarkのClarkである）を使用している。このような表記を見慣れていない人は、文書をタイトルではなく著者名で示すことを奇異に感じるかもしれないが、論文などの分野ではこのような表記が一般的である。

　さて、この文書をまじめに読む必要があるだろうか？　答えはノーである。なぜなら、いま読んでいる「C XML and SGML（Non-Normative）」は、Non-Normativeつまり参考であって、規定ではないからだ。XML勧告は、まったくSGMLに依存しない形で定義されており、SGMLとどう異なっているかを知ることは、XML勧告を正しく把握するために必要ではない。また、ほとんどの利用者にとって、SGMLとは（HTMLを使う場合を除き）利用する機会が極めて少ない言語であるために、XMLとSGMLの差を知りたいという欲求もめったに起こらないだろう。しかし、好奇心を持ってちらっと見ておく価値はあるかもしれない。好奇心を持つことは、健全なる精神の発露である。たまに猫を殺すことはあるにせよ（「好奇心猫を殺す」ということわざ）、健全な人間なら殺されることもあるまい。

　ではざっと『Comparison of SGML and XML』を見てみよう。この文書は3つの章に分かれている。最初の「1. Differences Between XML and SGML」は、文字どおりXMLとSGMLの相違（Differences）を列挙している。次の「2. Transforming SGML to XML」は、SGML文書をXML文書に機械的に変換するためのルールを示している。最後の「3. SGML Declaration for XML」は、XML文書をSGMLプロセッサで扱うためのSGML宣言（SGML Declaration）が2種類掲載されている。

　さて、ここで最後のSGML宣言に注目しておこう。SGML宣言とは、XML宣言と名前が似ているが、中身はまったくの別物である。SGMLはXMLと異なり、非常に多くのカスタマイズ可能な項目を持っている。これらの項目をどのように定義して使用するかを宣言するのがSGML宣言である。これが、例えば以下のような問題に対処するために使用されている。

　XMLでは空要素タグを以下のように記述する。

<elementName />

　しかし、空要素タグを「/>」で閉じるのはXML固有の流儀であって、一般的なSGML文書では、以下のように記述する。

<elementName>

　一見して両者が互換であるとは、とても信じられない。筆者も、最初はそう思い、悩んでしまった。しかし、SGML宣言の書き方次第では、SGMLプロセッサはXML流儀の空要素タグを受け入れることができるのである。

　具体的にいえば、1つ目のSGML宣言では以下の行がそれをカスタマイズしている。

NET "/>"

　2つ目のSGML宣言では以下の行がそれをカスタマイズしている。

NESTC "/"

　ここから分かることは、XML文書をSGMLプロセッサで扱うためには、そのために定義されたSGML宣言を必要とするということである。つまり、XMLはSGMLのサブセットであるという話を単純に信じ込み、XML文書をただ単にSGMLプロセッサに入れても期待どおりには処理されない。それを処理させるには、SGML宣言が必要とされるわけである。

　このことは、XMLとSGMLの関係について、いろいろと考える切っ掛けになるだろう。XMLとSGMLの関係は、決して単純なサブセット／スーパーセットの関係ではない。言葉のうえでサブセットであると書かれていても、サブセットという言葉から受ける印象と実際は異なっているかもしれない。

　そして、確実な根拠がない想像にすぎない、という前提さえ踏まえるなら、この状況からXMLを作り出した者たちの心情を推測することもできるだろう。XMLはSGMLを素直に縮小したサブセットではないが、素直に縮小しなかったのはなぜだろうか。もしかしたら、彼らはSGMLを肯定などしておらず、もっと別の理想像を持っていたのではないだろうか。それにもかかわらず、なぜSGMLのサブセットなのだろうか。

　その理由は、XMLプロセッサが世の中に1つもない状況でXML勧告が書かれたという状況を考えると見えてくるかもしれない。つまり、彼らは新しい言語を使いたかったのだが、いくら仕様を公開したとしても、だれもそれを実装してくれないかもしれない、という不安を抱いていた可能性が考えられる。しかし、SGMLプロセッサで処理できるような仕様にしておけば、すでに世の中にいくつもあるSGMLプロセッサで新しい言語の文書も扱えるわけで安心である。もしも、このような理由でXMLがSGMLのサブセットになったとすれば、要するにSGMLプロセッサで処理できればよいわけで、そのために多くの制約を課すこと（＝単純なサブセットにならないこと）は、リーズナブルな解決策といえるだろう。

　もちろん、このような解釈は根拠のあるものではないが、たまには頭を使っていろいろと理由を考えてみることも悪くないだろう。（次ページへ続く）

1/3

Index
やさしく読む「XML 1.0勧告」 第36回 XMLとSGMLはどこが違うのか
	Page 1 ・XMLとSGML、そして実体参照および文字参照の展開 ・XMLとSGMLの関係
	Page 2 ・実体参照および文字参照の展開 ・実体参照および文字参照の展開のサンプル1
	Page 3 ・実体参照および文字参照の展開のサンプル2

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

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