営業再開
何となく何も書きたくない症候群というか、イカれたアーティスト風に言えば「キーボードと仲が悪くなった」ので(いや仕事はフツーにしてたんだし、それはないか)、しばらくバーチャル失踪していました。
さてとりあえず先週の動向から…
Monoがsecuniaデビューを果たした件について
Monoもついにsecuniaにデビューです。ASP.NETエンジンにXSS脆弱性があるという話。しかも寝耳に水のimmediate disclosureです。
ちなみにこれはもともとMS ASP.NETの脆弱性レポートとして同じ報告者がMSに報告していたものだそうで(そっちはimmediate disclosureではないらしい—;)、MS.NETもMonoも現状どちらもunpatchedのままです。まあless criticalなんですけど。
GridView、言い換えればLluisはawful hackerである件について
ええ、英語が今より全然分かってなかった頃、間違ってawesomeをawfulと間違えて、Lluisに”You’re awful hacker”と言ってしまったのはワタクシです。よい子の皆さんは絶対に真似しないように。
ていうか、仕事早すぎ、すごすぎ。毎週のようにでかいコンポーネントが1つずつ出来てます。今週はGridViewです。System.Webのclass statusは、とても×が2500辺りからスタートしていたことを想起させません。
ReadXml()で読み込んだテーブルの列にint indexerでアクセスすべきでない件について
ここで
詳しい理由とベターな解決策も説明できるんですが、@ITの利用規約第4条によると、ここで書いてしまうと@ITに著作権が帰属すると書かれているようなので、勿体ないので書けません 。気が向いたら個人ページで書いてリンクを載せます。
と書いていた話。めんどっちいので@ITには追記しません(ていうか皆さん@ITの利用規約には問題があると思いませんか? 皆さんにもこういうスタイルで意味のある文章は外だしすることをお薦めします1)。
ていうかこんなもので生成したテーブルにintでアクセスしようなんていう人がいること自体信じられない…と言いたいところなんですが、そんな衝撃は半年前に既に受けていたので、ああまだいたかそんな香具師、っていう感じです。
さて、int indexerでアクセスすべきでない理由は、こんな感じです:
- インスタンス中の要素に属性や省略可能な要素があれば、順序は不定になる
- 親子関係(DataRelation)が生成される場合、そのキー(自動生成されるかも)がどこに入り込むか分からない
- そもそもReadXml()が生成中のDataColumnをどう管理しているか分からない。HybridDictionaryやHashtableが中で使われていたら(実質的に)ランダムになる。
ReadXml()…というよりその内部で使用されるInferXmlSchema()…はまともなビジネス アプリケーションで使うべきものではありません。ReadXmlSchema()を使うか(これもかなり挙動不審ですが)、あるいはxsd.exeを使ってstrongly typed datasetを生成して使った方がいいでしょう(これがベスト)。
いずれにしても、きっちりスキーマを定義すべきだと思います。XML Schemaなんて書けない!ということであれば、DataSetをプログラムでカリカリと定義して、TypedDataSetGeneratorという標準クラスを使えば、カスタムDataSetクラスをCodeDomで生成できます。
ちなみに、DataColumnにOrdinalを設定しておけば、予定通りの順序で出てきます。XML Schemaでmsdata:Ordermsdata:Ordinalプロパティを使えば、スキーマにも書けます。いずれにしろReadXml()では不可能な話ですが。
.NETのXPathNavigatorがそもそもXSLTと相性が悪い件について
これも@ITで引っ張ってきたネタですが、ていうかunparsed-entity-uri()が正しいXSLT関数として認識されていないこと自体は、OASISのstandalone testを走らせていて知っていたのですが、何でこんなバグがあるんだろう、というのを考えていて気付いてしまったわけです。
これ、どうあがいてもXPathNavigatorじゃ無理なんですね。DOMとは違って。サポートできるわきゃないんです。でも(少なくとも当時は)MSとしてはXPathDocumentを全面的にプッシュしていて、XmlDocumentじゃなきゃできないことは、なるべく表に出さないようにしていたわけです。MSXML4でちゃんとサポートされているunparsed-entity-uri()が、XslTransformでなぜかサポートされていないというのは、そういう堂々と表では言えない裏事情があったんじゃないか、と思えてしまうわけです。
どうでしょう、試しにMS feedbackにレポートしてみましょうか。「MS、知ってたんじゃん!」みたいな回答が返ってくると思います。
不思議なことに、Monoではちゃんと出来ているんですよね。ええと、ゴメンナサイ、昨日直しました(爆)。いや、基本設計は昔から合ってたし、全然不思議なものではないのです。IHasXmlNodeにキャストしてXmlNodeを取得すれば、OwnerDocumentもDocumentTypeもEntitiesも取得できますから。
xml.comでxml:idとxml-c14nの相性問題を語られている件について
planet XMLhack経由で気付いたのですが、こんな記事が出ていて、懐かしい なあ、と思いました。
Rich Salzの結論は、xml:idは使おう、xml-exc-c14nはこういうインポートが無いからそっちを使おう、というもので、禿同という感じです。
monoのページがそのうち変わるかもしれない件について
今のスタイルのNovellのCMSベースのページに変わってから、誰も更新したがらなくなり、どんどん情報が古くなって、Miguelとしては非常に印象がよろしくなかったようで(ていうかwebサイト翻訳者の僕から見ればあのシステムは逝って良しなのですが)、そのうち変わる予定です。翻訳するネタがばーっと増えます。皆様(誰だよ)お楽しみに(何をだよ)。
…あ、本家の話ね。
Footnotes
-
ていうかこんな利用規約は無効だと確信しているので、個人的にはどうでもいいんだけど ↩