半構造データ、あるいは Web 上のデータ

» Permanent link | |

国島先生や斉藤先生が XML や半構造データについていろいろ書いてくださっており、それに反応する形ではてなブックマークや twitter 上での議論が日本語で進んでいて面白い。

• http://kunishi.blogspot.com/2008/12/twitter.html
• http://leoclock.blogspot.com/2008/12/relational-style-xml-query-sigmod-j.html
• http://kunishi.blogspot.com/2008/12/xml-db.html

ブックマークや twitter で細かいコメントを書いているだけでは申し訳ないような気がするので、久々にエントリを書こうとしたのだけれど、なんだかバックグラウンドが長くなってしまった。最先端の研究者のみなさんに失礼な物言いもありますが、XML guy としては XML の話題は釣られるものなのでご容赦ください。

個人的なバックグランド

僕の個人的なコンピュータの原体験は、当時電電公社に勤めていた伯父からもらった PC-8201 である。これはいわゆるハンドヘルドコンピュータで、僕はこれを80年代後半に手に入れた。すでに世の中の流れからは置き去りにされてしまった悲しいコンピュータだったが、N82 BASIC が40文字×8行の液晶で動作して、プログラミングができた。

僕が作ったプログラムは F1 データベースで、歴代のチャンピオンがファリーナ/ファンジオからプロスト/セナまで検索できるものだった。このプログラムはデータとコードと画面がぐちゃぐちゃに入り混じった大変格好の悪いものだったが、それでも自分が書いたプログラムが動作する快感を知ることができたし、何より自分の中では実用的だった。

Web との出会い

PC-8201 のあとはプログラミングへの興味は薄れ、 PC-9801 RX21 でゲーム(A列車で行こうIIIはやりまくったなあ)をしたりしていた程度だったが、94年に大学に入学し、その年の暮に「インターネット」の存在を知り、年明け早々に大学ネットワークのアカウントをもらったことでコンピュータ熱が再燃した。MLも入りまくったし、ネットニュースもさんざんチェックしていた。SunOS4 の上で、NCSA httpd 経由の CGI (JPerl4)でご多分にもれず掲示板を作ったりもしていた。

こんなことを書いてるとおまえは情報系の学生だったのではないかと思われるかもしれないけれど、僕はれっきとした機械工学の学部生で、卒論はロボット(特にScara)のシミュレーションを OpenGL でやっていたりした。

NAIST へ

ロボットの研究はとても面白く、研究室も居心地がよかったのだけれど、一方で自分の中では Web、特にマークアップ言語・構造化文書としての SGML/XML への興味が非常に大きくなってきたため、当時 XML を研究対象にしていた数少ない研究者のおひとりである当時 NAIST (現京大)の吉川先生の研究室に行くことにした。幸い NAIST は大学院大学という特性もあり、情報系以外の学生にも手厚く教育をしてくれ、おもに M1 のときに僕はデータベースシステムについて学んだ。

XML への熱い期待

当時(90年代後半)の XML 業界はある種異常な雰囲気に包まれており、当時世間知らずの田舎学生だった僕の目から見てもアヤシゲなベンダーやコンサルが入り乱れていた(日本国内も、米国も)。それでも毎日 W3C TR のページは必ずチェックし、xml-dev/xml-user を購読し、暇さえあれば XSL(T) のアップデートを追随する毎日を送っていた。

XML勧告直後からは、村田さんという偉大な存在があったこともあり、日本国内でも XML コミュニティが立ち上がった。XML開発者の日というイベントは、昨今の勉強会・カンファレンスブームのさきがけだったと思う。そして、僕はそのコミュニティである程度のポジションを得ることができて、世の中にはすごい人がいるということを実感した。

XML を使う

当時から今まで、僕の基本的な興味のスタンスは変わっていない。僕にとって XML はあくまでも応用ありきである。もちろん基本知識として XML 1.0 のスペックは抑えなければいけないし、最低限 DOM/SAX/XSLT (今なら XQuery か)を使って XML 処理を行えなければならないが、しかし仕様をいくら知っていても、変換プログラムがいくらあっても現実の世界では役に立たないのである。XML で最も重要なのは XML インスタンス、XML 文書そのものであり、スキーマや各種 API はそれを便利に使うための補助ツールでしかない、という意識が僕にはある。

では僕にとって重要な XML 応用は何かというと、当時でいえば XHTML であり、現在はそれに Atom/RSS と microformats が加わったくらいである。もちろん必要であれば docbook を使うし(Markup Technologies99(XML99併催)の論文は docbook で書いた、というより書かされた)、ODF や OOXML も使うのだけれど、自分の中で重要なのは簡単にいえば XHTML と Atom なのである。これは言い換えると Web 上で流通するデータである。

Web とデータベースとデータベース管理システム

Web はデータベースか? この問いに対する答えは人によって異なると思うけれど、僕の答えは簡単だ。Web はデータベースである。しかし、Web はデータベース管理システムではない。

Web には集中管理機構はない。Web はその名の通り世界規模の分散システムであるが、そのアーキテクチャは集中的な管理機構で守られるのではなく、統一インターフェースとアドレス可能性というアーキテクチャスタイル(制約)で形作られている。

つまり Web 上のデータというのは、管理システムの制約から解放され、(RESTの制約にさえ逆らわなければ)自由にただデータとして振る舞うことができるのである。ここが RDBMS 中に格納されたデータと Web 上のデータの一番の違いだと思う。

Web 上のデータは、あらゆるプログラムから独立して生き延びることができる。Web 上のデータはプログラムによって性格を変える。Web アプリケーションを作る人と、検索エンジンを作る人、フィードリーダを作る人が独立して作業を行えるのは、Web上のデータがプログラムから独立しているからである。

データの天動説

XML の最も革新的な一面をあげるとすれば、僕は真っ先に整形式を許したことを挙げたい。XML ではスキーマが明示的に存在しなくても、プログラムからデータを利用可能になったのである。XML 文書に固定的なスキーマはない。これは逆に言うと、一つのXML文書に複数のスキーマを適用してもいい、ということになる。

一つのXML文書に複数のスキーマを適用できるとどうなるのか。それぞれのスキーマごとに、一つのXML文書が違った顔を見せるようになるのである。たとえばあるフィードリーダから見ると単純にサイトの新着情報を通知してくれていたAtomフィードが、OpenSearch 拡張を解釈できる検索アプリから見ると検索結果一覧に見える、といった具合である。

これはすなわち、XML文書はアプリケーションプログラムから独立しており、それはつまり Web 上のデータが持つ特性そのものである(整形式と名前空間でその特性をエンハンスしている)。

Data on the Web と半構造データ

「Web 上のデータ」とさんざん言ってきたのだが、わかる人にはわかると思うけどこれは "Data on the Web" なわけである。僕の意見がどれくらい Abiteboul 先生の意思と被っているのかはわからないけれど、彼の最初の半構造データ論文が "Querying semi-structured data" であり、"Managing semi-structured data" ではなかったのは何かを暗示しているような気がしてならない(単なる思い込みかもしれないが)。

