オケラボブログ跡地

完全に門外漢だし、ただなんとなく感じただけなんですけど、Ajaxが流行ってからPHPの話題が減った気がします。
もちろんPHPが十分に枯れたというのも理由の一つでしょうけど、それだけじゃないような気がする。

PHPってのはHTMLコードの中にPHPタグを埋め込むことができるから、画面設計が容易な言語らしいです。
(実際に使ったことはないので伝聞形。)
ところがAjaxを使えば、画面遷移なしでサーバとの通信ができる。
画面遷移がなければ「○○画面」をいくつも作らないですむから、PHPの優位性が薄れる、と。

Ajax的なものとして、リッチなUIが取りざたされていますけど、ほとんどはDHTMLとか呼ばれてたものっぽい。
(DHTMLによるWindowsもどきなら何年か前に作ろうとしたことあるし。IEがアレ過ぎて断念したけど。)
私的にはAjaxが凄いのは、その名のとおりの非同期通信だと思います。
(もちろんAjax以前から機能としてはできたけど、私を含めできる事を知らなかった人が殆どだと思う。
だから、Ajaxというキャッチーな名前によってJavaScriptのHTTPRequestオブジェクトの存在が広まったのは評価してます。)
Ajax以前の(と敢えて書く)Webベースのシステムは、サーバとの通信には画面遷移が必要だったわけで
だからこそPHPが非常に有用だったわけだけど、
Ajaxによって、サーバと(画面遷移なしに)データだけをやり取りできることがわかった。
そうすると、タグによってニャンニャンするPHPよりも、むしろデータだけをニャンニャンできる言語のほうが便利になる。
最近のあの辺をにぎわしてるのはRuby (on Rails)やGoogleの基幹言語としてのPythonなのもその辺に理由がありそう。

そういやこれまではPerlが使われてたけど、言語的にはPerl＜＜＜＜Python,Rubyで、
Perlが使われてたのはひとえに過去の資産のおかげなわけですけど
Ajaxによって過去の資産の無いところに新しいものを作ることになればPerlじゃない言語になるのは当然だろうなぁ。

っていう印象論。

Widget用といいますか、WebKitではHTMLのinputのtypeにsearchというものが加えられています。( Dashboard Programming Topics: Designing Widgets --Search Fieldsの項を参照 )
これを使うと、いくらかAppleっぽい検索フィールドを作る事が出来ます。
type="search"では、幾つか新しい属性が追加されています。
placeholder: 検索条件が無いときにうっすら見えるテキスト
results: 検索履歴をいくつ保存するか。数字で。
onsearch: サーチ用のイベントハンドラ。onchangeとかと同じ気分で。
incremental: この属性があると、１文字入力(削除とかも)があるごとにonsearch。
onkeypress: 読んで字の如し。

例えば画像の六法分書の場合は
[input type="search" name="srch" size="12" placeholder="条文番号" results="5" onsearch="showJoubun(this.value);" /]
という感じ。
resultsを設定するとサーチフィールドの左側に虫眼鏡アイコンがつきます。

ちなみにこのサーチフィールド、Safari等のWebKitブラウザでしか対応してないですが
inputのデフォルトtypeはtextなので、searchを知らないブラウザではテキストフィールドに見えるはず。
試しに書いてみる。→
onsearchだけでなくonchangeなんかを使えば、
Safariではリッチで、他のブラウザでも普通に使える検索窓をつけられると思います。


あ、それと、話がそれるけど六法分書で複数の法律を選択できるようにしました。
UIでは付箋紙みたいなイメージ。

文字を投稿するWebシステム(ex:Blog, Wiki)では、投稿前にプレビューを用意する事が多いようです。
あるシステムではプレビューボタンを押してプレビュー画面に遷移しますが、
わりと一般的なのは編集ページ内に、編集と平行してプレビューを表示する物です。
(このBlogの使うNewsHandlerもそう。)
しかし、このシステムだとプレビューを見るにはウィンドウをスクロールしなくてはなりません。

そこで試案。

プレビューは別のウィンドウに表示しておけば、両者を並べて編集する事が出来ます。
(フレームを使っても良いけど、ウィンドウの方が場所も広いし直感的だと思う。)
この時、プレビューを親窓、編集用ウィンドウを子窓にした方が便利だと思いました。
編集しながらプレビューを見る場合、編集用ウィンドウが常にアクティブだと楽です。
するとプレビューはデスクトップでは編集用ウィンドウの下にある事になります。
その時、上の記述とは逆にプレビューを子窓とすると、基本的に親窓より子窓の方が小さいので
プレビューが編集用ウィンドウに隠れてしまいます。
そこで、編集用ウィンドウを子窓として使う。
これなら常に編集用ウィンドウをアクティブにしたまま快適に編集できます。
編集用ウィンドウで隠れてプレビューが見えない部分は編集用ウィンドウをずらせば良いし。

