このブログの更新は Twitterアカウント @m_hiyama で通知されます。
Follow @m_hiyama

メールでのご連絡は hiyama{at}chimaira{dot}org まで。

はじめてのメールはスパムと判定されることがあります。最初は、信頼されているドメインから差し障りのない文面を送っていただけると、スパムと判定されにくいと思います。

参照用 記事

なにかが抜けている -- Webと関わる人間はどこにいる?

winplusさんが、色々と有意義な考察をなさっています。
http://d.hatena.ne.jp/winplus/20120716/1342407196

「アプリケーション状態エンジンとしてのハイパーメディア」というのは、アプリケーション状態はすべてリソース(≠<リソース>)として存在しているため、リンクをつうじてリソース間を移動することがそのままアプリケーション状態の遷移となる、ということだと理解しています。

ここで、「リソース」と「<リソース>」が区別されていますが、「リソース」に関しては、次の説明で十分だと思います。

リソースにはぜんぶURLをつける。つまりURLでリソースを識別できるようにする。

このような解釈に対して疑問に思うことがあります。この疑問が解決すれば、「<リソース>」から「リソース」に乗り換えてもいいと思っています。

[追記]「人間はどこにいる?」という見出しに深い意味はないので、気にしないでください。人間の選択や入力行為を伴う状態遷移の完全な履歴が、URLの空間のなかにエンコードされて存在しているんですか? という程度の話です。[/追記]


2010年4月に「Webアプリケーションの入出力と状態遷移」という記事を書いたのですが、そのなかの「7. なにかが抜けている」という最後の節で、僕は次のように述べてます。

ブラウザはユーザーエージェント(人間の代理)と呼ばれるわけで、「ブラウザ自身が」じゃなくて「人間が」リクエスト発生源です。人間と一緒になったブラウザは自発的な行為が可能となります。レスポンス受理に関しては、サーバー側で生成されたデータを鵜呑みにするだけで、ブラウザがサーバーの奴隷のようでしたが、サーバーは発行されたリクエストをひたすら処理するだけと考えれば、サーバーがしもべとも言えます。

どっちが偉いかはともかく、状態遷移機構を見ている限り、サーバーもクライアントもオートマトンに過ぎず、そこから自発性は出てきません。Webが活発にウゴメキ続けるのは、人間達の世界が動いているからでしょう。

「URLとそれを結ぶ有向辺で状態遷移*1が決まる」のような発想を、僕がどうしても受け入れられないのは「なにかが抜けている」からです。その「なにか」は人間です。ほんとに生きている人間でなくてもいいのですが、自発性を持ってリクエストを発生させる主体です。その主体(人間またはソフトウェア)は次のことを行います。

  1. Webページ(一般にはハイパーメディア・オブジェクト)のなかにあるたくさんのリクエスト先から、1つのリクエスト先を選ぶ。
  2. 必要とされる入力データを生成する。
  3. 実際にリクエストをする。

二番目の行為が伴うのを常に僕が仮定していることは「思考実験: HTMLのa要素はナシにしてform要素だけを考える」に書きました。人間がHTMLフォームを埋める行為が二番目の動作の典型です。

状態遷移系(オートマトン)の一般論でも、状態空間Sと入力値(入力記号、ラベル)の集合Vがあって、遷移は、S×V → S という(たいていは非決定性)写像で定義されます。対話的に進行する一連の事象を記述するために、なんらかの状態空間Sを想定します。状態点s(状態空間Sの要素)を固定して、次の状態がs'だとしましょう。通常、sからs'が一意には決まりません。

状態空間S以外に、リクエスト先を識別するIDの集合をXだとして、先に述べた「主体の行為」をもう一度書くと:

  1. Xの要素xを選ぶ。
  2. Vの要素vを選ぶ。このとき、任意の値を選べるわけではなくて、選んだxに応じた制約があるのが普通。
  3. 値vをxに送る。

このように、sにおいて選んだ (x, v) に対して次の状態 s' が決まる*2というのが僕が考える「対話における状態遷移」のモデルです。

Xは「リソース」、あるいはURLの集合だとみなしてもいいでしょう。リソース間の接続性で「対話における状態遷移」もモデル化できるということは、Xをノード集合、リソース間の接続性を有向辺とする有向グラフの情報から、状態遷移 S×V → S を再現できるという主張だと思えます。

そんなことがほんとに可能でしょうか? 僕が最初に想定したXでは不足で、X' = X×V とする必要があるでしょう。拡張されたURLの集合X' は、インターネット上のアドレスに加えて、ユーザーが入力した入力値も完全にエンコードされたIDとなります。HTTPメソッドをGETに限り、ユーザーの入力をクエリーパラメータにエンコードするなら確かに出来そうです。

さて、僕の疑問とは: GETとクエリーパラメータしかないWebに現実性がるのか? それとも、(直前の疑問を無効化するような)今僕が辿ったストーリーとは別に「対話における状態遷移」をモデル化する方法があるのか?

[追記]もう少し具体的に言うと、もともとが複雑な手続きをプログラムにした業務アプリケーションなんかだと、うっとうしいフォーム画面が十枚くらい続いたりするのですが、こんなアプリケーションを使っているユーザーがたどる可能性がある全ての事象列(膨大!)は、URLと接続性の有向グラフ上の経路の集合と同じなんでしょうか?[/追記]

僕が欲しいのは、ユーザー(人間じゃなくてもいい)による自発的なリクエスト先の選択と必要なデータの入力行為を含む対話のモデルです。この要望が見当違いである可能性は次の2つでしょう。

  1. そもそも、そんなモデルは必要ない。欲しがらなくてもいいんだよ。
  2. URLとその間の接続性だけで、お望みのモデルは構成できるよ。余計なことを考えなくてもいいんだよ。

*1:「状態」、「状態遷移」という言葉の解釈がズレている、という問題があるようです。ここでの状態、状態遷移は、ごく一般的に「ソフトウェアの振る舞いをモデル化する手段」という程度のものです。

*2:s, x, vを決めても、s'はなお非決定性でしょう。s'はサーバー側の状態にも依存するからです。