[2] 適用可能な仕様書applicable specificationとは、 実装や著者に対する要件を議論するにあたって考慮する対象とする仕様書のことをいいます。

仕様書

意味

[3] 仕様書は、ただ存在しているだけでは何ら効力を有しません。 権威を有する標準化団体によって出版されたとしても、それだけでは実効性を伴いません。 分野と国によっては法的に強制される標準仕様も存在しますが、 そのような例外を別とすれば、どの仕様書を選択し、実装するかは実装者に委ねられています。 ある仕様書が有益であり、それに従って実装する価値があると考えるなら、 それはその実装者にとって適用可能な仕様書となります。

[4] 仕様書に基づき行われる行為、例えば情報交換は、 通常送信者と受信者のように複数の当事者が存在します。 関係する当事者間で適用可能な仕様書の集合が一致していれば、 (そしてそれに適合しているなら、) 想定通りに正しく行えると期待されます。 そうでない場合、その行為が正しく行われ、正しく理解されるかどうかは自明ではありません。 場合によっては内容が矛盾する複数の仕様書が存在することもありますから、 どの仕様書が適用可能と考えるかにより、何が正しいかの定義が変わってきます。

[17] それ自体に意味は無いとはいっても、標準化団体の権威は仕様を選択する基準の一つとなり得ますから、 まったく無価値ではありません。更に、当該分野の主要プレイヤーが参画し標準化過程が正常に機能している標準化団体なら、 手続きを通過したことが業界における合意の存在を表しているとも言えます。 しかし結局は権威の源泉たる、業界の当該仕様への信頼にこそ意味があり、 権威自体から機械的に効力が発生するわけではありません。

[18] 例えば00年代前半には、日本の一部の Webサイトの著者が ISO の権威に惹かれたのか、 ISO-HTML を猛プッシュしていました。 しかし、一般的な著者にとっても、Webブラウザーの実装者にとっても、 (そしてWebブラウザーの利用者にとっても) ISO-HTML 仕様は有益なものでなかったため、市場には影響を与えませんでした。

Web における定義

[5] HTML Standard に対して vendor 中立な拡張が必要な時には、 HTML Standard 自体が更新されることもありますし、 HTML Standard の要件を上書きするような拡張仕様書を書くこともできます。 HTML Standard を自身の行為に適用している人がそのような拡張仕様書の要件を認識すると決めたなら、 HTML Standard の適合性の要件に於いては、適用可能な仕様書applicable specificationとなります。 >>6

[7] 仮に誰かが「任意のバイト列は適合する」と定義する仕様書を書いて、 適当なごみデータを適合すると主張したとします。しかし、 かと言ってそのごみデータが誰の目からも適合していると言えるわけではありません。 他の誰かがその仕様書を適用しないことにすれば、そのごみはあくまでゴミであって、 適合しないと言えます。適合性に関して特定のコミュニティーでどのような要件が適用されるかは、 そのコミュニティーで何を適用可能と合意するかに依るのです。 >>6

[12] DOM Standard にも同じ定義があります >>11。

実例

[8] 例えば HTML 仕様に対する拡張として、 W3C HTML WG は longdesc 属性を定義する独自の仕様書を出版しています。 WHATWG HTML Standard は longdesc 属性は廃止されたものと明記しており、 著者がこれを利用することを禁止しています。両者は矛盾していますが、もし W3C の longdesc 属性の仕様書をも適用可能な仕様書として採用すれば、 longdesc 属性を使った文書を適合すると主張することができます。

[9] もちろん、その主張が理解されるのは、同じように longdesc 属性の仕様書を適用可能な仕様書と認識する人々の間だけです。 HTML Standard で longdesc 属性が廃止されたのは、 どの Webブラウザーも実装しておらず、利用している文書もそう多くなく、 利用している場合には誤用が多い、またこれらの状況が変化する見込みはない、 という状況が続いているのが理由ですから、そのような状況を改善できない仕様書を書いたところで、 >>7 のごみデータと大差はないのです。

[10] HTML Standard が定義する unload a document 手順は、 「他の適用可能な仕様書の unloading document visibility change steps があれば実行する」 という部分を含んでいます。そして Page Visibility 仕様書がこの unloading document visibility change steps を定義しています。このため、 Page Visibility 仕様書を適用可能な仕様書と認識し、実装するWebブラウザーは、 文書の unload の途中で Page Visibility 仕様書に基づく処理を実行することになります。 Page Visibility の機能を用いた文書が世界に複数存在しており、 それを正しく処理するために複数の Webブラウザーが Page Visibility 仕様書の機能を実装していることから、これらの文書の著者と Webブラウザーの実装者の間では、 Page Visibility 仕様書は適用可能な仕様書の1つと認識されていることになります。

[16] 仮にこの認識に賛同しない Webブラウザーがあれば、 Page Visibility 仕様を実装していないとしても、 HTML Standard に違反していることにはなりません。 しかし現実には Page Visibility の機能を使った文書が存在しており、 そのような Webブラウザーでは正しく動作しないことになりますから、 その Webブラウザーは利用者にとって有用でないと言えます。 このように、何が適用可能な仕様書であるかは文脈 (コミュニティー、 あるいは市場と言い換えても構いません。) によって強制されることもあります。 より極端な例では、 HTML Standard は適用可能な仕様書では無いとして HTML を実装しない 「Webブラウザー」も理論上は存在し得ますが、そのような「Webブラウザー」 が市場に受け入れられる可能性はありません。

[21] このことをより細かな粒度で表した概念が「Web互換性」です。

歴史

[13] ある特定の基本仕様に対する拡張仕様に関する制約を記述したり、 拡張仕様書の体裁や登録手続きなどを規定したりすることは古くからよく行われてきました。 しかし、そのような拡張に関する仕様は普通は基本仕様が設定した範囲内に限定されるもので、 元となる仕様書の規定を上書きすることは認められていませんでした。 また、基本仕様が拡張仕様に定義を委任することで基本仕様に拡張仕様を加えた仕様群の一体性と正当性を確保する形を採っているのが普通でした。 更に、その拡張仕様の出版元が基本仕様の出版元に限定されていたり、 基本仕様の出版元が登録簿を設置して所定の手続きによる登録を義務付けたりして、 基本仕様の制定者が全体を統制下に置こうとしがちでした。

[15] それに対して HTML Standard による仕様書の適用可能性は、 仕様に含まれる規定を上書きすることを禁止していませんし、 適用可能な仕様書の範囲を限定することもしていません。 むしろ適用可能な仕様書の集合が異なり得るものであることを明記しています。 誰が適用可能な仕様書を出版するかも、一切制限していません。 これは仕様書の発行元の権威ではなく市場、すなわち実装者と著者、 利用者の選択によって発展してきた Web の歴史を反映したもので、 HTML Standard の新発明ではありませんが、 それまで明確にされなかった原理を初めて明文化した画期的なものでした。

[20] ところで HTML Standard を (内容を完全に理解せずに) コピペして出版している W3C は、「applicable specification」の規定を曲解して、 W3C が「applicable specifications」の指すものを規定する(できる)ものと考えている節があります。 拡張仕様書