というわけで、このアイディアの実証実験をオケラボに置いてあります。お試しあれ。(感想希望)
(Firefox1.5.0.1, Safari2.0.3で動作確認。IEは知らん。)
キモは編集用ウィンドウ側の　なお、このアイディア(とコード)に関する権利は放棄するんで、面白かったら使って下さい。
(っていうかもう既に誰か考えてそうだけど。)

私はWidgetの開発の際に、まず背景画像等を使わずにプロトタイプを作ります。
その時、ブロックには枠を付けて見えるようにしておくんですが、
並ぶとどれがどの階層にあるblockなのか解りにくい。
そこで階層を見やすくする方法を思い付きました。
とりあえず全部divで定義するという前提で、cssで下のようにスタイルを付けます。
一番の特徴はbackground-color。
ここで半透明の色を指定する事で、重なったら深い階層ほど背景色が濃くなります。
上のコードはSafari用。Safariは色指定にCSS2のrgbaが使えるんですねぇ。
クロスプラットフォームで遊びたかったら、
という感じになると思います。
背景色がblack(#000)ではなくgrayなのは、重ねまくっても真っ黒にならないようにするためです。
border-styleがinsetなのは趣味。深く見えるっしょ？

このようにdivにスタイルを設定して、階層を作りまくったのが左の画像。
という感じのhtmlを表示しています。(もちろん"["は"半角＜"、"]"は"半角＞")
div10から先は同じ色になってますね。まぁこれ以上深くするのはどうかと思いますけど。

合わせ鏡みたいで面白かったから勢いで紹介。

前に紹介した単純法規XMLですが、ちょと変更しようと考え中。
XMLの構造考えるのって、楽しいけどムズいね。
新しい言語はなるだけ作るな，という意見は知ってるし、同意なんだけど
どうせ仕事じゃなくて遊びだし、あと「5大フォーマット」では要件を満たせないので。
さて、変更点幾つか。

1) 法tagから条tagに変更。
単純に名前の問題。各条を指して法と言っても正しいときもあるけど、怪しいときもある。
法律は条文がリニアに並んでるけど、その地位はリニアじゃないから、
その1条をもって「法」と呼ぶには怪しい場合もある。
あと、後述するidの廃止との関係で、ここに入るものをより明確にしたかった。

2) idによる条文番号定義の廃止と番号tagの新設
あるものを要素にするか属性にするかはいつも悩む。
idの最大の難点は、これは属性なので、タグを非表示にした場合に条文番号が見えなくなる事。
他方、以前idを選んだ理由のgetElementByIdメソッドは、同等のものを実装するのは大して手間にならないと考えました。で、実際に書いてみた。
例の如く，不等号やtabの編集の都合でコピペは不可。
あ、あとXMLdocは、全法分書で使ってるグローバル変数。
グローバル変数なんざ使ってるものだから、「だっだめ！見ないで！」って感じです。
Pythonに慣れるとJavaScript (というかc系)は中括弧を閉じるのがめんどいなぁ。
省略すると保守の時にたまにうっかりしちゃうんだよね。
DOM使ってて厭なのが、textNode取得の面倒さ。
今回は番号tagの中に改行等が含まれない前提で書いてますけど、ちゃんとやるとホントめんどくさい。

3) 条文tagの新設
前は法tagの中に直に条文を書いていたんですが、それは法が他に子を含まない予定だったから。
番号tagを作ると、textNodeを取得するのがすこぶる厄介なので、条文tagから取り出せるようにします。
完全にプログラマの都合だから、あまり好みの変更ではないんだけど…。
(20060222追記)
やっぱり条文tag無くするかもしれません。テキストノードさえ何とかできれば良いのですが、まだ考え中。

以上の変更から，条文はこんな感じの構成で書かれる事になります。民法4条を例に。
(変更前)
[法 id="第4条"]年齢二十歳をもって、成年とする。[/法]
(変更後)
[条][番号]第4条[/番号][条文]年齢二十歳をもって、成年とする。[/条文][/条]

4) 参照tagの考察
前回追記した参照tagはまだ考え中ですが、案を一つメモ。
[参照][名称]民法[/名称][番号]94条[/番号][/参照]
みたいな感じでどうだろう。
前回追記した、冗長になり過ぎるというのは、参照tagの属性として名称等を規定する事を想定したため。
それだと、tagを表示しなくても条文をちゃんと出すには
[参照 名称="民法" 番号="第94条"]民法94条[/参照]
みたいに、同じものを2回も書く羽目になってウザいと思ったため。
上の方式はXHTML1.1のrubyタグに近い発想になってます。
これなら情報を損なわずに参照を指定できる。
ただし"参照/番号"が"条/番号"と違う書式になってしまう事が考えられる。(第n条)
この辺はまだ検討の余地があるなぁ。
参照tagの中に参照先を指定できるとすれば，「前条の場合」等の記述で前条への参照も書けるかも。
例えば空要素の属性で参照先を指定するとか。

なにはともあれ、細部は全法分書のロジックを書きながら詰めていく事にします。

