オルタナティブ・ブログ > ビジネスをデザインするブログ >

事業開発ほどクリエイティブな行為は他に無いと思いこんでいる人間の日常

今更聞けないXML?

»

Webで「XMLとは?」的に検索すると・・・

メタ言語である。

マークアップ言語である。

拡張性がある。

柔軟性がある。

プラットフォームに依存しない。

情報に意味づけができる。

といった解説が目につきますが、読み進めてみると、「???」と感じることが多い気がするのは私だけでしょうか。

特に、機能面である、なぜ、XMLには拡張性(柔軟性)があるのか?、プラットフォームに依存しないのか?、情報に意味づけができるのか?について、「なるほど!」と解説されているものは少ない気がしますし、XMLのメリットは明確に説明できない人って意外と多い気もします。

今日は、私なりの「だからXMLは便利だ」とう点を書いてみたいと思います。
XMLに詳しい人は読み流してください。

よくあるのが、CSVなどとの比較で、

「CSVはデータの羅列であるが、XMLはタグで囲むことで意味づけが行われている」

的な説明があります。が、なぜタグで囲むだけで意味づけができるのか、少なくとも私にはよくわかりません。確かにXMLにおいては、

<name>yamada taro</name>

と記述するこにより、タグの間におかれたデータが、どうやら何かの名前であるらしいことはわかりますが、人の名前であるのか、犬の名前であるのか、商品の名前であるのかは、結局わかりません。「<name></name>というのは人の名前です」と事前に決めておかなければならないのであれば、

0001,yamada taro

というCSVと同様、「カンマで区切った2つめのデータは人の名前です」と決めなければならないのとなんら変わらないではないでしょうか。

このあたりから、しどろもどろになる人が多い気がします。

実際、私は「XMLはデータに意味づけができる」という解説には懐疑的です。拡張性があるというのも、この流れから行けば疑問が残ります。

よくあるのは、

XMLであれば、拡張が必要になったとき(例えばアドレス情報)、

<hito>
     <name></name>
     <address></address>
</hito>

とタグを追加すればよいだけなのです!!!。

的な解説がありますが、結局、<address></address>が住所情報であるという定義づけを事前に行わなければならないのであれば、

001,yamada taro,tokyo

というCSVにおいて、カンマで区切った3つ目のところはアドレス情報です。と定義するのと、表面上の拡張性や柔軟性は変わらないのでは?ということにならないでしょうか。

XMLの拡張性や柔軟性は、XMLそのものではなく、実装に依存していることを忘れてはなりません。例えば、

<hito>
     <name>yamada taro</name>
</hito>

というXMLから、名前データを取り出すために「2行目の、>と<の間のデータを取り出す」という風に正規表現などを利用して実装してしまうと、

<hito>
     <address>tokyo</address>
     <name>yamada taro</name>
</hito>

という風にエレメントを追加した場合、CSVで起こるデータずれと同じようにデータずれが発生してしまいます。XMLの拡張性を利用しようと思うのであれば、当たり前ですが、XMLのポテンシャルを利用することを前提とした実装方法を用いなければなりません。

つまり、XMLパーサー(などが使用しているルールに従ってデータ)を利用しなければXMLの意味は全くありません。まあ、言語にも依存すると思いますが、「XMLの中から、<name></name>で囲まれたデータを取り出す」という感じでデータが利用できれば、XMLが、

<hito><address>tokyo</address><name>yamada taro</name>

と記述されようが、

<hito>
     <address>tokyo</address>
     <name>yamada taro</name>
</hito>

と記述されようが、関係なくデータを取り出すことができ、少なくともCSVよりは柔軟性があるといっても怒られないものとなります。

解説書のほとんどは、XMLのフォーマットの記述方法ばかりを紹介し、活用時(から逆算したフォーマットのメリット)に言及しているものがほとんど無いため、ピントのぼけた話になっている気がします。XMLは1つのデータ構造に過ぎません。が、あるデータ構造が有益かどうかは、それを利用するアルゴリズム(活用(実装)方法論)とセットで評価されなければ意味がありません。

そういう観点からすれば、CSV以上の拡張性や柔軟性を維持することだけを目的とするならば、XMLより、便利なデータ構造は他にもあると思います。

だらだれと書いてきましたが、数あるデータ構造の中からXMLが選ばれた(便利な)理由は、下記の2つであると私は解釈しています。

オブジェクトを記述(シリアライズ)するデータ構造として適しているから。
記述媒体?がテキスト形式であるから。

以前書いた「脱オブジェクト指向のススメ」では、すっかりオブジェクト指向否定派にされてしまいましたが(苦笑)、今の時代、明示的、暗示的に利用するかは別にして、オブジェクト指向のお世話にならずに過ごすことはできません。が、オブジェクトというものはあくまでも概念であったり、メモリに展開されたデータに過ぎませんので、目に見える形で保存しなければならない場合は多々ります。そして、どのような方法で記述するかは頭の痛い問題です。この際、最も矛盾の無い美しい方法の1つがXMLということなんでしょう。

Class A {
     Method A(){ variable X}
     Medhod B()
     Property C
}

というクラス(オブジェクト)は、

<Class name="A">
     <Method name="A"><variable>X</variable></Method>
     <Method name="B"></Method>
     <Property name="C"/>
</Class>

などと、うまく記述することができます(記述はテキトーですよ)。オブジェクトの状態をCSVで記述できないことも無いですが、どのようなルールを用いるのがよいのか思いつきませんよねえ。つまり、XMLはオブジェクトのような階層構造と属性をもった”何か”を保存するのに適したデータ構造であり、オブジェクト指向花盛りの状況下において、最も適したフォーマットということなのです(たぶん)。

よくUMLやWSDLから自動的にクラスソースコードが生成されたり、クラスをUMLとして保存できることに驚く人がいますが、それはむしろ当たり前のことなんです。

最後に、何といってもXMLはテキスト形式であることがとても重要です。よく、XMLがプラットフォームに依存しない理由をタグ形式だから・・・とさらっと言う(書く)人がいますが、XMLがプラットフォームに依存しないのは、単純にXMLがテキスト形式だからに他なりません。まあ、今、普通に稼動しているシステムにおいて、テキストファイルをオープンできないシステムはまずないでしょうから。

なんか、だらだらした内容になりましたが、お許しを。

Comment(0)