clock2015.02.13 13:10
SERVICE
home

第5回・XMLファイル|CSV、XML、JSON…データフォーマットの変遷について考える

AUTHOR :  岩谷 和男

beaconフォーマット解説の第三弾はXMLフォーマットです

前回(第4回)は、各フォーマットを説明していく第二弾としてみなさんもよくご存知のCSVフォーマットについて説明しました。今回は第三弾としてXMLフォーマットについて説明します。XMLはインターネット上の各種技術の標準化を推進する団体であるW3C(World Wide Web Consortium)によって仕様の策定および勧告がなされています。第一版の勧告が行われたのが1998年なのでXMLが誕生してから17年ほどになります。Windows95が発売された時にはまだ勧告前だった事を考えると意外と若いフォーマットですね。今日のインターネットを支えるデータフォーマットの中で、XMLは最も重要な役割を担っているテキストフォーマットの一つです。多くののプロダクトは設定ファイルや通信データフォーマットなどなんらかの形でXMLを利用しています。それはXMLの持つ「表現の自由度やデータ再利用性の高さ」に起因するのですが、そんなXMLの特徴を見ていきましょう。

これまでの記事と同様に、本連載で取り上げているフォーマットの一覧を再掲します。

  1. フラットフォーマット(固定長フォーマット)
  2. Character-Separated Valuesフォーマット(CSV,TSV,SSVなど)
  3. XMLフォーマット ←今回
  4. JSONフォーマット

また、これまで例題としてきたサンプルデータも再掲します。

順位 氏名 本数
1 王貞治 868
2 野村克也 657
3 門田博光 567
4 山本浩二 536
5 清原和博 525

※出展:日本プロ野球機構オフィシャルサイト・歴代最高記録 本塁打 【通算記録】より

XMLファイルはデータが囲われている

連載第1回でも申し上げましたが、上記サンプルデータをXMLフォーマットで表すと以下のようになります。

<?xml version=”1.0″ encoding=”utf-8″?>
<data name=”歴代ホームラン数の順位”>
 <record>
<順位>1</順位> <氏名>王貞治</氏名> <本数>868</本数>
 </record>
 <record>
<順位>2</順位> <氏名>野村克也</氏名> <本数>657</本数>
 </record>
 <record>
<順位>3</順位> <氏名>門田博光</氏名> <本数>567</本数>
 </record>
 <record>
<順位>4</順位> <氏名>山本浩二</氏名> <本数>536</本数>
 </record>
 <record>
<順位>5</順位> <氏名>清原和博</氏名> <本数>525</本数>
 </record>
</data>

 

「固定長フォーマットはデータがフラットに記述されている」「CSVフォーマットはデータがデリミタで区切られる」事に対して、XMLは「データがタグで囲まれる」ことによって分割されています。またタグの中に子供のタグを記述することもできます。これによって全体が木構造(ツリー構造)であらわされます。

  1. タグの事をXMLでは「要素(element)」といい、タグで囲まれた中身を「内容(content)」といいます。上記の王貞治さんの部分を例にとると、要素名(タグ名)=氏名で、内容=王貞治となります。各タグの名前は自由に決めることができます。
  2. さきほどXMLは木構造(ツリー構造)になっている事を申し上げましたが、「タグの中に子供のタグを記述する」という事は「要素内の内容として子要素を格納する」という事と同義になります。上記三行目の <record>タグ(要素)を例とすると、record要素内の内容は「順位という子要素」「氏名という子要素」「本数という子要素」となっています。
  3. このようにXMLの要素内の内容には一般的に、「”王貞治”のような文字列値」または「子要素」が格納されることになります。
  4. また、上記2行目のデータに着目してください。「<data name=”歴代ホームラン数の順位”>」と記述されていますが、”歴代ホームラン数の順位”の部分はタグ自身の中に記述されています。このような記述データを「属性(attribute)」といいます。この場合、属性名がnameで属性値が”歴代ホームラン数の順位”という事になります。

上記a、b、c、dをまとめると、XMLは要素属性で構成されていて基本的な構造は、

<要素名 属性名=”属性値”>内容 (文字列値または子要素) </要素名>

となります。

こんなXMLフォーマットについて前回と同様に「第2回で説明した6つの共通的な取り決め」に照らし合わせて特徴を掘り下げていきましょう。

① データ構造

これまでの説明で私は、

  • 1人目のデータを格納しているのはどの場所か。2人目のデータを格納しているのはどの場所か。
  • 1人分のデータの中で、順位を格納しているのはどの部分か。同様に氏名は。ホームラン数は?それぞれどの場所に格納されているか。

