要約

  • 憲章案は、WebDriverとWebDriver BiDiをSnapshot付きCandidate Recommendationへ進め、その段階で継続更新し、Recommendationを目標にしないとしている。
  • まだ提案であり、両仕様の現行文書はWorking Draftである。2018年のWebDriver Recommendationは同じ系列の別の公開状態で、新しい文書へ自動継承されない。
  • Candidate Recommendation SnapshotとDraftは、正式審査、特許手続、変更の意味が異なる。どちらもW3C標準として引用できない。
  • 再現可能な対応主張には、不変の仕様版、成熟度、WPTのcommitと試験範囲、ブラウザー、ドライバー、クライアント、OS、日付、除外事項が必要である。

中間段階を最終運用形態として選ぶ

WebDriverは、外部プログラムからブラウザーへ移動、要素探索、入力などを指示する共通手順を定める。WebDriver BiDiは、ブラウザー側の出来事を制御プログラムへ返す双方向路を加える。文書の一行は、複数のブラウザーエンジン、ドライバー、テストライブラリー、CI環境へ分かれて実装される。

W3Cは8月18日、次期憲章をAdvisory Committeeの審査に付した。一般からの意見は9月18日までで、現行憲章は10月23日まで延長された。従って後継憲章は未承認である。ただし提案が示す運用方針は分析できる。

規範的成果物として残るのはWebDriverとWebDriver BiDiである。作業部会は最新状態をCandidate Recommendationとして、Snapshotを伴って公開し、その後も更新する意向を示す。同時にRecommendationへ進める意図はないと書く。

これは単なる遅延ではない。Candidate Recommendationを長期の着地点にする設計である。W3Cの解説は、複数のコードベースから実装経験を受け取る仕様では、living CRが自然な場合があると述べる。節目をSnapshotで審査し、その間の統合状態をDraftで読めるようにする。

一方、下流は安定した引用点を自動的には得られない。Recommendationがなければならないという意味ではない。だが調達条件、障害報告、互換性表で「WebDriver」とだけ書いても、何を試したのかは確定しない。

憲章内の「最新版」は審査中にも進んだ

憲章案の成果物表は、WebDriverの最新版を4月1日、WebDriver BiDiを3月19日と記す。8月31日のW3C公開ページでは、それぞれ7月2日、8月25日のWorking Draftが最新版だった。

これは不正確さの告発ではない。憲章の起草・審査中も仕様は発行される。むしろ差分が、権限の対象を明確にする。憲章は変化する仕様系列を担当範囲に置く。ある実装者が使った版の本文を固定するものではない。

名前と成熟度も一対一ではない。W3Cは2018年6月のWebDriver Recommendationを維持しつつ、新しいWebDriver報告をWorking Draftとして掲載する。名称が同じだからといって後者が前者の成熟度を借りることはできず、前者が後から追加された全機能を含むわけでもない。

latest URLは現在の編集状態を読むには便利だ。しかし過去の検証を再現するとき、その参照先はすでに変わっている可能性がある。

SnapshotとDraftは別の問いに答える

W3C Processでは、最初または更新時のCandidate Recommendation Snapshotに、検証された移行・更新要求を求める。SnapshotはPatent Review Draftでもある。公開説明では、作業部会の合意、一般および他グループの正式審査、参加者のロイヤルティーフリー許諾上の約束が結び付く。

Candidate Recommendation Draftは、Snapshot後の変更予定を統合する。仕様を新しく保つため、公開要件は軽く設定される。その変更はSnapshotと同じ正式審査を受けておらず、Draft自体は同じ特許除外機会を生まない。

どちらもW3C標準ではない。またSnapshotだけで十分な実装経験が証明されるわけでもない。W3Cのliving CR解説は、変更中、実装の偏り、限定的な相互運用、試験不足が残り得ると明記する。

だからSnapshotに価値がないのではない。Snapshotは審査済みの実装目標と特許上の節目を示し、Draftはその後の統合状態を示す。Recommendationなら、さらにW3Cの承認と実装経験の条件が加わる。区別を保つことが制度の役割である。

実際の「対応」は複数記録の交点にある

憲章案は、Candidate Recommendationの変更や配備済み機能にWeb Platform Testsを求め、新機能には少なくとも二つの実装候補から関心表明を求める。安全性、プライバシー、アクセシビリティの節と横断審査も必要とする。

ただし関心表明は実装ではない。テストが存在しても規範要件を十分に覆うとは限らない。WPT画面の成功表示も、テストcommitとブラウザーbuildがなければ後日再現できない。機能がflag内だけの場合や、クライアントライブラリーが一部しか公開しない場合もある。

重要な結果には、少なくとも次を残すべきだ。

不変仕様版 + 成熟度 + テストcommit/選択 + ブラウザー/ドライバー/クライアントbuild + 環境 + 日付 + 除外事項

CR Draftを試すなら直前のSnapshotと対象変更を、Snapshotなら移行または更新決定と特許審査状態を結ぶ。latestを要件に使うなら、いつ、どの仕組みで解決し、どの不変URLを得たかも必要になる。

これは新しい認証制度ではない。W3C、作業部会、実装プロジェクト、利用者の権限はそのままに、それぞれの記録が交差した地点を保存するだけである。

Recommendationを強制する議論ではない

公開資料から、必ずRecommendationへ進むべきだとは言えない。実装から頻繁に学ぶプロトコルでは、living CRが実態に合う可能性がある。最終版という看板だけで互換性が生まれるわけでもない。

危険なのは、柔軟な状態から版情報が外れることだ。特定Draftの限定的な成功が系列全体の対応へ拡張され、後の変更が過去の契約へ逆流する。同じ名称が、審査と挙動の差を消してしまう。

結果の版を固定しても開発は止まらない。新しい仕様、テスト、実装には新しい記録を作ればよい。比較可能性が速度を妨げるのではなく、速度の意味を残す。

未確定事項

憲章は変更、承認、否決のいずれもあり得る。living CR条項も確定していない。両仕様はまだCandidate Recommendationではなく、最初の移行日も示されていない。

本稿は現在のブラウザー互換性を採点せず、WPTの動的画面を判定書として扱わない。必要な証拠粒度は用途で変わる。今日の開発版を調べる作業と、数年後にも有効な調達条件は同じではない。

確かな境界は一つである。Candidate Recommendationを継続的な着地点にするなら、正確な版の同定は技術的脚注ではなく統治成果になる。系列名は作業の場所を示すが、実行された組合せを示さない。

情報源

  1. W3Cの次期憲章審査案内
  2. Browser Testing and Tools次期憲章案
  3. Browser Testing and Tools現行憲章
  4. W3C Process
  5. 成果物の最終成熟段階に関するW3C解説
  6. W3Cが公開する文書の種類
  7. WebDriver最新技術報告
  8. WebDriver公開履歴
  9. WebDriver BiDi最新技術報告
  10. WebDriver BiDi公開履歴
  11. WebDriver BiDiのWPT結果
  12. WebDriver BiDiのWPTテストツリー