半構造データとは Web 上のデータであり、原理上 Web 上のデータは集中管理できない。なので単一の「管理システム」は存在するはずもない。逆に言うと単一の管理システムで管理できるような XML データは半構造データの文脈を持っていない XML データなわけで、そのようなデータは本来のモデルに基づいて管理するのが正しい姿だと思われる。

REST の勝利宣言と良い XML の見分け方

» Permanent link | |

ITpro Challenge 行ってきました。

豪華なメンバーでどの講演もとても面白かったですね。 江島さんの講演は、Web 上でサービスをやるとはどういうことなのかについてとても示唆に富んだ話だったし、 鵜飼さんのハッカーのソフト工学の話は職場的にすげータイムリーだったし、 なおやさんの話は同時代を生きてきた、生きている者としてとても共感できる内容だったし、 戀塚さんはこれぞハッカーという感じのすごい人でした。

僕は LT の最後に話をさせてもらったわけですが、 ネタを二つ持っていって聴衆のみなさんに選んでもらうことにしました。

結果は REST が勝ったので、当初の予告どおり REST の話をすることに。

結局お蔵入りになった XML の話ですが、もったいなかったので懇親会でお話させてもらいました。

プレゼン中で引用した Web ページはこちらです。

檜山さんの記事

• XML ボキャブラリのデザインパターン
• XML ボキャブラリのアンチパターン

Tim Bray の記事

• Don't Invent XML Languages
• 日本語訳: もう XML 言語を開発するな

リンクは重要ですよ。

XML の本当のメリットは拡張性を保証して構造化文書もマークアップできること

» Permanent link | |

デジャビュを感じる。

XMLの「本当のメリット」ってなに？

Matzにっき XML のメリット、デメリット

XML の仕様には歴史的・政治的理由でいろいろと不満な点があります。 これは XML をやればやるほど感じるものです。 しかし、拡張性を保証して構造化文書もマークアップしようとすると 選択肢は XML しかないのもまた事実です。

ということで、

• 構造のあるデータが書けること(すずきひろのぶさん)

  別にS式でもYAMLでも書けますよね。拡張性のあるテキストのマークアップという意味(テキストが主、マークアップが従)ならSGMLの系譜を否定しませんが、データ記述や設定ファイルにまでとなると話は別です。

Matzにっき XML のメリット、デメリット(追記より)

結局はここに落ち着くのではないでしょうか。 XML というメタ言語の設計が構造化文書のマークアップに寄っているので、 データ記述や設定ファイルに使うとどうしても冗長性が鼻についてしまいます。 つまり用途によっては XML が最良の選択とはなりえないと僕も思います。 (参考: 檜山さんによる JSON と XML の比較)

あと「野良XML」のほとんどが名前空間を使っていない云々というのは 単なる印象っぽいので、どのくらいの割合で使っていないのか不明なんですが、 仮に名前空間を使っていない野良 XML であったとしても 将来的には名前空間を使って拡張することが可能になることは忘れてはいけないと思います(例: RSS 2.0)。

Open Data が叫ばれる昨今、Web 上を流通するデータフォーマットでは この拡張性というのは非常に重要な概念なのでやっぱりX重要

本3冊

» Permanent link | |

しばらく時間が空いてしまいましたが、最近気になった本を3冊紹介します。

まずは Flickr の中の人、Cal Henderson の Building Scalable Web Site。

REST が設計思想からスケーラビリティを攻めているのに対し、この本は実践からいかにスケーラブルなサイトを構築するかを攻めています。 似たような話は古くは LiveJournal の中の人から、 Flickr の中の人まで、 さらに最近は mixi の中の人や はてなブックマークの中の人 (ビデオ)、 ライブドアの中の人まで さまざまなテクニックや経験則を公開してくれていて、まさに高速道路建設中なわけですが、 この本はその高速道路のひとつの出口になるんじゃないでしょうか。 ぜひ日本語版もほしい一冊だと思います。

Building Scalable Web Sites
Callum Henderson Cal Henderson

2冊目はデータ工学の研究者なら誰でも知っている Data on the Web の翻訳、「XML データベース入門」です。

訳者の国島先生は僕も知り合いですが、日本でまじめに XML 関連の研究をなさっている研究者のお一人です。 国島先生の翻訳解説エントリにもあるとおり、 かなり丁寧に翻訳さている印象です。特に XML の解説の章の訳注の入れ方は半端じゃないです。

本書で扱われているトピックは半構造データ(semi-structured data)、特に XML のデータモデルとその問合せ処理についてです。 いわゆる学術書なので、自分には関係ないと思う人も多いかもしれないですが、 現在一般に扱われているデータ RSS, Atom, JSON なんてのはまさに半構造データなわけです。 そういったデータをいかに蓄積し、検索するか。 そんな問題を考えている人は手にとってみるとよいかもしれません。

ただ、一点だけ気になったのは、キーワードが日本語オンリーなところ。 英語も併記してもらえると、特に初学者には理解が進むと思いました。 もし訳語リストがあれば、公開していただけませんか＞国島先生。 2006-08-01 追記: コメント欄で索引に訳語リストがあることを教えてもらいました。

XMLデータベース入門
Serge Abiteboul Dan Suciu Peter Buneman

最後は翔泳社の Web 2.0 キーワードブックです。 これは僕もお手伝いをしました。REST の章を書いてます。 たぶん、これまで書いた REST の解説の中で一番コンパクトにまとめたものになっています。 あまり Web 技術に詳しくない人にも理解できるように、なるべく平易な記述を心がけたつもりです。

Web 2.0 という言葉はすでに陳腐化してしまった感がありますが、 ギークのそういった気分もいくらか取り込まれていて、特に切込隊長のエピローグには思わずニヤッとしました。

それにしても、献本をもらうまで著者陣を知らなかったのですが、かなり強力ですね。 個人的には自分の原稿がまつもとさんと村田さんの間だった のに感動しました。

Web2.0 キーワードブック
SE 編集部

Windows Vista の RSS パーサは Well-formed XML のみサポート

» Permanent link | |

Dare Obasanjo の blog で知ったんですが、 Microsoft Team RSS Blog より

Our years of experience in with HTML in Internet Explorer have taught us the long-term pain that results from being too liberal with what you accept from others. Hence, we’ve adopted the following overriding principle for IE 7 and RSS platform in Windows Vista: 

 We will only support feeds that are well-formed XML.

This principle allows us to build a more predictable feed parser. As a platform, it's important that applications using the platform to consume feeds can rely on the fact that the platform will always be providing information in the way that the publisher intended (trying to guess what a publisher meant to do when there is an error in a feed can be tricky, at best). We also spoke to several people in the RSS and developer community at Gnomedex and at PDC, and they wholeheartedly supported this.

IE7 と Windows Vista の RSS パーサは整形式(well-formed)の XML だけをサポートすると。 現在世の中で流通している RSS フィードがどれくらい well-formed なのか知らないのですが、 英断だと思います。

microformats などの設計についていろいろ

» Permanent link | |

