へのつっぱりૐはいらんですよ
ほほう、Miggyがハリウッド映画に進出ですか。これは本人に知らせておかないと。みんながMiggy, Miggyって呼ぶたびに、僕は右手が振り回されている光景を想像していたんですが、そんなこと仲間に言っても通じるはずもなく…これで彼らにも理解してもらえるかもしれません。
…って思ってたら…えーっ、ミギーじゃないの?? ひぇー
RMLのLinux Kernel Developmentですか。確かに出たら僕もほしいなあ。って、Linuxカーネルなんてほぼ何も知らないし、RMLもGNOME Summitで彼のinotifyセッションを聞いていたという程度にしか知らないけど…。で、ここで言われている訳語云々が何のことを言ってるのかは分からないけど、多分翻訳を実際にやってるのはNovell JPの中の人じゃあないと思うし、以前に似たような訳本を出していたとしたら、その訳書を出したとこのクオリティなんじゃないかなあと思う。あの会社が訳語について指示しているとは思えないので。何かJISっぽい訳し方だよね、Linuxの核とかって。
たぬき・むじな事件
まず、コレがなかなかイイ感じ。たぬき・むじな事件というのは、大審院判例大正14年6月9日（刑集4巻378頁）の通称で、刑法を勉強したことのある人なら、むささび・もま事件と対照的に、事実の錯誤として処理された事案として知っているものです。事実の錯誤って言うと見方が偏っているかな。事実の錯誤、違法性の錯誤あるいは故意の不存在ということで…
で、いま故意と違法性の意識を読んでいるんだけど、これによると、このたぬき・むじな事件に対する学者の反応は
- 違法性の意識を欠き故意がない
- 厳格故意説 (滝川幸辰・大塚)
- 違法性の過失故意犯準拠説 (宮本英脩)
- 自然犯・法定犯区別説 (牧野、木村)
- 違法性の意識の可能性を欠き責任がない : 制限故意説 (団藤)
- 禁漁獣であるという意味の認識がない
- 違法性の過失故意犯準拠説 (草野)
- 責任説 (吉田常次郎)
- (萩原玉味)
- たぬきであるという意味の認識がない
- 制限故意説 (井上、日沖)
- 責任説 (平野、川端)
- 構成要件上の概念による認識を欠き故意がない : 江家
- 違法性の意識の喚起機能を持つ事実の認識を欠き故意がない
- 制限故意説 (藤木)
- 責任説 (西原)
という感じだったらしい。いやはや、バラエティに富んでいますな。
versioning hell
世間ではfirefox 1.0.5の日本語版が出せないとか言って騒ぎになっていますね。まあ、騒いでいる非モヒカン族（言葉を覚えたので使ってみたｗ）の大半は実は英語版でも問題なく使える人間か実はfirefox使ってない人間だと思いますが。
で、今回の件はAPIの安定性が問題だったわけですが、これって果たして解決できる問題なんでしょうかね。実際のところ、.NETのside by side executionというのは、そのような変更があっても問題なく動作させるための機構として提供されたはずなのですが、どうも.NET 1.1 -> 2.0の変遷を眺めていると、やっぱside by sideだけでは足らんのでしょうね。僕はいじったこと無いから知らないけど、WSEも結局全然違う物になってたっぽいし。複数バージョンを並行インストールできるJavaと比べて、あんまし大きな改善点は無かったようにも思えます。
Monoでは、API stabilityに関連して、Application Deployment Guidelineというドキュメントにガイドラインをまとめています。この中の「GACをいつ使うべきか」というセクションで、
But developers that install libraries into the GAC must be aware that putting something on the GAC is a commitment to API stability. It is a commitment that should not be taken lightly. If you are to change the API in a backwards-incompatible way, you should change the version of the library to ensure that old applications continue to work. When the library changes its version, then two copies of the library must be distributed: one for the old applications that might depend on the old API and the new version of the library.
と言われています。GACにライブラリをインストールするということは、APIが安定したものであるということを多かれ少なかれ約束したようなものだから、まだAPIが不安定なうちはGACにインストールなどするな、ということです。
Summer of Codeでばんばん改善されているmonodocでも、DotLuceneを使った検索機能が追加されようとしているんですが、どんだけ共用されていようとdotluceneのdllはGACにインストールしない方向でいくみたい。
まあGACについては、まだ@ITがおもしろかった頃に通常のアプリケーション用のアセンブリをGACにインストールする必要はまったくない、と既に言われていたことですし、あんまし関係ないはずですね。
MonoはGACのロケーションに関しては柔軟に指定できるのですが、インストール先の指定が問題になるのは、必ずしもglobal assemblyだけではないので、あまり複雑なことはしない方が吉なのでしょう。たとえば、WindowsユーザーはCodeDomProviderやASP.NETを使うとき、cscが内部で呼び出されるのは当たり前のことだと思っているかもしれませんが、Monoの場合はmcsにパスが通っているとは限りませんし、monoランタイムの位置からlibの位置を逆算できるとは限らないのです。それ以前に、環境によってインストールされるライブラリは異なりうるからmcsはデフォルトでmscorlib,System,System.Xml以外のライブラリは-rで明示的に参照しないといけないし、可愛いっぷり見せないといけないし…女の子は忙しいんです。
xml:id PR
xml:idのPRが出てますね。こん中に（一つ前のバージョンからだけど）Canonical XMLとの非互換性について言及されています。で、僕を含めて誰も使っていないので、exc-c14nがあるからいいんじゃん?っていうお気楽な結論でいるのが趨勢だと思うんですが、多分誰もxml:spaceやxml:baseが継承されないという問題は意識してないと思うんですよね。
本家monogatariでは「別のnamespaceを割り当てちゃえばいーんじゃん?」とだけ書きましたが、まあ、↑な問題にも誰も気づいてなさげだから、本当にニーズが無いんでしょう、きっと。それにMicrosoft.NETの世界では、ユーザーの誰かがxml:idを実装して、それがSignedXmlと相性が悪いことに気づいたら、SignedXmlの実装を変えろってMSにプッシュしてW3C仕様違反なAPIが増えるでしょうから、まあ心配しなくて良さそうです。先例あるし。