Development Style Round Table Talking
第2回 日本発の独自技術を開発する
浅海智晴×平鍋健児×原田洋子×村田真

構成 谷古宇浩司（編集局）
2003/12/10

---

なぜRELAXなのか、そしてなぜRelaxerなのか。浅海、平鍋、原田、村田各人の思惑はさまざまだが、国際の場に日本から技術を出そうという目的は共通しているようだ。議論は、RELAXの優位性を端緒にIT業界の問題点の指摘へと展開していく。（敬称略）　→第1回 オブジェクト指向の弱点

---

◆プロジェクト参加者各人の思惑

編集局　このプロジェクトに参画する各人にはどのような思惑が？

平鍋　僕の場合は、このプロジェクトと並行して、裏プロジェクトが動いているんです。「Jude」というUMLモデリングツールがあるんですが、このツールを将来的には、さまざまなプロセスをサポートするツールにしたいんです。その最初のプロセス・プロファイルとして、Judeに「Relaxer」プロセスを載せようと。

◎参考： Jude（Jude 竹1.2.4）→永和システムマネジメントが開発するフリーのUMLモデリングツール

原田　以前、「Jakarta POI」というAPIを使っていました。例えば、Excelのファイル形式をPureJava環境で読み書きするとか。Excelというのは見たとおり「表」ですから、XMLで簡単に構造を表現できるんですよね。XMLで表現したものをPOIのAPIに埋め合わせるものとしてRelaxerはすごくぴったりはまったんです。だから「あ、Relaxerって面白いな」と。で、ここから何か面白いことができるのではないかと思っています。

◎参考： Jakarta POI→Microsoft OLE2複合ドキュメント形式のファイルを読み書きするためのAPI。代表的なOLE2複合ドキュメントはMicrosoft Excelのファイル形式である。

村田　僕は「RELAX NG」にかかわる「場」があれば積極的に参加したいと思っています。個人的には、現在、RELAX NGの携帯電話で動く「バリデータ」を作っています。すでに、動いているんですが、バグがあまりにもたくさんあるので、最初から作り直そうと思っています。なお、XMLに関して、「XForms」は珍しくいい技術だと思うので、積極的に後押しをしていきたいですね。

◎参考： バリデータ→バリデートを行うソフトウェアをバリデータと呼ぶ。XML文書の妥当性を調べるだけで、ほかに何もしてくれないが、XML文書の作成を行っている場合には、有益なエラー情報を豊富に提供してくれるバリデータがあると非常に便利である。

◎参考： XForms→HTMLの持つフォーム機能を分離独立させ、さらに強化することを意図した仕様。Webにおける次世代のフォームを目指している。

◆リーダーシップ・コラボレーション型のプロジェクト

浅海　今回のプロジェクト（Relaxerサービス・フレームワーク・プロジェクト）の進め方についていうと、いままでのこういうプロジェクトの方法論はコマンダー＆コントロール型だったと思います。つまり、枠組みがあって、その枠組みの中に人を押し込んでいくという感じ。俗っぽいいい方をすると、オーケストラ型。それが最近は、ジャズ・セッション型に変わってきていると思うんですよ。まず、個人（の能力）ありきという考え方です。個人の能力を最大限に高めてコラボレーションをしていくという進め方が、今後のこういうプロジェクトの流れだと思うんです。

平鍋　リーダーシップ・コラボレーション型ですか。

浅海　すべての組織が現時点で、リーダーシップ・コラボレーション型を採用できるわけはないんですけど、われわれが、そういう流れの先端を行くのは面白いかなと思っているんです。各技術のトップレベルの人たちが集まり、同じ「場」でいろいろなことをすると、面白い成果ができるんではないだろうか、という期待があって。

