暑い日が続いてましたが、昨日の昼下がりは、関西は大荒れで雷雨でした。結構激しく降ったんですよ。

こういう時、仕事は結構怖いですね。もし近場に落雷して停電したら、その時にハードディスクが壊れるとか、トラブルが起きる可能性がゼロとは言えないですし....（雷雨じゃない急な停電で仕事が半日止まったこともこの間ありましたしね）

新聞とか見ると、亡くなられた方とかおられるようです....お気の毒に。自然は怖いものですね。

昔はよく、

雷が鳴る音を聴いたら、コンピュータは停止して、電源もコンセントから抜いて、それで安全

と教えられていたのですけどね....しかし、今はネットワークの時代です。電源以外に「ネットワークの接続」という電気的に厄介なものをコンピュータは備えてしまっているわけです....要するに、近くに落雷があると誘導電流が流れ、これによる被害が重大なのですが、電気は「入口と出口がないと、流れない」という性質があります。ですから、電源と電話線が電気的に出入口になってしまい、被害を拡大する傾向があるようです。困りましたね！でも逆に言えば、無線ＬＡＮは落雷対策になる...ということのようです。電話線とコンピュータが電気的に接続されるわけではなくなりますからね！

まあ、一番簡単でしかも落雷対策以外に停電対策にもなるのが、ＵＰＳの導入ですが、サーバ機以外ではちょっとコスト高ですしね.....ＯＡタップに付属するサージキラーって効くんでしょうか？？？？

あるいはビル全体で対策を講じる...というのもあるようです。ビル全体が等しい電圧になっている状態を作り出せば（言い換えるとすべてアースされているのと同じです）、誘導電流が建物内に入り込まないので、建物内部の被害が起きないことになる...という話です（要するに「電線に止まる小鳥が感電しないのはナゼ」と同じことでは？）。

たまにしかないことですが、こういう備えって意外に馬鹿にならないのかもしれませんね！ 自然には勝てないです....

参考：意外に詳しい記事少ないですが、これが例外的にスゴイです。

被害のメカニズムから守り方まで　ネットワークの落雷対策（日経BP）

1. Part1: メカニズムを知る
2. Part2: 手早く対策するには
3. Part3：建物全体で守る

さて今度はUNIXのシェルのコマンドラインで、

ハイフン ＝ 標準出力指定

として捉える習慣についてです。

これは、getopt(3) とは全然関係がなくて、個別にそのプログラムの側の独自実装として、明示的に

ハイフンだけのファイル名 ＝ 標準出力

と置き換えて処理します。ですから、ホントこれ、「そのツールの実装でしょ」と言えばその通りです。また、UNIXコマンドは

標準入力から読んで、結果を標準出力に流す

UNIX哲学に沿って書かれていることが多いのは当然なので、 特に「標準入出力を示すハイフン」が必要になるのは、「デフォルトではすでに別な用途で標準入出力が塞がっている事情がある」比較的珍しく、複雑なケースに限られることになります。ですから私が知る範囲では、

● tar の f オプションのパラメータ

標準入力(tar xvf, tar tvfz とかの場合)、標準出力(tar cvf とか)共に有効。

● sed, gawk の -f オプションのパラメータ

標準入力からスクリプトを読んで実行する。動的に実行詳細を変更する必要があるケースでこれは便利です。

● diff の操作対象ファイル指定

「% diff realFile.dat - 」で、実在するファイル radlFile.dat と標準入力読み込みとの間での比較がなされます。

● gs の -sOutputFile オプション

このオプションは PostScript の命令をレンダリングしてラスタ画像ファイルに変換する時の出力ファイル指定なので、ハイフンは標準出力に変換された(おそらくバイナリの)ラスタイメージを流します。ですから、PostScript で書かれた画像をフィルターのインターフェイスで加工する NetPBM みたいなツールで加工するケースでよく使われます。

