昨今では、データ記述フォーマットとしてXML（Extensible Markup Language）を利用するケースが多くなってきました。例えば「web.xml内の記述順を知る（サーブレット2.3）」でも紹介したJSP＆サーブレットに関連する標準的な設定ファイル「web.xml」（デプロイメント・ディスクリプタ）は、最も身近な一例です。
XMLは、「Extensible」というその名のとおり、自由にタグ（設定項目）を拡張できるという利点があります。しかし、当然のことながら、特定環境下での設定ファイルとして利用するケース、異なるシステム／アプリケーション間でデータを交換するようなケースでは、使えるタグの種類、登場する順番、階層関係などをあらかじめ規定しておく必要があります。さもなければ、システム／アプリケーションの側が正しくデータを解析することができないからです。
従来、データの妥当性を検証するには、アプリケーションがそれぞれのフォーマットに合わせて個別のロジックを用意する必要がありましたが、XMLを利用した場合、そのような必要はありません。DTD（Document Type Definition：文書型宣言）を利用することで、XML文書の構造（登場可能なタグの種類、階層構造、登場順など）をあらかじめ専用の形式で定義することができます。後は、XML文書とDTD文書とを結び付け、XMLパーサ（解析エンジン）に渡すだけで、自動的にパーサがデータの妥当性を検証してくれるというわけです。つまり、XML＋DTDを利用することで、アプリケーション側は「妥当性検証」などという本来のビジネスロジックとは関係ない部分をほとんど意識することなく、ロジックの記述に専念できます。
それでは、以下に具体的なコード例を挙げます。
解説
（1）XML文書とDTD文書とを用意する
ここでは、「ウェルカムページを設定する」でも使用した「web.xml」（サーブレット2.3対応）が、あらかじめ決められた仕様にのっとって記述されているかどうかを確認することにします。本TIPSではXML／DTDに関する詳細は割愛しますが、1点だけ以下の点を理解しておいてください。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
赤字部分がXML文書を特定のDTDに結び付けている部分です。ここでは、<web-app>要素配下の一連の文書が「http://java.sun.com/dtd/web-app_2_3.dtd」というURIで特定されたDTDのルールにのっとっているということを意味します。「http://java.sun.com/dtd/web-app_2_3.dtd」は、あらかじめ用意されたデプロイメント・ディスクリプタの文書型宣言です。
（2）Javaアプリケーションを用意する
XML／DTD文書の用意ができたところで、次にパーサによる解析を実行するためのJavaアプリケーションを作成してみましょう。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
上記のコードをコンパイルした後、コマンドプロンプトから実行するには、以下のように指定してください。なお、検証対象となるweb.xmlは、あらかじめCドライブの直下に配置しておくものとします。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
コード中でポイントとなるのは、赤字の個所です。SaxParserFactory#setValidatingメソッドでDTDによる妥当性検証の有効／無効を切り替えることができます。後はXMLReader#parseメソッドで解析処理を実行するだけです。処理過程で発生した検証エラーは、コマンドプロンプト上から確認することができます。例えば、以下は<welcome-list-file>要素の配下に誤った要素（ここでは<sample>要素）を追加した場合に返されるエラーの例です。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
なお、本TIPSではコード簡略化のために、パーサが提供するデフォルトのエラーハンドラを利用して出力を行っていますが、自分で明示的にエラーハンドラを定義することもできます。その方法については、後日公開予定の「XMLSchemaを使ったXMLファイルの妥当性検証を行う」で紹介する予定です。
Copyright © ITmedia, Inc. All Rights Reserved.