　開発者がXMLを使うときは、XML単体で使うことはなく、いろいろな技術を組み合わせて、そのバランスの中で使っていくことになると思います。さまざまな技術の断片を、開発者の切り口できちんとパッケージングしてあげないと、例えば、いくらいいスキーマ言語があっても使えないんですよね。
　
　Relaxerサービス・フレームワーク・プロジェクトでは、XML、Web技術とオブジェクト指向プロセスの技術をソリューション・パッケージとして提供できるようにしていきたいと思っています。

平鍋　パッケージとまではいかなくても、せめて、技術間のワイヤリングが可能になればいいですね。

浅海　まあね。確かに、完全なパッケージになるのは2年後とか、けっこう先のことになるかもしれないんだけど、まずは今回のプロジェクトを、新しいソリューション・パッケージを開発していく端緒にできればいいと思っています。

◆なぜ、RELAXなのか？

村田　XMLの話に戻りましょうか。僕が「RELAX Core」を作ったのは、W3Cが推している「W3C XML Schema」にどうしても満足できなかったからです。後に、ジェームズ・クラーク（James Clark）が「TREX（Tree Regular Expressions for XML）」を発表し、RELAXとTREXとの整合作業が進められ、RELAX NG（RELAX New Generation）としてOASIS（Organization for the Advancement of Structured Information Standards）が発表したんですね。

◎参考： OASIS
◎参考： RELAX Core解説
◎参考： W3Cスキーマに対抗するXMLの新仕様「RELAX NG」 （＠IT News）
◎参考： Thai Open Source Software CenterのRELAX NGのページ

　W3Cの向こうを張って、RELAXの普及を推進してきたわけですが、つくづく、「無謀な試み」というのは、やってみて面白いな、と実感しています。普通に考えれば、W3Cのお墨付きのW3C XML Schemaに異議を唱えるというのは、ある意味、狂気の沙汰だと思います。しかし、現在ではなんとか、RELAXが開発者の間で、ある程度は知られるようになってきています。もちろん、ジェームズの力を得たというのが大変大きな要素ですが、少なくとも、手を挙げないと絶対に何も起こらないということは明らかなんです。そういう意味で、日本のエンジニアはもっと無謀な試みをしてもいいと思っているんです。

浅海　僕はずっとIT業界で仕事をしているわけですが、いわゆる「Design by Committee」（委員会による設計）アンチ・パターンという状況をたくさん見ているんです。その結果、悟ったのは、結局、シンプルで普通の人が簡単に使えるものしか残っていかない、ということです。これが僕の経験則にもなっている。巨大な組織の後ろ盾、あるいは組織のお墨付きというのは確かに重要だと思いますが、ある技術が生き残るうえで最も重要なファクターではないな、と。RELAXをめぐる動きを見ていて、そう実感しています。

村田　今年開催された「WORLD WIDE WEB CONFERENCE 2003」（2003年5月20〜24日、ハンガリーのブダペストで開催）で、XMLの使用状況を調べたという資料があったんですよ。それを見ると、DTDの使用率が49％、W3C XML Schemaは0.0何％なんです。W3C XML Schemaは実際にはほとんど使われていない状況なんですね。さまざまな企業がW3C XML Schema対応のツールを開発しても、市場自体があまり拡大しないという状況が起こっている。水飲み場に馬を連れて行くことはできるけど、馬が水を飲まないという状況とでもいえましょうか。

浅海　W3C XML SchemaがW3CのRecommendationとして公表されたのは2001年でしたか。

村田　そうですよ。

浅海　2年たっても、全然まだまだということですか。

原田　新しく出てくるJavaの仕様書もDTDで書いてあることが多いですからね。

浅海　DTDにデータタイプを付ければいいんじゃないか、というのは昔からある議論だと思うんですけど。ただ、現在の利用範囲というのは、その辺が限界なのかもしれません。

村田　名前空間を入れれば、たいてい済んでしまうよね。

◆そして、なぜ、Relaxerなのか？

