座談会 「XMLの明日」
2.自分だけのタグを作るな! |
自分の<p>タグを 勝手に作ると データ交換ができず タコツボ状態に なってしまう (檜山氏) |
檜山 昔からよくタコツボという言葉を使っていたのだけれど、例えばSGMLでは、DTD(文書型)ごとに完全に孤立したネームスペースがあるとしか考えられないんですよ。同じDTDに従っていれば、それらの文書間では交流がある。そうじゃなければ、まったくデータ交換はできない。
檜山 例えば、(SGMLによる)化学と物理学と数学の論文があるときに、先頭のほうにタイトルがあって著者があって、と、直感的にこれらは非常によく似ている。式や用語などがマークアップされているし、普通の感覚なら、これらの論文を寄せ集めて論文集にするときには、似たような素材だからきっと(一本のSGMLに)まとめられると思うけど、SGMLではそれはできない(*)。1つ1つがタコツボにはいっていて全く交流ができない。
*檜山氏は、この例での化学と物理学と数学の論文が、それぞれ別のDTD(文書型)を持つと想定している。 |
檜山 でも今は状況が改善されている。似たような論文なんだから、全体はXHTMLにして、化学式を表現するタグはXHTMLにはないから、たとえばケミカルマークアップランゲージから借りてくる、数式は数式マークアップランゲージから借りてくる。それで論文も論文集も作る。<p>タグを自前で作ったりしないで、ほんとに必要なタグだけXHTMLに足す、というのがいいんじゃないかと思う。そうすれば混ぜたり、統合したりできる。ツールで簡単に作れるからって、自分のマークアップランゲージとして、私の<p>タグとか勝手に作ってしまうと、SGML時代みたいにデータ交換できなくなってしまって、タコツボ状態になってしまうのではないかな。
川俣 いま起こっているのは、昔ながらの世界観や方法論をXMLに置き換えよう、持ち込もうとしている人たちがいる、ということ。そういう人達はXMLで自分の<p>タグを作る!(笑)
檜山 別に悪意があってやっているとは思えないのだけど、端的に僕がいやなのはそれです。みんな本当に自分の<p>タグを作っちゃうんですよ。
川俣 スキーマの定義をシェアする、という発想がない。少し考えてもWebページの「私の日記」の中に、今日見たニュースを張り付けるとか、文書を混ぜることはありえるでしょう。だから、本当に独立して定義したXML文書で済むことって本当に少ないでしょう。
独自タグと情報共有のバランス |
われわれは情報を 共有するんだ、 という心構えを 持たねばならない 時期に さしかかっている (川俣氏) |
新野 でも、例えば複数の企業で回覧する発注書のような文書をXMLで作るとして、それをパブリックな仕様だけでは作れない、機能が不足していたらどうするんでしょう。やはり自分たちのタグを作らざるを得ないですよね。
江島 よくとられているのは、ある程度のライブラリを決めて、それを共有しましょうという方法。こことのやりとりはコレ使ってくれないと読めないよと、いう決まりを作っておく。そしてそれを分かりやすい形で提供しておく。ただ、その決まりをあまりに厳密で細かく決めると逆に分かりにくいので、そのバランスが難しいですね。XMLで情報をやりとりするコミュニティの中にはそういう規約がある。でもその規約をゆるくしておく、ということなんですね。
平野 BtoBでは、つなぐのが大前提。つなぐんだけど、いくつかのインダストリーごとに発注書が違う、ということは当然あります。けれど社内的にはそれぞれのインダストリーに発注書をださなければいけない、どうしよう、というとき。それを包含したような社内処理用スキーマがあったりする。
檜山 いまの例は分かりやすいですね。世の中に標準といわれているスキーマが3つあったときに、それぞれを採用している会社と取り引きするときには、社内的にどれか1つに決めるわけに行かない。しかも相互に完全にコンバージョンできるとかぎらないとしたら、しょうがないからちょっとジェネリックなものを社内で作るしかない。
江島 コンバージョンするのはグルーアプローチ(*)なんですね。それはグルーを作る時間のほうが長くなってしまう。
*グルー この場合のグルーとは、接着剤などの意味。コンバージョンによって2点間での接続を意識していると、3点間、4点間で情報交換しようとしたときにとたんに行き詰まることが多い。 |
檜山 例えば、関東ナントカ学会と関西ナントカ学会と東北ナントカ学会の3つの学会が、それぞれの論文のフォーマットとして独自にマークアップランゲージをXMLで定義する、というのでは不便きわまりないから、そうした状況では、見識を持って統合したものを作らなければならないでしょうね。
新野 ということは、現在いろんな業界ごとにXML化の動きを進めていることは、悪いことではないけれども、それぞれがタコツボにならないように気を付ける必要はあるだろうと。
川俣 これはXMLの問題と言うよりもっと大きいもので「われわれは情報を共有するんだ」という心構えが、いままではなかったけど、これからは持たなければならない時期にさしかかっているんだとおもいます。
檜山 共有しないことによって商売ができた時期もあったけど。それが文化として残っているところもまだあるね。
平野 でも現在は基本的にはつなぐことが前提ですね。つなぐからには標準のマークアップランゲージがあればそれを使う、というのが最初の選択肢で、それでカバーできなければ工夫をしなければならないでしょう。もちろん、その際の方法論といったものはある程度共通の認識を持っていなければならないでしょう。
檜山 そういうときにマークアップ言語を定義するツールは、パレットから既存のタグや機能をもってきて、それで足りないときにだけ、新しくタグを作るような、そういった方法をとるべきで、最初からオリジナルのタグを作るといった方法は最悪でしょうね。
新野 でも、そういったところまでXMLは熟しているんですかねえ?
平野 例えば現在のツール(*)の標準で出てくるパレットで、足りるか、というとまだまだ足りないでしょう。
*現在のツール ここでは具体的なアプリケーションを想定しているのではなく、もしそういったツールがあったと仮定しての話。 |
新野 それに関しては、まだいろんな人が提案するべきなのでしょうね。
檜山 まだマークアップランゲージがない分野もたくさんあるでしょうからね。それはまだまだですね。
Index | |
座談会 「XMLの明日」 | |
1.XMLが分裂してしまう可能性はあるか 今は多くのインダストリーでXMLを取り入れる動きが活発だ。このままインダストリーごとにXMLの規格が分裂してしまう可能性はないのか。それを防ぐにはどうすべきか |
|
2.自分だけのタグを作るな! XMLは独自にタグを定義できることが特長だが、それだけでは他社とのデータ交換ができなくなってしまう。独自のニーズを満たしつつデータ交換を実現する方法は? |
|
3.XMLアプリケーションのモデルが課題 XMLアプリケーションを開発する際に、定番の見本や方法論はまだほとんど存在していない |
- QAフレームワーク:仕様ガイドラインが勧告に昇格 (2005/10/21)
データベースの急速なXML対応に後押しされてか、9月に入って「XQuery」や「XPath」に関係したドラフトが一気に11本も更新された - XML勧告を記述するXMLspecとは何か (2005/10/12)
「XML 1.0勧告」はXMLspec DTDで記述され、XSLTによって生成されている。これはXMLが本当に役立っている具体的な証である - 文字符号化方式にまつわるジレンマ (2005/9/13)
文字符号化方式(UTF-8、シフトJISなど)を自動検出するには、ニワトリと卵の関係にあるジレンマを解消する仕組みが必要となる - XMLキー管理仕様(XKMS 2.0)が勧告に昇格 (2005/8/16)
セキュリティ関連のXML仕様に進展あり。また、日本発の新しいXMLソフトウェアアーキテクチャ「xfy technology」の詳細も紹介する
|
|