僕が提案した方法についておのひろきさんからツッコミが入り、 microformats を誤解している、マークアップする力の問題である、と批判されました。

まー実際、microformats を誤解しててマークアップする力もないかもしれないんだけど、 おのひろきさんの主張には賛成できないので、ここでまとめて反論しときます。

まず、「microformats についての誤解と，ぼくが理解している範囲」より。 前半の microformats の説明は特に異論はありません。 でもそれがなんでいきなり

それでさらに microformats であるなら，一度「意味付けと記述書式」を決め たら，それが他での使い回す事ができないと意味がありません．限定された問 題を解ければ良いとはいっても，特定の問題にしか対応できないほど限定して たら駄目なのです．

ってなっちゃんでしょう?(強調筆者) ここがまずわからない点。

rel 属性値は profile で定義してそこで意味付けをします．上の例では a 要素で rel 属性値 hatenab とある場合は href が指す URI ははてなブックマークであるってことになるのかな?

元記事では、主題が別だったので詳細なプロファイルまで書いてませんが、 リンク形式 rel="hatenab" は、リンク先が元ページの著者のはてなブックマークへのリンク、という意味です。 目的は「自分が使っているサービスを宣言」するため。

profile を定義するということを意識していないから rel 属性値をどうするかというところで間違えるのではないでしょうか．profile を定義することと，その profile が他で応用できるようにするということを考えないとダメだと思うのです．

最後のここもいまだにわからないんですよね。 rel を拡張するなら profile (microformats なら XMDP) が必用、というのはわかってるつもりです。 でもそれと、「他で応用できる」ってどう関係があるんでしょうか? たとえば XFN は友人関係を記述する以外にどう「他で応用できる」んでしょうか?

続けて「マークアップする力」より。

檜山さんの記事を引用して

「邪悪マークアップは先進的マークアップか？」から引用すると:

これがまずい理由は、<田中>元気で行ってこい。</田中>や<ミヨ子>おみやげ、忘れないでねぇ</ミヨ子>のあいだに共通性があるのに、その共通性がマークアップにより表現されてないことです。

これと同じ事が rel="hatenab" と rel="delicious" にも言えると思うのです．

と書いていますが、同じとは言えないと思いますよ。

おのひろきさんは Semantic Web に詳しいようなので釈迦に説法かもしれませんが、 rel 属性と class 属性の仕様上の違いをまず再確認してください。 rel は「リンク形式(のリスト)」、 class は「クラス名(のリスト)」です。 リンク形式(link type)がリンクの関係性を表現するのに対し、 クラス名は (X)HTML 要素の分類に用いるものです。

いわゆる microformats ではこの二つをちゃんと使い分けていて、 rel 属性は (X)HTML の仕様どおり、リンクの関係性を表現しています。 そのリンク先がライセンス文書であると指定したり、 リンク先のコンテンツがリンク元とは関係ない(follow してない)と指定する、などです。

一方で class 属性は XHTML に vCard の構造を埋め込んだり、 iCalendar の構造を埋め込んだりするのに使います。 クラス名が構造情報と対応しているわけです。

ここまでで明かだと思いますが、 檜山さんの記事に出てくる「多重マークアップ」は class 属性の応用の話です。 対して、ここで議論しているのは rel 属性の値(リンク形式)をどうするか、という話です。檜山さんの例を引けば、

<寄せ書き>
 <ひとこと 誰="田中">元気で行ってこい。</ひとこと>
 <ひとこと 誰="ミヨ子">おみやげ、忘れないでねぇ</ひとこと>
 ...
</寄せ書き>

ここで言う 「誰」属性の値は「田中」がいいのか「id:tanaka」がいいのか 「上司」がいいのか「社員」がいいのか「男」がいいのか「日本人」がいいの か「人間」がいいのか「哺乳類」がいいのか「動物」がいいのか「生物」がいいのか… って話と同じですよ。

だから、

つまり rel="hatenab" と rel="delicious" の間に共通性があるのに，その共通性が表現されていないのです．それは，書き手の頭の中だけにあります．

これは勘違いではないですか。 上記のとおり、リンク形式に指定する値の粒度をどれくらいにするかというのを議論してるんです。 その値の定義は、おのひろきさん自身が言っているとおり「profile によって定義するっていう手」を使います。

profile によって定義するっていう手もありますが，そうすると似たようなサービス全てについて profile で定義を用意しなければなりません．そうではなくて rel 属性では共通性の部分を表現するべきでしょう．

別に「似たようなサービス全て」を定義しなくてもいいんじゃないでしょうか。 プロファイル策定者がはてなだったら hatenab, hatenaa, hatenai, hatenad,... と自社のサービスを定義すればとりあえず十分でしょう。 これで、あとは API さえあれば、今閲覧している Web ページの作者のはてなブックマークを自分のお気に入りに入れるブックマークレットとか、 その人が使っているはてなのサービス一覧を小綺麗に表示する greasemonkey スクリプトとかが作れそうです。

ただ、一利用者の感覚とすれば、hatenab じゃなくて del.icio.us も使いたいんですよね。 でも del.icio.us には inbox はあっても「お気に入り」はない。 こんなかんじで hatenab と delicious を区別したいニーズはあります。

これについておのひろきさんは

rel="hatenab" とある場合とない場合で，メタデータの抽出の仕方がどう変わるかを考えたら，あまりrel="hatenab"ってのは有効ではないのでは? hatenabにマッチングするか b.hatena.ne.jp にマッチングするかの違いだか ら．

という見解のようですが、 僕はまったく逆ですね。 URI でマッチングしなきゃいけないような設計は悪い設計の代表例だと思います。 何で悪いかの理由のひとつは shckor さんがいうとおり URI がやむを得ず変わる場合ですね。 REST とか、疎結合の文脈で言えば、クライアントとサーバのお約束が増えてしまうという意味で悪い設計です。 せっかく rel 属性があるのに、関係ないところで URI のコンベンションを作るのは余計な制限を増やすだけだと思います。

ちなみに、はてなや del.icio.us のドメイン名は安定してそうなのでまだいいですが、 たとえば、サーバインストール型の Web アプリケーションだったり、 社内向けサーバで、どうしてもドメイン名を変更しなければならなかったりしたらどうするんでしょうか。 たとえば pukiwiki にソーシャルブックマークプラグインができたとしたらどうしますか。

<link rel="onlineBookmark delicious" href="http://del.icio.us/onohiroki"/>

ってのも良くないと思います．"delicious" ってのを profile で定義しなくちゃならないから．それなら "delicious" を与えるのは title 属性が良いと思うし，profile を定義しなくても良い class 属性のほうが rel 属性よりはまだ良いと思います．

上記のような理由から rel 属性の代わりに class 属性を安易に使うのは反対です。 rel には rel の意味があるのだから。

ここまで書いて、「class 属性を再発見」というエントリが追加されているのを発見したんで、 ついでにこちらにも若干コメントを。

最初に定義していなかったものを後から追加したくなったら，別 profile を作るのでしょうか? この問題をどう考えているのかはぜひ教えてほしいです．

