座談会 「XMLの明日」

1.XMLが分裂してしまう可能性はあるか

熱い議論を交わす四人の参加者。中央は進行役の新野

新野　最近僕が思うのは、いろんな分野でXMLに対する激しい動きが起こっているのではないかと。例えばデータベース屋さんがXMLに「これはすばらしい」と感動し、機械の設計者がXMLに感動し、出版にかかわるひとが感動し、ほかの分野の人が感動し、と。

川俣　そうですね。

新野　そうなると、この先どうなるのでしょう。それぞれの分野の人が「XMLはすばらしい」と考えてそれを自分の分野に適した形で使い始めたとき、不幸な場合は、そのままXMLは分裂していくのでしょうか。それとも、なおかつそうした全体をまとめる技術的な着地点がどこかにあるのでしょうか。

川俣　僕は、いままでの常識が通用しない時代がきたんだと思います。例えば、昔はSGMLといったら文書に関連した人たちだけがその技術について分かって入ればよかった。しかしXMLになって、XMLで文書もデータも扱うようになってきて、さらにSOAPだなんだってになってきて、突然、XMLは技術者全員が関係する技術かもしれない、ということになってしまったのです。

新野　それは、インダストリーをまたがるテクノロジーが出てきた、ということなんでしょうか？

江島　それもまだ狭い見方のような気がしていて、IT業界全体の底上げになるようなものなんじゃないですか。

局所的な動きはBtoBの妨げになるか

スキーマ言語は、 なんとか 収れんする方向へ 行ってほしい （平野氏）

新野　それで、（XMLでの企業間取り引きを推進する会社として）平野さんは、そうやってXMLの使われ方に局所的な動きが出てくるのは困らないですか？

平野　うーん。

新野　つまり、いま2つのことが同時に起こっているように思えるんです。例えば、XMLコンソーシアムのように、みなさんXMLを使ってください、というXMLの啓蒙が始まっている。

新野　一方で、文書とか、データベースとか建築とか、流通とか病院とか、それぞれの分野の人がXMLをにらみながら腕組みをして、「自分たちのXMLを作ろう」という局所的な動きがある。それは正しい動きなんでしょうか。そして、企業間取引を推進する平野さんとしては嬉しいですか？

平野　いまの話のようなインダストリごとにXMLを採用する動きと、もっと下の、XMLのスキーマ言語（*）のところの動きと、大まかに2つに分けて考えなければいけません。
　 例えば、XML SchemaをW3Cで決めている。これはXMLのスキーマ言語の部分。それから、いろんなインダストリーで決めているのは、その上でXMLを活用する応用の部分です。

*スキーマ言語　XML文書の構造（スキーマ）を記述するための言語。DTDをはじめ、W3Cで作成しているXML SchemaやRELAXなどがある。このスキーマ言語を使って、さまざまなXML文書を定義する。

平野　で、技術仕様、つまりスキーマ言語のところは、世の中にたくさん出てきてもらっては困る。このスキーマ言語のところは、なんとかいくつかに収れんする方向へ行ってほしい。逆に、さまざまなインダストリーでXMLを応用したボキャブラリ（*）がたくさんでてくるのは当初しょうがないと思います。目的に応じて作る。インダストリーごとに、あるスキーマ言語に基づいていろんな仕様がでてくる、それは仕方ない。それをどうやってやりとりしましょうか、という議論がでてきて。それが、あるところとあるところで、同じものを使いましょう、となるでしょう。
　 だから最初から全体に統一したものがなければならない、というのはやはりなくて、それだといつまでもXMLは使われないものになってしまう。BtoBならば、まず最低2者間でXMLの合意がとれれば使えればいい、そしてより多くつながるために、標準化が進んでいくのでしょう。標準がなければ使えないとか、標準化されなければ使ってはいけないとか、そういうことはない。

江島　そうそう。つまり先ほどの新野さんの話はスキーマ言語からみたら スキーマ・インスタンス（*）の話。スキーマ定義言語そのものとは 関係ない話なんですね。

新野　その辺の認識は檜山さんや川俣さんは一致しています？

*スキーマインスタンス　スキーマ言語によって定義されたXML文書の構造そのもの。 *ボキャブラリ　タグの種類。XML文書はDTDなどのスキーマ言語などで独自のタグを定義できるが、そのタグをまとめてボキャブラリと呼ぶ場合がある。例えば、CADデータをXMLで表す場合と、XHTMLではボキャブラリが異なることは容易に想像できるだろう。

スキーマ言語の種類はどうなる？

檜山　平野さんはスキーマ言語は1種類というか、少ないほうがいいと?

平野　あまり多くない方がいいと思ってます、スキーマ言語は。ボキャブラリは多くてもいい。

檜山　ボキャブラリはそれこそ用途によってですからね。

平野　同じ分野でも、ボキャブラリがいくつかできるのはしょうがないと思う。例えば、電子商取引で使えるのは世界で一種類しかない、となったら変。

檜山　理想論は1個ですけどね。

平野　そう。スキーマ言語も1個でなければだめということはないとしても、発散していると困ってしまうから、ある程度絞られないと困るでしょう。恐らく、いくつかデファクト的にスタンダードが決まってくるでしょう。

檜山　まさにその数が問題になると思うんだけど、僕はスキーマ言語が1個になることを希望してはいなくて、まあ、100も200もあるのも困るけど、5個とか10個は仕方がないと思う。

江島　ひょっとして、アプリケーションごとにカテゴライズされてしまうかもしれない。

