前回、XMLではなぜDTDが必要でどういったメリットが得られるのか、それがXML Schemaに変わることでどういったメリットが得られるのかを解説した。今回はXMLを扱うプログラム側から、XML Schemaという規格を眺めてみたい。
プログラマの負担を減らすXML Schema
まず、XMLを扱うプログラムの基本的な構造から解説しよう。XMLを扱うプログラムの大半は、「パーサ」と呼ばれるXML処理エンジンを用いている。これはプログラムとXMLの仲介のようなことをするソフトウェアの部品で、プログラムはこれを組み込むことによって、比較的容易にXMLに対応できる。パーサが行なう仕事の1つは、読み込んだXMLをプログラムからアクセスする手段を提供することだ。つまり、データを読み込みたい、あるいは書き出したいといったときに、パーサが提供する機能をプログラムが利用するわけだ。なお、W3Cでは「DOM」と呼ばれる規格を勧告しているが、これはこのアクセス手段を定義したもの。DOMに対応するパーサを組み込んでいれば、標準的な方法を使ってXMLにアクセスできる。
そしてもう1つ、パーサの持つ大きな役割になっているのが、読み込んだXMLを検証することである。
XMLを読み込んだときに、それがXML規格に適合していなければエラーとして通知する必要がある。パーサはこうした作業もプログラムに代わって行なってくれる。なお、前回解説したように、XMLの検証にはXML規格に適合している「well-formed」と、タグや属性の名前、出現する順番などが指定されたDTDどおりになっている「Valid」の2種類があるが、パーサもwell-formedかどうかだけを検証するもの、DTDを読み込んでValidかどうかまで調べてくれるものと、大きく2つの種類に分けられる(なお、DTDの検証のみを行なうバリデータというソフトウェアモジュールもある)。
こうした検証をパーサが行なってくれることによって得られるメリットは、XMLの検証のためのコードを書く必要がなくなるという点。何らかのデータを読み書きするプログラムを作成する際、そのデータが正しいかどうかをチェックする機構というのは必ず必要になる。必ず正しいデータであると仮定して作られたプログラムで、もし期待するデータの構造と違っていると、データを読み込めないというだけでなく、最悪その環境のいっさいの動作を止めてしまう重大なエラーが発生する可能性が出てしまう。そのため、データが正しくなかった場合のエラー処理のための機能も必要になってくるわけだ。ただ、単純なデータ構造であればデータが正しいかどうかのチェックは容易に行なえるが、複雑になってくるとそれに合わせてエラーチェックのためのコードも大量になってくる。
プログラムが独自の構造で表わされたデータを扱う場合、こうしたエラーチェックのための機能が必要になってくる。しかしXMLの場合、基本的な構文はXMLの規格によって定められており、それならばそれぞれのプログラムごとに正しいXMLかどうかをチェックするための機能を用意するのは無駄だろう。共通で利用できるモジュールを用意しておき、検証はその部分で行なうことにすれば、プログラマが記述する必要のあるコードの量を減らすことができる。well-formedかどうかをチェックするだけのパーサでも、それを利用してXMLを読み込むことによって、プログラム側ではwell-formedなXMLであると想定でき、XML規格に適合しているかどうかというチェックを行なう部分を省ける。
ただ、XML規格に適合していてもそのプログラムが想定しているXML文書とは異なる場合もある。たとえば要素や属性の名前が違う、現われる順番などといった構造が違うといった場合だ。well-formedかどうかの検証だけでは、これらの部分でエラーがあった場合に備える必要がある。ここまでサポートしてくれるのが、DTDのチェックまでの機能を持つパーサだ。スキーマ上の約束事をDTDとして用意し、それに適合しているかどうかの検証を行なってくれれば、こうした処理をプログラム側で行なう必要はない。
ただDTDを使ってチェックしても、要素の値までのチェックはできない。たとえば日付を表わす要素のなかに、日付とは関係のない数字や文字列が出現したのなら、XML規格やDTDのチェックは通っても、処理できないXMLとしてはじかなければならない。従来、こうした要素や属性の値が正しいかどうかというチェックは、パーサ部分では行なえず、プログラム側でのチェックが必要になっていた。つまり、パーサを使ってXMLの検証を行なっても、操作するXMLが正しいかどうかのチェックは必ず必要だったわけだ。
