スキーマ推測
というわけでスキーマ推測の設計は（MS設計も考慮に含めて）だいたい考えたので、いまは実装に入っている。設計のカテゴリとしては、属性型の推測と要素型の推測で、個別のトピックとしては、文字列型の推測、内容種別（content type）の推測、そしてパーティクルの推測がポイントになる。それぞれどんなことを考えているかというと…これは長くなりそうなので、明日のエントリからちょくちょく書こうかな。（前フリだけかYO!）まあ、まだ変わるかもしれないんだけど。
著作者人格権の放棄
livedoorの規約改定まわりで、そんなのが話題になっているらしい。
僕は何年も前から、著作者人格権は放棄できるんだよ、田村くらい嫁よ、って言ってるのだが、未だに著作者人格権は放棄できないとかいう連中は多いらしい（しばらく前にそんなトンデモ記事を掲載してた雑誌があったけど、どれだったかなあ）。大抵の場合、譲渡と放棄の違いが理解されていないのが理由だ。
法律で禁止されているわけでもないので、著作者人格権の放棄を契約条項（ライセンス条項を含む）に含めることだって、十分に可能だ。
むしろ問題は、どのような場合にこの契約が「無効となるか」である。勘違いしてはいけないのは、デフォルトではこのような契約は有効なのであり、どのような場合に「無効であるか」が問題となるのである。その意味でこの説明は完全にスタンスを間違えている。そもそも裁判例では慎重に慎重を重ねた表現で「著作権が譲渡されているケースであれば、著作者人格権の放棄も有効とすべきである」と言っているのであって、「著作権が譲渡されているのではないから、著作者人格権の放棄は無効である」という文が成立するわけではないことは、逆・裏・対偶の概念が分かる人なら分かることだろう。
IXmlSerializerImplementation
~~インターフェースなのか実装なのかハッキリしてください。~~おっと、October CTPではXmlSerializerImplementationに変わってました。
メモ
Japanglish : おもろい。
mono anonymous SVN
利用可能になったみたいです。
svn://mono.myrealbox.com/source/trunk/MODULENAME (mono/mcs/gtk-sharp …)
System.Messagingはニュートラルか?
昨日の話題について、oka326さんがさらなる考察をまとめられているので、それについて少々。
まず、System.Messagingはメッセージキューを操作するAPIである、という意味では、最初からCOM+を前提としたSystem.EnterpriseServicesに比べたら、まだ実装中立になる余地はあります。ただ、System.Messagingには、明らかにWindows/MSMQの実装を前提としたAPIが散在していたりします。たとえばActiveXMessageFormatterとか、CryptographicProviderType(.MicrosoftExchange)とか、一部の列挙型がなぜか不思議な数値バインディングを持っていたりとか。メッセージキューサービスの機能そのものも、どれだけ標準的なAPIが（標準的なAPIとして）実装されているのか、自明ではありません。
これは、LDAPに基づいて設計されている.NET 1.xのSystem.DirectoryServicesとは対照的なものです（.NET 2.0は、ActiveDirectory専用のAPIが大幅に追加されていて、しかもネームスペースを分けるという当然の配慮も怠られているのですが）。あるいは、クライアント別のConnection/Command/DataAdapterなどとは別に、共通APIとしてSystem.Data.Commonが用意されているADO.NETとも違うものです（もちろんSystem.Data.Commonは別に何かしらの標準があるわけではないですが、少なくとも共通APIをSystem.Data.SqlClientから切り離そうとはしているわけです）。
つまり、（IMHOですが）System.Messagingは、メッセージキューの共通APIではない、あるいは、共通APIとしては未熟なのです。これは、例えて言うなら、System.MessagingはJMSではあり得ず、むしろベンダー固有のAPIに近い存在です。
System.Messaging APIがある程度抽象化されているのは、MSMQの将来のバージョンとの互換性を考慮しているためでもあるでしょう。System.Data.SqlClientも、現在のバージョンのSQL Server (7とか2000とか）の機能の一部しか提供していないと思います。
IndigoはSystem.Messagingに比べたらもちろんハードルは高いのですが、System.Messagingよりmonoで実用に耐えるAPIであれば、実装する価値は十分にあるでしょう。もちろん、実物を見てみないと、何とも言えないのですけど。（4年くらい前には、System.Windows.FormsもクールなAPIだと思われていました）。
コメント
oka326 — 11/15/2004 22:14:38
なるほど。ActiveXMessageFormatter、CryptographicProviderTypeあたりは厭らしいですね。COMのシリアライズを提供するであろうActiveXMessageFormatterについてはIMessageFormatterの実装ということである程度釈明の余地はあるにしても、ネームスペースを分離していないことはお粗末です。あと、そもそもD-BUS自体がMQとしては未成熟であるということも、調べているうちにわかってきました。MQの仕掛けはDCOMのような偏った分散オブジェクトを包括しうるという点でもっと一般的に普遍的に存在してほしい存在なのですが(とりわけDCOMなどの分散オブジェクト実装のリスクを全面的にMSMQが担ってくれているという点は開発者にとっては恐ろしく有難いはずです)、なかなかハードルは高いようです。また面白いネタがあればお付き合いください。
謎工 — 11/16/2004 01:55:05
著作権法改正要望のパブコメ全文が公表されてます。
http://www.mext.go.jp/b\_menu/shingi/bunka/gijiroku/013/04110401/004.htm
atsushieno — 11/16/2004 10:26:10
ありがとうございます。
そうですねえ、MSMQとは言わずとも、バックグラウンドで（商用でもいいから）メッセージキューサービスが動いていて、それと接続するという形でサポートできないだろうか、という議論は、mono meetingの時にMainSoftの人たちも考えていました。ただ、それでmonoのライブラリを決め打ちで固めるわけにはいかないですし、やっぱりもっとまともなAPIがほしいところです。.NETがJavaに比べて劣っている点は、この手のベンダー中立のAPIが少ない点です。ADO.NETはまだオープンな設計で多くのDBベンダーから支持を得ることができたんですけどね。
atsushieno — 11/16/2004 10:27:09
パブコメ、公開されていますね。基本的にはこの前外部で公開されていたものと同じようですね。改めてお疲れ様でした。