C# XmlResolver

プログラミング自習中。
設定ファイルをXML形式にしてある。で、データの読み出し時に形式チェックしなければ気持ち悪いのでDTDを書いた。まずはテストなので、インラインでXML文書に埋め込んだ。特に問題はなかった。
しかし、データファイルにデータ定義を書き込んでもほとんど意味はないので、データ定義をプログラム内に移してデータチェックしようと思った。だが調べてみると、DTDを読み込む方法は外部エンティティーを解決するためのXmlResolverのみであるらしい。
とりあえずXmlResolverの内容を確認するのだが・・・え?カスタム・リゾルバーでも「必ずファイルストリームを返す」というのはどういうことでしょう?プログラムに埋め込んだ内容を返すのにファイルストリームを作成するのはあまりに気持ち悪い。画像ファイル等を読み込むためとしか考えていないのだろう。*1
まぁ、MicrosoftXML Schema*2の策定に関わったメンバなので、XML Schemaを使うことしか考えていないのだろうが。この場合、データ型までチェックできるのでたしかにDTDよりスキーマの方が向いていたりする。でも、XML Schemaって、キーワードがいちいち長いので手で書く気になれないのが大問題。XMLの解説書を見ると、「記法を憶えなければいけないDTDよりも楽」とか書いてあるが、人間が書くものとは思えないあの内容を見るとDTDの方が遙かに簡単に思える。同じ論理を記述しようとしたときの文字数が圧倒的に多くなる。これに対する答としては「ツールを使ってかけ」ということなのであろう。幸い、以前調査用に使っていたXML Spyの旧版があるのでこれで書いて試すべきであろうか。
外道な方法としては、読み込んだXMLフラグメントの頭にインラインのDTDをくっつけるというのもあるが、納期に迫られているわけでもない演習中にそんな苦し紛れの方法をとるのもよくあるまい。
そういえば、Relax NGとかを取り扱うにはどうすればいいのだろうか?どこかからライブラリを引っ張ってくる必要があるのか。まぁ、そこまでやらなければならない予定はないのでとりあえずは忘れておこう。
ところで、XML Schemaについてのハテナの項目には「実装が大きすぎる」とか書かれてあったが、SGMLの実装に比べればかわいいものであろう(笑)

*1:相変わらずヘルプファイルの記述が古いので、最新版では変わっているのかも。オンラインのヘルプは反応が遅いのであんまり読む気になれない。

*2:XML Schemaというのは一般名詞でもあるので、特定のスキーマの名前になっているのもかなり気持ち悪い。実のところさほど使われていないような気がする。何しろ、文字実体参照を追加する構文がないため、XHTMLDTDで定義されているぐらいだ。「文書」としてのXMLには全く不向きなものである。逆に、データベースファイルのような用途のXMLを作成するのには向いているはずだが、私の興味はそういうところにないので永久に交わらない。