ODP.NET or MS Oracle Client?
MSDNに比較記事が。MSDNのことだから、どうせ自社技術まんせーだろうと思って眺めてみたら、そんなことはない、これなら日本の.NETコミュニティの方がよっぽど提灯じゃないですか。仕事で両方いじってみたことがあるけど、そんなトリッキーなクライアントを作ってたわけでもなく、違いが生きる場面はせいぜいTAFのサポートくらいだったけど、Oracleの競合製品のプロバイダなんて…ってことでODP.NETにした覚えがある。
この記事の結論はつまり「VS.NETでdatasetをサクっと作ってから、ロジックはODP.NETで書くべし」っていうことだと思うんだけど、多分そんなこと実際にOracle + .NET開発した人なら誰だってやってると思う…。MS OracleClientじゃなくてOleDbを使ってやったような気もするけど。
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にするのが、真っ当な感覚だと言えるだろうか？
XmlSchemaSimpleType.ParseValue()
XQuery F&Oのsection5まわりで、サードパーティがXQueryを実装するのに必要になるに決まってるから、public APIとして追加するようにMS feedbackをつっついてみたが、どう出ることやら。別に僕は無くてもそんなに困らないのだけど（いざとなればまたSystem.Xmlで実装しちゃえばいいし）、XQPの面々はこれが無いと苦労するに違いない。
コメント
謎工 — 11/03/2004 04:24:02
著作権法改正要望のパブコメが文化庁の正式発表よりも先にアップされてました。
http://blog1.fc2.com/nirvana/?no=2