とはいえ...ファイル名（複数）を、オプションの後に並べて書く「対象ファイル」の一般的な書き方では、その複数ファイルの順番の中に、「標準入力から読む」を混ぜて指定できる、というのも非常に使いでがあるケースがあります。だから、

● cat の操作対象ファイル指定

対象ファイルとして「-」は実在するファイルと同じ役割りを果たします。

....cat(1) は「フィルターの練習で cat と同じように動作するプログラムを書いてみましょうね！」という時の練習台に使われることから判るように、

フィルター自体のモデル

と捉えても過言ではない「UNIX哲学としてのフィルター」ですが、これの実装はハイフンを標準入力として捉えます。ですから、あなたがフィルターを書く時に、「操作対象の指定として、ハイフンが現れたら、それを標準入力に置き換える」という処理を入れるのは、実は凄く正統派のやり方なのです.....(とはいえ、「使えたらいいな」というコマンドで実装されていないケースも結構ありますが)

しかし実質上「% rm file1 - file2」のような、「ファイルを操作すること」が目的のプログラムでは、この読み替えは無意味です...あくまで、「指定したファイルの中身を読む→標準入力から読む」の操作の同等性ゆえに、この読み替えがあるのですからね。実際ソースレベルで確認すると、GNUのcoreutils(6.12) の中で、ハイフンを標準入出力に読みかえて処理しているプログラムには次のものがあります。

cat, cut, date, dircolors, du, head,
shred,touch(/bin)
cksum,comm,csplit,env,expand,fmt,fold,join,
md5sum,nl,od,paste,pr,ptx,sort,split,sum,tac,
tail,tee,tsort,unexpand,uniq,wc(/usr/bin)

まあ、このリストはGNUで最新の6.12のソースから機械的に抽出したものなので、あなたの環境で使われている実装では、そう実装されているかどうかは知りません（あと、何かのオプションで特に使えるだけ、というものも含まれます、失礼）が....とはいえ、「ファイルの内容の読み書きをするコマンド」については、「ハイフン＝標準入出力」の読み替え対応が進行中である...という雰囲気を感じていただけましたか？ぜひぜひあなたのシェルスクリプトで使ってみましょう！

はい、買いました「集合知プログラミング」。

まだパラ見の状態ですが....要するにこれ、

プログラマのための統計学入門

というタイトルをつけてたら、売れないよね...という側面もあるかもね。ですから、「ネットの上から取れる統計的なデータ」から何か有用な情報を引き出すための、いろいろなテクニックを解説している、という感じの本です。

記述はとくに数式に足はつっこまず、アルゴリズムのレベルでやっつける、という感じの書き方です（最後に付録として数式でかいたものと、コードが対比されてます）。紹介されているテクニックは基本的なものがほとんど（というか、統計学知識の前提はゼロ）で、昔からよく知られているものが多いです...ピアスン相関係数の話から始まって、クラスター分析、因子分析、遺伝的アルゴリズム、ベイジアンフィルター...といった内容。

そういや大学の卒論でクラスター分析を使った憶えもある（FORTRANで書いたよ....）し、ベイジアン・スパムフィルターが話題になりかけた時、面白がって Perl のライブラリをゲットして、それを Java で書き直した...とか、結構私ここらへん好きだったりします。まあ、ものすごく斬新な内容ではないのですが、それでも

それをどう応用して、面白いサービスをするか？

という刺激を与えるという面では、それなりに良いポイントでの出版になるのかも。 「Web2.0 を空論にしないための基礎教養課程」くらいのつもりで読むのが良いのでは。

それでも良い点...というと、統計学って一般には全然知られてないに近い応用科学ですが、「９５％有意」という言葉で象徴される、「すでにある仮説からそう結論できる・できない」を判別するための技法...というのではなくて、統計データから「新しい知見」を得るための技術としての統計学...というあたりでの内容ですから、新鮮に感じる方も結構多いのでは、とも思います。まあ啓蒙的な内容であると割り切れば、啓蒙としての役割はちゃんと果たせているのではないのでしょうか（ごめん、キッツイかな）。

