さて人間がXML文書を作る場合、このように人間に分かりやすい、文章化された規定があればそれで済む。しかしそうして作られたXML文書が、スキーマにそって正しく記述されているかを検証するためには、人間にとって分かる(読める)だけではなく、コンピュータが理解できるかも重要になる。そのために用意されたのが「DTD」という形式のスキーマ言語だ。
XML文書の検証は、大きく2つの種類に分けられる。1つは「タグがきちんと記述されているか」、「開始タグと終了タグの対応がとれているか」など、XMLの規格に適合しているかどうかだけを検証する「Well-formed」、2つ目はタグと属性の名前や文書の構造までを検証する「Valid」だ。well-formedはXMLの規格に合っているかどうかのチェックだけで、タグや属性の名前が正しいか(そのソフトウェアが期待するXMLかどうか)までは検証しない。それを検証するのがValidで、こちらはDTDを利用してより細かなチェックを行なう。もしタグの名前などがDTDで規定されているものと違っていれば、そのXML文書はwell-formedなXML文書(つまり、XMLの規格には適合している)でも、エラーが通知される。このようにDTDは、厳密にXML文書を検証したい場面で利用される。
しかしDTDには弱点がある。なかでもユーザーの不満が大きかったのが、“データ型”の指定ができないという点だ。たとえば書籍の詳細なデータを表わすXML文書のなかで、<ページ数>というタグを使って総ページ数を数値で表わしたいといった場合、DTDではそのタグが現われる場所や、名前が正しいかどうかしかチェックできない。つまり<ページ数>128</ページ数>でも<ページ数>abc</ページ数>でも、DTDの上ではどちらも間違いではない。しかし数値が現われるはずの<ページ数>というタグのなかに、数値以外の文字が現われた場合はエラーとなれば、エラーチェックの精度は高められる。こうした理由で、タグや属性の値のデータ型まで指定できるスキーマ言語が待ち望まれていた。
こうしたDTDの弱点をカバーするスキーマ言語として、XMLを定めた総本山であるW3Cによって考えられていたのが「XML Schema」である。DTDとは異なり、タグや属性の値の型まで規定することができるため、XML中に<ページ数>abc</ページ数>という記述があった場合はエラーにする、といったことが可能だ。このようにXML SchemaはDTDよりも強力にXMLをチェックすることができ、今後はXML Schemaを使ってXMLをチェックするという場面は増えてくるだろう。ただ難点は規格があまりにも大きく、そして難しいということだ。規格が「Part1」と「Part2」に分かれており、さらに入門編ともいえる「Part0」が公開されていることからもその難度が想像できるだろう。次回もこのXML Schemaについて解説したい。
