ユーザ・サーバ数が無制限のライセンスも低価格でご利用いただけます。
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 がオーバースペックであることの証明だと思います。