JSONPとFREDDY

FREDDYのデータを分割する

　繰り返しになるが、FREDDYデータはイベントの境目で分割しても、そのデータの破片は正当なJavaScriptのコードである。ただし、ただ分割しただけでは、イベントの順序が保障できない。そこで以下のように各破片（Pageと呼ぶ）の先頭に、次のPageのリファレンスを書いておく。リファレンスもイベントと同じく、関数コールとして表される。

np(Page ID , URL);

　各Pageには0から始まる昇順の整数値（ID）が割り当てられており、Page IDには次のページのIDを指定する。また、URLは次のPageのJavaScriptファイルを指すURLを指定する。ただし、WebアプリケーションなどでFREDDYを利用する場合、1つのURLに対して、クエリ・ストリングとしてPage IDを渡すような構成になるだろう。このような場合、URLは最初のPageのURLから類推が可能であるので、Page IDのみを与えれば良い。

　このデータ分割の実例を図3に示す。データ分割、および分割されたデータのWebブラウザによる読み込みは、筆者らが提供する実装系によって支援される。このFREDDYの実装系に関しては、次回詳しく解説する。

　さて、最後にデータの圧縮に関して説明しよう。

FREDDYのデータを圧縮する

　FREDDYに限らず、半構造データの記述フォーマットは総じて冗長である。XMLがその最たる例かもしれない。例えば世界中のXML文書のと言うタグがと言う名前だったら、インターネット上の総データ量は、かなり増加するのではないだろうか。

　FREDDYでは、要素名を短い文字列に圧縮してしまうことで、要素名の長短によって起こる不必要なデータ量増加を防ぐことができる。圧縮のアルゴリズムは単純である。最初に出てきた要素から順番にa、b、c...と短い英数字からなる要素名（圧縮要素名と呼ぶ）を割り当て、その要素の2回目以降の出現時に、オリジナルの要素名の代わりに圧縮要素名を利用する。

　圧縮要素名による要素開始イベントは、通常の要素開始イベントと区別するため、大文字のSを使い「S(“圧縮要素名”, attribute);」のように記述する。また、要素終了イベントは直近に開始した要素から要素名を類推できるので引数は省略できる。

　図3に圧縮の例を示している。このXML文書にはとという2つの要素が存在する。出現順でa、b、cと命名するので、がaという、がbという圧縮要素名が与えられる。そして、2回目以降に出現した要素はすべて（図3の例だと6行目の要素）、圧縮要素名を使ったイベントとして定義される。

　このようにFREDDYはデータの冗長性をできる限り低く抑える仕組みを持っている。もちろん、この圧縮要素名の生成と復元はFREDDYのライブラリ内に隠ぺいされているため、ユーザーは圧縮手法の詳細を意識する必要は無い。

　さて、今週はFREDDYのデータフォーマットを紹介した。来週はこのデータフォーマットを使って、WebサーバーとWebブラウザ間のデータ通信の実装について説明する。