日々の破片

_ 最速

原文だと "world's fastest personal computer" 。

日本だとJAROみたいな機関があるが、イギリスにはIndependent Television Commission (ITC) というところが管理してるんだろうか。名前だけからいくとTV局の自主管理のようだな。

_ 貼れるかどうだか見てみよう

アイノラのシベリウス(舘野泉)

あっ、amazonに画像が無いのか……

を買いました。で、今、聴いているところ。

_ 絵が出ないとつまらないな

Heart & Soul(Joy Division)

ちなみに、ファクトリーのオリジナルのLiveビデオを持っているが、ビジュアルは死ぬほどかっこ悪い。なんか、イアンカーティスの動きはミイラ男のダンスという感じで肘と膝が曲がらないし、ごっついし。20年以上見てないから多分カビカビになってるだろうな。

なぜ、いきなりジョイディヴィジョンかと言えばミュージックのお勧めだったからだけど、確かにエコーアンドザバニーメンと被るところはないわけじゃないからなぁ。

って言うか、80年にビートルズとかストーンズとか聴いたり言及したりしてるオヤジってのは相当うざったい感じだったから、あのくらいうざったいだろうな。ふんふん。こうやって若い頃に培ったせっかくの憤激や嫌悪を呑み込んで人は無神経なオヤジになるのか。おもしろい。

_ ルーズスキーマ

XSDの型システムを肯定した上で、ここから構造を取り除くということを考えて見る。

でも、ここは<や>が書くの面倒なんで裏庭かも。

とりあえずメモと。

必要性：コンテキストで判断できる場合に大げさすぎ。

スローガン：コンテクスト対コントラクト

って言うか、ユーザー定義型を持たない型システムというか、すべてを配列とプリミティブ型でインスタンス化する。

インスタンスの処理をするのは、コンテキストを知っているからいいじゃんという発想。ANYは嫌い。ANYと名づけるくらいなら未知のものは未知のものとしておいておきたい。言及は避けるべきではないか。

コントラクトが無いわけではなく、各要素名が属する型（ただしプリミティブか配列か）の検証は可能。

コンテキストはルート要素で判定。ネームスペースはあり。ネストもあり。

XPathとは相性が悪いのでは？

検索が必要なほどの大物であればコントラクトで構わんじゃないか。

後付けのスキーマ。

おいらは、このXMLインスタンスをこのスキーマとして処理するんだから、こういう具合にインスタンス（オブジェクト）化せよ、とパーサに指示をする。

同一のXMLインスタンスを利用する側が再構成／補完／ルール付けをコンテキスト依存でパーサに指示。

XMLインスタンスは、オブジェクトがシリアライズ／デシリアライズされたものではなく、単なるメッセージとして、オブジェクト間でキャッチボールされる。玉をどう扱うかは受け取った側の勝手。

コンテキスト依存の問題点： 暗黙のルールの爆発

->爆発する場合は（予想がつくはず）最初から厳密なコントラクト。

->成長とともに爆発する場合は、後から厳密なコントラクト。既存のルーズアプリケーションは影響されないはず。機会があれば変えれば良い。

つまりハッシュですか？

多分。しかし、型検証は行われている。要素名はピア間で共有される。すなわち最小のコントラクトはある。