さしあたっては『全法分書』用として作った法律記述XML。
そのうち、単純な法規の記述に使う事のできる"単純法規XML"。
スキーマはまだ書いてないですが(仕様もまだ確定ではない)、とりあえずサンプルを。
国家賠償法の単純法規XML版
サンプルが国賠法なのは、国賠法が条文が少なく(6条からなる)構造が単純で、かつ重要度の高い法律だからです。

単純法規XMLは下のような構造になっています。無印は1回、+は1回以上、*は0回以上、?は0or1。

法tagの中身は、項が無ければ条文が入ります。項がある場合は項tagの中に条文が入ります。
公布・施行の中には日付tagが入り、日付tagは年・月・日が入っています。
上の概略では、単純化のために省略。
もしかすると補則tagを0orMoreで加えるかもしれません。
また、将来は各条文に表題を付けるtag (or attr)を加えると思います。
法tagにはidで条文番号を指定する事になっています。
本当はidではなく日本語の属性(または子要素)を使うつもりだったのですが、
XMLをハンドルする際にDOMのgetElementByIdを使うのが簡便なので、
Identifier=条文番号はidにする事にしました。
条文番号の数字は半角英数字にしなければなりません。
漢数字等の条文番号から検索する操作はソフトウェアの側で実装します。
じゃ第だの条だのなしで数字だけでも良いんじゃないかとも考えたのですが
それだと生のファイルを人が読んだ時に解るか怪しいので、折衷しました。

あと、他の条文への参照はXMLには含まないようにしようと考えています。
特定のファイルの存否に内容が依存しないようにしたいので。
他の条文への参照はソフトの方で正規表現でも使って実現すれば良いかな？
あー、でもファイルへの参照は含まなくても、法律の参照を含む部分をマークしておくくらいは良いかなぁ。
例えば この法に規定の無い部分は民法の規定による。とかあったら、
この法に規定の無い部分は＜参照＞民法＜/参照＞の規定による。みたいなの。
うーん、考えておこう。
(同日追記)
上のファイルの存否〜はHTMLの[A href=~]を念頭においての発言で、
ファイル名を書いておく事を想定していたからこんな問題になる。
ファイル名ではなく法律名を書いておいて、その法律がXMLをハンドルしてるソフトに認知されている時に
ソフトの側でリンクを貼らせるようにすればこの問題は解決するはず。
とするとタグでは[参照 法律名="民法" 条文="第94条"]みたいな形式になるかと思ったんですが、
これなら属性部分はどうせ参照tag内に書かれているものと同じになるだろうから
人への優しさを考えると参照tag内をソフトの側で解釈するのでも良いかも。
(/同日追記)

さて、このXMLフォーマットの特徴として、タグ名に日本語を使用しています。
万国共通規格なんてさらさら夢見てないので、日本語の方が適切と判断。
おそらくXMLについて知らない人でもファイルを見てどうなってるか解るだろうと思います。

ちなみにこれは単純法規XMLです。
編、章、節といった階層を持つ法規用は別フォーマットとして定義するべきかどうか考え中。

まぁ自分用フォーマットで終わるでしょうけど、オープンにするので、意見があったらツッコミお願いします。

英単語に足りない語彙があるとすれば、それはsuxという語だと思う。

いやまぁ、SAXはThe Simple API for XMLなんだから、SGMLが射程外なのは当然なんですけどね。
(HTMLとして正しくても)XMLとして正しくないHTMLを、正しいXHTMLに変換したいなと思ったわけです。
あるいは正しくないHTMLのままでも扱えたらそれはそれで、と。
で、Pythonでさくっと試してみたんですよ。
まずは間違ったHTMLを用意。ill.html ※編集の都合で、タグを全角で書いてます。 例えば閉じない空タグを入れてみたり、dtとddで対応を間違ってみたり、閉じないpを使ってみたり。
んで、saxをつかってパースしてみる。IllTest.py 実際にはエラーの箇所が分かりやすい、ちゃんとハンドラを実装したのを使ってたんですけどね。
実行してみるとエラーメッセージが。 つまり、brが閉じる前にqが閉じられてるのがパースエラーになってるわけです。
(ちなみに[br /]だと大丈夫。当たり前だけど)
なのでSGMLをXMLに変換するには、既存のパーサを使わず正規表現でゴリゴリ書くことになりそう。
tidyを使えば良いんですけど、なんかFinkで入れたtidyが上手く動作しないんだよね…。

(20060128追記)　例外処理すればいいじゃん！
ファイル自体だと変更できないけど、ドキュメントオブジェクトにしてからパースして、例外処理で修正。
修正→再パースを繰り返すから効率は悪いかもしれんが…。

Pythonにて 終了条件を関数自身に持たせたりとかできる。かも。
今回は外で管理してるけど、完全に関数任せにして、終わる時は例外を投げさせるとか？
可読性とかについては知らん。とりあえず、面白いな、って。

RoopOfStrategy.py 実行結果。 使い道、STGでボスのパターンをループさせるくらいしか思い付かないw
関数がオブジェクトな言語ってのは面白いなぁ。