檜山　本当に1個しか必要ないのは、文書インスタンスをマークアップするためのシンタックス。つまりそれは、現在実際1個しかないあのXML1.0。これはそのまま変わらないだろう。だから問題を感じていない。
　それでね、大事なのはスキーマ定義より文書インスタンスのほうでしょう。 DTDのシンタックスを使って定義した妥当インスタンス（*）の集まりと、XML Schemaのシンタックスを使って定義した妥当インスタンスの集まりが同じなら、アプリケーションはスキーマ言語に係わらず、妥当性チェックされたインスタンスを安心して処理できるわけだから、スキーマ言語が複数あっても、それほど致命的に酷いことにはならないだろうと思っている（*）。

*妥当インスタンス　インスタンスとは、XML文書の中身。タグ付けされたデータのこと。XMLインスタンス、文書インスタンスと呼ぶこともある。つまりXML文書の中身。妥当インスタンスとは、スキーマ言語によって定義された構造に従って、正しい構造を持つことが確認されたインスタンス。 *檜山氏は、スキーマからアプリケーションに情報が渡されないことを前提に考えている。スキーマからの情報があると、その情報付加の能力によりアプリケーションの処理可能性は変わってしまう。

江島　それを言ってしまえば、そういうケースではスキーマ言語なんて複数はいらなくなってしまうんじゃないですか。同じインスタンスを表すのに、複数のスキーマ言語で定義できる必要はないじゃないですか。

檜山　例えばの話、あくまで例えばの話だけど、CPUがこの世に1種類しかなくて、機械語も1種類しかないとしても、高級言語には得意分野をそれぞれ持っているFortranやPrologやCなどがあってもいい。それと同じで、インスタンスマークアップにはXML 1.0だけで問題がないけど、マークアップ言語を定義するとしたら、スキーマ言語ごとに得意分野があって、用途ごとに向いたものを使う、そういう選択肢を持たせる意味でスキーマ言語は1個である必要はないでしょう。もちろん、だからといって100個ではなくて5個か10個だろうと思うけど。

江島　アプリケーション次第、もしくはインスタンス次第ではないでしょうか。例えばかつて「文書」は人間が読む情報として定性的なものだった。やがてそれがフォームで処理されるようなものも「文書」になって、いまではRDBで交換する情報も「文書」と呼ばれている。それらをすべて処理しようとするためのスキーマ言語が検討されているから、XML Schemaのようなものはガチガチなものになっている。文書の定義も時間とともに代わってきてますよね、そしてXMLはそれを取り込む方法になってきている。

ツールが影響力を持ち始める

ウィザードのような もので、 スキーマどころか ロジックまで 扱えるようになります （江島氏）

新野　やっぱり、XMLがばらばらにならないような解決手段というのは、スキーマ言語の数を減らすことになるんですか？

平野　スキーマ間のコンバージョンも可能ですね。

川俣　スキーマというのは世界観だと思う。世界観を表現する言語で、世界観の数だけスキーマ言語は作られるでしょう。

檜山　スキーマを1つにする圧力はあまり強くないほうがいいと思うけど、同じようなものを亜流でぼこぼこ作るのは困る。

江島　でも、いまはその（ぼこぼこ作られる）傾向が強いのではないかと思う。亜流という観点で言うと。

檜山　データベースの例で言えば、RDBの経験があってSQLのシンタックスにもなれている人がいて、彼らの設計の効率が上がり、取り扱いやすいスキーマ言語が欲しいというなら、それはそれでいいと思う。

新野　でもそうしたスキーマ言語の定義はどこでやるべきなんでしょうか。いまそういうことがW3CのXML Schemaで起こっている、と言われていますよね。一方で、日本ではXML SchemaではないRELAXのようなものが出てくる動きがある。やはりW3Cでやるべきなんですか、それともあちこちでもやるとか、どこに落としどころがあるのでしょう。

平野　いまのような状態じゃないですかねえ。W3Cもやるし、ほかのコミュニティでもやると。

檜山　世界観というか、ものの見方によってスキーマ言語ができるのだから、いろいろなところでやらざるを得ないし、出てきてしまう。どのスキーマ言語もある面から見れば効率がいい、ということがあるから、あれがいいのこれが悪いのと言っても仕方ないでしょう。

平野　スキーマ言語のスペックのところを話していますが、あとはツールですね。今後、スキーマ自身をガリガリに書くことはなくなるでしょう。スキーマを定義するツールがどんなスキーマ言語をサポートしているか、といったところがポイントでしょう。
　ここで影響をもつのがマイクロソフトでしょう。マイクロソフトは先日、Biztalk 2.0の発表で、将来的にサポートするスキーマ言語をXDRからW3CのXML Schemaに変更すると再度強調しましたよね。でも、エンドユーザーはそういうところを意識しないで作っていくことになるでしょう。

新野　なるほど、この場合、（スキーマ言語の統合や分裂が）技術的にいい悪いとは別に、ツールが影響を持ってしまうわけですね。

平野　スキーマよりもずっと上のレイヤーで、こういったデータが必要ですね、という定義をグラフィカルで作って、それがいつのまにかスキーマ定義にまで落ちる、というところまでいくでしょう。

川俣　やっぱりAccessのウィザードみたいに、いくつかの質問にこたえていくとデータベースの定義ができるようなかたちで、XMLのスキーマができるようになるのでは？

檜山　そういうふうになるんですかねえ。

江島　なりますね（*）。スキーマどころかビジネスロジックまでそういうので表現する、ということまでありますね。フローまでスキーマで落ちてきて、アプリにまで落とせると言ったところまで考えている連中までいますね。

*インフォテリアが販売している「XML Authority」は、そういったアプリケーションに非常に近い。

新野　檜山さんが「そういうふうになるんですかねえ？」と否定的に聞いた理由はなんですか？

檜山　いや、そうなると不幸だなあと。

新野　どの変が不幸なんでしょう。

「自分だけのタグを作るな！」

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

■更新履歴
2000/8/23 平野氏、江島氏の発言の一部を分かりやすく変更

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