本コンテストも第3回を迎えたが、今回は応募要項で『クライアント側の WWWブラウザだけで動作する作品はやや不利になる可能性がある』という一文 を掲載したため、第1回、第2回とはやや傾向の異なる結果となった。
第1回、第2回の中心的なコンテンツは、XML文書をウェブサーバよりそのま ま送信し、Internet Explorerに組み込まれたXMLパーサで処理を行うたクライ アントサイド処理であった。しかし、現実に世の中に浸透しつつあるのは、 XML文書をウェブサーバ内で加工して、HTML文書を生成して、それをウェブブ ラウザへ送信するサーバサイド処理である。クライアントサイド処理は、サー バ側に特別な機能を必要とせず、クライアント側にInternet Explorerさえあ れば良いので、チャレンジするハードルは低い。しかし、クライアント側のウェ ブブラウザの種類を制限する他、Internet Explorerに組み込まれているXMLモ ジュール(MSXMLと呼ばれる)のバージョンにも強く依存することから、利用者 本位とは言い難いものである。一方、サーバサイド処理は、ウェブサーバ上で ユーザー作成のプログラムを実行させることが必要であるため、多くのインター ネットサービスプロバイダでは実践することができない。専用サーバを持てる 企業ユーザーなら、それほど大きな負担ではないが、個人によるチャレンジに はハードルが高い。
そのような事情から、より多くのコンテスト応募者を募るためには、クラ イアントサイド処理だけの作品を広く応募することが最善であり、事実、第1 回、第2回は、クライアントサイド処理が大多数であった。しかし、間口を広 く取り、誰でもXMLを用いたコンテンツの作成が可能であることは、既に第1回、 第2回のコンテストを通じて十分にアピールされたと言える。とすれば、次に 考えるべきことは、よりハードルは高くなろうと、過去のコンテストでは見ら れなかった斬新な実現手法で構築された作品を求め、XMLの可能性の広さをア ピールすることである。そのため、『クライアント側のWWWブラウザだけで動 作する作品はやや不利になる可能性がある』という一文を掲載することになっ た。
これにより、応募作品は減ったが、完成度、実用性、斬新さなど、様々な 飛び抜けた特徴を持った作品が集まったと言える。応募された作品の多くは、 サーバサイド処理またはサーバサイドとクライアントサイドの両方で処理する 仕組みのものとなった。
応募作品は大きく分けると3つのカテゴリーに分けられる。
1つは、実用性を高めたもの。従来技術から大きく踏み出すものではないが、 これまでのコンテストによくあった技術デモンストレーションのレベルではな く、そのまま実運用しても良いほどの高い完成度を持つもの。このような作品 からは、XMLが既に手探りの段階を脱して、実用システムに一部に組み込まれ ている状況がよく理解できる。
もう1つは、より新しい技術を活用して、より新しい応用面を切り開こうと チャレンジしているもの。これらの作品からは、XMLという技術の可能性はま だまだ全て開拓されていないことが、ひしひしと伝わってくる。XMLには、ま だまだ様々な可能性を切り開く余地があると言って良いだろう。
最後の1つは、実績も乏しい現在進行形の最先端技術に取り組んだもの。こ のカテゴリーは、ただ単にある技術を使って見せただけで、特に実用性が優れ ていたり、斬新な応用を提案しているわけではない。しかし、まだ実績も乏し い最先端技術を使いこなすのは容易なことではない。その努力は評価に値する。 また、これから普及すべき技術を積極的にアピールしたことも、社会的な意義 がある。これらの点が審査員の評価を得た。作品「UDDI-BizFind : ビジネス 検索ツール」は、今後普及が予想されるウェブサービスにおいて、ネットワー ク上の様々なウェブサービスを検索する機能を提供するUDDIを取り上げた点で、 非常に有意義と言える。また、作品「大学数学テキスト」では、開発途上のソ フトであるmozillaとMathMLの組み合わせで、近未来の数式表現のあるべき姿 を示した点が意義深い。
さて、今回のコンテストはは、現在のXMLに取り組む層の厚さを反映してい ないことを最後に付記しておこう。興味も意欲もあるが、利用可能なサーバに 恵まれなかったために応募を断念したケースもある。今回の応募作品は、幸運 によって選抜された代表選手のみであり、可能であればエントリーされていた 更に多くの作品が背後に存在する。それらの作品の中には、きっと、入選に値 するものもあっただろう。その意味で、今回の応募作品、日本のXML界の一部 を切り取ったものでしかなく、より多くの可能性がまだまだ眠っていることは 想像に難くない。
本地域提供サービスは、電子地図、GISコンテンツの送受信にG-XML 1.0プロトコルを使用し、メインの電子地図上にユーザー、グループレベルでのGISサービス情報を重ねて登録を行ない、閲覧表示を行なうための作品である。
地図情報を格納したサーバとはG-XML 1.0にて通信を行い、サーバ、クライアント間にて地図データの送受信、ユーザーレベルの独自情報の登録、登録データの要求が行なわれる。 様々な団体は、独自のGISサービス情報を登録し、独自の情報として、重ね合わせて活用することができる。
背景の地図への各階層のGISコンテンツのマッピング、描画はクライアントサイドで行なわれており、描画にはSVGが用いられている。
電子地図アプリケーションとしての完成度としてはいま一歩ではあるのだが、公開されたG-XML 1.0にいち早く着目し、グループ毎に独自の地図情報を登録、管理できる様に設計した点を大きく評価した。
XML技術を単一化された情報形態、限定された範囲における情報共有に主眼をおいて用いるのではなく、インターネット上という広い情報空間の中における情報共有、独自情報との組合せ、多様なフィルタリングによって活用しよういう姿勢は、今後のXML活用の方向性を捉えたものである。
G-XMLプロトコルの技術的特徴は、複数のサイトから分散的に提供され る電子地図とGISコンテンツとをクライアント側で合成して扱えるところ にある。本作品はこのG-XMLのコンセプトを「地域情報提供サービス」 という形でわかりやすく提示し、利用者や市民グループもまたGISコンテ ンツの情報発信者に容易になれるのだということを示して見せた点で、 G-XML応用のお手本ともいうべき作品に仕上がっている。
本作品ではさらに、電子地図の表示に際してG-XMLのデータをSVGへと 変換している点が特徴となっている。これにより、Abobe SVG Viewer Plug-inをインストールしたWebブラウザであれば、ズームやスクロール といった表示操作もサーバとのやりとりを介さずに快適におこなえる。 少なくとも原理的にはそうなのだが、実際には本作品では従来からの一 般的な地図サービスの操作方法を踏襲しているため、こうした操作性の メリットを活かせなかったことは残念である。
現在W3C SVGワーキンググループでは、携帯機器用のSVG Mobile仕様 を策定中であるが、電子地図はその代表的な応用シナリオのひとつだと 言われている。しかしながら、SVGを地図情報サービスで便利に利用で きるようになるためには、座標系や選択や単位の変換、レイヤの扱い、 ズーム不変サイズの実現など多くの課題をこれから解決してゆく必要が ある。本作品は、こうした課題を考えてゆく上でのモデルケースとして も非常に貴重であり、新しい標準規格の応用にタイムリーに取り組んだ 意義は大きいとして一席に評価した。
講評（村田真）
retotoは、totoの購入データを格納したSQLデータベースにWWWブラウザからア クセスするための作品である。こう書くと面白くない作品のように聞こえるか も知れない。実際，ちょっと見ただけでは、この作品の凄さは分からない。 この作品の優れている点は、その実装方式にある。
本実装方式は，「はじめにXMLとRELAXスキーマありき」である。RELAXスキー マから，関係データベーススキーマ，Javaクラス，関係データベースとJavaと の間を接続するプログラムをRelaxerによって自動生成している。また、WWWブ ラウザにXML文書として情報を送ることによって、WWWブラウザでの対話的な表 示を可能にしている。言い換えると，XMLを中心に据えることによって，関係 データベース、WWWサーバ，WWWブラウザの連携が容易になっている。
スキーマコンパイラRelaxer自体は浅海氏の手になるものだが、応募者は redetotoという作品として提示することによって、XMLを使うことの利点（と くにスキーマコンパイラRelaxerの利点）を分かりやすく示した。その点を評 価し、二席として表彰する。あえて欠点を挙げると，動作の安定性，実行の遅 さ，JSPページに埋め込まれたJavaScriptの読みづらさなどがある。