同じプロファイルに新しいサービス名を追加してバージョンアップします。 もちろんこれは XML のスキーマのバージョンアップ問題と同じ話で、 いろいろと難しい問題を含んでいるのですが、 どこに追加される可能性があるのかはっきりさせる、 新しいものを追加しても問題が起きないようにクライアントを作る(知らないサービスは無視するか、知らないサービスとして扱う)、 追加するだけならバージョンを上げなくてもいい(プロファイルの URI を変更しない)、 といったような設計が 2005 年の現時点では理想的かつ現実的な設計でしょうね。

shckor さんや yohei さんが言っている事がちゃんと理解できたら title 属性とかぢゃなくて class 属性ってすぐに出てこないとおかしいですよね．いや，未だに shckor さんや yohei さんの主張でよく分からないところがあるけど．

僕は以前にも title 属性は助言情報なのだからコンテンツ作成者の自由にさせるべきという意見を書いたとおり、 title 属性の安易な濫用はお勧めしません。 上記のとおり rel から class への安易な鞍替えも同様です。

Web らしく URI で連携する方向

» Permanent link | |

前のエントリで触れた ID だけのディスカバリの問題点ですが、 他にもこんなのもあります。

僕が自分のブログにはてな ID を埋め込んだとして期待するのは、 ブログを訪れた人が自分のブックマークやアンテナを見に来てくれたり、投げ銭してくれたりすることです。 でも僕がはてなで何を使っているかは僕にしかわかりません。 僕の場合はてブとはてアは使ってるけど、 はてダは更新を止めちゃった、はてフは知らん、という状況です。 もしかしたらアサマシは嫌いだから投げ銭してほしくない、という人もいるかもしれない。

これって「はてなID」の埋め込みだけでは実現できません。 自分ははてなのこのサービスを使っているよ、という主張をできないからです。

ではどうするか。 自分ははてなのこのサービスを使っているから見に行ってね、という宣言をしたらどうでしょう。 head 内で宣言するんだったらこんな感じ。

<link rel="hatenab" href="http://b.hatena.ne.jp/yohei" />
<link rel="hatenaa" href="http://a.hatena.ne.jp/yohei" />

body 内部で a タグに書くのであればこんな感じ。

<a rel="hatenab" href="http://b.hatena.ne.jp/yohei" >はてぶ</a>
<a rel="hatenaa" href="http://a.hatena.ne.jp/yohei" >はてあ</a>

ここまでくると、別にはてなに限らないでもいいのではないかという気がしてきます。 たとえば僕の場合、使っていると宣言したいサービスは

• hatenab
• hatenaa
• flickr
• bloglines
• delicious
• mixi
• blogger

なので、head はこうなります。

<head>
  <link rel="hatenab" href="http://b.hatena.ne.jp/yohei" />
  <link rel="hatenaa" href="http://a.hatena.ne.jp/yohei" />
  <link rel="bloglines" href="http://www.bloglines.com/public/yamamotoyohei" />
  <link rel="flickr" href="http://www.flickr.com/photos/60043209@N00/" />
  <link rel="delicious" href="http://del.icio.us/yohei" />
  <link rel="mixi" href="http://mixi.jp/show_friend.pl?id=173690" />
  <link rel="blogger" href="http://yohei-y.blogspot.com" />
</head>

a タグだったらこうなります。

<a rel="hatenab" href="http://b.hatena.ne.jp/yohei">僕のブックマーク</a>です。
<a rel="mixi" href="http://mixi.jp/view_profile.pl?">mixi</a>も使ってるよ。
<a rel="payment hatenagesen" href="http://nagesen.hatena.ne.jp/yohei">投げ銭</a>よろしく。

この rel= はいわゆる microformats ですね。 link タグなら Atom feed にも同じように入れられます。

rel 属性の値が各サービスごとに違うのがいいのか、 もっと別の値がいいのか、そもそもこんなことがやりたいのか、やっていいのか、という話はありますが (^^; URI で繋がるという方向性もある、ということを認知してもらえたらと思います。

そもそも ID を見つけるだけで十分なのだろうか

» Permanent link | |

なんか複雑な方向になってきたなーと思っていたところで風邪を引いてしまって寝込んでいたので、なんだか浦島太郎状態ですが、思うところを。

今の暫定仕様は僕にとってはちょっと違う方向のように感じるんですね。アカウントの ID だけを渡すというのは、関数のパラメータの一引数を渡すというのに繋がる気がするからです。

そもそも naoya さんがやりたかったことは

まずそもそも僕が考えた仕様は...という前にまず何をしたいかを明確にしないとですね。僕がしたいのは、はてなダイアリーを含めたインターネット上のウェブページ (Permalink) から、そのページを作った人の「はてなのID」を探し出したい、ということです。

ですが、では ID を探し出して具体的に何をするんでしょうか。 もちろん、はてなのサービスの中の人はいいと思います。 HTML や RSS/Atom を取ってきて、その中にはてなIDがあれば、その ID からユーザを特定していろいろできる。 でも Web 2.0 的に考えるなら、はてな外の Remix する人の事も考えてほしい。

そんな Web 2.0 的な Hatena ID Auto Dicovery の応用に、 吉松さんが触れていました。

僕は「投げ銭」に特化しないほうがいいなあ、と思ってます。例えばツールバーに「この人のはてダに移動」とか「このひとのはてブお気にを一覧」とかいうボタン作るのに役立ちそうだな、と思うもので。

なるほど。確かに便利そう。 とある Web の記事や RSS/Atom フィードを表示すると、 はてなツールバーや Greasemonkey スクリプトでその人のはてなブックマークへのリンクがポップアップしたら楽しい。 実際のコード(の断片)は例えばこんな感じかな。

var hatenaid = getIdFromRdfFoaf("http://www.hatena.ne.jp/");
document.write("<a href='http://b.hatena.ne.jp/" + hatenaid + "'>?B</a>");

うーん、嫌だ。

嫌な点の一つ目は "http://b.hatena.ne.jp/" という文字列をクライアント側で持っていて、ユーザ名と組み合わせている点。 これをやってしまうと、b.hatena.ne.jp を変えたり、URL の構造を変えたとたんに 途方もない数の全クライアントを一斉に変更しなければならなくなってしまう。 いわゆる密結合の一番悪いパターンですね。

もちろんはてなのドメイン名や URI の構造がそんなに簡単に変化するとは思いませんが、 一般的にはやらない方がいいことです。

それからもうひとつ嫌なのは JavaScript で getIdFromRdfFoaf() を作るのが大変そうなところ。 コメントアウトされた RDF/FOAF の文字列を「わざわざ」探し出して、さらにそれをパースして、RDF のトリプルにして…、 とやるのは想像するだけで鳥肌が立つ(のは僕だけかな)。

HTML に ID を埋め込む、というのは一見するとすごく汎用的で何にでも使えそうなんだけど、 汎用的であるが故に何をやるにも中途半端になってしまう危険性があります。 もう少し実用的な使い方をいくつか模索したり組み合わせたりして、 その中で汎用的に使える部分を探すという方がいいのではないかと思います。

では具体的には何なのだ、という話は次のエントリで。

Hatena ID Auto-Discovery について

» Permanent link | |

昨日は SIGMOD-J の大会に行った後にアルファギークなお二人と食事をしてきました。

大会ではやはり naoya さんの Web 2.0 についての話が一番面白かったです。 周りにいた人の反応も一緒でした。

ちなみに僕は naoya さんは初対面。 食事に途中参加の高林君とはちょうど4年ぶりだったことが今判明。オリンピックみたいだ:-)。

