要約

  • W3C Advisory CommitteeによるWeb of Things Working Group憲章案の審査は、2026年8月31日23時59分（UTC）に締め切られる。本稿の基準時点では結果は公表されていない。
  • 憲章案はWoT Binding Registryを追加し、2027年にRegistry Draft、Candidate Registry、W3C Registryへ進む日程を掲げる。
  • 公開中のレジストリ文書はまだ試行版である。Working Groupが作成した少数のバインディングはInitialから先へ進めず、外部提出は試行後に開く予定だ。
  • 将来のCurrent移行には、対象仕様の観点とWoT Thing Description適合性の観点による二つの審査が必要になる。同じ人が両分野の専門性を持つ場合、二つの文書を作成したうえで両方を担当できる。
  • Currentは、管理者が新規実装に推奨し、十分な実装経験があると判断した状態をいう。W3C Recommendationや普遍的な相互運用性を意味しない。
  • 移行ごとに「役割・証拠レシート」を残し、一人か二人か、各役割が何を確認したか、試験範囲、管理者の理由を明示すべきである。

締切は承認日ではない

これまでのWoT憲章では、プロトコル・バインディングは主として文書として扱われてきた。新しい案は、それらを構造化された更新可能なレジストリに載せ、W3C内部だけでなく外部の標準化コミュニティからも受け入れる構想を示す。単に文書の置き場所を変えるのではない。どの項目を推奨し、いつ状態を変えるかという継続的な判断機能をつくる。

8月31日は審査期間の終了であり、自動承認の日ではない。現行憲章は10月16日まで延長され、案の開始日と終了日はなお未記入である。2027年第1四半期のRegistry Draft、第2四半期のCandidate Registry、第3四半期のW3C Registryは計画であって、達成済みの状態ではない。

一方、作業の中身は既に見える。Binding Registry草案は、項目、提出条件、ライフサイクル、試験、審査責任を定めている。文書自身が「まだW3C Registryではない」と明記し、試行期間中はWorking Group由来の少数エントリーをInitialに固定する。外部提出はその後である。

この区切りは健全だ。実物で手続きを試しながら、試験中の状態を制度的な推奨として売り出さずに済む。

Currentは運用上の指示になり得る

ライフサイクルはInitial、Current、Superseded、Obsoleteの四段階である。エントリーは削除しない。新しい版には新しいエントリーを作り、旧版は状態を変えて残す。

ここでCurrentは単なる最新版ではない。草案は、管理者が新規実装に推奨し、十分な実装経験がある状態と定義する。ライブラリ、開発者向け文書、調達仕様は、この一語を選択の近道に使い得る。レジストリはプロトコルそのものではなくても、実装の流れを動かす。

W3C Processはその権限を限定する。レジストリが記録するのは値であり、アーキテクチャや相互運用性の要件を定義してはならない。要件はレジストリを参照する仕様側に置く。またRegistry ReportはW3C Patent Policyの対象ではなく、安定したエントリーがあるだけでRecommendationになることもない。

憲章案は、元のプロトコルを変更する権限も切り分ける。バインディング作業でプロトコル側の修正が必要だと判明した場合、WoT Working Groupは当該プロトコルを所管する組織に委ねる。MQTTやModbus、BACnet、CoAPのバインディングを登録しても、それらを改定する権限は得られない。

だからこそ、Currentの意味と非意味を決定記録に結び付ける必要がある。

二つの問いを一人が検査する場合

InitialからCurrentへの移行では、異なる二つの問いを扱う。対象仕様側の審査は、WoTの操作がプロトコルのメッセージへ正しく対応しているかを見る。WoT側の審査は、Thing Descriptionの意味と操作が一貫し、Consumerが記述どおりに扱えるかを見る。

草案は、対象仕様の専門家とWoTの専門家を少なくとも二人割り当てるべきだとする。その直後に、両方の専門性を持つ人なら同一人物が双方を担当できると記す。ただし審査文書は二つに分けなければならない。

