『Dr.WEB メールデーモン』、MTA 用迷惑メール対策製品です！
LeopardにはRailsやらRubyGemsやらが標準添付されるという話。
OSXはますますRuby(Rails)的開発環境になるなあ。
そろそろMac OS Xを入手して、Rubyの主要開発環境とすべきか。 とはいえ、先立つモノが...。
夕べ、布団に入ってつらつらと考えていると、 (また)GCの新しいアイディアが湧いてきた。 で、その場でメモしておいたのだが、 一晩寝てから考えると、そんなに性能は出ないような気がしてきたなあ。
実際に実装してみないとわからないけど、批判的モードの目で見ると、 ライトバリアのコストと、 リメンバードセットの(空間)コストが馬鹿にならないような気がしてきた。
まあ、時間作ってダメもとで実装してみるかなあ。
XMLのメリット・デメリットについて改めてまとめてある。
問題はメリットの方。ここであげられているのは以下のもの。
XMLとその関連技術をひととおり学んだら、XMLを使用する際のメリットとデメリットを自分なりにあらためて整理しておくことをお勧めする。
データ公開の容易さ
XML はHTMLと同様にWebとの親和性が高く、データをWeb上に公開することが容易である。そして公開されたXMLデータに対しては、URLの入力により簡単にアクセスできる。データを利用する側では、公開されたXMLデータをいつでも取り込み、有効に活用することができる。
データの再利用性
XML をアプリケーションやシステム連携の際の共通フォーマットとして利用すれば、データの再利用性が高まる。例えば企業内の既存システムには、さまざまなデータが蓄積されているが、XMLフォーマットを活用することで、社内ネットワークを通じてイントラネット上でデータを表示することができる。つまり、データの2次利用が容易にできる。
データの拡張性
現在公開されている RSSデータに対して、既存の要素とともに、これまで使用されていない新しい要素を追加することができる。既存のアプリケーションでは既存の要素のみを処理し、新しく作成されるアプリケーションでは、既存の要素とともに新しい要素も処理できる。このようにXMLフォーマットには拡張性がある。
データの長期保存性
XML データはテキストで記述することができ、特定のOSやアプリケーションに依存せず、データを長期保存する際に適している。また前述のようにデータに拡張性があることは今後長期にわたってデータを扱ううえでの運用上のメリットであり、データの長期保存性を向上させる。
さて、このメリットのいずれも「XMLならでは」ではない。 プレーンテキスト、S式、YAMLなどでいけない理由はない。
この記事は一応は「XMLのプロ」による記事なのだと思うのだが、 それで改めてメリットを紹介するのに、この程度のメリットしか出てこない というのはどういうことなんだか。
XMLの「本当のメリット」ってなに？
(追記)
いろいろと反応があって嬉しい。 「XMLの本当のメリット」について、いろいろな意見をいただいた。 せっかくだからまとめておこう。
なお、独断と偏見によってあらかじめ分類している。
非技術的(政治的)なもの
頭から否定するわけではないが、あまり感心はしないものが多い。
XML独自の利点ではないもの
そういう利点はあるかもしれないけど、別にXMLでなくてもいいよね、というもの。
構造のあるデータが書けること(すずきひろのぶさん)
別にS式でもYAMLでも書けますよね。拡張性のあるテキストのマークアップという意味(テキストが主、マークアップが従)ならSGMLの系譜を否定しませんが、データ記述や設定ファイルにまでとなると話は別です。
プログラミング言語に依存しない(maedaさん)
YAMLもJSONも依存しませんね。
タグの意味が標準化されている(maedaさん)
XMLのタグの意味はごく一部(preludeとか)以外は標準化されていないんじゃないでしょうか。標準化されているのはXML文法を利用した規格(SVGとか)ですよね。それでは「野良XML」を説明できません。
誤り訂正に強い？(tamotoさん)
そういう話はありますね。でも、デメリットを上回るメリットかどうかは疑問です。
「XMLは流行ってるから」とかいう理由を否定するつもりはない。 けど、技術者としては(この「Matzにっき」のような場所では)、政治的な思惑を離れて本音ベースで「これこれこういう技術的メリットがあります」というような話がしたい。
その点、「標準化されている」というのは、 実際には「流行ってる」と同じようなことを表現していても、 技術者的に納得しやすい(よく使われているからこそ標準化されるわけで)。 もっとも、「標準化されていないと使えない」という話になれば、 RubyもPHPもPythonも使えないわけで。 Javaもちょっとだけ怪しい(最終的には私企業の仕様だから)。 その点ECMAに提出されたC#は意外にも安心だ。
逆にこれらが使えるという環境であれば、 ある程度安定していれば「標準化されているかどうかは関係ない」とも言えるかもしれない。
namespaceとDOMについて指摘してくださった方もいらっしゃるが、 「野良XML」のほとんどはnamespaceを使ってないような気がするし、 DOMも結局はそのフォーマットに対するアクセスAPIがあるかどうか というだけのような気もする。
言うほどそんなに人は言語やライブラリを渡り歩かないし。
HTMLと似ている、とか。
捺印ナビリティ？
RubyCocoaも搭載されるようですよ。
WWDCのCocoaブースではRubyの事を絶賛してたそうです。
データが構造を持てること。マークアップランゲージの一般的な性質。
あらいさん、zundaさん。
HTMLに似ているのは技術的にはメリットになりませんよね。
今やHTMLを直書きする人はどんどん減ってますし。
「捺印ナビリティ」はありそうな話ですが、これも技術的ではないですし。
結局、「XMLには技術的にはたいしたメリットはない。メリットは政治的なものだ」ということなんでしょうか。それはそれで否定しないんですが、技術的なメリットがあるフリをするのはフェアじゃないと思います。
Ayatoさん。
「Ruby絶賛」ですか。嬉しいなあ。
なんか書いている途中でサブミットしてごめん。で、マークアップランゲージ一般の性質なんだからXMLでもYAMLでもかまわない。XML等のメリットでしょう。S式は面倒なのでかんべんだな。むかしはデータ構造が記述したいがために本当にS式で書いていたりしたから。
「構造のあるデータが書けること」がメリットなのはわかります。
が、それを人間が読み書きすることを第一に考えるのであれば数ある構造化テキストの中でもXMLは繁雑ではないかと。それこそS式以上に。
あまりに読みにくいので結局機械で読み書きする手段を提供しているのが現状ではないかと。
S式等に比べたXMLの利点は「タグの意味が標準化されている」「プログラミング言語に依存しない」とかじゃないでしょうか。つまり、相互運用性。
また、XMLの主な用途は機械による読み書きであって、人が書くことを意図していないと思います。
マークアップランゲージはどれも似たようなものだと思うけど。多くのユーザは既にHTMLなんて手で書かないし。80年代の頃にSGMLが出ていて、まったく同じことをいっていた。歴史の繰り返しを観ているようだ。S式はですね、Lispになれていたらいいんだけど。たとえばcannaなんて初期設定ファイルを読むために内部にlispインタプリタを用意していたんだけど、あの頃はプログラマー側はそんなのが普通の感覚だった。でも普通のユーザには意味不明。ちょっと可哀想だな。XMLもスキーマ定義の仕方で読みやすくもあり、読みにくくもありといえるといえる。理想的なDTD定義をして「簡単だ」ということもできるし、ひどい定義を指して「わけわからん」といえる。そこがある意味、落し穴だと思う。
XMLのメリットは仕様が決まっていることではないでしょうか。
YAMLはいまだworking draftしかないような気がします。
XMLの「本当のメリット」,
QWERTY配列キーボードと似ている、標準と思われていて(マインドシェア)
皆が使うから、そこに集積のメリットが獲得できた。
人が読み書きする場面では、XML互換の簡易構文を提案が絶えません
(行数 水ぶくれは、誰の目にも明らか)
例：XSLTXT - the XSLT compact form
http://www.zanthan.com/ajm/xsltxt/index.html
スキーマの簡易構文もいくつか あります。
とりあえず流行っちゃってること
個人的にはAPI(DOM)が標準化されていて普及しているのが大きなメリットかな。どの環境でもこれさえ知ってればXMLを読み書きするプログラムは書けるので。
誤り訂正に強い？
http://www.cuspy.org/blog/2006/05/30/
takahashim氏と似ているのですが、namespaceの仕様が標準化されているのは大きな利点だと思います。
これにより安心して拡張することができます。
なんでいつもお約束の「ユニコード標準に基づく国際化」が出てこないのでしょうねえ。
# YAMLはUTF-8限定なのがイマイチ。。。
XML禁止。プレーンテキストのみ可。
となったら不便に思うことはないでしょうか。
テキストが送られてきた。この文字は何の属性だろう。
それを送り手受けてで決めておこう。そういう発想は
でてくるはずです。決めようとしてやってみているところに価値があると思います。（メリットといえると思います。）
（YAMLとかと比較した場合のメリットはまた別の観点になりますね。）
スタンダードであるという事
賛同する人が多い事がメリットだと思います。
頭文字が"X"なのが格好いい。
SGMLやXMLは、部屋を整理しようと思って収納家具を買い過ぎて部屋が狭くなっている感じ。
……ちょっとまじめに比較してみましょう。突っ込み歓迎します。
・対プレーンテキスト
○木構造を表現できる
×<>をエスケープする必要がある。
ていうか別物でしょう、これ……。同列に語るのはちょっと……
・対S式
○標準化されている（文字コードやエスケープなどの扱いも含めて）
○『属性』という特殊な要素を扱える
○エラー検証能力が高い（閉じタグに名前が付いているから）
×タイプ量が増える
×パースしづらい
いいとこ取りしたSXMLなんかもありますね。
・対YAML
○インライン要素が扱いやすい
△YAMLはデータ構造の詳細まで規定しているのに対し、
XMLは木構造を作る部分までしか規定していない
＃あくまでメタ言語。
＃そのかわり、XMLは周辺規格も充実しているわけですが。
×読みにくい
『YAMLはXMLに改良を加える』
http://www-06.ibm.com/jp/developerworks/xml/030124/j_x-matters23.html
の序文でも記載されていますが、XMLはより汎用的なメタ言語、
YAMLはデータ構造に特化した言語ということなんでしょうね。
>また、XMLの主な用途は機械による読み書きであって、
>人が書くことを意図していないと思います。
これよく言われますけど、SGMLから派生した言語って皆
機械に読ませるにはやたら文法が冗長でなおかつ
機械が読みにくい文法になってませんか？
極端な話機械に読ませるのが主な用途なら
バイナリデータの仕様を統一すればいい話ですし。
個人的には、現時点では X Schema が標準化されてることがメリットでしょうか。XML で XML のフォーマットが規定できるというのは、体系としての美しさという点で重要かと思います。
ただ、技術的なメリットとは激しく言い難いですね。それだけ XML がオーバースペックであることの証明だと思います。
「野良XML」に関しては、極論すればそれは「XML っぽいもの」だったり、単に『XML を扱えるライブラリ』で扱えるファイル程度の意味しかないでしょう。「野良XML」を比較対象に持ち出して技術の優位性云々を言うのはこの場では『この「Matzにっき」のような場所では』不公平だと思います。
個人的には、現時点では X Schema が標準化されてることがメリットでしょうか。XML で XML のフォーマットが規定できるというのは、体系としての美しさという点で重要かと思います。
ただ、技術的なメリットとは激しく言い難いですね。それだけ XML がオーバースペックであることの証明だと思います。
最小公倍数的な存在なので、あらゆる場面において技術的にはベストな解ではないと思います。
メリットは標準であること以外に無いと思います。
tsekineさんへ
「体系としての美しさ」はあるかもしれません。実際の利用局面では「なにそれ」という感じでしょうけど。
「野良XML」について比較対象にすることはこのような場所では不公平とおっしゃいますが、それはどうしてなんでしょうか。世間一般で「XML」と呼ばれているものの大半は、「XML っぽいもの」だったり、単に『XML を扱えるライブラリ』で扱えるファイル程度のものだったりするような気がするので、それを除外したXML議論は現実から遊離してしまうんじゃないでしょうか。
非技術的(政治的)なメリットで、「フリーである」。はいかが？
GIFとかと比べてみて。
ワンショットで使い捨て、あるいは寿命の短いプログラムのデータフォーマットのように短期的に考えたら、Matzさんのおっしゃるようにどんなデータ形式でも大差ないように思います。
個人的には、XMLのメリットは間口の広さ＋懐の深さの両面があること、といたらいいでしょうか。技術のスケーラビリティといいましょうか。
というのも、XMLはアタマのすごくいい人がスキーマやらボキャブラリやら理論やらと、非常によくできた資産を構築してくれています。でもそれをまったく無視して野良XMLのようなところから始められる間口の広さを持っています。でも野良XMLから始めたとしても、必要になればXSLTなり、XML SchemaやRelaxなり、SOAPなりXML暗号なり、その先にあるアタマのいい人たちが作ったものを野良XMLからはじめて（野良XMLをうまく作れば、ですが）取り込んでいけるという懐の深さがある、というのはどうでしょうか。
ＣＳＶなどシンプルなデータは、間口が広いけど拡張性は少ないし、SGMLやYAMLは間口が狭い感じがしますし。
既に出ている意見ですが、技術的な利点は仕様が詳細に決まっていてあいまいな部分が少ないということでしょうか。例えばCSVでは、コメントを書く方法など、あいまいな部分がたくさんあります。
政治的には、大きな声で「これが標準です」と言っている人がいるから安心という事でしょうか。
冗長さを見ると全く美しくないでしょう。
それから、木構造はSGML系形式でなくても表現できると思います。例えば ls や dir コマンドの結果は木構造を含んでいますが、単純で読みやすいリスト形式で出力されます。あれがXMLで出力されると、うんざりすると思います。
開発者のメリットとしては、パーサーやその他のツールを自分で書かずに、いろんなプラットフォーム用のものをどこかから拾って来れるということでしょうか。「流行っている」というのと同じですが。
なんかまだ上がっていないようなので。
XMLをYAMLやJSONと比較した際のメリットとしてデータ検証が行いやすいというのがあると思います。
XMLはDTDやX Schema、あるいはRelaxNGなどによってスキーマを定義することができます。スキーマを使うことで、あるXMLデータがその目的のXML文書として扱えるかどうかの判断が簡単になります。
以前、他社のシステムと連携をとるアプリケーションを開発した際に、データ通信部のインターフェイスをXMLで行うかJSONで行うかの選択になり、送られてくるデータの検証しやすさからXMLに決定した事がありました。
これは純粋に技術的なメリットかなと思います。
XMLにはコンソーシアムがあるので、対抗してS式コンソーシアム
を作ればいいのではないでしょうか。
すいません嘘です。
田辺さん、
XMLそのものは文法でしかないので「フリーである」ことそのものに意味があるかどうかは疑問です。GIFと比べて、ということは特許を意識していらっしゃるのかもしれませんが、XMLが関連技術も含めて特許フリーであることって保証されていましたっけ。
一方、処理系がフリーというのは確かにメリットでしょうが、それはXMLでなくてもありますよね。
gakuさん、
検証が行いやすいというのは確かにメリットでしょう。他の構造化フォーマットでも検証は可能ですが、検証に特化したライブラリはあまり広まってないようですし。
もっともYAML、JSONは(XML＋データ表現スキーマ)という位置づけなので、XML単体よりも検証の必要性は下がりますね。
あと、あまり検証を重視しちゃうと、元記事で利点とされている「データの拡張性」と対立しちゃいそうです。検証のやり方によるのかな。
jniinoさん、
「間口の広さ＋懐の深さ」というのは、大変耳触りが良いのですが、私自身の経験が足りなくて、具体的にイメージできません。技術的メリットというよりはイメージ先行？
「ＣＳＶなどシンプルなデータは、拡張性は少ない」というのは分かります。
「SGMLやYAMLは間口が狭い」ってのはどういうことなんでしょうね。
「間口」ってなんなんでしょう。
もちろん、(SGMLは知りませんが)YAMLはあくまでもデータ表現フォーマットですから、メタ言語であるXMLよりは適用範囲が狭いのは自明です。が、「技術的に」重要なのは合目的性であって、適用範囲が広ければ良いのかというとそうでもないと思います。
文書型、データ型の両方を扱える。
YAMLでXHTML相当の表現をしようとしたら死ぬｗ
要素、属性といったものが使いやすい粒度で抽象化されているのも扱いやすいです。
初戦はデータの表現形式なので、優れている・いないは無いのではないでしょうか。
XML で表現できるものは S 式や YAML でも表現できると思っています。
XML のメリットは標準としての仕様が決まっていることと、
ツール・ライブラリ群が豊富にそろっていることだと思います。
純技術的に優れているところというのは思い当たりません。
「XML で表現できるものは S 式や YAML でも表現できる」というのはYAMLなどを買いかぶりすぎていると思います。XMLの方が「クラスが広い」ので、YAMLやS式で表現できるものは情報欠落なくXMLで扱うことができますが、逆は必ずしも成立しません。無理すればできないことはないのかもしれませんが、無理は無理でしょう。たとえばmoonwolfさんが指摘された「YAMLでXHTML相当の表現」しようとすることなどはその例です。
問題はカバーできるからといって適用するのが技術的に正しいのか、つまり生産性向上やら効率向上やらにつながるのか、という点です。確かにXMLを使って表現可能だけど、もっと良い別のテクノロジーもあるかもしれない。そういう時にあえてXMLを選択する理由はなにか、ということです。
おおむね「標準だから」というのが共通した答えのようですが、ひとことに「標準だから」といっても背景となる考えはいろいろのような気がします。
* 曖昧性がない
* 標準規格の信頼性
* 標準でないと上司が認めてくれない
* 新たな技術を学ぶ必要がない
で、ですね。「捺印ナビリティ」とか、「学びたくない」とか、技術を選択する理由としては正当なものだとは思いますが、そういうのには正直関心がないんで、そうでない理由について考えたいわけです。
いまんとこ、「検証」とか「信頼性」とかはちょっとだけ説得力を感じました。
「DOM」をあげる人も複数あったんですが、たとえばYAMLに対するSyckがそんなに悪いようには思えないんで、あまり共感できてません。もっと日常的にDOMを使う人なら違う感じ方をするのでしょうか。
moonwolfさん、「文書とデータで同じフォーマットが使える」というのは事実ですが、そのことのうれしさは私にはちょっとピンと来ません。むしろ、文書には文書の、データにはデータにふさわしい扱い方があるのではないんですかね。
属性についてですが、文書(マークアップ_について考えるときには属性は確かに嬉しいですよね。でも、データを扱うときには両方の区別が邪魔になることもあるような気がします。というか、邪魔になった個人的な経験があります。
まあ、これは私が最初にYAMLなどのデータ表現で考えて、それをXMLにマップしようとしているからかもしれませんが。
技術的に優れているわけでもないWeb2.0がチヤホヤされているようなもんで、ベターな方向ベターな方向へと進化して実用化された過渡期の技術って感じかなぁ。難しい。
局所的にベストな解(設定ファイルとしてのYAML)はあるんだろうけど、全体に適用できるものが無い、と。
現時点では無理にXML使う必要なし、ただしXMLへの変換も出来るように作っておくというのがいいのかなぁ。
#XMLが嫌われるのは良いエディタが無い(or 高い)からかもしれない?
XML (XHTML) はマークアップがベースなので、
文章の中にタグを埋め込んでも見た目に違和感がないというのは
あるかもしれませんね。
とはいえ、同時にツリー構造も表現しているので、
同様のデータは YAML でも記述できるのではないでしょうか。
テキストとしての一覧性は低いですが、
XHTML の DOM Tree と等価のものは作れるはずでは。
(仕様やルールを作るのが大変だとは思いますが)
実体のないWeb2.0と実体のあるXMLを一緒にしちゃかわいそうかも。
それはそれとして、私には全体に同一の技術を適用する必然性が見いだせないのですが。毎回、局所的ベストな解を追求すればそれでよいんじゃないんですかねえ。
技術の種類が増えすぎるのが良くないと思うのかもしれないけど、技術屋が新しい技術の登場に文句を言うようじゃ「アガリ」が近い気がしますし。
# そういう意味では、私の「アガリ」も遠くなさそうですが。
katsuwoさん、
XHTML相当のデータをYAMLで表現することはもちろん可能ですし、実際にやっている人もいます(YAMLドキュメントとか)。でも、やっぱり「無理してる」感満載ですねえ。
YAML と比較した XMLのメリット:空白を無視しない、かつ、空白があることが見える。
設定ファイル中に空白をリテラルで持つ必要のあるプログラムを書くことになったのですが YAML では末尾の空白がエディタで見えにくく、 XML を採用したことがあります。
wabikoさん、
YAMLで空白を含む文字列を使いたいときには、クオートでくくれば良いんじゃないですかね。
>そういう時にあえてXMLを選択する理由はなにか、ということです。
他のフォーマットと比べて
・テキストベースのフォーマットとしてXMLが最も有名で、またフォーマットとしての検証が進んでいる
＃最近だとCVSより有名な気がします
・解説書／解説Webページが豊富
・（広く普及している）HTMLと似た体裁をしていて馴染みやすい。
・ライブラリが豊富
・既にXMLに慣れているプログラマが多い
といったところでしょうか。苦労極小化の法則ですね
たとえ彫刻刀の方がより適当な場合でも、簡単にナイフやカッターを使ってしまうことは良くあると思います。
ずっと使ってますが、XML単体で特有のメリットを挙げるのは難しいと思います。
システム間通信の時、プロトコルを考えなくてよかった＆パーズが楽だったことくらいかなぁ…。
じゃぁ、なぜ使うのと問われれば、私はHTMLを生成するプログラムを書く必要に常に迫られているから、としか言えませんね。XMLアプリケーションを使うと、吐き出すHTMLを整形式に保ちやすいんです。それに関して言えば明らかに楽です。もちろん、別のやり方でも同じことができますので、XML特有のメリットとは言い難いですが。
・フリーであることについて
文法に特許を付けることができなければ、ご指摘のとおりです。
もし、文法の利用に費用が掛かるのであれば、これはデメリットとなります。
逆に文法の利用に費用が掛からない場合、これをメリットとするかどうかは
文化に依るのかもしれません。どちらにしても技術的な点での、
XMLならではのメリットではありません。
・環境と標準化について
> 逆にこれらが使えるという環境であれば、ある程度安定していれば
>「標準化されているかどうかは関係ない」とも言えるかもしれない。
環境とそこにいる人が固定であれば、そうかもしれません。
しかし、この業界は、人材が流動的で、人が環境（会社）を渡り歩きます。
技術が流行していれば、企業からすれば人を集めやすいし、
仕様が標準化されていれば、「前の会社と文法が若干異なる」などの余計な
混乱を回避できます。
・その他
「野良XML」の件ですが、表現の問題だと思えました。
もしかしたら、「野良XML」を作成する使用者側に問題があって、それは、
教育および環境を改善すれば解決する問題かもしれまん。
もっと、機能の問題を直接指摘された方が誤解がなかったように思います。
・「用途がない」から意味がない。
・仕様が一般の理解度を超えている。
特段のメリットもないXMLが選ばれた、ではなく、何を選ぼうともそれには特段のメリットはないのでは？
重要なのは合意がなされることだけで、それは何でもよかった。最良の形式は不要で、酷くなくて、まあまあ使える形式ならよかった。worse-is-betterで今がある（XMLがworseとも思いませんが、もしかしたらあったかもしれない完全究極の理想的絶対的な何かと比較して）。
YAML/XML/S-expr/...と選択できる状況でXMLを選ぶ理由はなにか、については、形式は用途に合わせて選ぶので、どれでもOKな用途なら、主観かサイコロでとなってしまう。当時XMLが選ばれた理由はHTMLがあったからだし、今選ぶ理由はXML応用仕様（データ交換仕様やAPI仕様）を自分なり他人が使えるようにしたいから。
もっと突き進んで「なぜHTMLがあったからXMLになったか？」と受け入れられた最初の瞬間を見ると、ただ似ていて楽そうだったからという、提唱者の意図とは関係ない人間臭い所にいってしまうのでは。私も使ってるので非難する気はないですが、例えばYAMLを「簡単だから」という大誤解に基づいて採用しているようなものでしょう。
JSONがRFCになる、といっても、CategoryはInformationalなので、参考情報的な位置付けとなりますが、
http://www.atmarkit.co.jp/fwcr/rensai/ajaxwatch11/01.html#02