ドキュメントへのアプロ―チ／(3) プログラミング

続いて、(3) XMLとプログラミング環境についてのまとめをお送りします。最初は「XMLとプログラム言語」というサブタイトルにしてたのですが、XMLデータベースやxfyの話題を扱うに当たり、プログラム言語では意味が狭すぎるのでプログラミング環境としました。

ドキュメント技術へのアプローチ―大野邦夫氏による研究・開発の軌跡

目次

1. 動向分析：XMLビッグバンとその後

2. 製品開発：マルチメディアドキュメントからXML応用システムへ

3. XMLとプログラミング環境（本記事）

4. モバイルユビキタス技術

5. PIM（個人情報管理）

6. ネットワークコンシェルジュ

7. ドキュメントと組織・社会・文化

8. 型、オントロジー、知識表現

9. ヒューマン・インタフェース

10. テクニカル・コミュニケーション

3. XMLとプログラミング環境

XMLはマークアップ言語であり、基本的には木構造のタグ付きデータである。従ってアプリケーションとして何らかの処理を行うには、プログラミング環境を必要とする。XMLを活用するプログラム言語のAPIとしては、DOMとSAXがある。XMLの普及に伴い、JavaやJavaScriptによるXML処理システムが続々と世の中に出現しつつあった。その頃、日本人によるオブジェクトスクリプト言語であるRubyが紹介され、INSエンジニアリングの吉田正人氏がDOMとSAXに相当するAPIを開発した。

3-1. 「オブジェクト指向スクリプト言語RubyによるXMLの処理」

この報告は、私が執筆したが、内容は吉田正人氏のものである。Python、Perlとの比較で、Rubyの処理系を紹介している。吉田氏はXMLやプログラミング技術に関する逸材である。技術的なセンスは素晴らしいが、上司の命令にすなおに従う組織人ではない。種々の経緯があり、INSエンジニアリングにおける新規事業部門の私の部下となり、その後ドコモ・システムズの間も一緒に仕事をした。彼のような人材を上手に生かすことが企業としては重要である。当時常務であった中津川氏はそのように語り、彼の特別待遇を認めてくれた。日本の組織で、彼のような人材を生かし育てるのは難しい。その理由は日本の組織文化にあるが、それを支えるのは横並びの平等意識である。

Rubyは使い勝手の良い言語である。Javaが、ネットワークアプリケーション用のデファクト標準言語として確立されたとは言え、コンパイル言語であるがために、開発やデバッグには煩雑なプロセスを要求される。その点スクリプト言語は型定義は不要で、即実行でき、使いやすい。Python、Perlに比べると、Rubyはオブジェクト指向プログラミング言語なので、クラス継承が使用でき、UMLの分析結果を直接クラス定義に生かせるメリットは大きい。このシステムは、吉田氏の個人サイトで公開され、ダウンロード可能であった。このシステムの利用者はかなり多く、Rubyの普及に貢献したと思われる。最近はRuby On Rails（略称Rails）がWebアプリのフレームワークとして利用される。Railsは、2003年の夏にDavid Heinemeier Hansson氏が作成を開始して、2004年にはじめて一般に公開された技術であるが、吉田氏のXML実装はそれを４～５年も遡る。当時、私自身もRubyでプログラムを作成したことがあるが、多重継承、ポリモルフィズムをふんだんに活用できるLispのオブジェクト指向プログラミングの方が優れていると感じた。さらに木構造データのXMLによる表現もLispのS式に比べると冗長であることを感じて、改めてLisp言語のメリットが印象付けられた。

このRubyによるXML処理系を応用する具体的な応用システムを開発した。このシステムはXML統合サーバーという名称で、ORACLEによるデータベースアプリケーションとLotus Notesによるメール機能・ワークフロー管理機能を連携させる社内システムとして作成された。このシステムに関しては製品開発紹介の項でも述べた。

3-2. 「オブジェクト指向スクリプト言語RubyによるXML応用システムの検討」

XML統合サーバーは、各種のアプリケーションが共通のXMLデータにアクセスして処理を行う。そのためにはXMLデータベースが有効であろうと考えられた。しかし、照会言語のXQueryの標準化が滞っており、XMLデータベースは標準化されずに商品が販売されるという奇妙な状態であった。そのために、取りあえず種々のXMLデータベースを評価してみた。XMLデータベースとは言ってもRDBと共存するもの (IBM DB2)、OODBを用いDOMと同様に木構造のXMLを要素単位で取り出せるもの (eXcelon)、インデックスを強化した追記式縦列XMLデータ管理システム (Tamino, Yggdrasill) があり、それらについて調べてみた。

3-3. 「XMLデータベースの機能と性能に関する一検討」

以上の結果、木構造が浅いデータ用にはRDB共存型、木構造が深い文書用にはOODB型、書き換えニーズが少ないアーカイブ管理用には追記型という大雑把な結論が得られた。種々のアプリケーションが混在するXML統合サーバの場合はOODBベースのeXcelonが妥当であった。しかし、eXcelonは、2GBという容量制限があり、それが問題になると予想された。

2000年の12月に、INSエンジニアリングの株式の大半をNTTドコモが取得することにより、名称がドコモ・システムズに変更された。研究開発の方向も従来の企業情報システムからコンシューマーを主体にする携帯電話やモバイル応用へとシフトした。INSエンジニアリング時代に開発してきたXML統合サーバは、ネットワーク上の秘書機能を提供する個人用ポータルサーバという位置づけで見直されることになり、アクセス端末も携帯電話やカーナビを想定することになった。以上の意図から、今後のモバイル・ユビキタス・サービスの要としてのシステムを想定して検討した結果をまとめて報告したのが下記の論文である。