浅海　僕がなぜRelaxerを作ったのかというと、簡単にいえば、W3C XML Schemaを理解することができなかったからなんです。もともと、W3C XML Schemaを使って何かできるんじゃないかと思い、独自に調べていたんですがあまりの難しさに「これは駄目だ！」と匙（さじ）を投げました。ちょうどそのころ、村田さんが作ったRELAX Coreを見て、「あ、これはオブジェクトにマップできるな」と感じたんですね。それで、Relaxerを作り始めました。開発後、2カ月で動きましたよ。

村田　RELAX Core、RELAX NGにはもともと、オブジェクト指向的な香りが何もないわけですよ。何もない方が、かえって楽だと。

浅海　Relaxerを作る前に「SmartDoc」を作っていたんですが、これを作っているときに、XML処理で頻繁に出てくるパターンをだいたい把握できたと思います。「こういうプログラムを作ると、必ずこんなパターンになる」と。そういうノウハウをRelaxerが生成するコードに盛り込んでいるんです。そういう意味で、オブジェクトモデルとしては、とても使いやすいんじゃないか、と思います。

◎参考： SmartDoc→XMLをベースにしたドキュメント生成ツール

村田　Relaxerが実現しているのは、XMLを操作する基本的なソースのパターン生成の支援、ということですか。

原田　Visitorパターンが使えるとかでしょう？

浅海　実は、Relaxerの機能で一番好評なのが、Visitorパターンが使えるということなんです。Visitorのソースを自分で書くとすごい手間がかかるんですね。決まりきったパターンなのだけれど。しかし、RELAX NGスキーマを書いて、ポンとボタンを押すと、Visitorの構造まで、あるいはCompositeの構造（Compositeパターン）まで、全部自動生成してくれるんです。なぜ、こういうことができるかというと、ツリー構造に特化しているからなんです。グラフ構造にしてしまうとなかなかできないんですけど。

村田　パターンについては、Relaxerは「JAXB（Java Architecture for XML Binding）」に勝っていると思う。

原田　確かに、JAXBはクラスが複雑で分かりにくいですね。

◆アプリケーションの“性能”問題

原田　ところで、Webアプリケーションだと、膨大なアクセス量をさばかないといけないので、どうやって性能を上げるかというのは常に考えなければいけない問題ですね。

浅海　要するに、XML処理を（データベース処理の）トランザクションから切り離すことができるのかがポイントではないかと思います。トランザクションから切り離して処理できる部分はスケールアウトによってスケーラビリティを確保できるので。つまり、Webページ生成処理など、XMLを使う部分をトランザクションから切り離せば、マシンの増設だけで処理性能を確保できるので、XML処理の重たさはあまり問題にならないんじゃないかと思います。もちろん、このようなシステム構成を実現するためには、上流の分析や設計の段階でそのことが可能になるようなモデリングが行われていないといけないですけど。

村田　「Webサービスは遅いらしいですね」といううわさ話を聞くこともあります。

浅海　Webサービスは、いまのところプロトコルにHTTPを使うことになってしまうので、性能的には仕方がない面があるという気がします。インターネット上での通信では必要な選択ですから。だから、一番外側の部分だけ、つまり、社外との接続部分にWebサービスを使い、中身は別のプロトコルでやるというのが現実解だと思います。全コンポーネントをWSDLで定義してWebサービスとして実現するというアプローチだと、かなり厳しいと思いますけど。

村田　そもそも、XMLは仕様が複雑で膨大ですよね。「XML」「W3C XML Schema」「XQuery」「DOM」というふうにすべての技術を詰め込んでいくと（仕様書の）総ページ数は3000を超えるんじゃないかな。最初は30ページくらいだったのに。

浅海　本棚いっぱいの入門書を読まないと。

原田　技術はシンプルじゃないと浸透しないですよね。作る人たちはものすごく優秀な人たちばかりだと思うんですけど、使う人ってそうじゃないから。使う人が増えるに従い、そういう人たちにも間違いがないような導き方、技術というのが必要なんでしょうね。

