Edit

Page

Page title:

Page body:

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

* 仕様書

[REFS[
- [6] [CITE@en-GB-x-hixie[HTML Standard]] ([TIME[2014-05-23 20:05:44 +09:00]] 版) <https://www.whatwg.org/specs/web-apps/current-work/#other-applicable-specifications>
- [11] [CITE@en-US[DOM Standard]] ([TIME[2014-05-26 14:29:04 +09:00]] 版) <https://dom.spec.whatwg.org/#other-applicable-specifications>
]REFS]

* 意味

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

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

;; [17] それ自体に意味は無いとはいっても、[[標準化団体]]の[[権威]]は[[仕様]]を選択する基準の一つとなり得ますから、
まったく無価値ではありません。更に、当該分野の主要プレイヤーが参画し標準化過程が正常に機能している標準化団体なら、
手続きを通過したことが業界における合意の存在を表しているとも言えます。
しかし結局は権威の源泉たる、業界の当該仕様への信頼にこそ意味があり、
権威自体から機械的に効力が発生するわけではありません。
[EG[
[18] 例えば00年代前半には、[[日本]]の一部の [[Webサイト]]の[[著者]]が [[ISO]]
の権威に惹かれたのか、 [[ISO-HTML]] を猛プッシュしていました。
しかし、一般的な[[著者]]にとっても、[[Webブラウザー]]の実装者にとっても、
(そして[[Webブラウザー]]の[[利用者]]にとっても)
[[ISO-HTML]] 仕様は有益なものでなかったため、[[市場]]には影響を与えませんでした。
]EG]

* Web における定義

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

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

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

* 実例

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

[9] もちろん、その主張が理解されるのは、同じように [CODE(HTMLa)@en[[[longdesc]]]] 
[[属性]]の[[仕様書]]を[[適用可能な仕様書]]と認識する人々の間だけです。
[[HTML Standard]] で [CODE(HTMLa)@en[[[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] それに対して [CITE[HTML Standard]] による仕様書の適用可能性は、
仕様に含まれる規定を上書きすることを禁止していませんし、
適用可能な仕様書の範囲を限定することもしていません。
むしろ適用可能な仕様書の集合が異なり得るものであることを明記しています。
誰が適用可能な仕様書を出版するかも、一切制限していません。
これは仕様書の発行元の権威ではなく[[市場]]、すなわち[[実装]]者と[[著者]]、
[[利用者]]の選択によって発展してきた [[Web]] の歴史を反映したもので、
[CITE[HTML Standard]] の新発明ではありませんが、
それまで明確にされなかった原理を初めて明文化した画期的なものでした。

- [22] 
[CITE@en['''['''e''']''' (0) Other applicable specifications definition.]], [[Hixie]], [TIME[2009-09-29 11:41:23 +09:00]], [TIME[2024-09-08T12:52:39.000Z]] <https://github.com/whatwg/html/commit/b243875c11017244cac2e928f78e74672a5feb9c#diff-41cf6794ba4200b839c53531555f0f3998df4cbb01a4d5cb0b94e3ca5e23947d>

[REFS[
- [1] [CITE@en[Web Applications 1.0 r5996 9178]]
( ([TIME[2011-04-13 08:32:00 +09:00]] 版))
<http://html5.org/tools/web-apps-tracker?from=5995&to=5996>
- [14] [CITE@en[Re: TAG minutes 10 Sep for review (f2f planning, websockets URI  scheme, HTML, ...)]] ([[Henri Sivonen]] 著, [TIME[2009-09-17 16:54:11 +09:00]] 版) <http://lists.w3.org/Archives/Public/www-tag/2009Sep/0041.html>
]REFS]

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

[REFS[
- [19] [CITE@en[Longdesc shouldn't be described in text - ignores modularization · Issue #507 · w3c/html]] ([TIME[2016-08-03 12:00:00 +09:00]]) <https://github.com/w3c/html/issues/507>
]REFS]

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Page name(s)