これらに関する取り決めを定めている(=持っている)のは誰でしょうか?入力データでしょうか?プログラムでしょうか?という質問をしました。

XMLの場合、この答えは「ほとんどがデータ側で定められている」です。

サンプルデータでは、データの構造はXMLに記述されている要素と一致しています。前回のCSVでは、データ自身は区切られていても、「1番目の項目は順位で、2番目の項目は氏名、3番目の項目は本塁打数である。」という「項目順と項目の意味との対応付け」をプログラムで取り決める必要がありましたが、このXMLは項目の意味そのものを要素名として記述している(=データ側で取り決めている)ので、要素名さえプログラムでわかっていれば順番による対応付けは不要なのです。この便利さの一例として「データに新しい項目が追加された場合」を想像してみましょう。本サンプルデータの仕様変更として「順位と氏名の間にチーム名を入れたい」という仕様変更が発生したとします。この場合チーム名の追加に関するプログラムの処理変更は当然です。しかし、それ以外にこれがもしCSVフォーマットであった場合「1番目の項目は順位で、2番目の項目はチーム名、3番目の項目は氏名、4番目の項目は本塁打数である」という仕様変更になるので「氏名と本塁打数」のデータ取得処理も「取得項目番号を変更する」というプログラムの処理変更が発生しているのです。本サンプルは項目数が少ないので変更範囲は軽微に見えますが、これが100項目のデータを処理するプログラムであれば影響範囲は甚大です。プログラム変更後の試験工程まで考えれば変更コストはさらに増大します。XMLフォーマットの場合、「順番による対応付け」を行っていない=データ構造の取り決めをデータ側で定めているので、この仕様変更による影響範囲は純粋にチーム名の追加処理のみに限定されます。言い換えるとこれは「仕様変更前の既存データ」が仕様変更後の新しいプログラムで再利用できることを意味します。XMLはそれを扱うプログラムに対して項目の順番を気にさせないので、<チーム名>タグに関する処理を追加した新しいプログラムであっても矛盾なく処理を行うことができるのです。(もちろんその場合、仕様変更前のデータからはチーム名を取得できませんがw)このデータ再利用性の高さはXMLが持つ長所の一つです。

もう一つわかりやすい例を説明するために、前々回前回と同様に、本サンプルデータのデータ仕様の例を以下に示します。

データ仕様
データ名 最初の要素内のname属性名に従う
文字コード 本XMLの文字コードに従う
項目№ 項目名
要素名に従う

 

おお!前々回前回と比べて、ずいぶん記述量が減っていますね?ほとんど内容が無い状態です。これまで説明させていただきましたが、上記のデータ仕様もAさん→Bさん→Cさん→Dさんとデータが手渡されていく際に上記のデータ仕様も一緒に手渡されていくわけです。この内容がほとんど無いということは「面倒くさくない」という状態です。この点に関しても「XMLは再利用性の高いデータフォーマットである」と言えるわけです。

② 項目の最大データサイズ

このルールを持っているのもデータです。項目データは「タグで囲われたデータ」というルールなので、項目の長さをプログラムで決める必要がないのです。

この観点において、「XMLは自由度の高いデータフォーマットである」と言えるわけです。

③ レコードの最大データサイズ

この取り決めに関しても定めているのはデータになります。本サンプルは歴代1位の王さんから歴代5位清原さんまで掲載していますが、このデータに6位のかたが加わったとしても、プログラムの処理に変更はありません。「XMLは自由度の高いデータフォーマットである」…と言いかけて、実はここに落とし穴があります。

それは「レコードの最大データサイズがとても大きい(=件数の多い)XMLデータ」を処理する場合に起こります。(ここではあえてXMLビッグデータと呼びます)

「XMLは木構造を持っている」という事を思い出してください。XMLビッグデータは「巨大な木」と言い換えることができます。つまりXMLビッグデータを扱うプログラムは「巨大な木をまるごとを一つの処理単位として処理する」事を求められるのです。これはコンピュータにおいては「大きなメモリを必要とするリソースコストの大きい処理」なのです。ただでさえマシンリソースを要求するビッグデータの処理においてこのデメリットは大きいと言わざるをえません。「XMLはフォーマット的な自由度が高い。しかしビッグデータ処理には向かないフォーマットである。」といえるのです。

Note:

