ユーザ・サーバ数が無制限のライセンスも低価格でご利用いただけます。
金曜日の午後から火曜日の午後までまる4日間ネットにアクセスしなかったことになるのだが、 帰宅してからメールを取り込むと、7400通以上のメールがたまっていた。
スパムフィルタを使ってフィルタリングしてもまだ1200通以上の「読むべきメール」が残っている。途方に暮れそうだ。
とりあえず仕事関係の急ぐものだけ、ピックアップする。 それでもかなりの量だ。げんなり。
吹き出しそうになった。恐るべし、Ruby City MATSUE。
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があるかどうか というだけのような気もする。
言うほどそんなに人は言語やライブラリを渡り歩かないし。
_ MoonWolf [文書型、データ型の両方を扱える。 YAMLでXHTML相当の表現をしようとしたら死ぬｗ 要素、属性といったものが..]
_ katsuwo [初戦はデータの表現形式なので、優れている・いないは無いのではないでしょうか。 XML で表現できるものは S 式や..]
_ まつもと [「XML で表現できるものは S 式や YAML でも表現できる」というのはYAMLなどを買いかぶりすぎていると思い..]
_ まつもと [moonwolfさん、「文書とデータで同じフォーマットが使える」というのは事実ですが、そのことのうれしさは私にはちょ..]
_ MoonWolf [技術的に優れているわけでもないWeb2.0がチヤホヤされているようなもんで、ベターな方向ベターな方向へと進化して実用..]
_ katsuwo [XML (XHTML) はマークアップがベースなので、 文章の中にタグを埋め込んでも見た目に違和感がないというのは..]
_ まつもと [実体のないWeb2.0と実体のあるXMLを一緒にしちゃかわいそうかも。 それはそれとして、私には全体に同一の技術を..]
_ まつもと [katsuwoさん、 XHTML相当のデータをYAMLで表現することはもちろん可能ですし、実際にやっている人もいま..]
_ wabiko [YAML と比較した XMLのメリット:空白を無視しない、かつ、空白があることが見える。 設定ファイル中に空白をリ..]
_ まつもと [wabikoさん、 YAMLで空白を含む文字列を使いたいときには、クオートでくくれば良いんじゃないですかね。 ]
_ memolog:XML とか YAML とか メタ言語から作られた言語を車輪の再発明することなしに使えるこ..
山口にいるあいだはネットアクセスがなく、メールの読み書きができないので、 この機会にmorq(のデータベースを)メンテする。 全文検索エンジンをHyperEstraierにしたのだが、 その時にほかのデータベースを壊してしまったのだ。
また、バグもいくつか見つけてしまった。 いままで「なんか変だな」と思っても放置してたんだけど、 ちゃんと調べたらやっぱりバグだった。
しかし、H.E.に満足というワケではない。
良い点
悪い点
予定されている(はずの)Rastの性能改善が実現されたら、 またRastに戻るかも。 H.E.に負けない登録速度とDBサイズはかなり難しいチャレンジではあるのだが。