最近の記事群で、「クライアント側の状態遷移を中心にしてWebサービスの設計をしたらいいよ」と僕は言っているわけで、実践もしているのですが、まー課題もありますね。
もともと僕は、ハイパーリンクのグラフ構造を正確かつ完全に把握したいという強い要求・願望を持っていました。その1つの方法を提案したのが次の記事です。
少し長くなりますが、上の記事の最後を引用します。
一旦有向グラフが出来てしまえば、ノード間の可達性、ハブノードの存在、ノード間の経路距離などを判定／算出できます。入次数／出次数（in-degree/out-degree）などから何か計量的な指標が得られるかも知れません。特定のノード（Webコンテンツ）から距離nの近傍（距離がn以内のノードの集まり）を観察したり、可能な経路をすべて列挙してみることで、サイトに関する知見が得られるかも知れません。
「知れません」と書いたのは、実際にやってみないと有効性が分からないからです。もちろん、僕は有効だろうと思ってますがね。URLが、対応表を引くキーとかプログラムを起動するトリガーだったりすると、サイト内全コンテツを列挙して静的解析を遂行するのはかなり困難だと思います。「静的サイトと同じ作りにする」に拘っているCatyだから実行可能なタスクだと思えるので、やってみる価値はあります。
この当時僕が想定していた方法は、HTMLファイルを解析してハイパーリンクを取り出して、それをもとに有向グラフを描くという方法です。それができる前提は、「URLの書き換えやマッピングは一切しない」ことです。しかし、この前提は崩れてきているので、ファイルシステムをスキャンしてグラフを描く方法は使えない場面が増えています。
であるなら、ハイパーリンク（＝クライアント側の状態遷移）を記述するデータを別に持てばいいだろう、と。それをもとにグラフを描けるでしょう、と。そこで「Webサービスを設計するための単純明快な方法」が登場するわけです。これは方法だけで、ツールは存在しません。その点は気にしています。
今述べたことを実践するには、ある程度の指針や方法が必要です。そこで、僕自身が使っているやり方を紹介します。あまり完成度は高くないし、現状ではサポートツールもないのですが、単純明快なのがメリットです。
現状、このような発想や方法を支援するツールが何も無いのがつらいところです。が、定式化がシッカリすれば、ソフトウェアによるサポートが特別困難だとは思っていません。
仮に、なんらかの「ハイパーリンク（＝クライアント側の状態遷移）を記述するデータ」が定義できて、それをもとに有向グラフが描けたとします。果たしてそれでいいのでしょうか？ 僕は最初「それでいい」と思っていました。
なにはともあれ、ハイパーリンクの全貌が目視で確認できたら、それは気持ちいいでしょう。精神衛生上は非常にヨロシイ。ですが、そのハイパーリンク -- グラフ構造ですが、それが正しいのを目視で確認するのは容易じゃないです。例えば、ノードが100個ある有向グラフを見せられて、「これは正しい？」と聞かれても答えられません。
事情は型システムと同じです。目の前に出されたデータが、型の制約を満たしているかを人間が目視で判断していたらやってられない。だから型システムがあるわけです。型はスキーマで定義され、バリデータでチェックされます。同様に、“ハイパー型”が“ハイパースキーマ”で定義され、“ハイパーバリデータ”でチェックされないとやってられない。
「ハイパー型システムが必要だなー、欲しいなー」と、僕は切実に思っています。
「ハイパーリンクはホントウに難しい」より引用：
ハイパーオブジェクトとトリガーという概念は、単なる雰囲気や比喩としてだけ語っていてはダメなんです。ソフトウェアにも人間にも明白に分かる記述が必要です。
おおよその枠組みは「Webサービスの設計： Webフローの図示法を再考する」で触れたようなモノでいいだろう、とは思っています。とはいえ、おおよその枠組みを考えるのと、細部を詰めるのは別な作業なので、試行錯誤の日々が続くでしょう。しゃーない。
