データ処理装置

【課題】構造化されたデータを適切に処理する技術を提供する。
【解決手段】データ処理装置では、ＸＭＬデータをＤＯＭツリーとして内部で保持し、様々な様式のデータをすべてＤＯＭツリーによって表現されるデータとして取り扱う。その結果、データの組み合わせや新しいデータ様式の追加が容易に行えるだけでなく、それぞれのデータに対して、様式間の境界を越えた統一的な操作や参照を行うことができるという利点がある。

【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理技術に関し、特に、構造化されたデータを処理する技術に関する。
【背景技術】
【０００２】
人類は、岩壁に壁画を描いていた時代から現在にいたるまで、人と人とをつなぎ、その思いやアイデア、知識などを伝え、共有するための方法を求め続けてきた。そのためのメディアとして文字や紙が生み出され、印刷、出版といった技術によって紙ドキュメントの大量生産が行われるようになり、さらにコンピュータやインターネットの出現によって、電子化されたドキュメントがやりとりされる世界へと発展を遂げてきた。
【０００３】
本出願人は、ユーザが自らの思いやアイデア、知識を自由自在に、思いのままにドキュメントとして表現し、取り扱うことができるドキュメントハンドリング環境の実現に取り組み続けてきた。そのような取り組みの中で、１９９６年に、次世代のドキュメントを担うフォーマットとしてふさわしい特長を持つＸＭＬに出会い、その後ＸＭＬに対する研究を続けてきたが、このたび、その特長を最大限に活かすことができるＸＭＬドキュメントハンドリングプラットホームとして本システムを開発するに至った。
【０００４】
ＸＭＬが世に出た当初は、ドキュメントハンドリングの場面や、ｗｅｂアプリケーションにおけるデータ交換の場面などでの使用が想定されていた。そのときには次世代ドキュメントハンドリングとＸＭＬアプリケーションプラットホームの未来について、「近い将来には、ＸＭＬを元にした複数のタグセットをユーザが自由に組み合わせて、ユーザの目的に合った文書を手軽に作成するようになる。」「特定のベンダーやソフトウェアに縛られることのないデータの公開性、保存性、交換性、再利用性が得られる。」「いつの日か、世の中のありとあらゆるデータがＸＭＬで表現され、自由にやりとりされるときが来る。」といった夢が語られていた。
【０００５】
その後ＸＭＬは、ＳＧＭＬやＨＴＭＬが新たに担おうとして挫折した応用分野を中心に、ゆっくりとではあるものの、確実に私たちの身の回りに浸透してきた。現在では、企業間の電子商取引、ｗｅｂサービスや、ニュースやｗｅｂサイトの更新情報配信、携帯端末での文書や図形の表示、単一のＸＭＬファイルから他の形式に変換して活用する文書管理の分野などにおいてＸＭＬの採用が進んでいるほか、マルチメディアデータの管理や、メタ情報・知的処理の分野など、情報処理技術の幅広い領域でのＸＭＬの活用が研究されている。
【特許文献１】特開２００１−２９０８０４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、いまだにユーザの多くは、相変わらずバイナリで表現された自由度の低いデータを利用するソフトウェアを使っている。一部にはそれらのソフトウェアで使用するデータをＸＭＬ化する動きもあるが、それらはあくまでベンダーが決めた範囲のタグセットの組み合わせしか許されていない。ＸＭＬが世に出た当初の、ドキュメントやデータを自由に取り扱うという夢が実現されているとは言い難い状況である。
【０００７】
このような現状に対して、本出願人は、データ処理システムを開発するに至った。本システムは、ＸＭＬが本質的に持つ自由度の高さを最大限に活かすために、ＸＭＬに最適な文書オブジェクトモデル（ＤＯＭ）によるデータ管理、柔軟で自由なモジュール組み合わせ、新しいタグセットにすばやく対応することができるボキャブラリコネクション（ＶＣ）といったしくみを備えている。本出願人は、このシステムがエンドユーザおよびデベロッパーにとって、今日直面している課題を乗り越えるための最適なソリューションであり、この新しいプラットホームを利用することによって、自由度の高いドキュメントハンドリング環境の構築、ＸＭＬアプリケーションの開発期間の短縮とソフトウェア品質向上、および総体的なコストの削減、ひいては、多くのエンドユーザへ決して欠かすことのできないソフトウェア環境を実現することができると確信している。
【課題を解決するための手段】
【０００８】
本発明のある態様は、データ処理装置に関する。このデータ処理装置は、構造化されたデータを処理するための基本機能を提供するコアコンポーネントと、所定のデータ様式のデータを処理する機能を提供するプラグインと、前記プラグインで処理不可能なデータを、前記プラグインで処理可能なデータに変換する機能を提供するボキャブラリコネクションと、を組み合わせてなることを特徴とする。
【０００９】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システムなどの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１０】
本発明によれば、構造化されたデータを適切に処理する技術を提供することができる。
【発明を実施するための最良の形態】
【００１１】
［概要］
ＸＭＬは、公開性、保存性、交換性および再利用性に優れた次世代の文書フォーマットして、広範囲で活用されることが期待されてきたが、いまだにその目標は達成されていない。その理由として、今まで使い勝手に優れ十分な機能と速度を持ったソフトウェアが開発されなかったことがある。本出願人は、この問題にいち早く取り組み、本実施の形態のデータ処理システムを完成させた。本システムは、ＸＭＬアプリケーションプラットホームであり、ＸＭＬに最適なドキュメントプロセッシングとアプリケーション開発環境を実現する。
【００１２】
本実施の形態では、本システムがＸＭＬの持つあらゆる自由度を最大限に生かすために備えている特長:ＸＭＬの対話的な編集、目的に合わせた複数のビューの切り替え、複数のボキャブラリを組み合わせた複合文書の表示・編集など、について説明する。また、これらを実現するための内部アーキテクチャ:ＸＭＬ複合文書フレームワーク、プラガブルアーキテクチャ、ボキャブラリコネクションなどについても解説する。
【００１３】
［ＸＭＬの利点と将来］
（テキスト形式での扱い）
ＸＭＬは、拡張可能なマークアップ言語である。マークアップ言語とは、コンピュータなどで作成した文書やデータファイルの中に、付加情報をテキストで埋め込む言語のことである。このため、全てのデータがプレーンテキスト形式で扱われることで、これは人がそのまま見ても理解することができる。マークアップ言語の一番の特長は、データファイルを見た時に、その言語の文法を知らなくても、マークアップを読み飛ばすことで、ある程度内容を把握できることである。
【００１４】
文書やデータの保管で現在主流なのは、バイナリ形式であるが、これは、プレーンテキストに比べてデータサイズが小さくなるので、保管時のメモリの消費量が小さくなったり、ハードディスクへの読み書きが早かったりするので、ハードウェアのリソースが限られていた時代にはメリットがあったが、ハードウェアの進歩により、その重要性は薄くなっている。
【００１５】
（アプリケーションによる共有）
一方で、ますます重要となってきたのが、データの互換性である。ＷＹＳＩＷＹＧは、ドキュメントを見たままに編集して、見たままに印刷するという意味であるが、ただドキュメントを作成し、それを印刷したらそれで終わり、という時代は終わった。一度作成したドキュメントは、それを効果的に再利用できなければ価値がない。それは、ドキュメントをデータベースとして共有するという、企業内の場合もあれば、他の会社との取引をするためにやりとりをするという、企業外の場合もあるだろう。どちらにせよ、いったん作成した文書やデータが他のアプリケーションで読み込めないというのでは話にならない。
【００１６】
（マルチプラットフォーム環境でのデータ交換）
さらに最近では、Ｌｉｎｕｘの普及で非Ｗｉｎｄｏｗｓ（登録商標）の動作環境も増えてきている。Ｌｉｎｕｘはサーバーのみならず、クライアントでも使われる例が増えており、Ｗｉｎｄｏｗｓ環境とＬｉｎｕｘ環境を含むマルチプラットフォーム環境で、同じ文書やデータファイルを扱いたい、という声は着実に増えている。さらにＰＤＡや携帯電話にもその世界は大きく広がっている。
【００１７】
ＸＭＬは、アプリケーション間の互換性を最も重視しており、第三者、例えば、Ｗ３Ｃ（World Wide Web Consortium）などにより規格の制定が行われている。その結果、ＸＭＬはどんな編集ソフトでも最も共通に使われるフォーマットとなるであろう。
【００１８】
そしてまた、ＸＭＬはインターネットにおけるデータ交換に使われることが確実視されている。企業間の電子商取引の共通フォーマットとしてＸＭＬが最適であるためである。
【００１９】
［本システムの特長］
本システムは、ＸＭＬで記述されたありとあらゆるドキュメントを、その特長を最大限に活かしながら、自由自在に思いのままに取り扱うことができるＸＭＬドキュメントハンドリング環境を提供することを目標に開発された。本システムには次のような特長がある。
【００２０】
（構造化されたドキュメントを自然なＵＩで作成・表示・編集）
人が持つ思いやアイデア、知識などを伝え、共有する。そのときに、少しでも多くの思いを込めたり、少しでも正確にアイデアや知識を表現したりするための手段として、ドキュメントを構造化し、より多くの情報を埋め込むという方法がある。さらに、ドキュメントの作成者と利用者の間で共通の構造化ルールを使うことで、埋め込まれた情報の解釈を共有することができ、ドキュメントの再利用性を高めることができる。
【００２１】
すでに世の中ではハイパーテキスト、ベクトル図形、数式や化学式など、さまざまなデータ様式を構造として表現するためのＸＭＬボキャブラリが策定・公開されている。本システムでは、それぞれのＸＭＬボキャブラリごとにプラグインを用意することで、それらのＸＭＬボキャブラリを使ったドキュメントを作成・表示・編集することができる。
【００２２】
また、プラグインがまだ存在していないような新しいプライベートＸＭＬボキャブラリに対しても、ボキャブラリコネクションというしくみによって素早くプラグインを用意することができる。さらに、一つのＸＭＬボキャブラリに対して複数のプラグインを用意しておけば、それらのプラグインを動的に切り替えることができる。そのため、いくつかのプラグインの中から、ユーザがより自然なＵＩであると感じるプラグインを選択してドキュメントの編集を行うこともできる。
【００２３】
（さまざまな様式のデータを自由に組み合わせ、シームレスに参照・編集）
たった一つのドキュメントを作成する場合においても、ユーザが表現したい内容を余すことなく表現するためには、文章、図形、表、チャート、数式などを効果的に組み合わせることが必要になってくる。また、単に組み合わせるだけではなく、文書中の数値と連動した表を生成したり、図形中にあらわれる要素の数をチャートでまとめたり、データ様式の垣根を越えた参照や連携などの自由な取り扱いができるようになれば、表現力が格段に向上したドキュメントをこれまでよりも簡単に作れるようになるはずである。
【００２４】
しかし、現在のオフィススイートアプリケーションを使った場合では、これらはひとつひとつ独立したソフトウェア、例えばドキュメント編集ソフト、描画ソフト、表計算ソフトなどで各部分を作成し、後からインポートして合成する方法が一般的である。これでは、それぞれのデータ様式を単に組み合わせただけに過ぎない。
【００２５】
本システムでは、ＸＭＬボキャブラリとして表現されたさまざまな種類のデータ様式について、そのデータ様式単体に対してだけではなく、それらを組み合わせた複合ドキュメントについても対話的な表示・編集を行うことが可能である。ＸＭＬボキャブラリを組み合わせることによって、一つのＸＭＬボキャブラリだけでは得られなかった高い表現力を得ることができる。さらに、それらのデータはすべてＸＭＬとして表現されているので、データ様式の垣根を越えた参照や連携が可能となり、高い再利用性を得ることができる。
【００２６】
（ユーザの目的にあわせたビューで自由自在にハンドリング）
ＸＭＬボキャブラリに対する複数プラグインの切り替えや、複合ドキュメントのハンドリング、ボキャブラリコネクションによるプライベートＸＭＬボキャブラリへの対応といった本システムの特長を利用すると、ユーザの目的にあわせてビューを切り替えることで、ＸＭＬドキュメントの自由自在なハンドリングができるようになる。
【００２７】
例えば、製本のプロセスなどを考えた場合、ライターはテキストが編集しやすい画面、デザイナーはグラフィックスが編集しやすい画面、校正者は修正が入れやすい画面、そしてパブリッシャーは印刷イメージのチェックがやりやすい画面、など各人が自分の目的に応じたビューを設定できる。また、このビューは簡単に切り替えることができ、そのためアプリケーションの切り替えや合成といった作業の必要がなく、非常に能率的に編集作業を行うことができる。
【００２８】
製本プロセスの例をもう少し詳しく見てみることにする。ライターはプレーンテキスト形式で原稿を執筆し、編集者に渡す。編集者はこれを校正し、ＸＭＬ化した上で、レイアウターに渡す。このとき追加されるタグは、入れ替えや追加、訂正といったものになるだろう。ＸＭＬなら原文をそのままにして、タグの追加のみで編集者のビューを実現できる。その後レイアウトをするわけであるが、フォントを決め、見出しを振り、段組みをして、レイアウトを決定する。この段階で、フォントのスタイルやサイズ、見出し、段組、ページレイアウトなどのタグが追加される。またその一方で、写真やデザイナーが描いたイラストなどを原稿に追加していくことになる。この段階で写真やグラフィックスのタグが入る。レイアウトが完成したら、版下として、印刷に回るわけであるが、この場合も、編集部から印刷所への特別な指示、例えば、紙の種類の指定や、色のマッチング、印刷部数などの情報を追加することができる。
【００２９】
こうして完成したドキュメントはひとつのＸＭＬファイルとなるわけであるが、ライター、編集者、レイアウター、デザイナー、印刷工場など、その情報を扱う人によってそれぞれの視点が違うのが分かる。
【００３０】
（目的志向のＸＭＬアプリケーションを簡単に作成）
ＸＭＬドキュメントの自由自在なハンドリングを推し進めていくと、ＵＩ部品とＸＭＬボキャブラリを組み合わせて簡単に目的を達成することができるＸＭＬアプリケーションという考えにたどり着く。これにより、議事録の作成や各種の申請処理などの定型アプリケーションを本システム上に構築したり、すでに存在する定型アプリケーションをカスタマイズすることが可能になる。例えば、スケジュール帳を作成するような場合、入力した時刻に会わせてスケジュール時間をグラフィックス表示する機能を追加したり、出席者の名前を登録して出席メンバーの空き時間を確認し、ミーティング召集のレターを出す機能を作成したりすることができる。
【００３１】
［本システムのアーキテクチャ］
本システムはこれらの特長を実現するため、次のようなアーキテクチャから成り立っている。
・ＸＭＬ複合文書フレームワーク
・プラガブルアーキテクチャ
・ボキャブラリコネクション
以下、それらについて説明する。
【００３２】
［ＸＭＬ複合文書編集フレームワーク］
ＸＭＬで記述されたありとあらゆるドキュメントを、その特長を最大限に活かしながら、自由自在に思いのままに取り扱うために最初に必要なものは、ＸＭＬで表現されるデータのツリー構造をそのまま取り扱うことができ、ＸＭＬボキャブラリ自体の数の増大やその組み合わせ数の爆発的増加にも対応できる、文書オブジェクトモデル（ＤＯＭ）の採用である。
【００３３】
文書オブジェクトモデル（ＤＯＭ）とは、ＸＭＬ文書をメモリにツリーとして展開し、そのノードにランダムにアクセスする方式（ＡＰＩ）のことである。ＸＭＬ文書はその性質から構造をツリー構造として扱うことができる。このＤＯＭを利用してＸＭＬ文書をツリー構造のまま編集することにより、ＸＭＬアプリケーション間の連携は飛躍的に容易となり、かつ移植性も高まる。本システムはこのＸＭＬ文書をＤＯＭを利用して編集するＸＭＬ複合文書フレームワークを提供する。図１に従来のＸＭＬ編集フレームワークと本システムのＸＭＬ編集フレームワークの比較を示す。
【００３４】
左側は従来の編集プラットホームで一般的に多く採用されているデータモデルを示している。このモデルでは、ファイルの入出力にはＸＭＬフォーマットを使用しているが、内部データは独自の、それぞれの様式データ（たとえば文章、ベクトル図形、数式など）を処理するのに最も適したデータモデルに変換して保持している。その結果、それらのデータの取り扱いが容易になり、必要なメモリ容量も少なくなるという利点がある。
【００３５】
しかし、このモデルにおいては、新しいデータ様式を追加する事が難しく、データの組み合わせや拡張性が制限されるという欠点がある。また、それぞれの様式間でアンドゥなどの統一的な操作を行ったり、他の様式中のデータを直接参照するなどといった処理は、様式間であらかじめインターフェースを規定した範囲内でしか行うことができず、データに対する参照・操作の拡張性も確保できない。
【００３６】
それに対し、本システムでは右側に示すように、ＸＭＬをそのままＤＯＭツリーとして内部で保持している。そのため、様々な様式のデータはすべてＤＯＭツリーによって表現されるデータとして取り扱われる。その結果、データの組み合わせや新しいデータ様式の追加が容易に行えるだけでなく、それぞれのデータに対して、様式間の境界を越えた統一的な操作や参照を行うことができるという利点がある。
【００３７】
例えば、文章と表で書かれたドキュメントに、ベクトル図と数式を追加する場面を考えてみる。従来のＯＬＥなどによる方法では、あくまで両者はオーバーレイされた表示イメージとして同じページに存在するだけで、様式間相互でデータを参照することはできなかった。しかしＤＯＭツリーを採用している本システムでは、文章と表とベクトル図の中にバラバラに含まれている単語を統一的に検索したり、表の部分で計算処理した結果を数式部分に反映したりすることができる。
【００３８】
また、表、文章、ベクトル図、また表、といった順番でデータに変更を加え、その操作をアンドゥしたいような場面を考えてみる。ＯＬＥではそれぞれの様式ごとにアンドゥが行なわれるが、本システムでは様式の境界を越えて統一的にアンドゥを行うことができる。
【００３９】
このような柔軟な複合文書の取り扱いを可能にしたのが、本システムのＸＭＬ複合文書編集フレームワークである。
【００４０】
［プラガブルアーキテクチャ］
前章で述べたように、本システムでは内部データの保持方法として、ＸＭＬの特長を最大限に活かすことができるＤＯＭを採用した。その結果、様々な様式のデータはすべてＤＯＭツリーによって表現されるデータとして取り扱われ、データの組み合わせや新しいデータ様式の追加を容易に行うことができるようになった。
【００４１】
データ様式が容易に追加され、組み合わせられるとなると、次に重要なのは、それらのデータに対応した処理モジュールの柔軟な追加や拡張、連携の実現である。例えば、新しいＸＭＬボキャブラリが出現した場合に、そのボキャブラリに対する処理系を追加したり、印刷機能や別なフォーマットでのファイル出力など必要な機能を必要に応じて追加できるなど、よりいっそうの柔軟性と拡張性を実現する必要がある。
【００４２】
このような機能追加を行うために従来からとられていた方法としては、プラグインというしくみがあった。しかし、従来のプラグインのしくみのように、大きなコアコンポーネントに対して、限定された機能をプラグインで追加するという考え方では、機能の拡張性に限界があり、またコアコンポーネントに備えられた機能については差し替えが不可能であるといった制限が付きまといがちであった。
【００４３】
そこで本システムでは、従来のコアコンポーネントとプラグインの考え方を一歩進め、従来のコアモジュールが備えていた基本的な機能の部分も含め、ほとんど全ての機能をプラグインとして実現する、新しいプラガブルアーキテクチャを構築することにした。図２の左に一般的なプラグインのしくみを、右に本システムのプラガブルアーキテクチャを示す。
【００４４】
このプラガブルアーキテクチャでは、コアコンポーネントを小さくすることで機能の拡張に関する自由度を飛躍的に高めることができるほか、比較的小さな粒度の機能をプラグインとすることによって、プラグインの組み合わせの選択に幅を持たせることができる。さらに最大の特長として、プラグインを追加するためのインターフェース自体を柔軟に追加できるしくみを備えている。これにより、ある決まったインターフェースのプラグインだけでなく、新しいインターフェースを持つプラグインを自由に追加することが可能である。その結果、新しいＸＭＬボキャブラリへの対応、機能の追加やバージョンアップが容易になるだけではなく、必要とする機能からアプリケーションを組み替える事もできるようになっている。さらに開発時のコーディングやデバックも手間がかからないものになっているほか、ボキャブラリ自体の数の増大やその組み合わせ数の爆発的増加にも対応できるものとなっている。
【００４５】
ＸＭＬファイルからＤＯＭツリー、そして各ボキャブラリを処理するプラグインへの流れを図３に示す。この例では、ＸＨＴＭＬとＳＶＧが複合しているＸＭＬドキュメントファイルがＤＯＭツリーとして表現され、それぞれのボキャブラリの部分ツリーがＸＨＴＭＬプラグインとＳＶＧプラグインによってレンダリングされ、最終的に一つのキャンバスに複合した形で描画されている。
【００４６】
［ボキャブラリコネクション］
本システムは、ＤＯＭとプラガブルアーキテクチャの採用によって、ボキャブラリ自体の数の増大や、その組み合わせ数の爆発的増加に対応する能力を得たが、ＸＭＬには、まだユーザがプライベートボキャブラリを自由に定義できるという大きな特長がある。
【００４７】
この特長を活かしてユーザが独自のプライベートボキャブラリを定義した場合、そのままでは、そのボキャブラリに対しては、ＸＭＬソースレベルでの操作しか行えなくなってしまうため、毎回ハードコードで大変な労力と時間を費やしてプラグインを作成する必要があった。
【００４８】
我々が必要としていたのは、プライベートボキャブラリを取り扱うプラグインをすばやく簡単に構築でき、しかもそのボキャブラリの取り扱い方を柔軟にカスタマイズできるしくみであった。そこで本システムでは、ボキャブラリコネクション（Vocabulary Connection：ＶＣ）というしくみを考案した。
【００４９】
ＶＣでは、独自ボキャブラリから既存のボキャブラリへのマッピングルール（コネクション）を定義するようになっている。このマッピングルールにより、ユーザはあたかも既存のＸＭＬドキュメントを編集するように、独自のボキャブラリを持ったドキュメントを編集することができる。（図４）
【００５０】
このマッピングルールを指定したものがＶＣＤ（Vocabulary Connection Descriptor）（図５）である。ＶＣＤはＸＳＬＴライクのＸＭＬスクリプトによって記述されており、その作成は、プライベートボキャブラリの処理系を新たにハードコードで書き起こすことに比べるとはるかに簡単で短時間で済む。ＶＣＤ中に記述されたマッピングルールは、ソースのＤＯＭツリー上の各ノードに対して適用される。このようなマッピングルールを蓄積していくことによって、容易に編集環境の拡張とカスタマイズを行うことができる。
【００５１】
図６〜図２１に、上記の実施の形態を説明するための図面を添付する。
【００５２】
［最後に］
誰でも自由に使えるPersonal Computerの出現は、第三の波、つまり情報革命の実現に計り知れない影響を与えた。そして、今インターネットの普及の時代を経て、ドキュメントプロセッシングの世界にもＸＭＬという、第三の大きな波が訪れようとしている。本出願人は、これまで培ってきたドキュメントプロセッシングの技術に、先進のＪａｖａ（登録商標）テクノロジーと革新的なＸＭＬ言語処理技術を組み合わせて、本システムのプラットホームを完成させた。本実施の形態で述べたように、本システムは、来るべきＸＭＬ時代の先駆けとなるものであり、次世代ドキュメントプロセッシングおよびＸＭＬアプリケーションに最適な基盤を提供する。
【００５３】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【図面の簡単な説明】
【００５４】
【図１】従来のＸＭＬ編集フレームワークと本システムのＸＭＬ編集フレームワークの対比を示す図である。
【図２】従来のプラグインと本システムのプラガブルアーキテクチャの対比を示す図である。
【図３】ＸＭＬファイルからＤＯＭツリーを生成し、各ボキャブラリを処理するプラグインにより表示される流れを示す図である。
【図４】ボキャブラリコネクションを説明するための図である。
【図５】ＶＣＤの例を示す図である。
【図６】本システムの特徴を説明するための図である。
【図７】本システムの特徴を説明するための図である。
【図８】本システムの特徴を説明するための図である。
【図９】本システムの特徴を説明するための図である。
【図１０】本システムの特徴を説明するための図である。
【図１１】本システムの特徴を説明するための図である。
【図１２】本システムの特徴を説明するための図である。
【図１３】本システムの特徴を説明するための図である。
【図１４】本システムの特徴を説明するための図である。
【図１５】本システムの特徴を説明するための図である。
【図１６】本システムの特徴を説明するための図である。
【図１７】本システムの特徴を説明するための図である。
【図１８】本システムの特徴を説明するための図である。
【図１９】本システムの特徴を説明するための図である。
【図２０】本システムの特徴を説明するための図である。
【図２１】本システムの特徴を説明するための図である。

【特許請求の範囲】
【請求項１】
構造化されたデータを処理するための基本機能を提供するコアコンポーネントと、
所定のデータ様式のデータを処理する機能を提供するプラグインと、
前記プラグインで処理不可能なデータを、前記プラグインで処理可能なデータに変換する機能を提供するボキャブラリコネクションと、
を組み合わせてなることを特徴とするデータ処理装置。

【図１】