STなんとかとSTTP

時間軸に沿ったオブジェクトの移動・変形に関するプログラミングを可能にするインタプリタ型言語「Streaming Text なんとか」と、その通信用プロトコル「Streaming Text Transfer Protocol」に関するまとめ。

概要

ゲームのプログラムでキャラクタの画像をアニメーションさせながらテキストを表示するに当たり、画像を表示する順番やテキストを表示する時間間隔を指定できる汎用的なインタプリタ型言語があれば便利なので、既存の言語を参考にしながら新しく設計することにした。

その言語で書かれたソースコードは、ストリーミング配信し、クライアント側では受信したぶんから順次実行できるようにする(演出上の)目的があるため、 Streaming Text なんとかという言語名にするつもりだ。XML/HTML、Sakura Scriptで使われる概念をいくつか参考にしている。

ストリーミング配信に使うプロトコルは HTTP と同じレイヤーで極めてシンプルな STTP（Streaming Text Transfer Protocol）というものを想定している。

これらの言語仕様とプロトコルは、今後インターネットで動画をはじめとするマルチメディアがますます積極的に配信されるようになったとき実用的な内容・思想を含んでいると考えられるため、なるべく拡張が容易な設計にしたい。

XML/HTML と Sakura Script 、STなんとかの関係

以下いいところ、悪いところ、と書いているのは「STなんとかの目的のために」いいところと悪いところであって、一般に言語仕様としていい・悪いと言える点を指摘しているわけではない点に注意されたい。

XML/HTMLのいいところ

XML/HTMLが今ほど(誤った言語仕様の解釈に基づいた解説がWeb上に散見されるほど)知られるようになったのは、言語記述とデバッグがしやすかったからではないだろうか。メモ帳でタグを書き、ブラウザでファイルを読み込めばすぐさま内容が確認できる手軽さがキモだったように思う。

STなんとかはそのような手軽さを保証するため、人間が読めるテキスト形式で全てを記述できる言語とする。（バイナリによる拡張はありうる。）

また、XMLには名前空間を追加して機能を拡張できる、メタ言語仕様的な仕組みがある。これもXMLファミリーの普及に一役買ったのだろう。

STなんとかは、必要に応じて読めるデータフォーマットを追加できるような言語にする。

XML/HTMLの悪いところ

ただ、STなんとかは次の一点においてXML/HTMLと根本的に異なる。「文書をむやみに構造化しない」のだ。

極端な「構造化」思想の厄介な点

現在の主なプログラミング言語は手続き型と関数型に大別される。

XMLは主にインタプリタによって即時実行される高級言語であり、作成できるプログラムに制約が多いためあまりその分類が意識されることもないが、仕様としては手続き型と関数型の境界に位置しているように見える。

つまり、パースされる順番によって基本的には兄弟関係が時系列の意味を持ち、手続き型のようでありながら、プログラム全体が階層構造によって特徴づけされる点で関数型に近い構成を成している。

後者の、文書を構造化(structurize)によって意味づけ(mark up)する特徴は今ではXML/HTMLの根幹をなす思想だが、HTMLのインタプリタ(レンダリングエンジン)にとっては意外に厄介な性質だ。

文書全体が一つの根を持つ木構造をなしているため、文書の正当性は木を全部読み込んでからでないと判断できず、厳密なパースとレンダリングを目指すならいったん文書全体を読み込み終える必要がある。ブラウザがWebサイトを表示するとき、読み込みが終わるのを適当な時間待つ仕様になっているのもこのためだ。

厳密な構造化と人間性のはざまで

ただし、HTML文書は多くの場合、原則画面上に表示される内容から順に記述される。人間の頭の中が時系列で物事を語るようにできているのだから当たり前といえば当たり前だろう。

その特徴をとらえれば、インタプリタが読み込みとレンダリングを同時並行で行えるような言語仕様を組み直せるはずだ。

そもそもすべてのタグは(構造を正しく保つために)閉じなければならない、というのはHTMLがXMLのサブセットとして定義され直した時期にスポットが当てられた原則であり、かねてより、閉じなくてもよいタグ、つまり(改行や水平線などのように)単体で何らかの機能を果たすタグは当然のように存在した。