naoya さんは普段から blog やブックマークを見ているので、ぜんぜん初対面な気がしなかったんですが、 僕としては REST だの Folksonomy だの microformats だのといった単語をガンガン喋ったり聞いたりするのが新鮮かつエキサイティングでした。 やっぱり直接会って話すのは大切だと実感です。

以下本題です。僕は話題に出遅れてしまったんですが Hatena ID Auto-Discovery について。 naoya さんには直接喋ったんだけど、 酔っ払っててよくわからなかったと思うので、 もう一回ここに書いておきます。

まず、現状の仕様はこうですね。

<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
<link rel="DC.creator" title="id:naoya"
  href="http://www.hatena.ne.jp/user?userid=naoya" />

で、僕が提案するのはこれ。

<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
<link rel="DC.creator" href="http://www.hatena.ne.jp/user/naoya" />

二点提案があります。

最初は title 属性について。 例では title="id:naoya" となっていますが、 別にこれはなくてもいいのではないでしょうか。 DC の creator は href 属性で指定される URI で識別されるのであって、title 属性はあくまでも便宜上の助言的情報。 ならば、title 属性の内容はコンテンツ作成者に委ねた方が自由度が上がる、と考えられます。 もちろん id 記法が好きな人は title="id:yohei" としていいし、 そうじゃなくて title="YAMAMOTO Yohei" としてもいいし、 title="このページの作者のはてなIDです" とかしてもいいわけです。

次に href でリンクする先の URI についてです。 ひとつは ?userid=naoya というように、query string を使うのはどうだろう、という話。 もうひとつはこの URI が適切なのか、という話です。

こういう ID としての URI に query string が入っているとちょっとクールじゃないですね。 文字列長も長くなっちゃうし、何より query string はクライアント側でいじれる所がいかにも密結合的です。 ま、このケースはそんなに気にすることはないんですが、 僕のこれまでの感覚だと、はてなは URI がいつも綺麗だという印象があります。 はてならしさを維持するためにも、ここは query string を使わないほうがいいのではないでしょうか。

あとはリンク先の妥当性です。 はてなダイアリーの id 記法でリンクする先はそのユーザのダイアリーですよね。 その観点から id 記法との整合を考えると、ダイアリーを持っているユーザの場合は、 ダイアリーにリンクするのが最も適切ではないでしょうか。 ダイアリーを使っていないユーザはどうするのかという問題が残りますが、 それも id 記法でのリンク先にあわせるのがいいのではないでしょうか。

ということで、最終的には以下のような形になりました。

<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
<link rel="DC.creator" href="http://d.hatena.ne.jp/naoya" />

CDF を…覚えていますか?

» Permanent link | |

CDF を覚えている人はいるだろうか。

たとえば このファイル をダウンロードして、デスクトップに保存してみてほしい。 Windows を使っている人なら、アンテナのアイコンが現われるはずだ。

ためしにダブルクリックしてみよう。 あやしげなダイアログボックスが表示されるだろう(キャンセルしといてね)。

右クリックしてみよう。 いっぱいメニューが出てくるはずだ。

エディタで開いてみよう(「右クリック→編集」でもよい)。 タグ名が大文字の見なれない XML ファイルである。

これは XML の創世記に話題となった Channel Definition Format (CDF) だ。