◆国際の場に日本から技術を出そう

村田　Relaxerの弱点はスキーマの変更に弱いところですね。

浅海　スキーマ言語の強さを見る場合、いろいろな切り口があると思うんですよ。以前、評判になった「ボヘミアンと貴族の話」みたいな、つまり、硬いデータとスキーマも何もないデータとの中間のデータ、ちょっと柔らかいくらいのデータを扱うときにどうすればいいのか、という問題。この問題には実は、XML技術を扱ううえでの1つの鉱脈が隠されています。例えばスキーマ・エボリューションやスキーマの変更の話ですね。このような技術はいずれもRelaxerでは厳しいですね。

　スキーマ言語という観点では、アドホックなアプローチでは難しくて、数学的なきちんとしたアプローチでやっていかないと、どこかで破たんするのではないか、と思います。

◎参考： XMLにおける「ボヘミアンと貴族の階級闘争」を読み解く （XML & Web Services ）
◎参考： XML 1.1を巡る「ボヘミアン」と「貴族」の階級闘争 （＠IT News）

村田　ただ、Relaxerでも、後でだれかが、属性や要素を追加できるようにしておくと、ある程度現段階の問題は回避できるかもしれない。

浅海　僕がいま、考えているのは、ルーティング・ランゲージを使って、RELAX NG以外のスキーマがきたら、DOMで格納するなどの対応策です。

村田　「NRL（Namespace Routing Language）」というのは2つのスキーマ言語や2つのスキーマを併用するための仕組みです。簡単にいうと、エレメントを見て、名前空間がコレだったらこっち、コレだったらこっちというように、名前空間ごとにスキーマ言語なり、バリデータなりを切り替えるという仕組みのことです。

　「RELAX Namespace」を僕が日本で最初に作り、ISOに提出、ジェームズがそれを見て、「MNS（Modular Namespaces）」を作り、それに僕などがいくつかの変更を提案し、さらにジェームズがNRLを作成しました。今度ISOで、Final Committee Draftにしようと働きかけを行っています。

浅海　結局、RELAX NGもNRLも日本発で出てきた技術なんです。ジェームズ・クラークの力が非常に大きいとはいえ。

村田　少なくとも、われわれと関係ないところで仕様が決まっているわけではない。

浅海　最も濃い情報が一番初めに日本語で流通するIT技術というのはあまりないんですよ。しかし、XMLやRELAX NG関係では日本は強い。日本でエンジニアをやりながら、最新のIT技術の詳細を知るには、英語のドキュメントを読むか、英語のドキュメントを読んだ人から話を聞くしかないという構造になっていますよね。しかし、XML技術やRELAX NG技術を核にして新しい技術を開発していけば、日本にいながらにして、日本語で一番重要な技術が入ってくるようになる。ということは、世界に先駆けできる可能性が高いということですよね。しかも、僕が最初に述べた仮説（第1回参照）が正しいとすると、オブジェクト指向の開発方法論も含めて、いまのIT業界に地殻変動を起こす1つの鍵になる技術かもしれない。だから、日本の中でコミュニティを立ち上げるというのは、とても重要なことだし、面白いことになるんじゃないかな、と思います。

村田　XMLは日本でもいい教科書がいっぱい出ましたよね。日本人が書いた本が。これは、日本でXMLの立ち上がりが早かったことの1つの表れでしょう。

浅海　要するに、日本も世界と対等に勝負できている時期があったわけですよ、XMLでは。いまは欧米に追い越されてしまったかもしれないんですけど、とにかく、ある時点まではそういう状況だったわけです。なので、努力次第では、日本が互角にやっていけるような構造をもう1回作れると思いますよ。少なくとも、RELAX NGの情報に関しては、日本が一番早いし、（情報の質も）濃いんです。ここをベースにいろんな人のノウハウやスキルを足し込んでいく、という形でうまく育てていけば、日本発ですごく大きなマーケットもできるだろうし、技術としても大きく育つと思います。

