[2] 差分仕様書delta specificationとは、他の仕様書に対する差分の形で記述された仕様書のことをいいます。

[3] 一般に差分仕様書は理解が難しく、結合部分で不具合を生じやすいことなどから、好ましくないと考えられています。 特に差分仕様書によって元の仕様が改訂される場合、元の仕様書だけを見ても改訂されたことに気づけない危険性があります。

[9] 特に元の仕様書の規定に割り込む形で新しい規定を注入するものを猿パッチといいます。

[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] 差分仕様書が好まれる背景には、既に“確定”している既存の仕様書に手を入れたくないという事情があるようです。 確かに変更することにより仕様に不具合を混入させてしまう可能性はありますし、 標準化団体の手続きによってはそのような変更で手続き上の仕様の状態が後退してしまうこともよくあります。

[23] 例えば IETF の標準化過程RFCは技術的に変更が加えられると提案標準からやり直しになります。

[22] 例えば W3C の標準トラックの仕様書は技術的に有意な変更があると LC からやり直しになります。

[24] 逆に差分化することで統合部分の規定が不十分であるなどの不具合が生じたり、 差分出版後の元の仕様の更新で不整合が生じたりするリスクはありますが (リスクだけでなく実際そうなった例は枚挙に暇がないのですが)、 それらは発覚に時間がかかりますから、差分化する時には気づかないのでしょう。。。[25] このような事情はモジュール化が好まれる理由とも同じでしょう。

[14] なお差分仕様書は同一の対象や密接に関わる同一階層の概念に関する場合によっては競合しかねない規定を別の仕様書に含めたものを指すので、 階層化、モジュール化された機能単位同士の仕様書は普通は差分仕様書とはいいません。

[16] 例えば TCP と IP は通常は組み合わせて使い、相互作用に関する規定も含まれてはいますが、異なる層の独立したプロトコルなので、 どちらがどちらの差分でもありません。電子メール (RFC 822) に対する MIME も、実際には深く関係するとは言え一応は独立した形をとっているので、 MIME は差分仕様書ではありません。

[17] また XML と XML Schema や、 XML と XLink は、一方が他方に依存してはいますが、 他方の仕様書の内容に変更を加えていませんから、互いに独立した仕様書であって、差分仕様書ではありません。

[15] >>14 の観点で >>12 は URI がプロトコル要素、 IRI が表示に関わる部分なので階層が異なるというのが分かれている根拠のようですが [要出典]、 あまり実態に合っているとは思えませんね。

[18] 正誤表は、通常は差分仕様書とはいいませんが、差分仕様書と同じ問題点をはらんでいます。

[19] W3C勧告には必ず正誤表が用意されており、たまに追記されるようですが (頻度は担当 WG が存続しているかどうかや出版済み仕様書のメンテナンスの真剣度などにより異なります。)、 本文しか見ない人が多いので、修正前の古い記述に基づき理解されたり、実装されたりすることがよくあります。

[20] しかもややこしいことに、公式には正誤表の内容は「修正案」 であり、再度勧告として出版する手続きが行われるまで効力を持たないことに (形式的には) なっています。

[27] 差分仕様書状態が解消されることは、残念ながらそれほど多くありません。 逆に、混乱を解消するためなどと称して新たな説明のための文書が出版され、 そこで新たな解釈が発生して更に混乱を深めるようなこともあります。

[28] 解消された例:

[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 していく形態が一般化しています。 この形態は議論と変更が頻繁に行われる提案の初期段階では関係する規定を一箇所にまとめることができ、 しかも既存仕様との変更点だけをすぐに把握でき、 初期開発が完了した後の関心が薄れ始めてからは既存仕様の開発インフラに統合することで放置して現実と乖離していくリスクも軽減できるというメリットがあります。 不安定な仕様を既存仕様書に早い段階で統合してしまうことで既存仕様書が実態より先に進みすぎてかえって使いにくくなることも防げます。 開発がうまくいかなかったときも既存仕様書はそのままで新仕様書を廃棄するだけですみます。