[1] 仕様の巨大化はしばしばモジュール化につながりますが、往々にしてモジュール化は死亡フラグだったりします。
その要因としては、
[21] モジュール化で規格制定作業が迅速になるというのはだいたい嘘で、 分離した他の仕様と結局依存関係が残ってしまったり、足並みを揃えようとする力が働いたり、 色々な理由で結局たいしてはやくなりません。
[22] バリエーションとしてモジュール化して “重要な一部のモジュールだけ先に完成させて残りは順次進めていく” というケースもよくあり、その場合大抵は重要な一部のモジュール以外は関心が低いなどの理由で切り捨てられる結果となります。
[23] 仕様同士の疎結合化もしばしばモジュール化が良いとする根拠に挙げられますが、 実際は密結合にしたくて密結合にしていることなどなく (元の仕様を書いた人も馬鹿じゃないので、 意味もなく何でも1つに詰め込んだりしない)、接合部分の仕様が必要以上に複雑になったり、 どちらのモジュールからも明確に規定されなくて相互運用性上の問題を引き起こしたりすることがよくあります。
[24] モジュール化すればモジュールそれぞれで必要なところだけ改訂していける、 というのも大体は嘘で、どれかを改訂したい時には他のも改訂が必要になるか、 あるいは本来改訂が必要なのに改定せずに仕様が不安定な状態のまま放置されるか、 はたまたある仕様に別の仕様の改訂の差分が含まれているようなモジュール化の意味のない状態になるか、 いずれにせよ当初の目的はあまり達せられません。
[27] モジュール化により同じような定義や規定が複数の仕様に併存し、 それぞれの細かな差異をどう処理するべきかが問題になったり、 他の仕様から参照するにあたって何をどう参照するべきか不明確で困ったりすることもしばしばあります。
[32] モジュール化の結果崩壊したプロジェクトの例
[33] 崩壊まで至らないものの明らかに失敗している例
[31] モジュール化とは関係なしに失敗したもの
[26] IETF の仕様は全面改訂していく方式の他に、 TCP や DNS や telnet のように差分をオプションとして出版していく方式があります。 これは仕様のモジュール化というよりはデルタ仕様書に分類するべきでしょうが、 やはりモジュール化のような問題を引き起こします。
クラーク氏は、XML 1.0の仕様策定にかかわったメンバーの1人。XMLがこれほど成功した要因を、仕様がモジュール化されていたためだと分析する。「XMLの仕様を策定しているとき、想定されていた分野は電子出版だった。しかし、いまでは電子出版はXMLの用途のごく一部にすぎない。もともと電子出版用に開発されたXMLが成功したのは、シンタックス(文法)とセマンティックス(意味)を分割したからだ」(クラーク氏)。
つまり、XML 1.0の仕様で決められているのはXMLを記述する方法(つまり文法)だけであり、その文書がどのような意味を持つのかは、そのXML文書を処理するアプリケーションの責任になっている。このように、仕様がカバーする範囲を明確にし、それぞれの仕様をシンプルにした結果が、XMLの成功要因だとした。
[36] モジュール化っていってるけど Clark 発言はデータ形式と応用仕様の分離の話しかしていない。 そしてその分離は SGML 時代からずっと一貫した前提なんだよなー。
[37] XML 本体と XLink と XPointer と XPath と XSLT と XSL-FO がばらばらになって、 XML と XPath と XSLT だけ成功した、 モジュール化のおかげで失敗した部分が足を引っ張らずに済んだ、という話なら納得感ある。