詳しい説明は割愛いたしますが、実はXMLであっても件数の多いデータ処理は可能です。SAX(Simple API for XML)と呼ばれる処理手法を用いることによって、XMLビッグデータを「巨大な一本の木として扱わない処理手法」を採って処理速度を上げる事ができるのです。しかしこの方法は「XMLの持つ自由度を十分に生かせない」「データ構造に関する取り決めをプログラムに依存している」という観点から本連載における評価の対象から外した次第です。ちなみにXMLを木構造として扱い本来の持ち味を生かす手法をDOM(Document Object Model)と呼びます。

④ 文字コード

これがXMLの特徴の一つです。この取り決めを定めているのはデータです。サンプルデータの1行目を見てください。「<?xml version=”1.0″ encoding=”utf-8″?>」と記述されています。XMLはデータフォーマット内に文字コードにする取り決めを記述できるフォーマットなのです。このメリットは革命的で、XMLの構文規則に従って処理を行えばプログラムは処理対象ファイルの文字コードをプログラム内で個別に指定する必要がなくなったのです。このデータがAさん→Bさん→Cさんと手渡されていっても、AさんBさんCさんのプログラムは文字コードを気にする必要が無いのです。「XMLは文字コードに関して、再利用性が高いデータフォーマットである」と言えます。

⑤ エスケープ文字

この取り決めもデータが定めています。XMLにおいて文字のエスケープ処理は、「実体参照 (entity reference)」という用語で取り決められています。XMLは要素を”<“や”>”で表現しますが「じゃあ、”<“や”>”の文字そのものをデータとして表現したかった場合どうするんだ?」という取り決めになります。XMLの場合、上述のW3Cという団体で仕様が以下のように定められています。

  • 文字「&」は「&amp;」と表現する
  • 文字「<」は「&lt;」と表現する
  • 文字「>」は「&gt;」と表現する
  • 文字「’」は「&apos;」と表現する
  • 文字「”」は「&quot;」と表現する

実体参照(エスケープ)の規則はCSVと比べて少々複雑ですが、仕様が厳格に定められておりCSVのようなあいまいさ(方言)がないので、処理の過程で間違いが起こることもほとんどありません。「XMLはエスケープ処理に関して、再利用性が高いデータフォーマットである」と言えます。

⑥ 処理速度

ここまでベタ褒めしてきた感があったXMLフォーマットですが、処理速度においてはフラットフォーマット・CSVフォーマットに劣ります。XMLは開始タグと終了タグで内容を囲むことでデータを表現しているので、データの識別方法として、

  • 開始タグ:どんなに短くても「<x>」のように3バイトが必要
  • 終了タグ:どんなに短くても「</x>」のように4バイトが必要

の整合性をプログラム上の判断として必要とします。またCSVのように「データを区切る」処理よりも「開始タグと終了タグを開閉する」処理のほうが処理コストを必要とします。

データの再利用性や自由度の高さがXMLの魅力

以上、各フォーマット説明の第三弾としてXMLフォーマットについて説明しました。ここで多少の私見をまじえて今回のまとめを述べます。

「項目順と項目意味の対応付けが不要」「文字コードの情報を内包している」という事に代表される「データの再利用性や自由度の高さ」は、一つのデータファイルが単独で複数の人の手やプログラムを渡り歩く現在のシステムにとってまさにうってつけといえるものであり、ネット社会への貢献度は計り知れないといえるでしょう。XMLフォーマットはCSVフォーマットの欠点を補うために考え出されたということが言えます。しかし私がおもしろいと感じることは、「XMLの長所・短所はちょうどフラットファイルの長所・短所と裏表である」という事です。

①.データ構造
フラットフォーマット:不自由
XMLフォーマット:自由
②.項目の最大データサイズ
フラットフォーマット:不自由
XMLフォーマット:自由
③.レコードの最大データサイズ
フラットフォーマット:大量データを得意とする
XMLフォーマット:大量データを苦手とする
④.文字コード
フラットフォーマット:内包できない
XMLフォーマット:内包できる
⑤.エスケープ文字
フラットフォーマット:存在しない
XMLフォーマット:存在する
⑥.処理速度
フラットフォーマット:早い
XMLフォーマット:遅い

前回も述べさせていただいた「便利な事と不便な事の交換がデータフォーマットの変遷に現れている」ということがここでも言えるのではないでしょうか?ここで私自身も「じゃあCSVの位置付けは?」と考えるのですが、それらも含めた本連載の総まとめは次の次の回で述べたいと考えています。

次回フォーマット説明の最後となる第四弾は、JSONフォーマットについての説明をさせていただきます。

本連載について

 

SERVICE