とはいえ、以前「今後（内部でちょっとしたシミュレーションみたいなことをして、比較したいくつかの結果のうち最高のものをとりあえず「解」として返す）手法も一般にアリ、になるのでは」と書いたこともありますが、ようするにそういう手法の取っ掛かりにもなることでしょう。どうでしょうこれ？

というわけで、昨日の昼休みにジュンク堂に行って購入。

マイクロフォーマット John Allsopp 著　毎日コミュニケーションズ刊

昨日は夜用事があったりとか、忙しかったんですが、ちょっとづつ読みました。

内容はですね、概説～利用状況～ＨＴＭＬのPOSH風味な説明～個別フォーマット（rel-*,VoteLinks,XFN,geo,adr,hCard,hCalendar,hReview,hResume,hAtom）説明～事例研究(Cork'd, Yahoo!)～開発プロセス

という感じで網羅的なものです。やはり、6/13の講演でも強調していたことですが、

まだあまりマークアップが使われてない→そのマイクロフォーマットを集約するサービスが開発されない

という悪循環ではなくて、

サービスがあろうとなかろうと、とにかくマークアップする→現実にマークアップされたコンテンツがあるのならば、サービスを作るセンシティブが刺激される

という好循環の方に賭けようという、一種エヴァンジェリスト的な姿勢がうかがわれる部分もあります...まあ、そこらへん好き嫌いが分かれるのでは？

ですから、逆に「自分用サービス」を、そこそこ普及したマイクロフォーマットから作る...というあたりを同時多発的に試みる、という辺りから始めるのが、具体的な普及としては正しいのかも...とも思います。

まあこれは REST とも共通しますが、

「新しいものを作る」ではなくて、すでにネット資産として「そこにある」ものをちょいと手直して「新しい哲学」を吹き込むことで、新しいことをしよう

というマッシュアップ指向..というか「リサイクル指向」な話なのが、今風なのかもしれませんね。

ちなみにオライリー・ジャパンから 7/25 に出る「集合知プログラミング」が、結構このマイクロフォーマットにも関連する話（だろう...というか、集めた後の話中心ですね）なので、コッチも結構期待してます....

前回wgetのハイフンを使った小技(標準出力指定を「-O -」でする)を紹介しましたが、UNIXコマンドのオプションの細かい話....というと

そんなん知ってるだろ！

というノリで(かつて)は全然説明されず、今も

めちゃ細かいことまでは知らんよ

とほっておかれている雰囲気のあるネタについて話しましょうか。

これ実際にはですね、getopt(3) という有名なライブラリ(Linux だと GNU の実装がデフォ。正確には「長いオプション」を扱うのはその拡張である getopt_long(3))を、大概のUNIX基本コマンドが使って、ややこしくも大量なオプションを処理するのが基本なのです。ですから、 getopt(3) のルールをまず理解することが大切でしょう。 まず、コマンド引数は

1. 1. パラメータのないオプション
2. 2. パラメータのあるオプション
3. 3. 操作対象(大概実在するファイル・非オプション)

の３つのカテゴリに分けるのがいいでしょう。

% command -S --single file1 file2

というコマンドラインの場合、「-S, --single」がパラメータのないオプションであり、file1, file2 が操作対象になります。このコマンドを見たとき、 file1 と file2 に対して、何か処理がされるけども、詳細な動作のオプショナルな指定が -S と --single によってされている と理解すればOKです。

オプションの指定方法には大概

1. 1. 頻繁に使い、手っ取り早く指定するための短いオプション(-S)
2. 2. 説明的で判りやすく、具体的な詳細に応じていくつでも作れる長いオプション(--single)

の2通りがあり、一般に「長いオプション ⊃ 短いオプション」の関係になります。だったら「長いオプションだけ、でもいいのかも」と思うかも知れませんが、実は短いオプションの場合、「それを組み合わせて一発で指定する」という技があります(後述)。

また、オプション指定がそれ自身として完結せずに、何かオプションに対するパラメータが必要な時、どう指定するか...というと、

% command -O param --option=param file1 file2

といったかたちで書くことになります。オプションのパラメータは

• A. 短いオプションの場合は空白で区切って
• B. 長いオプションの場合は空白で区切るか、「=」でつないで

指定できます。先ほど述べた「短いオプションを合体させる」というと、こういう感じでよく使いますでしょ(長い表記=l、ファイル種別に応じて末尾に記号を付加する=F、「.」で始まる隠しファイルも表示する=a)。

% ls -lFa

これは、

% ls --format=long -classify -all

と長いオプションで表記することもできますけども(説明的なのがgoodなスクリプト内部だと、わざわざそうするメリットありますね)、

% ls -l -F -a

で分離して書いたとしても同じです(けど短い方がいいですね！)。 このときオプション・パラメータがあるのならば(-w,--widthは一覧表示幅を120文字に広げるので、マルチカラム表示の列数が変わると思う)、

% ls -aF --width=120

を、

% ls -aFw120

と合体最後のオプション・パラメータ(120)だけはそのまま引数に続けて書けば、引数付きオプションを指定できたりするのです。

で、あとヒジョーに有用、でも知らない人は知らない「オプション」として、 -- があります。これはですね、たとえば うっかり「-i」ってファイルを作っちゃって、そのファイルが消せない(% rm -i は問い合わせ付き削除のオプション指定)ことがありますが、実は

% rm -- -i

で消せます(ま、ワイルドカードうまく使って、 % rm ?i で消す手もあるけど)。つまり、「--」オプションは、 このオプション以降は、純粋に操作対象(非オプション)と見て、オプション解析をしない ことを伝えます。ですから、いくら格好がオプションでも、それは操作対象(実在するファイル)と捉えてうまく削除ができるわけですね！

としてみるとですね、実は逆に -- オプションが出ないのならば、操作対象とオプションは、必ずしもオプションが先、操作対象が後、である必要はない！ ということになります(とはいえ「プログラムでのこのライブラリの使い方」でこれは変わることがあります)...これ UNIX の風習とは少し違う気がしますから、 フツーはオプションが先、操作対象が後できっちり分けておく のがどっちか言えば常識だと思います。しかし、そうじゃない扱いもできますよ...というのがこの getopt(3)の懐の深いところなのかもしれません。

ですから、たまにある + を「特殊なオプションとして使う」コマンド(date, head)だって、このgetopt(3) を使うことができますし、あるいは昔の cc が、 リンク順指定の都合で、リンクライブラリ指定(-l)をコマンドラインの一番最後にもってこないといけない... というような特殊ケースにもちゃんと対応できるわけです。

ま、今時はそうしなくても共有ライブラリのおかげでリンク順が無関係になりましたが、Makefile とかでは非共有ライブラリOS対応も兼ねて、今でも一番最後に -l を書いてますよね....

長くなってきたので、「標準出力を表すハイフン」については別稿で。

前回の続きです。

けどぉ、bash だとＤＢにアクセスしたりとか、HTTP でアクセスしたりとか、面倒じゃないのかなぁ....言語サポートのあるスクリプト言語の方がいいのでは？

とお考えの諸兄姉に。それは間違いです！

たとえば、ＤＢアクセスだと（PostgreSQL＆Cygwinの場合）

/cygwin/c/Program\ Files/PostgresSQL/8.1/bin/psql -U postgres -c 'select name from sometable where somecond=true' dbname | tail +3 | tac | tail +3 | tac

という感じで、-c オプションでコマンドをPostgreSQLのフロントエンドに渡して実行させればＯＫです。結果はカラム名とか結果行数とかスクリプト的には余計なものが入りますから、

tail +3

先頭から３行を無視

tac

入力を行単位で逆転

のフィルターを使えば、本当に欲しい結果行だけをコマンドライン的に得られます。

また、HTTP でアクセスできるネット上の情報ならば

/usr/bin/wget -O - http://some.url/   2>/dev/null | grep someMark

の要領で、wget を使えばよろしい。-O オプションで出力ファイルを指定するけども、これは「-」指定すれば標準出力になります（これよくあるパターンです）。wget は取得状況ログが標準エラー出力に出ますが、これはウルサイだけなので、/dev/null にリダイレクトして黙らせます。あとはこれでパイプラインで何とでも加工すればよろしい。

...という具合に、本当は bash ＋標準UNIX環境というのは、極めてプログラマ・フレンドリな環境なのです。

すべてのテキストはパイプラインに流せて、好きなように加工してよろしい！

というのが、そもそもの「UNIX 思想」なのですよ。その枠組みを提供するのがシェルですし、特に bash と言えば「プログラムできるシェル」として、長きに渡って実績のあるものなのです.....シェルを使いましょうね！

さて、仕事からのネタです。Java ってマクロがないですから、

「定義」をするために、複数の関連しあうシンボルを定義し、データをとして作り上げるコードが、ムチャクチャたくさん必要だけど、作業自体は機械的で１回やればいいだけ...

な場合、「何かコードジェネレータ（「達人プログラマ」で言う「消極的コードジェネレータ」です）にそういう仕事はさせたい」と思いませんか？しかし、Java で開発しているケースでは、適当なスクリプト言語インタプリタがありません...から、

1. 1. Java で使い捨てプログラムを書く
2. 2. Emacs とかエディタのマクロ機能を使い倒す
3. 3. 何かスクリプト言語インタプリタを導入する（Perl でも PHP でも Python でも Ruby でもお好きなものを...）

というあたりの解決が多いのかなぁ...とも思います。しかし、

Windows 環境だって Cygwin とか使ってるジャン！

というプログラマの現実から見るとき、第4の解決策として

4. 4. bash で書く！

というのがあるのです。実はコレ私は最大の特選言語なんですね！ パワフルで柔軟、しかも「特に何もしなくてもソコにある！」というメリット付きです。

まあ勿論、「コマンドラインの延長線上としての、シェルスクリプト」の知識では、これはできません。ちゃんと、「スクリプト言語として、bash を使い倒す」という勉強をしなくてはなりませんが、しかし一度身につければ、極めて強力なツールです。たとえば、適当なファイルから、1行の中に空白で区切られた２つの文字列を取得し、行数分だけループする...というありふれた処理は、

while read var1 var2
do
  echo "$var1 -- $var2"
done < ./myfile.txt

という風に書けてしまいます...ポイントは勿論、done（というかwhileブロック）に対してリダイレクトが書ける、ということと、組み込み命令のread が、その行を分解してシェル変数 var1, var2 にセットしてくれる、ということですよね！

ですから、

1. 1. このループ処理
2. 2. ヒアドキュメントを活用した出力フォーマット
3. 3. 文字列加工は sed を活用
4. 4. 数値計算は expr を活用

...といったあたりの処理を組み合わせれば、コードジェネレータくらいのことならばお手軽に出来てしまうのです！ わざわざ「コードジェネレータのために Perl を入れる」とかしなくて済むのです。どうです？勉強する価値がこれありますよ！

ちなみに「スクリプト言語としてのシェル」を勉強すると、自動的にコマンドラインにも強くなります....そっちも極めてイイことですよねぇ...

というのは、XMDP（XHTML Meta Data Profiles） という規格です（判りやすい紹介）。これですね、前回の続きで、

head タグの profile 属性値で示される URL にある（はずの）メタデータプロファイルに、使われている rel 属性値がどういうものかの定義があるはずだ.....

の「データプロファイル」のフォーマットに関する規格なんです。「profileで示される URL にあるはず」と HTML4.01 で決まっていながら、

どう書いたらいいものやら？

というのが全然決まっていなかったというヒドイ話です。まあ誰も使っていなかった...のが実際のところなので、「決まってないので書けない...」でもとりあえず問題なかった、ということです。とはいえ、この rel 属性についての profile 属性指定のやり方は、HTML5 では撤回されそうです。ですからちょっとこの XMDP 自体は宙に浮きつつあるのですが....しかし、

自分で作る（こともできる）、タグ属性値のコレクションを公開するには、どうすれば？

というのはより汎用的に、マイクロフォーマットで重要になってきつつあるわけです。この XMDP が、たとえば hCard や xfn のような構造的なマイクロフォーマット（ですからいろいろ沢山のプロパティ名がある）で、

それらの名前を定義する

ためのフォーマットとして採用されるわけです。で、面白いのはこの XMDP のお姿で、中身が

<dl class="profile">
  <dt id="author">author</dt>
  <dd>A person who wrote (at least part of) the document.</dd>
</dl>

のプロファイルで、author というプロパティが定義されることになるわけです...ここで dl, dt, dd の使い方は、まったく HTML での使い方そのままだ、というのがポイントですよね。

要するに、

新しいボキャブラリを作るよりも、既存のボキャブラリで誰でも知ってるようなものを仕立て直す

という「デザインパターン」で、実はマイクロフォーマット自体が出来ているような雰囲気なのですね....とりあえず既存のＨＴＭＬの「上に」乗っかるマイクロフォーマットの、そのプロパティ定義自体がＨＴＭＬの上に乗っかった感じで定義されるのって、何かメタな感じの「デザパタ」で面白いでしょ。

というのもたまにはあるようで（1.x系の話です）。

まず最初はこういう問題でした（こっちは単純）。

いくら forward を struts-config.xml に追加しても、そのシンボルのプログラム上での解決に失敗する

.....あ、スペルミスじゃないです。原因はですね、

struts-config.xml に同じ action がダブって定義されていて、最初に登場する方を修正していた

ということでした。要するに、

同じ action があれば、Struts は黙って上書きする

という動作のようです。ごめん...でも、struts-config.xml が 256K byte もあるんです。気がつかないっす。

---

２点目はもっと面白いです。こっちは同僚に指摘され、修正しました。問題は、

私が追加した Form の JavaBeans について、同名の Bean が、その Form クラスの継承クラスで定義されており、しかも、私が定義したのは「単純なBean」で、継承クラスで定義されていたのは「インデックス付きのBean」だった

のが原因です。Struts はリクエスト時に、プロパティのセットをリフレクションを通じて行います。ですから、「プロパティ名」を手がかりにして、リフレクションをするのですが、Struts の「実用性」から、この「リフレクションのやり方」が一般的なリフレクションよりも少し多機能に設定されているのです。要するにプロパティを

base.myProperty
array[3]
map(key)

とか書ける...という便利な仕様のことを言っています。ですから、これは便利なのですが、

継承クラスで配列アクセス用とかMapアクセス用とかでそのプロパティ名について引数付きのゲッタが定義されているとき、基底クラスでシンプルな引数なしのゲッタを定義しちゃうと、Struts のリフレクションが「どれを使えばいいのか」誤解して例外を投げる

という想定外の動作をしてしまうのです。まあ、この部分実は「Struts の仕様」でさえなくて、

org.apache.commons.beanutils.BeanUtilsBean#setProperty()

の仕様、ただしソースに、

警告：　このメソッドの挙動は、Struts 開発コミュニティに相談することなしに、変更してはならない。上に掲げた JavaDoc に書かれていないビミョーな機能があり、それが Struts にとってこのメソッドが役立つ大事なものだからだ。

とコメントされてます....要するに「Struts にとって必要だから」で開発されたこのライブラリの「青春の尻尾」を残しているわけですね....

まあこれで事情はわかります。しかし、ホントの問題は、

このプロパティ名のバッティングは、「自分が直すクラスを直したツモリ」でも、「自分の関心がない」（継承クラスを使った）部分に意外な影響を与えちゃって、しかも Java のコンパイル時の静的なチェックによって、絶対検出しようがない...

困ったということです。要するに、

 Java でのプロパティ（JavaBeansによる後づけですが）

と、

Struts が同じプロパティ名と捉える範囲

が食い違っているためにこれが起きるかも、ということです。ふう、世の中ままなりませんね。

やり方、って一つとは限らないのが真理かもしれませんね。

いろいろとマイクロフォーマット関連で見ていって、見つけたのですが、

XHTML Role属性モジュール（W3C Working Draft, 2007/10/04）

というのがあります。

一部で誤解があるかもしれませんが、マイクロフォーマットの本質って、

属性値の使い方に関する、公的なかたちでの合意プロセス

じゃないか...と思います。つまり、

勝手に自分が決めたオレオレ・マイクロフォーマットは、実はマイクロフォーマットとは呼べない！

のですよ。「マイクロフォーマット」と呼ぶためには、やはり Wiki での議論を踏まえた上で、コミュニティに認められてなくてはならないわけです。CSSを適用するために class 属性に event と付けることと、マイクロフォーマットとして使うために vevent とつけることとは、同じに見えても、ホントはしていることが「まったく違う」わけです。

rel="tag" とか rel="nofollow" といった、「rel 属性の属性値」として定義されたマイクロフォーマット、というパターンもよく知られています。しかし、これ本来のHTMLの規格だと、

head タグの profile 属性値で示される URL にある（はずの）メタデータプロファイルに、使われている rel 属性値がどういうものかの定義があるはずだ.....

ということになっています。知ってました？ あ、これ知らない方多いでしょうね....というわけで、この規格は全然まともに使われていない、というのが実情です。で、本題の「XHTML Role属性モジュール」は、こういうタイプの「属性値の定め方」を、role という属性について新たに定義しなおすものです。ですから、この role 属性の値も「ページの中での役割」を記述するもので、簡単に言うとたとえば、

banner＝バナー広告、main=主要部分、search=検索セクション、navigation=他のページへのリンク

といったものがあらかじめ定義されています。しかし、この role 属性の面白いのは、

自分用に勝手な role 属性を決めてよく、名前空間を使ってうまく公開できる

という楽しい性質があります。

<html xmlns:myrole="http://mydomain.jp/role/sitemap#">
<ul role="navigation myrole:sitemap">

という感じでオレオレrole を使うことが出来るようになります....ですから、これマイクロフォーマットのように使えるのですが、完全にオレオレなものなので、正しい意味でのマイクロフォーマットではありません。

ですからこれうまくマイクロフォーマットと「住み分け」ができるのでは...と思いませんか？ 意外にコレ、マイクロフォーマットを補完する、いい規格になるのでは...

そういえば、　「はてな」のアカウントを示すマークアップを作り AutoDiscovery できたらいいじゃん！...という話で３年くらい前にモメてましたね。その時も「固有名詞が入るような特殊化したマイクロフォーマットは認められない！」という議論が強かったので、「マイクロフォーマットのデビュー」がちょいとチャンスを逃した...のかもしれませんね（RESTで有名な山本陽平氏とかおのひろき氏とかろいろ書かれてますね）。

 

私の趣味...というと実は宝塚歌劇なんですが、こんなニュース。

宝塚歌劇95周年の2009年より、宝塚大劇場・東京宝塚劇場公演を年間10興行に変更し....

要するにですね、昔は花月雪星の４組で年間８番組でしたが、1998年に新たに宙組が出来まして、５組で年間８番組を回していました。それを年間１０番組に変更しよう....というニュースです。

しかしですね、現状の「５組で年間８番組を回す」というのは実にイイやり方なのです。なぜって...それはですね、「５と８とが互いに素」ですから、特に何も考えなくても、毎年各組平等にスケジュールが回り、たとえば年明け番組でも各組の回る確率は同じになるのです....そう考えてみると、５で割り切れない８から１０に年間番組数を増やすというのは、「余計なことを考えなくてはならない」というややこしい話になりそうです。「割り切れる数でデザインする」のが必ずしもいいというわけではないのですね！

同じような現象...というと、ハッシュテーブルでもあります。ハッシュテーブルは、

ハッシュ関数による大まかな分類（ノンリニア）→厳密な一致検索（リニア）

と２ステップに分けてスピードを稼ぐアルゴリズムですが、特に第１ステップの「ハッシュ関数による大まかな分類」での、その分類カテゴリをバケツに例えて「ハッシュバケット」と呼んだりします。で、この「ハッシュバケット」の数は任意で好きな数をとってもいいのですが、

素数だと効率がいい！

という有名な話があります。これは計算されたハッシュ関数の値を、このバケツ数で割った余りで、「どのバケットで管理させるか」を決定しますから、ハッシュテーブルの効率とは、

1. なるべく均等にバケツを使うのがいい
2. なるべくハッシュ関数の値と素になりやすい数がいい
3. だったらバケツ数は素数。

という論理で、バケツ数が素数か否かで影響を受けるわけです。

ですから、固定したバケツ数で運用するのでしたら、適当にバケツ数は素数で決めればいいです。しかし、Java のハッシュテーブル java.util.Hashtable みたいな、「バケツ数を自動で拡大していくハッシュテーブル（これはバケツに値が溜まりすぎないようにするためです）」の場合、

なるべく「素数っぽい」バケツ数に拡大するのがいい

ということになります。ですから、java.util.Hashtable の実装では、バケツ数の初期値は 11 で、それが n = 2n + 1 という式で順次拡大されていきます。この計算式で n0 ≡ 2 (mod 3) な初期値(11)というのは、

２の倍数と３の倍数にならないので、素数が出てくる確率が少し高い

うまい式です....とはいえ、上には上があるもので「オイラーの素数生成式」と呼ばれる式

n2 + n + 41

という面白い性質を持った式があります。これだと何と、n=39 (1601) まで延々素数が続き、10万以下の値では約７割が素数、という驚くべき結果になります。もし、

完全に素数であることは求めないが、素数だといろいろと性質がいい

数の系列がプログラム上欲しい時、これを使うと便利なのでは（ハッシュに使いたいなぁ...）。

という感慨が、実はマイクロフォーマットについてあるのですね。

あ、マイクロフォーマットは「やさしい、普及しやすい方」です。「難しく普及しにくい方」というのは、ＸＭＬの名前空間ベースのアドオンのやり方です。実際、マイクロフォーマットのライバルとして、RDFa という規格（W3Cのドラフトのようです）がありますが、

<html xmlns:cal="http://www.w3.org/2002/12/cal/ical#">

というふうに名前空間を宣言して、

<p role="cal:Vevent">
.....
</p>

みたいに使うもののようです。まあ、これですと、タグや属性に名前空間修飾が付くような、ガチのXML名前空間使いというほどでもないので、複雑さはそれほどでもないのですが、実際 XML 名前空間というのは「困りモノ」だったりすることもあるわけです。

プログラマだったら、XML名前空間を理解して使うことはそれほどには難しいことではない（それでもややこしいです....）でしょうけども、実際にはたとえば、

CMS のテンプレートをいじって、正しく XML名前空間付きの○○用のテンプレートを追加する

が一般ユーザレベルでできるか....というと、これかなり難しいと言わざるを得ないです。要するに、

○○を追加するためには、それ以前（コピペ一発で済まない「かなり前」 ）で××を追加しておく必要がある

というタイプの入れ子ルールを一般向けで広く普及させる、というのはやや難しいのではないのでしょうか。

マイクロフォーマットの強み...というのは、きっとそれが「XMLの拡張ではないこと」なのでしょう。マイクロフォーマットは単なる「ボキャブラリの使い方」に過ぎませんから、「構文的な追加要素」であることを可能な限り避けているわけです。これは洒落みたいなものですが、

マイクロフォーマットはセマンティック・ウェブを実現するための、まったくセマンティックではないやり方

なのかもしれませんね....