従来からJavaの開発現場はXMLで溢れかえっていましたが、Webサービスの登場、普及とともに、XMLへの注目が一段と増します。
XMLがなければ開発できない状況に追い込まれますが、そんなにコレって必要なんでしょうか。

配置記述子に始まり、コンテナの設定ファイル、Strutsコンフィグ、Log4J、DIコンテナ...ほぼ全ての設定ファイル。なんでローカルマシンで、同じ言語で動いているものに、XMLを使う必要があるのか。Propertiesの何がいけなかったの？・・・と、疑問が満載。

確かにXMLは、ビジュアル的にわかりやすい（HTMLが普及した理由と同じ）という利点はあります。たとえばSpring Frameworkのapplication.xmlは、システム設計書そのものです（もちろん、うまく作れば、ですが）。そして、オーサリングツールとの親和性が高い。StrutsコンフィグだとScioworks Caminoなどの優れた描画ツールがありましたが、DIコンテナではまだこれからといったところでしょうか。

XMLは、複雑なデータ構造も扱える。ネストも繰り返しも思いのまま。

XMLでIF文を書く。それこそ地獄。

XSLTに始まり、2003年頃に現れたBPELなど。コンパイラも実行環境もない言語でプログラミングして、ぶっつけ本番で、どこぞの馬の骨とも知れぬマシンで動かす、そんな感じ。しかも、そのプログラムにインポートする定義（ネームスペースね）も、馬の骨。いったいいつ誰が保障してくれるのか・・・。そんなこんなで、HelloWorld程度のBPELを作ろうと思っても、１週間かかります。

BPELの目論見は、ビジネスプロセスの再利用・流通だろうと思います。「一度作ったプロセスは、どこでも動く」と、そういうことでしょう。しかし、Javaプラットフォーム同士ですら実現できなかったことが、異機種間で実現できるのでしょうか。

おフザケはこのくらいにして、本来のXMLの使い方、異機種間接続のためのXML。

Webサービス（WSDL、SOAP）や、RosettaNet、ebXMLなどのBtoB標準は、多少複雑でも、XMLの使い方としては正しいと思うので、多少モチベーションは上がります。こういう技術を採用するプロジェクトは企業間接続が目的ですから、そもそも規模が大きいですし（お金になるし）。
がんばってXMLしていこう！と思えるのです。

でも、XMLの最大の問題は、技術うんぬんの話ではありませんでした。

XMLは、常に、多くの企業が議論するステージになっています。ITを先導するトップ企業が、企業間取引のルールや、技術的な接続のルールなどを議論して、世界標準のXML定義を作ります。

これがまた問題です。下の方（末端の開発者）から見ると、ヤキモキすることばかり。たとえるなら、日本メーカーがDVDの標準規格を争ったことに消費者がヤキモキした、アレと同じようなことが１０倍くらいのスピードで進行するのです。

新しい仕様が登場しては、似た仕様が出てきて、２つの仕様を互換させる仕様もあらわれ、しまいには全て頓挫する。仕様が確定するころには、「それでは機能が足りない！」なんつって、バージョンアップの議論や、独自拡張が始まる。

ITに関わる人なら誰でも、「開発途中のテーブルスキーマ変更は、大きなリスクである」ことを知ってます。それなのに、業界トップが、それをやってるんですからね。もうついていけません。

せめて仕様を決めたら、パーサーくらい自分らで作ってくれっつーのっ。


XMLのことを振り返るとアドレナリンがおさまりません。
全てのXMLを隠蔽するツールを作ってくれたら、許す。