要約

  • 現行の2025年W3C Processでは、Recommendationの本文に新機能を追加するには、初めてRecommendationとして公開する前から追加可能と明示しておく必要がある。2026年10月25日の草案は、この条件を全件について外す。
  • 候補修正は注記の段階では規範にならない。少なくとも60日の公開コメント、Advisory Committeeの審査、特許除外の機会、実装経験などを経て更新される。機能の範囲を固定したい採用者には日付入りの版が要る。

貼り付けた一行が、後日の合意を決める

調達仕様書の担当者がW3CのURLを一つ貼る。納入側も同じページを開く。そこで安心してしまうと、二人が別の時点の文書を読んでいる可能性を見落とす。URLには、特定の日に出た版を示すものと、いま公開されている最新版へ進むものがある。誤字の修正なら差は小さい。新しい機能の追加なら、検査する対象そのものが増える。

2025年8月18日の現行Processは、勧告になった文書の機能を後で増やす条件を先に決めさせている。最初のRecommendation公開までに「新機能を許す」と示した文書なら、既存の勧告を改訂して機能を追加できる。そうでなければ、別の技術報告をFirst Public Working Draftから始め、勧告へ進める。既存文書の誤りを直す道は残る。標準の機能集合については、事前宣言がない限り増えないという初期値がある。

10月25日付の次期Process草案は、その初期値を変える。クラス3の実質変更とクラス4の新機能を、すべてのRecommendationに候補修正として載せられる仕組みだ。草案は簡素化のために以前の制約を外したと説明する。規則を書く側にとっては分類が一つ減る。既存のRecommendationを長年引用してきた側には、同じ「最新版」URLの内側で機能が増える可能性が生まれる。

草案はまだCommunity Groupの報告案であり、W3Cの状態説明は現行Processが引き続き使われると明記する。Advisory Boardが準備し、Advisory Committeeが審査する段階が残っている。技術規範の変更を、草案リポジトリへのマージだけで既成事実にしてはいけない。

消える保証、残る固定版

W3CのProcessプルリクエスト1168には、変更を推す理由が率直に書かれている。従来の区別は複雑で混乱を招いた。一方、事前宣言のない勧告では、文章の手直しやバグ修正が続いても機能集合が増えないという保証が、日付のないURLの利用者にあった。提案者は、その保証に実際に依存している証拠は乏しいと述べる。変更は7月22日に草案側へマージされ、定義済みの八つの用語を廃止した。廃止用語を説明する付録を除けば、本文は差し引き43行短くなる。

「依存の証拠が乏しい」は、リポジトリで確認できる範囲についての説明だ。外部の契約、購買要件、互換性試験が何件この既定値を頼りにしているか、公開資料からは数えられない。コメントが少ない保証ほど役に立たない、という結論も出せない。そもそも既定値は、毎回申し出なくても働くように設けるものだからだ。

W3Cの仕様参照ガイドは、引用の作法をはっきり分ける。「this version」は特定の公開文書。「latest published version」はシリーズの最新公開文書。編集者の草案はさらに別の作業面だ。特定版は壊れたマークアップやリンクの限定的な修正を除き、元の形で長く残す方針が示されている。採用した機能範囲を固定したいなら、日付入り版のURIを書けばよい。最新版を追うなら、追うという決定を明記しなければならない。

修正案の棚に置いただけでは効かない

新しい経路にも審査はある。候補修正は注記として公表されるだけで、直ちに規範本文を変えない。本文へ組み込むには、公開の最終レビューを呼びかけ、少なくとも60日コメントを受け付け、実装経験を求める。Advisory Committeeの審査と特許除外の機会、コメントへの正式対応、十分な実装経験、更新出版の申請が続く。Working DraftやCandidate Recommendationへ戻る経路も残る。

10月26日のARIA公開議事録では、編集者たちが特許期間、変更履歴、実装が進んだ後から届く横断的レビューを議論した。現場で効くのは、審査が存在することだけではなく、実装が固まる前に変更を読めることだ。この会議は今回のProcess草案や個別機能の採択記録ではない。

W3Cは規則の中で機能追加の入口を一本化できる。契約や製品で標準を使う人には、別の仕事が残る。どの日の、どの版を受け入れたか。短いURLにその決定を代行させてはいけない。

出典