覚えていない人、あるいはそもそも知らない人のために解説すると、 CDF は XML の最初のアプリケーションとして 1997-1998年当時に大変注目されていた技術である。 タグ名が大文字なのも、当時としては普通のことだった(あのころ僕たちは HTML のタグを大文字で書いていた)。 村田さんの「XML 入門」(この本が書かれたのは'97年で XML の勧告化前)でも、 XML の応用例として最初に CDF が登場している。

この CDF はプッシュ型 Web キャスティングのために開発された規格である。 プッシュ型 Web キャスティングというのは、 ユーザが Web ページをいちいちチェックしなくても、 CDF 対応クライアントが CDF ファイルを定期的にチェックして、 更新があったときだけ通知してくれる機能のことだ。

鋭い人ならもう気付いている思うが、 この機能は現在我々が RSS でやっていることと、基本的には全く同じなのである。

当時、現在の RSS リーダーはまだ一つもなかった。 ではいったい何で CDF を受信していたのか。 それは PointCast (あー懐しい)や Windows の ActiveDesktop あるいは IE 4.0 などだ。 PointCast はもうとっくに廃れているけれど、 Windows や IE はまだ現役なので、 我々のデスクトップにアンテナアイコンを表示してくれるのだ。

---

(hr タグを使うのも久しぶりだなあ…)

さて、なんで今さら CDF の話をしたのかというと、 naoya さんのこの記事を読んだからだ。 いわく、一度はキャズムを越えられなかった RSS が、 blog という最良の伴侶を見つけてキャズムを越え爆発的に普及した、ということである。

技術的にはそんなに違わないのに CDF はキャズムを越えられなかった。 当時でも CDF を理解して PointCast を使っていたのはギークだけだろう。 それ以外の何万(もっとかな)のユーザは CDF なんて知らずに PointCast で天気予報と朝日新聞を見ていたのだ。 でも CDF は死んだ。

RSS も粘って粘ってやっとキャズム越えた。 blog ツールによりすべての人々が RSS を提供できる仕組みができたからだろうか。僕にはわからない。

コンセプト/アイデアはいいのに死んでいった技術の中にも、 復活するものがあるのかもしれない。 ただし、復活させるには駄目になったときとは違うグループがやる必用がある。 たぶん。

冒頭の CDF は Sam Ruby さんのものです。

Alpine

» Permanent link | |

前のエントリの続き。

同論文では Alpine の設計目標が提示されている。

1. Stay in the XML space as much as possible.
2. Take advantage of as much leading edge infrastructure as we can.
3. Adopt the the handler chain pattern of Axis/JAX-RPC.
4. Target SOAP 1.2 (POST only, WS-I Basic Profile 1.1)
5. Document/literal mssages only, not RPC/encoded.
6. Support XSD and Relax NG schemas.
7. Run server-side, client-side, and as an intermediary.
8. No support for JAX-RPC or JAX-M/SAAJ APIs.
9. Configurable procedurally, through the Java Manage- ment API (JMX).
10. Permit dynamic handler chain configuration during mes- sage processing.
11. One supported parser.
12. Run on Java 1.5 and later.
13. No provision of side features such as a built in HTTP server, or a declarative configuration mechanism. These are delegated to other products.

この中でも注目は 1 と 3 だ。

XML の API として、彼らは XOM を念頭においているようだ。 ハンドラチェーンを使うのは「知っている XML だけを処理する」モジュールを接続して処理をするためだろう。

いやーしかし、こういう論文が Sun でも IBM でも BEA でもなく HP から出てくるところが、面白いなー。

Java SOAP スタックの再考

» Permanent link | |

とても興味深い論文を読んだ。 Steve Loughran と Edmund Smith の "Rethinking the Java SOAP Stack" だ。 この論文は現在の Java の SOAP 実装スタック、特に JAX-RPC の問題点を XML セントリックな視点から明確に指摘している。 また、最後の部分で Alpine という新しい SOAP スタックのコンセプトを提案している。

Alpine の方はまだどんなものかわからないので、これからに期待したいが、 JAX-RPC の問題点の方はとても面白い。 雰囲気を伝えるために論文の第二章 "基本的な JAX-RPC の欠陥(The Fundamental Flaws of JAX-RPC)" の見出しを日本語で引用する。

1. オブジェクト/XML のインピーダンスミスマッチ
   1. XML 要素の Java クラスへのバインディング
   2. XML の名前(Names)の Java 識別子へのマッピング
   3. Enumeration
   4. ポータブルでない型
   5. オブジェクトのグラフの直列化
   6. XML メタデータと名前空間
   7. メッセージ妥当性検証
   8. XML と直列化データの不適切な混和
   9. フォールト処理
2. SOAP は RPC ではない
3. SOAP は RMI ではない
4. WSDL: 別の複雑さ

このように論文で指摘されている問題点はいくつもあるのだが、基本的には SOAP/XML Web サービスを Java 世代のプログラミング言語(Java に加えて C#, VB.NET も)にネイティブにマッピングしてしまうことへの批判となっている。 その中でも特に大きいのが XML と オブジェクトのデータモデルの違いに起因するインピーダンスミスマッチだ。 ここで指摘されている各事項は、XML をオブジェクトにマッピングしたり、 オブジェクトを XML にマッピングしたりすることが本質的に難しいことを示している。

上でも述べたとおり、この論文は XML セントリックな視点から記述されているので、 逆に RPC/RMI/Object セントリックな視点から見るとまったく許容できない内容なのかもしれない。 そういう意味で面白い文(Don Box も引用している)がある。

我々は Web サービス開発者にはただ二つの分類があると考える。 XML に満足していてそれを扱う仕事をしたいと願っている人々と、満足していないのに結局はなんだかんだいってそれを扱う人々だ。

(We believe that only two categories of web service developer exist: those who are comfortable with XML and want to work with it, and those who aren’t but end up doing so anyway.)

明らかに僕は前者だ :-)

疎結合と XML

» Permanent link | |

疎結合(loosely-coupled)って何でしょう?

僕自身、適当に疎結合という言葉を使ってしまいがちですが、 ちゃんとした説明なり定義なりが必用だと感じています(自分のために)。 いいかげんな定義で話をはじめると、 各人の方向性がずれまくって議論ができないですよね。 Web サービスしかり、 SOA しかり、REST しかり。 ということで今回は僕なりに疎結合ってこんなもの、 というのを考えてみます。

ものすごく一般化してしまうと、 疎結合というのは複数のコンポーネント間の結び付きが ゆるいことを指すんでしょうね。 たぶん、ここまでは誰でも同意してくれるはず。 ただこれだけでは議論ができなくて、 このコンポーネントに何をもってくるかを決めて、 はじめて具体的な話ができます。

僕がここで話したいのは Web サービスの文脈での「疎結合」ですから、 コンポーネントは Web サービスになります。 コンポーネントがオブジェクトだとかもっと細かいレベルの話もあると思いますけど、 ここではしません。

あ、Web サービスという言葉も危いですね。 ここでは Web 上で機械(プログラム)可読なフォーマットで情報を提供するもの、 だとします(実際、僕の Web サース感はこれに近い)。 SOAP インターフェースの株価サービスかもしれないし、 AtomAPI のはてなブックマークかもしれない。 RSS フィードも含みます。

ところで、この「疎結合」をもろに扱った本があります。 タイトルがずばり「疎結合」です。 SOAP よりの Web サービスの文脈での疎結合を扱っている本です。 この本は10章で疎結合とは何かを解説しているんですが、 そこにはこんなことが書いてあります。

(前略) 多くの人々が「疎結合」という言葉を口にしますが、 その意味を正確に説明できる人はほとんどいません。 これは、疎結合が方法論もしくは作法であり、 確立された規則や仕様ではないからです。

疎結合は、俊敏性(アジリティ)、すなわち変化に適応する能力を重要視する 分散アプリケーション設計へのアプローチの一種です。 (後略)

つまり疎結合というのは分散アプリケーションの作り方、 設計の仕方に関する考え方のひとつであり、 特に決った規則や仕様はないってことです。 これは逆の意味でしっくりきました(僕には)。 これだけ曖昧な定義なら、議論の方向性が定まらないのも仕方ないですね。

僕が今考える疎結合システムのイメージはこんな感じです。

まず、サービス(コンポーネント)間のインターフェースは統一し、 半永久的に変更しません。 サービスのインターフェースに少しでも修正が入ると、 旧インターフェースを利用していたクライアントを修正しなければならないからです。

インターフェースを統一して不変にしたときに、 ではいったいどこでサービス同士の機能を差別化するのか。 それはサービス間でやり取りするデータで行います。 データ形式を思いっきり自由に拡張可能にして、 どんな種類のデータでも統一インターフェースで受け渡し可能にします。 オブジェクトだとこの拡張性が厳しいのですが、 XML と名前空間の組み合わせならぜんぜん問題ありません(ちょっと言い過ぎか)。

XML が拡張可能ということは、自分が知らない要素や属性が出てくる可能性があるということです。 でも、そんな拡張された未知のデータでもエラーにせずに、使えなければなりません。 そのために、知らない要素は無視する、という動作をデフォルトで行わなければならないのです。 SOAP の mustUnderstand 属性がデフォルトで false なのは、こういう理由からではないかと思います、たぶん。

で、このデフォルトで無視という動作は、 吉松さんがこのポストで言っている 「無邪気なまでにデータの読み手に解釈をゆだねる姿勢」 のデータの読み手側の一番簡単な実践なんだと思うのです。 本当はさらに吉松さんのポストのコメントで萩原正義さん(らしき人)が言っている「semantics を重視した…」 というのも直感的にわかりそうなのだけれど、今の僕には残念ながら理解しきれません。 だからとりあえず、 XPath なりで知ってる要素と属性をパターンマッチして知らないやつは無視、からやってみるしかないんだな、 というなんだか当たり前の結論になっちゃったなあ。

REST は XML の王道

» Permanent link | |

最近の僕の日記のエントリを見ていただければわかると思いますが、もう完全に REST に傾倒しています。自分はなんでこんなに REST に惹かれるのだろうと考えてみたんですが、なんとなく答えがわかりました。REST には XML Guy の王道(XML の王道)が具現化されているのです。

いったん話を 1998年に戻しましょう。1998年、僕たちには華々しい未来がありました。それまでの大文字の HTML が XML によってプログラマブルに拡張される。名前空間やリンク機構を生かしてそれまでの Web が大幅に進化する。Jon Bosak の XML, Java, and the future of the Web や村田さんの「XML入門」に語られているような未来です(村田さんたちが訳したJon Bosak の記事の日本語版が見つけられなかった…)。

しかし世の中はその後さまざまな方向に迷走していきました。スキーマ言語戦争だったり、単なる設定ファイルとしての XML 応用だったり(ini や csv の代用…)、バインディングツールだったり。もちろんそれらは重要で、実際に役立つものですが、あまりにも初期の目標から論点がずれてしまったように(今となっては)感じます。そして、その迷走の最たるものが SOAP による Web サービスでしょう。XML による RPC は確かに便利で、ある面(異なるプラットフォーム間で見ると)実用的なものですが、それは XML の王道ではありません。

XML の王道はやはり、インターネットスケールの Web 上でハイパーリンクされた XML インスタンスを無数のプログラムが操作する世界でしょう。それはまさに REST で実現される世界です。だから僕(=XML Guy)は REST にワクワクするんだと思います。

[update 2005-03-31] 村田さんが XML, Java, そして Web の将来の日本語訳を再公開してくれました。

XML、データ、コード、そして Chimaira

» Permanent link | |

XML guy としての、最近の心境です。

そもそも XML とは何なのか、について考えさせられることが多くなりました。

一つはまつもとゆきひろさんの「私はなぜ XML を愛していないか」という日記です。ここで、まつもとさんはデータ記述言語としての XML の存在意義に疑問を投げかけられています。「XML を愛する人」と自己紹介している身としては、この日記に反論? しておきたかったのですが、考えをうまく文章化することができず、時機を逸してしまいました。

もう一つは檜山さんの一連の記事(Java World の連載および chimaira.org)です。どちらの記事においても、檜山さんは一貫して XML タグ構文とソフトウェアコンポーネントを統合的に取り扱うアーキテクチャ(の土台となるべき議論)について論じられています。

まつもとさんの指摘を一言で言い表すと「XML ってそんなにイイの? 使いやすいの?」となるのではないでしょうか。まつもとさんの側(プログラミング言語設計者、OOP の視点?)から見ると XML は冗長で回りくどくてスマートでなく、しかもデータ型など細かいところに手が届かない中途半端なデータ形式、と思われているようです。

XML は本当に使いやすいのでしょうか。

結論から先に言うと、ある視点からみれば全くそのとおり、使いにくいです。以下では僕が感じていることをもう少し書き綴ってみます。

まつもとさんの日記のコメントでは Relaxer が話題に上っていました。関連した話として、川俣さんが chimaira.org に言及した記事で Relaxer に疑問を投げかけられています。僕は Relaxer を有効活用していますが、Relaxer が XML を扱う最適な処理形態ではないと感じています。Java (あるいはプログラミング言語)の世界のデータモデルに合致したスキーマを利用する限りにおいては Relaxer は有効ですが、XML 特有のモデルが出現したとたん、バインディングが複雑になってしまいます。Relaxer を使っている現場では、ラベルを駆使したスキーマや choice などは使っていないのではないかと想像しますが、どうなのでしょうね。

しかしなぜ Relaxer は人気があるのでしょうか。なぜ人々は Java の世界で閉じずに、あえて RELAX NG(XML)という別の世界に流れるのでしょうか。まず考えられるのは、Relaxer がいろいろな雑誌に紹介記事が載っていて、かつインストールが簡単、比較的安定しているなどマーケティングのうまさとツールとしての出来のよさです。雑誌に書いてあって何か使えそうだ→インストールも簡単だった→いっぱい Java のコードを生成してくれる(感動!)という流れです。

それからもう一つ、実はこれが結構重要だと思いますが、Relaxer を使うと Java オブジェクトの永続化が簡単に行えるということも挙げられるのではないかと感じています。逆に言うと Java ではオブジェクト永続化が難しい、ということです。ツリーで表現できるデータ構造を Java で設計し、アクセッサを用意して、かつ入出力のコードも書き、というようなコーディングを手で一からやっていると、非常に手間がかかります。一般論として、プログラマはデータ構造の設計に集中したいのです。Relaxer を使えば、これが実現できます。すなわち RELAX NG スキーマの設計(=データ構造の設計)に集中すれば、その他の雑多なコードは全てツール(Relaxer)が自動生成してくれるのです。これは特に Java のような堅い言語で威力を発揮するのではないでしょうか。

さらにいうと、その永続化したデータが、Java 以外の言語やツール、たとえば XSLT などからアクセス可能である、というところがシステム設計者にとっても大きなメリットとなっているのではないでしょうか。ここはまさに XML の持つインターオペラビリティの本領発揮というところでしょう。

僕自身は Ruby に関して何も知らないので推測ですが、堅い Java に対して軟らかい Ruby では Relaxer のようなツールがあったとしても Java 版ほど利用されないのではないかと感じ(あくまでも感じるだけ)ます。

さて、ここまでは Java, OOP などの視点で語ってきました。しかし、世の中には別の視点もあります。それは、構造化文書、ハイパーテキスト、などいわゆるボヘミアンの視点です。ボヘミアンにとって一番大切なのは XML の構文とデータモデル(普通は? Infoset、でも檜山さんは DOM のようですね)です。彼らがプログラミング言語に期待するのは、自分の XML データをいかに効率的に扱えるか、処理できるかということです。そのような立場の人間からしてみると、既存のプログラミング言語(というよりは XML 処理ライブラリか)は中途半端で出来が悪く感じます。XML データを処理するコードを書こうとすると、とたんに冗長で回りくどくてスマートでなく、しかも混在内容など細かいところに手が届かない中途半端なプログラムになってしまいます。プログラミングの視点から見れば、そんなデータ形式のほうが悪い、となるのかもしれませんが、ボヘミアンからしてみれば、なんで俺のデータをこのプログラミング言語(ライブラリ)は扱えないのだ、となります。すなわち、興味の対象がコードなのかデータなのか、ということです。

プログラマの視点から見る世界は圧倒的にコード重視の世界でした。プログラムが真ん中にいて、その周りをデータが回っている世界です。ところが、Web 環境ではデータの価値が上がり、相対的にコードの価値が下がりました。データが中心にいて、その周りを複数のコードが回っているような状況です。XML 2004 のキーノートで、Michael Daconta がこれをコペルニクスの天動説と地動説になぞらえていました。

XML をインターオペラビリティのためだけにあると捉える人々は、天動説主義者ではないでしょうか。そしてボヘミアンは地動説主義者であるといえます。

ただ、データを中心に捉える考え方は、別に新しい物ではありません。たとえば Unix でおなじみの行指向のデータはどうでしょうか。Unix で伝統のある行指向のテキストデータは、それを扱う小さいプログラムがたくさん揃っています。そしてそれらをパイプとフィルタで自由自在に結合し、処理することが出来ます。フィルタは cat, sort など基本的なコマンド以外に、適当なスクリプト言語のワンライナー(使い捨て)をその場で作ってしまうことも出来ます。これはまさに行指向のテキスト(データ)の周りを小さいフィルタプログラム(コード)が回っている世界ではないでしょうか。

だいぶ昔、確かユニマガだったと思いますが、ラリーウォールがインタビューで perl の今後を聞かれたときに、これまで行指向のテキストデータが対象だったものを XML のようなツリー構造も対象にしていきたい、というようなことを返答していたと記憶しています。そして今、檜山さんが chimaira アーキテクチャでやろうとしている Janus はまさにこのパイプ&フィルタを XML の世界に拡張しようとする試みです。

XML の本領発揮はこれからではないでしょうか。まだ僕たちには見えていない世界があるようです。

こんな感覚が分散システムのアーキテクチャである REST と相関して自分の中になんともいえないモヤモヤを作っています。ここで述べた見解以外にも、他方では document vs object, rpc vs messaging, そして messaging コミュニティにおいても WS-* スタック vs REST など、問題のドメインは微妙に異なっていても実は課題は同じなのではないかと思えることがたくさんあります。継続して考えていかないといけないですね。

未知のボキャブラリのタグをどう表示するか

» Permanent link | |

xfy の話の続きである。

とりあえずユーザ登録して xfy をダウンロード、で使ってみた。単なる XHTML 編集環境としては、まあこんなもんかという感じである。やはり独自ボキャブラリを定義してこそ、意味のあるものであろう。ということで、自分が持っていた XHTML + 独自ボキャブラリのファイルを読み込ませてみた。これは比較的大きな XHTML ファイルで、170KB くらいあるが、そこそこ快適に開いて動作させることができた。僕の定義した独自ボキャブラリは単純で、脚注タグ <book:fn>と索引タグ <book:index>の二つである。どちらも XHTML のインライン要素に混ぜて使うことができる、という仕様だ。XHTML インスタンスの断片はたとえば、以下のようになる。

<p><book:index>XSLT</book:index> の名前空間は
"http://www.w3.org/1999/XSL/Transform" である。
ここでは XSLT の名前空間接頭辞として xsl を用いているが <book:fn>
この接頭辞は歴史的な理由で xsl を用いている。</book:fn>、
もちろんこれは正しく宣言されていれば、何でも構わない。</p>

サンプルで明らかだが、book:fn 要素は脚注としてレンダリングされることを期待しており、book:index 要素は索引からリンクされることを期待している。これを何の設定もせず、そのまま xfy に読ませてみた。するとレンダリング結果は以下のような感じになった。

?
の名前空間は "http://www.w3.org/1999/XSL/Transform" である。
ここでは XSLT の名前空間接頭辞として xsl を用いているが
?
、もちろんこれは正しく宣言されていれば、何でも構わない。

ここで注目して欲しいのは xfy にとって未知のタグ (book:fn と book:index) は、"?" という箱でレンダリングされたところである。すなわち、xfy は通常の Web ブラウザのように、知らないタグは無視するのではなく、「知らないタグである」というしるしを表示しているのだ。

これはボキャブラリ設計者(僕自身である)の気持ちとしてはどうなって欲しいかというと、book:index 要素に関してはタグを無視して内容を表示してほしくて、book:fn タグに関しては、できれば脚注らしく表示、それが難しかったら book:fn を示すicon が段落のインラインで表示されてほしい、というところである。

たとえば以下のような感じだ。

XSLT の名前空間は "http://www.w3.org/1999/XSL/Transform" である。
ここでは XSLT の名前空間接頭辞として xsl を用いているが(*)、
もちろんこれは正しく宣言されていれば、何でも構わない。

このように、XHTML + αのαの部分をどう表示するかは、法則があるわけではなく、その要素の意味で決まるので実装は難しいのだ。xfy の実装は、完璧ではないにせよかなりイイ線である。

…というようなことは実は僕のオリジナルではなく、"Java World 特別編集 XML World 第一弾" という雑誌の中の"XML 実践活用の手引き Part1 XML ボキャブラリ作成のポイントを知る"という記事で、"タグは読み飛ばしてもよいのか?" という囲み記事(54ページ左下)として檜山正幸さんが指摘している問題そのものである。

ここでの檜山さんは、「タグの無視」が DOM ツリーの構造を破壊することを指摘したうえで、次のように結論付けている。

妥協できる線としては、「知らない要素(タグではない)を無視したうえで、そこ に要素があった痕跡(例えば、疑問符が描かれたボックス)を残し、ユーザーが明示的に『タグを無視した表示』を選択したら表示する」といった動作が考えられる。

xfy の実装は前半部(無視しないで "?" ブロックで表示)はこのとおりだが、後半部(無視するかどうかユーザが選択可能)は実装していないようだった。おそらく VCD を書けばいいのだが、ドキュメントが少なくて僕にはできなかった。

xfy

» Permanent link | |

XML 2004 初日の講演で一番印象に残ったのは Justsystem の xfy だった(エクスファイと呼ぶそうである)。 これは一言で言ってしまうと、複数ボキャブラリを組み合わせた XML 文書の統合編集プラットフォームである。 日本語の記事では ITmedia が詳しい。

xfy では、たとえば XHTML 文書の中に SVG と MathML を入れて、それらをシームレスに編集することができる。 特に感動したのは このスクリーンショット において、左側の XML 文書ソースと右側のレンダリング済み XML が完全に同期しているところである。 たとえば左側のテキストを編集すると右側の SVG 画像が動的に完全に同期して再描画されていた。逆も同じである。

xfy の肝は Vocabulary Connection Description (VCD) にあるようだ。 これはボキャブラリ をどのように表示するか、そしてどのように編集するかを定義する XSLT ライクな言語である。表示(描画)の部分に関しては、セッションでのデモやチュートリアルを見た限りほとんど XSLT であった。編集に関しては、ちょっとまだよくわかっていない。単なるテキストの編集であれば簡単そうだが、複雑なボキャブラリ、特に構造を持っている場合にどのように定義するのだろうか。

SVG や MathML のように特殊なレンダリングが必要な場合はプラグインが必要になるのは理解できるが、テキストベースの複雑な構造を持った XML 文書はどうなるのだろうか。

また、実用のためには GUI 部品がどれだけそろっているかも重要なのではないかと思う。競合製品にはならないかもしれないが、マイクロソフトの InfoPath は Office に統合されていて非常にリッチなエディットコントロールを装備している。XSD を読み込んで、たとえば xs:date 型の要素はカレンダーで編集することもできる。xfy にもこのような編集環境が装備されていれば、十分実用的な XML 編集環境になりそうだ。

ところで、XML 2004 の xfy の発表会場で、檜山さんに久しぶりにお会いした。本当に偶然、僕の後ろの席に座っておられて、最後に振り返らなければ気づかなかったかもしれない。僕のことも覚えていただいており、大変うれしかった。この日記(はてなの方ですが)もご存知でちょっと冷や汗が出てきたり。

追記: 村田さんの blog にニュース記事などへのリンクが集められていた。