座談会 「XMLの明日」

3.XMLアプリケーションのモデルが課題

檜山　（XMLをビジネスで使うときに）困るという話では、別のことも感じている。実際にXMLアプリケーションを作るときに困るんですよ。アプリケーションのモデルがないのね。

川俣　それはJavaのような言語の限界でもあるでしょう。プログラム言語の側で、（XMLが持っている）ツリー型のデータ構造をうまく表現する機能を持ち合わせていない。

檜山　開発するアプリケーションでXMLを扱うことは合意しているとして、それを適応する分野もはっきりしているとしてね、そこから先のガイドラインというかフレームワークがないのね。もちろん、それはプログラムを作る側の問題でもあるけど、DOMのエンジンがあったとしても、それはなにかを作ろうとしたときに「ネジがあります」というくらいなもんで。もっとなんかフレームワークがほしい。

川俣　XPath Scriptとかチャレンジはありますね。C#のようなものへの期待もあるでしょう。

新野　（DOMなどの）APIよりもずっと高級なものですね。

檜山　モノとしてコンポーネントが提供されてもいいし、設計手法やフレームワークでもいいと思うけどね。

新野　そこは江島さんの会社のメシのタネになるんじゃないですか？

江島　そうなるんじゃないですかね。もちろん上にいくほどその手法というかワークフレームは広がっているとは思うのですけどね。

檜山　分野ごとにそれが違うのはしょうがないと思う。でも、分野がきまっている、仕様も決まっている。XMLを使うことも明らか。そうしたときに、要求とXMLの機能を重ね合わせると、だいたいこういったモデルで開発するでしょう、といったものがない。

江島　そうそう、ネジはあるんだけどビルディングブロックになっていない。まだ粒度が小さい。

XMLで失敗する方法ならある

檜山　いまいくつかのXMLを使うプロジェクトがあるのだけど、当たり前だけど、ほとんどの人はXMLを使って動くものを作った経験がない。そうするとXMLを使うことがいつのまにかトーンダウンしちゃう。やっぱりRDBにしちゃおうとか。
　一般のプログラミングに関して言えば、教科書が成立するじゃないですか。例えば広域変数使っちゃいけないよ、みたいな基本事項はあるでしょう。そういったノウハウやTipsが、XMLではあんまり蓄積されていない。ある典型的なプログラム、例えばソートプログラムを作るときには、こういうデータ構造とアルゴリズムで、というセオリーが書けるでしょ。でもXMLではそういうのがまだない。

川俣　私も気になっているけど、SGMLの時代からおもにたくさんの失敗を通じて経験が蓄積されてね、こうしたら失敗するというケースが存在しているにもかかわらず、いまからXMLをはじめた人はそれを知らない。で、同じ失敗にはまるケースが見えるから、なんとかしたいんだけど。

檜山　こうしたら失敗する、のほうはある。けど、こうしたら成功する、という決め手はないなあ。

新野　でも失敗しそうな人を救えるだけでもいいじゃないですか。

檜山　例えば番号でタグ作ると絶対に失敗する。（笑）

川俣　そういうのぜひ原稿で書いてくださいよ。檜山さん。（笑）
　 例えば、日本電子出版協会の作ったJapaXという言語がありますけど、これはSGMLの経験のある人がアドバイスしたので、結構すんなりできたという経緯がある。経験のある人がアドバイスするかどうかで、XMLで作る言語の質がそれだけで変わってしまうことがある。

新野　ぜひわれわれもそうした情報の提供に努力していきましょう。

Index
座談会 「XMLの明日」
	1.XMLが分裂してしまう可能性はあるか 今は多くのインダストリーでXMLを取り入れる動きが活発だ。このままインダストリーごとにXMLの規格が分裂してしまう可能性はないのか。それを防ぐにはどうすべきか
	2.自分だけのタグを作るな！ XMLは独自にタグを定義できることが特長だが、それだけでは他社とのデータ交換ができなくなってしまう。独自のニーズを満たしつつデータ交換を実現する方法は？
	3.XMLアプリケーションのモデルが課題 XMLアプリケーションを開発する際に、定番の見本や方法論はまだほとんど存在していない

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）