過去に蓄積されたXML技術のどのあたりを檜山が面白いと感じ、再評価・再発見してみたいと望んでいるのか？
それは、また次ね。
前回、こんな文面で終わってしまったので、「それはどこ？」の話をせざるを得ないでしょうね。だから実際しますけれども、論理的な順序から言うと、その前に話しておくべきことがあるのだった。まー、いきがかりだから論理的順序は無視します。したがって、解説としては若干不親切で、幾分錯綜した感じになりそう。致し方ない。
話は前世紀まで遡＜さかのぼ＞るのだが
「過去に蓄積されたXML技術」という言葉は、なにか特定単一の仕様を意味してるわけではありません。いまだ脈ありと僕が思っているものがいくつかあるわけです。そのなかで第一の候補を挙げれば、… …
XLinkです。
XLinkは、XML 1.0仕様とほぼ同じ時期から構想されているものです。XMLの初期のドラフトでは、XLink仕様がXML仕様の一部だったと記憶しています。「過去の蓄積」の期間は、飛び抜けて長い技術ですね。
XLinkは、HyTimeやTEIの血統を継ぎ、XML 1.0の兄弟であり、将来を大いに嘱望されていたのです。1990年代後半、無邪気だった（けど、既にオッサンだった）僕なんか、HTMLのアンカーやイメージはXLinkに置き換えられるもんだと思っていましたよ。そして、諸々のハイパーメディアのベース技術として利用されるのだろうとも期待してました。で、今どうなってます？ これといった応用もないですね。実装？ なんかショボイのがあったような気もするけど…？ もうダメっぽな雰囲気が漂いまくり。
実際、XLinkはダメなところがいろいろあります。対話的処理系内でXLinkを使おうとすると、実装上の問題が山のように出てきます。僕は一時期、その問題群と格闘していたから、XLinkがなぜダメかには通じているつもりです。雑誌の連載で随分詳しく取り上げたこともあります。あまりに詳しくて、実感・共感を持って読んだ人はごく少数（皆無かも？）でしょう。今その説明を繰り返すつもりはありません。
XLink Again … (?)
と、なんかボコボコにこき下ろしておいて、「いまだ脈あり」の技術の第一候補に挙げるとは、いったいどういう了見だ!? -- XLinkを、想定された本来の用途に使おうと思うと、たぶん「もう無理、無理」です。脈ありとすれば、別な側面に目をやるしかないでしょう。その別な側面に僕は光を感じるのです。
ところで、XLinkの想定された本来の用途とは何でしょう。そりゃ、ハイパーテキスト／ハイパードキュメント／ハイパーメディアの基盤ですよ。HTMLのアンカー（aタグ）をうーんと機能拡張したようなハイパーリンクです。既存ボキャブラリの要素や属性に影響を与えずに、ハイパーリンク機能をアタッチできるのがウリ（のはず）です。構文的には名前空間付きの大域属性のセットを使います（これは、HyTimeアーキテクチャル・フォームのXML的な焼き直し）。この本来の用途の文脈で、あの概念と構文を考えてみると、…… ほぼ破綻＜はたん＞しています（あっ、またけなしちゃったよ）。
しかしですねぇ、リンク概念／リンク機構の用途が、対話的ハイパーメディアに限定されるわけじゃありません。僕がいま想定している（あるいは、要求している）リンクは、次の意味でHTMLアンカーより頑丈（robust）でリッチなものです。
- リンクの生成／確立に、リンク両端の調停と合意が必要とされる。
- リンクに役割（role）／機能性（fuｎctionality）／振る舞い（behaviour/bihavior）を持たせることができる。
- リンクを、イベント（主に変更通知）の伝搬経路として使える。
- 以上の機能により、リンク両端の同期／協調動作／整合性維持などを行える。
リンクにこの程度のことを要求するのは、別に珍しいことではないでしょう。実際僕は、知り合いのありきたりの要望を実現しようと考えているうち、「頑丈でリッチなリンクがないと困るなー」と思い至ったのです。
XLinkの構文は忘れ去るとして（どうせ破綻しているから使いものにならない）、背後にあるデータ構造とソフトウェア・アーキテクチャを利用すれば、上記の要求はその守備範囲内です。守備範囲といえば、XLinkとRDFはその適用領域がかぶっているので、RDFに依拠する道もありますが、XLinkを選ぶのは、まー僕の嗜好ですかね。
今日はここまで。だけど、XLinkの話とか、その他の埋もれた仕様とかの話をボチボチとするでしょう。ペースはゆっくりだろうけど、（圏論やErlangネタがそうであるように）継続的に取り上げるつもりではいます。
