2003年1月12日(日)更新

さらら: だいぶいろいろなXML Schemaの技術を学んできたけれど、実際にスキーマを作ろうと思ったら、結構、難しそうね。

たけち: そうだね。今まで学んできたもの、そしてこれからもしばらく学ばないといけないものは「こうしたい時にはどうしたらいいか」というXML Schemaのテクニックなんだよね。
でも、実際にスキーマを作ろうと思ったら、「この問題に対しては、どういうスキーマを作るべきか」という、XML Schemaを使う以前の大きな課題もあるから、また別にいろいろなことを考えないといけないんだよね。

さらら: う〜ん、大変そう。

たけち: でもねぇ。。

さらら: えっ?

たけち: そうだね。ここでスキーマを作る際の究極の奥義を、さららに教えとこうかな (^ ^)

さらら: え、なになに、スキーマを作る際の究極の奥義ってどんなの?

たけち: これはとても大事なことだからよく聞いてね。スキーマを作る際の究極の奥義とは...

さらら: えぇ、それは。。。

たけち: スキーマを作らないということ。

さらら: えっ?　.....ねぇ、たけちって私のことを馬鹿にしてない?(- -;)

たけち: あ、ごめん。別にそんな意味じゃないんだよ。確かにこの言葉には、逆説的なことを言って人を驚かせているようなところがあるけれど、ちゃんと真面目な意味がこめられているんだよ。例えば
「剣の道の究極の奥義とは、剣を使わずにすますことである」
　とかいうと、結構奥深い言葉になるよね。

さらら: まあそう言われればそうだけど・・・・・

たけち: スキーマを作る際の究極の奥義とは、スキーマを作らないことであるというは、下手な、自分だけが満足しているスキーマを濫造するのではなくて、先人の作った考え抜かれた上手なスキーマをなるべく再利用し、どうしても必要な部分だけ、自分でスキーマを作りなさい、といった意味なんだ。

さらら: あぁ。。。。なんとなくわかるわ。

たけち: 次のXMLデータを見てみようね。

たけち: そうだね。1番目の例は歌をあげてその解説をしている、いわゆる「解説」型のドキュメントだね。そして2番目は歌を並べている「歌集」型のドキュメントだね。そして最後の3番目は会話の中に歌が出てくる「会話」型のドキュメントになっているんだね。
「解説」と「歌集」と「会話」では、DTDが違ってきて当然だし、実際にそうなっているよね。でも、歌という共通点を持ち、そして歌の部分では同じDTDの構造を持っているわけだね。というところで、考えてみると、同じようなDTDを3回も新たに書くというのは無駄なことをしているように思えるよね。

さらら: そうね。無駄と言えば無駄よね。似たようなものや同じものを3回も書くというのは、ね。

たけち: さらにh1要素やp要素やem要素の定義を考えると、1番目に出てきたDTDの

