安定したJSON Schemaに向けて

昨年この頃、私はAPI仕様に関する会議でJSON Schemaの将来について議論を行いました。最も話題になったのは、JSON Schemaがいつ「完成」するのかということです。もちろん、この質問は何度も聞いてきました。「ドラフト」というラベルをリリースに付けていることが、この質問の根源です。「ドラフト」という用語は長年にわたりコミュニティにかなりの混乱をもたらしてきたため、その由来を理解しておきましょう。

なぜ「ドラフト」なのか？

JSON Schemaは、IETF標準化トラックのRFCプロセスを大まかに従ってきました。つまり、私たちのリリースはインターネットドラフト（I-D）の形になっています。そのため、「ドラフト」と呼んでいます。しかし、JSON Schemaは本番システムで広く使用されているため、仕様を典型的なI-Dのように扱うことは実際には不可能です。したがって、「ドラフト」という用語の使用は、IETFプロセスがJSON Schemaにとってより意味を持っていた時代の遺産と言えるでしょう。

これは問題となっています。「ドラフト」と聞くと、「未完成」または「本番環境では使用できない」と解釈されるからです。しかし、私たちはリリースをそうは扱っていません。すべてのリリースは、本番環境での使用を期待し、推奨しています。これは、OpenAPIが新しいバージョンをリリースすることと変わりません。OpenAPIがいつ「完成」するのかと尋ねる人はいません。JSON Schemaは、私たちがリリースを「ドラフト」と呼ぶため、異なる認識をされているのです。

真の問題点

しかし、これは単なるブランドの問題ではありません。「JSON Schemaがいつ『ドラフト』から外れるのか」と尋ねている人たちは、実際には「JSON Schemaがいつ安定するのか」を意味しています。彼らは、スキーマを作成し、JSON Schemaが将来どのように進化しても同じように動作し続けることを確信したいと考えています。依存関係を更新しても、正常に動作していたスキーマを更新する必要がないことを望んでいるのです。

これはライブラリのメンテナンス担当者にも影響を与えます。下位互換性または上位互換性の保証がない複数のバージョンのJSON Schemaをサポートする必要があることは面倒であり、多くのメンテナンス担当者が古いリリースのサポートを終了するに至っています。このようなことが起こると、ユーザーは壊れていない既存のスキーマをすべて更新するか、使用しているJSON Schemaライブラリのサポートが終了したバージョンに固定するという選択を迫られる可能性があります。

私たちの解決策

これらは、次のリリースで解決しようとしている問題です。各リリースで新しい不変で非互換なバージョンのJSON Schemaをリリースし続けるのではなく、次のリリースは、安定していて進化する、長期間にわたって使用できるバージョンになります。「安定」とは、変更に対して厳格な下位互換性と上位互換性の要件が満たされなければならないことを意味します。JavaScriptのように、進化しても既存のスキーマが使用しているJSON Schemaライブラリで引き続き動作することは保証されますが、新しい機能を使用する際にはリスクを負うことになります（すべてのライブラリがそれらの機能を実装しているとは限らないためです）。

安定しながらも継続的に進化する仕様というビジョンは、IETFのプロセスにはうまく適合しません。検討した方法はありますが、標準の進化を続け、「ドラフト」からすぐに脱却できると私たちが考えるものは提案されていません。したがって、私たちのビジョンの実現に向けた最初のステップは、メインの仕様開発をIETFのプロセスから切り離すことです。この分離により、私たちのビジョンに沿ったメインの仕様開発のための新しいモデルを追求することができます。

JavaScript言語の進化の方向性に賛成するかどうかは別として、相互運用性と長期的な存続性を犠牲にすることなく継続的な進化を可能にする効果的なプロセスを考案したことは明らかです。そのため、JavaScript言語の進化に使用されているプロセスを基に新しいプロセスを選択しました。次のリリースでは、現在使用しているほとんどのキーワードと機能が安定版として宣言され、下位互換性のない方法で変更されることはありません。まだ安定版にする準備ができていない機能とキーワードは、現在定義に取り組んでいる新しい段階的リリースプロセスの一部になります。段階的リリースプロセスの目標は、機能が十分な実装、テスト、および現実世界の検証を受けて、安定版と宣言することに自信を持てるようにすることです。このプロセスは、私たちに自信を与えるだけでなく、その自信をはるかに迅速に達成することも可能にします。

標準化に関する考慮事項

次のリリースから、JSON Schema仕様は当社のウェブサイトで自己公開されます。

自己公開に関する懸念事項の1つは、他の標準がJSON Schema仕様を参照できるかどうかです。OpenJS Foundationへの会員資格に基づき、当社の方法が標準に当社の仕様を参照するのに許容されるとする、標準開発に関わっている人々からのフィードバックを受けています。すべての標準機関が同じ結論に達するかどうかはわかりませんが、このフィードバックにより、大きな問題にはならないという自信が得られました。

メインの仕様は自己公開されますが、IETFのプロセスは意味のある範囲で継続して進めていきます。例えば、application/schema+jsonなどのメディアタイプをHTTPAPIs WGを通じて登録する作業を進めています。また、IETFを通じて、Relative JSON Pointerなどの再利用可能なコンポーネントの標準化も検討しています。

結論

新しいプロセスの詳細は、最終決定後に別の投稿で共有しますが、ユーザーが期待できる結果をいくつか紹介します。

• 安定した機能のみを使用する場合は、JSON Schemaライブラリ間の相互運用性が保証され、新しいリリースに追いつくためだけにスキーマを更新する必要はなくなります。
• スキーマを使用するライブラリがその機能をサポートしている限り、機能が安定する前に新しい機能を安全に使用できます。
• 互換性/相互運用性の保証は、次のリリース以降にのみ適用されます。スキーマを安定版に更新する必要がありますが、JSON Schemaが進化するにつれて継続的に更新する必要はありません。
• カスタム方言と語彙は、JSON Schemaのカスタマイズと拡張のための主要な概念として引き続き存在します。
• 実装者は、過去の安定版リリースをサポートするための個別のコードを維持する必要がなくなります。2025年リリースをサポートするライブラリは、自動的に2023年および2024年リリースもサポートします。過去の安定版リリースは、個別のバージョンとして維持する必要がなくなります。ただし、「ドラフト」リリースを引き続きサポートする実装では、それらを現在の安定版リリースとは別個のバージョンとして維持する必要があります。