タグという呼称は「くくりつけるもの」という意味を持っているが、何重にもテキストをくくりつける「構造化」思想は、行き過ぎると非人間的な(人間向きでない)言語仕様を生んでしまう。

Sakura Script 的な何か

Sakura Script は言語仕様がインタプリタのプログラム内で静的に定められており、基本的には拡張性に乏しい。しかし、その点を除けばストリーミング配信に向いており、実際SSTPというプロトコルで配信されている優秀な言語仕様であると言える。

STなんとか＝ストリーミング配信向け＝人間的（ファジィ）

STなんとかはソースコード全体がひとつの根を持つ木構造にまとまるわけではない。あくまでストリーミング配信を念頭に置いて文書の先頭からパースしていけるようにし、Sakura Script のように文書の途中に制御コード(簡単なタグ)を挿入することで機能を持たせる。制御コードという概念は Sakura Script を参考にしている。Sakura Script では で始まる文字列が制御コードだったが、STなんとかはHTMLライクに < で始まる制御コードを用意する。

Sakura Script とは異なり、閉じタグに相当するものも用意し、対応する既出のタグで適用された設定を取り消して元に戻す意味を持たせるが、閉じタグはなくても問題なくスクリプトが実行されるようにする。

STTPとHTTPの関係

ほとんど一緒の予定。(Keep-Aliveを基本にする？詳しくは未定。)

応用範囲

ユーザインターフェースに関するごく近未来の予想

デスクトップ環境の3D・アニメ化

現在、一般に広く普及している主要OSのデスクトップが続々3D化されて(3Dの描画エンジンによって管理されるようになってきて)おり、近い将来、3Dのデスクトップマスコットをはじめ、多くの3DCGを普通のコンピュータのディスプレイ上でリアルタイムにアニメーションさせられる環境が整う。

人間的なユーザインターフェースの要請

また、人工知能研究のスピンオフで、人間工学的に使いやすいインターフェースとして、人間的な振る舞いをするエージェントが多くなってくることが予想される。

「構造化」されたユーザインターフェースの衰退

「構造化」思想を基本としたユーザインターフェース、例えばツリー構造で目的の文書にたどり着くまでに何階層も深く潜らなければならないヘルプファイルなどは、ときに情報量が多すぎるため、人間に扱いづらいものとして、一部でのみ使われるようになるのではないか。

そのとき必要とされるもの

そうしたとき求められるもののひとつが、時間軸上に生きている人間と同じように、時系列に沿う振る舞いをプログラムされたエージェントだろう。

すでにWeb上では、Ajax、Flash、あるいはそれらを使ったニコニコ動画のように、時間依存で動的に変化するコンテンツが人気である。

そのとき必要とされる言葉

コンピュータ言語は、これまでに十分抽象化されてきた。その知見を踏まえ、活かしながら、人間にとって(組む側にも、組まれたプログラムを享受する側にも)自然な言語を考えられる時期がきたように思う。STなんとかは、前述の目的で設計された人間的な言語にしたい。

そして生まれるなにものか

具体的な応用としては、静的なSTなんとかのスクリプトによってデスクトップマスコット(エージェント)の振る舞いを制御したり、サーバからストリーミング配信されてくるSTなんとかスクリプトによってクライアントのデスクトップ上でデジタルアイドルのライブを開いたり、といったことが考えられる。

とりあえずの目標

初期の目的が2Dのデスクトップマスコットの制御のため、まずは2D向けのSTなんとかサブセットを作成するが、近いうち、3Dのモデリングデータを、関節定義や物理演算などで制御できる3D向けのSTなんとかサブセットも作成したい。

参考文献など

• 伺か - 仕様書
• MPML Homepage
• SMIL 1.0 仕様書
• SMIL

どれも一長一短。とくに伺か以外全部XMLベースというのは如何なものか。

タグ: プロジェクト・クレノ プログラム ネット
固定リンク | トラックバック(0) | はてなブックマーク(0)