<!ELEMENT h1 (#PCDATA)>

<!ELEMENT p (#PCDATA | em)*>
<!ELEMENT em (#PCDATA)>

たけち: 　という部分は、3番目に出てきたDTDの、

<!ENTITY % Inline "(#PCDATA | font | strong | em)*">
<!ENTITY % coreattrs
        "class          CDATA          #IMPLIED"
>
<!ENTITY % TextAlign "align (left|center|right|justify) #IMPLIED">
<!ELEMENT h1 %Inline;>
<!ATTLIST h1
        %coreattrs;
        %TextAlign;
>
<!ELEMENT p %Inline;>
<!ATTLIST p
        %coreattrs;
        %TextAlign;
> <!ELEMENT em %Inline;>
<!ATTLIST em %coreattrs;>

たけち: 　と実は同じなんだよね。3番目の方がより詳しい定義のしかたをしているので、一見別物に見えるけれど、この3番目のh1要素やp要素やem要素の定義の仕方で、1番目のXMLデータのh1要素やp要素やem要素を検証することも可能だよね。結局1番目も3番目も、少し違う形でXHTMLの真似をしているだけなんだね。

さらら: そう言われればそうだわね。

たけち: ここでは、3つの例を出したけれど、これからさらに歌にまつわる別のドキュメント構造が必要になればなるほど、一部が同じで一部が違うというDTDがどんどん増えていくことになるね。
これって効率が悪くて無駄が多いことだよね。特にh1要素やp要素やem要素なんかは、既にW3Cが定めたきちんとしたXHTMLのDTDがあるのに、それとは別に、それと似たようなDTDをいくつも書かないといけないなんて、特に無駄な気がするよね。

さらら: それは、そうだわ。とっても無駄なことをしているわね。

たけち: そう考えると、ほとんどその共通部分からできているたとえば2番目のDTDについては、これを共通部分を持っているDTDから参照したくなるよね。それからXHTML系要素について書いた部分についても、こんな偽物のXHTMLのDTDを何回も書くくらいだったら、本物のW3Cが定めたXHTMLのDTDを参照したいよね。

さらら: えぇ、それはそうだわね。でも、そんなことができるの? (^ ^;)

たけち: それが可能なんだよ。まずは実例を見てもらった方が早いよね。これをするにはまずXHTML系のDTDは、インターネット対応のDTDのパーサーがあればいいんだけれど、あまりそういうのがなさそうだから、
ここでは本物のXHTMLのDTDである
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
を、同じフォルダにxhtml1-transitional.dtdとしてダウンロードしておこうね。
さらにこれが必要としている
http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent
http://www.w3.org/TR/xhtml1/DTD/xhtml-symbol.ent
http://www.w3.org/TR/xhtml1/DTD/xhtml-special.ent
などについても、それぞれ同じフォルダにxhtml-lat1.ent, xhtml-symbol.ent, xhtml-special.entとしてダウンロードしておくことにするよ。

さらら: えぇ。

たけち: そうすると、1番目の例のDTDは次のように書くことができるんだよ。

※DTD例: 万葉歌と解説-1　他のDTDを参照
<!ENTITY % manyouPoem SYSTEM "manyouPoem.dtd">
%manyouPoem;
<!ENTITY % XHTML SYSTEM "xhtml1-transitional.dtd">
%XHTML;
<!ELEMENT document (h1, poem, kaisetsu)>
<!ELEMENT kaisetsu (%block;)*>

たけち: それから、3番目の例のDTDは、こう書くことができるんだよ。

※DTD例: 万葉歌と解説-3　他のDTDを参照
<!ENTITY % manyouPoem SYSTEM "manyouPoem.dtd">
%manyouPoem;
<!ENTITY % XHTML SYSTEM "xhtml1-transitional.dtd">
%XHTML;
<!ELEMENT document (%block; | poem)*>

たけち: さっきのDTDと比較してみるとわかるけれど、DTDが随分短くなったよね。(^ ^) こういうふうに、共通となる他のDTDを参照することによって、新たに書かなくても良くなったんだね。

さらら: そうね。本当に短くなっているわ。(^ ^)

たけち: 　ちなみにここに出てくる「%block;」というのは、xhtml1-transitional.dtd の中に出てくるけれど、

<!ENTITY % block
      "p | %heading; | div | %lists; | %blocktext; | isindex |fieldset | table">

　というもので、p要素だけでなくて、h1のようなheading系の要素、div要素、table要素等を含むものなんだ。だから、

<!ELEMENT document (%block; | poem)*>

　というのは、

<!ELEMENT document
    (p | %heading; | div | %lists; | %blocktext; | isindex |fieldset | table | poem)*>>

　　という意味になって、p要素やh1要素だけでなく、それ以外のこれらのXHTML系要素も使えるようになるんだね。

さらら: よくわからないけど、凄〜い! あんなに長かったDTDがこんなに短くまとまった上に、さらに複雑なことができるDTDになっているのね! これだと完璧ね!(^ ^)

たけち: そう、確かに凄く綺麗に簡潔になったよね。まあもっとも、実は完璧じゃなくて、大きな問題点もあるんだけどね...(^ ^;)

さらら: あらま　(^ ^;)

たけち: 確かに素晴らしいテクニックなんだけれど、このテクニックをDTDで利用する際の問題点は、
参照する側のDTDでは、参照される側のDTDの中で定義されているのと同じ名前の要素の要素型宣言が出現してはならない。また参照されるDTDが複数あるとき、それらの中に同じ名前の要素の要素型宣言が存在してはならない
　ということなんだ。
例えば参照される「manyouPoem.dtd」の方にはyomi要素が要素型宣言されているよね。ということは、参照する側のDTDでは、また別のyomiという名前の要素の要素型宣言はできないんだ。
つまり、まず最初に参照される外部DTDにどんな要素があるか全て知った上でないと、スキーマを決めることができないということだね。
例え参照される外部DTDの要素の一部しか使わなくてもね。さらに言うと、上記のように複数のDTDを参照したい場合、それらの中に名前が同じ要素の要素型宣言が出てくると、例えそれらが同じ定義であっても、そしてそれらを使わなくても、エラーになってしまうんだね。
例えばXHTMLにはtitleという名前の要素があるけれど、これにもし「manyouPoem.dtd」の方にもtitleという名前の要素型宣言があったら、それだけでエラーになってしまうんだ。ということは、別々の人が作ったDTDをいろいろと組み合わせて使いたいとき、当然、同じ名前の要素が出てくる可能性があるから、そうなったらもうその組み合わせは使えないんだよね。

さらら: う〜ん、それは困るわ。

たけち: この問題を解決するためには、要するに、皆それぞれが作るスキーマの要素名が、全部違っていればいいんだよね。つまりそれぞれの人が作る要素の名前の衝突が起きなければうまくいくんだ。

さらら: え、そんなことができるの?

たけち: うん、それじゃあ次回は本格的に「名前空間」について話すことにするね。

さらら: あっ、は〜い!!

次回は名前空間とスキーマ(2)です。...... (^ ^)v