仕様は依存ツリーのどこに位置するのか？

あなたの Ruby gem は required_ruby_version >= 3.0 を宣言しています。 ランタイムは少なくともツールのどこかに現れます。あなたの HTTP ライブラリも RFC 9110 に依存し、JSON パーサーは ECMA-404 に、TLS 実装は RFC 8446 に依存していますが、それらのいずれもマニフェスト、ロックファイル、または SBOM（ソフトウェア部品表）には現れません。 ライブラリの依存関係には完全な扱いが施されます：マニフェストで宣言され、ロックファイルで固定され、SBOM で追跡され、スキャナで脆弱性チェックが行われます。一方、ランタイムのバージョンは1層下位に位置し、エコシステムごとに異なる方法で扱われます。Python には Requires-Python という仕組みがあります。 開発者は、これら単独では十分に信頼できないため、新しいレイヤーを次々と発明し続けています。Ruby プロジェクトでは required_ruby_version >= 3.0 が使われますが、ランタイムの実装自体はほとんど追跡されていません。JRuby 9.4 は RUBY_VERSION を報告しますが、それでも不十分です。 そのすべての下位には、仕様書自体が存在します。言語定義やプロトコル標準、エンコーディングルールなどですが、これらも依存グラフのどこにも現れません。 HPC パッケージマネージャーである Spack は、依存関係を暗黙的に放置したときに何が起きるか学ぶために7年間を費やしました。 Spack v1.0 以前では、コンパイラは依存グラフ内の実際のノードではなく、特別な「ノード属性」として扱われていました。これらは compilers.yaml で設定されます。 gcc-runtime のようなコンパイラのランタイムライブラリも同様に扱われます。 この問題を解決するアイデアは 2016 年に提出されました。動機となったのは、あるデバッグの事例です。システム管理者が大規模な依存関係グラフをインストールしましたが、gfortran が欠落しており、openmpi は Fortran サポートなしでビルドされ、その後、hypre がずっと後に失敗しました。パッケージが言語依存関係を宣言していれば、ビルドが始まる前に依存関係解決プロセス自体が不足しているコンパイラを検出できたはずです。 PR #45189（"Turn compilers into nodes"）がマージされたのは 2025 年 3月まで待たなければなりませんでした。Spack v1.0 では、C言語のような言語も depends_on("c") depends_on("cxx") のように扱われます。 Nix は常にコンパイラをハッシュ化された依存関係として扱ってきました。すべての派生（derivation）は stdenv を通じてビルドツールを取得します。 仕様遷移 その境界で何が起きるのでしょうか？仕様が変わり、実装がそれに追随しなければならない場合です。結果はほとんどがきれいなものではありません。 Chrome と Firefox が 2017 年 2 月に TLS 1.3 のテストを有効にした際、失敗率は予想以上に高くなりました。Chrome から Gmail への接続では、TLS 1.2 では 98.3% の成功率でしたが、TLS 1.3 ではわずか 92.3% でした。犯人はミドルボックス（middlebox）でした。企業のプロキシやファイアウォールで、TLS ハンドシェイクのフィールドについてハードコードされた期待値を持っていたものです。TLS の仕様ではこれらのフィールドの変更を常に許可していましたが、長期間安定していたため、ミドルボックスの開発者はそれらを定数として扱っていました。 現在の TLS 1.3 は自身のバージョンについて嘘をついています。ClientHello は TLS 1.2 であると主張し、TLS 1.3 では不要なダミーの session_id および ChangeCipherSpec フィールドを含み、supported_versions を使用します。 Unicode は毎年おおよそ新しいバージョンをリリースしており、各バージョンでは既存の文字のプロパティを変更するだけでなく、新しい文字を追加することもあります。Chrome が ICU データを更新した際、レスラーと握手の絵文字は Emoji_Base 属性を失いました。 PyPI クラシファイアにより、パッケージは Programming Language :: Python :: 3 を宣言できます。 python_requires Node.js における CommonJS と ES Modules は互換性のないモジュール仕様です。ESM は CJS をインポートできますが、CJS は require() を使用できません。 SMTP から ESMTP への移行はプロトコルレベルでネゴシエーションが行われ、クライアントは EHLO を送信します。 実行可能な仕様 Web Platform Tests には 56,000 以上のテストと 180 万のサブテストがあり、それぞれ W3C または WHATWG の仕様の特定のセクションにマッピングされています。WPT ダッシュボードでは、どのブラウザエンジンがどのテストをパスしたかが表示されます。TC39 の Test262 は ECMAScript に対して同様の役割を果たします。「CSS Grid Level 1 を実装しました」とブラウザチームが言う場合、実際には特定の WPT テストセットに合格していることを意味します。 これらのテストスイートは、プロース形式の RFC よりも依存関係として宣言できるものに近いです。これらはバージョン管理され、コミットハッシュを持つ具体的なアーティファクトです。仕様依存関係に対して PURL 型の識別子を必要とする場合、仕様ドキュメントのバージョンよりもテストスイートのバージョンの方が有用かもしれません：pkg:spec/w3c/wpt-css-grid@sha256:abc123 pkg:spec/w3c/css-grid@level-1 ただし、多くの仕様には適合性スイート自体が存在しません。IETF RFC は公式テストを同梱することはめったにありません。テストが存在する場合でも、標準化過程における相互運用性テストから生まれ、その後メンテナンスされなくなることがほとんどです。ほとんどのソフトウェアの依存チェーンは依然として「パッケージ → 実装 → プロセステキスト文書の暗黙的な理解」という構造になっています。 TypeScript の DefinitelyTyped エコシステムでは、ランタイム API に対してすでにこのようなアプローチが採用されています。@types/node 事実上の仕様 すべての仕様が標準化団体に存在するわけではありません。Node.js モジュール解決には正式な仕様がありません。これは Node の動作によって定義されており、誰かがそれを文書化するかどうかに関わらず、同じ方法でモジュールを解決するものはすべてその動作に依存しています。 Oracle は Java EE を Eclipse 財団に寄贈しましたが、Java の商標権は保持しました。これにより、Eclipse 財団が javax パッケージを変更することが妨げられました。 javax.persistence 仕様間の依存関係 仕様には独自の依存グラフが存在します。JSON は UTF-8 に依存し、その通じて Unicode に依存しています。HTTP は TLS の上にあり、TLS は X.509 と ASN.1 の上にあります。したがって、ASN.1 符号化に対する破壊的変更は、TLS 実装に波及し、そこから HTTP ライブラリを経由してネットワーク要求を行うすべてのものに影響を及ぼします。CSS Grid は Box Model（ボックスモデル）と Visual Formatting contexts（視覚フォーマット文脈）の上に構築されています。 rfcdeps ツールは、RFC エディタの XML インデックスから「obsoletes（廃止）」および「updates（更新）」ヘッダーを解析することでこれらの関係をグラフ化しますが、仕様グラフとソフトウェア依存関係グラフを接続する方法を持っていません。また、誰もそれを試したようには見えません。 パッケージ管理は命名の問題であり、仕様の命名問題はパッケージのそれよりも深刻です。 IETF は、仕様の新バージョンごとに完全に新しい番号を付与する連番方式を使用しています。RFC 9110 は RFC 7231 を廃止し、その RFC 7231 は RFC 2616 を廃止しました。「HTTP セマンティクス」を参照したい場合、どの RFC 番号を選ぶかを決める必要があり、その選択はバージョン範囲ではなく特定の時点点を符号化することになります。W3C は CSS にレベル（CSS Grid Level 1, Level 2）を使用し、古い仕様には番号付きバージョン（HTML 4.01）、成熟度段階（Working Draft, Candidate Recommendation, Recommendation）を使用します。WHATWG はバージョン管理を完全に放棄し、HTML はバージョン番号もスナップショットもない「Living Standard」として扱われています。ECMA は版数と年名を組み合わせて使用しています（ECMA-262 第 6 版は ES2015 とも呼ばれます）。ISO は、改正および訂正の層を持つ構造化識別子を使用します（ISO/IEC 5962:2021） インターネットドラフト（draft-claise-semver-02）は、IETF 仕様にセマンティックバージョニング（semver）を適用し、RFC にパッケージが使用するのと同じ種類の機械比較可能なバージョン識別子を与えることを提案しましたが、採用されることなく期限切れとなりました。障壁は実際には技術的なものではなく、標準化団体は何十年も独自の方式でバージョン管理を行っており、その慣習はツールや引用慣行、組織プロセスに組み込まれています。IETF、W3C、WHATWG、ECMA、ISO、IEEE が共通のバージョニングスキームに合意することは、パッケージマネージャーがロックファイル形式に合意することよりもはるかに困難な調整問題です。 もし仕様に PURL に似たスキームを望むなら、pkg:spec/ietf/rfc9110@2022 のようなものが考えられます。 仕様を明示的に扱うには、問題を一度にすべて解決する必要はありません。データモデルの一部は既に存在しています：SPDX 3.0 には hasSpecification という概念が含まれています

仕様は依存ツリーのどこに位置するのか？

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト