今からでも遅くない　W3C XML Schemaを学ぼう！（前編）
難しいという固定観念を取り払う

W3C XML Schema

　XMLに詳しくない方でもXMLスキーマという言葉は耳にされていることでしょう。ただし「W3C XML Schema」と「W3C」を付けているのはなぜでしょうか？ ウィキペディアで調べるとXML Schema（当記事でのW3C XML Schemaのこと）には「XML Schema（XMLスキーマ）は、XML文書の論理的構造を定義するために開発されたスキーマ言語の1つ」とあります。この言葉どおり、W3C XML SchemaはXMLスキーマの1つです。他にはDTDやRelax NGなどのスキーマが存在します。

　次に「論理的構造を定義する」とは何のことでしょうか。最近はWebアプリケーションサーバやその他のミドルウェアをはじめ、その設定ファイルがXMLであることがほとんどです。そのような時「このパラメータは必須なのだろうか？」「このパラメータは複数指定してもよいのだろうか？」と悩まれたことでしょう。

　このように、XMLのこの要素は必須なのかオプションなのか、繰り返し可能なのかを示すための文書がXMLスキーマです。分かりやすく言うと、XMLスキーマはXML文書の文法書です。従って、XMLスキーマと照らし合わせ、XML文書が正しいかどうかを検査することが可能となります（正しいかどうかの検証を妥当性検証と呼びます）。XMLを扱うプログラムで細かいところまでチェックするのは現実的ではありません。XMLを扱う場合なくてはならないものと言えます。

環境構築

　今回の連載はW3C XML Schemaの説明ですが、次の連載としてJAX-WSを予定しています。SOAPやWSDLを使ってWebサービスを説明する予定です。JAXBについても触れる予定ですが、ここで避けて通れないのがW3C XML Schemaです。TomcatとApaceh CXFという組み合わせでもJAX-WSを利用することは簡単ですが、今回は構築に目的を置いていません。

　筆者が学習という観点からおすすめするのは、アプリケーションサーバとしてはGlassFish、開発環境としてはGlassFishが扱いやすいNetBeansです。最近はGlassFishもEclipseで扱えるようになりましたが、今のところNetBeansに分があるように思えます。お好みの環境で当連載のサンプルコードを利用されるのも結構ですが、説明自体はNetBeansを使用することから、この際NetBeansを覚えるのもいいかと思います。Javaの世界に限って考えると、Eclipseだけでは十分とは言えず、NetBeansを使いこなせてほとんどの領域をカバーできるというのが筆者の感想です。筆者も仕事ではEclipse、自宅で実験するのにNetBeansを使用しています。

　GlassFishはv2.1を、NetBeansは6.7.1を使用します。インストールの仕方についてはGlassFishからアプローチするJava～入門編～第1回「GlassFishとNetBeansのインストール」を参照ください。Eclipseに習熟された方は、Webアプリなどにも習熟されているかと思います。設定ファイルなど適宜置き換えていただければと思います。

W3C XML Schemaを説明する理由

　XMLスキーマにはDTDやRelax NGなどが存在するにも関わらず、なぜW3C XML Schemaをあえて説明しようとしているのでしょうか。

DTDではない理由

　DTDは、W3C XML Schemaができる前はよく使用されていましたが、次のような理由があり、より厳密な検査ができないという理由から使用されないようになりました。

名前空間がサポートされていない

　XML文書の最上位要素でxmlns:k1="http://kawakubo.jp/xmlsamples"と宣言されているのを見たことがあるかと思います。この宣言のことを名前空間宣言と呼びます。このうち"http://kawakubo.jp/xmlsamples"を名前空間、k1を接頭辞（正確には名前空間接頭辞）と呼びます。XML文書内で<k1:name>のように指定することで、他の文脈で使用されているname要素と区別できます。

　DTDはこのような仕組みを持っていないため、AというスキーマとBというスキーマにname要素が存在すると区別できなくなり、スキーマの再利用ができなくなるという欠点があります。

データ型という概念がない

　これは小さなことのように思えますが、要素や属性の値がどのような型であるかを示せないのは致命的とも言えます。後の連載でWebサービスを説明しますが、アプリケーション間のメッセージとなるXMLの要素や属性の型を示すことができなければ、アプリケーションからXMLへ、XMLからアプリケーションへ値を変換する場合、要素のテキスト内容をアプリケーションのどの型に変換すべきか、あるいはアプリケーションの型をXML要素のテキスト内容でどのように表現すべきか判別できなくなります（厳密にはDTDの属性にはデータ型が存在しますが、W3C XML Schemaほど豊富なデータ型ではありません）。

XMLではない

　DTDスキーマ文書自体がXML文書ではありません。つまり、XMLであることの恩恵を受けることができません。

　他にも理由がありますが、XML誕生当初からは想像もつかないくらいXMLがIT全体に影響を持つようになってからはDTDでは対応できないことが明らかになり、徐々に使用されなくなりつつあります。

Relax NGではない理由

　Relax NGについては、後のIT技術に対応できなくなったからではありません。DTDの弱点であった名前空間、データ型などは当然のこととしてサポートしており、W3C XML Schemaよりも直感的に分かりやすい作りという点からすれば、Relax NGがXMLスキーマとして採用されるべきところですが、XML関連の仕様の多くがW3Cで標準化されていることから、たとえ優れたものでも存在感が薄れつつあるのは否めません。将来、その設計思想がW3C XML Schemaに大きく取りこまれることを望むのみです。