■
19日に決定…。残念ながら謎工さんとこの知財系会議とかぶってしまいました。（何が）
XmlSchemaValidatorを作っていると、XML Schemaのvalidationの何がStartTagOpenDerivで出来て、何がStartTagCloseDerivまで出来ないか、というのが分かるようになってくる。いくつか例を挙げると…
- パーティクルの検証はstart tagのうち要素名だけで分かる。
- identity constraintsはxs:elementに属し、そのうちのselectorは属性ではあり得ないので、要素名だけで分かる。
- 属性の出現可否はactual type definitionに依存するが、actual type definitionはxsi:typeという属性によって決定されるので、それぞれの属性は開始タグが閉じるまで検証することはできない。ただし、もしxsi:typeが属性として検証されないのであれば、それぞれの属性の出現時点で検証が可能。というか、そうあるべき。
- ID型属性は、他の属性とかぶるかもしれないのだけど、かぶったときにエラーとすればいいので、単体でも検証できる。（ただし、そのためにはそもそも属性の型を含むactual type definitionが、開始タグが閉じてからでなくても決定されている必要がある。）
で、この辺MSには「何がいつエラー捕捉されるのか」をドキュメントとしてしっかりまとめてほしいんだけど、まあ無理だろうなあ。だってこんなの実装依存だし。
めんどくさいね。RELAX NGならderivativeで一発しかもそれ自体がstate objectになっていて、しかも明確なのにね。
XmlSchemaValidatorでもう一つ今ひとつだなあと思うのは、XmlSchemaInfoがValidityなるプロパティをもっていること。validityは実験してみた感じ、開きタグが閉じた時点なんかでもValidと報告されてしまうことがあるようだけど、実際にはこれから得体の知れないchild itemsが出現するかもしれないのだから、NotKnownじゃないといけないはずなのだ。しかしそうするとValidだと分かるのはEndElementが来たときくらいであって、最後になって「良かったネー! validでした☆」とか言われても別に嬉しくも何ともないのである。そもそもNotKnownは、情報の足りないスキーマコンポーネントが出現した時に初めて使うべきものだと思うのだけど、いまいち使い道の無さそうな情報だ。
…というわけで、検証を行うための最低限の機能は全て実装完了。まともに動くかどうかはこれからのテスト次第。残りあと2週間弱。今年はボストンに合わせてクリスマス以降は休暇にしてやる（ｗ
…と書いて数時間後に基本部分はできた。includeやidentity constraintsなど一部を除いてちゃんとmono上では動く。ms.net上では知らへん。
