データ交換フォーマット、Webページ記述言語、電子商取引のメッセージ、 SGMLに変わる文書フォーマットとして注目を集めるXMLであるが、 影の部分にも焦点を当てその現状を探った。

仕様が未確定

XML1.0がW3C勧告となりはや３年を経過したが、周辺仕様は未成熟というのが現状である。 その最たるものがスキーマ（データ構造）の記述方法である。 XMLスキーマを記述するDTD(Document Type Definition)は、 XMLとは別の書式で書かれており、型、名前空間をサポートしていない。 これを受けて出されたDTDに代わるスキーマ記述仕様 XMLスキーマ はようやくW3C勧告案（確定の一歩手前）になったばかりである。 日本では、これを待たずして RELAX 等のスキーマ記述仕様が策定・実装されており、 現在は、DTD,RELAX,XMLSchemaが混在する状況である。 この他のXMLの周辺仕様もまだ十分固まってはおらず、 仕様が定着し、その処理系が出揃うには今一つ時間がかかりそうだ。

XMLをSGMLの代わりに文書標準として使うには、組版印刷機能が必要である。 XMLのスタイル規格 XSL(extensible stylesheet language) の一部であるXSL-FOがこれに相当する。 しかし仕様が確定しておらず、XSL−FOに対応した日本語対応組版ソフトは、 XSL Formatter などごく少数である。

パフォーマンスの問題

XML関連のツールも未成熟である。 アプリケーション開発にはDBMSが重要となるが、 XMLを構文解析したDOM(Document Object Model)ツリーを ネイティブに蓄積、検索でき、しかも日本語が扱える主要なDBMSは、 eXcelon , Tamino など数種類しかない。 歴史の長いRDBと比べ、XMLでは販売本数がはけないからであろうが、 これらはやや高価である。 SQLで検索した結果をXML化するという方式をとれば保存はRDBでもよい。 実際レガシーデータの多くはRDBであり、これをXML化するのはコストがかかる。 このとき、問題となるのは、XMLとRDBの入出力時のパフォーマンスである。 階層構造のXMLを正規化されたRDBテーブルに入力しようとすると、 階層を紐解いて、各階層ごとにRDBテーブルに入力しなければならない。 逆に、正規化された複数のRDBテーブルから１つのXMLデータを得ようとすると、 一旦階層ごとに選択した結果を結合(JOIN)等しなければならず、 XMLの階層が複雑であるほどこの部分のパフォーマンスが問題となる。

データ交換用途では、タグの文字列マッチングや変換のパフォーマンスが問題となる。 XMLのメリットの１つに、変換規格 XSLT(XSL Transformations) で容易に構造変換が可能というものがある。 SGMLのように常にDTDの検証を必要としないというのがXMLメリットなのだが、 変換した結果は別のスキーマのXMLであるので、 例え元のXMLが構文解析されていても 再度構文解析しなければならずせっかくのメリットが活きない。

これらの問題は、時間が解決するものと、XMLそのものに潜在する問題がある。 仕様やツールの充実は時間が解決するだろうが、 パフォーマンスは、階層型のテキストデータであるXMLの構造そのものに依存する部分が大きい。 これは、即ち従来RDB＋固定長データでパフォーマンスを追及してきた 大量トランザクション・アプリケーションにXMLがあまり向かないことを意味する。

フリーソフトに期待

ここまで、ツールが未成熟といってきたが、フリーソフトの分野では必ずしもそうではない。 IBMのalpha works , Apache XML project , BAYKIT , SmartDocなど 仕様に未確定部分があっても多くのフリーソフトが提供されており、 動くサンプルを取得できる。 仕様の確定がXML普及の必須要件なら、 XMLの普及を底辺で支えるのはこれらフリーソフトではなかろうか？ 今後ともこのフリーソフトの発展に期待する。