2004-09-09

gtkmozembed on Windows

ウヒョー!! そんなのがあったなんて、知らなかったYO! すげー。これでWindowsでgecko#が使える日がくるかも。

the copyright blank slate

今にして思えば、著作権法をもっとも自由に学ぶことが出来た最後の世代は、いまの高校生くらいまでだった。いや、もっとも自由に学ぶことができたのは、おそらく20世紀前半の学者のみであったろう。そんな僕らの時代ですら、ブランクスレートこそ維持されていたものの、まともでない教材がほとんどだった。2ちゃんねると同じで、読む力が問われていた。

最近、著作権の禁止的効力の性質について議論をしていたのだけど、僕の落書きは著作権の原理と現代著作権理論を一歩も踏み出していないことを痛感した。「著作権の財産的効力が自然権なのは当たり前で、それをいかに制約するかが問題なんだ」という主張がコペルニクス以前であることを、僕は議論の中で何度と無く示唆しているのだけど、どうもプロテスタントはカトリックと戦うのに必死で、無神論者は神の教えを理解しない邪宗徒だと理解しているような気がする¹。

XML should be more fun

昨日と今日で、XmlReaderSettingsとXmlWriterSettingsの実にどうでもいいサポートをあらかたやっつけた。コレは実にくだらない機能だ。ていうか、System.Xml 2.0に魅力を感じている人って、一体どれだけいるのだろうか? XmlReader.Create()を見たとき、これを素晴らしいと思うか、それとも今までのXmlValidatingReaderがいかに不自由であったかということに気づくか、その違いは大きい。

最近、XmlDocumentを利用したobject mappingは出来ないかなあと考えている。ある要素の内容をnon-deterministicに2通りに解釈しうる場合に、relaxerモデルというかXmlDocumentをツリーコンテナにして、オブジェクトは必要に応じて生成しキャッシュする。何でもかんでもmappingしないと成り立たず、クラスの拡張とも相性の悪いXmlSerializerよりは、実際的なんじゃないかなあと思っている。

XmlReaderを任意の文書構造向けに拡張するという方法でも、それなりに良いと思うけど、解釈が後戻りできない点が劣る。それに、XPathNavigatorを選んで、単なる参照のためだけに生成されるインスタンスをmapped objectごとに保持して、ツリーと合わせて実質2倍のオブジェクトを保持するよりは、navigatorではなくツリーノード参照だけを保持すれば足りるXmlDocumentの方が、ずっとセンスがあると考えている。

って、まだまだぜんぜん試案段階なのだけど。

コメント

oka326 — 09/10/2004 12:40:10

「XmlDocumentを利用したobject mapping」、手間は増えますがいいです。関知したくないネームスペースの要素は無視できるし、DOMの編集後にはサポートしてない要素も含めて完全に書き戻せるし、Undo/Redoの実装ができるし、いいことは沢山あります。欠点はメモリを倍食うこと、DOMとオブジェクトツリーのシンクロで若干パフォーマンス低下があることですね。Sodipodiのアーキティクチャはこのモデルを実装しています。

atsushieno — 09/10/2004 15:50:38

あ、とても参考になります。どちらかというと柔軟なデシリアライゼーションが主な目的だったので、オブジェクトを変更した後のシリアライゼーションについては、まだ検討していませんでした。特に同期的なDOMツリーの変更が必須となってしまうと、パフォーマンス的に厳しいですね（同期しなくても問題がない設計って、ちゃんと考える必要がありそうですが）。
.NET 2.0のXmlReaderには、ReadAsObject()なんていうのがあって、XmlSerializerを利用したツリーフラグメントのdeserializationが行えますが、これと近いものがDOMでも出来るんじゃないかなあと思ったのが出発点です。（それだけならnew XmlNodeReader(node).ReadAsObject(arbitrary_type)でいいんですけどね。）