　プログラマ的な観点から見ると、RELAX NGの方が圧倒的に使いやすいですよ。W3C XML Schemaを推奨している人たちの理由が知りたい。W3C XML Schemaは文法がめちゃくちゃ難しくて、少なくとも僕ぐらいの力では全然分かりません。最近少し分かってきたのは、無理やりオブジェクトにマップしようとして、すごい無理しているということです。普通のレコード定義くらいならできないわけではないですが、それでも、なんで、コレがここに入るんだろうっていう、意味の分からない文法があって、これはもうそのまま丸のみして覚えるしかない。考えだすと逆に分からなくなっちゃうんですよ。理解するのではなく、丸のみすれば書けるようになるという感じです。

原田　私は単純に仕様のページを見て、その量に圧倒されてあきらめました。でも、RELAX NGなら仕様書がそんなに大きくないですよね。チュートリアルも分かりやすいですし。

浅海　W3C XML Schemaが致命的に駄目だと思うのは、XML的にやりたいこと、肝心なことができないという点です。要素名のみで型を特定してしまうので、要素に格納されている属性などの情報によって別の型と判定するというようなことはできない。これはXML処理では割とよく使うパターンなんです。RELAX NGは簡単に書けるし、Relaxerも対応しています。結局W3C XML Schemaはやたらと難しい割には肝心なことには使えない、という困った仕様なんだよね。

（第3回に続く）

---

ラウンド・テーブル参加者 プロフィール

◆ 浅海智晴（あさみ ともはる） 　1985年立命館大学電気工学科卒業。同年富士通(株)入社。UNIXワークステーション/サーバのOS、分散基盤、Web基盤の開発に従事。2001年11月より浅海智晴事務所代表。現在はオブジェクト指向、Java、XMLを中心に活動を行っている。著書に「Java Super Tips オブジェクト指向設計編」、「XML/DOM Programming」（秀和システム）、「やさしいUML入門」、「Relaxer - Java/XMLによるWeb開発」、 「XML SmartDoc公式リファレンスマニュアル」（ピアソンエデュケーション）がある。代表作はJava&XMLベースのオープンソース・ソフトウェアであるXML SmartDoc(XML文書処理システム)<http://www.XMLSmartDoc.org>、Relaxer(XML/Javaスキーマコンパイラ)<http://www.relaxer.org>。 ◆ 平鍋健児（ひらなべけんじ） 　1989年東京大学工学部卒業後、3次元CAD、リアルタイムソフト、UMLエディタなどの開発を経て、現在、株式会社永和システムマネジメントでコンサルタントとしてオブジェクト指向開発を研究・実践。XPに関するメーリングリストXP-jpを運営、オブジェクトクラブを主宰。酒と映画と福井を愛する。翻訳書に「XPエクスストリーム・プログラミング 導入編」（ピアソン･エデュケーション）、「マルチパラダイムデザイン」（ピアソン･エデュケーション）がある。 ◆ 原田洋子（はらだようこ） 　1994年9月にWeb サーバ／Proxy サーバを自ドメインに立ち上げて以来、特にWeb サーバやインターネットの世界に興味をもつ。サーバサイドJavaとして後に名を馳せるようになったJava Servlet に巡り合い、Java に目覚める。現在はServlet&JSPを中心とするJavaプログラミングが本業である。著書に『Javaサーバサイドプログラミング』(技術評論社)がある。 ◆ 村田真（むらたまこと） 　1960年生まれ。1982年京都大学理学部卒業。W3C XML WGのメンバとして、XML 1.0の制定に携わる。編著書に「XML入門」（日本経済新聞社）。インターネットコンファレンス 98論文賞。国際会議WWW'99、PODDP 98、EP 98などのプログラム委員。国際ジャーナルMarkup Languagesの編集ボードメンバー。

IT Architect 連載記事一覧