the whitest of the winters
mono日本語wikiの方向性をまとめようと思っていたんですが、昨日頭の頭痛がイタかったのと、今日はさすがにNVDLを進めようと思ってこっちに走ってしまったのと、map pluginでマップが出ていればとりあえずいいかなと思ったのとで、結局もう少し内容を加えながら様子を見てみることにしました。portalも、少しずつ消していこうかと思っていたのですが、フォーラムがちょっと使われたりもしていたので、もう少し現状のままで様子見にします。あ、でもリンク集は不便なのでwikiに移そうかな。
↑のwikiは、僕も気の向くままに追加しているものですし、MS.NET関係の用語とか、けっこう未入力のまま放置してあったりするので、どなたでも気が向いたら編集してやってください。
今年は少しずつユーザーサポートというか、情報流通の幅を広げられるようにしたいと思っています。僕も知らないことだらけなんですけどね。実際には知らないことは即本家に丸投げして聞いているので（ｗ もちろん、僕の目標はネズミ講よろしくmono hackerを増やすことｗなんですけど（いや別にmono hackerが増えても僕の懐はちいとも温かくなりませんが）。
ところでid:akirameiさんとKazukiさんに提案なんですけど、こんどはmono-devel-listにpostしてみません? mono-bugsにパッチを登録するより反応が早い気がします（僕がbugzillaで反応してもそれで完結してしまいますので^^;）。一番早いのは、irc.gimp.orgの#mono(IRC)で「パッチ作ったんだけど…」と表明していただくことなんですが（それなりにリアルタイムで英会話?になります）。
6日目にして全く実装ならず
先週はサイト作っててだいぶお休みになってしまったNVDLのつづき。
PlanElem = { (v, e) | (s, v, e) in Z, if (s, v, e’) is in Z then |e| >= |e’|}
どういう意味だコレ…orz 仕様書4.にあるa set of attributesとは違うはずだし。
…nm. 分かった気がしてきた。
コメント
Kazuki — 01/24/2005 02:54:31
えーっと、明日IntegerFormatterとFloatingPointFormatterを合体させたFormatterを作る予定なので、ポストはそれが出来てからということで・・・
atsushieno — 01/24/2005 03:04:50
合体した方がいいかどうかはちょっと分かりません。もしかしたらパフォーマンス上の理由で分別しているのかもしれません。
Kazuki — 01/24/2005 03:43:22
僕が作ったIntegerFormatterってStringBuilderを使っているので、少しばかり遅いんですよね・・・それなら、拡張すれば同じコードでFloatingPointにも対応できることに気付いたので、統合しようかなーと思ったわけです。結構同じコードを使いまわす羽目になりますし。
atsushieno — 01/24/2005 04:15:44
あ、いや、何でもありませんでした。すみません。実は昔この辺をいじっていたときに、殆ど同じコードばかりだったのでまとめようとして、Miguelに「それらはパフォーマンス上の理由で別々になってるんだ」って言われたことがあるんです。が、今確認したら↓で結局Lluis Sanchezがやっちゃったみたいなんで、大した問題じゃないのかもしれません。
http://svn.myrealbox.com/viewcvs/trunk/mcs/class/corlib/System/IntegerFormatter.cs?rev=26046&r1=25840&r2=26046
村田 — 01/28/2005 23:19:36
偶然見つけました。実装、ありがとうございます。
以下、質問にお答えします。まず、
が、foo:fooをルートとするsectionとbar:barをルートとするsection
に分割されたとします。
そして、foo:fooに
<namespace …>
<validate …>
が適用され、bar:barに
<namespace …>
が適用されたとします。
すると、
foo:fooを検証するんじゃなくて、
を検証しないといけない。つまり、foo:fooを生成するほうのinterpretation
じゃなくて、bar:barをfoo:fooにattachしてから生成するほうの
interpretation を選ばないといけない。そのために、要素数を数えて
（ |e| >= |e’| ）いるわけです。
実装ができたら、ぜひ教えて下さい。期待してます。
村田 — 01/28/2005 23:32:46
書き忘れましたが、要素を数えるなんていうのはもちろんダサくて、attach
の回数がいちばん多いものを選べばいいわけです。attachの回数という概念を
導入するとますます仕様がややこしくなるので、ああしています。
atsushieno — 01/29/2005 09:01:12
わざわざありがとうございます。
the biggest validation candidateというのが「一番大きな（サブ）ツリー」のことを表しているんだろう、という意味では理解が合っていた（と思う）のですが、検証対象にbar:barが含まれているのが、想定していた仕様と違っていたので、ひとつ確認させてください。
PlanElemこと(v,e)のeは、sectionをベースに計算されたinterpretation /をもとに計算されたsyn[/]から表されたsyn/なので、sectionを対象としているのだと思いますが、ひとつのvalidateアクションの検証対象には、単一の名前空間に属しているsectionだけではなく、そのsectionに対応するelementの子孫として含まれる、別の名前空間の要素も含まれる、という理解で良いのでしょうか?
validationは/A(s)で表されるような、section「に対して」行われるものだと思っていたので、foo:fooの検証をしているときは、bar:barをチェックする必要は無いのだろうと思っていたのです。foo:fooの下にbar:barが存在するとき、OKを出したりNGを出したりするのは、foo:fooのsectionに対するvalidateアクションではなく、NVDL scriptの対応する現在のmodeではないかと思っていたのです。
…が、この理解だと、attachとunwrapの違いが無さそうですね。
atsushieno — 01/29/2005 09:06:15
あ、この議論を続けるなら、ここより他の場所のが適切かもしれませんね。xml-users MLとか（脱退しているので入り直さないと）…
村田 — 01/29/2005 15:29:30
RELAX制定に関する日本語メーリングリスト (http://www2.xml.gr.jp/1ml\_main.html?MLID=relax-std-j)に移りますか。登録したら、
自己紹介メールを出してください。