まだまだ未熟なXML

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

仕様が未確定

XML1.0がW3C勧告となりはや3年を経過したが、周辺仕様は未成熟というのが現状である。
その最たるものがスキーマ(データ構造)の記述方法である。 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テーブルから1つのXMLデータを得ようとすると、
一旦階層ごとに選択した結果を結合(JOIN)等しなければならず、
XMLの階層が複雑であるほどこの部分のパフォーマンスが問題となる。

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

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

フリーソフトに期待

ここまで、ツールが未成熟といってきたが、フリーソフトの分野では必ずしもそうではない。 IBMのalpha works , Apache XML project ,
BAYKIT ,

SmartDoc
など 仕様に未確定部分があっても多くのフリーソフトが提供されており、 動くサンプルを取得できる。
仕様の確定がXML普及の必須要件なら、 XMLの普及を底辺で支えるのはこれらフリーソフトではなかろうか?
今後ともこのフリーソフトの発展に期待する。