延髄からどんどん電波が湧き出してきます。困ったことです。
デジカメの高解像度化が進んで，1枚の写真が数十MBにも達すると。
これだけデータがでかくなってくると，それを処理するプログラムのサイズが相対的に小さく見えてきます。例えばIJGのlibjpegなら，コンパイルオプションやターゲットプラットフォームにもよりますが，100kB程です。ところがオーバーメガピクセルのデジカメ写真なら数十MBもいまや珍しくないしょう？
こうなってくると，データの処理をするプログラムをデータ自身にひっつけて持ち運んだ方がええんとちゃうかという気すらしてきます。
例えば最近は画像処理のためにカメラのパラメータあるいは諸元が必要だと聞きます。CCDの補正あるいは校正情報まで必要と。つまりそのデータはそのカメラで撮影されたという情報がないと不完全だというのです。ほんとですかね？
しかし撮影も測定の一種だと考えれば，トレーサビリティの観点からは当然のことのようにも思えます。別の手段は規格化です。物差のトレーサビリティのために物差の製造工場の名前を知りたがるのはばかげています。JIS2級と書いてあって定期的に校正しておれば，それは3級よりも真値に近く，1級よりは真値から遠いと分かる。それで充分です。
すぐ話が逸れるのは悪い癖ですな。無駄に知識をひけらかす困ったチャン。しかもそれが間違いだらけだという。
とにかく，プログラムの表現を共通化して可搬バイナリに加工しデータと引っ付けてポータブルにすれば何かが得られるのは分かりきったことです。
例えば，各種のアプリケーションサーバーは，まさにそうなっています。巨大なデータベースは，それをハンドリングするシステム一式ともはや切り離せません。例えばPCやサーバの仮想化というのは，システム一式を手間をかけずに行き当たりバッタリでポータブル化するための手段のひとつでしかありません。システムインテグレーションというのは，データとプログラムの癒着作業です。切り離せるというのなら，毎度毎度"インテグレーション"する必要は無いはず。
例えば，遺伝情報はそれを転写して利用する仕組みと常にセットで維持されます。遺伝情報だけを取り出しても，それは記号の並びでしかなく，ネコの日めくりカレンダーほどにも役に立ちません。遺伝情報を適切に解釈してたんぱく質を合成したり，別の遺伝情報の解読のスイッチをON/OFFするための仕組みが常に必要です。最近まで知らなかったのですが，塩基配列というシーケンシャルな記号の並びだけが遺伝情報ではありません。3次元空間における配置にも意味があるのです。しかもそれは転写操作において動的ですらあります。しかしながら，その配置は塩基配列から再現可能でもあります。んなことはどうでもよくて，とにかくデータとプログラムは切り離せません。
極端な話，データの種類だけプログラムがあっても良いのです。そうすれば共通データフォーマットの策定のために，しょうもない会議を何百回も開く必要がなくなります。「使い捨て」フォーマットでもOK。理想を言えばもう1段高い抽象化レベルで共通のインターフェースがあれば素敵でしょうけどね。
だけど現状を見てくださいよ。あるプログラムAのデータを別のプログラムBからハンドリングできないでしょう？XML使ったって同じことです。読み込めても意味が違う。そこらへんにヒミツが隠されているのです。
(２００６．１２．０２リンク追加)
