XML 2.0, sir?

XQueryが蒸発してしまった現在、残るXML 2.0の仕事なんてあんましない。とりあえず昨日ついうっかり買ってしまった古いUnderworldのbeaucoup fishを聴きながら、何でXML 2.0の仕事がそんなに魅力的でないのかを考えてみる：

strongly typed APIの型マッピングは、XQuery/XPath2 F&Oの仕様とは合っていない、XmlConvert並に中途半端な代物で、物の役に立つとはちょっと思えない。だからあまり現時点で積極的にこの辺を実装する気にはなれない。実装する気になったら、ほとんどはXmlValueConverterの肉体労働なので、大した問題だとは思っていない。

XmlSchemaInferenceは、簡単にできるものではないし、それなりの覚悟を決めてやっつけなければいけないけど、完全に独立した機能だし、そういうものは後回しにした方が得だ。誰か他の人がやってくれるかもしれないし。

XmlReaderSettingsとXmlWriterSettingsのサポートの仕事はまだ残っている。でも、このクラスは今回のアップデートでだいぶ様変わりしたし、次のアップデートでも大幅に変わらないという見込みは全くない。どっちにしろ機能の大半は実装されているんだから、今さらに進めるまでもない。

XmlTextReaderがエンティティ解析をサポートする機能は、比較的いまやっつける仕事としてはイイ感じだ。しかもmonoには（MS.NETにも）関連するバグがある。ただ、実はいまやっているのはXmlTextReaderを何とかしてもうちょっと高速化しようという試みなのだけど、これがあんましはかどらない。とりあえずまだXmlTextReaderを内部で呼び出すような他のクラスの依存性を下げたりして、外堀を埋めている。

XmlSchemaValidatorは、MSDNドキュメントはまっちろで、何の情報も無いし、APIから見ても設計は自明ではない。まだ変更が生じないとは、ちょっと考えにくい。いま何かやるのはちょっと愚かしい気がする。それにこれも基本的には独立した部品だろう、という気がしている。XsdValidatingReaderで使うかもしれないが。

XslCompiledTransform。コレ、mono 2.0までにやるってのはけっこう無理がある気がするんだけど。API的には完全に無視して良い代物だ。しかしMicrosoft開発者はつくづくセンスが悪い。XslTransformは機能をあらわすクラス名で、XslCompiledTransformは実装の詳細を露出させるクラス名、つまりblahImplクラスみたいなものだ。XslCompiledTransformを使わせるためにXslTransformをobsoleteにするのが、真っ当な感覚だと言えるだろうか？