XMLのカタチ：XMLを学ぼう（2）（2/2 ページ）
前回は、XMLが言語を記述するためのメタ言語である、ということを簡潔に示した。それゆえに、XMLは非常に幅広い領域に応用可能だということを理解していただいた。今回は、XMLによってどのように情報が表現されるのか、その構造と、XML自身が持つ枠組みについて説明する。
XML以外のデータ記述方式との比較
さて、XML文書は木構造を記述することが許されていることがわかったと思う。それでは、木構造というのは、実際のデータを記述するのに十分なものなのだろうか。それを検証するために、他のデータ記述手段と比較してみよう。
■プレーンテキスト
プレーンテキストは、ただ単に、文字が先頭から最後に向かって並んでいるだけのデータである。つまり、構造と呼べるような高度なものはなにもない。親子関係もなにもなく、ただ、一列の前後関係があるだけだ。たとえて言うなら、1本のひものようなデータ構造と言える。
木構造でプレーンテキストの情報を表現するのは簡単だ。1本の幹だけ作って、それをプレーンテキストに見立てるだけでよい。枝葉は必要ない。
XML文書では、最低でも1つの要素が存在しなければならないという制限があるため、文字列だけでXML文書とすることはできない。そのため、1個の要素を置き、その子として文字列を置けば、それでプレーンテキスト相当のデータを表現したことになる。
■CSVやRDBのテーブル
RDBのデータを交換するためにXMLを使用したい、というニーズは差し迫ったものがある。RDBにはすでに大量のデータがあり、それを直接データ互換性のない他のアプリケーションで使うために渡すとか、Internetを経由して送るといった必要性はすでに存在している。そういう緊急性のあるニーズを背景に、いきなりXMLの深い森に迷い込んだユーザーが、最初に抱く疑問が、XMLを使うっていうのは、CSVで交換するのと、どこが違うの?ということだ。
表面的に目に入るデータだけを見ていると分かりにくいが、データを記述する形という切り口で見ていくと、CSVとXMLの違いは簡単に理解できる。
CSVは、基本的に、1行にカンマで区切ったデータを列挙し、それを複数行並べた形式といえる。これは、縦と横に2次元的に広がっている表であると考えられる。RDBのテーブルも、基本的にはこれと同じ構造を持っていると考えられる。そのため、ある情報を明確に示すためには、縦の位置と横の位置が定まればよい。
それに対して、XMLは木構造である。特定のデータを指し示すために、縦横ではなく、親子で考える。CSVとXMLの決定的な違いはこれである。CSVは、あらかじめ決まった数の項目が縦横に並んでいるので、あるデータに関してより詳しい情報を追加しようとしても、入る余地がない。それに対して、XMLは親子関係が基本であるため、子を追加するという形で情報をどんどん追加していくことができる。さらに、子の情報を充実させるために孫の情報を追加するということもできる。
この差から言えることは、XMLの方がCSVよりも柔軟に情報を記述できるということである。
さて、RDBのデータを転送するためにXMLを利用するというケースに限って考えると、もともとRDBのテーブルには子や孫という考え方はないため、そのようなデータは存在しない。だから、XMLを使わねばならない積極的な理由がない。ただ、既述する文字エンコーディングを明示的に示したり、スキーマ言語を用いたデータのチェックができるといったメリットがXMLには存在するため、それらを目的としてXMLを利用するのは有益だろう。このあたりの話題は、今回のテーマとは外れるので、詳しくは触れない。
それはさておき、2次元の表であるCSVを、木構造であるXMLに変換することは可能なのだろうか。一見、まったく違うように見えるが、いくつかのルールを決めてやると、CSVからXMLへ、情報をロスすることなく変換できる。
まず、ファイル全体を示す要素を定義する。そして、その子として、1行単位のデータを束ねる要素を定義する。更にその子として、データを表現する要素を定義し、それにデータを含める。この要素を1行分だけ並べてやる。これをすべての行に関して繰り返せば、CSVからXMLへの変換は完了である。
■ワープロ等の文書
ワープロソフトなどが生成する文書ファイルに関しては、それぞれの構造がソフトごとに決まっているので、すっきりした結論を書くことはできない。だが、おそらくたいていの場合、木構造の内側に収まるのではないかと考える。
とはいえ、ワープロソフトのユーザーが、本当の意味でデータの形を意識して文書作成を行っているか、疑問もある。大半のユーザーは、紙の上に、何が表現されるかだけを意識しているのではないだろうか。ワープロが紙の上の表現を扱うソフトだとすれば、それはXMLというよりも、XMLと併用するスタイルシートの問題と言える。スタイルシートとは、XML文書に具体的な見かけ（フォントの指定や表示、印刷の位置など）を与える仕掛けである。
データの形とスタイルシートの関係に関しては、あらためて独立したテーマとして取り上げてみたい。
■HTML
本来、HTMLはSGMLで作られたマークアップ言語である。SGMLは、XMLの生み出す母体となったメタ言語で、基本的な考え方はXMLとなんら変わるところはない。つまり、SGMLも木構造であり、当然、それによって作られたHTMLも木構造に制約されるはずである。
ところが、現実のWebブラウザは、木構造になっていないHTMLを解釈して表示してしまうのである。
以下のサンプルを見ていただきたい。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
このサンプルは、筆者の使用するWindows 2000のInternet Explorer 5.0で、そのままエラーにもならず、表示できてしまう。実際に試してみたい方は、ここの直接見られるサンプルを見ていただきたい。
しかし、この行は変である。strong要素がem要素の親だとすれば、strong要素の開始タグと終了タグは、em要素の開始タグと終了タグより外側になければならない。だが、実際には、strong要素の終了タグは、em要素の内側に記述されている。かといって、strong要素がem要素の子だとすれば、em要素の開始タグと終了タグは、strong要素の開始タグと終了タグより外側になければならない。だが、実際には、em要素の開始タグは、strong要素の内側に記述されている。つまり、どちらで解釈しようとしても、うまく解釈できないのである。ところが実際にマークアップされたテキストとして記述されたファイルが実在し、しかも、それを解釈できるソフトウェア（この場合はWebブラウザ）も存在するわけで、あり得ないものではない。
解釈できない構造でありながら実在するというのは、どういうことだろうか?
木構造の逸脱はエラーとなる
その理由は、木構造を逸脱した文書というのも、この世の中には存在するということにある。このサンプルは典型的な木構造からの逸脱である。これが表示できるということは、木構造から逸脱した場合でも表示可能とするという、本来HTML仕様には含まれない独自拡張がなされていることを意味する。
もちろん、本来の正しいSGMLやHTMLの仕様からすれば、このような木構造からの逸脱はエラーである。しかし、現実的にこのような誤用を含むページが多いため、Webブラウザの多くは、これらの記述を受け入れ、寛容に表示するようになっている。
■HTMLでは許されても
ところが、である。XMLは、この種の寛容さを明確に否定しているのである。つまり、これまでWebブラウザが適切に表示できていたHTMLのすべてをXMLに変換することはできないかもしれない、ということなのである。
もっと直接的な表現でいうなら、HTMLの後継言語であるXHTMLは、XMLをベースに作られている。つまり、XHTMLをサポートするWebブラウザは、木構造になっていない全ての文書をエラーとして処理し、表示しないということだ。つまり、ただ単に表記上の小さな相違（例えば、空要素タグの最後に/を挿入するような）を修正するだけでは、HTMLからXHTMLへの修正は完了しないかもしれない、ということである。タグの並び順まで見直さねばならない可能性が生じてしまうのである。
このようなXMLの不寛容さは、実はユーザーのためなのである。HTMLは、ただWebブラウザで表示するためだけの用途で普及したが、本来は、もっとさまざまな文書自動処理に利用できる可能性を秘めたものであった。しかし、誤ったHTML文書があまりにも増えすぎたため、HTMLの自動処理は、現実に実行しても意味のある結果を出せないことになってしまった。これを本来あるべき姿に引き戻すためには、間違いがあったときに、それをユーザーに伝える必要がある。これまでのHTMLは寛容に解釈されて、それらしく表示してしまうために、誤りがあってもそれにユーザーが気付かずに見過ごすことが多かった。だからこそ、エラーに対しては不寛容になる必要があるのだ。それが、ユーザーに対する本当の親切なのである。
まとめ：ポイントは木構造
今回のポイントは、XMLは木構造を扱うということである。このデータはXMLで記述できるだろうか?という疑問を持ったときには、そのデータを家系図形式に整理してみると良い。シンプルな親子関係だけでまとまれば、容易にXMLで表現することができる。
もちろん、それだけで、XMLで表現できると結論を出せるわけではない。全体の構造以外にも、適、不適があるからだ。それらの問題に関しては、これから、順次取り上げていきたいと考えている。
次回は、さまざまな実際のXML文書を見ながら、今回解説した知識を具体的に確認してみたいと考えている。
それでは次回、また会おう。
Copyright © ITmedia, Inc. All Rights Reserved.