３−４： yorm
worm の別の実装が現われたのは、予想よりも遅かった。あるいは見逃していたのか。それとも名前が知られたのがそれだっただけなのか。それは “yorm” と名付けられていた。 “yet another worm” だという。
yorm の実装は、黒田 の worm よりも行儀のいいものだった。すくなくとも、 yorm スクリプトの文法は worm のものと同じであり、yorm の実行系は perl で書かれ、CGIとして呼び出され、また機能していた。探索結果の共有サーバは、worm のものを——サーバを別に立てるとしても——使うようになっていた。すくなくとも共有サーバを独自の仕様で開発していない点において、 worm との連携や共有サーバ間の連携が考えられた。
ともかく、表面上はそうだった。だが、内部がどうであるかは別の問題だった。
情報処理研究所のチームは yorm のコードを一行ずつ確認し、またテスト用のサーバを立て、その実行を確認した。 yorm の仕様を参照しながらの作業だった。だが、 yorm の仕様と、テストの結果をそのまま信じることはできない作業でもあった。
まず、 yorm スクリプトの実装にバグがないかが検証された。すくなくとも文法上におけるバグは存在しなかった。
次に特定の条件で実行される部分はないかが検証された。たとえば、それと知っている者であれば、 yorm スクリプトにおける特定の文法ミスやその組合わせによって実行される部分はないかが検証された。
さらに、 yorm スクリプトの実行系が持ち得る状態が検証された。ここにおいても、 worm スクリプトの実行系が持つもの以外の状態は存在しなかった。
yorm においては、その実行系のソースはこれらの検証によってそのすべての行が確認された。
yorm が作られた理由がドキュメントに記載されていた。そこには、 worm スクリプトの実行系は果たして信用できるのかという記述があった。それは当然の疑問でもあった。C言語で書かれたJavascriptの実行系によって worm スクリプトの実行系は書かれていた。これによって、 yorm スクリプトの perl によって書かれているという状態よりも検証に手間がかかる。そこにはバグがあるかもしれない。
サーバ・サイドでのJavascriptの実行系を構築している理由を、黒田らは明らかにすることはできなかった。それは、ブラウザを開発している会社との契約に含まれていた。理由を明らかにしたとしても、検証を望む人はいるだろうし、あるいは信用されるというわけでもないだろう。だが、契約には将来においてブラウザの開発会社がサーバ・サイドでのJavascriptの実行系を提供する旨の項目があった。期日、あるいはバージョンについての言及はないとしても。
黒田は、それはJavascriptからHTMLの要素に自由にアクセスできるようになる時、あるいはバージョンにおいてだろうと予想していた。要素を取得できるだけでなく、要素を書き換えることも可能となるバージョンにおいてだろうと。その時期は予想できるものではなかったが。
だが、そこから予想できる流れがあった。現状のHTMLでは構造の記述と装飾の記述が混在していた。CSSが制定されかけてはいたが、それによって構造の記述と装飾の記述がはっきりと分離されるだろう。またそれと前後して、HTMLファイルにはヘッダとBODYタグしか存在しなくなるだろう。すべてのHTMLファイルにおいてそうなるとは考え難かったが。
だからこそ、 worm ではサーバ・サイドでのJavascriptの実行系という形態を捨てることはできなかった。チーム内でしかその予想を共有できないとしても。だが、ブラウザの次のバージョンからは、 worm を意識し、Javascriptの実行系をより分離しやすくする旨も契約に含まれていた。それにより、今回の、あるいはこれまでのような手間は減るはずだった。
ただ、同時に懸念もあった。別の会社から提供されてるブラウザにも、先日、Javascriptに似たものが含まれるようになった。その会社が worm に似たものを提供し始めれば、その実行系はどうなるだろう。 worm の規格に沿っている限り、問題は起きない。 worm スクリプトはあくまで worm スクリプトであり続けるだろう。だが、その保証は得ることはできなかった。チームから保証は求めた。だが、得られた返答は、「尊重する」というものだった。それ以上のものを求めるなら、すくなくともより大きい組織からの意見として求める必要があるだろう。そうできたとしても、やはりなんの保証も得られないかもしれなかった。
