デベロッパーズコーナー：エンジニアのためのXMLスキーマ講座 ＩＩＩ（1）

エンジニアのためのXMLスキーマ講座
第３回：XMLの標準スキーマ表現　DTDを「書く」

XMLのスキーマ表現の標準ともいえるDTDを構成する４つの部分を詳しく解説します。実際にDTDを「読む」ことができるようになるのが目標です。

前回のこの記事ではもっとも一般的に利用されているスキーマ定義であるDTDについて、それを構成する４つの宣言を詳しく検証することが出来ました。みなさんも、もうDTDを「読む」ことができるようになったことでしょう。

では今回は実際に、DTD作成の手順をステップごとに学んでいきたいと思います。DTDを「書けるようになる」という目標を持ってこの記事を読み進めてください。

さっそくDTDを作成していきたいところですが、その前にぜひ考えたいことがあります。

それは「本当にDTDを作成する必要があるのだろうか？」ということです。つまり、既存のDTDを流用できないかどうかをまず検討すべきだということです。

結論から言えば前回も述べたとおり、自分で一からDTDを作成するよりも、できることなら既存のDTDを流用する方が良いといえます。

良いスキーマ（DTD）を自分で作成するのは非常に難しいことです。またすでに公開されていて自由に流用できる各分野のDTDが数多く存在しています。それらのDTDを改変することが可能であるならば、そのDTDに手を加えて利用すればよいのです。以下に、利用できるDTDを公開しているサイトを幾つかあげておきます。

• http://www.xml.com/pub/rg/DTDs
• http://xml.org/registry/index.shtml
• http://www.antenna.co.jp/XML/fr-dtd.htm

このように考えると、DTDを一から作るということにこだわる理由がまったく無いということが理解できます。

しかし現実にはどうしてもDTDを最初から作らなくてはならない場合もあるでしょう。また既存のDTDに手を入れるとしても、書き方が分からなくては話になりませんから、そのような場合でもDTDを書く手順を知っておくことは有益です。

実際にDTDを書いていく上でよく注意しなければならないことがあります。それは「人間にとっても読みやすいDTDを書く」ということです。DTDはシステムが処理できればそれでよい、というものではありません。

例えば、DTDに沿った文書インスタンスを記述するのに、そのDTDを見ながら書いていく必要がある場合があります。また、プログラマはDTDを読んで構造を分析し、必要なシステムを構築していきます。場合によっては後でDTDを拡張しなければならない場合もありますが、そのような時にも読みやすいDTDであれば作業が比較的に容易にすすめられます。

読みやすいDTDにするためにはどんなことに気をつけるべきでしょうか。例えばエンティティの名前は、そのエンティティが意味しているものが直感的に分かるものであることが望ましいでしょう。要素の名前や属性名、記法名にも同じことが言えます。

また要素型宣言を書く順番も関係するかもしれません。構造の最上位の要素を最初に宣言し、その要素の子要素を次に宣言する、というような順番で書いていくように心がける必要があります。

ではこれらの点を念頭において、これからDTDの「書き方」について考えていきましょう。実際にひとつのサンプルデータを使用して、データの分析からDTDの記述までの作業の流れを次のようなステップに分けて考えていきます。

• STEP1：データを集める
• STEP2：要素を洗い出す
• STEP3：要素をグループ化する
• STEP4：エンティティ宣言、記法宣言を記述する
• STEP5：要素型宣言を記述する
• STEP6：属性リスト宣言を記述する

関連サービス