一時期、ある狭い範囲内では「XMLの檜山さん」だったわけですが、ここんところ、XMLにはご無沙汰で、事実上何もしてない。個人的な事情もあるけれど、期待したほどには XML everywhere、everything in XML という状況にはならないし、XML技術が変に矮小化されたり、トンチンカンな使い方をされたり、不毛な議論があったりと、デスパレートな気分にもなりますわな。
じゃ、XMLにまったく興味を失ったかというと、それはないです。不本意に別れた昔の彼女に未練があるくらいの感情は残っています。あわよくば復縁したい、とね。そうは思っていても、行き違いや誤解や不運とかが重なってなかなか復縁できなかった、とそんな感じでしたね。
最近になって、XMLに戻れるかな、もう一度なんらかの形でコミットしようか、と思いはじめました。その事情を話す前に、XML技術がどう使えるか、どう使うべきかを述べておきます。ただし、合意された一般論を述べるわけではなく、僕個人のバイアスが強くかかった議論ですから、その点はご注意ください。
内容：
●普遍的構文プラットフォームとしてのXML
XMLを「データ構造をテキスト形式で表現するための構文」と考えると、代替手段はたくさんあります。JSONやYAML、WindowsのINI形式やJavaのproperties形式でも間に合うことも多いでしょう。LispのS式やErlangのタームだってなかなかの表現力です。みなさんのお好みのプログラミング言語のリテラル表現を考えてみてください； かなりの用途をカバーできるでしょ。
より簡単で、より書きやすく、より親しみやすいリテラル表現があるのに、XMLを使うメリットは何でしょうか？ 個別事例を考えている限りメリットなんてないです。すべてのデータが（控えめに言って多くのデータが）XMLで表現されたときに、大きな効果があると期待できるのです。
「一週間ほど保存しておきたい私だけのデータをどうするか」と、「100年先まで考えて、世界中のデータをどうすべきか」では論点が異なります。個別的ローカルな状況下では、カンマ区切り（CSV）をXMLに変換するなんてバカバカしいだけ。
「100年先まで考えて、世界中のデータをどうすべきか」への解がXMLだったわけですが、実効的な解となるには、データ表現構文のなかで独占的な地位を確立する必要があったのです。しかし現状では one-of-them に過ぎないし、近い将来に独占的な（唯一普遍的な）構文になる可能性も見えません。
●不定／複雑なデータを扱えるのか
JSONやS式ではカバーできない用途もあるんだよ -- 確かにそのとおりです。本来の意味の“文書”のように、不定形で複雑な入れ子や繰り返しを含むデータは従来の（XML以外の）データ形式では扱いにくいものです。
こういう不定／複雑なデータを扱うときこそXMLの本領発揮。のはずですが、不定／複雑なデータはXMLでも扱えません。ここで「扱える」は「表現できる」（テキストにエンコードできる）と同意ではありません。「扱う」は、テキストエディタがプレーンテキストを扱い、ワープロがその固有文書データを扱うように「扱う」ってことです。XMLネイティブな編集系は、実装も普及も困難だという現実がそこにあります。
既存のワープロだって、XML形式で保存できるよ -- あれはですね、単なるアンロード形式としてXMLを使っているだけです。あるいは交換形式（interchange format）としての利用です。
交換形式こそXMLの本命的な用途だと思う人も多いようですが、僕は最初からそのての意見には与してないし、XML技術の矮小化だと思っています。あまりのセコサ、ツマラナサに頭が痛くなります。
●文字エンコーディングの問題
XML規格は、最初からUnicodeをちゃんと考慮し／ちゃんと使った事例です。僕は、「プログラミング言語のリテラル表現などに比べて、この点は大きなアドバンテージだ」と思っていました。いや、今でもencoding宣言は素晴らしいと思います。
しかし、ファイルの先頭のほうで -*- coding: utf-8 -*- とか書くとうまくいくエディタやプログラミング言語もあります。つまり、encoding宣言のアイディアは、ローカル構文／野良構文でもパクることができるし、うまく機能するのです。これは良いことなのか悪いことなのか？
よく出来たXMLプロセッサは、そこいらのローカル・パーザー／野良パーザーに比べて、ずっとたくさんのエンコーディングをサポートしています。ですが、「UTF-8だけサポートすればいいじゃね」という傾向も確かにあるわけで、「文字エンコーディングで悩まなくて済むからXMLがいいぞ」ってのも、なんか説得力が落ちたようです。
●XMLはタグなのか
僕は、普遍的構文プラットフォームとしてのXMLに期待してましたが、どうやらその目はないようです。しかし、XMLは構文を規定するだけのものではありません -- そう聞いて意外に思う人もいるかもしれませんが、現実に何かをするときに、構文が決まればOKなんてことがあるわきゃないですよ。
XHTMLでもSVGでもMathMLでも、そりゃ確かに構文が規定されています。しかしその構文の背後には、応用固有の領域があり、データ構造があり、ソフトウェア・アーキテクチャがあるのです。XML応用ボキャブラリを策定するとき、構文を決めるよりずっとずっと多くの時間と労力が、領域の定義、データ構造とそのセマンティクスの明確化、アーキテクチャの提示に使われます。構文の議論が紛糾してときに時間を食うのは、恣意的・趣味的要素があるからですよ。
だから、タグなんてなくてもいいのかも知れません。むしろ、構文なんて気にしないほうが幸せな応用もあるでしょう。アンロードや交換（interchange）が必要なら、S式でもCSVでもRubyのリテラルでも、お好きにどうぞ、ってな具合。
XMLの規格／仕様が総体として膨大になってしまったのも、いろいろな分野のセマンティクスとアーキテクチャを、構文を通じて記述し規定しようとしたからです。構文を除いてしまっても、セマンティクス／アーキテクチャは残るのです。なかには出来の悪い仕様もありますが、十分に使える／参照できる仕様もあります。
現時点において、過去に蓄積されたXML技術を再評価したいなら、構文なんて忘れちまう、無視してしまうってのも「一つの視座」を提供すると思います。実際僕は、構文の議論にはもはや食指が動かないし、必要性も感じていません。でもあいかわらず、データ構造論とソフトウェア・アーキテクチャには魅力を感じています。
●それはどこ？
では、過去に蓄積されたXML技術のどのあたりが面白くて、再評価・再発見するにあたいするのか？ いやっ、そんな客観的な話ではなくて、過去に蓄積されたXML技術のどのあたりを檜山が面白いと感じ、再評価・再発見してみたいと望んでいるのか？
それは、また次ね。
