[2] [DFN[[RUBYB[差分仕様書]@en[delta specification]]]]とは、他の[[仕様書]]に対する差分の形で記述された[[仕様書]]のことをいいます。 [3] 一般に[[差分仕様書]]は理解が難しく、結合部分で不具合を生じやすいことなどから、好ましくないと考えられています。 特に差分仕様書によって元の仕様が改訂される場合、元の仕様書だけを見ても改訂されたことに気づけない危険性があります。 ;; [9] 特に元の仕様書の規定に割り込む形で新しい規定を注入するものを[[猿パッチ]]といいます。 [4] [[W3C]] の出版規則は原則として[[差分仕様書]]を避けるようにと述べています。 [REFS[ - [1] [CITE@en-US[About W3C Publication Rules]] ( ([TIME[2012-08-06 21:42:10 +09:00]] 版)) ]REFS] [10] ただ[[差分仕様書]]が避けるべきものであるとの認識は必ずしも一般的ではありません。 [7] [[W3C]] の [[HTML WG]] は設立当初 (>>5) は[[差分仕様書]]でなく完全な仕様書を作ると[[憲章]]に明記していましたが、 [[WHATWG]] と決別した後の[[憲章]] (>>6) では逆に拡張という形で[[差分仕様書]]をむしろ積極的に採用しています。 実際には[[憲章]]改訂の数年前から[[差分仕様書]]を量産していました。 [REFS[ - [5] [CITE@en-US[HTML Working Group]] ([TIME[2011-02-14 13:58:22 +09:00]] 版) - [6] [CITE@en[HTML Working Group Charter]] ([TIME[2013-09-30 19:26:59 +09:00]] 版) ]REFS] [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] [[差分仕様書]]が好まれる背景には、既に“確定”している既存の仕様書に手を入れたくないという事情があるようです。 確かに変更することにより仕様に不具合を混入させてしまう可能性はありますし、 [[標準化団体]]の手続きによってはそのような変更で手続き上の仕様の状態が後退してしまうこともよくあります。 [EG[ [23] 例えば [[IETF]] の[[標準化過程RFC]]は技術的に変更が加えられると[[提案標準]]からやり直しになります。 ]EG] [EG[ [22] 例えば [[W3C]] の[[標準トラック]]の仕様書は技術的に有意な変更があると [[LC]] からやり直しになります。 ]EG] ;; [24] 逆に差分化することで統合部分の規定が不十分であるなどの不具合が生じたり、 差分出版後の元の仕様の更新で不整合が生じたりするリスクはありますが (リスクだけでなく実際そうなった例は枚挙に暇がないのですが)、 それらは発覚に時間がかかりますから、差分化する時には気づかないのでしょう。。。 ;; [25] このような事情は[[モジュール化]]が好まれる理由とも同じでしょう。 [14] なお[[差分仕様書]]は同一の対象や密接に関わる同一階層の概念に関する場合によっては競合しかねない規定を別の仕様書に含めたものを指すので、 階層化、モジュール化された機能単位同士の仕様書は普通は[[差分仕様書]]とはいいません。 [EG[ [16] 例えば [[TCP]] と [[IP]] は通常は組み合わせて使い、相互作用に関する規定も含まれてはいますが、異なる層の独立したプロトコルなので、 どちらがどちらの差分でもありません。[[電子メール]] ([[RFC 822]]) に対する [[MIME]] も、実際には深く関係するとは言え一応は独立した形をとっているので、 [[MIME]] は差分仕様書ではありません。 [17] また [[XML]] と [[XML Schema]] や、 [[XML]] と [[XLink]] は、一方が他方に依存してはいますが、 他方の仕様書の内容に変更を加えていませんから、互いに独立した仕様書であって、[[差分仕様書]]ではありません。 ]EG] ;; [15] >>14 の観点で >>12 は [[URI]] がプロトコル要素、 [[IRI]] が表示に関わる部分なので階層が異なるというのが分かれている根拠のようですが [要出典]、 あまり実態に合っているとは思えませんね。 [18] [[正誤表]]は、通常は[[差分仕様書]]とはいいませんが、[[差分仕様書]]と同じ問題点をはらんでいます。 [EG[ [19] [[W3C勧告]]には必ず[[正誤表]]が用意されており、たまに追記されるようですが (頻度は担当 [[WG]] が存続しているかどうかや出版済み仕様書のメンテナンスの真剣度などにより異なります。)、 本文しか見ない人が多いので、修正前の古い記述に基づき理解されたり、実装されたりすることがよくあります。 ;; [20] しかもややこしいことに、公式には[[正誤表]]の内容は「修正案」 であり、再度[[勧告]]として出版する手続きが行われるまで効力を持たないことに (形式的には) なっています。 ]EG] [27] [[差分仕様書]]状態が解消されることは、残念ながらそれほど多くありません。 逆に、混乱を解消するためなどと称して新たな説明のための文書が出版され、 そこで新たな解釈が発生して更に混乱を深めるようなこともあります。 [28] 解消された例: [FIG(list)[ - [32] [[HTML3]] の各モジュールは、統合されて [[HTML4]] となりました。 - [30] [[Web Applications 1.0]] は [[HTML4]] と [[XHTML1]] と [[DOM2 HTML]] に対する差分でしたが、 [[HTML4]] や [[XHTML1]] や [[DOM2 HTML]] に相当する部分の規定が追加されて完全な仕様 ([[HTML5]]) となりました。 - [29] [[Web Forms 2.0]] は [[HTML4]] と [[XHTML1]] と [[DOM2 HTML]] に対する差分でしたが、 [[HTML5]] に統合されました。 - [33] [[HTML Templates]] は [[HTML Standard]] に統合されました。 - [31] [[URI]] と [[IRI]] の分断状態は [[URL Standard]] により解消されました。 - [34] [CODE(HTMLe)@en[[[picture]]]] [[要素]]は [[HTML Standard]] に統合されました。 ]FIG] [26] [CITE@en[''''''[''''''lots'''''']'''''' -webkit prefixed properties and values]] ([[Tab Atkins Jr.]] 著, [TIME[2015-12-10 06:19:27 +09:00]] 版) [35] [CITE@en[Make a new/updated base IRC RFC · Issue #132 · ircv3/ircv3-specifications]] ( ([TIME[2016-12-13 23:04:13 +09:00]])) [36] 近年の[[Web標準]]開発の現場では、まとまった新機能を追加するとき、 いったん既存仕様に対する[[差分仕様書]] (+ 完全新機能) の形で仕様をまとめ、ある程度の完成を見た段階で差分を既存仕様書に [[upstream]] していく形態が一般化しています。 この形態は議論と変更が頻繁に行われる提案の初期段階では関係する規定を一箇所にまとめることができ、 しかも既存仕様との変更点だけをすぐに把握でき、 初期開発が完了した後の関心が薄れ始めてからは既存仕様の開発インフラに統合することで放置して現実と乖離していくリスクも軽減できるというメリットがあります。 不安定な仕様を既存仕様書に早い段階で統合してしまうことで既存仕様書が実態より先に進みすぎてかえって使いにくくなることも防げます。 開発がうまくいかなかったときも既存仕様書はそのままで新仕様書を廃棄するだけですみます。