[2] 差分仕様書とは、他の仕様書に対する差分の形で記述された仕様書のことをいいます。
[3] 一般に差分仕様書は理解が難しく、結合部分で不具合を生じやすいことなどから、好ましくないと考えられています。 特に差分仕様書によって元の仕様が改訂される場合、元の仕様書だけを見ても改訂されたことに気づけない危険性があります。
[4] W3C の出版規則は原則として差分仕様書を避けるようにと述べています。
[10] ただ差分仕様書が避けるべきものであるとの認識は必ずしも一般的ではありません。
[7] W3C の HTML WG は設立当初 (>>5) は差分仕様書でなく完全な仕様書を作ると憲章に明記していましたが、 WHATWG と決別した後の憲章 (>>6) では逆に拡張という形で差分仕様書をむしろ積極的に採用しています。 実際には憲章改訂の数年前から差分仕様書を量産していました。
[8] IETF は差分仕様書を好む文化があるようで、 DNS、TCP、telnet などは沢山の RFC が他の RFC に追加する形で改訂が重ねられていて、最新の有効な規定を探すのが困難です。
[11] SGML (ISO 8879) は本体仕様の改訂を ENR と Web SGML の2回行っていますが、 元の仕様書を改訂することを嫌い、どちらも Amendment という形の差分仕様書により発行しています。
[12] IRI (RFC 3987) は URI (RFC 3986) を拡張したものですが、 URI の仕様を参照しつつ違いを記述する形で IRI が定義されています。 (URI と IRI の概念は2つ分けたとしても、仕様書としては一緒にまとめても良かったようなものですが。 両者は足並みを揃えて同時に発行されたものの、 編集者も IETF の WG も別々でした。)
[13] XHTML 1.0 や XHTML m12n は HTML4 を XML の構文で再定義する差分仕様書の形で規定されていました。 そのため HTML4 のどの部分の規定が XHTML にも適用されるのかは曖昧でした。
[21] 差分仕様書が好まれる背景には、既に“確定”している既存の仕様書に手を入れたくないという事情があるようです。 確かに変更することにより仕様に不具合を混入させてしまう可能性はありますし、 標準化団体の手続きによってはそのような変更で手続き上の仕様の状態が後退してしまうこともよくあります。
[14] なお差分仕様書は同一の対象や密接に関わる同一階層の概念に関する場合によっては競合しかねない規定を別の仕様書に含めたものを指すので、 階層化、モジュール化された機能単位同士の仕様書は普通は差分仕様書とはいいません。
[16] 例えば TCP と IP は通常は組み合わせて使い、相互作用に関する規定も含まれてはいますが、異なる層の独立したプロトコルなので、 どちらがどちらの差分でもありません。電子メール (RFC 822) に対する MIME も、実際には深く関係するとは言え一応は独立した形をとっているので、 MIME は差分仕様書ではありません。
[17] また XML と XML Schema や、 XML と XLink は、一方が他方に依存してはいますが、 他方の仕様書の内容に変更を加えていませんから、互いに独立した仕様書であって、差分仕様書ではありません。
[18] 正誤表は、通常は差分仕様書とはいいませんが、差分仕様書と同じ問題点をはらんでいます。
[19] W3C勧告には必ず正誤表が用意されており、たまに追記されるようですが (頻度は担当 WG が存続しているかどうかや出版済み仕様書のメンテナンスの真剣度などにより異なります。)、 本文しか見ない人が多いので、修正前の古い記述に基づき理解されたり、実装されたりすることがよくあります。
[27] 差分仕様書状態が解消されることは、残念ながらそれほど多くありません。 逆に、混乱を解消するためなどと称して新たな説明のための文書が出版され、 そこで新たな解釈が発生して更に混乱を深めるようなこともあります。
[28] 解消された例:picture 要素は HTML Standard に統合されました。
[26] [lots] -webkit prefixed properties and values (Tab Atkins Jr. 著, 版) https://lists.w3.org/Archives/Public/www-style/2015Dec/0132.html
[35] Make a new/updated base IRC RFC · Issue #132 · ircv3/ircv3-specifications ( ()) https://github.com/ircv3/ircv3-specifications/issues/132
[36] 近年のWeb標準開発の現場では、まとまった新機能を追加するとき、 いったん既存仕様に対する差分仕様書 (+ 完全新機能) の形で仕様をまとめ、ある程度の完成を見た段階で差分を既存仕様書に upstream していく形態が一般化しています。 この形態は議論と変更が頻繁に行われる提案の初期段階では関係する規定を一箇所にまとめることができ、 しかも既存仕様との変更点だけをすぐに把握でき、 初期開発が完了した後の関心が薄れ始めてからは既存仕様の開発インフラに統合することで放置して現実と乖離していくリスクも軽減できるというメリットがあります。 不安定な仕様を既存仕様書に早い段階で統合してしまうことで既存仕様書が実態より先に進みすぎてかえって使いにくくなることも防げます。 開発がうまくいかなかったときも既存仕様書はそのままで新仕様書を廃棄するだけですみます。