Top > Programming > DataFormat > AboutXML
Last-modified: Tue, 04 Dec 2012 12:30:38 JST
Counter:11656 Today:3 Yesterday:9 Online:8
このエントリーをはてなブックマークに追加

データフォーマットとしてXMLを選択する理由

About

 検索エンジンで調べてみればXMLの利点、欠点は多くヒットする。とは言え、どういう場合にデータフォーマットにXMLを採用するべきかを独自に考えてみる。XML以外には、CSVやJSON、独自のフォーマットを決定するという選択肢がある。

結論

  • データの仕様(構造)を考えるのが面倒な場合に、XMLが要求を満たすならXMLで良い。
    • 親子構造、階層構造が重要である場合には、XMLが要求を満たす可能性は十分にある。
    • データ項目数が少ない場合には、わざわざXMLである必要性はない。
    • 後に大幅な変更やデータ項目が追加される可能性がある場合には、XMLが後の要求を満たす可能性は十分にある。
  • 様々なシステムで、汎用的に使い回すデータを作りたい場合にはXMLで良い。
  • データサイズを気にする場合にはXMLでない方が良い。
    • 特にネットワークを経由してデータを転送する必要があるか、ないかに留意する。

利点から見る

お堅いデータ形式

 XMLは名前の通り"マークアップ言語"なので、開始タグと終了タグで明確に区切られる。つまりXMLとして成り立っている限りは、そのデータは最低限の品質が保証される。所謂「お堅い」フォーマットである。W3Cで提唱されるフォーマットであるし、細かいデータ構造仕様を考えなくとも、取りあえず運用に用いるフォーマットとして選択できる。

 まず変更や追加に強いフォーマットであるのは間違いない。任意の位置に新たに値を追加してもXMLとしてのデータ形式が壊れることはない。また親子構造(入れ子:階層)が明確になっているので、そういったデータ構造をとる必要がある場合には充分に利用できる。

 逆に言えば「とりあえずデータを挿入してみました」が原因で、不測の事態を招くこともあるかもしれない。言語使用の柔軟さと、完成するソースコードの曖昧さがトレードオフであるのと同様に、データ形式の自由度と、構成されるデータの曖昧さはトレードオフである。とはいえ先の通り、XMLという枠組みが壊れないことはある程度信用できる。

どのようなデータであるかを明示できる

 一見してデータ構造が分かり易いという点が、XMLの利点として良く取り上げられている。これは任意に付けるタグが、その値が何を意味するかを示すように設計されていることが多い、ことに起因している(ハズ)。例えば身体データを管理する場合などに「<height>175.3</height>」などと記されていれば、値が身長を示していることを直に把握することができるし、データ中に明示的に示すことができる。

 これはCSVでは普通しないことで、CSVの場合はそれを読み取るプログラマや人間側が、その値の順番と対応する意味とを知っている必要がある。例えば「176.8,100.2,1,0,…」と列挙されても、データの順と意味を知っている場合にしか理解できない。

 とは言え、独自フォーマットやJSONでは同じように値の意味を定義することができるので、これだけでXMLを選択する理由になるかと言われると少し弱い。CSVでは確かにできないのだが、明示的なデータ構造である、という点だけ見るのはヨロシクなさそう。

汎用性:使い回しには便利

 XMLは広く普及するフォーマットの一つと言える(ハズ)。XMLを読み取るためのプログラムは様々な言語、ライブラリで実装されているので、データを広く使い回しいたい、つまり汎用的なデータとしたい場合には有利かもしれない。結果としてプログラム上へデータを読み込むまでの作業プロセスが少なくなる可能性は大いにある。

 しかしながら、そのXMLがどのようなデータ構造になっているか、そのフォーマットを知らなければ、読み取るだけで扱いに困るタダの値になってしまう。結局XMLという大枠のフォーマットは共通であるが、その内部のデータ構造は設計者によって任意に定義されるので、その構造を知る必要がある。そういう観点から見てしまうと、JSONやCSV、独自フォーマットと大差がない気もする。

 とはいえ、XML形式だ、と分かっていればプログラム側で読み取るアルゴリズムはおのずと決まってくるので、やはり取り回しの効くデータフォーマットと言えるハズ。仮にあるXMLデータが与えられて、それを読み込むプログラムとアルゴリズムを開発しろ、と言われた場合に、XMLデータの可読性もそれを相まって、他のフォーマットと比較して開発しやすいだろう。

欠点から見る

データの種類・絶対数が少ない場合には不向き

 XMLは任意のタグ付けによってまとまったデータを管理することができる。確かにそれは良いのだけれど、データ数が少ない場合に、果たしてXMLを採用する理由があるかは疑問である。少ない数のデータであれば態々タグ付けして管理する必要もなく、CSV形式や独自の形式でも十分把握することが可能である。一方でデータ量が多い場合になると次の項目「データサイズが大きい」の問題にぶつかる。

 例えば、「SampleData」なるデータセットがあって、そのデータ項目には「A,B,C,D」があるとする。これが一組しか与えられない場合に、態々XMLを使ってタグ付ける意味は殆どない。(別途XMLのエディタを用いてでも)タグを書くのが面倒になるだけなので、CSV/JSONなり独自フォーマットを使うべき。

  • SampleData
    • A:123.08
    • B:30.2
    • C:47.77
    • D:5

 組み合わせの数(SampleData)が将来的に「SampleData1,SampleData2…」と増え続けるならXMLを採用する価値はあるだろう。一方でデータの上限数が10などと少ない数で決まっているのであれば、やはりXMLを採用する意味はあまりない。

データサイズが大きい

 XMLは基本的にタグとパラメータで管理される。例えば「<sampledata>Value</sampledata>」といった具合になる。しかしこの書式、数が増えれば増える程、データサイズが大きくなる。例えば先の「sampledata」なるタグが1000個並ぶとして、「(10文字 + 2文字) + 値α文字 +(10文字 + 3文字) * 1000個 = 25000文字 + α」となる。命名方法を少し間違えれば爆発的な文字量=データサイズになる。

1行あたり25文字の「a」を並べて、改行込みで1000行並べたテキストファイルのサイズは26.3KBになった。

 任意のタグ付けによってデータの種類を分類できる所にメリットがあるのだから、XMLを採用する場合、実際には単一のデータ群ではなく、複数のデータをまとめて管理するのが普通である。データの種類が増えれば増える程、データサイズが比例以上で大きくなるのはXMLの欠点である。ネットワークを通じた転送を必要とする場合には注意が必要になる。一方でローカルでの管理を前提としているなら、記憶領域は大容量化されてきているし(2012初執筆)、SSDなどの普及に伴って転送もそれなりに高速になりつつあるから、この欠点は殆ど気にならないだろう。必要であれば、XMLデータベースの特定の領域のみデータを展開してピックする様な仕組みも作れるのであろうし、ネットワークに乗せるデータなのかどうかだけ留意しておけば良い。