ダブルスタンダードになりかけることは標準化団体では珍しくない

JSRにおけるDI標準化戦争のように一時的に
ダブルスタンダードになりかけるケースは
JCPのような標準化団体では珍しくはなく
普通に起こりえる事態で、それが起こった
ことでその団体の存在価値に疑問を呈する
ような問題ではありません。

ダブルスタンダードのような状態に
なるケースは現に他の標準化団体でも
起こっています。

W3CでXHTML2が議論されていたにも
関わらず、WHAT WGがHTML5を提案
したのもダブルスタンダードになりかけ
ました。
結局、遅々として仕様策定が進まない
XHTML2ではなく(X)HTML5をW3Cが推進
する方向で決着しました。

ECMAではAdobeが主導してECMA Script4仕様が
策定されていましたが、MS等がECMA Script3の
改訂版を提案し、ダブルスタンダードになりかけました。
結局、MS等の提案する案を叩き台にECMA Script4から
その機能の一部をマージする形でECMA Script5を
策定する方向で決着しました。

一時的にダブルスタンダードのような状態になったW3Cや
ECMAは標準化団体としておかしな状態にあるのでしょうか？

一時的にダブルスタンダードのような状態になることで
そのような状態を作り出した標準化団体は
おかしい状態にあると判断するのはそもそも
間違いです。

標準化団体による仕様策定が遅々として進まないのは
標準化団体の抱える宿命としかいいようがありません。

最近は全ての仕様が確定する前に仕様策定と並行して実装を
先行して行い標準仕様化を後付で行う方向にあります、
標準化団体での標準仕様化は概ねそのように推移しています。

JCPのように特定の企業が標準化団体の運営を主導している例
は稀ですが、それなりにメリットはあります、
企業主導によるデメリットもありますが。

特定の企業がその運営を主導していることでJCPは他の標準化団体
に較べて迅速に仕様の策定・改訂が行われています。

ISOが標準化を行っているC/C++等の仕様改訂の
ペースと比較すれば、JCPが標準化団体としては
仕様の策定・改訂をかなり迅速に行っていることが
わかると思います。

ISO等の標準化団体ではリーダーに対して大きな権限が
付与されていないので、どうしても異なる意見の調整役と
なってしまい議論の収束に時間が掛かるため、仕様の策定
にそのぶん時間が掛かってしまいます。

Java7へのプロパティ構文やプロシージャ構文等の導入が
見送られようとしているのは、十分な議論がなされていない
状態でJCPを主導する企業(Sun)が議論の叩き台として自ら
提示した草案をそのまま、ごり押しで標準仕様としてしまう
ことは避けるべきだと判断したためだと思います。

JCPを主導する企業(Sun)のこの判断は正しいと
思います、標準化団体を主導する企業・人物は
その権限で自分(たち)の案を議論し尽くさない
うちに標準仕様としてねじ込むべきでは
ありません。

必要性があるからという理由だけで十分な議論が
なされていない状態で叩き台であるはずの草案
レベルの仕様をそのまま標準仕様にしてしまって
失敗した例もあります。
その最たる例はW3C XML Schemaです、
欠陥だらけの仕様をW3Cの議長がその権限で
無理矢理、勧告してしまいました。
W3C XML Schemaはその欠陥を指摘されながら
誰もその欠陥を修正できない状態になっています。

十分な議論がなされていない状態で叩き台レベルの
草案を標準仕様としてしまうことは例えその仕様に
必要性があったとしても避けるべきです。

推敲中。

[蛇足]
ISOに提出される予定のRuby仕様は仕様全体の実装が
先行していて後付で標準仕様として認定されようと
している例になります。