3-4. 「モバイル環境におけるデジタルドキュメントの可能性 : ネットワークのIP化とREST
の適用」

DD研自体の検討対象も、従来の企業主体のドキュメントから、ケータイやカーナビといった個人を指向したサービスとそれに関わるドキュメントという新分野が誕生することになると予想した。さらにB2Bで用いられているWebサービスも、コンシューマ向けのB2Cへ移行することが予想され、それに伴い従来のSOAPに代わってRESTが使用されることを予測した。RESTは今でこそWebサービスの主流となっているが、当時日本で注目した人は殆どおらず、本論文は日本でRESTを最初に紹介した事例である。

XMLの世界で処理的な効果を提供する最も分かりやすい技術はXSLであろう。それは構造を表現に反映させる機能であり、SGML時代のDSSSLのXML版である。DSSSLが処理的な機能をLisp言語の方言であるSchemeで記述したが、XSLはその処理をあくまでもXMLの世界に閉じて記述した。だが一挙に構造から表現に移行させるのは無理があり、構造変換（XSLT）とフォーマッティング・オブジェクトの処理（XSL-FO）に分割した。

XSLTは構造変換言語なので、XMLをHTMLに変更することは容易である。このことから、情報を系統的にXMLで記述し、それをXSLT経由でHTML化しWebに表示する手法が一般化した。他方、XSL-FOの製品化は。世界的に見てもアンテナハウスのXSL Formatter程度で普及が進展していない。ページ概念や段構成といったレイアウトは、紙の時代の産物であり、Webの時代はXSLTとCSSで済ませれば良いという思想が主流になったということであろう。

XMLとプログラミング環境というフォーカスで、xfyは世界的に見て挑戦的で興味深い技術である。コア技術は、XVCDにある。XVCDは言わばXSLTの双方化である。WYSIWYGでHTMLコンテンツ、すなわちWebコンテンツの制作が可能ということである。ところで、W3CはWebを複合文書として標準化する企画を立てCDF (Compound Document Format) WGを立ち上げていた。xfyはこの分野でキーテクノロジーとなり得る潜在的な技術であった。複合文書 (Compound Document)という概念を提案したのはOMGである。

文字・図形・画像を包含する文書をオブジェクトモデル化し、各々の作成機能 (Editor)と表示機能（Viewer）をAPIとしてIDLで定義するものであった。しかし、AppleのOpenDocを雛形としたために、世の主流となっていたマイクロソフトのOLE（Object Linking & Embedding）技術をベースとするオフィス文書との連携 (CORBA COM Interoperability) に失敗しその後は顧みられなくなった。CDF-WGは、OMGがIDLで記述することを試みたを構成したEditorとViewerとXMLによるコンテンツ制作ツールとXHTMLをベースとするWebブラウザで構成することを指向するものであった。そのような狙いからすると、xfyは理想的なXMLによるコンテンツ制作ツールと言えた。

しかし、その意図は実現できなかった。個人が有償でXHTMLエディタを購入するような状況は想像しにくく、かつ当面のターゲットがWebブラウザよりは携帯電話画面に特化されていたからである。技術的にもCDR (Compound Document for Reference)とCDI (Compound Document for Integration)の２段階に分けられ、第一段階は参照に特化したCDRとされたために、xfyの出番は無かった。CDFの規格もCDRについて決めた段階で実質的にCDFWGの活動は終了してしまった。そのような経緯から、xfyの本来の趣旨であったWebコンテンツのオーサリング分野の標準化にはいたらなかった。

そのようなxfyのビジネス応用という観点で最初に取り上げられたのはXBRL関連文書のWYSIWYG化であった。企業の財務報告書の作成や管理のためにXBRLは使用される。XBRLの規格は、XMLによる財務データのフォーマットであるが、最終的には報告書の文書として発行される。したがって目標は財務データと連携する報告書の作成にある。そのような目的で作成されたのが、xfy for XBRLであった。

3-5. 「XBRL用xfyの試作」

このシステムの内容は、2006年にマドリードで開催されたXBRL国際カンファレンスで報告された。このシステムは、さらに財務分析ソフトと連携する、企業の経営支援システムとして構築されたが、XBRL自体の普及が必ずしも進展しなかったので、本格的なビジネスには至らなかった。

まとめ：XMLの用途は、一般にトランザクション的なデータと構造化文書の記述とに大別され、各々分離されて論じられることが多い。だがXMLのメリットは、データと文書に対して共通に使えるフォーマットであり、種々の情報源をXML（eXchange andMerge Language）化してデータ統合し、XMLフォーマットで共有されるデータを種々のアプリケーションで処理することにある（Cross[X] Media Language）。このモデル・アーキテクチャはXML統合サーバで実現されている。後者に関しては、ILLUSTRAのデータブレードの概念を用いると、アプリケーション・ブレードとも言うべき概念である。この概念においてxfyはWYSIWYGのヒューマンインタフェースブレードとして位置づけられる。 （大野邦夫　k-ohno@uitec.ac.jp）

著者紹介：大野 邦夫 (おおの くにお)　経歴はこちら

[略歴] 1968年、東京工業大学工学部機械工学科卒業、70年同大学大学院修士課程機械工学専攻修了、電電公社(現NTT)に就職。電気通信研究所、米国ウイス コンシン大学マジソン校派遣、横須賀研究所、NTTインテリジェントテクノロジ(株)、ヒューマンインタフェース研究所などに在籍。95年にNTTを退 職、グループ企業のINSエンジニアリング(株)*に転籍(*2000年にドコモ・システムズと社名変更)。同社退職後、(株)ジャストシステムに移り、 主にxfyに関わる標準化とその関連技術の調査を担当した。2007年から職業能力開発総合大学校通信システム工学科教授。現在に至る。