明 細 書
情報配信システム
技術分野
[0001] 本発明は、情報配信技術に関し、特に、 XML (extensible Markup Language)によ り記述された文書を携帯端末に配信する情報配信システムに関する。
背景技術
[0002] 近年、幅広い層にわたって携帯電話端末が広く普及しており、成人のほとんどが携 帯電話端末を所有していると言っても過言ではない。また、インターネットのインフラ の整備が進み、インターネットの利用者が爆発的に増加している。携帯電話端末の 多くは、インターネットへアクセスする機能を有しており、インターネットを介した携帯 電話端末への情報配信ビジネスも盛んに行われて 、る。
発明の開示
発明が解決しょうとする課題
[0003] 現在広く普及している情報配信サービスでは、ウェブサーノから HTML (HyperTe xt Markup Language)で記述されたウェブページを配信している。し力し、 HTMLは 、主として表示形式を規定するマークアップ言語であるから、文書の内容に対してタ グで意味が付されているわけではない。したがって、文書の再利用性が困難であると いう問題がある。
[0004] 本発明はこうした状況に鑑みてなされたものであり、その目的は、 XMLにより記述さ れた文書を携帯端末に配信する技術を提供することにある。
課題を解決するための手段
[0005] 本発明のある態様は、情報配信システムに関する。この情報配信システムは、携帯 端末と、前記携帯端末へ情報を配信する情報配信装置と、を含み、前記情報配信装 置は、マークアップ言語により記述された文書を保持する保持部を含み、前記携帯 端末は、前記情報配信装置から前記文書を取得する取得部と、所定のタグセットで 記述された文書を処理する処理系と、前記文書に含まれる要素を前記処理系が処 理可能な要素に変換し、変換前後の要素の対応を管理する変換部と、前記変換部
により変換され、前記処理系により処理された文書を表示する表示装置と、を含むこ とを特徴とする。
[0006] 前記情報配信装置は、前記文書を前記携帯端末へ送信する送信部を更に含んで もよぐ前記携帯端末は、前記情報配信装置から送信された前記文書を受信する受 信部を更に含んでもよい。
[0007] 前記携帯端末は、前記文書に含まれる文書を前記処理系が処理可能な要素に変 換するためのルールを記述した定義ファイルを更に含んでもよぐ前記変換部は、前 記定義ファイルを参照して、前記文書に含まれる要素を前記処理系が処理可能な要 素に変換してもよい。前記保持部は、前記定義ファイルを更に保持してもよぐ前記 送信部は、前記定義ファイルを前記携帯端末へ送信してもよい。前記携帯端末は、 前記文書に対応する複数の前記定義ファイルを取得したときに、それらを切り替えて 適用する切替部を含んでもよい。前記定義ファイルは、前記文書を処理するための ユーザインタフェースを更に記述してもよぐ前記携帯端末は、前記定義ファイルに 記述された前記ユーザインタフェースを前記表示装置に表示し、ユーザからの指示 を受け付けてもよい。
[0008] 前記携帯端末は、前記処理系により編集した前記文書を前記情報配信装置へ返 送する送信部を更に含んでもょ ヽ。
[0009] 前記携帯端末は、自身と通信可能な情報配信装置を検索する検索部を更に含ん でもよぐ前記取得部は、前記検索部により検索された情報配信装置から文書を取 得してもよい。前記検索部は、前記携帯端末が有している定義ファイルにより処理可 能なタグセットで記述された文書を検索してもよぐ前記取得部は、前記検索部により 検索された文書を取得してもよ 、。
[0010] なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システムな どの間で変換したものもまた、本発明の態様として有効である。
発明の効果
[0011] 本発明によれば、 XMLにより記述された文書を携帯端末に配信する技術を提供す ることがでさる。
図面の簡単な説明
[図 1]前提技術に係る文書処理装置の構成を示す図である。
[図 2]処理対象となる XML文書の例を示す図である。
[図 3]図 2に示した XML文書を HTMLで記述された表にマッピングする例を示す図 である。
[図 4(a)]図 2に示した XML文書を図 3に示した表にマッピングするための定義フアイ ルの例を示す図である。
[図 4(b)]図 2に示した XML文書を図 3に示した表にマッピングするための定義フアイ ルの例を示す図である。
[図 5]図 2に示した成績管理ボキヤブラリで記述された XML文書を、図 3に示した対 応により HTMLにマッピングして表示した画面の例を示す図である。
[図 6]ユーザが定義ファイルを生成するために、定義ファイル生成部がユーザに提示 するグラフィカルユーザインターフェースの例を示す図である。
[図 7]定義ファイル生成部により生成された画面レイアウトの他の例を示す図である。
[図 8]文書処理装置による XML文書の編集画面の一例を示す図である。
[図 9]文書処理装置により編集される XML文書の他の例を示す図である。
[図 10]図 9に示した文書を表示した画面の例を示す図である。
[図 11(a)]文書処理システムの基本構成を示す図である。
[図 11(b)]文書処理システム全体のブロック図を示す図である。
[図 11(c)]文書処理システム全体のブロック図を示す図である。
[図 12]文書管理部の詳細を示す図である。
[図 13]ボキヤブラリコネクションサブシステムの詳細を示す図である。
[図 14]プログラム起動部と他の構成の関係の詳細を示す図である。
[図 15]プログラム起動部によりロードされたアプリケーションサービスの構造の詳細を 示す図である。
[図 16]コアコンポーネントの詳細を示す図である。
[図 17]文書管理部の詳細を示す図である。
[図 18]アンドゥフレームワークとアンドゥコマンドの詳細を示す図である。
[図 19]文書処理システムにおいて文書がロードされる様子を示す図である。
圆 20]文書とその表現の例を示す図である。
[図 21]モデルとコントローラの関係を示す図である。
[図 22]プラグインサブシステム、ボキヤブラリコネクション、及びコネクタの詳細を示す 図である。
[図 23]VCDファイルの例を示す図である。
[図 24]文書処理システムにおいて複合文書をロードする手順を示す図である。
[図 25]文書処理システムにおいて複合文書をロードする手順を示す図である。
[図 26]文書処理システムにおいて複合文書をロードする手順を示す図である。
[図 27]文書処理システムにおいて複合文書をロードする手順を示す図である。
[図 28]文書処理システムにおいて複合文書をロードする手順を示す図である。
[図 29]コマンドの流れを示す図である。
圆 30]実施の形態に係る情報配信システムの構成を示す図である。
[図 31]図 31 (a) (b)は、情報配信システムの第 1の適用例を示す図である。
[図 32]図 32 (a) (b)は、情報配信システムの第 2の適用例を示す図である。
[図 33]図 33 (a) (b)は、情報配信システムの第 3の適用例を示す図である。
[図 34]情報配信システムの別の構成例を示す図である。
[図 35]情報配信システムの更に別の構成例を示す図である。
符号の説明
20 文書処理装置、 21 表示装置、 22 主制御ユニット、 23 入力装置、 24 編 集ユニット、 25 情報配信装置、 26 文書保持部、 27 送信部、 30 DOMユニット、 32 DOM提供部、 34 DOM生成部、 35 DOM管理部、 36 出力部、 40 CSS ユニット、 42 CSS解析部、 44 CSS提供部、 46 レンダリング部、 50 HTMLュ- ット、 52, 62 制御部、 54, 64 編集部、 56, 66 表示部、 60 SVGユニット、 70 携帯端末、 71 個人情報保持部、 72 フィルタリング部、 73 文書保持部、 74 検索 部、 75 通信部、 76 販売装置、 77 定義ファイル保持部、 78 切替部、 80 VCュ ニット、 82 マッピング部、 84 定義ファイル取得部、 86 定義ファイル生成部、 89 無線 ICタグ。
発明を実施するための最良の形態
[0014] (前提技術)
図 1は、前提技術に係る文書処理装置 20の構成を示す。文書処理装置 20は、文 書内のデータが階層構造を有する複数の構成要素に分類された構造化文書を処理 するが、本前提技術では構造化文書の一例として XML文書を処理する例にっ ヽて 説明する。文書処理装置 20は、主制御ユニット 22、編集ユニット 24、 DOMユニット 3 0、 CSSユニット 40、 HTMLユニット 50、 SVGユニット 60、及び変換部の一例である VCユニット 80を備える。これらの構成は、ハードウェアコンポーネントでいえば、任意 のコンピュータの CPU、メモリ、メモリにロードされたプログラムなどによって実現され る力 ここではそれらの連携によって実現される機能ブロックを描いている。したがつ て、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合 せによっていろいろな形で実現できることは、当業者には理解されるところである。
[0015] 主制御ユニット 22は、プラグインのロードや、コマンド実行のフレームワークを提供 する。編集ユニット 24は、 XML文書を編集するためのフレームワークを提供する。文 書処理装置 20における文書の表示及び編集機能は、プラグインにより実現されてお り、文書の種別に応じて必要なプラグインが主制御ユニット 22又は編集ユニット 24に よりロードされる。主制御ユニット 22又は編集ユニット 24は、処理対象となる XML文 書の名前空間を参照して、 XML文書が 、ずれのボキヤブラリにより記述されて 、る かを判別し、そのボキヤブラリに対応した表示又は編集用のプラグインをロードして表 示や編集を実行させる。例えば、文書処理装置 20には、 HTML文書の表示及び編 集を行う HTMLユニット 50、 SVG文書の表示及び編集を行う SVGユニット 60など、 ボキヤブラリ(タグセット)ごとに表示系及び編集系がプラグインとして実装されており、 HTML文書を編集するときは HTMLユニット 50が、 S VG文書を編集するときは S V Gユニット 60が、それぞれロードされる。後述するように、 HTMLと SVGの双方の構 成要素を含む複合文書が処理対象となって ヽる場合は、 HTMLユニット 50と SVG ユニット 60の双方がロードされる。
[0016] このような構成によれば、ユーザは、必要な機能のみを選択してインストールし、後 力 適宜機能を追加又は削除することができるので、プログラムを格納するハードデ イスクなどの記録媒体の記憶領域を有効に活用することができ、また、プログラム実行
時にも、メモリの浪費を防ぐことができる。また、機能拡張性に優れており、開発主体 としても、プラグインの形で新たなボキヤブラリに対応することが可能なので開発が容 易となり、ユーザとしても、プラグインの追カ卩により容易かつ低コストにて機能を追カロ することができる。
[0017] 編集ユニット 24は、ユーザインターフェースを介してユーザ力も編集指示のイベント を受け付け、そのイベントを適切なプラグインなどに通知するともに、イベントの再実 行 (リドウ)又は実行の取消(アンドゥ)などの処理を制御する。
[0018] DOMユニット 30は、 DOM提供部 32、 DOM生成部 34、及び出力部 36を含み、 X ML文書をデータとして扱うときのアクセス方法を提供するために定められた文書ォ ブジェクトモデル(Document Object Model: DOM)に準拠した機能を実現する。 DO M提供部 32は、編集ユニット 24に定義されているインタフェースを満たす DOMの実 装である。 DOM生成部 34は、 XML文書力も DOMツリーを生成する。後述するよう に、処理対象となる XML文書力 VCユニット 80により他のボキヤブラリにマッピング される場合は、マッピング元の XML文書に対応するソースツリーと、マッピング先の X ML文書に対応するデスティネーションツリーが生成される。出力部 36は、例えば編 集終了時に、 DOMツリーを XML文書として出力する。
[0019] CSSユニット 40は、 CSS解析部 42、 CSS提供部 44、及びレンダリング部 46を含 み、 CSSに準拠した表示機能を提供する。 CSS解析部 42は、 CSSの構文を解析す るバーサの機能を有する。 CSS提供部 44は、 CSSオブジェクトの実装であり、 DOM ツリーに対して CSSのカスケード処理を行う。レンダリング部 46は、 CSSのレンダリン グエンジンであり、 CSSを用いてレイアウトされる HTMLなどのボキヤブラリで記述さ れた文書の表示に用いられる。
[0020] HTMLユニット 50は、 HTMLにより記述された文書を表示又は編集する。 SVGュ ニット 60は、 SVGにより記述された文書を表示又は編集する。これらの表示 Z編集 系は、プラグインの形で実現されており、それぞれ、文書を表示する表示部(Canvas) 56、 66、編集指示を含むイベントを送受信する制御部(Editlet) 52、 62、編集コマン ドを受けて DOMに対して編集を行う編集部 (Zone) 54、 64を備える。制御部 52又は 62が外部力も DOMツリーの編集コマンドを受け付けると、編集部 54又は 64が DO
Mツリーを変更し、表示部 56又は 66が表示を更新する。これらは、 MVC (Model-Vi ew-Controller)と呼ばれるフレームワークに類似する構成をとつており、概ね、表示部 56及び 66が「View」に、制御部 52及び 62が「Controller」に、編集部 54及び 64と D OMの実体が「Model」に、それぞれ対応する。本前提技術の文書処理装置 20では、 XML文書をツリー表示形式で編集するだけでなく、それぞれのボキヤブラリに応じた 編集を可能とする。例えば、 HTMLユニット 50は、 HTML文書をワードプロセッサに 類似した方式で編集するためのユーザインターフェースを提供し、 SVGユニット 60は 、 SVG文書を画像描画ツールに類似した方式で編集するためのユーザインターフエ ースを提供する。
[0021] VCユニット 80は、マッピング部 82、定義ファイル取得部 84、及び定義ファイル生 成部 86を含み、あるボキヤブラリにより記述された文書を、他のボキヤブラリにマツピ ングすることにより、マッピング先のボキヤブラリに対応した表示編集用プラグインで文 書を表示又は編集するためのフレームワークを提供する。本前提技術では、この機 能を、ボキヤブラリコネクション(Vocabulary Connection: VC)と呼ぶ。定義ファイル取 得部 84は、マッピングの定義を記述したスクリプトファイルを取得する。この定義ファ ィルは、ノードごとに、ノード間の対応 (コネクション)を記述する。このとき、各ノードの 要素値や属性値の編集の可否を指定してもよい。また、ノードの要素値や属性値を 用いた演算式を記述してもよい。これらの機能については、後で詳述する。マツピン グ部 82は、定義ファイル取得部 84が取得したスクリプトファイルを参照して、 DOM生 成部 34にデスティネーションツリーを生成させ、ソースツリーとデスティネーションッリ 一の対応関係を管理する。定義ファイル生成部 86は、ユーザが定義ファイルを生成 するためのグラフィカルユーザインターフェースを提供する。
[0022] VCユニット 80は、ソースツリーとデスティネーションツリーの間のコネクションを監視 し、表示を担当するプラグインにより提供されるユーザインタフェースを介してユーザ 力も編集指示を受け付けると、まずソースツリーの該当するノードを変更する。 DOM ユニット 30が、ソースツリーが変更された旨のミューテーシヨンイベントを発行すると、 VCユニット 80は、そのミューテーシヨンイベントを受けて、ソースツリーの変更にデス ティネーシヨンツリーを同期させるベぐ変更されたノードに対応するデスティネーショ
ンツリーのノードを変更する。デスティネーションツリーを表示/編集するプラグイン、 例えば HTMLユニット 50は、デスティネーションツリーが変更された旨のミューテー シヨンイベントを受けて、変更されたデスティネーションツリーを参照して表示を更新 する。このような構成により、少数のユーザにより利用されるローカルなボキヤブラリに より記述された文書であっても、他のメジャーなボキヤブラリに変換することで、文書を 表示することができるとともに、編集環境が提供される。
[0023] 文書処理装置 20により文書を表示又は編集する動作について説明する。文書処 理装置 20が処理対象となる文書を読み込むと、 DOM生成部 34が、その XML文書 力も DOMツリーを生成する。また、主制御ユニット 22又は編集ユニット 24は、名前空 間を参照して文書を記述しているボキヤブラリを判別する。そのボキヤブラリに対応し たプラグインが文書処理装置 20にインストールされて 、る場合は、そのプラグインを ロードして、文書を表示/編集させる。プラグインカ Sインストールされていない場合は 、マッピングの定義ファイルが存在するか否かを確認する。定義ファイルが存在する 場合、定義ファイル取得部 84が定義ファイルを取得し、その定義に従って、デスティ ネーシヨンツリーが生成され、マッピング先のボキヤブラリに対応するプラグインにより 文書が表示 Z編集される。複数のボキヤブラリを含む複合文書である場合は、後述 するように、それぞれのボキヤブラリに対応したプラグインにより、文書の該当箇所が それぞれ表示 Z編集される。定義ファイルが存在しない場合は、文書のソース又はッ リー構造を表示し、その表示画面にぉ 、て編集が行われる。
[0024] 図 2は、処理対象となる XML文書の例を示す。この XML文書は、生徒の成績デー タを管理するために用いられる。 XML文書のトップノードである構成要素「成績」は、 配下に、生徒ごとに設けられた構成要素「生徒」を複数有する。構成要素「生徒」は、 属性値「名前」と、子要素「国語」、「数学」、「理科」、「社会」を有する。属性値「名前」 は、生徒の名前を格納する。構成要素「国語」、「数学」、「理科」、「社会」は、それぞ れ、国語、数学、理科、社会の成績を格納する。例えば、名前カ^ A」である生徒の国 語の成績は「90」、数学の成績は「50」、理科の成績は「75」、社会の成績は「60」で ある。以下、この文書で使用されているボキヤブラリ(タグセット)を、「成績管理ボキヤ ブラリ」と呼ぶ。
[0025] 本前提技術の文書処理装置 20は、成績管理ボキヤブラリの表示 Z編集に対応し たプラグインを有しないので、この文書をソース表示、ツリー表示以外の方法で表示 するためには、前述した VC機能が用いられる。すなわち、成績管理ボキヤブラリを、 プラグインが用意された別のボキヤブラリ、例えば、 HTMLや SVGなどにマッピング するための定義ファイルを用意する必要がある。ユーザ自身が定義ファイルを作成す るためのユーザインターフェースについては後述することにして、ここでは、既に定義 ファイルが用意されているとして説明を進める。
[0026] 図 3は、図 2に示した XML文書を HTMLで記述された表にマッピングする例を示 す。図 3の例では、成績管理ボキヤブラリの「生徒」ノードを、 HTMLにおける表(「TA BLE」ノード)の行(「TR」ノード)に対応づけ、各行の第 1列には属性値「名前」を、第 2 列には「国語」ノードの要素値を、第 3列には「数学」ノードの要素値を、第 4列には「 理科」ノードの要素値を、第 5列には「社会」ノードの要素値を、それぞれ対応付ける 。これにより、図 2に示した XML文書を、 HTMLの表形式で表示することができる。 また、これらの属性値及び要素値は、編集可能であることが指定されており、ユーザ が HTMLによる表示画面上で、 HTMLユニット 50の編集機能により、これらの値を 編集することができる。第 6列には、国語、数学、理科、社会の成績の加重平均を算 出する演算式が指定されており、生徒の成績の平均点が表示される。このように、定 義ファイルに演算式を指定可能とすることにより、より柔軟な表示が可能となり、編集 時のユーザの利便性を向上させることができる。なお、第 6列は、編集不可であること が指定されており、平均点のみを個別に編集することができないようにしている。この ように、マッピング定義において、編集の可否を指定可能とすることにより、ユーザの 誤操作を防ぐことができる。
[0027] 図 4 (a)及び図 4 (b)は、図 2に示した XML文書を図 3に示した表にマッピングする ための定義ファイルの例を示す。この定義ファイルは、定義ファイル用に定義された スクリプト言語により記述される。定義ファイルには、コマンドの定義と、表示のテンプ レートが記述されている。図 4 (a) (b)の例では、コマンドとして、「生徒の追加」と「生 徒の削除」が定義されており、それぞれ、ソースツリーにノード「生徒」を挿入する操作 と、ソースツリーからノード「生徒」を削除する操作が対応付けられている。また、テン
プレートとして、表の第 1行に「名前」、「国語」などの見出しが表示され、第 2行以降 に、ノード「生徒」の内容が表示されることが記述されている。ノード「生徒」の内容を 表示するテンプレート中、「text-of」と記述された項は「編集可能」であることを意味し 、「value-of」と記述された項は「編集不可能」であることを意味する。また、ノード「生 徒」の内容を表示する行のうち、第 6列には、「(src:国語 + src:数学 + src:理科 + src: 社会) div 4」という計算式が記述されており、生徒の成績の平均が表示されることを 意味する。
[0028] 図 5は、図 2に示した成績管理ボキヤブラリで記述された XML文書を、図 3に示した 対応により HTMLにマッピングして表示した画面の例を示す。表 90の各行には、左 から、各生徒の名前、国語の成績、数学の成績、理科の成績、社会の成績、及び平 均点が表示されている。ユーザは、この画面上で、 XML文書を編集することができる 。たとえば、第 2行第 3列の値を「70」に変更すると、このノードに対応するソースッリ 一の要素値、すなわち、生徒「B」の数学の成績が「70」に変更される。このとき、 VC ユニット 80は、デスティネーションツリーをソースツリーに追従させるベぐデスティネ ーシヨンツリーの該当箇所を変更し、 HTMLユニット 50力 変更されたデスティネー シヨンツリーに基づいて表示を更新する。したがって、画面上の表においても、生徒「 B」の数学の成績が「70」に変更され、更に、平均点が「55」に変更される。
[0029] 図 5に示した画面には、図 4 (a) (b)に示した定義ファイルに定義されたように、「生 徒の追加」及び「生徒の削除」のコマンドカ -ユーに表示される。ユーザがこれらの コマンドを選択すると、ソースツリーにおいて、ノード「生徒」が追加又は削除される。 このように、本前提技術の文書処理装置 20では、階層構造の末端の構成要素の要 素値を編集するのみではなぐ階層構造を編集することも可能である。このようなッリ 一構造の編集機能は、コマンドの形でユーザに提供されてもよい。また、例えば、表 の行を追加又は削除するコマンドが、ノード「生徒」を追加又は削除する操作に対応 づけられてもよい。また、他のボキヤブラリを埋め込むコマンドがユーザに提供されて もよい。この表を入力用テンプレートとして、穴埋め形式で新たな生徒の成績データ を追加することもできる。以上のように、 VC機能により、 HTMLユニット 50の表示 Z 編集機能を利用しつつ、成績管理ボキヤブラリで記述された文書を編集することが可
能となる。
[0030] 図 6は、ユーザが定義ファイルを生成するために、定義ファイル生成部 86がユーザ に提示するグラフィカルユーザインタフェースの例を示す。画面左側の領域 91には、 マッピング元の XML文書がツリー表示されている。画面右側の領域 92には、マツピ ング先の XML文書の画面レイアウトが示されている。この画面レイアウトは、 HTML ユニット 50により編集可能となっており、ユーザは、画面右側の領域 92において、文 書を表示するための画面レイアウトを作成する。そして、例えば、マウスなどのポイン ティングデバイスにより、画面左側の領域 91に表示されたマッピング元の XML文書 のノードを、画面右側の領域 92に表示された HTMLによる画面レイアウト中へドラッ グ&ドロップ操作を行うことにより、マッピング元のノードと、マッピング先のノードとの コネクションが指定される。例えば、要素「生徒」の子要素である「数学」を、 HTML画 面の表 90の第 1行第 3列にドロップすると、「数学」ノードと、 3列目の「TD」ノードの間 にコネクションが張られる。各ノードには、編集の可否が指定できるようになつている。 また、表示画面中には、演算式を埋め込むこともできる。画面の編集が終わると、定 義ファイル生成部 86は、画面レイアウトとノード間のコネクションを記述した定義フアイ ルを生成する。
[0031] XHTML, MathML、 SVGなどの主要なボキヤブラリに対応したビューヮゃエディ タは既に開発されて 、るが、図 2に示した文書のようなオリジナルなボキヤブラリで記 述された文書に対応したビューヮゃエディタを開発するのは現実的でな 、。しかし、 上記のように、他のボキヤブラリにマッピングするための定義ファイルを作成すれば、 ビューヮゃエディタを開発しなくても、 VC機能を利用して、オリジナルなボキヤブラリ で記述された文書を表示 ·編集することができる。
[0032] 図 7は、定義ファイル生成部 86により生成された画面レイアウトの他の例を示す。図 7の例では、成績管理ボキヤブラリで記述された XML文書を表示するための画面に 、表 90と、円グラフ 93が作成されている。この円グラフ 93は、 SVGにより記述される。 後述するように、本前提技術の文書処理装置 20は、一つの XML文書内に複数のボ キヤブラリを含む複合文書を処理することができるので、この例のように、 HTMLで記 述された表 90と、 SVGで記述された円グラフ 93とを、一つの画面上に表示すること
ができる。
[0033] 図 8は、文書処理装置 20による XML文書の編集画面の一例を示す。図 8の例で は、一つの画面が複数に分割されており、それぞれの領域において、処理対象とな る XML文書を異なる複数の表示形式により表示している。領域 94には、文書のソー スが表示されており、領域 95には、文書のツリー構造が表示されており、領域 96に は、図 5に示した HTMLにより記述された表が表示されている。これらのいずれの画 面上においても、文書の編集が可能であり、いずれかの画面上でユーザが編集を行 うと、ソースツリーが変更され、それぞれの画面の表示を担当するプラグインカ、ソー スツリーの変更を反映すべく画面を更新する。具体的には、ソースツリーの変更を通 知するミューテーシヨンイベントのリスナーとして、それぞれの編集画面の表示を担当 するプラグインの表示部を登録しておき、いずれかのプラグイン又は VCユニット 80に よりソースツリーが変更されたときに、編集画面を表示中の全ての表示部が、発行さ れたミューテーシヨンイベントを受け取って画面を更新する。このとき、プラグインが V C機能により表示を行っている場合は、 VCユニット 80がソースツリーの変更に追従し てデスティネーションツリーを変更した後、変更されたデスティネーションツリーを参照 してプラグインの表示部が画面を更新する。
[0034] 例えば、ソース表示及びツリー表示を、専用のプラグインにより実現している場合は 、ソース表示用プラグインとツリー表示用プラグインは、デスティネーションツリーを用 いず、直接ソースツリーを参照して表示を行う。この場合、いずれかの画面において 編集が行われると、ソース表示用プラグインとツリー表示用プラグインは、変更された ソースツリーを参照して画面を更新し、領域 96の画面を担当して!/、る HTMLユニット 50は、ソースツリーの変更に追従して変更されたデスティネーションツリーを参照して 画面を更新する。
[0035] ソース表示及びツリー表示は、 VC機能を利用して実現することもできる。すなわち 、ソース、ツリー構造を HTMLによりレイアウトし、その HTMLに XML文書をマツピン グして、 HTMLユニット 50により表示してもよい。この場合、ソース形式、ツリー形式、 表形式の 3つのデスティネーションツリーが生成されることになる。いずれかの画面に おいて編集が行われると、 VCユニット 80は、ソースツリーを変更した後、ソース形式、
ツリー形式、表形式の 3つのデスティネーションツリーをそれぞれ変更し、 HTMLュ ニット 50は、それらのデスティネーションツリーを参照して、 3つの画面を更新する。
[0036] このように、一つの画面上に複数の表示形式で文書を表示することにより、ユーザ の利便性を向上させることができる。例えば、ユーザは、ソース表示又はツリー表示 により文書の階層構造を把握しつつ、表 90などを用いて視覚的に分力りやすい形式 で文書を表示し、編集することができる。上記の例では、一つの画面を分割して複数 の表示形式による画面を同時に表示した力 一つの画面に一つの表示形式による画 面を表示し、表示形式をユーザの指示により切り替え可能としてもよい。この場合、主 制御ユニット 22が、ユーザから表示形式の切り替え要求を受け付け、各プラグインに 指示して表示を切り替える。
[0037] 図 9は、文書処理装置 20により編集される XML文書の他の例を示す。図 9に示し た XML文書では、 SVG文書の「foreignObject」タグの中に XHTML文書が埋め込 まれており、さら〖こ、 XHTML文書の中に MathMLで記述された数式が入っている 。このような場合、編集ユニット 24が、名前空間を参照して、適切な表示系に描画作 業を振り分ける。図 9の例では、編集ユニット 24は、まず、 SVGユニット 60に四角形 を描画させ、つづいて、 HTMLユニット 50に XHTML文書を描画させる。さらに、図 示しない MathMLユニットに、数式を描画させる。こうして、複数のボキヤブラリを包 含する複合文書が適切に表示される。表示結果を図 10に示す。
[0038] 文書編集中、カーソル (キャリッジ)の位置に応じて、表示されるメニューを切り替え てもよい。すなわち、カーソルが、 SVG文書が表示された領域内に存在するときは、 SVGユニット 60が提供するメニュー、又は SVG文書をマッピングするための定義フ アイルに定義されたコマンドを表示し、カーソルが、 XHTML文書が表示された領域 内に存在するときは、 HTMLユニット 50が提供するメニュー、又は XHTML文書を マッピングするための定義ファイルに定義されたコマンドを表示する。これにより、編 集位置に応じて適切なユーザインターフェースを提供することができる。
[0039] 複合文書にお!、て、あるボキヤブラリに対応する適切なプラグイン又はマッピング定 義ファイルがな力つた場合は、そのボキヤブラリにより記述された部分は、ソース表示 又はツリー表示されてもよい。従来、ある文書に他の文書を埋め込んだ複合文書を
開くとき、埋め込まれた文書を表示するアプリケーション力 Sインストールされて 、な 、と 、その内容を表示することができな力つた力 本前提技術では、表示用のアプリケー シヨンが存在しなくても、テキストデータにより構成された XML文書をソース表示又は ツリー表示することにより内容を把握することができる。これは、テキストベースである XMLなどの文書ならではの特徴と 、える。
[0040] データがテキストベースで記述されることの他の利点として、例えば、複合文書中の 、あるボキヤブラリにより記述される部分において、同一文書内の他のボキヤブラリで 記述された部分のデータを参照してもよい。また、文書内で検索を実行する時に、 S VGなどの図に埋め込まれた文字列も検索対象とすることができる。
[0041] あるボキヤブラリにより記述された文書内に、他のボキヤブラリのタグを用いてもよい 。この XML文書は、妥当(valid)ではないが、整形式 (welH rmed)であれば、有効な XML文書として処理可能である。この場合、挿入された他のボキヤブラリのタグは、 定義ファイルによりマッピングされてもよい。例えば、 XHTML文書中に、「重要」、「 最重要」などのタグを使用し、これらのタグで囲まれた部分を強調表示してもよ 、し、 重要度の順にソートして表示してもよ 、。
[0042] 図 10に示した編集画面において、ユーザにより文書が編集されると、編集された部 分を担当するプラグイン又は VCユニット 80がソースツリーを変更する。ソースツリー には、ノードごとにミューテーシヨンイベントのリスナーを登録できるようになっており、 通常は、各ノードが属するボキヤブラリに対応したプラグインの表示部又は VCュ-ッ ト 80がリスナーとして登録される。 DOM提供部 32は、ソースツリーが変更されると、 変更されたノードから上位の階層へたどって、登録されたリスナーがあれば、そのリス ナ一へミューテーシヨンイベントを発行する。例えば、図 9に示した文書において、く html >ノードの下位のノードが変更された場合、く html >ノードにリスナーとして登 録された HTMLユニット 50にミューテーシヨンイベントが通知されるとともに、その上 位のく svg>ノードにリスナーとして登録された SVGユニット 60にもミューテーシヨン イベントが通知される。このとき、 HTMLユニット 50は、変更されたソースツリーを参 照して表示を更新する。 SVGユニット 60は、自身のボキヤブラリに属するノードが変 更されて!/、な!/、ので、ミューテーシヨンイベントを無視してもよ!/、。
[0043] 編集の内容によっては、 HTMLユニット 50による表示の更新に伴って、全体のレイ アウトが変わる可能性がある。この場合は、画面のレイアウトを管理する構成、例えば 最上位のノードの表示を担当するプラグインにより、プラグインごとの表示領域のレイ アウトが更新される。例えば、 HTMLユニット 50による表示領域が以前より大きくなつ た場合、 HTMLユニット 50は、まず自身の担当する部分を描画して、表示領域の大 きさを決定する。そして、画面のレイアウトを管理する構成に、変更後の表示領域の 大きさを通知し、レイアウトの更新を依頼する。画面のレイアウトを管理する構成は、 通知を受けて、プラグインごとの表示領域を再レイアウトする。こうして、編集された部 分の表示が適切に更新されるとともに、画面全体のレイアウトが更新される。
[0044] つづいて、前提技術の文書処理装置 20を実現する機能構成について更に詳細に 説明する。以下の説明では、クラス名などを記載する際には、英字をそのまま用いて 記載することにする。
[0045] A.概要
インターネットの出現により、ユーザによって処理され管理される文書の数力 ほぼ 指数関数的に増加してきた。インターネットの核を形成するウェブ (World Wide Web) は、そのような文書データの大きな受け皿となっている。ウェブは、文書にカ卩えて、こ のような文書の情報検索システムを提供する。これらの文書は、通常、マークアップ 言語により記述される。マークアップ言語のシンプルかつポピュラーな例の一つに H TML (HyperText Markup Language)がある。このような文書は、ウェブの他の位置に 格納されている他の文書へのリンクをさらに含む。 XML (eXtens¾le Markup Languag e)は、さらに高度でポピュラーなマークアップ言語である。ウェブ文書にアクセスし、 閲覧するためのシンプルなブラウザ力 Java (登録商標)のようなオブジェクト指向の プログラミング言語で開発されて 、る。
[0046] マークアップ言語により記述された文書は、通常、ブラウザや他のアプリケーション の中では、ツリーデータ構造の形で表現される。この構造は、文書を構文解析した結 果のツリーに相当する。 DOM (Document Object Model)は、文書を表現し、操作す るために使用される、よく知られたツリーベースのデータ構造モデルである。 DOMは 、 HTMLや XML文書などを含む文書を表現するための標準的なオブジェクトのセッ
トを提供する。 DOMは、文書内のコンポーネントを表現するオブジェクトがどのように つながっているかという標準モデルと、それらのオブジェクトにアクセスしたり操作した りするための標準インタフェイスという、 2つの基本的なコンポーネントを含む。
[0047] アプリケーション開発者は、独自のデータ構造や API (Application Program Interfac e)へのインタフェイスとして DOMをサポートすることができる。他方、文書を作成する アプリケーション開発者は、彼らの APIの独自インタフェイスではなぐ DOMの標準 インタフェイスを使用することができる。したがって、標準を提供するというその能力に より、 DOMは、様々な環境、特にウェブにおいて、文書の相互利用を促進させるた めに有効である。 DOMのいくつかのバージョンが定義されており、異なるプログラミ ング環境及びアプリケーションによって使用されている。
[0048] DOMツリーは、対応する DOMの内容に基づいた文書の階層的表現である。 DO Mツリーは「根 (ルート)」、及びルートから発生する 1つ以上の「節(ノード)」を含む。 ルートが文書全体を表す場合もある。中間のノードは、例えば、テーブル及びそのテ 一ブル中の行及び列のような要素を表すことができる。 DOMツリーの「葉」は、通常、 それ以上分解できな!、テキストや画像のようなデータを表す。 DOMツリーの各ノード は、フォント、サイズ、色、インデントなど、ノードによって表される要素のパラメータを 記述する属性に関連付けられてもよい。
[0049] HTMLは、文書を作成するために一般に用いられる言語である力 フォーマット及 びレイアウト用の言語であり、データ記述のための言語ではない。 HTMLドキュメント を表現する DOMツリーのノードは、 HTMLのフォーマッティングタグとして予め定義 されたエレメントであって、通常、 HTMLは、データの詳述や、データのタギング Zラ ベリングのための機能を提供しな!、ので、 HTMLドキュメント中のデータに対するク エリを定式ィ匕することは多くの場合困難である。
[0050] ネットワーク設計者たちの目指すものは、ウェブ上の文書がソフトウェアアプリケーシ ヨンによってクエリされたり処理されたりできるようにすることである。表示方法とは無関 係で、階層的に構造ィ匕された言語であれば、そのようにクエリされ処理されることがで きる。 XML (extensible Markup Language)のようなマークアップ言語は、これらの特 徴を提供することができる。
[0051] HTMLとは逆に、 XMLのよく知られた利点は、文書の設計者が自由に定義可能 な「タグ」を使用して、データ要素にラベルを付けることが可能である点である。このよ うなデータ要素は、階層的に構造ィ匕することができる。さらに、 XML文書は、文書内 で用いられるタグ及びそれらの相互関係の「文法」を記述した文書型定義を含むこと ができる。構造ィ匕された XML文書の表示方法を定義するために、 CSS (Cascading S tyle Sheet)又は XSL (XML Style Language)が使用される。 DOM、 HTML, XML、 CSS、 XSL及び関連する言語の特徴に関する付加的な情報は、ウェブからも得るこ とができる。 (例えば、 http://www.w3.org/TR/)
[0052] Xpathは、 XML文書の部分の位置を指定するために共通のシンタックス及びセマ ンテイクスを提供する。機能性の例として、 XML文書に対応する DOMツリーのトラバ ース (移動)がある。それは、 XML文書の様々な表現に関連した文字列、数、及びブ ーリアン文字の操作のための基本的な機能を提供する。 Xpathは、 XML文書の見 た目のシンタックス、例えば、テキストとしてみたときに何行目であるとか何文字目であ るとかと!/、つた文法ではなぐ DOMツリーなどの抽象的 ·論理的な構造にぉ 、て動 作する。 Xpathを使用することにより、例えば XML文書の DOMツリー内の階層的構 造を通じて場所を指定することができる。アドレシングのための使用の他に、 Xpath は、 DOMツリー中のノードがパターンにマッチするか否かをテストするために使用さ れるようにも設計されている。 XPathに関する更なる詳細は、 http:〃 www. w3.org/TR /xpathで得ることができる。
[0053] XMLの既知の利点及び特徴により、マークアップ言語 (例えば XML)で記述され た文書を扱うことができ、文書を作成及び修正するためのユーザフレンドリーなインタ フェイスを提供することができる、効果的な文書処理システムが求められる。
[0054] ここで説明されるシステムの構成のうちのいくつかは、 MVC (Modd-View-Controll er)と呼ばれる、よく知られた GUI (Graphical User Interface)パラダイムを用いて説明 される。 MVCパラダイムは、アプリケーション又はアプリケーションのインタフェイスの 一部を、 3つの部分、すなわち、モデル、ビュー、コントローラに分割する。 MVCは、 元は、 GUIの世界に、従来の入力、処理、出力の役割を割り当てるために開発され
[入力]→ [処理]→ [出力]
[コントローラ]→ [モデル]→ [ビュー]
[0055] MVCパラダイムによれば、外界のモデリング、ユーザへの視覚的なフィードバック、 及びユーザの入力は、モデル(M)、ビュー(V)、及びコントローラ(C)オブジェクトに より分離されて扱われる。コントローラは、ユーザからのマウスとキーボード入力のよう な入力を解釈し、これらのユーザアクションを、適切な変更をもたらすためにモデル 及び Z又はビューに送られるコマンドにマップするように作用する。モデルは、 1以上 のデータ要素を管理するように作用し、その状態に関するクエリに応答し、状態を変 更する指示に応答する。ビューは、ディスプレイの長方形の領域を管理するように作 用し、グラフィクスとテキストの組合せによりユーザにデータを提示する機能を有する
[0056] B.文書処理システムの全体構成
文書処理システムの実施例は、図 11— 29に関連して明らかにされる。
[0057] 図 11 (a)は、後述するタイプの文書処理システムの基礎として機能する要素の従来 の構成例を示す。構成 10は、通信経路 13によりメモリ 12に接続された CPU又はマ イク口プロセッサ 11などの形式のプロセッサを含む。メモリ 12は、現在又は将来に利 用可能な任意の ROM及び Z又は RAMの形式であってもよい。通信経路 13は、典 型的にはバスとして設けられる。マウス、キーボード、音声認識システムなどのユーザ 入力装置 14及び表示装置 15 (又は他のユーザインタフェイス)に対する入出力イン タフェイス 16も、プロセッサ 11とメモリ 12の通信のためのバスに接続される。この構成 は、スタンドアロンであってもよいし、複数の端末及び 1以上のサーバが接続されてネ ットワーク化された形式であってもよ 、し、既知の 、かなる方式により構成されてもよ い。本発明は、これらのコンポーネントの配置、集中又は分散されたアーキテクチャ 一、あるいは様々なコンポーネントの通信方法により制限されない。
[0058] さらに、本システム及びここで議論される実施例は、様々な機能性を提供する 、く つかのコンポーネント及びサブコンポーネントを含むものとして議論される。これらの コンポーネント及びサブコンポーネントは、注目された機能性を提供するために、ハ 一ドウエアとソフトウェアの組合せだけでなぐハードウェアのみ、ソフトウェアのみによ
つても実現されうる。さらに、ハードウェア、ソフトウェア、及びそれらの組合せは、汎用 の計算装置、専用のハードウェア、又はそれらの組合せにより実現されうる。したがつ て、コンポーネント又はサブコンポーネントの構成は、コンポーネント又はサブコンポ 一ネントの機能性を提供するための特定のソフトウェアを実行する汎用 Z専用の計 算装置を含む。
[0059] 図 11 (b)は、文書処理システムの一例の全体のブロック図を示す。このような文書 処理システムにおいて文書が生成され編集される。これらの文書は、例えば XMLな ど、マークアップ言語の特徴を有する任意の言語により記述されてもよい。また、便宜 上、特定のコンポーネント及びサブコンポーネントの用語及び表題を創造した。しか しながら、これらは、この開示の一般的な教示の範囲を制限するために解釈されるべ きではない。
[0060] 文書処理システムは、 2つの基本的な構成を有するものととらえることができる。第 1 の構成は、文書処理システムが動作する環境である「実行環境」 101である。例えば 、実行環境は、文書の処理中及び管理中に、ユーザだけでなくシステムも支援する、 基本的なユーティリティ及び機能を提供する。第 2の構成は、実行環境において走る アプリケーション力も構成される「アプリケーション」 102である。これらのアプリケーシ ヨンは、文書自身及び文書の様々な表現を含む。
[0061] 1.実行環境
実行環境 101のキーとなるコンポーネントは Programlnvoker (プログラムインボー力: プログラム起動部) 103である。 Programlnvokerl03は、文書処理システムを起動す るためにアクセスされる基本的なプログラムである。例えば、ユーザが文書処理シス テムにログオンして開始するとき、 Programlnvokerl03が実行される。 Programlnvoker 103は、例えば、文書処理システムにプラグインとしてカ卩えられた機能を読み出して 実行させたり、アプリケーションを開始して実行させたり、文書に関連するプロパティ を読み出すことができる。 Programlnvokerl03の機能はこれらに限定されない。ユー ザが実行環境内で実行されるように意図されたアプリケーションを起動した 、とき、 Pr ogramlnvokerl03は、そのアプリケーションを見つけ、それを起動して、アプリケーシ ヨンを実行する。
[0062] Programlnvokerl03には、プラグインサブシステム 104、コマンドサブシステム 105 、及び Resource (リソース)モジュール 109などのいくつかのコンポーネントがアタッチ されている。これらの構成については、以下に詳述する。
[0063] a)プラグインサブシステム
プラグインサブシステム 104は、文書処理システムに機能を追加するための高度に 柔軟で効率的な構成として使用される。プラグインサブシステム 104は、また、文書処 理システムに存在する機能を修正又は削除するために使用することができる。さらに 、種々様々の機能をプラグインサブシステムを使用して追加又は修正することができ る。例えば、画面上への文書の描画を支援するように作用する Editlet (エディットレツ ト:編集部)機能を追加することもできる。 Editletプラグインは、システムに追加される ボキヤブラリの編集も支援する。
[0064] プラグインサブシステム 104は、 ServiceBroker (サービスブローカ:サービス仲介部) 1041を含む。 ServiceBrokerl041は、文書処理システムに加えられるプラグインを管 理することにより、文書処理システムに加えられるサービスを仲介する。
[0065] 所望の機能性を実現する個々の機能は、 Service (サービス) 1042の形でシステム に追加される。利用可能な Servicel042のタイプは、 Application (アプリケーション)サ 一ビス、 ZoneFactory (ゾーンファクトリ:ゾーン生成部) Service, Editlet (エディットレツ ト:編集部) Service、 CommandFactory (コマンドファクトリ:コマンド生成部) Serviceゝ C onnectXPath (コネクト XPath:XPath管理部) Service、 CSSComputation (CSSコンビ ユーテーシヨン: CSS計算部) Serviceなどを含む力 これらに限定されない。これらの Service,及びシステムの他の構成とそれらとの関係は、文書処理システムについての よりよい理解のために、以下に詳述される。
[0066] プラグインと Serviceの関係は以下の通りである。プラグインは、 1以上の ServiceProvi der (サービスプロバイダ:サービス提供部)を含むことができるユニットである。それぞ れの ServiceProviderは、それに関連した Serviceの 1以上のクラスを有する。例えば、 適切なソフトウェアアプリケーションを有する単一のプラグインを使用することにより、 1 以上の Serviceをシステムに追加することができ、これにより、対応する機能をシステム に追加することができる。
[0067] b)コマンドサブシステム
コマンドサブシステム 105は、文書の処理に関連したコマンドの形式の命令を実行 するために使用される。ユーザは、一連の命令を実行することにより、文書に対する 操作を実行することができる。例えば、ユーザは、コマンドの形で命令を発行すること により、文書処理システム中の XML文書に対応する XMLの DOMツリーを編集し、 XML文書を処理する。これらのコマンドは、キーストローク、マウスクリック、又は他の 有効なユーザインタフェイスアクションを使用して入力されてもよい。 1つのコマンドに より 1以上の命令が実行されることもある。この場合、これらの命令が 1つのコマンドに ラップ (包含)され、連続して実行される。例えば、ユーザが、誤った単語を正しい単 語に置換したいとする。この場合、第 1の命令は、文書中の誤った単語を発見するこ とであり、第 2の命令は、誤った単語を削除することであり、第 3の命令は、正しい単語 を挿入することであってもよい。これらの 3つの命令が 1つのコマンドにラップされても よい。
[0068] コマンドは、関連した機能、例えば、後で詳述する「アンドゥ」機能を有してもょ 、。こ れらの機能は、オブジェクトを生成するために使用されるいくつかの基本クラスにも割 り当てられてもよい。
[0069] コマンドサブシステム 105のキーとなるコンポーネントは、選択的にコマンドを与え、 実行するように作用する Commandlnvoker (コマンドインボー力:コマンド起動部) 105 1である。図 11 (b)には、 1つの Commandlnvokerのみが示されているが、 1以上の Co mmandlnvokerが使用されてもよぐ 1以上のコマンドが同時に実行されてもよい。 Com mandlnvokerl051は、コマンドを実行するために必要な機能及びクラスを保持する。 動作において、実行されるべき Command (コマンド:命令) 1052は、 Queue (キュー) 1 053に積まれる。 Commandlnvokerは、連続的に実行するコマンドスレッドを生成する 。 Commandlnvoker内で既に実行中の Commandがなければ、 Commandlnvoker 1051 により実行されるように意図された Commandl052が実行される。 Commandlnvokerが 既にコマンドを実行している場合、新しい Commandは、 Queuel053の最後に積まれ る。しかしながら、それぞれの Commandlnvokerl051では、一度に 1つの Commandの みが実行される。指定された Commandの実行に失敗した場合、 CommandlnvokerlO
51は例外処理を実行する。
[0070] Commandlnvokerl051により実行される Commandの型は、 UndoableCommand (取 消可能コマンド) 1054、 AsynchronousCommand (非同期コマンド) 1055、及び VCCo mmand (VCコマンド) 1056を含む力 これらに限定されない。 UndoableCommand 10 54は、ユーザが望めば、その Commandの結果を取り消すことが可能な Commandであ る。 UndoableCommandの例として、切り取り、コピー、テキストの挿入、などがある。動 作において、ユーザが文書の一部を選択し、その部分に切り取りコマンドを適用する とき、 UndoableCommandを用いることにより、切り取られた部分は、必要であれば、「 切り取られて ヽな 、」ようにすることができる。
[0071] VCCommandl056は、ボキヤブラリコネクション記述子(Vocabulary Connection De scriptor: VCD)スクリプトファイルに格納される。これらは、プログラマにより定義されう るユーザ指定の Commandである。 Commandは、例えば、 XMLフラグメントを追加した り、 XMLフラグメントを削除したり、属性を設定したりするための、より抽象的な Comm andの組合せであってもよい。これらの Commandは、特に、文書の編集に焦点を合わ せている。
[0072] AsynchronousCommand 1055 ¾ ,文書のロードや保存など、システムよりの Comman dであり、 UndoableCommandや VCCommandとは別に、非同期的に実行される。 Async hronousCommandは、 UndoableCommandではないので、取り消すことはできない。
[0073] c)リソース
Resourcel09は、様々なクラスに、いくつかの機能を提供するオブジェクトである。 例えば、ストリングリソース、アイコン、及びデフォルトキーバインドは、システムで使用 される Resourceの例である。
[0074] 2.アプリケーションコンポーネント
文書処理システムの第 2の主要な特徴であるアプリケーションコンポーネント 102は 、実行環境 101において実行される。アプリケーションコンポーネント 102は、実際の 文書と、システム内における文書の様々な論理的、物理的な表現を含む。さらに、ァ プリケーシヨンコンポーネント 102は、文書を管理するために使用されるシステムの構 成を含む。アプリケーションコンポーネント 102は、さらに、 UserApplication (ユーザァ
プリケーシヨン) 106、アプリケーションコア 108、ユーザインタフェイス 107、及び Core Component (コアコンポーネント) 110を含む。
[0075] a)ユーザアプリケーション
UserApplicationl06は、 Programlnvokerl03と共にシステム上にロードされる。 User Applicationl06は、文書と、文書の様々な表現と、文書と対話するために必要なユー ザインタフェイスとをつなぐ接着剤となる。例えば、ユーザが、プロジェクトの一部であ る文書のセットを生成したいとする。これらの文書がロードされると、文書の適切な表 現が生成される。ユーザインタフェイス機能は、 UserApplicationl06の一部として追 カロされる。言いかえれば、 UserApplicationl06は、ユーザがプロジェクトの一部を形 成する文書と対話することを可能とする文書の表現と、文書の様々な態様とを、共に 保持する。ー且 UserApplicationl06が生成されると、ユーザがプロジェクトの一部を 形成する文書との対話を望むたびに、ユーザは簡単に実行環境上に UserApplicatio nl06をロードすることができる。
[0076] b)コアコンポーネント
CoreComponentl 10は、複数の Pane (ペイン)の間で文書を共有する方法を提供す る。後で詳述するように、 Paneは、 DOMツリーを表示し、画面の物理的なレイアウトを 扱う。例えば、物理的な画面は、個々の情報の断片を描写する画面内の複数の Pane 力もなる。ユーザから画面上に見える文書は、 1又はそれ以上の Paneに出現しうる。 また、 2つの異なる文書が画面上で 2つの異なる Paneに現れてもよ!、。
[0077] 図 11 (c)に示されるように、画面の物理的なレイアウトもツリーの形式になっている。
Paneは、 RootPane (ルートペイン) 1084にもなり得るし、 SubPane (サブペイン) 1085 にもなり得る。 RootPanel084は、 Paneのツリーの根に当たる Paneであり、 SubPane 10 85は、 RootPanel084以外の任意の Paneである。
[0078] CoreComponentl 10は、さらに、フォントを提供し、ツールキットなど、文書のための 複数の機能的な操作のソースの役割を果たす。 CoreComponentl 10により実行され るタスクの一例に、複数の Pane間におけるマウスカーソルの移動がある。実行される タスクの他の例として、ある Pane中の文書の一部をマークし、それを異なる文書を含 む別の Pane上にコピーする。
[0079] c)アプリケーションコア
上述したように、アプリケーションコンポーネント 102は、システムにより処理され管 理される文書から構成される。これは、システム内における文書の様々な論理的及び 物理的な表現を含む。アプリケーションコア 108は、アプリケーションコンポーネント 1 02の構成である。その機能は、実際の文書を、それに含まれる全てのデータとともに 保持することである。アプリケーションコア 108は、 DocumentManager (ドキュメントマネ 一ジャ:文書管理部) 1081及び Document (ドキュメント:文書) 1082自身を含む。
[0080] DocumentManagerl081の様々な態様を以下に詳述する。 DocumentManager 108 1は、 Documentl082を管理する。 DocumentManagerl081は、 RootPanel084、 Sub Pane 1085, ClipBoard (クリップボード)ユーティリティ 1087、及び Snapshot (スナップ ショット)ユーティリティ 1088にも接続される。 ClipBoardユーティリティ 1087は、ユー ザがクリップボードに加えることを決定した文書の部分を保持する方法を提供する。 例えば、ユーザが、文書の一部を切り取り、後で再考するために新規文書にそれを 保存することを望んだとする。このような場合、切り取られた部分力 SClipBoardに追加さ れる。
[0081] つづいて、 Snapshotユーティリティ 1088についても説明する。 Snapshotユーティリ ティ 1088は、アプリケーションがある状態力も別の状態まで移行するときに、アプリケ ーシヨンの現在の状態を記憶することを可能とする。
[0082] d)ユーザインタフェイス
アプリケーションコンポーネント 102の別の構成は、ユーザがシステムと物理的に対 話する手段を提供するユーザインタフェイス 107である。例えば、ユーザインタフェイ スは、ユーザが文書をアップロードしたり、削除したり、編集したり、管理したりするた めに使用される。ユーザインタフェイスは、 Frame (フレーム) 1071、 MenuBar (メ -ュ 一バー) 1072、 StatusBar (ステータスバー) 1073、及び URLBar(URLバー) 1074 を含む。
[0083] Framel071は、一般に知られているように、物理的な画面のアクティブな領域であ るとみなされる。 MenuBarl072は、ユーザに選択を提供するメニューを含む画面領 域である。 StatusBarl073は、アプリケーションの実行状態を表示する画面領域であ
る。 URLBarl074は、インターネットをナビゲートするために URLアドレスを入力する 領域を提供する。
[0084] C.文書管理及び関連するデータ構造
図 12は、 DocumentManagerl081の詳細を示す。これは、文書処理システム内で 文書を表現するために用いられるデータ構造及び構成を含む。分かりやすくするた めに、このサブセクションで説明される構成は、 MVCパラダイムを用いて説明される
[0085] DocumentManagerl081は、文書処理システム内にある全ての文書を保持しホスト する DocumentContainer (ドキュメントコンテナ:文書コンテナ) 203を含む。 Document Managerl081にアタッチされたツールキット 201は、 DocumentManagerl081により 使用される様々なツールを提供する。例えば、 DomService (DOMサービス)は、文書 に対応する DOMを生成し、保持し、管理するために必要とされる全ての機能を提供 するために、ツールキット 201により提供されるツールである。ツールキット 201により 提供される別のツールである IOManager (入出力管理部)は、システムへの入力及び システムからの出力を管理する。同様に、 StreamHandler (ストリームハンドラ)は、ビッ トストリームによる文書のアップロードを扱うツールである。これらのツールは、図中に 特に示さず、参照番号を割り当てないが、ツールキット 201のコンポーネントを形成す る。
[0086] MVCパラダイムの表現によれば、モデル(M)は、文書の DOMツリーモデル 202 を含む。前述したように、全ての文書は、文書処理システムにおいて DOMツリーとし て表現される。文書は、また、 DocumentContainer203の一部を形成する。
[0087] 1. DOMモデノレ及びゾーン
文書を表現する DOMツリーは、 Node (ノード) 2021を有するツリーである。 DOMッ リーの部分集合である Zone (ゾーン) 209は、 DOMツリー内の 1以上の Nodeの関連 領域を含む。例えば、画面上で文書の一部のみを表示し得るが、この可視化された 文書の一部は Zone209を用いて表示される。 Zoneは、 ZoneFactory (ゾーンファクトリ: ゾーン生成部) 205と呼ばれるプラグインを用いて、生成され、取り扱われ、処理され る。 Zoneは DOMの一部を表現する力 1以上の「名前空間」を使用してもよい。よく
知られているように、名前空間は、名前空間内でユニークな名前の集合である。換言 すれば、名前空間内に同じ名前は存在しない。
[0088] 2. Facet及び Facetと Zoneとの関係
Facet (ファセット) 2022は、 MVCパラダイムのモデル(M)部分内の別の構成であ る。 Facetは、 Zoneにおいて Nodeを編集するために使用される。 Facet2022は、 Zone 自身の内容に影響を与えずに実行することができる手続 (プロシージャ)を使用して、 DOMへのアクセスを編成する。次に説明するように、これらの手続は、 Nodeに関連 した重要で有用な操作を実行する。
[0089] 各 Nodeは、対応する Facetを有する。 DOMの中の Nodeを直接操作する代わりに、 操作を実行するために Facetを使用することによって、 DOMの保全性は保護される。 操作が Node上で直接実行される場合、いくつかのプラグインが DOMを同時に変更 することができ、その結果矛盾を引き起こす。
[0090] W3Cが策定した DOMの標準規格は、 Nodeを操作するための標準的なインタフエ イスを定義する力 実際には、ボキヤブラリごと又は Nodeごとに特有の操作があるの で、これらの操作を APIとして用意しておくのが好都合である。文書処理システムで は、このような各 Nodeに特有の APIを Facetとして用意し、各 Nodeにアタッチする。こ れにより、 DOMの標準規格に準拠しつつ、有用な APIを付加することができる。また 、ボキヤブラリごとに特有の DOMを実装するのではなぐ標準的な DOMの実装に、 後から特有の APIを付加するようにすることで、多様なボキヤブラリを統一的に処理 することができるともに、複数のボキヤブラリが任意の組合せで混在した文書を適切 に処理することができる。
[0091] ボキヤブラリは、名前空間に属するタグ (例えば XMLのタグ)のセットである。上述し たように、名前空間は、ユニークな名前 (ここではタグ)のセットを有する。ボキヤブラリ は、 XML文書を表現する DOMツリーのサブツリーとして現れる。このサブツリーは Z oneを含む。特定の例においては、タグセットの境界は Zoneによって定義される。 Zon e209は、 ZoneFactory205と呼ばれる Serviceを利用して生成される。上述したように 、 Zone209は、文書を表現する DOMツリーの一部の内部表現である。このような文 書の一部へのアクセスを提供するために、論理的な表現が要求される。この論理的
表現は、文書が画面上で論理的にどのように表現されるかについてコンピュータに通 知する。 Canvas (キャンバス) 210は、 Zoneに対応する論理的なレイアウトを提供する ように作用する Serviceである。
[0092] 他方、 Pane211は、 Canvas210により提供される論理的なレイアウトに対応する物 理的な画面レイアウトである。実際、ユーザは表示画面上で文字や画像によって文 書のレンダリングのみを見る。したがって、文書は、画面上に文字や画像を描画する プロセスにより、画面上に描写されなければならない。文書は、 Pane211により提供さ れる物理的なレイアウトに基づいて、 Canvas210により画面上に描写される。
[0093] Zone209に対応する Canvas210は、 Editlet206を使用して生成される。文書の DO Mは、 Editlet206及び Canvas210を使用して編集される。元の文書の完全性を維持 するために、 Editlet206及び Canvas210は、 Zone209における 1以上の Nodeに対応 する Facetを使用する。これらの Serviceは、 Zone及び DOM内の Nodeを直接操作しな い。 Facetは、 Command207を利用して操作される。
[0094] ユーザは、一般に、画面上のカーソルを移動させたり、コマンドをタイプしたりするこ とによって、画面と対話する。画面上の論理的なレイアウトを提供する Canvas210は、 このカーソル操作を受け付ける。 Canvas210は、対応するアクションを Facetに実行さ せることができる。この関係により、カーソルサブシステム 204は、 DocumentManagerl 081に対して、 MVCパラダイムのコントローラ(C)として機能する。 Canvas210は、ィ ベントを扱うタスクも有する。例えば、 Canvas210は、マウスクリック、フォーカス移動、 及びユーザにより起こされた同様のアクションなどのイベントを扱う。
[0095] 3. Zone, Facet, Canvas及び Paneの間の関係の概要
文書処理システム内の文書は、少なくとも 4つの観点から見ることができる。すなわ ち、 1)文書処理システムにおいて文書の内容及び構造を保持するために用いられる データ構造、 2)文書の保全性に影響を与えずに文書の内容を編集する手段、 3)文 書の画面上の論理的なレイアウト、 4)文書の画面上の物理的なレイアウト、である。 Z one, Facet, Canvas及び Paneは、前述の 4つの観点に相当する、文書処理システム のコンポーネントをそれぞれ表す。
[0096] 4.アンドゥサブシステム
上述したように、文書に対するいかなる変更 (例えば編集)も取消可能であることが 望ましい。例えば、ユーザが編集操作を実行し、次に、その変更の取消を決定したと する。図 12に関連して、アンドゥサブシステム 212は、文書管理部の取消可能なコン ポーネントを実現する。 UndoManager (アンドゥマネージャ:アンドゥ管理部) 2121は、 ユーザによって取り消される可能性のある全ての文書に対する操作を保持する。
[0097] 例えば、ユーザが、文書中の単語を別の単語に置換するコマンドを実行したとする 。その後、ユーザは考え直し、元の単語に戻すことを決定したとする。アンドゥサブシ ステム 212は、このような操作を支援する。 UndoManager2121は、このような Undoabl eEdit (アンドゥアプルエディット:取消可能な編集) 2122の操作を保持する。
[0098] 5.カーソノレサブシステム
前述したように、 MVCのコントローラ部分は、カーソルサブシステム 204を備えても よい。カーソルサブシステム 204は、ユーザ力も入力を受け付ける。これらの入力は、 一般にコマンド及び Z又は編集操作の性格を有している。したがって、カーソルサブ システム 204は、 DocumentManagerl081に関連した MVCパラダイムのコントローラ( C)部分であると考えることができる。
[0099] 6.ビュー
前述したように、 Canvas210は、画面上に提示されるべき文書の論理的なレイアウト を表す。 XHTML文書の例では、 Canvas210は、文書が画面上でいかに見えるかを 論理的に表現したボックスツリー 208を含んでもよい。このボックスツリー 208は、 Doc umentManager 1081に関連した MVCパラダイムのビュー(V)部分に含まれよう。
[0100] D.ボキヤブラリコネクション
文書処理システムの重要な特徴は、 XML文書を、他の表現にマップして取り扱うこ とが可能で、かつ、マップした先の表現を編集すると、その編集が元の XML文書に 整合性を保ちつつ反映される環境を提供することにある。
[0101] マークアップ言語により記述された文書、例えば XML文書は、文書型定義により定 義されたボキヤブラリに基づいて作成されている。ボキヤブラリは、タグのセットである 。ボキヤブラリは、任意に定義されてもよいため、無限に多くのボキヤブラリが存在しう る。し力しながら、多数の可能なボキヤブラリのそれぞれに対して専用の処理 Z管理
環境を提供するのは現実的ではない。ボキヤブラリコネクションは、この問題を解決す る方法を提供する。
[0102] 例えば、文書は 2以上のマークアップ言語により記述されてもよい。文書は、例えば 、 XHTML (.extensible HyperText Markup Language)、 ¾ V"G (Scalable Vector Grap hies)、 MathML (Mathematical Markup Language)、その他のマークアップ言語によ り記述されてもよい。換言すれば、マークアップ言語は、 XMLにおけるボキヤブラリゃ タグセットと同様に見なされてもよい。
[0103] ボキヤブラリは、ボキヤブラリプラグインを用いて処理される。文書処理システムにお いてプラグインが利用不可能であるボキヤブラリにより記述された文書は、プラグイン が利用可能である別のボキヤブラリの文書にマッピングすることにより表示される。こ の特徴により、プラグインが用意されていないボキヤブラリの文書も適切に表示するこ とがでさる。
[0104] ボキヤブラリコネクションは、定義ファイルを取得し、取得した定義ファイルに基づい て 2つの異なるボキヤブラリの間でマッピングする能力を含む。あるボキヤブラリで記 述された文書は、別のボキヤブラリにマッピングすることができる。このように、ボキヤ ブラリコネクションは、文書がマッピングされるボキヤブラリに対応した表示 Z編集ブラ グィンにより文書を表示し編集することを可能にする。
[0105] 上述したように、各文書は、一般に複数のノードを有する DOMツリーとして文書処 理システムにおいて記述される。「定義ファイル」は、それぞれのノードについて、そ のノードと他のノードとの対応を記述する。各ノードの要素値及び属性値が編集可能 か否かが指定される。ノードの要素値又は属性値を用いた演算式が記述されてもよ い。
[0106] マッピングという特徴を利用して、定義ファイルを適用したデスティネーション DOM ツリーが生成される。このように、ソース DOMツリーとデスティネーション DOMツリー の関係が構築され保持される。ボキヤブラリコネクションは、ソース DOMツリーとデス ティネーシヨン DOMツリーの対応を監視する。ユーザ力も編集指示を受けると、ボキ ャブラリコネクションは、ソース DOMツリーの関連したノードを変更する。ソース DOM ツリーが変更されたことを示す「ミューテーシヨンイベント」が発行され、デスティネーシ
ヨン DOMツリーがそれに応じて変更される。
[0107] ボキヤブラリコネクションの使用により、少数のユーザのみに知られていた比較的マ イナ一なボキヤブラリを、別のメジャーなボキヤブラリに変換することができる。したが つて、少数のユーザによって利用されるマイナーなボキヤブラリであっても、文書を適 切に表示し、望ましい編集環境を提供することができる。
[0108] このように、文書処理システムの一部であるボキヤブラリコネクションサブシステムは 、文書の複数の表現を可能にする機能を提供する。
[0109] 図 13は、ボキヤブラリコネクション(VC : Vocabulary Connection)サブシステム 300 を示す。 VCサブシステム 300は、同一の文書の 2つの代替表現の整合性を維持す る方法を提供する。例えば、 2つの表現は、同一文書の、 2つの異なるボキヤブラリに よる表現であってもよい。前述したように、一方はソース DOMツリーであってもよぐ 他方はデスティネーション DOMツリーであってもよい。
[0110] 1.ボキヤブラリコネクションサブシステム
ボキヤブラリコネクションサブシステム 300の機能は、 VocabularyConnection301と 呼ばれるプラグインを使用して、文書処理システムにおいて実現される。文書が表現 される Vocabulary305ごとに、対応するプラグインが要求される。例えば、文書の一部 が HTMLで記述され、残りが SVGで記述されている場合、 HTMLと SVGに対応す るボキヤブラリブラグィンが要求される。
[0111] VocabularyConnectionプラグイン 301は、適切な Vocabulary305の文書に対応した 、 Zone209又は Pane211のための適切な VCCanvas (ボキヤブラリコネクションキャン バス) 310を生成する。 VocabularyConnection301を用いて、ソース DOMツリー内の Zone209に対する変更は、変換ルールにより、別の DOMツリー 306の対応する Zone に伝達される。変換ルールは、ボキヤブラリコネクション記述子(Vocabulary Connecti on Descriptor: VCD)の形式で記述される。このようなソース DOMとデスティネーショ ン DOMの間の変換に対応するそれぞれの VCDファイルにつ!/、て、対応する VCMa nager (ボキヤブラリコネクションマネージャ) 302が生成される。
[0112] 2. Connector
Connector304は、ソース DOMツリーのソースノードと、デスティネーション DOMッ
リーのデスティネーションノードとを接続する。 Connector304は、ソース DOMツリー 中のソースノード、及びソースノードに対応するソース文書に対する修正 (変更)を見 るために作用する。そして、対応するデスティネーション DOMツリーのノードを修正 する。 Connector304は、デスティネーション DOMツリーを修正することができる唯一 のオブジェクトである。例えば、ユーザは、ソース文書、及び対応するソース DOMッリ 一に対してのみ修正を行うことができる。その後、 Connector304がデスティネーショ ン DOMツリーに、対応する修正を行う。
[0113] Connector304は、ツリー構造を形成するために、論理的にリンクされる。 Connector 304により形成されたツリーは、 ConnectorTree (コネクタツリー)と呼ばれる。 Connect or304は、 ConnectorFactory (コネクタファクトリ:コネクタ生成部) 303と呼ばれる Servi ceを用いて生成される。 ConnectorFactory303は、ソース文書から Connector304を 生成し、それらをリンクして ConnectorTreeを形成する。 VocabularyConnectionManage r302は、 ConnectorFactory303を保持する。
[0114] 前述したように、ボキヤブラリは名前空間におけるタグのセットである。図示されるよ うに、 Vocabulary305は、 VocabularyConnection301によって文書に対して生成され る。これは、文書ファイルを解析し、ソース DOMとデスティネーション DOMの間の写 像のための適切な VocabularyConnectionManager302を生成することにより行われる 。さらに、 Connectorを生成する ConnectorFactory303と、 Zone209を生成する ZoneF actory205と、 Zone内のノードに対応する Canvasを生成する Editlet206との間の適切 な関係が作られる。ユーザがシステム力も文書を処分又は削除するとき、対応する Vo cabularyConnectionManager302が肖 lj除される。
[0115] Vocabulary305は、 VCCanvas310を生成する。さらに、 Connector304及びデステ イネーシヨン DOMツリー 306が対応して生成される。
[0116] ソース DOM及び Canvasは、それぞれ、モデル(M)及びビュー(V)に対応する。し 力しながら、このような表現は、ターゲットのボキヤブラリが画面上に描写可能である 場合に限って意味がある。描写は、ボキヤブラリブラグィンにより行われる。ボキャプラ リプラグインは、主要なボキヤブラリ、例えば、 XHTML, SVG, MathMLについて 提供される。ボキヤブラリブラグィンは、ターゲットのボキヤブラリに関連して使用され
る。これらは、ボキヤブラリコネクション記述子を用いてボキヤブラリ間でマッピングする 方法を提供する。
[0117] このようなマッピングは、ターゲットのボキヤブラリが、マッピング可能で、画面上に描 写される方法が予め定義されたものである場合にのみ意味がある。このようなレンダリ ング方法は、例えば XHTMLなどのように、 W3Cなどの組織により定義された標準 規格となっている。
[0118] ボキヤブラリコネクションが必要であるとき、 VCCanvasが使用される。この場合、ソー スのビューを直接生成することができないので、ソースの Canvasは生成されない。こ の場合、 VCCanvas力 ConnectorTreeを使用して生成される。この VCCanvasは、ィ ベントの変換のみを扱い、画面上の文書の描写を援助しない。
[0119] 3. DestinationZone、 Pane、及びし anvas
上述したように、ボキヤブラリコネクションサブシステムの目的は、同一の文書の 2つ の表現を同時に生成し保持することである。第 2の表現も、 DOMツリーの形式であり 、これはデスティネーション DOMツリーとして既に説明した。第 2の表現における文 書を見るために、 DestinationZone, Canvas及び Paneが必要である。
[0120] VCCanvasが作成されると、対応する DestinationPane307が生成される。さらに、関 連する DestinationCanvas308と、対応する BoxTree309が生成される。同様に、 VCC anvas310も、ソース文書に対する Pane211及び Zone209に関連づけられる。
[0121] DestinationCanvas308は、第 2の表現における文書の論理的なレイアウトを提供す る。特に、 DestinationCanvas308は、デスティネーション表現における文書を描写す るために、カーソルや選択のようなユーザインタフェイス機能を提供する。 Destination Canvas308に生じたイベントは、 Connectorに供給される。 DestinationCanvas308は 、マウスイベント、キーボードイベント、ドラッグアンドドロップイベント、及び文書のデス ティネーシヨン(第 2)表現のボキヤブラリに特有なイベントを、 Connector304に通知 する。
[0122] 4.ボキヤブラリコネクションコマンドサブシステム
ボキヤブラリコネクション (VC)サブシステム 300の要素として、ボキヤブラリコネクシ ヨン (VC)コマンドサブシステム 313がある。ボキヤブラリコネクションコマンドサブシス
テム 313は、ボキヤブラリコネクションサブシステム 300に関連した命令の実行のため に使用される VCCommand (ボキヤブラリコネクションコマンド) 315を生成する。 VCCo mmandは、内蔵の CommandTemplate (コマンドテンプレート) 318を使用して、及び Z 又は、スクリプトサブシステム 314においてスクリプト言語を使用してスクラッチカもコ マンドを生成することにより、生成することができる。
[0123] コマンドテンプレートには、例えば、「If」コマンドテンプレート、「When」コマンドテン プレート、「挿入(Insert)」コマンドテンプレートなどがある。これらのテンプレートは、 V CCommandを作成するために使用される。
[0124] 5. XPathサブシステム
?&1^サブシステム316は、文書処理システムの重要な構成であり、ボキヤブラリコ ネクシヨンの実現を支援する。 Connector304は、一般に xpath情報を含む。上述した ように、ボキヤブラリコネクションのタスクの 1つは、ソース DOMツリーの変化をデステ イネーシヨン DOMツリーに反映させることである。 xpath情報は、変更 Z修正を監視さ れるべきソース DOMツリーのサブセットを決定するために用いられる 1以上の xpath 表現を含む。
[0125] 6.ソース DOMツリー、デスティネーション DOMツリー、及び ConnectorTreeの概要 ソース DOMツリーは、別のボキヤブラリに変換される前のボキヤブラリで文書を表 現した DOMツリー又は Zoneである。ソース DOMツリーのノードは、ソースノードと呼 ばれる。
[0126] それに対して、デスティネーション DOMツリーは、ボキヤブラリコネクションに関連し て前述したように、同一の文書を、マッピングにより変換された後の異なるボキヤブラリ で表現した DOMツリー又は Zoneである。デスティネーション DOMツリーのノードは、 デスティネーションノードと呼ばれる。
[0127] ConnectorTreeは、ソースノードとデスティネーションノードの対応を表す Connector に基づく階層的表現である。 Connectorは、ソースノードと、ソース文書になされた修 正を監視し、デスティネーション DOMツリーを修正する。 Connectorは、デスティネー シヨン DOMツリーを修正することを許された唯一のオブジェクトである。
[0128] E.文書処理システムにおけるイベントフロー
実用のためには、プログラムはユーザ力 のコマンドに応答しなければならない。ィ ベントは、プログラム上で実行されたユーザアクションを記述し実行する方法である。 多くの高級言語、例え «Java (登録商標)は、ユーザアクションを記述するイベントに 頼っている。従来、プログラムは、ユーザアクションを理解し、それを自身で実行する ために、積極的に情報を集める必要があった。これは、例えば、プログラムが自身を 初期化した後、ユーザが画面、キーボード、マウスなどでアクションを起こしたときに 適切な処理を講じるために、ユーザのアクションを繰り返し確認するループに入ること を意味する。し力しながら、このプロセスは扱いにくい。さらに、それは、ユーザが何か をするのを待つ間、 CPUサイクルを消費してループするプログラムを必要とする。
[0129] 多くの言語が、異なるパラダイムを採用することにより、これらの問題を解決している 。そのうちの一つは、現代の全てのウィンドウシステムの基礎となっている、イベントド リブンプログラミングである。このパラダイムでは、全てのユーザアクションは、「ィベン ト」と呼ばれる抽象的な事象の集合に属する。イベントは、十分詳細に、特定のユー ザアクションを記述する。プログラムがユーザにより生成されたイベントを積極的に収 集するのではなぐ監視すべきイベントが生じたときに、システムがプログラムに通知 する。この方法によりユーザとの対話を扱うプログラムは「イベントドリブン」であると言 われる。
[0130] これは、多くの場合、全てのユーザにより生成されたイベントの基本特性を獲得する 「Event (イベント)」クラスを使用して扱われる。
[0131] 文書処理システムは、 自身のイベント、及びこれらのイベントを扱う方法を定義して 使用する。いくつかの型のイベントが使用される。例えば、マウスイベントは、ユーザ のマウスアクションから起こるイベントである。マウスを含むユーザアクションは、 Canva s210によって、マウスイベントに渡される。このように、 Canvasは、システムのユーザ による相互作用の最前部にあると言える。必要であれば、最前部にある Canvasは、そ のイベントに関連した内容を子へ渡す。
[0132] それに対して、キーストロークイベントは、 Canvas 210から流れる。キーストロークイ ベントは、即時的なフォーカスを有する。すなわち、それは、いかなる瞬間でも作業に 関連する。 Canvas210上に入力されたキーストロークイベントは、その親に渡される。
キー入力は、文字列挿入を扱うことが可能な、異なるイベントによって処理される。文 字列の挿入を扱うイベントは、キーボードを使用して文字が挿入されたときに発生す る。他の「イベント」は、例えば、ドラッグイベント、ドロップイベント、マウスイベントと同 様に扱われる他のイベントを含む。
[0133] 1.ボキヤブラリコネクション外のイベントの取り扱い
イベントは、イベントスレッドを用いて渡される。 Canvas210は、イベントを受け取ると 、その状態を変更する。必要であれば、 Commandl052力 Canvas210により Comman dQueuel053にポストされる。
[0134] 2.ボキヤブラリコネクション内のイベントの取り扱い
VocabularyConnectionプラグイン 301を用いて、 DestinationCanvasの一例である X HTMLCanvasl l06は、発生したイベント、例えば、マウスイベント、キーボードィベン ト、ドラッグアンドドロップイベント、及びボキヤブラリに特有のイベントなどを受け取る。 これらのイベントは、コネクタ 304に通知される。より詳細には、図 21 (b)に図示される ように、 VocabularyConnectionプラグイン 301内のイベントフローは、 SourcePanel lO 3、 Vし Canvas丄 104、 DestinationPanel lOo、 DestinationCanvasの一 f列で fcoDestin ationCanvasl 106、デスティネーション DOMツリー及び ConnectorTreeを通過する。
[0135] F. Programlnvoker及び Programlnvokerと他の構成との関係
Programlnvokerl03及びそれと他の構成との関係は、図 14 (a)に更に詳細に示さ れる。 Programlnvokerl03は、文書処理システムを開始するために実行される実行環 境中の基本的なプログラムである。図 11 (b)及び図 11 (c)に図示されるように、 User Application 106、 ¾erviceBrokerl04l、 Commandlnvokerl051、及び Resourcel09 は、全て Programlnvokerl03に接続される。前述したように、アプリケーション 102は、 実行環境中で実行されるコンポーネントである。同様に、 ServiceBrokerl041は、シ ステムに様々な機能をカ卩えるプラグインを管理する。他方、 Commandlnvokerl051は 、ユーザにより提供される命令を実行して、コマンドを実行するために使用されるクラ ス及びファンクションを保持する。
[0136] 1.プラグイン及びサービス
ServiceBrokerl041について、図 14 (b)を参照して更に詳細に説明する。前述した
ように、 ServiceBrokerl041は、システムに様々な機能を追加するプラグイン (及び関 連するサービス)を管理する。 Servicel042は、文書処理システムに特徴を追加又は 変更可能な最も下の層である。「Service」は、 ServiceCategory401と ServiceProvider 402の 2つの部分からなる。図 14 (c)に図示されるように、 1つの ServiceCategory401 は、複数の関連する ServiceProvider402を持ちうる。それぞれの ServiceProviderは、 特定の ServiceCategoryの一部または全部を実行するように作用する。 ServiceCatego ry401は、他方では、 Serviceの型を定義する。
[0137] Serviceは、 1)文書処理システムに特定の特色を提供する「特色サービス」、 2)文書 処理システムにより実行されるアプリケーションである「アプリケーションサービス」、 3) 文書処理システムの全体にわたって必要な特色を提供する「環境サービス」、の 3つ の型に分類することができる。
[0138] Serviceの例は、図 14 (d)に示される。アプリケーション Serviceの Categoryにおいて は、システムユーティリティが対応する ServiceProviderの例である。同様に、 Editlet20 6は Categoryであり、 HTMLEditlet及び SVGEditletは対応する ServiceProviderである 。 ZoneFactory205は、 Serviceの別の Categoryであり、対応する ServiceProvider (図 示せず)を有する。
[0139] プラグインは、文書処理システムに機能性をカ卩えると既に説明した力 いくつかの Se rviceProvider402及びそれらに関連するクラスからなるユニットと見なされてもよい。 各プラグインは、宣言ファイルに記述された依存性及び ServiceCategory401を有す る。
[0140] 2. Programlnvokerとアプリケーションとの関係
図 14 (e)は、 Programlnvokerl03と UserApplicationl06との関係についての更なる 詳細を示す。必要な文書やデータなどは、ストレージからロードされる。必要なプラグ インは、全て ServiceBrokerl041上にロードされる。 ServiceBrokerl041は、全てのプ ラグインを保持し管理する。プラグインは、システムに物理的に追加することができ、 又、その機能はストレージカもロードすることができる。プラグインの内容がロードされ ると、 ServiceBrokerl041は、対応するプラグインを定義する。つづいて、対応する Us erApplicationl06が生成され、実行環境 101にロードされ、 Programlnvokerl03にァ
タツチされる。
[0141] G.アプリケーションサービスと環境との関係
図 15 (a)は、 Programlnvokerl03上にロードしたアプリケーションサービスの構成に ついての更なる詳細を示す。コマンドサブシステム 105のコンポーネントである Comm andlnvokerl051は、 Programlnvokerl03内の Commandl052を起動又は実行する。 Commandl052は、文書処理システムにおいて、 XMLなどの文書を処理し、対応す る XMLDOMツリーを編集するために用いられる命令である。 Commandlnvokerl05 1は、 Commandl052を実行するために必要なクラス及びファンクションを保持する。
[0142] ServiceBrokerl041も、 Programlnvokerl03内で実行される。 UserApplicationl06 は、ユーザインタフェイス 107及び CoreComponentl lOに接続される。 CoreCompone ntl lOは、全ての Paneの間で文書を共有する方法を提供する。 CoreComponentl lO は、さらにフォントを提供し、 Paneのためのツールキットの役割を果たす。
[0143] 図 15 (b)は、 Framel071、 MenuBarl072、及び StatusBarl073の関係を示す。
[0144] H.アプリケーションコア
図 16 (a)は、全ての文書、及び文書の一部及び文書に属するデータを保持するァ プリケーシヨンコア 108についての更なる説明を提供する。 CoreComponentl lOは、 文書 1082を管理する DocumentManagerl081にアタッチされる。 DocumentManager 1081は、文書処理システムに関連づけられたメモリに格納される全ての文書 1082 の所有者である。
[0145] 画面上の文書の表示を容易にするために、 DocumentManagerl081は RootPanel 084にも接続される。 ClipBoardl087、 SnapShotl088、 Drag&Drop601、及び Overla y602の機能も、 CoreComponentl 10にアタッチされる。
[0146] SnapShotl088は、アプリケーションの状態を元に戻すために使用される。ユーザが SnapShotl088を起動したとき、アプリケーションの現状が検知され、格納される。そ の後、アプリケーションの状態が別の状態に変わるとき、格納された状態の内容は保 存される。 SnapShotl088は、図 16 (b)に図示される。動作において、アプリケーショ ンがある URL力 他へ移動するときに、前に戻る動作及び先に進む動作をシームレ スに実行可能とするために、 SnapShotl088は以前の状態を記憶する。
[0147] I. DocumentManager内における文書の構成
図 17 (a)は、 DocumentManagerl081の更なる説明と、 DocumentManagerにおいて 文書が構成され保持される様子を示す。図 11 (b)に示したように、 DocumentManager 1081は、文書 1082を管理する。図 17 (a)に示される例において、複数の文書のう ちの 1つは RootDocument (ルート文書) 701であり、残りの文書は SubDocument (サブ 文書) 702である。 DocumentManager 1081は、 RootDocument701に接続され、 Root Document701は、全ての SubDocument702に接続される。
[0148] 図 12及び図 17 (a)に示すように、 DocumentManager 1081は、全ての文書 1082を 管理するオブジェクトである DocumentContainer203に結合される。 DOMService703 及び IOManager704を含むツールキット 201 (例えば XMLツールキット)の一部を开 成するツールも、 DocumentManager 1081に供給される。再び図 17 (a)を参照して、 DOMService703は、 DocumentManagerl081により管理される文書に基づいた DO Mツリーを生成する。各 Document705は、それが RootDocument701であっても SubD ocument702であっても、対応する DocumentContainer203によって管理される。
[0149] 図 17 (b)は、文書 A— Eが階層的に配置される様子を示す。文書 Aは RootDocume ntである。文書 B— Dは、文書 Aの SubDocumentである。文書 Eは、文書 Dの SubDocu mentである。図 17 (b)の左側は、これと同じ文書の階層が画面上に表示された例を 示す。 RootDocumentである文書 Aは、基本フレームとして表示される。文書 Aの SubD ocumentである文書 B— Dは、基本フレーム Aの中のサブフレームとして表示される。 文書 Dの SubDocumentである文書 Eは、サブフレーム Dのサブフレームとして画面に 表示される。
[0150] 再び図 17 (a)を参照して、 UndoManager (アンドゥマネージャ:アンドゥ管理部) 706 及び UndoWrapper (アンドゥラッパ一) 707は、それぞれの DocumentContainer203に 対して生成される。 UndoManager706及び UndoWrapper707は、取消可能なコマンド を実行するために使用される。この特徴を使用することにより、編集操作を使用して 文書に対して実行された変更を取り消すことができる。 SubDocumentの変更は、 Root Documentとも密接な関係を有する。アンドゥ操作は、階層内の他の文書に影響する 変更を考慮に入れて、例えば、図 17 (b)に示されるような連鎖状の階層における全
ての文書の間で整合性が維持されることを保証する。
[0151] UndoWrapper707は、 DocumentContainer203内の SubDocumentに関連するアンド ゥオブジェクトをラップし、それらを RootDocumentに関連するアンドゥオブジェクトに結 合させる。 UndoWrapper707は、 UndoableEditAcceptor (アンドゥァブルエデイットァク セプタ:アンドゥ可能編集受付部) 709に利用可能なアンドゥオブジェクトの収集を実 行する。
[0152] UndoManager706及び UndoWrapper707は、 UndoableEditAcceptor709及び Undo ableEditSource (アンドゥァブルエディットソース) 708〖こ接続される。当業者には理解 されるように、 Document705が UndoableEditSource708であってもよぐ取消可能な 編集オブジェクトのソースであってもよ 、。
[0153] J.アンドゥコマンド及びアンドゥフレームワーク
図 18 (a)及び図 18 (b)は、アンドゥフレームワーク及びアンドゥコマンドについて更 なる詳細を提供する。図 18 (a)に示されるように、 UndoCommand801、 RedoComman d802、及び UndoableEditCommand803は、図 11 (b)に示したように Commandlnvoke r 1051に積むことができるコマンドであり、順に実行される。 UndoableEditCommand8 03は、 UndoableEditSource708及び UndoableEditAcceptor709に更にアタッチされ る。「foo」 Editし ommand804及び「bar」 Editし ommand805i 、 UndoableEditCommand の例である。
[0154] 1. UndoableEditCommandの実行
図 18 (b)は、 UndoableEditCommandの実行を示す。まず、ユーザが編集コマンドを 使用して Document705を編集すると仮定する。第 1ステップ S 1では、 UndoableEditA cceptor709力 Document705の DOMツリーである UndoableEditSource708にァタツ チされる。第 2ステップ S2では、ユーザにより発行されたコマンドに基づいて、 Docum ent705が DOMの APIを用いて編集される。第 3ステップ S3では、ミューテーシヨンィ ベントのリスナー力 変更がなされたことを通知される。すなわち、このステップでは、 DOMツリーの全ての変更を監視するリスナーが編集操作を検知する。第 4ステップ S 4では、 UndoableEditが UndoManager706のオブジェクトとして格納される。第 5ステツ プ S5では、 UndoableEditAcceptor709が UndoableEditSource708からデタツチされる
。 UndoableEditSource708は、 Document705自身であってもよい。
[0155] K.システムへの文書のロードに関する手順
上記のサブセクションでは、システムの様々なコンポーネント及びサブコンポーネン トについて説明した。以下、これらのコンポーネントの使用に関する方法論について 説明する。図 19 (a)は、文書処理システムに文書がロードされる様子の概要を示す。 それぞれのステップは、図 24— 28において、特定の例に関連して詳述される。
[0156] 簡単には、文書処理システムは、文書に含まれるデータ力 なるバイナリデータスト リームから DOMを生成する。 ApexNode (エイペックスノード:頂点ノード)が、注目対 象であり Zoneに属する文書の一部のために生成される。つづいて、対応する Paneが 同定される。同定された Paneは、 ApexNode及び物理的な画面表面から Zone及び Ca nvasを生成する。 Zoneは、次に、それぞれのノードに Facetを生成し、それらに必要と される情報を提供する。 Canvasは、 DOMツリーから、ノードをレンダリングするための データ構造を生成する。
[0157] より詳細には、文書はストレージ 901からロードされる。文書の DOMツリー 902が生 成される。文書を保持するための、対応する DocumentContainer903が生成される。 DocumentContainer903は、 DocumentManager904にアタッチされる。 DOMツリーは 、ルートノードと、ときには複数のセカンダリノードを含む。
[0158] 一般に、このような文書は、テキスト及びグラフィクスの双方を含む。したがって、 D OMツリーは、例えば、 XHTMLサブツリーだけでなく SVGサブツリーを有してもよい 。 XHTMLサブツリーは、 XHTMLの ApexNode905を有する。同様に、 SVGサブッ リーは、 SVGの ApexNode906を有する。
[0159] ステップ 1では、 ApexNode906力 画面の論理的なレイアウトである Pane907にァタ ツチされる。ステップ 2では、 Pane907は、 PaneOwner (ペインオーナー:ペインの所有 者) 908である CoreComponentに、 ApexNode906のための ZoneFactoryを要求する。 ステップ 3では、 PaneOwner908は、 ZoneFactoryと、 ApexNode906のための CanvasF actoryである Editletとを返す。
[0160] ステップ 4では、 Pane907力 ¾one909を生成する。 Zone909は Pane907にアタッチ される。ステップ 5では、 Zone909がそれぞれのノードに対して Facetを生成し、対応
するノードにアタッチする。ステップ 6では、 Pane907力 Canvas910を生成する。 Canv as910は Pane907にアタッチされる。 Canvas910には様々な Commandが含まれる。ス テツプ 7では、 Canvas910が文書を画面にレンダリングするためのデータ構造を構築 する。 XHTMLの場合、これはボックスツリー構造を含む。
[0161] 1. Zoneの MVC
図 19 (b)は、 MVCパラダイムを用いて Zoneの構成の概要を示す。この場合、 Zone 及び Facetは文書に関連した入力であるから、モデル(M)は Zone及び Facetを含む。 Canvasと、文書を画面にレンダリングするためのデータ構造体は、ユーザが画面上に 見る出力であるから、ビュー(V)は Canvas及びデータ構造体に対応する。 Command は、文書とその様々な関係に対して制御操作を実行するので、コントロールお)は Ca nvasに含まれる Commandを含む。
[0162] L.文書の表現
図 20を用いて、文書及びその様々な表現の例について以下に説明する。この例で 使用される文書は、テキストと画像の双方を含む。テキストは、 XHTMLを用いて表さ れ、画像は、 SVGを用いて表される。図 20は、文書のコンポーネント及び対応するォ ブジエタトの関係の MVC表現を詳細に示す。この例において、 DocumentlOOlは、 Document 1001を保持する DocumentContainer 1002にアタッチされる。文書は DO Mツリー 1003により表現される。 DOMツリーは、 ApexNodel004を含む。
[0163] ApexNodeは、黒丸で表される。頂点でないノードは、白丸で表される。ノードを編集 するために用いられる Facetは、三角形で表され、対応するノードにアタッチされる。 文書がテキストと画像を有するので、この文書の DOMツリーは、 XHTML部分と SV G部分を含む。 ApexNodel004は、 XHTMLサブツリーの最上のノードである。これ は、文書の XHTML部分の物理的な表現のための最上 Paneである XHTMLPanelO 05にアタッチされる。 ApexNodel004は、文書の DOMツリーの一部である XHTMLZ onel006にもアタッチされる。
[0164] Nodel004に対応する Facetも、 XHTMLZonel006にアタッチされる。 XHTMLZone 1006は、 XHTMLPanel005にアタッチされる。 XHTMLEditletは、文書の論理的な 表現である XHTMLCanvasl007を生成する。 XHTMLCanvasl007は、 XHTMLPane
1005にアタッチされる。 XHTMLCanvasl007は、 Document 1001の XHTMLコンポ 一ネントのための BoxTreel009を生成する。文書の XHTML部分を保持し描画する ために必要な様々な Commandl008も、 XHTMLCanvasl007に追加される。
[0165] 同様に、文書の SVGサブツリーの ApexNodelOlOは、文書の SVGコンポーネント を表現する Document 1001の DOMツリーの一部である SVGZone 1011にアタッチさ れる。 ApexNodelOlOは、文書の SVG部分の物理的な表現の最上の Paneである SV GPanelO 13にアタッチされる。文書の SVG部分の論理的な表現を表す SVGCanvas 1012は、 SVGEditletにより生成され、 SVGPanel013にアタッチされる。画面上に文 書の SVG部分をレンダリングするためのデータ構造及びコマンドは、 SVGCanvasに アタッチされる。例えば、このデータ構造は、図示されるように、円、線、長方形などを 含んでもよい。
[0166] 図 20に関連して説明された文書例の表現の一部について、図 21 (a)に関連して、 前述した MVCパラダイムを用いて更に説明する。図 21 (a)は、文書 1001の XHTM Lコンポーネントにおける MVの関係を簡略化して示す。モデルは、 DocumentlOOl の XHTMLコンポーネントのための XHTMLZone 1101である。 XHTMLZoneのッリ一 には、いくつかの Node及びそれらに対応する Facetが含まれる。対応する XHTMLZon e及び Paneは、 MVCパラダイムのモデル(M)部分の一部である。 MVCパラダイムの ビュー(V)部分は、 DocumentlOOlの XHTMLコンポーネントの、対応する XHTML Canvasl 102及び BoxTreeである。文書の XHTML部分は、 Canvasと、それに含まれ る Commandを使用して画面に描写される。キーボードやマウス入力などのイベントは 、図示されるように、逆方向へ進む。
[0167] SourcePaneは、更なる機能、すなわち、 DOMの保有者としての役割を有する。図 2 1 (b)は、図 21 (a)に示した DocumentlOOlのコンポーネントに対するボキヤブラリコ ネクシヨンを提供する。 DOMホルダーとして機能する SourcePanel l03は、文書のソ ース DOMツリーを含む。 ConnectorTreeは、 ConnectorFactoryにより生成され、デス ティネーシヨン DOMの保有者としても機能する DestinationPanel 105を生成する。 D estinationPanel 105は、 XHTMLDestinationCanvasl 106としてボックスツリーの形式 でレイアウトされる。
[0168] M.プラグインサブシステム、ボキヤブラリコネクション、及びコネクタの関係 図 22 (a) - (c)は、それぞれ、プラグインサブシステム、ボキヤブラリコネクション、及 び Connectorに関連する更なる詳細を示す。プラグインサブシステムは、文書処理シ ステムに機能を追加又は交換するために用いられる。プラグインサブシステムは、 Ser viceBrokerl041を含む。 ServiceBrokerl041にアタッチされる ZoneFactoryServicel 201は、文書の一部に対する Zoneを生成する。 EditletService 1202も、 ServiceBroke rl041にアタッチされる。 EditletServicel202は、 Zone中の Nodeに対応する Canvasを 生成する。
[0169] ZoneFactoryの例は、 XHTMLZone及び SVGZoneをそれぞれ生成する XHTMLZone Factoryl211及び SVGZoneFactoryl 212である。文書例に関連して前述したように、 文書のテキストコンポーネントは、 XHTMLZoneを生成することにより表現されてもよ!ヽ し、画像は SVGZoneを用いて表現されてもよい。 EditletServiceの例は、 XHTMLEditle U221及び SVGEditletl222を含む。
[0170] 図 22 (b)は、ボキヤブラリコネクションに関連する更なる詳細を示す。ボキヤブラリコ ネクシヨンは、前述したように、文書処理システムの重要な特徴であり、 2つの異なる 方法で文書の整合のとれた表現及び表示を可能とする。 ConnectorFactory303を保 持する VCManager302は、ボキヤブラリコネクションサブシステムの一部である。 Conn ectorFactory303は、文書の Connector304を生成する。前述したように、 Connector は、ソース DOM中のノードを監視し、 2つの表現の間の整合性を維持するために、 デスティネーション DOM中のノードを修正する。
[0171] Template317は、いくつかのノードの変換ノレ一ノレを表す。ボキヤブラリコネクション 記述子 (VCD)ファイルは、特定のパス又はルールを満たす要素又は要素の集合を 他の要素に変換するいくつかのルールを表す Templateのリストである。 Template317 及び CommandTemplate318は、全て VCManager302にアタッチされる。 VCManager は、 VCDファイル中の全てのセクションを管理するオブジェクトである。 1つの VCDフ アイルに対して、 1つの VCManagerオブジェクトが生成される。
[0172] 図 22 (c)は、 Connectorに関連する更なる詳細を提供する。 ConnectorFactory303 は、ソ ~~ス文善力ら Connectorを生成する。 ConnectorFactory303は、 Vocabulary ^ T
emplateゝ及び ElementTemplateにアタッチされ、それぞれ、 VocabularyConnectorゝ T emplateConnector、 Elementし onnector 生成 *f る。
[0173] VCManager302は、 ConnectorFactory303を保持する。 Vocabularyを生成するため に、対応する VCDファイルが読み込まれる。こうして、 ConnectorFactory303が生成 れる。このし onnectorFactory30dは、 Zoneを生成する ZoneFactory及びし anvasを生 成する Editletに関連する。
[0174] つづ!/、て、ターゲットボキヤブラリの EditletServiceが、 VCCanvasを生成する。 VCCa nvasも、ソース DOMツリー又は Zoneにおける ApexNodeの Connectorを生成する。必 要に応じて、子の Connectorが再帰的に生成される。 ConnectorTreeは、 VCDフアイ ル中のテンプレートの集合により生成される。
[0175] テンプレートは、マークアップ言語の要素を他の要素に変換するためのルールの集 合である。例えば、各テンプレートは、ソース DOMツリー又は Zoneにマッチされる。 適切にマッチした場合には、頂点 Connectorが生成される。例えば、テンプレートお/ */D」は、間にどんなノードがあるかに関係なぐノード Aで始まりノード Dで終わる全 ての枝に合致する。同様に、「〃B」は、ルートからの全ての「B」ノードに一致する。
[0176] N. ConnectorTreeに関係する VCDファイルの例
特定の文書と関係する処理を説明する例を続ける。ドキュメントタイトルのある「MyS ampleXML」というタイトルの文書が文書処理システムにロードされる。図 23は、「MySa mpleXMLjファイルのための、 VCManager及び ConnectorFactoryTreeを用いた VCD スクリプトの例を示す。スクリプトファイル中のボキヤブラリセクシヨン、テンプレートセク シヨンと、 VCManagerにおける対応するコンポーネントが示される。タグ「vcd:vocabula ry」において、属'性「match_^¾「sample:root」、「label」は「MySampleXML」、「caU— temp late」は sample template となって 、る。
[0177] この例では、 Vocabularyは、「MySampleXML」の VCManagerにおいて「sample:root」 として頂点要素を含む。対応する UIラベルは、「MySampleXML」である。テンプレート セクションにお 、て、タグは「vcd:template」であり、名前は「sample:template」である。
[0178] O.ファイルがシステムにロードされる方法の詳細な例
図 24— 28は、文書「MySampleXML」のロードについての詳細な記述を示す。図 24
(a)に示されるステップ 1では、文書がストレージ 1405からロードされる。 DOMService は、 DOMツリー及び DocumentManagerl406と対応する DocumentContainerl401 を生成する。 DocumentContainerl401は、 DocumentManagerl406にアタッチされる 。文書は、 XHTML及び MySampleXMLのサブツリーを含む。 XHTMLの ApexNode 1403は、タグ「xhtml:html」が付された XHTMLの最上のノードである。「MySampleX MLJの ApexNodel404は、タグ「sample:root」が付された「MySampleXML」の最上ノ ードである。
[0179] 図 24 (b)に示されるステップ 2では、 RootPaneが文書の XHTMLZone、 Facet,及び Canvasを生成する。 Panel407、 XHTMLZonel408、 XHTMLCanvasl409、及び Bo xTreel410力 ApexNode 1403に対応して生成される。
[0180] 図 24 (c)に示されるステップ 3では、 XHTMLZoneが知らないタグ「sample:root」を発 見し、 XHTMLCanvasの領域から SubPaneを生成する。
[0181] 図 25に示されるステップ 4では、 SubPaneが「sample:root」を扱うことができ、適切な Zoneを生成 Γ會な ZoneFactory 得る。この ZoneFactoryi;、 ZoneFactory 行 n丁 能な Vocabulary内にある。それは、「MySampleXML」の VocabularySectionの内容を含 む。
[0182] 図 26に示されるステップ 5では、「MySampleXML」に対応する Vocabularyが Default Zonel601を生成する。対応する Editletが生成され、対応する Canvasを生成するた めに SubPanel501が提供される。 Editletは、 VCCanvasを生成する。そして、それは T emplate¾ection 呼ふ。 Connectorractory freet a.3;れて 、る。し onnectorFactoryTr eeは、 ConnectorTreeとな 全飞の Connectorを生成する。
[0183] 図 27に示されるステップ 6では、各 Connectorがデスティネーション DOMオブジェク トを生成する。コネクタのうちのいくつかは xpath情報を含んでいる。 xpath情報は、変 更 Z修正を監視する必要のあるソース DOMツリーの部分集合を決定するために使 用される 1以上の xpath表現を含む。
[0184] 図 28に示されるステップ 7では、ボキヤブラリは、ソース DOMのペインからデスティ ネーシヨン DOMツリーの DestinationPaneを作成する。これは、 SourcePaneに基づい てなされる。デスティネーションツリーの ApexNodeは、 DestinationPane及び対応する
Zoneにアタッチされる。 DestinationPaneは、 DestinationCanvasを生成し、文書をデス ティネーシヨンのフォーマットでレンダリングするためのデータ構造及びコマンドを構 築する、自身の Editletを提供される。
[0185] 図 29 (a)は、対応するソースノードを持たず、デスティネーションツリーにのみ存在 するノード上でイベントが発生したときのフローを示す。マウスイベント、キーボードィ ベントなど、 Canvasが取得したイベントは、デスティネーションツリーを通過して、 Elem entTemplateConnectorに izs達 れる。 ElementTemplateConnectorは对 、す oソ ~~ス ノードを持たな 、ので、伝達されたイベントはソースノードに対する編集操作ではな ヽ 。 ElementTemplateConnectorは、 1ZS達 れた ヘント し ommandTemplateに己 さ れたコマンドに合致すれば、それに対応する Actionを実行する。合致するコマンドが なければ、 ElementTemplateConnectorは、伝達されたイベントを無視する。
[0186] 図 29 (b)は、 TextOfConnectorによりソースノードに対応づけられているデステイネ ーシヨンツリーのノード上でイベントが発生したときのフローを示す。 TextOfConnector は、ソース DOMツリーの XPathで指定されたノード力 テキストノードを取得して、デ スティネーシヨン DOMツリーのノードにマッピングする。マウスイベント、キーボードィ ベントなど、 Canvasが取得したイベントは、デスティネーションツリーを通過して、 Text OlConnectorに伝達される。 TextO!Connectorは、伝達されたイベントを、対応するソ ースノードの編集コマンドにマッピングし、 Queuel053に積む。編集コマンドは、 Face tを介して実行される DOMの APIコールの集合である。キューに積まれたコマンドが 実行されると、ソースノードが編集される。ソースノードが編集されると、ミューテーショ ンイベントが発行され、リスナーとして登録された TextOfConnectorにソースノードの 変更が通知される。 TextOfConnectorは、ソースノードの変更を、対応するデステイネ ーシヨンノードに反映させるように、デスティネーションツリーを再構築する。このとき、 TextO!Connectorを含むテンプレートに、「for each」 「for loop」などの制御文が含ま れている場合、 ConnectorFactoryがこの制御文を再評価し、 TextOfConnectorを再構 築した後、デスティネーションツリーが再構築される。
[0187] (実施の形態)
実施の形態では、携帯端末に、 XML文書と、その XML文書を閲覧 Z編集するた
めの定義ファイルを配信し、様々なビジネスモデルを実現するための技術を提案す る。
[0188] マークアップ言語で記述された文書を配信するモデルとして、ウェブサーバを利用 した HTML文書の配信が広く普及している。しかし、 HTMLは、主として表示形式を 規定するマークアップ言語であるから、文書の内容に対してタグで意味が付されてい るわけではない。したがって、文書の再利用性に劣るという問題がある。
[0189] それに対して、 XML文書と定義ファイルを配信するモデルによれば、任意のタグセ ットにより文書をマークアップし、意味を付すことが可能であるから、配信された XML 文書を様々な用途に再利用することができる。従来は、 XML文書の処理系がほとん ど存在せず、メジャーではな ヽボキヤブラリで記述された XML文書はテキスト文書と して扱うしかないという問題があった力 前提技術として上記で説明した技術によれ ば、 VCユニット 80を携帯端末に搭載し、 XML文書を記述したタグセットを処理する 定義ファイルを用意すれば、任意のタグセットで記述された文書を携帯端末にぉ 、 て表示'編集することができる。したがって、携帯電話端末などのリソースが限られた 装置であっても、任意の XML文書を処理可能な汎用的な処理系を実現できる。
[0190] また、適切な VCDを用意すれば、任意のタグセットで記述された XML文書を表示
'編集することができるので、配信する XML文書には表示情報を含ませる必要がな い。したがって、配信する XML文書のデータ量を低減することができる。データ量が 小さいので、小型で軽量な半導体チップなどに格納することができ、小さな商品など にも付すことができる。また、バーコードィ匕して商品に付すこともできる。
[0191] XML文書を表示する技術として、 XSLTや CSSなどにより XML文書の表示情報 を規定する技術がある力 XML文書を表示することはできても、編集することはでき ない。 VCDを利用した VC技術によれば、任意のタグセットで記述された XML文書 を編集可能である。また、 VCDに UIやロジックなどを記述することができる。したがつ て、単なる情報の配信だけでなぐユーザに対してアクションを起こしたり、ユーザから のアクションを取得するような対話型の通信が可能となる。
[0192] JavaScript (登録商標)によってもロジックを記述することができるが、 JavaScript ( 登録商標)は、ビューを作成する能力の面で VCDに劣る。 VCDは、 XSLTのビュー
作成能力を兼ね備えており、任意のタグセットで記述された XML文書のビューを容 易に作成することができる。また、プログラミングの観点から考察すると、 VCDは、 Jav a (登録商標)をベースとしており、環境に非依存で、かつ、開発の容易性で長じてい る。また、サイズが小さぐ携帯端末を利用したビジネスモデルにとって好都合である
[0193] 図 30は、実施の形態に係る情報配信システムの構成を示す。情報配信システム 10 0は、携帯端末 70と、携帯端末 70へ情報を配信する情報配信装置 25を含む。情報 配信装置 25は、携帯端末 70へ配信すべき文書を保持する文書保持部 26と、文書 保持部 26から文書を読み出して携帯端末 70へ送信する送信部 27とを含む。携帯 端末 70は、情報配信装置 25との間の通信を制御する通信部 75と、前提技術で説明 した文書処理装置 20と、文書処理装置 20により処理された文書を表示する表示装 置 21と、ユーザ力もの入力を受け付けるボタンなどを備えた入力装置 23と、携帯端 末 70のユーザの個人情報を保持する個人情報保持部 71と、定義ファイルを保持す る定義ファイル保持部 77と、文書に適用する定義ファイルを切り替える切替部 78とを 含む。情報配信装置 25は、ネットワーク 29を介して携帯端末 70に文書を配信する。 文書は、 Bluetoothなどの無線通信技術を用いて配信されてもよいし、携帯電話網 やインターネットなどを利用して配信されてもよい。この場合、通信部 75が、情報配 信装置 25から送信された文書を受信する受信部の機能を有する。また、文書の内容 をバーコードなどで表現し、携帯端末 70がバーコードを読み取ることで文書を取得 できるようにしてもよい。この場合、情報配信装置 25は、送信部 27に替えてバーコ一 ド表示部を含み、携帯端末 70はバーコードリーダーを含む。
[0194] 携帯端末 70は、一般的なパーソナルコンピュータに比べてリソースが少ないので、 余分な構成を省略し、最小限の機能を効果的に設けるのが望ましい。したがって、本 実施の形態では、文書を処理する処理系として、 HTMLユニット 50と VCユニット 80 のみを設けることにする。 XHTML以外のタグセット(ボキヤブラリ)で記述された文書 は、 XHTMLへの変換テンプレートを記述した定義ファイルを用意し、 VCユニット 80 により XHTMLに変換して、 HTMLユニット 50により表示する。これにより、最小限の 構成で、任意のタグセットの汎用的な処理系を実現することができる。なお、実施の
形態では、処理系として HTMLユニット 50のみを設ける例を説明する力 もちろん他 のタグセットの処理系を携帯端末 70に搭載してもよ 、。
[0195] 情報配信装置 25が、配信する文書に対応する定義ファイルを携帯端末 70に配信 してもよいし、携帯端末 70は他の経路から定義ファイルを取得してもよい。取得され た定義ファイルは、定義ファイル保持部 77に格納される。例えば、共通するタグセット を処理するためのデフォルト定義ファイルを携帯端末 70にプリインストールしておき、 文書内の共通タグセットで記述された最低限の情報はデフォルト定義ファイルを適用 して閲覧することができるようにしてもよい。また、文書を処理するための定義ファイル が複数用意されてもよい。例えば、同一の文書を異なるレイアウトで表示する複数の 定義ファイルを用意して、それらを切替可能とすることにより、利用シーンに合わせて ユーザが好みの画面を選択可能としてもよい。この場合、切替部 78は、ユーザから 定義ファイルを切り替える指示を受け付けて、 XML文書に適用する定義ファイルを 切り替える。また、異なる要素の表示テンプレートを含む複数の定義ファイルを用意し てもよい。例えば、通常の定義ファイルでは表示できない要素を文書に含ませておき 、その要素のテンプレートを記述した特別な定義フアイノレを入手したユーザのみがそ の要素を閲覧できるようにしてもよい。これにより、会員限定の秘密のバーゲン情報を 配信したり、店舗に来店したユーザのみが取得可能なサービスチケットを提供したり するなど、様々な形態のサービスを提供することができ、例えば、販売促進のための 演出に利用することができる。
[0196] 定義ファイルには、コマンドやロジックを記述することができるので、これを利用して 、独自のユーザインタフェイスを提供することができる。また、 VC機能を用いてユーザ に文書を編集させ、編集した文書を通信部 75を介して情報配信装置 25へ返送する こともできる。この場合、通信部 75が、編集した文書を情報配信装置 25へ返送する 送信部の機能を有する。これにより、商品や役務の購入、アンケートに対する回答な ど、双方向通信を利用した各種サービスを提供することができる。文書を編集すると きに、個人情報保持部 71に格納されたユーザの個人情報を利用してもよい。たとえ ば、個人情報保持部 71に、ユーザの氏名、住所、電話番号、携帯端末 70の ID、公 開鍵、証明書、電子署名などを格納しておき、文書を編集するための定義ファイルが
適宜利用できるようにしてもよい。これにより、ユーザの入力の手間を低減することが できるとともに、証明書などを利用した信頼性の高い通信を行うことができる。
[0197] このように、文書処理装置 20を、提供主体が自由に用意した、独自のボキヤブラリ で記述された文書を汎用的に処理するプラットフォームとして利用することにより、様 々なビジネスモデルを柔軟かつ効果的に実現することができる。以下、適用例をいく つ力述べる。
[0198] 図 31 (a) (b)は、情報配信システム 100の第 1の適用例を示す。図 31 (a)では、商 品の販売装置 76に情報配信装置 25が設けられており、携帯端末 70に、販売装置 7 6で購入可能な商品の情報や、販売装置 76で商品を購入するための UIを提供する ための文書を配信する。図 31 (b)は、携帯端末 70に配信された文書を表示装置 21 に表示した画面の例を示す。販売装置 76に設けられた情報配信装置 25から配信さ れる文書には、例えば、販売装置 76で購入できる商品のリスト、それらの商品に関す る情報などが記述されている。また、この文書に対応づけられた定義ファイルには、 文書に記述された商品リストや関連情報などを表示するためのテンプレートや、商品 の購入要求を販売装置 76へ送信するためのコマンドなどが記述されて 、る。定義フ アイルは、販売装置 76から文書とともに配信されてもよいし、他の任意の経路から携 帯端末 70に配信されてもよい。例えば、独自のボキヤブラリで販売装置 76の商品情 報などを記述した文書を配信する場合は、そのボキヤブラリの要素のテンプレートを 記述した専用の定義ファイルを用意して、文書とともに送信してもよい。また、例えば 複数のベンダーが共通のボキヤブラリを用いて文書を記述する場合は、携帯端末 70 に初めて文書を配信するときにのみ定義ファイルを配信し、以降は、携帯端末 70に 保持されて 、る定義ファイルを適用してもょ 、。
[0199] 携帯端末 70が、配信された文書と定義ファイルにより提示される GUIを利用して、 販売装置 76に購入要求を送信すると、販売装置 76は、図示しない受付部により購 入要求を受け付け、商品を販売する。このとき、個人情報保持部 71に格納された決 済情報、たとえばクレジットカードや電子マネーなどに関する情報が販売装置 76に 送られてもよい。
[0200] ユーザは、携帯端末 70を用いて、販売装置 76で販売されている商品の詳細情報
を閲覧することができるとともに、携帯端末 70から商品の購入を要求することができる 。これにより、販売装置 76自身では伝えきれない情報をユーザに提供することができ るとともに、販売装置 76自身の UIよりも多機能な UIをユーザに提供することができ、 ユーザの利便性を飛躍的に向上させることができる。携帯端末 70を用いた決済サー ビスなどと連動させることにより、商品購入の決済も自動的に処理することが可能とな り、さらにユーザの利便性を向上させることができる。
[0201] 図 32 (a) (b)は、情報配信システム 100の第 2の適用例を示す。図 32 (a)では、商 品 79に添付された無線 ICタグ 89を情報配信装置 25として機能させる。無線 ICタグ 8 9には、商品の流通経路などの情報が記述された文書を保持する記憶装置と、その 文書を無線通信により携帯端末 70に送信する送信装置とが設けられる。図 32 (b)は 、携帯端末 70に送信された文書を表示装置 21に表示した画面の例を示す。無線 タグ 89から配信される文書には、商品の生産主体、生産場所、生産日、流通経路な どの情報が記述されている。また、この文書に対応づけられた定義ファイルには、文 書に記述された流通経路などの情報を表示するためのテンプレートや、それらの情 報を編集するためのコマンドなどが記述されている。
[0202] 消費者は、携帯端末 70を用いて、商品の流通経路などの情報を閲覧することがで きる。これにより、消費者に安心感を与えることができるので、商品の販売促進にもつ ながる。流通の過程において、例えば、中間流通業者の担当者が携帯端末 70により 無線 ICタグ 89から文書を取得し、入荷日や出荷日などの情報を追加して無線 ICタ グ 89に保存してもよい。これにより、流通経路の管理を容易かつ適切に行うことがで きる。業者が商品を検品するときに、検印を付加するための定義ファイルを備えた携 帯端末 70を用いて、無線 ICタグ 89から取得した文書に検印を付加してもよい。検印 が押された文書は通信部 75を介して無線 ICタグ 89へ返送され文書保持部 26に格 納される。個人情報保持部 71に検印者の証明書を格納しておき、検印した文書に電 子署名を付してもよい。これにより、検品を迅速に進めることができるとともに、検品の 信頼性を向上させることができる。
[0203] 図 33 (a) (b)は、情報配信システム 100の第 3の適用例を示す。図 33 (a)では、各 所に情報発信スポットとして情報配信装置 25が設けられており、ユーザが移動中に
携帯端末 70が情報配信装置 25の無線通信圏内に入ると、情報配信装置 25から携 帯端末 70に、周辺の店舗や観光地などの情報を提供するための文書が配信される 。図 33 (b)は、携帯端末 70に送信された文書を表示装置 21に表示した画面の例を 示す。情報配信装置 25から配信される文書には、情報発信スポットの周辺、すなわ ち、ユーザの現在位置の周辺の情報などが記述されている。ユーザの現在位置の周 辺の店舗などの情報を配信することにより、より効果的な宣伝を行うことができる。また 、文書とともに配信される標準的な定義ファイルには、秘密情報のテンプレートを記 述せず、店舗でしか取得できない定義ファイルには、秘密情報のテンプレートを記述 しておき、その定義フアイノレを適用して初めて秘密のバーゲン情報やクーポンチケッ トなどを表示可能としてもょ 、。
[0204] 図 34は、情報配信システムの別の構成例を示す。図 34に示した情報配信システム 100においては、携帯端末 70が、フィルタリング部 72及び文書保持部 73を更に備 えている。情報配信装置 25は、電子メールにより、メールマガジンの形態で XML文 書を携帯端末 70へ配信する。フィルタリング部 72は、ユーザが蓄積を希望する情報 を抽出して文書保持部 73に格納する。フィルタリング部 72は、 XML文書のうち、特 定のタグセットにより記述された部分のみを抽出して文書保持部 73に蓄積してもよい 。また、特定の要素のみを抽出して文書保持部 73に蓄積してもよい。ユーザは、任 意のタイミングで、文書保持部 73に格納された文書を読み出し、文書処理装置 20に より表示させ、編集することができる。
[0205] 図 35は、情報配信システムの更に別の構成例を示す。図 35に示した情報配信シ ステム 100においては、携帯端末 70が、検索部 74を更に備えている。検索部 74は、 携帯端末 70の周囲に存在し、携帯端末 70と通信が可能な情報配信装置 25を検索 する。例えば、検索部 74は、図 33 (a)に示したような状況下において、無線通信圏 内に存在する情報配信装置 25を探索し、発見した情報配信装置 25に XML文書の 送信を要求する。すなわち、図 33 (a)においては、情報配信装置 25が無線通信圏 内に存在する携帯端末 70を探索して XML文書を配信したが、本図の構成例では、 逆に、携帯端末 70が無線通信圏内に存在する情報配信装置 25を探索して XML文 書の配信を要求する。検索部 74は、情報配信装置 25が配信している XML文書の
中から、携帯端末 70が有して 、る定義ファイルにより処理可能なタグセットで記述さ れた文書を検索してもよい。
[0206] 検索部 74は、定義ファイルと VCユニット 80により実現されてもよい。例えば、ユー ザ力 バーゲン情報を記述するタグセットを処理する定義ファイルを起動すると、検索 部 74が、通信可能な情報配信装置 25が配信する XML文書の中から、バーゲン情 報用タグセットで記述された文書を検索し、発見した文書を取得するようにしてもよい
[0207] 以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それ らの各構成要素や各処理プロセスの組合せに 、ろ 、ろな変形例が可能なこと、また そうした変形例も本発明の範囲にあることは当業者に理解されるところである。
産業上の利用可能性
[0208] 本発明は、 XMLにより記述された文書を配信する情報配信システムに利用するこ とがでさる。