この柔軟性には理由がある。特定の産業プロトコルとWeb抽象化の両方を深く理解する人材は少ない。境界を知る一人の専門家が、形式だけの二人目より有益なこともある。

しかし二文書は、二つの独立した裏付けと同じではない。同じ版依存を読み違え、同じ試験前提を受け入れ、同じ例外経路を見落とせば、盲点は二審査にまたがる。反対に、二人いても、所属企業、実装、テストハーネス、設計上の前提が共通なら独立性は弱い。

必要なのは人数規制より審査構造の開示である。一人が二役を担ったなら、その事実自体を状態として残すべきだ。

試験の床はあるが、証拠の型は未完成

試行版は、単なる机上審査を求めているわけではない。バインディングが定義する各操作をテストイベントで自動検証しなければならない。Test Reportには環境、シナリオ、Thing Descriptionから通信成立までの論理的な流れを記載する。さらに記述された操作と機能を扱えるConsumerとExposerを少なくとも一つずつ含める。

つまり、動く実装がCurrentの前提に置かれている。

同時に草案は、Test Reportの正確な内容がまだ決まっていないと認め、2025年2月から開いているissue 3を参照する。未解決なのは試験の要否ではなく、結果をどの形式で検証可能にするかだ。

任意のエラー経路も全操作に含めるのか。同じコードベースの両端をConsumerとExposerとして数えられるのか。共有ライブラリや共通ハーネスをどう開示するのか。失敗と修正履歴を残すのか。メッセージ交換だけでなく意味の適合を何で示すのか。

外部エントリーが進み始める前に決めなければ、最初の成功例が明文化されていない証拠基準を事実上固定する。

「役割・証拠レシート」を付ける

草案には既に公開issue、レビュー、pull request、待機期間がある。新しい裁定機関を作る必要はない。散在する資料を一つの状態変更に結ぶ短い記録があればよい。

レシートは、バインディング、対象仕様、補助文書、適用したレジストリ定義の版を固定する。二つの審査役を別欄にし、担当者、関連専門性、同一人物が兼任したかを明記する。提出者、プロトコル、試験実装との関係や利益相反は、判断に必要な範囲で示し、不要な個人情報は載せない。

証拠欄には試験日、環境、Consumer、Exposer、操作別の網羅範囲、共有コード、未試験経路を記す。二つの審査は、それぞれ結論、留保、修正要求を残す。その後にコメント期間、異議、管理者の日時付き判断、理由、根拠となる定義版を続ける。

Currentの横には四つの非主張も必要だ。W3C Recommendationではない。普遍的な相互運用性の証明ではない。元のプロトコルを変更しない。レジストリ文書にPatent Policy上の約束を生じさせない。

エントリーがSupersededやObsoleteへ移っても、レシートは残す。行だけ保存して、なぜかつて推奨したかを失えば、履歴は再現できない。

Heng Luの議論を狭く適用すれば、専門家は判断を、動く実装は証拠を、管理者は限定された権限を提供する。どれか一つが他の二つの代わりをしてはならない。

試行段階だから安く直せる

一人二役の審査が失敗した、手続が支配された、特定のバインディングに欠陥がある、という証拠はない。将来手続の下で外部エントリーがCurrentになった事実も示されていない。憲章はなお案である。

だから今なら、防御的な危機対応ではなく設計として記録を整えられる。ツールや調達担当がCurrentを既定値にしてから来歴を復元する方が、はるかに高くつく。

二つの審査は二人でも、一人でもよい。ただし最終的な緑色の状態が、その違いまで消してはならない。

情報源

  1. WoT憲章案のW3C審査通知
  2. Web of Things Working Group憲章案
  3. 現行Web of Things Working Group憲章
  4. WoT Binding Registry試行版
  5. 固定コミットのレジストリ原文
  6. issue 3：Test Report内容の定義
  7. W3C Process：Registry Track
  8. Heng Lu「The Multi-Stakeholder Mirage」