koriym/json_saga_by_douglas_crockford.md

## json_saga_by_douglas_crockford.md

      
    Raw
  

              json_saga_by_douglas_crockford.md
            
          
    The JSON Saga (2009)

Douglas Crockford (当時Yahoo!でSenior JavaScript Architect)
JSON設計者による伝説的プレゼンテーション

Youtube: https://youtu.be/-C-JoyNuQJs?si=vkmXthR2bMqe7UOY
Script: https://mamund.site44.com/rwcbook/the-json-saga/index.html
Slide: https://www.crockford.com/pp/jsonsaga2019.pptx

(日本語訳)
ダグラス こんばんは、ヤフーのダグ・クロックフォードです。 これはJSONサーガです。これはJSONについての本当の話になります。最初に警告です。私は異端者です。異端な話を聞きたくない人は、今すぐ離れることをお勧めします。私はJSONを発見した。なぜなら、JSONはすでに自然界に存在していたからです。私がしたことは、JSONを発見し、JSONに名前を付け、JSONがどのように便利かを説明したことだ。JSONを発見した最初の人間だと主張するつもりはない。少なくとも、私が発見する1年前に発見した人が他にもいることは知っている。私が発見した中で一番古いのは、Netscape社の誰かが1996年の時点でJavaScriptの配列リテラルを使ってデータ通信を行っていたことです。つまり、このアイデアはしばらく前からあったということだ。私がしたことは、それを仕様化し、ちょっとしたウェブサイトを作ったことだ。それ以外のことはすべて自分でやったことなんだ。
私のストーリーは2001年に始まる。チップ・モーニングスターと私は、今日Ajaxやコメント・アプリケーションと呼ばれるもののためのアプリケーション・フレームワークを開発する会社を始めた。私たちは会社の名前をどう呼べばいいのかわからなかったので、「Veil（ヴェール）」という仮の社名にしました。仮の名前とはいえ、私はこのロゴをデザインした。このロゴはとても気に入っていたからだ。本当に、本当にうまくできたと思う。それで私たちはステート・ソフトウェアになった。そして広告代理店がこのロゴを思いついた。その間のネガティブ・スペースが、StateのSのように見えるんだ。だから私たちはそう名付けた。これが最初のJSONメッセージだ。"神は何をなさったのでしょう？"や "ワトソンさん、来てください、あなたが必要です！"ほど重大ではありません。私たちは当時、自分たちが歴史を作っているなんて知らなかった。私たちはチップのガレージにいた。彼のサーバーは、フォーム送信の投稿に応じて、このメッセージを私のラップトップに送った。そして返ってきたのがこれだ。緑色のテキストが最初のJSONメッセージです。
私たちのフレームワークでは、オブジェクトは特定のオブジェクトに宛てられていました。そしてこのケースでは、セッション・オブジェクト宛でした。通常、セッション・オブジェクトはアプリケーションを表すオブジェクトをインスタンス化する。この場合、セッション・オブジェクトはテストを処理しているだけだった。つまり、doはこのテストを行うメソッドだったのです。このメソッドはHTMLドキュメントに埋め込まれています。IEでもNetscape 4と同じように動いたので、このようにしました。2001年当時、Netscape 4はまだ重要なブラウザーでしたから。ネットスケープ6がいかにひどいかという話はよくありますが、その時点ではIE6がこれまでで最高のブラウザでした。ネットスケープ4はあまりにもひどかったので、マイクロソフトが優秀で有能に見えた。それくらいひどかった。人類に対する罪でした。技術的に後進的な企業の多くがIE 6に固執していたため、私たちはIE 6をサポートできるようにしたかったのです。私たちは、サン・マイクロシステムズやIBMなど、それらの企業と取引したかったのです。そこで、当時私たちが考えたのが、このコミュニケーション・スキームだったのです。
その文書にはスクリプトが含まれていました。スクリプトの最初の行はdocument.domainを設定し、同じオリジン・ポリシーを回避できるようにした。そして、2行目のステートメントで、フレーム内のセッション・オブジェクトのreceiveメソッドを呼び出した。こうしてメッセージが配信され、そのメッセージがドキュメントに含まれるようにした。実に素晴らしいフォームだった。うまくいったと言いたいところだが、うまくいかなかった。一番最初に送ったメッセージは失敗した。失敗した理由は、予約語が入っていたからだ。JavaScriptではdoは予約語なのだ。そのため、何が起こったのかを理解するのに時間がかかりました。送った？ええ、送りました！どこに行ったんだ？というわけで、構文エラーが発生し、それを理解するのに数分かかった。その時、引用符で囲まれていない名前の問題が発覚した。
ECMA Script 3は予約語のポリシーに問題があることがわかったのだ。そのため、予約語はキーの位置で引用しなければならない。この問題を正式に規格化することになったとき、私は予約語をすべて規格に入れる必要はないと考えました。当時は、JavaScriptでアプリケーションを書けば実際に動くし、いい言語なんだよ、と人々を説得しようとしていた。そして私は、同時に、彼らがやったこの本当に愚かなことを見てくださいとは言いませんでした！そこで私は、代わりにキーを引用することにした。そうすれば、それがどれだけ馬鹿げたことなのか、誰にも言う必要はない。これが、今日までJSONでキーが引用される理由だ。また、JSONの文法を大幅に簡略化できるという副次的なメリットもあった。名前があるということは、文字が何であるかを定義する必要があるということです。Unicodeを使う場合、文字とは何かという問題は驚くほど複雑であることがわかった。でも、「もういいや、全部引用しちゃおう」ということで、その複雑さを完全に回避することができた。また、Pythonにも同じ記法が組み込まれていて、Pythonではキーの引用が必要なことがわかりました。Pythonはキーの引用を必要とします。そのため、Pythonとの整合性がとれ、Pythonコミュニティにとってより魅力的なものになると考えました。
JSONのエンベロープとしてHTMLを使用する際に見つかったもう1つの問題は、データ内の文字列がたまたまHTMLのように見えた場合、特にスクリプトタグのように見えた場合、その場でブロックが閉じてしまうことでした。そうすると、全体が配信されないので構文エラーが発生し、厄介なことになる。そこで私がJSON標準に追加したのは、スラッシュの前にバックスラッシュを置くという許容範囲でした。これで、HTMLのように見えても、ブラウザにはHTMLに見えないものができあがりました。JSONはスラッシュをエスケープする必要はないが、スラッシュを許容している。私たちはJSONに名前をつけようと思い、JSMLと名づけた。しかし、Javaの世界にはJava Speech Markup Languageという誰も聞いたことのない別の標準があることがわかった。そこで私は、別の名前を考えなければならないと思った。そこで私たちはJSON：JavaScript Object Notationを思いついた。JSONの発音についてはいろいろ議論があるようですが、私は厳密に気にしません。おそらく正しい発音は "Je son "だと思います。
でも、この発音はとても効果的でした。つまり、私たちが考案した、ブラウザとサーバーの通信という目的には非常に効果的だったのです。でも、サーバー間通信にもたくさん使いました。私たちのプラットフォームは非常にスケールが大きかったので、たくさんのボックスがあり、それらを同期させる必要がありました。JSONは、サーバー間でメッセージを送信するのに最適でした。また、シンプルなデータベースの実装にもJSONを使いました。つまり、キーがあり、それぞれのキーにJSONデータを保存するだけです。そうすることで、何かを保存したり、それを取り出したりするのがとても効率的になりました。私たちはそれをとても気に入り、顧客にもその良さを納得してもらおうとしました。するとお客さんは、"そんなの聞いたことがないから嫌いだ "と言った。XMLに決めたばかりだから、今さら他は考えられない。また、"標準ではないから使えない "と言う人もいた。私は「これは標準であり、ECMA262のサブセットだ」と言った。彼らは "いや、それは規格ではない "と言った。だから、これを使うためには、これが標準であると宣言しなければならない。だから私はそうした。これからはこれを標準にしようと決めたんだ。
だからJSON.orgを買った。JSONについて説明した1ページのウェブサイトを立ち上げた。その1ページには、簡略化したBNFと、ダートマスのビル・マッキーマンが推奨していたレイルロード・ダイアグラムというフォーマットで、この言語の文法を3通り載せました。これを使う人は誰でも、少なくともこのうちのひとつは理解できるはずだと思ったんだ。そして、実際にJSONにパースされるコードを見て、どうやるのかを確認できるように、Javaのリファレンス実装を入れました。これは2002年のとても遅いことだった。その頃、私は引退を決意していた。それまでの2年間は、バブル崩壊後、9.11後の環境で資金調達に奔走していました。資金を集めるのはあまりにも難しく、その時点で資金が底をついてしまった。しばらくは別のことをしようと思い、家電業界に戻った。ハイビジョンテレビとデジタル変換のコンサルティングをやっていたんだ。数年間は、インターネットのことはみんなに任せようと思ったんだ。私がやったことはそれだけだ。基本的に、私はメッセージフォーマットを瓶に詰め、インターネットに投げ込んだ。
時が経つにつれて、何人もの人々が私のウェブページを偶然見つけ、それを見て、"ああ、これは使えそうだ "と言った。そして使い始めた。そして、そのうちの何人かが私にコードを送り返すようになった。JSONのものをRubyやPythonに移植したよ。君のページに僕のコードへのリンクを貼ってくれないか？と言ってくれた。しばらくして、これらすべての言語をサポートできるようになりました。データ・フォーマットを本当にシンプルに記述することの利点のひとつは、それを実装するのに多くのコードを必要としないということです。そして、このように簡単に書けるコードがあれば、それを書いて共有しようとする人がたくさん出てくる。だから、あらゆる言語用のものがここにある。だから、これらの言語のどのペアで書かれたアプリケーションでも、JSONを使って通信することができる。JSONは、これらすべての言語の交差点であり、現代のすべてのプログラミング言語の交差点だからです。
すべての言語には、データとデータの構造に関する感覚がある。数値文字列やブール値のような単純な値を持っている。どの言語も、一連の値という意味を持っている。ある言語では配列、ある言語ではベクトル、ある言語ではリストなど。オブジェクト、レコード、構造体、ハッシュ、プロパティ・リストなどだ。どの言語にもある、普遍的な考え方だ。言語ごとに表現方法は異なるし、その上に型システムやセマンティクスなど、さまざまなものが追加される。しかし、データがどのように見えるかについては、どれも同じ考えを持っており、JSONにはすべてに共通するものがある。そして、JSONはその交差点にあることで、誰もが同意できるものであることがわかった。だから、データのやり取りがとても簡単になる。以前のデータ交換フォーマットは、すべての言語の集合体になろうとする傾向があったが、それは恐ろしく複雑で、扱うのが本当に難しいことがわかった。JSONは非常にシンプルであるため、実際に使いやすくなった。
JSONのサイトには、さまざまな手法でJSONパーサーを実装できる例が掲載されている。これは再帰降順コンパイラのスニペットだ。本当に、本当に簡単に書けます。これは、プッシュダウンオートマトンを使用した有限状態マシンのスニペットです。ほとんどの作業は緑のステートメントで行われ、テーブルに移動して現在のトークンと現在の状態を取得し、そこに格納されている関数を実行する。JavaScriptはステートマシンを書くのに非常に適している。JavaScriptはステートマシンを書くのに非常に適している。ほとんどの人がJSONとJavaScriptを使う方法は、JSON 2ライブラリか、それによく似たものを使う。これは本当に安全でないことが判明したので、4つの正規表現で守られている。最初は1つだったんだけど、誰かが「おっとっと。それで2つ目の正規表現を追加することになった。おっとっと、これが通った。結局、4つの正規表現が必要になった。そのため、エバルを取得することで期待していたパフォーマンス上のメリットを十分に得られていない。幸いなことに、ECMAScriptの第5版ではそれが修正されている。JSON.parseが言語に組み込まれたのだ。JSON.parseは独自のコンパイラを持つことになり、Evalコンパイラよりも高速になるので、パフォーマンスはとてもとても良くなるはずです。本当に安全で、本当に信頼できるものになるだろう。私たちは、ECMAScript第5版が今年中に完成し、承認されることを期待していますが、JSON.parseは現在、どこでもより良いブラウザで利用可能です。
言語が本当にシンプルに記述されていることのもうひとつの利点は、それを別の人間の言語に翻訳するのに手間がかからないということです。だから、世界中の素晴らしい人たちが翻訳を投稿してくれて、本当に嬉しかった。そして今、JSONページはこれらすべての言語で利用できるようになりました。もしあなたがリストにない言語に堪能で、協力してくれるなら、それは本当に素晴らしいことです。しかし、人々がJSONに注目するようになったきっかけは、Ajaxだった。2005年、ジェシー・ジェームス・ギャレットは、ウェブブラウザを使えば、ユーザーとのインタラクションのたびにページを入れ替えることなく、完全にインタラクティブなアプリケーションを実現できることを発見した。私たちの多くは、5年前からそれをやっていましたが、ジェシーがそれを発見したときは本当に重要でした。2001年の時点では、私たちはそれを手放すことはできなかったのですが、2005年には突然、本当にホットなものになったのです。多くのウェブ開発者が、XMLの扱いは実に面倒だが、JSONは実に簡単だということに気づいたのだ。そして、JSONの人気を押し上げたのはAjaxでした。当時は、「ちょっと待て、ジェシー・ジェイムズ・ギャレットは、XはXMLの略だと言っている。だからJSONは使えない、XMLを使わなければならない」と言う変人もいた。それは長くは続かなかった。
そして、この言語を使う人々のコミュニティが広がっていった。そのひとつが、人々がパーサーへの指示をコメントに書いていたことです。これは本当に良くないことで、相互運用性を完全に壊してしまうからです。そこで私は、JSONの定義を修正し、コメントを削除した。スラッシュスラッシュとスラッシュスターがありましたが、今はなくなりました。また、不必要な複雑さが加わっていることも判明した。私たちの使い方では、コメントは使ったことがなかった。便利かもしれないと思ったので、最初に入れただけだ。しかし、それほど有用ではないことが判明した。他の言語への移植では、複雑さの半分くらいはコメントだけだった。驚くほど難しかった。なぜなのか、まったく理解できなかった。しかし、コメントを削除することで、JSONを他の言語に移植するのが簡単になり、それは望ましいことでした。
また、YAMLという別のデータ交換フォーマットがあった。YAMLは、偶然にも、JSONのほとんど適切なスーパーセットだった。最大の違いは、JSONにはそのスタイルのコメントがあり、YAMLにはなかったことだ。だから、コメントを削除することで、JSONはYAMLに近くなり、そうすることである程度の利点があるように見えた。そして最後の変更は、数値に科学的記法を追加したことだ。私たちがステートで仕事をしていたときは、ビジネスアプリケーションをやっていて、その必要性に気づくことはありませんでした。しかし、Ajaxが大きくなるにつれて、Ajaxの中でいろいろなことが起きていることがわかったので、私はそれを導入した。そして、その時点でドアを閉めた。もうJSONに変更を加えることはないだろう。というのも、私はJSONにバージョン番号を入れなかったので、あなたが使っているJSONのバージョンを示す方法がないのです。だから、JSONを拡張したり再定義したりする安全な方法がない。だから結果として、JSONは変更されない。何かにバージョン番号を付けると、1.0があれば1.1があり、2.0があることがわかる。そして3.0になるまでは、すべてがくだらない。だから、我々はそれを避けようと思っている。JSONはただのJSONなんだから。
安定性は、私たちが思いつくどんな機能よりもずっと重要です。何年もの間、JSONに入れることができるものの提案をたくさん聞いてきた。JSONでできることは、すべてJSONでできる。だから、いつかJSONはもっと大きくてエキゾチックなものに取って代わられるだろうと期待している。その日が来るのを楽しみにしている。でもそれまでは、JSONは今のままでいる。そしてその後も、JSONはありのままの姿であり続けるだろう。JSONは、時の終わりまでありのままの姿であり続けるだろう。そうすることで、スタックの少なくとも1つの部分は、永遠に頼ることができるのだ。JSONの背後にある重要な設計目標の1つは、ミニマリズムでした。相互運用するために合意しなければならないことが少なければ少ないほど、うまく相互運用できる可能性が高まるというのが私の考えでした。インターフェイスが本当にシンプルであれば、簡単につながることができる。もしインターフェイスが本当に複雑であれば、何かがうまくいかない可能性が非常に高くなる。
だから私は、JSONをできるだけシンプルにするよう努めた。そして、JSON標準を名刺の裏に書けるようにすることを目標にしました。そしてこれがその名刺だ。この名刺が欲しい人は、私に会いに来てください。これはJSONカードで、裏面にJSON標準が記載されています。さて、私は、それがすべての標準のゴールであるべきだと提案しているわけではありません。名刺の裏に書くよりも複雑な規格もあります。しかし、標準化委員会の会合で、これをもっとシンプルにして名刺に収まるようにする方法はないだろうか、と考えるのは、本当にいいことだと思います。一般的に、標準化委員会はそのようなことは考えない。物事を大きくするのは簡単ですが、より良くするのは難しいのです。
ですから、JSONのデザインには多くの影響がありました。JSONは、私の頭から出てきたものではありません。私が長年にわたって観察してきた多くの事柄に基づいている。最初に影響を受けたのは、1958年にマサチューセッツ工科大学（MIT）で発表されたジョン・マッカーシーのLispです。Lispは、単純なバイナリツリーのテクスチャ表現で構築されていました。Lispは本当に強力で、構文的にはほとんど何もないのですが、大量の括弧が入れ子になっているため、視覚的には混乱していました。Lispが優れていたのは、プログラムとデータにまったく同じ表現を使っていたことです。そのため、もともとのアイデアは、プログラムが自分自身をデータとして扱い、面白いことができるというものでした。S式を標準的なデータ交換フォーマットにすることを勧める人たちがいましたが、それはいいアイデアでしたが、Lispが主流の言語にならなかったのと同じ理由で、実現しませんでした。つまり、主流は構文を好むということだ。そして、Lispはあまりにグーフィーな見た目だった。だから実現しなかった。
もうひとつの影響はRebolです。Rebolはより現代的な言語ですが、Lispと非常によく似たアイデアを持っています。しかし、構文的にはもっとリッチなものだ。Rebolは素晴らしい言語であり、もっと人気が出てしかるべきなのに、そうなっていないのは残念だ。JSONはJavaScriptだからだ。JSONはJavaScriptだからだ。私は、JavaScriptのちょっとした良さを見つけることでキャリアを積んできたように思う。JavaScriptの良いところについてのパンフレットを書いたようにね。JSONもJavaScriptの良いところです。この言語には良いところがいくつかある。それは偶然ではない。この言語の設計者であるBrendan Eichは素晴らしい人物だ。JavaScriptには素晴らしいものがある。他にもいろいろあるが、それを使う必要はない。そしてひとつ驚くべきことは、JavaScript、Python、Newtonはすべてほぼ同時期に、孤立して設計されたということだ。3人のデザイナーは誰も、他の人たちがやっていることに注意を払っていなかった。彼らは皆、配列の中で入れ子になったオブジェクトを処理するために、まったく同じ記法を考え出したのだ。これは驚くべき偶然の一致かもしれないし、あるいは、ずっと以前からある自然なアイデアを、全員が同時にまとめたということかもしれない。
もうひとつの例は、NeXT社で93年にOpenStepプラットフォームに取り組んでいたときのことです。基本的にはJSON構造でした。コロンの代わりに等号があり、カンマの代わりにセミコロンが使われていました。しかし、基本的にはJSONで、考え方は同じだった。JSONは93年に完成し、その後OS 10で破棄された。しかし、データ構造を表現し、人間にとって快適で、マシンにとって実に効率的な形でデータを保持することができるというアイデアは正しかった。これが、このようなものの核となるアイデアの一部だ。JSONはその名前を付けただけで、昔からあったものだ。そしてXMLだ。XMLについて私にとって興味深いのは、その特徴ではなく、どのようにして標準になったのか、そしてどのようにして急速に普及したのかということです。XMLがSGMLと呼ばれていた当時、世界はXMLを文書フォーマットとして拒否した。XMLはいくつかの点を変えたが、それが悪い文書フォーマットであった点を修復することはなかった。その証拠として、XHTMLがHTMLを置き換えることに完全に失敗したという事実を提示しよう。もしXMLが優れた文書フォーマットであれば、XHTMLはHTMLに簡単に勝っているはずですが、そうはなっていません。HTMLはまだ優勢で、XHTMLは失敗している。
つまり、そもそもXMLはあまり優れた文書フォーマットではなく、データ交換フォーマットとしてはさらに劣っているのです。では、XMLが意図したことを何一つ効果的に実現できていないのに、なぜこれほど普及したのでしょうか？そのルーツはHTMLにあると思います。HTMLもSGMLをベースにしています。しかし、HTMLはSGMLを単純化することで、SGMLを大幅に改良した。SGMLから多くのゴミを取り除き、基本的な部分を減らし、さらに弾力性を持たせました。というのも、この文書フォーマットの悪いところのひとつは、正しく作るのが本当に難しいということです。すべてのバランスを取り、すべてを引用するのは本当に難しい。なぜそんなに難しいのかはわからないが、その証拠に誰も正しくやったことがない。誰もテキストエディタを開いてHTMLを書くことができない。だからブラウザは最初から、マークアップの意味を理解するために、非常に弾力的で寛容で知的でなければならなかった。そして、少しでもエラーを見つけたら、それを消して何も表示しないというアプローチは、ウェブにとって死を意味します。そして、それは流行らなかった。
しかし、ウェブが出現した当時、多くの優秀なCTOや技術者がウェブを見て、これは明らかにうまくいかないと言った。これは多くの点で欠陥があり、明らかにうまくいかない。しかし、もっと多くのBレベルやCレベルの技術者が、これは素晴らしいと言った！そして彼らはそれを手に入れ、それが雪崩効果を生み、最終的にはHTMLが勝利した。というのも、彼らが指摘した問題点によって、私たちは今も毎日苦しんでいるからです。彼らが欠陥として挙げたものはすべて正しかった。十分に優れているかどうかではなく、十分に普及するかどうかを問うべきだったのです。XMLが発表されたとき、それはHTMLを作った人たちによるもので、角括弧がついている。だから、彼らは邪魔をしないで放っておいたんだ。
2002年4月、私はCTOフォーラムでジョン・シーリー・ブラウンが話しているのを見た。ブラウンは何年も何年もゼロックスPARCを経営していた。オブジェクト指向プログラミング、グラフィカル・ユーザー・インターフェース、ローカル・エリア・ネットワーキング、レーザープリンターなど、今日私たちが当たり前のように使っているものの多くが、ブラウン氏の下で生まれたのだ。素晴らしい人だ。彼は、次世代は疎結合のシステムでできていくだろうと話していて、XMLがそれらを結びつけるものになると考えていた。彼は、"これほどシンプルなものでなければうまくいかないかもしれない "と言っていた。本当に興味深い講演だった。その数ヵ月後、私は別のカンファレンスに行き、より現場に近い別の人物がXMLについて話しているのを聞いた。彼は、"こんな複雑なものでしかうまくいかないのかもしれない "と言ったんだ。私はその言葉に衝撃を受けた。たった2、3ヶ月の間に、とてもシンプルなものから、とても複雑なものへと変化したのです。これは何を示しているのだろうか？ここから何を学ぶべきなのか？
そして、それが複雑なのは、それがフィットしていないからだと思い当たった。間違った問題を解決している。私たちがうまくやる必要のあることをやるのに、それ自体が適応していない。このことに気づいた人は他にもいた。例えば、『XML Sucks』という人気サイトがあった。そのサイトのタイトルは、「XMLは技術的に最悪だが、とにかく使わなければならない理由」だった。つまり、XMLについては基本的に2つの考え方がある。ひとつは、これは完璧だとする考え方だ。私たちは、世界中が愛したSGMLから始めて、それを正しく、完璧なものにしたのです。そしてもうひとつは、これはひどいという意見だ。しかし、両者が同意できることがひとつだけあった： XMLが標準なんだから黙ってろ。黙れ！しかし、誰もが黙ったわけではありません。XMLは標準なのだから、黙っていろ！」しかし、誰もが黙っていたわけではなかった。これがXMLの代替案のリストだ。このリストの背後には、XMLには何か深い間違いがあることを発見し、それを修正できると考えた、クレイジーな発明家がいる。このリストは、ポール・Tという人物がまとめたものです。彼が誰なのかは知りませんが、彼もその一人で、自分のものがトップに来ることを期待していたのですが、そうはなりませんでした。そして私のがトップに浮上したとき、彼はOK、もう終わりだと言って、最新情報を更新するのを止めた。
しかし、XMLに欠陥があることを見抜いたという点では、どの人も正しかった。このリストの中で、他の人のXMLを見て、ああ、この人の方が優れていると言う人はおそらくいないでしょう。誰もそんなことはしない。だから、エイジャックス効果のせいで、一人を除いては、誰も自分たちの雑音から抜け出すことができなかった。つまり、Ajaxが勝ったのだ。XMLコミュニティは、JSONの台頭に注目した。彼らは、初期には破壊的な技術であることを喜んでいたが、その後、自分たちが破壊され始めたことを非常に不満に思い、それを止めようとした。初期には、漠然とした脅し......脅しというよりは、「XMLの技術的優位性を疑ったことを後悔することになるぞ！」というような口ごもりがあった。そんなの知ってるだろ。いつか後悔する日が来る、それは確かだ。JSONが台頭し始めると、彼らは少し意地悪になり始めた。「あなたの小さなウェブアプリケーション、JSONで十分だ。うまくいかないと言ったのは分かっている。しかし、本当のアプリケーション、男らしいアプリケーションを作るなら、XMLの複雑さが必要だ。その複雑さには理由がある。それがなければ失敗する」。彼らは、なぜ失敗するのかを明確に説明することはできなかったが、失敗すると確信していた。それ以来、多くの男らしいアプリケーションがJSONで書かれるようになった。そして何が起こったかというと、失敗しなかった。
そして最後に、殺害予告があった。そう、殺害予告だ。例えば、2006年のクリスマス直前にJSONを発見したDave Winerは、「これはXMLですらない！誰がこんな茶番をやったんだ？木を見つけて吊るそう。今すぐ」。なんて醜いことを言うんだ。幸いなことに、デイブ・ワイナー氏の言うことに耳を傾ける人はいない。XMLの主要アーキテクトの一人であったジェームス・クラークは、その数ヵ月後、「どんなバカでもXMLより優れたデータフォーマットを作ることができる」と書いた。これは事実であることがわかった。つまり、XMLヒステリーの中で、私たちは職人技の第一のルールである「適切な仕事には適切な道具を使う」ということを忘れてしまったのだ。その代わりに、1つのツールですべてを支配するという別のことに気を取られてしまった。それは優れたエンジニアリングでもなければ、優れた職人技でもない。何でもできるスーパーツールが1つあればいいのかもしれない。しかし、そのような道具は存在せず、道具は常に専門化されてきた。そして、エンジニアリングの技術の一部は、利用可能なすべての道具の中から、どの問題を解決するのに最適な道具が何かを見極めることである。そして、その方法を忘れてしまった奇妙な時期があった。
JSONが許容されるようになったことの利点のひとつは、最高のツールを検討することが許されるようになったことです。JSONは必ずしもすべての仕事にとって最適なツールではありません。しかし、最適なツールであれば、それを使うことができる。そうでないものについては、他に使えるツールがある。つまり、優れたエンジニアリングが再び一般的になったということだ。それはいいことだと思う。それで私は考えたんだ。データは文書フォーマットで表現されるべきだという考えはどこから来たのだろう？振り返ってみると、何の意味もない。そのアイデアはどこから来たのでしょうか？しばらくの間、誰もがそれを信じたからだ。でも、何の意味もない。そこで私は、この考えがどこから来たものなのかを突き止めるために、化石の記録をさかのぼり始めた。RUNOFFというプログラムまでさかのぼりました。これはMITで始まり、テックシステムズやマルチックス、その他多くのメインフレームに搭載された。メインフレーム時代のことだ。このプログラムの最初のバージョンはパンチカードを使っていました。当時、パンチカードは大文字しかなかったので、大文字のどれを小文字にするかを示す特別なコードを挿入することで、きれいな文書を印刷することができた。
そして、文字で始まるカードにはテキストが書かれ、テキストは段落に埋められていった。列目のピリオドで始まるカードはコマンドで、空白行を1行スキップするか、4つのスペースをタブでオーバーすることを示している。つまり、ここでは多くの明示的なコントロールが行われているのだ。マニュアルを作ったりするのには十分でしたが、これを使えばもっといいことができるのは明らかです。IBMのチャールズ・ゴールドファーブは、ジェネリック・マークアップ言語と呼ばれるものを作ることを思いついた。これらのタグ名のいくつかは、あなたにとって不気味なほどなじみのあるものでしょう。そこで彼は、1列目の予期せぬ句読点から始めた。そして、同じ行にテキストを置くことができるように、句読点を閉じるというアイデアも思いついた。EOLタグは、現在私たちが使っているものと正確に対応するものではありませんが、それが何を意味するかは想像がつくでしょう。ゴールドファーブはこのタグを使いながら、最初は特別な目的のためのタグであったが、それを一般化するという進化を遂げた。そして、角括弧のアイデアに行き当たった。HTMLでこのようなものを今でも目にすることができるのは、エンティティの中だ。エンティティには、おかしな句読点があり、文字があり、さらにおかしな句読点がある。こんなものが意味を持つわけがない。まあ、これはここから来ている。彼はその時点で角括弧を使い果たし、他に括るものがなかったのだ。
ドキュメント・システムが最初に正しく作られたのは、ブライアン・リードがカーネギー・メロン大学で開発し、1980年に発表した『Scribe』だった。Scribeは、文書構造と書式を分離し、それを見事に実現した最初の文書フォーマットだった。それだけでなく、彼は文書を表現するための実に優れた記法を持ち、それはHTMLよりもずっと書きやすく、HTMLよりもずっと正しいものにしやすく、SGMLよりも確実に簡単だった。彼の予約文字はひとつだけで、それは@だった。だから、@をリテラルで使いたい場合は、@を二重にすればよかった。の後に単語が続くとタグになる。一般的に、タグの後には開始文字と終了文字のブロックが続いた。そのブロックの中では、開始文字と終了文字を文字通りに使うことはできないが、それ以外の文字を使うことはできる。彼は、開始文字と終了文字のセットを6つ用意した。視覚的にもっと扱いやすいものができた。ゴールドファーブはそれを見て、そうだ、角括弧だ、と思った。
彼はまた、章とか表とか、とても長いものに対して、開始と終了を指定し、その引数をタグにする素晴らしい形式も持っていた。この形式では、引用符の末尾以外なら何でも入れることができ、文字の混同を心配する必要もない。この形式は本当に弾力性があり、構文的にもシンプルでした。素晴らしいアイデアのひとつだった。リードは本当に素晴らしい人だった。ティム・バーナーズ＝リーが文書フォーマットについてもっと詳しくなかったのは本当に残念だ。もし彼がSGMLではなくScribeをベースにしてワールド・ワイド・ウェブを作っていたら、今日のワールド・ワイド・ウェブはもっと良いものになっていただろう。しかし、これだけでは、私が皆さんをこの旅に連れて行った質問の答えにはなっていない。もう一つ見るべきことがある。Scribeには書誌のサポートもありました。ここに技術報告書や書籍の説明があります。そしてその中にデータがあります。実際、それはJSONのように見えます。カラムで区切られた名前と値のペアです。ドキュメントの中にあっても、これはデータです。これはドキュメントを記述するデータです。ですから、データを表現するために文書フォーマットが使われたのは、これが初めてだと思います。そしてScribeはゴールドファーブに大きな影響を与えた。
彼はこれらをSGMLの属性としたのです。しかし、彼はそれ以外の部分を正しく理解できなかったのです。でもそのおかげで、SGMLコミュニティでは「そうだ、Reidがやったんだから、私たちは文書フォーマットでデータを表現できるんだ。だから私たちにもできる。そして、その考えはXMLの時代まで生き残りました。リファレンス実装をウェブサイトに掲載する際、ソフトウェアライセンスを付ける必要がありました。そして利用可能なすべてのライセンスを調べました。一番気に入ったのはMITライセンスで、これはソースに貼る通知で、「どんな目的でも使っていいよ。ただ、ソースに注意書きを残すだけで、私を訴えないでください」と書かれている。私はこのライセンスが大好きです。でも、これは2002年末のことで、ちょうどテロとの戦争が始まったばかりだった。私たちは大統領や副大統領と一緒に悪人を追っていた。だから、自分のライセンスにもう一行加えたんだ。"ソフトウェアは悪ではなく善のために使われるべきだ "とね。自分の役目は果たしたと思った。年に一度くらい、変人から手紙をもらうことがある！あなたがライセンスを変更するまで、私はそれを使用するつもりはありません！"と。あるいは、"悪かどうかどうやって判断すればいいんだ？私は悪だとは思わないが、他の誰かが悪だと思うかもしれない。だから、私はそれを使うつもりはない"。いいね。私のライセンスは機能している！
聴衆：別にライセンスを要求すれば、それを悪に使うことができるのですか？
ダグラス： それは興味深い指摘だ。また、年に一度くらい、弁護士から手紙をもらうんですが、毎年違う会社の弁護士なんです。その会社の名前を言って恥をかかせたくないので、イニシャルだけIBMと書いておくと、私が書いたものを使いたいという内容だ。私が書いたものを使いたいのだと。彼らは私が書いたものを彼らが書いたものに使いたいんだ。彼らはそれを悪用するつもりはないと確信していたが、彼らの顧客については断言できなかった。だから、そのための特別なライセンスを与えてもいいだろうか？もちろんだ。文字通り2週間前のことだ。IBMとその顧客、パートナー、手下がJSLintを悪用することを許可します。そして弁護士から返信が来て、"どうもありがとう、ダグラス！"と言われた。
さて、そろそろ話をまとめなければならないが、その前にロゴについて話したい。2002年にウェブページを立ち上げたとき、ページをクラスアップし、より充実したものに見せるためにロゴが必要だと考えた。そこでこんなものを思いついた。これはインポッシブル・トーラスという有名な目の錯覚をモチーフにしたもので、アンビヘリカル・ヘクスナットと関連しているんだ。それを丸くして、向きを変えて、素敵な陰影をつけたんだ。これが気に入った理由はいくつかある。ひとつは、これを2次元の図形として見た場合、同じでありながら位相がずれている2つの要素で構成されていること。だから、この図形は、会話の両側面を示唆しているようなものなんだ。また、文字の形も見える。Jもあるし、Nもあるかもしれない。明らかにOがある。それで、その名前にあったイニシャルがほとんど入っていたんだ。しかし、数年間これを眺めていて、私はあることに気づいた。それは、正方形を円形に押し出したものだ。そして一周して戻ってくる。
観客：メビウスの帯みたいですね。
ダグラス： ダグラス：一回転することを除けばね。そうでなければメビウスの帯のようですが、一回転します。一回転して一公転する。だから不可能な形ではなく、実は単純な形なんだ。正方形と円にひねりを加えたものです。JSONのシンボルとしてとてもうまく機能すると思う。それがわかったら、この背後に数学的モデルを置くことができる。そこで、Canvassを使ってJavaScriptでこれをレンダリングし、Tシャツのデザイン用に極端な陰影をつけてみた。JavaScriptが独自のロゴをレンダリングできるほど強力になったのはいいことだ。これは名刺のデザイン。100年前からあるようなものが欲しかったんだ。だからJSONは、母親たちが何世代にもわたって信頼してきたデータ交換フォーマットなんだ。最後に、シェパード・フェアリーのオバマ・ポスターにインスパイアされたものです。私はこれを「Data Interchange We Can Believe In」と呼んでいます。ありがとう、そしておやすみなさい。
HTMLをより良くするにはどうしたらいいと思いますか？もっと拡張性を持たせること。限られたタグの集合にすべてを収めなければならないのは、うまくいかない。あなたがおっしゃった、見出しがいっぱいない文書でも見出しを使えるようにするというのは、うまくいきません。私はCSSを使って、タイトルや広告、コントローラーなど、新しいものが欲しいと言えるようになりたいのです。好きな名前をつけて、CSSで何をするのか指定するだけです。言語を拡張し、自分のアプリケーションをマッピングするために必要なことはそれだけだ。しかし、HTML 5は違う方向に進んでいる。UnicodeのHex文字でバックスラッシュUの大文字と小文字の区別はありますか？
聴衆：はい。
ダグラス：いいえ： いいえ、大文字でも小文字でも使えます。
聴衆：そうです： それを仕様に追加できると思いますか？私はJSON-Cを使っていたのですが、JSONの感度について知らないのです。そして、ウェブページもそれを知らないことがわかりました。
ダグラス： へえ。それを見てみないと。それは知りませんでした。
観客：そうですか： わかりました。
ダグラス： とりあえず、小文字を使うべきです。JSONに代わるものは何でしょうか？現在、JSON用のテンプレート言語が登場しています。JSONT言語は本当に素晴らしいと思います。
聴衆：そうですね： そうですね。
ダグラス： JSONフォーマットの最大の弱点の1つは、JSONが持つ「テンプレート言語」であることです。JSONフォーマットの最大の弱点の1つは、XMLの弱点でもあるのですが、循環構造を簡単に表現できないこと、一般的なDAGを表現できないことです。ほとんどのアプリケーションでは、これは必要条件ではありませんが、本当に望ましいアプリケーションもあります。JSONからそれを除外するのは申し訳ないと思いましたが、JavaScriptにはなかったので、除外せざるを得ませんでした。JavaScriptのサブセットでなければならないというのが、私の他のデザインルールの1つでした。だから、私はその船に乗り遅れた。いつかキーから引用符を外せるようにしたい。
聴衆の皆さん： JavaScriptを使えないアプリケーションの例を挙げてください。
ダグラス：わかりました： ダグラス：わかりました。JSONでエンコードできない最も単純なものです。配列を作ります。これは循環構造です。JSONにそれを直列化するように頼むと、無限の開括弧が出てきます。そして、最初の閉じ括弧を生成する前に死んでしまう。スキーマやDTDについてどう思うか？どうでもいい。そうしたいなら、それでいい。JSONのスキーマに取り組んでいる非常に賢い人たちがいる。DojosのKris Zypは本当にいい仕事をしている。というのも、JSONが台頭し始めると、XMLの世界から多くの人がやってきて、「それはできない。スキーマができるまでは使えない」と。JSONがどのように機能するのかがわかるまで、彼らは1カ月ほどそう言い続けました。だから私たちはその時点に到達できなかった。それでスキーマを設計したのですが、その必要性があまり感じられなかったので実装しませんでした。スキーマの必要性を感じている人もいる。でも、それを便利にするためにコアとなるデータフォーマットそのものを変える必要はない。私がコメントを削除した主な理由は、コメントの内容に基づいてパーサーが何をするかをコントロールしようとする人たちを見たからです。そしてそれは相互運用性を完全に壊してしまった。だから、コメントの使い方をコントロールすることはできなかった。