データ処理装置及びデータ処理方法
【課題】構造化文書を処理する際の利便性を向上させる。
【解決手段】帳票デザイン端末装置300において、スキーマ設定部332は、所定のタグセットで記述された構造化文書の要素構造を示す情報を取得する。レイアウト設定部334は、構造化文書ファイルに含まれるデータを、編集用の別のタグセットで記述されたデータに変換することにより、構造化文書ファイルの編集用ユーザインタフェース画面を表示するための定義データを要素構造情報に基づいて生成する。データ入力機能付加部338は、構造化文書が繰り返し可能な要素を有する場合、外部から与えられる表形式データの少なくとも一部を、繰り返し可能な要素又はその要素の下位に存在するノードのノード値として入力するデータ入力機能を定義データに付加する。
【解決手段】帳票デザイン端末装置300において、スキーマ設定部332は、所定のタグセットで記述された構造化文書の要素構造を示す情報を取得する。レイアウト設定部334は、構造化文書ファイルに含まれるデータを、編集用の別のタグセットで記述されたデータに変換することにより、構造化文書ファイルの編集用ユーザインタフェース画面を表示するための定義データを要素構造情報に基づいて生成する。データ入力機能付加部338は、構造化文書が繰り返し可能な要素を有する場合、外部から与えられる表形式データの少なくとも一部を、繰り返し可能な要素又はその要素の下位に存在するノードのノード値として入力するデータ入力機能を定義データに付加する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、データ処理技術に関し、特に、マークアップ言語により記述されたデータを処理するデータ処理装置及び方法に関する。
【背景技術】
【0002】
近年、コンピュータの普及とネットワーク技術の進展に伴い、ネットワークを介した電子情報の交換が盛んになっている。これにより、従来においては紙ベースで行われていた事務処理の多くが、ネットワークベースの処理に置き換えられつつある。
【0003】
企業においても、個人の知識や情報を組織全体で活用する、いわゆるナレッジマネジメントが、重要な経営手法となってきている。多くの企業においては、社内にデータベースシステムを有し、従業員からの情報を電子ファイル化して蓄積する。その一方で、従業員も、この社内データベースに蓄積されたファイルにネットワークを介してアクセスする。これによって、組織全体としての業務効率の向上が図られる。
【0004】
この社内データベースに蓄積されるファイルの多くは、HTML(Hyper Text Markup Language)とよばれる言語によって作成されている。また、近年においては、XML(eXtensible Markup Language)とよばれる言語を用いて、これらのファイルが作成される例も多くなってきている。
【0005】
HTMLは、ウェブページを記述するための言語である。すなわち、HTMLは文書ファイルの表示方法を定義するマークアップ言語の一種である。これに対して、XMLはHTMLの様に、直接的にウェブページを記述することを目的とする言語というよりは、むしろ、文書ファイルに含まれるデータのデータ構造を定義する機能を有する言語といえる。XMLによって作成された文書ファイルは、別に表示レイアウト情報を与えることによって、ウェブページとして表示される。すなわち、XML文書においては、データの構造とその表示レイアウトが別々のものとして扱うことができる。XMLのように、マークアップ言語を生成するための言語はメタ言語ともよばれる。
【0006】
XMLは、ネットワークなどを介して他者とデータを共有するのに適した形式として注目されており、XML文書を作成、表示、編集するためのアプリケーションが開発されている(たとえば、特許文献1参照)。XML文書は、文書型定義などにより定義されたボキャブラリ(タグセット)に基づいて作成されている。
【特許文献1】特開2001−290804号公報
【発明の開示】
【発明が解決しようとする課題】
【0007】
通常、XMLにより文書ファイルを作成するに際しては、まず、データ構造を定義し、更に、その表示レイアウトを定義する。このため、XMLによって作成された文書ファイルは、同一内容のデータであっても、複数の表示レイアウトを定義できる。
【0008】
XMLにより作成された文書ファイルの表示レイアウトは、たとえば、XSL(eXtensible Stylesheet Language)のようなスタイルシートを記述するための言語によって定義される。あるいは、XSLT(XML Stylesheet Language Transform)とよばれる言語によって、XML文書ファイルをHTML文書ファイルに変換する方法もある。
【0009】
XMLのようなメタ言語によって作成された文書ファイル(以下、このようなメタ言語によって作成された、データ構造を有する文書ファイルを、特に「構造化文書ファイル」とよぶ)は、データベースとの親和性が高いというメリットがある。なぜならば、構造化文書ファイルに含まれるデータは構造化されているため、データ検索などの処理になじみやすいからである。しかし、その一方で、一般にはXMLのようなメタ言語によって文書ファイルを作成しその表示レイアウトを定義するプロセスには多くの専門知識が必要であり、ユーザは多大な負担を強いられる。
【0010】
換言すれば、XMLのようなメタ言語は、複数のアプリケーションソフトウェアが扱うべきデータを統一したスキームで取り扱うことができるという潜在能力を有しながら、その習得の難しさが、往々にしてこの能力を発揮させる上での阻害要因となっている。
【0011】
本発明はこうした状況に鑑みてなされたものであり、その主たる目的は、構造化文書を作成する際のユーザの利便性を向上させる技術を提供することにある。
【課題を解決するための手段】
【0012】
本発明のある態様は、データ処理装置に関する。このデータ処理装置は、所定のタグセットで記述された構造化文書の要素構造を示す情報を取得する要素構造情報取得部と、前記構造化文書に含まれるデータを、編集用の別のタグセットで記述されたデータに変換することにより、前記構造化文書の編集用ユーザインタフェース画面を表示するための定義データを、前記要素構造を示す情報に基づいて生成する定義データ生成部と、前記構造化文書が繰り返し可能な要素を有する場合、外部から与えられる表形式データの少なくとも一部を、前記繰り返し可能な要素又はその要素の下位に存在するノードのノード値として入力するデータ入力機能を前記定義データに付加するデータ入力機能付加部と、を備えることを特徴とする。
【0013】
データ入力機能は、前記表形式データにヘッダ行が含まれる場合、前記ヘッダ行を解析することにより、前記表形式データの列と、前記ノードとの対応関係を決定してもよい。データ入力機能は、前記ヘッダ行に記載された前記表形式データの列の内容を示す文字列と、前記ノードの名称とを比較することにより、前記表形式データの列と、前記ノードとの対応関係を決定してもよい。
【0014】
前記定義データ生成部は、前記ノードに対して別名を設定する機能を有してもよく、前記データ入力機能は、前記ヘッダ行に記載された前記表形式データの列の内容を示す文字列と、前記ノードの別名とを比較することにより、前記表形式データの列と、前記ノードとの対応関係を決定してもよい。
【0015】
本発明の別の態様は、データ処理装置に関する。このデータ処理装置は、所定のタグセットで記述される構造化文書を処理する処理部と、前記構造化文書が繰り返し可能な要素を有する場合、外部から与えられる表形式データの少なくとも一部を、前記繰り返し可能な要素又はその要素の下位に存在するノードのノード値として入力するデータ入力部と、を備えることを特徴とする。
【0016】
本発明の更に別の態様は、データ処理方法に関する。このデータ処理方法は、所定のタグセットで記述された構造化文書の要素構造を示す情報を取得するステップと、前記構造化文書に含まれるデータを、編集用の別のタグセットで記述されたデータに変換することにより、前記構造化文書の編集用ユーザインタフェース画面を表示するための定義データを、前記要素構造を示す情報に基づいて生成するステップと、前記構造化文書が繰り返し可能な要素を有する場合、外部から与えられる表形式データの少なくとも一部を、前記繰り返し可能な要素又はその要素の下位に存在するノードのノード値として入力するデータ入力機能を前記定義データに付加するステップと、を備えることを特徴とする。
【0017】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システムなどの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【0018】
本発明によれば、構造化文書を作成する際のユーザの利便性を向上させる技術を提供することができる。
【発明を実施するための最良の形態】
【0019】
(前提技術)
図1は、前提技術に係る文書処理装置20の構成を示す。文書処理装置20は、文書内のデータが階層構造を有する複数の構成要素に分類された構造化文書を処理するが、本前提技術では構造化文書の一例としてXML文書を処理する例について説明する。文書処理装置20は、主制御ユニット22、編集ユニット24、DOMユニット30、CSSユニット40、HTMLユニット50、SVGユニット60、及び変換部の一例であるVCユニット80を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのCPU、メモリ、メモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【0020】
主制御ユニット22は、プラグインのロードや、コマンド実行のフレームワークを提供する。編集ユニット24は、XML文書を編集するためのフレームワークを提供する。文書処理装置20における文書の表示及び編集機能は、プラグインにより実現されており、文書の種別に応じて必要なプラグインが主制御ユニット22又は編集ユニット24によりロードされる。主制御ユニット22又は編集ユニット24は、処理対象となるXML文書の名前空間を参照して、XML文書がいずれのボキャブラリにより記述されているかを判別し、そのボキャブラリに対応した表示又は編集用のプラグインをロードして表示や編集を実行させる。例えば、文書処理装置20には、HTML文書の表示及び編集を行うHTMLユニット50、SVG文書の表示及び編集を行うSVGユニット60など、ボキャブラリ(タグセット)ごとに表示系及び編集系がプラグインとして実装されており、HTML文書を編集するときはHTMLユニット50が、SVG文書を編集するときはSVGユニット60が、それぞれロードされる。後述するように、HTMLとSVGの双方の構成要素を含む複合文書が処理対象となっている場合は、HTMLユニット50とSVGユニット60の双方がロードされる。
【0021】
このような構成によれば、ユーザは、必要な機能のみを選択してインストールし、後から適宜機能を追加又は削除することができるので、プログラムを格納するハードディスクなどの記録媒体の記憶領域を有効に活用することができ、また、プログラム実行時にも、メモリの浪費を防ぐことができる。また、機能拡張性に優れており、開発主体としても、プラグインの形で新たなボキャブラリに対応することが可能なので開発が容易となり、ユーザとしても、プラグインの追加により容易かつ低コストにて機能を追加することができる。
【0022】
編集ユニット24は、ユーザインターフェースを介してユーザから編集指示のイベントを受け付け、そのイベントを適切なプラグインなどに通知するともに、イベントの再実行(リドゥ)又は実行の取消(アンドゥ)などの処理を制御する。
【0023】
DOMユニット30は、DOM提供部32、DOM生成部34、及び出力部36を含み、XML文書をデータとして扱うときのアクセス方法を提供するために定められた文書オブジェクトモデル(Document Object Model:DOM)に準拠した機能を実現する。DOM提供部32は、編集ユニット24に定義されているインタフェースを満たすDOMの実装である。DOM生成部34は、XML文書からDOMツリーを生成する。後述するように、処理対象となるXML文書が、VCユニット80により他のボキャブラリにマッピングされる場合は、マッピング元のXML文書に対応するソースツリーと、マッピング先のXML文書に対応するデスティネーションツリーが生成される。出力部36は、例えば編集終了時に、DOMツリーをXML文書として出力する。
【0024】
CSSユニット40は、CSS解析部42、CSS提供部44、及びレンダリング部46を含み、CSSに準拠した表示機能を提供する。CSS解析部42は、CSSの構文を解析するパーサの機能を有する。CSS提供部44は、CSSオブジェクトの実装であり、DOMツリーに対してCSSのカスケード処理を行う。レンダリング部46は、CSSのレンダリングエンジンであり、CSSを用いてレイアウトされるHTMLなどのボキャブラリで記述された文書の表示に用いられる。
【0025】
HTMLユニット50は、HTMLにより記述された文書を表示又は編集する。SVGユニット60は、SVGにより記述された文書を表示又は編集する。これらの表示/編集系は、プラグインの形で実現されており、それぞれ、文書を表示する表示部(Canvas)56、66、編集指示を含むイベントを送受信する制御部(Editlet)52、62、編集コマンドを受けてDOMに対して編集を行う編集部(Zone)54、64を備える。制御部52又は62が外部からDOMツリーの編集コマンドを受け付けると、編集部54又は64がDOMツリーを変更し、表示部56又は66が表示を更新する。これらは、MVC(Model-View-Controller)と呼ばれるフレームワークに類似する構成をとっており、概ね、表示部56及び66が「View」に、制御部52及び62が「Controller」に、編集部54及び64とDOMの実体が「Model」に、それぞれ対応する。本前提技術の文書処理装置20では、XML文書をツリー表示形式で編集するだけでなく、それぞれのボキャブラリに応じた編集を可能とする。例えば、HTMLユニット50は、HTML文書をワードプロセッサに類似した方式で編集するためのユーザインターフェースを提供し、SVGユニット60は、SVG文書を画像描画ツールに類似した方式で編集するためのユーザインターフェースを提供する。
【0026】
VCユニット80は、マッピング部82、定義ファイル取得部84、及び定義ファイル生成部86を含み、あるボキャブラリにより記述された文書を、他のボキャブラリにマッピングすることにより、マッピング先のボキャブラリに対応した表示編集用プラグインで文書を表示又は編集するためのフレームワークを提供する。本前提技術では、この機能を、ボキャブラリコネクション(Vocabulary Connection:VC)と呼ぶ。定義ファイル取得部84は、マッピングの定義を記述したスクリプトファイルを取得する。この定義ファイルは、ノードごとに、ノード間の対応(コネクション)を記述する。このとき、各ノードの要素値や属性値の編集の可否を指定してもよい。また、ノードの要素値や属性値を用いた演算式を記述してもよい。これらの機能については、後で詳述する。マッピング部82は、定義ファイル取得部84が取得したスクリプトファイルを参照して、DOM生成部34にデスティネーションツリーを生成させ、ソースツリーとデスティネーションツリーの対応関係を管理する。定義ファイル生成部86は、ユーザが定義ファイルを生成するためのグラフィカルユーザインターフェースを提供する。
【0027】
VCユニット80は、ソースツリーとデスティネーションツリーの間のコネクションを監視し、表示を担当するプラグインにより提供されるユーザインタフェースを介してユーザから編集指示を受け付けると、まずソースツリーの該当するノードを変更する。DOMユニット30が、ソースツリーが変更された旨のミューテーションイベントを発行すると、VCユニット80は、そのミューテーションイベントを受けて、ソースツリーの変更にデスティネーションツリーを同期させるべく、変更されたノードに対応するデスティネーションツリーのノードを変更する。デスティネーションツリーを表示/編集するプラグイン、例えばHTMLユニット50は、デスティネーションツリーが変更された旨のミューテーションイベントを受けて、変更されたデスティネーションツリーを参照して表示を更新する。このような構成により、少数のユーザにより利用されるローカルなボキャブラリにより記述された文書であっても、他のメジャーなボキャブラリに変換することで、文書を表示することができるとともに、編集環境が提供される。
【0028】
文書処理装置20により文書を表示又は編集する動作について説明する。文書処理装置20が処理対象となる文書を読み込むと、DOM生成部34が、そのXML文書からDOMツリーを生成する。また、主制御ユニット22又は編集ユニット24は、名前空間を参照して文書を記述しているボキャブラリを判別する。そのボキャブラリに対応したプラグインが文書処理装置20にインストールされている場合は、そのプラグインをロードして、文書を表示/編集させる。プラグインがインストールされていない場合は、マッピングの定義ファイルが存在するか否かを確認する。定義ファイルが存在する場合、定義ファイル取得部84が定義ファイルを取得し、その定義に従って、デスティネーションツリーが生成され、マッピング先のボキャブラリに対応するプラグインにより文書が表示/編集される。複数のボキャブラリを含む複合文書である場合は、後述するように、それぞれのボキャブラリに対応したプラグインにより、文書の該当箇所がそれぞれ表示/編集される。定義ファイルが存在しない場合は、文書のソース又はツリー構造を表示し、その表示画面において編集が行われる。
【0029】
図2は、処理対象となるXML文書の例を示す。このXML文書は、生徒の成績データを管理するために用いられる。XML文書のトップノードである構成要素「成績」は、配下に、生徒ごとに設けられた構成要素「生徒」を複数有する。構成要素「生徒」は、属性値「名前」と、子要素「国語」、「数学」、「理科」、「社会」を有する。属性値「名前」は、生徒の名前を格納する。構成要素「国語」、「数学」、「理科」、「社会」は、それぞれ、国語、数学、理科、社会の成績を格納する。例えば、名前が「A」である生徒の国語の成績は「90」、数学の成績は「50」、理科の成績は「75」、社会の成績は「60」である。以下、この文書で使用されているボキャブラリ(タグセット)を、「成績管理ボキャブラリ」と呼ぶ。
【0030】
本前提技術の文書処理装置20は、成績管理ボキャブラリの表示/編集に対応したプラグインを有しないので、この文書をソース表示、ツリー表示以外の方法で表示するためには、前述したVC機能が用いられる。すなわち、成績管理ボキャブラリを、プラグインが用意された別のボキャブラリ、例えば、HTMLやSVGなどにマッピングするための定義ファイルを用意する必要がある。ユーザ自身が定義ファイルを作成するためのユーザインターフェースについては後述することにして、ここでは、既に定義ファイルが用意されているとして説明を進める。
【0031】
図3は、図2に示したXML文書をHTMLで記述された表にマッピングする例を示す。図3の例では、成績管理ボキャブラリの「生徒」ノードを、HTMLにおける表(「TABLE」ノード)の行(「TR」ノード)に対応づけ、各行の第1列には属性値「名前」を、第2列には「国語」ノードの要素値を、第3列には「数学」ノードの要素値を、第4列には「理科」ノードの要素値を、第5列には「社会」ノードの要素値を、それぞれ対応付ける。これにより、図2に示したXML文書を、HTMLの表形式で表示することができる。また、これらの属性値及び要素値は、編集可能であることが指定されており、ユーザがHTMLによる表示画面上で、HTMLユニット50の編集機能により、これらの値を編集することができる。第6列には、国語、数学、理科、社会の成績の加重平均を算出する演算式が指定されており、生徒の成績の平均点が表示される。このように、定義ファイルに演算式を指定可能とすることにより、より柔軟な表示が可能となり、編集時のユーザの利便性を向上させることができる。なお、第6列は、編集不可であることが指定されており、平均点のみを個別に編集することができないようにしている。このように、マッピング定義において、編集の可否を指定可能とすることにより、ユーザの誤操作を防ぐことができる。
【0032】
図4(a)及び図4(b)は、図2に示したXML文書を図3に示した表にマッピングするための定義ファイルの例を示す。この定義ファイルは、定義ファイル用に定義されたスクリプト言語により記述される。定義ファイルには、コマンドの定義と、表示のテンプレートが記述されている。図4(a)(b)の例では、コマンドとして、「生徒の追加」と「生徒の削除」が定義されており、それぞれ、ソースツリーにノード「生徒」を挿入する操作と、ソースツリーからノード「生徒」を削除する操作が対応付けられている。また、テンプレートとして、表の第1行に「名前」、「国語」などの見出しが表示され、第2行以降に、ノード「生徒」の内容が表示されることが記述されている。ノード「生徒」の内容を表示するテンプレート中、「text-of」と記述された項は「編集可能」であることを意味し、「value-of」と記述された項は「編集不可能」であることを意味する。また、ノード「生徒」の内容を表示する行のうち、第6列には、「(src:国語 + src:数学 + src:理科 + src:社会) div 4」という計算式が記述されており、生徒の成績の平均が表示されることを意味する。
【0033】
図5は、図2に示した成績管理ボキャブラリで記述されたXML文書を、図3に示した対応によりHTMLにマッピングして表示した画面の例を示す。表90の各行には、左から、各生徒の名前、国語の成績、数学の成績、理科の成績、社会の成績、及び平均点が表示されている。ユーザは、この画面上で、XML文書を編集することができる。たとえば、第2行第3列の値を「70」に変更すると、このノードに対応するソースツリーの要素値、すなわち、生徒「B」の数学の成績が「70」に変更される。このとき、VCユニット80は、デスティネーションツリーをソースツリーに追従させるべく、デスティネーションツリーの該当箇所を変更し、HTMLユニット50が、変更されたデスティネーションツリーに基づいて表示を更新する。したがって、画面上の表においても、生徒「B」の数学の成績が「70」に変更され、更に、平均点が「55」に変更される。
【0034】
図5に示した画面には、図4(a)(b)に示した定義ファイルに定義されたように、「生徒の追加」及び「生徒の削除」のコマンドがメニューに表示される。ユーザがこれらのコマンドを選択すると、ソースツリーにおいて、ノード「生徒」が追加又は削除される。このように、本前提技術の文書処理装置20では、階層構造の末端の構成要素の要素値を編集するのみではなく、階層構造を編集することも可能である。このようなツリー構造の編集機能は、コマンドの形でユーザに提供されてもよい。また、例えば、表の行を追加又は削除するコマンドが、ノード「生徒」を追加又は削除する操作に対応づけられてもよい。また、他のボキャブラリを埋め込むコマンドがユーザに提供されてもよい。この表を入力用テンプレートとして、穴埋め形式で新たな生徒の成績データを追加することもできる。以上のように、VC機能により、HTMLユニット50の表示/編集機能を利用しつつ、成績管理ボキャブラリで記述された文書を編集することが可能となる。
【0035】
図6は、ユーザが定義ファイルを生成するために、定義ファイル生成部86がユーザに提示するグラフィカルユーザインタフェースの例を示す。画面左側の領域91には、マッピング元のXML文書がツリー表示されている。画面右側の領域92には、マッピング先のXML文書の画面レイアウトが示されている。この画面レイアウトは、HTMLユニット50により編集可能となっており、ユーザは、画面右側の領域92において、文書を表示するための画面レイアウトを作成する。そして、例えば、マウスなどのポインティングデバイスにより、画面左側の領域91に表示されたマッピング元のXML文書のノードを、画面右側の領域92に表示されたHTMLによる画面レイアウト中へドラッグ&ドロップ操作を行うことにより、マッピング元のノードと、マッピング先のノードとのコネクションが指定される。例えば、要素「生徒」の子要素である「数学」を、HTML画面の表90の第1行第3列にドロップすると、「数学」ノードと、3列目の「TD」ノードの間にコネクションが張られる。各ノードには、編集の可否が指定できるようになっている。また、表示画面中には、演算式を埋め込むこともできる。画面の編集が終わると、定義ファイル生成部86は、画面レイアウトとノード間のコネクションを記述した定義ファイルを生成する。
【0036】
XHTML、MathML、SVGなどの主要なボキャブラリに対応したビューワやエディタは既に開発されているが、図2に示した文書のようなオリジナルなボキャブラリで記述された文書に対応したビューワやエディタを開発するのは現実的でない。しかし、上記のように、他のボキャブラリにマッピングするための定義ファイルを作成すれば、ビューワやエディタを開発しなくても、VC機能を利用して、オリジナルなボキャブラリで記述された文書を表示・編集することができる。
【0037】
図7は、定義ファイル生成部86により生成された画面レイアウトの他の例を示す。図7の例では、成績管理ボキャブラリで記述されたXML文書を表示するための画面に、表90と、円グラフ93が作成されている。この円グラフ93は、SVGにより記述される。後述するように、本前提技術の文書処理装置20は、一つのXML文書内に複数のボキャブラリを含む複合文書を処理することができるので、この例のように、HTMLで記述された表90と、SVGで記述された円グラフ93とを、一つの画面上に表示することができる。
【0038】
図8は、文書処理装置20によるXML文書の編集画面の一例を示す。図8の例では、一つの画面が複数に分割されており、それぞれの領域において、処理対象となるXML文書を異なる複数の表示形式により表示している。領域94には、文書のソースが表示されており、領域95には、文書のツリー構造が表示されており、領域96には、図5に示したHTMLにより記述された表が表示されている。これらのいずれの画面上においても、文書の編集が可能であり、いずれかの画面上でユーザが編集を行うと、ソースツリーが変更され、それぞれの画面の表示を担当するプラグインが、ソースツリーの変更を反映すべく画面を更新する。具体的には、ソースツリーの変更を通知するミューテーションイベントのリスナーとして、それぞれの編集画面の表示を担当するプラグインの表示部を登録しておき、いずれかのプラグイン又はVCユニット80によりソースツリーが変更されたときに、編集画面を表示中の全ての表示部が、発行されたミューテーションイベントを受け取って画面を更新する。このとき、プラグインがVC機能により表示を行っている場合は、VCユニット80がソースツリーの変更に追従してデスティネーションツリーを変更した後、変更されたデスティネーションツリーを参照してプラグインの表示部が画面を更新する。
【0039】
例えば、ソース表示及びツリー表示を、専用のプラグインにより実現している場合は、ソース表示用プラグインとツリー表示用プラグインは、デスティネーションツリーを用いず、直接ソースツリーを参照して表示を行う。この場合、いずれかの画面において編集が行われると、ソース表示用プラグインとツリー表示用プラグインは、変更されたソースツリーを参照して画面を更新し、領域96の画面を担当しているHTMLユニット50は、ソースツリーの変更に追従して変更されたデスティネーションツリーを参照して画面を更新する。
【0040】
ソース表示及びツリー表示は、VC機能を利用して実現することもできる。すなわち、ソース、ツリー構造をHTMLによりレイアウトし、そのHTMLにXML文書をマッピングして、HTMLユニット50により表示してもよい。この場合、ソース形式、ツリー形式、表形式の3つのデスティネーションツリーが生成されることになる。いずれかの画面において編集が行われると、VCユニット80は、ソースツリーを変更した後、ソース形式、ツリー形式、表形式の3つのデスティネーションツリーをそれぞれ変更し、HTMLユニット50は、それらのデスティネーションツリーを参照して、3つの画面を更新する。
【0041】
このように、一つの画面上に複数の表示形式で文書を表示することにより、ユーザの利便性を向上させることができる。例えば、ユーザは、ソース表示又はツリー表示により文書の階層構造を把握しつつ、表90などを用いて視覚的に分かりやすい形式で文書を表示し、編集することができる。上記の例では、一つの画面を分割して複数の表示形式による画面を同時に表示したが、一つの画面に一つの表示形式による画面を表示し、表示形式をユーザの指示により切り替え可能としてもよい。この場合、主制御ユニット22が、ユーザから表示形式の切り替え要求を受け付け、各プラグインに指示して表示を切り替える。
【0042】
図9は、文書処理装置20により編集されるXML文書の他の例を示す。図9に示したXML文書では、SVG文書の「foreignObject」タグの中にXHTML文書が埋め込まれており、さらに、XHTML文書の中にMathMLで記述された数式が入っている。このような場合、編集ユニット24が、名前空間を参照して、適切な表示系に描画作業を振り分ける。図9の例では、編集ユニット24は、まず、SVGユニット60に四角形を描画させ、つづいて、HTMLユニット50にXHTML文書を描画させる。さらに、図示しないMathMLユニットに、数式を描画させる。こうして、複数のボキャブラリを包含する複合文書が適切に表示される。表示結果を図10に示す。
【0043】
文書編集中、カーソル(キャリッジ)の位置に応じて、表示されるメニューを切り替えてもよい。すなわち、カーソルが、SVG文書が表示された領域内に存在するときは、SVGユニット60が提供するメニュー、又はSVG文書をマッピングするための定義ファイルに定義されたコマンドを表示し、カーソルが、XHTML文書が表示された領域内に存在するときは、HTMLユニット50が提供するメニュー、又はXHTML文書をマッピングするための定義ファイルに定義されたコマンドを表示する。これにより、編集位置に応じて適切なユーザインターフェースを提供することができる。
【0044】
複合文書において、あるボキャブラリに対応する適切なプラグイン又はマッピング定義ファイルがなかった場合は、そのボキャブラリにより記述された部分は、ソース表示又はツリー表示されてもよい。従来、ある文書に他の文書を埋め込んだ複合文書を開くとき、埋め込まれた文書を表示するアプリケーションがインストールされていないと、その内容を表示することができなかったが、本前提技術では、表示用のアプリケーションが存在しなくても、テキストデータにより構成されたXML文書をソース表示又はツリー表示することにより内容を把握することができる。これは、テキストベースであるXMLなどの文書ならではの特徴といえる。
【0045】
データがテキストベースで記述されることの他の利点として、例えば、複合文書中の、あるボキャブラリにより記述される部分において、同一文書内の他のボキャブラリで記述された部分のデータを参照してもよい。また、文書内で検索を実行する時に、SVGなどの図に埋め込まれた文字列も検索対象とすることができる。
【0046】
あるボキャブラリにより記述された文書内に、他のボキャブラリのタグを用いてもよい。このXML文書は、妥当(valid)ではないが、整形式(well-formed)であれば、有効なXML文書として処理可能である。この場合、挿入された他のボキャブラリのタグは、定義ファイルによりマッピングされてもよい。例えば、XHTML文書中に、「重要」、「最重要」などのタグを使用し、これらのタグで囲まれた部分を強調表示してもよいし、重要度の順にソートして表示してもよい。
【0047】
図10に示した編集画面において、ユーザにより文書が編集されると、編集された部分を担当するプラグイン又はVCユニット80がソースツリーを変更する。ソースツリーには、ノードごとにミューテーションイベントのリスナーを登録できるようになっており、通常は、各ノードが属するボキャブラリに対応したプラグインの表示部又はVCユニット80がリスナーとして登録される。DOM提供部32は、ソースツリーが変更されると、変更されたノードから上位の階層へたどって、登録されたリスナーがあれば、そのリスナーへミューテーションイベントを発行する。例えば、図9に示した文書において、<html>ノードの下位のノードが変更された場合、<html>ノードにリスナーとして登録されたHTMLユニット50にミューテーションイベントが通知されるとともに、その上位の<svg>ノードにリスナーとして登録されたSVGユニット60にもミューテーションイベントが通知される。このとき、HTMLユニット50は、変更されたソースツリーを参照して表示を更新する。SVGユニット60は、自身のボキャブラリに属するノードが変更されていないので、ミューテーションイベントを無視してもよい。
【0048】
編集の内容によっては、HTMLユニット50による表示の更新に伴って、全体のレイアウトが変わる可能性がある。この場合は、画面のレイアウトを管理する構成、例えば最上位のノードの表示を担当するプラグインにより、プラグインごとの表示領域のレイアウトが更新される。例えば、HTMLユニット50による表示領域が以前より大きくなった場合、HTMLユニット50は、まず自身の担当する部分を描画して、表示領域の大きさを決定する。そして、画面のレイアウトを管理する構成に、変更後の表示領域の大きさを通知し、レイアウトの更新を依頼する。画面のレイアウトを管理する構成は、通知を受けて、プラグインごとの表示領域を再レイアウトする。こうして、編集された部分の表示が適切に更新されるとともに、画面全体のレイアウトが更新される。
【0049】
つづいて、前提技術の文書処理装置20を実現する機能構成について更に詳細に説明する。以下の説明では、クラス名などを記載する際には、英字をそのまま用いて記載することにする。
【0050】
A.概要
インターネットの出現により、ユーザによって処理され管理される文書の数が、ほぼ指数関数的に増加してきた。インターネットの核を形成するウェブ(World Wide Web)は、そのような文書データの大きな受け皿となっている。ウェブは、文書に加えて、このような文書の情報検索システムを提供する。これらの文書は、通常、マークアップ言語により記述される。マークアップ言語のシンプルかつポピュラーな例の一つにHTML(HyperText Markup Language)がある。このような文書は、ウェブの他の位置に格納されている他の文書へのリンクをさらに含む。XML(eXtensible Markup Language)は、さらに高度でポピュラーなマークアップ言語である。ウェブ文書にアクセスし、閲覧するためのシンプルなブラウザが、Java(登録商標)のようなオブジェクト指向のプログラミング言語で開発されている。
【0051】
マークアップ言語により記述された文書は、通常、ブラウザや他のアプリケーションの中では、ツリーデータ構造の形で表現される。この構造は、文書を構文解析した結果のツリーに相当する。DOM(Document Object Model)は、文書を表現し、操作するために使用される、よく知られたツリーベースのデータ構造モデルである。DOMは、HTMLやXML文書などを含む文書を表現するための標準的なオブジェクトのセットを提供する。DOMは、文書内のコンポーネントを表現するオブジェクトがどのようにつながっているかという標準モデルと、それらのオブジェクトにアクセスしたり操作したりするための標準インタフェイスという、2つの基本的なコンポーネントを含む。
【0052】
アプリケーション開発者は、独自のデータ構造やAPI(Application Program Interface)へのインタフェイスとしてDOMをサポートすることができる。他方、文書を作成するアプリケーション開発者は、彼らのAPIの独自インタフェイスではなく、DOMの標準インタフェイスを使用することができる。したがって、標準を提供するというその能力により、DOMは、様々な環境、特にウェブにおいて、文書の相互利用を促進させるために有効である。DOMのいくつかのバージョンが定義されており、異なるプログラミング環境及びアプリケーションによって使用されている。
【0053】
DOMツリーは、対応するDOMの内容に基づいた文書の階層的表現である。DOMツリーは「根(ルート)」、及びルートから発生する1つ以上の「節(ノード)」を含む。ルートが文書全体を表す場合もある。中間のノードは、例えば、テーブル及びそのテーブル中の行及び列のような要素を表すことができる。DOMツリーの「葉」は、通常、それ以上分解できないテキストや画像のようなデータを表す。DOMツリーの各ノードは、フォント、サイズ、色、インデントなど、ノードによって表される要素のパラメータを記述する属性に関連付けられてもよい。
【0054】
HTMLは、文書を作成するために一般に用いられる言語であるが、フォーマット及びレイアウト用の言語であり、データ記述のための言語ではない。HTMLドキュメントを表現するDOMツリーのノードは、HTMLのフォーマッティングタグとして予め定義されたエレメントであって、通常、HTMLは、データの詳述や、データのタギング/ラベリングのための機能を提供しないので、HTMLドキュメント中のデータに対するクエリを定式化することは多くの場合困難である。
【0055】
ネットワーク設計者たちの目指すものは、ウェブ上の文書がソフトウェアアプリケーションによってクエリされたり処理されたりできるようにすることである。表示方法とは無関係で、階層的に構造化された言語であれば、そのようにクエリされ処理されることができる。XML(eXtensible Markup Language)のようなマークアップ言語は、これらの特徴を提供することができる。
【0056】
HTMLとは逆に、XMLのよく知られた利点は、文書の設計者が自由に定義可能な「タグ」を使用して、データ要素にラベルを付けることが可能である点である。このようなデータ要素は、階層的に構造化することができる。さらに、XML文書は、文書内で用いられるタグ及びそれらの相互関係の「文法」を記述した文書型定義を含むことができる。構造化されたXML文書の表示方法を定義するために、CSS(Cascading Style Sheet)又はXSL(XML Style Language)が使用される。DOM、HTML、XML、CSS、XSL及び関連する言語の特徴に関する付加的な情報は、ウェブからも得ることができる。(例えば、http://www.w3.org/TR/)
【0057】
Xpathは、XML文書の部分の位置を指定するために共通のシンタックス及びセマンティクスを提供する。機能性の例として、XML文書に対応するDOMツリーのトラバース(移動)がある。それは、XML文書の様々な表現に関連した文字列、数、及びブーリアン文字の操作のための基本的な機能を提供する。Xpathは、XML文書の見た目のシンタックス、例えば、テキストとしてみたときに何行目であるとか何文字目であるとかといった文法ではなく、DOMツリーなどの抽象的・論理的な構造において動作する。Xpathを使用することにより、例えばXML文書のDOMツリー内の階層的構造を通じて場所を指定することができる。アドレシングのための使用の他に、Xpathは、DOMツリー中のノードがパターンにマッチするか否かをテストするために使用されるようにも設計されている。XPathに関する更なる詳細は、http://www.w3.org/TR/xpathで得ることができる。
【0058】
XMLの既知の利点及び特徴により、マークアップ言語(例えばXML)で記述された文書を扱うことができ、文書を作成及び修正するためのユーザフレンドリーなインタフェイスを提供することができる、効果的な文書処理システムが求められる。
【0059】
ここで説明されるシステムの構成のうちのいくつかは、MVC(Model-View-Controller)と呼ばれる、よく知られたGUI(Graphical User Interface)パラダイムを用いて説明される。MVCパラダイムは、アプリケーション又はアプリケーションのインタフェイスの一部を、3つの部分、すなわち、モデル、ビュー、コントローラに分割する。MVCは、元は、GUIの世界に、従来の入力、処理、出力の役割を割り当てるために開発された。
[入力] → [処理] → [出力]
[コントローラ]→ [モデル] → [ビュー]
【0060】
MVCパラダイムによれば、外界のモデリング、ユーザへの視覚的なフィードバック、及びユーザの入力は、モデル(M)、ビュー(V)、及びコントローラ(C)オブジェクトにより分離されて扱われる。コントローラは、ユーザからのマウスとキーボード入力のような入力を解釈し、これらのユーザアクションを、適切な変更をもたらすためにモデル及び/又はビューに送られるコマンドにマップするように作用する。モデルは、1以上のデータ要素を管理するように作用し、その状態に関するクエリに応答し、状態を変更する指示に応答する。ビューは、ディスプレイの長方形の領域を管理するように作用し、グラフィクスとテキストの組合せによりユーザにデータを提示する機能を有する。
【0061】
B.文書処理システムの全体構成
文書処理システムの実施例は、図11−29に関連して明らかにされる。
【0062】
図11(a)は、後述するタイプの文書処理システムの基礎として機能する要素の従来の構成例を示す。構成10は、通信経路13によりメモリ12に接続されたCPU又はマイクロプロセッサ11などの形式のプロセッサを含む。メモリ12は、現在又は将来に利用可能な任意のROM及び/又はRAMの形式であってもよい。通信経路13は、典型的にはバスとして設けられる。マウス、キーボード、音声認識システムなどのユーザ入力装置14及び表示装置15(又は他のユーザインタフェイス)に対する入出力インタフェイス16も、プロセッサ11とメモリ12の通信のためのバスに接続される。この構成は、スタンドアロンであってもよいし、複数の端末及び1以上のサーバが接続されてネットワーク化された形式であってもよいし、既知のいかなる方式により構成されてもよい。本発明は、これらのコンポーネントの配置、集中又は分散されたアーキテクチャー、あるいは様々なコンポーネントの通信方法により制限されない。
【0063】
さらに、本システム及びここで議論される実施例は、様々な機能性を提供するいくつかのコンポーネント及びサブコンポーネントを含むものとして議論される。これらのコンポーネント及びサブコンポーネントは、注目された機能性を提供するために、ハードウェアとソフトウェアの組合せだけでなく、ハードウェアのみ、ソフトウェアのみによっても実現されうる。さらに、ハードウェア、ソフトウェア、及びそれらの組合せは、汎用の計算装置、専用のハードウェア、又はそれらの組合せにより実現されうる。したがって、コンポーネント又はサブコンポーネントの構成は、コンポーネント又はサブコンポーネントの機能性を提供するための特定のソフトウェアを実行する汎用/専用の計算装置を含む。
【0064】
図11(b)は、文書処理システムの一例の全体のブロック図を示す。このような文書処理システムにおいて文書が生成され編集される。これらの文書は、例えばXMLなど、マークアップ言語の特徴を有する任意の言語により記述されてもよい。また、便宜上、特定のコンポーネント及びサブコンポーネントの用語及び表題を創造した。しかしながら、これらは、この開示の一般的な教示の範囲を制限するために解釈されるべきではない。
【0065】
文書処理システムは、2つの基本的な構成を有するものととらえることができる。第1の構成は、文書処理システムが動作する環境である「実行環境」101である。例えば、実行環境は、文書の処理中及び管理中に、ユーザだけでなくシステムも支援する、基本的なユーティリティ及び機能を提供する。第2の構成は、実行環境において走るアプリケーションから構成される「アプリケーション」102である。これらのアプリケーションは、文書自身及び文書の様々な表現を含む。
【0066】
1.実行環境
実行環境101のキーとなるコンポーネントはProgramInvoker(プログラムインボーカ:プログラム起動部)103である。ProgramInvoker103は、文書処理システムを起動するためにアクセスされる基本的なプログラムである。例えば、ユーザが文書処理システムにログオンして開始するとき、ProgramInvoker103が実行される。ProgramInvoker103は、例えば、文書処理システムにプラグインとして加えられた機能を読み出して実行させたり、アプリケーションを開始して実行させたり、文書に関連するプロパティを読み出すことができる。ProgramInvoker103の機能はこれらに限定されない。ユーザが実行環境内で実行されるように意図されたアプリケーションを起動したいとき、ProgramInvoker103は、そのアプリケーションを見つけ、それを起動して、アプリケーションを実行する。
【0067】
ProgramInvoker103には、プラグインサブシステム104、コマンドサブシステム105、及びResource(リソース)モジュール109などのいくつかのコンポーネントがアタッチされている。これらの構成については、以下に詳述する。
【0068】
a)プラグインサブシステム
プラグインサブシステム104は、文書処理システムに機能を追加するための高度に柔軟で効率的な構成として使用される。プラグインサブシステム104は、また、文書処理システムに存在する機能を修正又は削除するために使用することができる。さらに、種々様々の機能をプラグインサブシステムを使用して追加又は修正することができる。例えば、画面上への文書の描画を支援するように作用するEditlet(エディットレット:編集部)機能を追加することもできる。Editletプラグインは、システムに追加されるボキャブラリの編集も支援する。
【0069】
プラグインサブシステム104は、ServiceBroker(サービスブローカ:サービス仲介部)1041を含む。ServiceBroker1041は、文書処理システムに加えられるプラグインを管理することにより、文書処理システムに加えられるサービスを仲介する。
【0070】
所望の機能性を実現する個々の機能は、Service(サービス)1042の形でシステムに追加される。利用可能なService1042のタイプは、Application(アプリケーション)サービス、ZoneFactory(ゾーンファクトリ:ゾーン生成部)Service、Editlet(エディットレット:編集部)Service、CommandFactory(コマンドファクトリ:コマンド生成部)Service、ConnectXPath(コネクトXPath:XPath管理部)Service、CSSComputation(CSSコンピューテーション:CSS計算部)Serviceなどを含むが、これらに限定されない。これらのService、及びシステムの他の構成とそれらとの関係は、文書処理システムについてのよりよい理解のために、以下に詳述される。
【0071】
プラグインとServiceの関係は以下の通りである。プラグインは、1以上のServiceProvider(サービスプロバイダ:サービス提供部)を含むことができるユニットである。それぞれのServiceProviderは、それに関連したServiceの1以上のクラスを有する。例えば、適切なソフトウェアアプリケーションを有する単一のプラグインを使用することにより、1以上のServiceをシステムに追加することができ、これにより、対応する機能をシステムに追加することができる。
【0072】
b)コマンドサブシステム
コマンドサブシステム105は、文書の処理に関連したコマンドの形式の命令を実行するために使用される。ユーザは、一連の命令を実行することにより、文書に対する操作を実行することができる。例えば、ユーザは、コマンドの形で命令を発行することにより、文書処理システム中のXML文書に対応するXMLのDOMツリーを編集し、XML文書を処理する。これらのコマンドは、キーストローク、マウスクリック、又は他の有効なユーザインタフェイスアクションを使用して入力されてもよい。1つのコマンドにより1以上の命令が実行されることもある。この場合、これらの命令が1つのコマンドにラップ(包含)され、連続して実行される。例えば、ユーザが、誤った単語を正しい単語に置換したいとする。この場合、第1の命令は、文書中の誤った単語を発見することであり、第2の命令は、誤った単語を削除することであり、第3の命令は、正しい単語を挿入することであってもよい。これらの3つの命令が1つのコマンドにラップされてもよい。
【0073】
コマンドは、関連した機能、例えば、後で詳述する「アンドゥ」機能を有してもよい。これらの機能は、オブジェクトを生成するために使用されるいくつかの基本クラスにも割り当てられてもよい。
【0074】
コマンドサブシステム105のキーとなるコンポーネントは、選択的にコマンドを与え、実行するように作用するCommandInvoker(コマンドインボーカ:コマンド起動部)1051である。図11(b)には、1つのCommandInvokerのみが示されているが、1以上のCommandInvokerが使用されてもよく、1以上のコマンドが同時に実行されてもよい。CommandInvoker1051は、コマンドを実行するために必要な機能及びクラスを保持する。動作において、実行されるべきCommand(コマンド:命令)1052は、Queue(キュー)1053に積まれる。CommandInvokerは、連続的に実行するコマンドスレッドを生成する。CommandInvoker内で既に実行中のCommandがなければ、CommandInvoker1051により実行されるように意図されたCommand1052が実行される。CommandInvokerが既にコマンドを実行している場合、新しいCommandは、Queue1053の最後に積まれる。しかしながら、それぞれのCommandInvoker1051では、一度に1つのCommandのみが実行される。指定されたCommandの実行に失敗した場合、CommandInvoker1051は例外処理を実行する。
【0075】
CommandInvoker1051により実行されるCommandの型は、UndoableCommand(取消可能コマンド)1054、AsynchronousCommand(非同期コマンド)1055、及びVCCommand(VCコマンド)1056を含むが、これらに限定されない。UndoableCommand1054は、ユーザが望めば、そのCommandの結果を取り消すことが可能なCommandである。UndoableCommandの例として、切り取り、コピー、テキストの挿入、などがある。動作において、ユーザが文書の一部を選択し、その部分に切り取りコマンドを適用するとき、UndoableCommandを用いることにより、切り取られた部分は、必要であれば、「切り取られていない」ようにすることができる。
【0076】
VCCommand1056は、ボキャブラリコネクション記述子(Vocabulary Connection Descriptor:VCD)スクリプトファイルに格納される。これらは、プログラマにより定義されうるユーザ指定のCommandである。Commandは、例えば、XMLフラグメントを追加したり、XMLフラグメントを削除したり、属性を設定したりするための、より抽象的なCommandの組合せであってもよい。これらのCommandは、特に、文書の編集に焦点を合わせている。
【0077】
AsynchronousCommand1055は、文書のロードや保存など、システムよりのCommandであり、UndoableCommandやVCCommandとは別に、非同期的に実行される。AsynchronousCommandは、UndoableCommandではないので、取り消すことはできない。
【0078】
c)リソース
Resource109は、様々なクラスに、いくつかの機能を提供するオブジェクトである。例えば、ストリングリソース、アイコン、及びデフォルトキーバインドは、システムで使用されるResourceの例である。
【0079】
2.アプリケーションコンポーネント
文書処理システムの第2の主要な特徴であるアプリケーションコンポーネント102は、実行環境101において実行される。アプリケーションコンポーネント102は、実際の文書と、システム内における文書の様々な論理的、物理的な表現を含む。さらに、アプリケーションコンポーネント102は、文書を管理するために使用されるシステムの構成を含む。アプリケーションコンポーネント102は、さらに、UserApplication(ユーザアプリケーション)106、アプリケーションコア108、ユーザインタフェイス107、及びCoreComponent(コアコンポーネント)110を含む。
【0080】
a)ユーザアプリケーション
UserApplication106は、ProgramInvoker103と共にシステム上にロードされる。UserApplication106は、文書と、文書の様々な表現と、文書と対話するために必要なユーザインタフェイスとをつなぐ接着剤となる。例えば、ユーザが、プロジェクトの一部である文書のセットを生成したいとする。これらの文書がロードされると、文書の適切な表現が生成される。ユーザインタフェイス機能は、UserApplication106の一部として追加される。言いかえれば、UserApplication106は、ユーザがプロジェクトの一部を形成する文書と対話することを可能とする文書の表現と、文書の様々な態様とを、共に保持する。一旦UserApplication106が生成されると、ユーザがプロジェクトの一部を形成する文書との対話を望むたびに、ユーザは簡単に実行環境上にUserApplication106をロードすることができる。
【0081】
b)コアコンポーネント
CoreComponent110は、複数のPane(ペイン)の間で文書を共有する方法を提供する。後で詳述するように、Paneは、DOMツリーを表示し、画面の物理的なレイアウトを扱う。例えば、物理的な画面は、個々の情報の断片を描写する画面内の複数のPaneからなる。ユーザから画面上に見える文書は、1又はそれ以上のPaneに出現しうる。また、2つの異なる文書が画面上で2つの異なるPaneに現れてもよい。
【0082】
図11(c)に示されるように、画面の物理的なレイアウトもツリーの形式になっている。Paneは、RootPane(ルートペイン)1084にもなり得るし、SubPane(サブペイン)1085にもなり得る。RootPane1084は、Paneのツリーの根に当たるPaneであり、SubPane1085は、RootPane1084以外の任意のPaneである。
【0083】
CoreComponent110は、さらに、フォントを提供し、ツールキットなど、文書のための複数の機能的な操作のソースの役割を果たす。CoreComponent110により実行されるタスクの一例に、複数のPane間におけるマウスカーソルの移動がある。実行されるタスクの他の例として、あるPane中の文書の一部をマークし、それを異なる文書を含む別のPane上にコピーする。
【0084】
c)アプリケーションコア
上述したように、アプリケーションコンポーネント102は、システムにより処理され管理される文書から構成される。これは、システム内における文書の様々な論理的及び物理的な表現を含む。アプリケーションコア108は、アプリケーションコンポーネント102の構成である。その機能は、実際の文書を、それに含まれる全てのデータとともに保持することである。アプリケーションコア108は、DocumentManager(ドキュメントマネージャ:文書管理部)1081及びDocument(ドキュメント:文書)1082自身を含む。
【0085】
DocumentManager1081の様々な態様を以下に詳述する。DocumentManager1081は、Document1082を管理する。DocumentManager1081は、RootPane1084、SubPane1085、ClipBoard(クリップボード)ユーティリティ1087、及びSnapShot(スナップショット)ユーティリティ1088にも接続される。ClipBoardユーティリティ1087は、ユーザがクリップボードに加えることを決定した文書の部分を保持する方法を提供する。例えば、ユーザが、文書の一部を切り取り、後で再考するために新規文書にそれを保存することを望んだとする。このような場合、切り取られた部分がClipBoardに追加される。
【0086】
つづいて、SnapShotユーティリティ1088についても説明する。SnapShotユーティリティ1088は、アプリケーションがある状態から別の状態まで移行するときに、アプリケーションの現在の状態を記憶することを可能とする。
【0087】
d)ユーザインタフェイス
アプリケーションコンポーネント102の別の構成は、ユーザがシステムと物理的に対話する手段を提供するユーザインタフェイス107である。例えば、ユーザインタフェイスは、ユーザが文書をアップロードしたり、削除したり、編集したり、管理したりするために使用される。ユーザインタフェイスは、Frame(フレーム)1071、MenuBar(メニューバー)1072、StatusBar(ステータスバー)1073、及びURLBar(URLバー)1074を含む。
【0088】
Frame1071は、一般に知られているように、物理的な画面のアクティブな領域であるとみなされる。MenuBar1072は、ユーザに選択を提供するメニューを含む画面領域である。StatusBar1073は、アプリケーションの実行状態を表示する画面領域である。URLBar1074は、インターネットをナビゲートするためにURLアドレスを入力する領域を提供する。
【0089】
C.文書管理及び関連するデータ構造
図12は、DocumentManager1081の詳細を示す。これは、文書処理システム内で文書を表現するために用いられるデータ構造及び構成を含む。分かりやすくするために、このサブセクションで説明される構成は、MVCパラダイムを用いて説明される。
【0090】
DocumentManager1081は、文書処理システム内にある全ての文書を保持しホストするDocumentContainer(ドキュメントコンテナ:文書コンテナ)203を含む。DocumentManager1081にアタッチされたツールキット201は、DocumentManager1081により使用される様々なツールを提供する。例えば、DomService(DOMサービス)は、文書に対応するDOMを生成し、保持し、管理するために必要とされる全ての機能を提供するために、ツールキット201により提供されるツールである。ツールキット201により提供される別のツールであるIOManager(入出力管理部)は、システムへの入力及びシステムからの出力を管理する。同様に、StreamHandler(ストリームハンドラ)は、ビットストリームによる文書のアップロードを扱うツールである。これらのツールは、図中に特に示さず、参照番号を割り当てないが、ツールキット201のコンポーネントを形成する。
【0091】
MVCパラダイムの表現によれば、モデル(M)は、文書のDOMツリーモデル202を含む。前述したように、全ての文書は、文書処理システムにおいてDOMツリーとして表現される。文書は、また、DocumentContainer203の一部を形成する。
【0092】
1.DOMモデル及びゾーン
文書を表現するDOMツリーは、Node(ノード)2021を有するツリーである。DOMツリーの部分集合であるZone(ゾーン)209は、DOMツリー内の1以上のNodeの関連領域を含む。例えば、画面上で文書の一部のみを表示し得るが、この可視化された文書の一部はZone209を用いて表示される。Zoneは、ZoneFactory(ゾーンファクトリ:ゾーン生成部)205と呼ばれるプラグインを用いて、生成され、取り扱われ、処理される。ZoneはDOMの一部を表現するが、1以上の「名前空間」を使用してもよい。よく知られているように、名前空間は、名前空間内でユニークな名前の集合である。換言すれば、名前空間内に同じ名前は存在しない。
【0093】
2.Facet及びFacetとZoneとの関係
Facet(ファセット)2022は、MVCパラダイムのモデル(M)部分内の別の構成である。Facetは、ZoneにおいてNodeを編集するために使用される。Facet2022は、Zone自身の内容に影響を与えずに実行することができる手続(プロシージャ)を使用して、DOMへのアクセスを編成する。次に説明するように、これらの手続は、Nodeに関連した重要で有用な操作を実行する。
【0094】
各Nodeは、対応するFacetを有する。DOMの中のNodeを直接操作する代わりに、操作を実行するためにFacetを使用することによって、DOMの保全性は保護される。操作がNode上で直接実行される場合、いくつかのプラグインがDOMを同時に変更することができ、その結果矛盾を引き起こす。
【0095】
W3Cが策定したDOMの標準規格は、Nodeを操作するための標準的なインタフェイスを定義するが、実際には、ボキャブラリごと又はNodeごとに特有の操作があるので、これらの操作をAPIとして用意しておくのが好都合である。文書処理システムでは、このような各Nodeに特有のAPIをFacetとして用意し、各Nodeにアタッチする。これにより、DOMの標準規格に準拠しつつ、有用なAPIを付加することができる。また、ボキャブラリごとに特有のDOMを実装するのではなく、標準的なDOMの実装に、後から特有のAPIを付加するようにすることで、多様なボキャブラリを統一的に処理することができるともに、複数のボキャブラリが任意の組合せで混在した文書を適切に処理することができる。
【0096】
ボキャブラリは、名前空間に属するタグ(例えばXMLのタグ)のセットである。上述したように、名前空間は、ユニークな名前(ここではタグ)のセットを有する。ボキャブラリは、XML文書を表現するDOMツリーのサブツリーとして現れる。このサブツリーはZoneを含む。特定の例においては、タグセットの境界はZoneによって定義される。Zone209は、ZoneFactory205と呼ばれるServiceを利用して生成される。上述したように、Zone209は、文書を表現するDOMツリーの一部の内部表現である。このような文書の一部へのアクセスを提供するために、論理的な表現が要求される。この論理的表現は、文書が画面上で論理的にどのように表現されるかについてコンピュータに通知する。Canvas(キャンバス)210は、Zoneに対応する論理的なレイアウトを提供するように作用するServiceである。
【0097】
他方、Pane211は、Canvas210により提供される論理的なレイアウトに対応する物理的な画面レイアウトである。実際、ユーザは表示画面上で文字や画像によって文書のレンダリングのみを見る。したがって、文書は、画面上に文字や画像を描画するプロセスにより、画面上に描写されなければならない。文書は、Pane211により提供される物理的なレイアウトに基づいて、Canvas210により画面上に描写される。
【0098】
Zone209に対応するCanvas210は、Editlet206を使用して生成される。文書のDOMは、Editlet206及びCanvas210を使用して編集される。元の文書の完全性を維持するために、Editlet206及びCanvas210は、Zone209における1以上のNodeに対応するFacetを使用する。これらのServiceは、Zone及びDOM内のNodeを直接操作しない。Facetは、Command207を利用して操作される。
【0099】
ユーザは、一般に、画面上のカーソルを移動させたり、コマンドをタイプしたりすることによって、画面と対話する。画面上の論理的なレイアウトを提供するCanvas210は、このカーソル操作を受け付ける。Canvas210は、対応するアクションをFacetに実行させることができる。この関係により、カーソルサブシステム204は、DocumentManager1081に対して、MVCパラダイムのコントローラ(C)として機能する。Canvas210は、イベントを扱うタスクも有する。例えば、Canvas210は、マウスクリック、フォーカス移動、及びユーザにより起こされた同様のアクションなどのイベントを扱う。
【0100】
3.Zone、Facet、Canvas及びPaneの間の関係の概要
文書処理システム内の文書は、少なくとも4つの観点から見ることができる。すなわち、1)文書処理システムにおいて文書の内容及び構造を保持するために用いられるデータ構造、2)文書の保全性に影響を与えずに文書の内容を編集する手段、3)文書の画面上の論理的なレイアウト、4)文書の画面上の物理的なレイアウト、である。Zone、Facet、Canvas及びPaneは、前述の4つの観点に相当する、文書処理システムのコンポーネントをそれぞれ表す。
【0101】
4.アンドゥサブシステム
上述したように、文書に対するいかなる変更(例えば編集)も取消可能であることが望ましい。例えば、ユーザが編集操作を実行し、次に、その変更の取消を決定したとする。図12に関連して、アンドゥサブシステム212は、文書管理部の取消可能なコンポーネントを実現する。UndoManager(アンドゥマネージャ:アンドゥ管理部)2121は、ユーザによって取り消される可能性のある全ての文書に対する操作を保持する。
【0102】
例えば、ユーザが、文書中の単語を別の単語に置換するコマンドを実行したとする。その後、ユーザは考え直し、元の単語に戻すことを決定したとする。アンドゥサブシステム212は、このような操作を支援する。UndoManager2121は、このようなUndoableEdit(アンドゥアブルエディット:取消可能な編集)2122の操作を保持する。
【0103】
5.カーソルサブシステム
前述したように、MVCのコントローラ部分は、カーソルサブシステム204を備えてもよい。カーソルサブシステム204は、ユーザから入力を受け付ける。これらの入力は、一般にコマンド及び/又は編集操作の性格を有している。したがって、カーソルサブシステム204は、DocumentManager1081に関連したMVCパラダイムのコントローラ(C)部分であると考えることができる。
【0104】
6.ビュー
前述したように、Canvas210は、画面上に提示されるべき文書の論理的なレイアウトを表す。XHTML文書の例では、Canvas210は、文書が画面上でいかに見えるかを論理的に表現したボックスツリー208を含んでもよい。このボックスツリー208は、DocumentManager1081に関連したMVCパラダイムのビュー(V)部分に含まれよう。
【0105】
D.ボキャブラリコネクション
文書処理システムの重要な特徴は、XML文書を、他の表現にマップして取り扱うことが可能で、かつ、マップした先の表現を編集すると、その編集が元のXML文書に整合性を保ちつつ反映される環境を提供することにある。
【0106】
マークアップ言語により記述された文書、例えばXML文書は、文書型定義により定義されたボキャブラリに基づいて作成されている。ボキャブラリは、タグのセットである。ボキャブラリは、任意に定義されてもよいため、無限に多くのボキャブラリが存在しうる。しかしながら、多数の可能なボキャブラリのそれぞれに対して専用の処理/管理環境を提供するのは現実的ではない。ボキャブラリコネクションは、この問題を解決する方法を提供する。
【0107】
例えば、文書は2以上のマークアップ言語により記述されてもよい。文書は、例えば、XHTML(eXtensible HyperText Markup Language)、SVG(Scalable Vector Graphics)、MathML(Mathematical Markup Language)、その他のマークアップ言語により記述されてもよい。換言すれば、マークアップ言語は、XMLにおけるボキャブラリやタグセットと同様に見なされてもよい。
【0108】
ボキャブラリは、ボキャブラリプラグインを用いて処理される。文書処理システムにおいてプラグインが利用不可能であるボキャブラリにより記述された文書は、プラグインが利用可能である別のボキャブラリの文書にマッピングすることにより表示される。この特徴により、プラグインが用意されていないボキャブラリの文書も適切に表示することができる。
【0109】
ボキャブラリコネクションは、定義ファイルを取得し、取得した定義ファイルに基づいて2つの異なるボキャブラリの間でマッピングする能力を含む。あるボキャブラリで記述された文書は、別のボキャブラリにマッピングすることができる。このように、ボキャブラリコネクションは、文書がマッピングされるボキャブラリに対応した表示/編集プラグインにより文書を表示し編集することを可能にする。
【0110】
上述したように、各文書は、一般に複数のノードを有するDOMツリーとして文書処理システムにおいて記述される。「定義ファイル」は、それぞれのノードについて、そのノードと他のノードとの対応を記述する。各ノードの要素値及び属性値が編集可能か否かが指定される。ノードの要素値又は属性値を用いた演算式が記述されてもよい。
【0111】
マッピングという特徴を利用して、定義ファイルを適用したデスティネーションDOMツリーが生成される。このように、ソースDOMツリーとデスティネーションDOMツリーの関係が構築され保持される。ボキャブラリコネクションは、ソースDOMツリーとデスティネーションDOMツリーの対応を監視する。ユーザから編集指示を受けると、ボキャブラリコネクションは、ソースDOMツリーの関連したノードを変更する。ソースDOMツリーが変更されたことを示す「ミューテーションイベント」が発行され、デスティネーションDOMツリーがそれに応じて変更される。
【0112】
ボキャブラリコネクションの使用により、少数のユーザのみに知られていた比較的マイナーなボキャブラリを、別のメジャーなボキャブラリに変換することができる。したがって、少数のユーザによって利用されるマイナーなボキャブラリであっても、文書を適切に表示し、望ましい編集環境を提供することができる。
【0113】
このように、文書処理システムの一部であるボキャブラリコネクションサブシステムは、文書の複数の表現を可能にする機能を提供する。
【0114】
図13は、ボキャブラリコネクション(VC:Vocabulary Connection)サブシステム300を示す。VCサブシステム300は、同一の文書の2つの代替表現の整合性を維持する方法を提供する。例えば、2つの表現は、同一文書の、2つの異なるボキャブラリによる表現であってもよい。前述したように、一方はソースDOMツリーであってもよく、他方はデスティネーションDOMツリーであってもよい。
【0115】
1.ボキャブラリコネクションサブシステム
ボキャブラリコネクションサブシステム300の機能は、VocabularyConnection301と呼ばれるプラグインを使用して、文書処理システムにおいて実現される。文書が表現されるVocabulary305ごとに、対応するプラグインが要求される。例えば、文書の一部がHTMLで記述され、残りがSVGで記述されている場合、HTMLとSVGに対応するボキャブラリプラグインが要求される。
【0116】
VocabularyConnectionプラグイン301は、適切なVocabulary305の文書に対応した、Zone209又はPane211のための適切なVCCanvas(ボキャブラリコネクションキャンバス)310を生成する。VocabularyConnection301を用いて、ソースDOMツリー内のZone209に対する変更は、変換ルールにより、別のDOMツリー306の対応するZoneに伝達される。変換ルールは、ボキャブラリコネクション記述子(Vocabulary Connection Descriptor:VCD)の形式で記述される。このようなソースDOMとデスティネーションDOMの間の変換に対応するそれぞれのVCDファイルについて、対応するVCManager(ボキャブラリコネクションマネージャ)302が生成される。
【0117】
2.Connector
Connector304は、ソースDOMツリーのソースノードと、デスティネーションDOMツリーのデスティネーションノードとを接続する。Connector304は、ソースDOMツリー中のソースノード、及びソースノードに対応するソース文書に対する修正(変更)を見るために作用する。そして、対応するデスティネーションDOMツリーのノードを修正する。Connector304は、デスティネーションDOMツリーを修正することができる唯一のオブジェクトである。例えば、ユーザは、ソース文書、及び対応するソースDOMツリーに対してのみ修正を行うことができる。その後、Connector304がデスティネーションDOMツリーに、対応する修正を行う。
【0118】
Connector304は、ツリー構造を形成するために、論理的にリンクされる。Connector304により形成されたツリーは、ConnectorTree(コネクタツリー)と呼ばれる。Connector304は、ConnectorFactory(コネクタファクトリ:コネクタ生成部)303と呼ばれるServiceを用いて生成される。ConnectorFactory303は、ソース文書からConnector304を生成し、それらをリンクしてConnectorTreeを形成する。VocabularyConnectionManager302は、ConnectorFactory303を保持する。
【0119】
前述したように、ボキャブラリは名前空間におけるタグのセットである。図示されるように、Vocabulary305は、VocabularyConnection301によって文書に対して生成される。これは、文書ファイルを解析し、ソースDOMとデスティネーションDOMの間の写像のための適切なVocabularyConnectionManager302を生成することにより行われる。さらに、Connectorを生成するConnectorFactory303と、Zone209を生成するZoneFactory205と、Zone内のノードに対応するCanvasを生成するEditlet206との間の適切な関係が作られる。ユーザがシステムから文書を処分又は削除するとき、対応するVocabularyConnectionManager302が削除される。
【0120】
Vocabulary305は、VCCanvas310を生成する。さらに、Connector304及びデスティネーションDOMツリー306が対応して生成される。
【0121】
ソースDOM及びCanvasは、それぞれ、モデル(M)及びビュー(V)に対応する。しかしながら、このような表現は、ターゲットのボキャブラリが画面上に描写可能である場合に限って意味がある。描写は、ボキャブラリプラグインにより行われる。ボキャブラリプラグインは、主要なボキャブラリ、例えば、XHTML、SVG、MathMLについて提供される。ボキャブラリプラグインは、ターゲットのボキャブラリに関連して使用される。これらは、ボキャブラリコネクション記述子を用いてボキャブラリ間でマッピングする方法を提供する。
【0122】
このようなマッピングは、ターゲットのボキャブラリが、マッピング可能で、画面上に描写される方法が予め定義されたものである場合にのみ意味がある。このようなレンダリング方法は、例えばXHTMLなどのように、W3Cなどの組織により定義された標準規格となっている。
【0123】
ボキャブラリコネクションが必要であるとき、VCCanvasが使用される。この場合、ソースのビューを直接生成することができないので、ソースのCanvasは生成されない。この場合、VCCanvasが、ConnectorTreeを使用して生成される。このVCCanvasは、イベントの変換のみを扱い、画面上の文書の描写を援助しない。
【0124】
3.DestinationZone、Pane、及びCanvas
上述したように、ボキャブラリコネクションサブシステムの目的は、同一の文書の2つの表現を同時に生成し保持することである。第2の表現も、DOMツリーの形式であり、これはデスティネーションDOMツリーとして既に説明した。第2の表現における文書を見るために、DestinationZone、Canvas及びPaneが必要である。
【0125】
VCCanvasが作成されると、対応するDestinationPane307が生成される。さらに、関連するDestinationCanvas308と、対応するBoxTree309が生成される。同様に、VCCanvas310も、ソース文書に対するPane211及びZone209に関連づけられる。
【0126】
DestinationCanvas308は、第2の表現における文書の論理的なレイアウトを提供する。特に、DestinationCanvas308は、デスティネーション表現における文書を描写するために、カーソルや選択のようなユーザインタフェイス機能を提供する。DestinationCanvas308に生じたイベントは、Connectorに供給される。DestinationCanvas308は、マウスイベント、キーボードイベント、ドラッグアンドドロップイベント、及び文書のデスティネーション(第2)表現のボキャブラリに特有なイベントを、Connector304に通知する。
【0127】
4.ボキャブラリコネクションコマンドサブシステム
ボキャブラリコネクション(VC)サブシステム300の要素として、ボキャブラリコネクション(VC)コマンドサブシステム313がある。ボキャブラリコネクションコマンドサブシステム313は、ボキャブラリコネクションサブシステム300に関連した命令の実行のために使用されるVCCommand(ボキャブラリコネクションコマンド)315を生成する。VCCommandは、内蔵のCommandTemplate(コマンドテンプレート)318を使用して、及び/又は、スクリプトサブシステム314においてスクリプト言語を使用してスクラッチからコマンドを生成することにより、生成することができる。
【0128】
コマンドテンプレートには、例えば、「If」コマンドテンプレート、「When」コマンドテンプレート、「挿入(Insert)」コマンドテンプレートなどがある。これらのテンプレートは、VCCommandを作成するために使用される。
【0129】
5.XPathサブシステム
XPathサブシステム316は、文書処理システムの重要な構成であり、ボキャブラリコネクションの実現を支援する。Connector304は、一般にxpath情報を含む。上述したように、ボキャブラリコネクションのタスクの1つは、ソースDOMツリーの変化をデスティネーションDOMツリーに反映させることである。xpath情報は、変更/修正を監視されるべきソースDOMツリーのサブセットを決定するために用いられる1以上のxpath表現を含む。
【0130】
6.ソースDOMツリー、デスティネーションDOMツリー、及びConnectorTreeの概要
ソースDOMツリーは、別のボキャブラリに変換される前のボキャブラリで文書を表現したDOMツリー又はZoneである。ソースDOMツリーのノードは、ソースノードと呼ばれる。
【0131】
それに対して、デスティネーションDOMツリーは、ボキャブラリコネクションに関連して前述したように、同一の文書を、マッピングにより変換された後の異なるボキャブラリで表現したDOMツリー又はZoneである。デスティネーションDOMツリーのノードは、デスティネーションノードと呼ばれる。
【0132】
ConnectorTreeは、ソースノードとデスティネーションノードの対応を表すConnectorに基づく階層的表現である。Connectorは、ソースノードと、ソース文書になされた修正を監視し、デスティネーションDOMツリーを修正する。Connectorは、デスティネーションDOMツリーを修正することを許された唯一のオブジェクトである。
【0133】
E.文書処理システムにおけるイベントフロー
実用のためには、プログラムはユーザからのコマンドに応答しなければならない。イベントは、プログラム上で実行されたユーザアクションを記述し実行する方法である。多くの高級言語、例えばJava(登録商標)は、ユーザアクションを記述するイベントに頼っている。従来、プログラムは、ユーザアクションを理解し、それを自身で実行するために、積極的に情報を集める必要があった。これは、例えば、プログラムが自身を初期化した後、ユーザが画面、キーボード、マウスなどでアクションを起こしたときに適切な処理を講じるために、ユーザのアクションを繰り返し確認するループに入ることを意味する。しかしながら、このプロセスは扱いにくい。さらに、それは、ユーザが何かをするのを待つ間、CPUサイクルを消費してループするプログラムを必要とする。
【0134】
多くの言語が、異なるパラダイムを採用することにより、これらの問題を解決している。そのうちの一つは、現代の全てのウィンドウシステムの基礎となっている、イベントドリブンプログラミングである。このパラダイムでは、全てのユーザアクションは、「イベント」と呼ばれる抽象的な事象の集合に属する。イベントは、十分詳細に、特定のユーザアクションを記述する。プログラムがユーザにより生成されたイベントを積極的に収集するのではなく、監視すべきイベントが生じたときに、システムがプログラムに通知する。この方法によりユーザとの対話を扱うプログラムは「イベントドリブン」であると言われる。
【0135】
これは、多くの場合、全てのユーザにより生成されたイベントの基本特性を獲得する「Event(イベント)」クラスを使用して扱われる。
【0136】
文書処理システムは、自身のイベント、及びこれらのイベントを扱う方法を定義して使用する。いくつかの型のイベントが使用される。例えば、マウスイベントは、ユーザのマウスアクションから起こるイベントである。マウスを含むユーザアクションは、Canvas210によって、マウスイベントに渡される。このように、Canvasは、システムのユーザによる相互作用の最前部にあると言える。必要であれば、最前部にあるCanvasは、そのイベントに関連した内容を子へ渡す。
【0137】
それに対して、キーストロークイベントは、Canvas210から流れる。キーストロークイベントは、即時的なフォーカスを有する。すなわち、それは、いかなる瞬間でも作業に関連する。Canvas210上に入力されたキーストロークイベントは、その親に渡される。キー入力は、文字列挿入を扱うことが可能な、異なるイベントによって処理される。文字列の挿入を扱うイベントは、キーボードを使用して文字が挿入されたときに発生する。他の「イベント」は、例えば、ドラッグイベント、ドロップイベント、マウスイベントと同様に扱われる他のイベントを含む。
【0138】
1.ボキャブラリコネクション外のイベントの取り扱い
イベントは、イベントスレッドを用いて渡される。Canvas210は、イベントを受け取ると、その状態を変更する。必要であれば、Command1052がCanvas210によりCommandQueue1053にポストされる。
【0139】
2.ボキャブラリコネクション内のイベントの取り扱い
VocabularyConnectionプラグイン301を用いて、DestinationCanvasの一例であるXHTMLCanvas1106は、発生したイベント、例えば、マウスイベント、キーボードイベント、ドラッグアンドドロップイベント、及びボキャブラリに特有のイベントなどを受け取る。これらのイベントは、コネクタ304に通知される。より詳細には、図21(b)に図示されるように、VocabularyConnectionプラグイン301内のイベントフローは、SourcePane1103、VCCanvas1104、DestinationPane1105、DestinationCanvasの一例であるDestinationCanvas1106、デスティネーションDOMツリー及びConnectorTreeを通過する。
【0140】
F.ProgramInvoker及びProgramInvokerと他の構成との関係
ProgramInvoker103及びそれと他の構成との関係は、図14(a)に更に詳細に示される。ProgramInvoker103は、文書処理システムを開始するために実行される実行環境中の基本的なプログラムである。図11(b)及び図11(c)に図示されるように、UserApplication106、ServiceBroker1041、CommandInvoker1051、及びResource109は、全てProgramInvoker103に接続される。前述したように、アプリケーション102は、実行環境中で実行されるコンポーネントである。同様に、ServiceBroker1041は、システムに様々な機能を加えるプラグインを管理する。他方、CommandInvoker1051は、ユーザにより提供される命令を実行して、コマンドを実行するために使用されるクラス及びファンクションを保持する。
【0141】
1.プラグイン及びサービス
ServiceBroker1041について、図14(b)を参照して更に詳細に説明する。前述したように、ServiceBroker1041は、システムに様々な機能を追加するプラグイン(及び関連するサービス)を管理する。Service1042は、文書処理システムに特徴を追加又は変更可能な最も下の層である。「Service」は、ServiceCategory401とServiceProvider402の2つの部分からなる。図14(c)に図示されるように、1つのServiceCategory401は、複数の関連するServiceProvider402を持ちうる。それぞれのServiceProviderは、特定のServiceCategoryの一部または全部を実行するように作用する。ServiceCategory401は、他方では、Serviceの型を定義する。
【0142】
Serviceは、1)文書処理システムに特定の特色を提供する「特色サービス」、2)文書処理システムにより実行されるアプリケーションである「アプリケーションサービス」、3)文書処理システムの全体にわたって必要な特色を提供する「環境サービス」、の3つの型に分類することができる。
【0143】
Serviceの例は、図14(d)に示される。アプリケーションServiceのCategoryにおいては、システムユーティリティが対応するServiceProviderの例である。同様に、Editlet206はCategoryであり、HTMLEditlet及びSVGEditletは対応するServiceProviderである。ZoneFactory205は、Serviceの別のCategoryであり、対応するServiceProvider(図示せず)を有する。
【0144】
プラグインは、文書処理システムに機能性を加えると既に説明したが、いくつかのServiceProvider402及びそれらに関連するクラスからなるユニットと見なされてもよい。各プラグインは、宣言ファイルに記述された依存性及びServiceCategory401を有する。
【0145】
2.ProgramInvokerとアプリケーションとの関係
図14(e)は、ProgramInvoker103とUserApplication106との関係についての更なる詳細を示す。必要な文書やデータなどは、ストレージからロードされる。必要なプラグインは、全てServiceBroker1041上にロードされる。ServiceBroker1041は、全てのプラグインを保持し管理する。プラグインは、システムに物理的に追加することができ、又、その機能はストレージからロードすることができる。プラグインの内容がロードされると、ServiceBroker1041は、対応するプラグインを定義する。つづいて、対応するUserApplication106が生成され、実行環境101にロードされ、ProgramInvoker103にアタッチされる。
【0146】
G.アプリケーションサービスと環境との関係
図15(a)は、ProgramInvoker103上にロードしたアプリケーションサービスの構成についての更なる詳細を示す。コマンドサブシステム105のコンポーネントであるCommandInvoker1051は、ProgramInvoker103内のCommand1052を起動又は実行する。Command1052は、文書処理システムにおいて、XMLなどの文書を処理し、対応するXMLDOMツリーを編集するために用いられる命令である。CommandInvoker1051は、Command1052を実行するために必要なクラス及びファンクションを保持する。
【0147】
ServiceBroker1041も、ProgramInvoker103内で実行される。UserApplication106は、ユーザインタフェイス107及びCoreComponent110に接続される。CoreComponent110は、全てのPaneの間で文書を共有する方法を提供する。CoreComponent110は、さらにフォントを提供し、Paneのためのツールキットの役割を果たす。
【0148】
図15(b)は、Frame1071、MenuBar1072、及びStatusBar1073の関係を示す。
【0149】
H.アプリケーションコア
図16(a)は、全ての文書、及び文書の一部及び文書に属するデータを保持するアプリケーションコア108についての更なる説明を提供する。CoreComponent110は、文書1082を管理するDocumentManager1081にアタッチされる。DocumentManager1081は、文書処理システムに関連づけられたメモリに格納される全ての文書1082の所有者である。
【0150】
画面上の文書の表示を容易にするために、DocumentManager1081はRootPane1084にも接続される。ClipBoard1087、SnapShot1088、Drag&Drop601、及びOverlay602の機能も、CoreComponent110にアタッチされる。
【0151】
SnapShot1088は、アプリケーションの状態を元に戻すために使用される。ユーザがSnapShot1088を起動したとき、アプリケーションの現状が検知され、格納される。その後、アプリケーションの状態が別の状態に変わるとき、格納された状態の内容は保存される。SnapShot1088は、図16(b)に図示される。動作において、アプリケーションがあるURLから他へ移動するときに、前に戻る動作及び先に進む動作をシームレスに実行可能とするために、SnapShot1088は以前の状態を記憶する。
【0152】
I.DocumentManager内における文書の構成
図17(a)は、DocumentManager1081の更なる説明と、DocumentManagerにおいて文書が構成され保持される様子を示す。図11(b)に示したように、DocumentManager1081は、文書1082を管理する。図17(a)に示される例において、複数の文書のうちの1つはRootDocument(ルート文書)701であり、残りの文書はSubDocument(サブ文書)702である。DocumentManager1081は、RootDocument701に接続され、RootDocument701は、全てのSubDocument702に接続される。
【0153】
図12及び図17(a)に示すように、DocumentManager1081は、全ての文書1082を管理するオブジェクトであるDocumentContainer203に結合される。DOMService703及びIOManager704を含むツールキット201(例えばXMLツールキット)の一部を形成するツールも、DocumentManager1081に供給される。再び図17(a)を参照して、DOMService703は、DocumentManager1081により管理される文書に基づいたDOMツリーを生成する。各Document705は、それがRootDocument701であってもSubDocument702であっても、対応するDocumentContainer203によって管理される。
【0154】
図17(b)は、文書A−Eが階層的に配置される様子を示す。文書AはRootDocumentである。文書B−Dは、文書AのSubDocumentである。文書Eは、文書DのSubDocumentである。図17(b)の左側は、これと同じ文書の階層が画面上に表示された例を示す。RootDocumentである文書Aは、基本フレームとして表示される。文書AのSubDocumentである文書B−Dは、基本フレームAの中のサブフレームとして表示される。文書DのSubDocumentである文書Eは、サブフレームDのサブフレームとして画面に表示される。
【0155】
再び図17(a)を参照して、UndoManager(アンドゥマネージャ:アンドゥ管理部)706及びUndoWrapper(アンドゥラッパー)707は、それぞれのDocumentContainer203に対して生成される。UndoManager706及びUndoWrapper707は、取消可能なコマンドを実行するために使用される。この特徴を使用することにより、編集操作を使用して文書に対して実行された変更を取り消すことができる。SubDocumentの変更は、RootDocumentとも密接な関係を有する。アンドゥ操作は、階層内の他の文書に影響する変更を考慮に入れて、例えば、図17(b)に示されるような連鎖状の階層における全ての文書の間で整合性が維持されることを保証する。
【0156】
UndoWrapper707は、DocumentContainer203内のSubDocumentに関連するアンドゥオブジェクトをラップし、それらをRootDocumentに関連するアンドゥオブジェクトに結合させる。UndoWrapper707は、UndoableEditAcceptor(アンドゥアブルエディットアクセプタ:アンドゥ可能編集受付部)709に利用可能なアンドゥオブジェクトの収集を実行する。
【0157】
UndoManager706及びUndoWrapper707は、UndoableEditAcceptor709及びUndoableEditSource(アンドゥアブルエディットソース)708に接続される。当業者には理解されるように、Document705がUndoableEditSource708であってもよく、取消可能な編集オブジェクトのソースであってもよい。
【0158】
J.アンドゥコマンド及びアンドゥフレームワーク
図18(a)及び図18(b)は、アンドゥフレームワーク及びアンドゥコマンドについて更なる詳細を提供する。図18(a)に示されるように、UndoCommand801、RedoCommand802、及びUndoableEditCommand803は、図11(b)に示したようにCommandInvoker1051に積むことができるコマンドであり、順に実行される。UndoableEditCommand803は、UndoableEditSource708及びUndoableEditAcceptor709に更にアタッチされる。「foo」EditCommand804及び「bar」EditCommand805は、UndoableEditCommandの例である。
【0159】
1.UndoableEditCommandの実行
図18(b)は、UndoableEditCommandの実行を示す。まず、ユーザが編集コマンドを使用してDocument705を編集すると仮定する。第1ステップS1では、UndoableEditAcceptor709が、Document705のDOMツリーであるUndoableEditSource708にアタッチされる。第2ステップS2では、ユーザにより発行されたコマンドに基づいて、Document705がDOMのAPIを用いて編集される。第3ステップS3では、ミューテーションイベントのリスナーが、変更がなされたことを通知される。すなわち、このステップでは、DOMツリーの全ての変更を監視するリスナーが編集操作を検知する。第4ステップS4では、UndoableEditがUndoManager706のオブジェクトとして格納される。第5ステップS5では、UndoableEditAcceptor709がUndoableEditSource708からデタッチされる。UndoableEditSource708は、Document705自身であってもよい。
【0160】
K.システムへの文書のロードに関する手順
上記のサブセクションでは、システムの様々なコンポーネント及びサブコンポーネントについて説明した。以下、これらのコンポーネントの使用に関する方法論について説明する。図19(a)は、文書処理システムに文書がロードされる様子の概要を示す。それぞれのステップは、図24−28において、特定の例に関連して詳述される。
【0161】
簡単には、文書処理システムは、文書に含まれるデータからなるバイナリデータストリームからDOMを生成する。ApexNode(エイペックスノード:頂点ノード)が、注目対象でありZoneに属する文書の一部のために生成される。つづいて、対応するPaneが同定される。同定されたPaneは、ApexNode及び物理的な画面表面からZone及びCanvasを生成する。Zoneは、次に、それぞれのノードにFacetを生成し、それらに必要とされる情報を提供する。Canvasは、DOMツリーから、ノードをレンダリングするためのデータ構造を生成する。
【0162】
より詳細には、文書はストレージ901からロードされる。文書のDOMツリー902が生成される。文書を保持するための、対応するDocumentContainer903が生成される。DocumentContainer903は、DocumentManager904にアタッチされる。DOMツリーは、ルートノードと、ときには複数のセカンダリノードを含む。
【0163】
一般に、このような文書は、テキスト及びグラフィクスの双方を含む。したがって、DOMツリーは、例えば、XHTMLサブツリーだけでなくSVGサブツリーを有してもよい。XHTMLサブツリーは、XHTMLのApexNode905を有する。同様に、SVGサブツリーは、SVGのApexNode906を有する。
【0164】
ステップ1では、ApexNode906が、画面の論理的なレイアウトであるPane907にアタッチされる。ステップ2では、Pane907は、PaneOwner(ペインオーナー:ペインの所有者)908であるCoreComponentに、ApexNode906のためのZoneFactoryを要求する。ステップ3では、PaneOwner908は、ZoneFactoryと、ApexNode906のためのCanvasFactoryであるEditletとを返す。
【0165】
ステップ4では、Pane907がZone909を生成する。Zone909はPane907にアタッチされる。ステップ5では、Zone909がそれぞれのノードに対してFacetを生成し、対応するノードにアタッチする。ステップ6では、Pane907がCanvas910を生成する。Canvas910はPane907にアタッチされる。Canvas910には様々なCommandが含まれる。ステップ7では、Canvas910が文書を画面にレンダリングするためのデータ構造を構築する。XHTMLの場合、これはボックスツリー構造を含む。
【0166】
1.ZoneのMVC
図19(b)は、MVCパラダイムを用いてZoneの構成の概要を示す。この場合、Zone及びFacetは文書に関連した入力であるから、モデル(M)はZone及びFacetを含む。Canvasと、文書を画面にレンダリングするためのデータ構造体は、ユーザが画面上に見る出力であるから、ビュー(V)はCanvas及びデータ構造体に対応する。Commandは、文書とその様々な関係に対して制御操作を実行するので、コントロール(C)はCanvasに含まれるCommandを含む。
【0167】
L.文書の表現
図20を用いて、文書及びその様々な表現の例について以下に説明する。この例で使用される文書は、テキストと画像の双方を含む。テキストは、XHTMLを用いて表され、画像は、SVGを用いて表される。図20は、文書のコンポーネント及び対応するオブジェクトの関係のMVC表現を詳細に示す。この例において、Document1001は、Document1001を保持するDocumentContainer1002にアタッチされる。文書はDOMツリー1003により表現される。DOMツリーは、ApexNode1004を含む。
【0168】
ApexNodeは、黒丸で表される。頂点でないノードは、白丸で表される。ノードを編集するために用いられるFacetは、三角形で表され、対応するノードにアタッチされる。文書がテキストと画像を有するので、この文書のDOMツリーは、XHTML部分とSVG部分を含む。ApexNode1004は、XHTMLサブツリーの最上のノードである。これは、文書のXHTML部分の物理的な表現のための最上PaneであるXHTMLPane1005にアタッチされる。ApexNode1004は、文書のDOMツリーの一部であるXHTMLZone1006にもアタッチされる。
【0169】
Node1004に対応するFacetも、XHTMLZone1006にアタッチされる。XHTMLZone1006は、XHTMLPane1005にアタッチされる。XHTMLEditletは、文書の論理的な表現であるXHTMLCanvas1007を生成する。XHTMLCanvas1007は、XHTMLPane1005にアタッチされる。XHTMLCanvas1007は、Document1001のXHTMLコンポーネントのためのBoxTree1009を生成する。文書のXHTML部分を保持し描画するために必要な様々なCommand1008も、XHTMLCanvas1007に追加される。
【0170】
同様に、文書のSVGサブツリーのApexNode1010は、文書のSVGコンポーネントを表現するDocument1001のDOMツリーの一部であるSVGZone1011にアタッチされる。ApexNode1010は、文書のSVG部分の物理的な表現の最上のPaneであるSVGPane1013にアタッチされる。文書のSVG部分の論理的な表現を表すSVGCanvas1012は、SVGEditletにより生成され、SVGPane1013にアタッチされる。画面上に文書のSVG部分をレンダリングするためのデータ構造及びコマンドは、SVGCanvasにアタッチされる。例えば、このデータ構造は、図示されるように、円、線、長方形などを含んでもよい。
【0171】
図20に関連して説明された文書例の表現の一部について、図21(a)に関連して、前述したMVCパラダイムを用いて更に説明する。図21(a)は、文書1001のXHTMLコンポーネントにおけるMVの関係を簡略化して示す。モデルは、Document1001のXHTMLコンポーネントのためのXHTMLZone1101である。XHTMLZoneのツリーには、いくつかのNode及びそれらに対応するFacetが含まれる。対応するXHTMLZone及びPaneは、MVCパラダイムのモデル(M)部分の一部である。MVCパラダイムのビュー(V)部分は、Document1001のXHTMLコンポーネントの、対応するXHTMLCanvas1102及びBoxTreeである。文書のXHTML部分は、Canvasと、それに含まれるCommandを使用して画面に描写される。キーボードやマウス入力などのイベントは、図示されるように、逆方向へ進む。
【0172】
SourcePaneは、更なる機能、すなわち、DOMの保有者としての役割を有する。図21(b)は、図21(a)に示したDocument1001のコンポーネントに対するボキャブラリコネクションを提供する。DOMホルダーとして機能するSourcePane1103は、文書のソースDOMツリーを含む。ConnectorTreeは、ConnectorFactoryにより生成され、デスティネーションDOMの保有者としても機能するDestinationPane1105を生成する。DestinationPane1105は、XHTMLDestinationCanvas1106としてボックスツリーの形式でレイアウトされる。
【0173】
M.プラグインサブシステム、ボキャブラリコネクション、及びコネクタの関係
図22(a)−(c)は、それぞれ、プラグインサブシステム、ボキャブラリコネクション、及びConnectorに関連する更なる詳細を示す。プラグインサブシステムは、文書処理システムに機能を追加又は交換するために用いられる。プラグインサブシステムは、ServiceBroker1041を含む。ServiceBroker1041にアタッチされるZoneFactoryService1201は、文書の一部に対するZoneを生成する。EditletService1202も、ServiceBroker1041にアタッチされる。EditletService1202は、Zone中のNodeに対応するCanvasを生成する。
【0174】
ZoneFactoryの例は、XHTMLZone及びSVGZoneをそれぞれ生成するXHTMLZoneFactory1211及びSVGZoneFactory1212である。文書例に関連して前述したように、文書のテキストコンポーネントは、XHTMLZoneを生成することにより表現されてもよいし、画像はSVGZoneを用いて表現されてもよい。EditletServiceの例は、XHTMLEditlet1221及びSVGEditlet1222を含む。
【0175】
図22(b)は、ボキャブラリコネクションに関連する更なる詳細を示す。ボキャブラリコネクションは、前述したように、文書処理システムの重要な特徴であり、2つの異なる方法で文書の整合のとれた表現及び表示を可能とする。ConnectorFactory303を保持するVCManager302は、ボキャブラリコネクションサブシステムの一部である。ConnectorFactory303は、文書のConnector304を生成する。前述したように、Connectorは、ソースDOM中のノードを監視し、2つの表現の間の整合性を維持するために、デスティネーションDOM中のノードを修正する。
【0176】
Template317は、いくつかのノードの変換ルールを表す。ボキャブラリコネクション記述子(VCD)ファイルは、特定のパス又はルールを満たす要素又は要素の集合を他の要素に変換するいくつかのルールを表すTemplateのリストである。Template317及びCommandTemplate318は、全てVCManager302にアタッチされる。VCManagerは、VCDファイル中の全てのセクションを管理するオブジェクトである。1つのVCDファイルに対して、1つのVCManagerオブジェクトが生成される。
【0177】
図22(c)は、Connectorに関連する更なる詳細を提供する。ConnectorFactory303は、ソース文書からConnectorを生成する。ConnectorFactory303は、Vocabulary、Template、及びElementTemplateにアタッチされ、それぞれ、VocabularyConnector、TemplateConnector、ElementConnectorを生成ずる。
【0178】
VCManager302は、ConnectorFactory303を保持する。Vocabularyを生成するために、対応するVCDファイルが読み込まれる。こうして、ConnectorFactory303が生成される。このConnectorFactory303は、Zoneを生成するZoneFactory及びCanvasを生成するEditletに関連する。
【0179】
つづいて、ターゲットボキャブラリのEditletServiceが、VCCanvasを生成する。VCCanvasも、ソースDOMツリー又はZoneにおけるApexNodeのConnectorを生成する。必要に応じて、子のConnectorが再帰的に生成される。ConnectorTreeは、VCDファイル中のテンプレートの集合により生成される。
【0180】
テンプレートは、マークアップ言語の要素を他の要素に変換するためのルールの集合である。例えば、各テンプレートは、ソースDOMツリー又はZoneにマッチされる。適切にマッチした場合には、頂点Connectorが生成される。例えば、テンプレート「A/*/D」は、間にどんなノードがあるかに関係なく、ノードAで始まりノードDで終わる全ての枝に合致する。同様に、「//B」は、ルートからの全ての「B」ノードに一致する。
【0181】
N.ConnectorTreeに関係するVCDファイルの例
特定の文書と関係する処理を説明する例を続ける。ドキュメントタイトルのある「MySampleXML」というタイトルの文書が文書処理システムにロードされる。図23は、「MySampleXML」ファイルのための、VCManager及びConnectorFactoryTreeを用いたVCDスクリプトの例を示す。スクリプトファイル中のボキャブラリセクション、テンプレートセクションと、VCManagerにおける対応するコンポーネントが示される。タグ「vcd:vocabulary」において、属性「match」は「sample:root」、「label」は「MySampleXML」、「call-template」は「sample template」となっている。
【0182】
この例では、Vocabularyは、「MySampleXML」のVCManagerにおいて「sample:root」として頂点要素を含む。対応するUIラベルは、「MySampleXML」である。テンプレートセクションにおいて、タグは「vcd:template」であり、名前は「sample:template」である。
【0183】
O.ファイルがシステムにロードされる方法の詳細な例
図24−28は、文書「MySampleXML」のロードについての詳細な記述を示す。図24(a)に示されるステップ1では、文書がストレージ1405からロードされる。DOMServiceは、DOMツリー及びDocumentManager1406と対応するDocumentContainer1401を生成する。DocumentContainer1401は、DocumentManager1406にアタッチされる。文書は、XHTML及びMySampleXMLのサブツリーを含む。XHTMLのApexNode1403は、タグ「xhtml:html」が付されたXHTMLの最上のノードである。「MySampleXML」のApexNode1404は、タグ「sample:root」が付された「MySampleXML」の最上ノードである。
【0184】
図24(b)に示されるステップ2では、RootPaneが文書のXHTMLZone、Facet、及びCanvasを生成する。Pane1407、XHTMLZone1408、XHTMLCanvas1409、及びBoxTree1410が、ApexNode1403に対応して生成される。
【0185】
図24(c)に示されるステップ3では、XHTMLZoneが知らないタグ「sample:root」を発見し、XHTMLCanvasの領域からSubPaneを生成する。
【0186】
図25に示されるステップ4では、SubPaneが「sample:root」を扱うことができ、適切なZoneを生成可能なZoneFactoryを得る。このZoneFactoryは、ZoneFactoryを実行可能なVocabulary内にある。それは、「MySampleXML」のVocabularySectionの内容を含む。
【0187】
図26に示されるステップ5では、「MySampleXML」に対応するVocabularyがDefaultZone1601を生成する。対応するEditletが生成され、対応するCanvasを生成するためにSubPane1501が提供される。Editletは、VCCanvasを生成する。そして、それはTemplateSectionを呼ぶ。ConnectorFactoryTreeも含まれている。ConnectorFactoryTreeは、ConnectorTreeとなる全てのConnectorを生成する。
【0188】
図27に示されるステップ6では、各ConnectorがデスティネーションDOMオブジェクトを生成する。コネクタのうちのいくつかはxpath情報を含んでいる。xpath情報は、変更/修正を監視する必要のあるソースDOMツリーの部分集合を決定するために使用される1以上のxpath表現を含む。
【0189】
図28に示されるステップ7では、ボキャブラリは、ソースDOMのペインからデスティネーションDOMツリーのDestinationPaneを作成する。これは、SourcePaneに基づいてなされる。デスティネーションツリーのApexNodeは、DestinationPane及び対応するZoneにアタッチされる。DestinationPaneは、DestinationCanvasを生成し、文書をデスティネーションのフォーマットでレンダリングするためのデータ構造及びコマンドを構築する、自身のEditletを提供される。
【0190】
図29(a)は、対応するソースノードを持たず、デスティネーションツリーにのみ存在するノード上でイベントが発生したときのフローを示す。マウスイベント、キーボードイベントなど、Canvasが取得したイベントは、デスティネーションツリーを通過して、ElementTemplateConnectorに伝達される。ElementTemplateConnectorは対応するソースノードを持たないので、伝達されたイベントはソースノードに対する編集操作ではない。ElementTemplateConnectorは、伝達されたイベントがCommandTemplateに記述されたコマンドに合致すれば、それに対応するActionを実行する。合致するコマンドがなければ、ElementTemplateConnectorは、伝達されたイベントを無視する。
【0191】
図29(b)は、TextOfConnectorによりソースノードに対応づけられているデスティネーションツリーのノード上でイベントが発生したときのフローを示す。TextOfConnectorは、ソースDOMツリーのXPathで指定されたノードからテキストノードを取得して、デスティネーションDOMツリーのノードにマッピングする。マウスイベント、キーボードイベントなど、Canvasが取得したイベントは、デスティネーションツリーを通過して、TextOfConnectorに伝達される。TextOfConnectorは、伝達されたイベントを、対応するソースノードの編集コマンドにマッピングし、Queue1053に積む。編集コマンドは、Facetを介して実行されるDOMのAPIコールの集合である。キューに積まれたコマンドが実行されると、ソースノードが編集される。ソースノードが編集されると、ミューテーションイベントが発行され、リスナーとして登録されたTextOfConnectorにソースノードの変更が通知される。TextOfConnectorは、ソースノードの変更を、対応するデスティネーションノードに反映させるように、デスティネーションツリーを再構築する。このとき、TextOfConnectorを含むテンプレートに、「for each」や「for loop」などの制御文が含まれている場合、ConnectorFactoryがこの制御文を再評価し、TextOfConnectorを再構築した後、デスティネーションツリーが再構築される。
【0192】
(実施例)
図30は、本実施例における帳票管理システムのハードウェア構成図である。
この帳票管理システム302においては、フォーム設定者がデザインした帳票の入力フォームに応じて、データ入力者が各種のデータを入力する。本実施例では、会社などの業務組織において、データ入力者としての社員が業務に必要な部材を発注するための帳票を題材として説明する。
【0193】
帳票管理システム302において、帳票データ管理サーバ308、帳票入力端末装置304および帳票デザイン端末装置300はLAN306を介して接続されている。
フォーム設定者は、帳票デザイン端末装置300において電子的な帳票の入力フォームをデザインする。この入力フォームの内容を定義するデータ(以下、「フォームデータ」とよぶ)は、帳票デザイン端末装置300から帳票データ管理サーバ308にアップロードされる。ここでいうフォームデータは、入力フォームのデータ構造(以下、「スキーマ」とよぶ)と、表示レイアウトが定義されたXML文書ファイルである。これは、例えば、前提技術に記載した「定義ファイル」に相当するファイルである。
【0194】
データ入力者となる社員は、帳票データ管理サーバ308に保存されているフォームデータを、帳票入力端末装置304にダウンロードする。定義された表示レイアウトにしたがって帳票入力のための入力フォームが帳票入力端末装置304に画面表示される。データ入力者は、この入力フォームを介して発注対象の部材に関連して各種データを入力する。たとえば、発注者として自己を特定するための情報や、発注部材に関する情報などである。こうして入力されたデータは、定義されたスキーマにしたがったXML文書ファイルとして保管される。ちょうど、図2に関連して説明したようなXML文書ファイル(以下、「入力データファイル」ともよぶ)が成果物として生成されることになる。
帳票入力端末装置304は、前提技術における文書処理装置20によって実現されるといえる。フォームデータである定義ファイルに基づいて、主として、VCユニット80により、データの編集が実行されることになる。
【0195】
入力データファイルは、帳票入力端末装置304から帳票データ管理サーバ308に送信される。帳票データ管理サーバ308は、帳票ごとに入力データファイルを保持する。すなわち、帳票データ管理サーバ308には、帳票ごとにデータが集積されることになる。フォーム設定者により作成された入力フォームという「型」を通して、入力データが取得され、かつ、そのスキーマにしたがって入力データが構造化されることになる。
【0196】
フォームデータに定義されたスキーマにしたがって入力データが構造化されるため、帳票データ管理サーバ308は、入力データの検索や統計などのデータ処理を容易に実行できる。これは、スキーマを定義できるXMLの利点でもある。また、データ入力者にとっても、あらかじめ設定された表示レイアウトにしたがってデータを入力すればよいため、帳票の作成作業が容易となっている。
このような帳票管理システム302の利便性を高めるためには、フォーム設定者が容易に帳票の入力フォームを作成できる必要がある。いいかえれば、フォームデータにおける表示レイアウトとスキーマの設計を容易に行うためのユーザインタフェースが必要である。
以下、フォームデータ、特に、フォームデータの編集処理に関して詳細に説明する。
【0197】
なお、フォーム設定者は帳票デザイン端末装置300にてフォームデータをローカルに作成し、作成された後のフォームデータが帳票データ管理サーバ308にアップロードされる形態として本実施例を説明する。
このほかにも、フォーム設定者は、帳票デザイン端末装置300のウェブブラウザを介して、帳票データ管理サーバ308のフォームデータ、特に、スキーマにアクセスしてもよい。すなわち、フォーム設定者は、LAN306を介して帳票データ管理サーバ308に編集コマンドを送信することにより、帳票データ管理サーバ308において一元的に管理されるフォームデータを編集するとしてもよい。
同様に、データ入力者も、帳票入力端末装置304のウェブブラウザを介して、帳票データ管理サーバ308のフォームデータにアクセスしてもよい。このときには、データ入力者はLAN306を介して入力データを送信することにより、帳票データ管理サーバ308において入力データファイルが生成されてもよい。
【0198】
図31は、帳票デザイン端末装置の機能ブロック図である。
ここに示す各ブロックは、ハードウェア的には、コンピュータのCPUをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
ここでは、主として各ブロックの発揮すべき機能について述べ、その具体的な作用については、図32以降に関連して説明する。
【0199】
帳票デザイン端末装置300は、ユーザインタフェース処理部310、通信部320、データ処理部330およびフォームデータ保持部340を含む。
ユーザインタフェース処理部310は、フォーム設定者に対するユーザインタフェース処理全般を担当する。通信部320は、フォームデータのアップロードなどに関して、帳票データ管理サーバ308との通信処理を担当する。フォームデータ保持部340は、作成されたフォームデータを保持する。データ処理部330は、フォーム設定者による操作入力に応じて、フォームデータを編集するためのデータ処理を実行する。データ処理部330は、ユーザインタフェース処理部310、通信部320およびフォームデータ保持部340を統合的に制御する。
データ処理部330の主たる機能は、前提技術で説明した定義ファイル生成部86により実現される。
【0200】
ユーザインタフェース処理部310は、画面表示部312と操作検出部314を含む。
画面表示部312は、入力フォームを編集するための設計画面を表示させる。本実施例においては、いわゆるウェブブラウザ態様にて設計画面が表示される。操作検出部314は、フォーム設定者によるマウスやキーボードなどの入力デバイスを介した編集のための操作入力を検出する。
【0201】
データ処理部330は、スキーマ設定部332、レイアウト設定部334およびプロパティ設定部336を含む。
後に図示するが、帳票の入力フォームにはデータ入力者がデータを入力するための項目が設定される。レイアウト設定部334は、入力フォームの表示レイアウトを設定する。この表示レイアウトに関する情報はフォームデータの一部として、レイアウト設定部334によりフォームデータ保持部340に格納される。この表示レイアウト情報にしたがって、帳票の入力フォームがデータ入力者に表示されることになる。
【0202】
入力フォームの各項目に入力されたデータは、所定のデータ構造にしたがって構造化される。これも後に図示するが、フォーム設定者は、この入力されたデータを仕分けするためのスキーマも設定する。スキーマ設定部332は、この入力データについてのスキーマを設定する。この設定されたスキーマに関する情報もフォームデータの一部として、スキーマ設定部332によりフォームデータ保持部340に格納される。このスキーマ情報にしたがって、データ入力者により入力されたデータが構造化されることになる。スキーマは、XMLのタグ構造に相当するといえる。
【0203】
また、各項目には、入力データのフォーマットなどについて各種のプロパティが設定される。プロパティ設定部336は、この項目についてのプロパティに関する情報もフォームデータの一部としてフォームデータ保持部340に格納する。このプロパティ情報にしたがって、各項目の入力データに関する規約が設定されることになる。
【0204】
ここで、フォームデータ作成に関する流れをまとめておく。
通信部320は、帳票データ管理サーバ308からフォームデータのテンプレートをダウンロードすると、フォームデータ保持部340に格納する。なお、帳票デザイン端末装置300は、フォームデータを最初から作成してもよい。フォーム設定者は、ユーザインタフェース処理部310を介してフォームデータの表示レイアウトやスキーマを編集するための画面表示をさせる。データ処理部330は、フォーム設定者からの入力に応じてフォームデータの内容を変更する。変更後のフォームデータは、フォームデータ保持部340に格納される。通信部320は、フォーム設定者による指示により、フォームデータ保持部340のフォームデータを帳票データ管理サーバ308にアップロードする。このようにして、作成された帳票の入力フォームがデータ入力者に提供される。
【0205】
図32は、帳票デザイン端末装置においてフォーム設定者が入力フォームを編集するための帳票フォーム設計画面を示す図である。
帳票デザイン端末装置300の画面表示部312は、帳票フォーム設計画面350に示す形態にて、入力フォームを編集するための画面を表示させる。帳票フォーム設計画面350は、レイアウト編集領域360とスキーマ編集領域400に分かれる。レイアウト編集領域360は、入力フォームの表示レイアウトを編集するための領域である。スキーマ編集領域400は、入力されたデータのスキーマ、すなわち、タグ構造を編集するための領域である。
【0206】
この帳票は、データ入力者が発注する予定の部材を記入するためのものである。図35に関連しても説明するが、レイアウト編集領域360に示される表示レイアウトにて、帳票の入力フォームが帳票入力端末装置304に表示されることになる。
【0207】
まず、レイアウト編集領域360から説明する。
社員情報欄370は、社員を特定するための情報を記入させるための欄である。
社員情報欄370は、社員ID欄372、社員名欄374、社員所属欄376および社員写真欄378の4つの入力項目を含む。
社員ID欄372は、社員IDを選択させるための項目である。社員ID欄372は、コンボボックスで形成されており、データ入力者はこのコンボボックスをプルダウンしたときに表示される社員IDの一覧から、所望の社員IDを選択する。社員名欄374は、社員の氏名を表示する項目である。社員所属欄376は、社員の所属部署を示す項目である。社員写真欄378は、社員の顔写真を示す項目である。
【0208】
発注部材情報欄380は、発注すべき部材を特定するための情報を記入させるための欄である。
発注部材情報欄380は、部材名欄382、部材説明欄384、部材単価欄386、部材発注量欄388および部材小計欄390の5つの項目を含む。
部材名欄382は、発注の対象となる部材名を記入するための項目である。部材説明欄384は、発注部材の内容に関する説明を記入させるための項目である。部材単価欄386は、部材の単価を示し、部材発注量欄388は、部材の発注量を示す。部材小計欄390は、部材単価欄386の単価と部材発注量欄388の発注量を乗算した小計値を示す。このように、部材小計欄390は、部材単価欄386と部材発注量欄388の入力データに基づいてその値が算出されるべき項目である。これは、図4に関連して説明した、生徒の平均点を算出するための編集不可能な「value-of」の項目と同様である。
【0209】
発注部材情報欄380は、発注する部材の種類に応じて行を追加することもできる。発注部材情報欄380には、そのような行の追加削除を実行するためのコマンドが割り当てられている。合計発注額欄392は、この帳票において各種部材を発注するときの合計額を示す。備考欄394は、データ入力者に発注に関する備考を記入させるための項目である。
【0210】
これらの項目の中には、データ入力者にデータを入力させるための編集可能項目や、その入力されたデータを変数として実行される計算結果を表示させるための編集不可能項目がある。いずれにせよ、これらの各項目を介して、さまざまなフォーマットのデータが取得されることになる。スキーマ編集領域400は、こうして得られたデータを構造化して管理するためのスキーマを編集するための領域である。
【0211】
スキーマ編集領域400において、「Person」とあるのは、レイアウト編集領域360の社員情報欄370に対応するXMLのタグである。社員情報欄370が4つの項目をもっていたように、「Person」も、「ID」、「Name」、「Post」および「Snapshot」の4つのタグをもっている。これらは、それぞれ、社員ID欄372、社員名欄374、社員所属欄376および社員写真欄378に対応する。
「Item」タグは、発注部材情報欄380に対応する。「Item」の下にある5つのタグ「Name」、「Description」、「ItemCost」、「Quantity」および「SubTotal」は、発注部材情報欄380の部材名欄382、部材説明欄384、部材単価欄386、部材発注量欄388および部材小計欄390にそれぞれ対応する。
また、「TotalCost」タグは合計発注額欄392、「Notice」タグは備考欄394に対応する。
【0212】
フォーム設定者は、スキーマ編集領域400にてタグを定義する。タグをレイアウト編集領域360にドラッグ&ドロップすることにより、レイアウト編集領域360に対応する項目を作ることができる。このとき、レイアウト設定部334は、タグに対応した項目のグラフィクスを、レイアウト編集領域360に設定する。また、たとえば、コンボボックスとするかテキストボックスとするかといったタグの表示形態に関しても、帳票フォーム設計画面350において設定できる。
このような表示レイアウトとスキーマの対応づけは、ちょうど、図2に示した成績データのデータ構造に含まれる構成要素を、図4に示した表形式テンプレートに割り当てる方式と同様である。帳票フォーム設計画面350において、フォーム設定者は、直接XMLのソースファイルや定義ファイルを編集しなくとも、GUI(Graphical User Interface)を介してフォームデータを作成できる。いいかえれば、GUIを介して、タグの定義、構造化および表示レイアウトを同一画面上にて作成できる。
【0213】
図33は、タグの制約条件を設定するための画面図の一例である。
この制約条件設定画面430は、「Person:Snapshot」タグについての制約条件を設定するための画面である。ここでいう制約条件としては、主なものとしては、以下の諸条件を挙げることができる。
1.入力形式条件
編集可能項目に入力されるデータのフォーマットに関する条件である。たとえば、入力されるデータが、文字列型であるか整数型であるかといったデータ入力形式についての条件が該当する。
2.入力範囲条件
編集可能項目または編集不可能項目において、入力データとして許容される範囲を指定するための条件である。
3.データ処理条件
項目の入力データを算出するために実行されるべき処理内容を示す条件である。また、他の項目における入力データを変数として実行される処理であってもよい。
4.エラー処理条件
入力データが入力フォーマット条件や入力データ範囲条件に違反したときに、実行すべき処理内容を示すための条件である。
5.入力権限条件
データを入力する権限を有するデータ入力者を特定するための条件である。
【0214】
制約条件設定画面430においては、社員写真欄378についての制約条件が設定される。入力ガイド欄432におけるデータは、カーソルが社員写真欄378に合わせられたときにツールチップ(ToolTip)として表示されるべきメッセージである。データ位置欄434は、社員写真欄378に表示されるべき社員の顔写真データの所在を示す。本実施例においては、社員IDや、名前、所属、顔写真などの社員に関するデータは、帳票データ管理サーバ308のデータベースに格納されている。ここでは、そのデータベースにおいて顔写真データが所在する位置を示している。表示名欄436は、社員写真欄378において表示されている項目名「写真」を示している。
OKボタン456がオンされると、プロパティ設定部336は設定を有効化する。キャンセルボタン458がオンされると、設定が有効化されずに帳票フォーム設計画面350に戻る。
【0215】
図34は、タグの制約条件を設定するための画面図の別例である。
この制約条件設定画面440は、「TotalCost」タグについての制約条件を設定するための画面である。
項目欄442は、制約条件を設定する対象となっているタグを示す。条件欄444は、入力範囲条件を示し、変数欄446は、その範囲を特定するための変数を示す。ここでは、「TotalCost」、すなわち、合計発注額欄392に入力される数値が30000(円)以下でなければならないという入力範囲条件が設定されている。この入力範囲条件に違反すると、メッセージ欄448に示されるメッセージが表示されることになる。ここでいうメッセージ欄448は、エラー処理条件に相当するといえる。関数欄450は、この項目の入力データを計算するための演算式を示す。ここでは、「Item:SubTotal」として示される項目の入力データ、すなわち、発注部材の小計をトータルした値を合計発注額欄392に入力されるべき値として設定している。いわば、この関数欄450は、制約条件のうちデータ処理条件を示しているといえる。
このほかにも、項目によっては、データを入力する権限が与えられるべきデータ入力者を特定するための入力権限条件を指定するための欄が設けられてもよい。
【0216】
図35は、帳票入力端末装置においてデータ入力者がデータを入力するための帳票の入力フォームを示す図である。
帳票デザイン端末装置300の通信部320は、作成されたフォームデータを帳票データ管理サーバ308にアップロードする。帳票入力端末装置304は、このフォームデータにおける表示レイアウトにしたがって、帳票入力画面460を表示させる。
【0217】
図32と比較しながら説明する。社員情報欄470は、レイアウト編集領域360の社員情報欄370に対応する。社員ID欄462、社員名欄464、社員所属欄466および社員写真欄468は、レイアウト編集領域360における社員ID欄372、社員名欄374、社員所属欄376および社員写真欄378に対応する。
データ入力者は、社員ID欄462にプルダウン表示される社員IDリストから、自分の社員IDを選択する。こうして、社員ID欄462に対応する「Person:ID」タグには、選択された社員IDが対応データとして保持されることになる。ここで社員名欄464に対応する「Person:Name」タグについては、社員IDが入力されたときには対応する社員名を表示させるというデータ処理条件が設定されている。社員IDの入力が検出されると、帳票入力端末装置304は、帳票データ管理サーバ308の社員データベースから、社員IDに対応する社員名を取得し、「Person:Name」タグの入力データとして格納する。こうして、データ入力者が社員IDを入力すると、社員名欄464に自動的に社員氏名が表示される。社員所属欄466や社員写真欄468についても同様である。すなわち、データ入力者が社員IDを入力するだけで、社員名、所属、顔写真データが自動的に入力フォームに表示される。
【0218】
発注部材情報欄480は、レイアウト編集領域360の発注部材情報欄380に対応する。部材名欄482、部材説明欄484、部材単価欄486、部材発注量欄488および部材小計欄490は、レイアウト編集領域360における部材名欄382、部材説明欄384、部材単価欄386、部材発注量欄388および部材小計欄390に対応する。
データ入力者は、部材名欄482に発注部材名を記入し、部材説明欄484に部材の説明を記入する。部材単価欄486に単価、部材発注量欄488に量を記入すると、部材小計欄490に自動的に小計が表示される。
この部材小計欄490に対応する「Item:SubTotal」タグには、部材単価欄486の単価と部材発注量欄488の量の乗算値が入力データとなるようにデータ処理条件が設定されている。帳票入力端末装置304は、部材単価欄486と部材発注量欄488の入力値を変数として、部材小計欄490に設定された演算を実行することにより、部材小計欄490における入力値を演算する。こうして、部材小計欄490に小計値が表示される。
行削除ボタン494は、発注部材情報欄480において行を削除するためのボタンであり、行追加ボタン492は、発注部材情報欄480において行を追加するためのボタンである。「Item」タグには、このような行の追加や削除のためのコマンドが追加されている。図4の定義ファイルにおいて示した「生徒の追加」や「生徒の削除」についてのコマンドと同様である。
【0219】
合計発注額欄495には、部材小計欄490における金額の合計値が表示される。これは、図34の関数欄450に関連してすでに説明したとおりである。ここで、合計発注額欄495について設定されていたエラー処理条件、すなわち、「合計金額が30000円以内」という条件に違反したので、メッセージ欄448に示されていたメッセージがアノテーション498として表示されている。備考欄496はレイアウト編集領域360おける備考欄394に対応する。
このようにして、フォーム設定者により設計されたスキーマに沿って、データ入力者から各種データが取得されることになる。
【0220】
図36は、帳票デザイン端末装置において制約条件を一覧表示させるための画面の一例である。
フォーム設定者は、帳票フォーム設計画面350において複数の項目に制約条件を設定できる。しかし、入力フォームに多くの項目が含まれるときには、どの項目にどのような制約条件を設定したかを把握することが困難になってくると考えられる。
このような課題を解決するために、帳票デザイン端末装置300は、制約条件を一覧表示させる機能を備えている。
【0221】
表示条件設定領域502は、制約条件のうち、一覧表示の対象となる条件を設定する為の領域である。同図においては、入力範囲条件とそれに関連するエラー処理条件について「入力規則に関する一覧」として一覧表示の対象とされている。操作検出部314は、フォーム設定者からのこのような指示入力を受け付けると、プロパティ設定部336は、その指示に応じた制約条件が設定されているタグをフォームデータ保持部340から検出する。画面表示部312は、入力規則一覧画面500に示すように項目と制約条件を対応づけたリストを表示する。すなわち、入力規則一覧画面500のリスト表示領域504に、そのリストが一覧表示される。
【0222】
また、入力権限条件が指定されているときには、データ入力者に応じた制約条件が表示されてもよい。たとえば、ある項目について、社員IDが「0100」〜「0200」のデータ入力者に対する制約条件と、社員ID「0201」〜「0300」のデータ入力者による制約条件が異なるときには、一つの項目についてのこれら複数種類の制約条件がリスト表示領域504に並置して表示されてもよい。たとえば、係長クラスで承認される部材発注額と課長クラスで承認される部材発注額が異なる場合が想定される。このようなときには、データ入力者に応じて制約条件が設定されてもよい。
【0223】
図37は、帳票デザイン端末装置において制約条件を一覧表示させるための画面の別例である。
ここでは、表示条件設定領域502は、帳票管理システム302においてデータが格納される位置を特定するための情報が示される。
このほかにも、入力フォーマット条件や入力権限条件など、さまざまな、観点から一覧表示させてもよい。なお、フォーム設定者は、入力規則一覧画面500やデータ規則一覧画面510においても、各タグの制約条件を設定できる。
【0224】
以上、帳票入力用のフォームを設計する例について説明したが、本実施の形態の帳票デザイン端末装置300を利用して、表形式やリスト形式のデータを効率よく処理する技術について更に説明する。
【0225】
図38は、帳票デザイン端末装置の構成の例を示す。図38に示した帳票デザイン端末装置300は、図31に示した帳票デザイン端末装置300の構成に加えて、データ入力機能付加部338を更に備える。その他の構成及び動作は、図31に示した帳票デザイン端末装置300と同様である。
【0226】
データ入力機能付加部338は、データ処理部330が生成する入力フォームの定義ファイルに、表形式データを外部から入力する機能を付加する。表形式データは、例えば、TSV(Tab Separated Values)又はCSV(Comma Separated Values)などの形式で与えられてもよいし、表計算ソフトやデータベースソフトなどのデータエクスポート機能により与えられてもよいし、表計算ソフトやデータベースソフトなどからドラッグ&ドロップ又はコピー&ペーストなどの機能を利用して与えられてもよいし、HTTPなどの通信プロトコルにより外部装置から与えられてもよい。データ入力機能付加部338により付加されるデータ入力機能は、入力フォームにより入力されるデータのうち、プロパティ設定部336において、繰り返し可能と定義されたデータに対して適用される。すなわち、このデータ入力機能は、入力フォームに対して外部から表形式のデータが与えられたとき、与えられた表形式のデータの各行を、繰り返し可能と定義された要素、又は、その要素の下位の要素のデータとして入力する。このような機能を付加することにより、入力フォームにデータを入力する際の利便性を飛躍的に向上させることができる。
【0227】
図39は、入力フォームに付加されるデータ入力部の機能ブロックを示す。データ入力部3090は、入力データ取得部3092、ヘッダ解析部3094、及びデータ設定部3096を含む。入力データ取得部3092は、表計算ソフト、データベースソフト、クリップボードなどから、表形式の入力データを取得する。ヘッダ解析部3094は、取得した入力データを解析して、どの列のデータを入力フォームのどのノードに設定するかを決定する。データ設定部3096は、ヘッダ解析部3094により決定されたノードにデータを設定する。
【0228】
ヘッダ解析部3094は、取得した表形式データの中にヘッダ行があれば、そのヘッダ行の内容を解析することにより、表形式データの列と、入力フォームのノードとの対応関係を決定する。例えば、表形式データの第1行に各列のデータの内容を記述した行があれば、その文字列と、入力フォームのノードの要素名又は属性名とを比較し、一致又は類似するものがあれば、それらを対応づける。取得した表形式データの第1行に限らず、例えば、いずれかの行にテキストデータが存在する場合は、その行をヘッダ行として解析してもよい。このとき、辞書を参照して同義語や翻訳語などを取得して、更に比較してもよい。また、帳票デザイン端末装置300のプロパティ設定部336が、入力フォームの繰り返し要素の下位にある要素や属性などに対して、表形式データのヘッダとして記述される可能性のある文字列を設定しておいてもよい。例えば、各要素や属性に対して通称名を設定し、その通称名と表形式データのヘッダ情報とを比較してもよい。ヘッダ解析部3094は、取得した表形式データをダイアログなどによりユーザに提示し、表形式データの列と、入力フォームのノードとの対応関係の指定をユーザから受け付けてもよい。このように、本実施の形態のデータ入力部3090によれば、表形式データの各列と、データを設定すべき要素又は属性などとの対応関係を自動的に又はユーザの指定により決定するので、表形式データの各列の並び順と、入力フォームのノードの並び順が一致していなくても、適切にデータを入力することができる。データを設定する要素又は属性をロケーションパスにより指定できるようにしてもよい。
【0229】
データ設定部3096は、ヘッダ解析部3094により決定された対応関係にしたがって、取得したデータを入力フォームに設定する。このとき、既に入力されたデータが存在する場合、それらを上書きしてもよいし、新たに繰り返し要素を追加してデータを挿入してもよい。
【0230】
図40は、帳票デザイン端末装置においてフォーム設定者が入力フォームを編集するための帳票フォーム設計画面を示す。画面右側のスキーマ定義領域において、「成績」ボキャブラリの構成要素が定義されている。「成績」ボキャブラリにおいて、ルート要素である「成績」要素は、下位に「生徒」要素を有しており、「生徒」要素は、下位に「国語」、「数学」、「理科」、「社会」の各要素を有している。
【0231】
図41は、「生徒」要素のプロパティを設定するためのダイアログ画面を示す。「生徒」要素のプロパティとして、「繰り返し」欄にチェックを入れ、繰り返し回数の最小数と最大数を指定すると、「生徒」要素が繰り返し要素として設定される。
【0232】
図42は、「生徒」要素の下位に含まれるデータの入力フォームのレイアウトを設定するためのダイアログ画面を示す。スキーマ定義領域に表示されている「生徒」要素をドラッグしてレイアウト領域にドロップすると、「生徒」要素の入力フォームを自動レイアウトするためのダイアログ画面が提示される。ここでは、「生徒」要素の下位に含まれるデータを表形式で入力する入力フォームを生成する。
【0233】
図43は、自動レイアウトされた「生徒」要素の入力フォームを示す。「生徒」要素の下位に含まれる「国語」、「数学」、「理科」、「社会」の各要素の要素値を入力するための表形式の入力フォームが生成されている。表の最上段には、各要素の要素名がヘッダとして表示されている。
【0234】
ここで、入力フォームの設定を終了すると、データ処理部330が入力フォームの画面を表示して、受け付けた入力データを文書として保存する機能を提供する定義データを生成する。データ入力機能付加部338は、この定義データに、表形式のデータをこの入力フォームに入力する機能を有するデータ入力部3090を付加する。
【0235】
図44は、帳票入力端末装置において入力フォームにデータを入力するための帳票フォーム入力画面を示す。画面左側のテンプレート領域において、「成績表」のテンプレートを選択すると、上記のように生成された定義データが呼び出され、成績表の入力フォーム画面が提示される。
【0236】
図45は、帳票入力端末装置により編集される文書のソースを示す。図44において、「成績表」のテンプレートを選択すると、図45に示したテンプレートが呼び出される。図44の帳票フォーム入力画面において、各セルにデータが入力されると、対応する要素の要素値としてデータが書き込まれる。
【0237】
図46は、表計算ソフトにおいて成績表のデータが入力された画面を示す。データ入力部3090は、これらのデータを帳票入力端末装置の入力フォームへコピーする機能を提供する。ユーザは、入力したいデータを選択して、コピー&ペースト、ドラッグ&ドロップなどの操作により、帳票入力端末装置の入力フォームへデータをコピーする。
【0238】
図47は、コピーしたデータを貼り付けるためのダイアログ画面を示す。マウスの右クリックにより提示されるコンテキストメニューにおいて、「タブ区切り値の貼り付け」を選択すると、クリップボードにコピーされている、タブにより区切られたデータが、繰り返し要素の下位のノードに貼り付けられる。このとき、カーソル位置が繰り返し要素の入力フォーム以外の位置にあっても、繰り返し要素に対してデータが貼り付けられる。
【0239】
図48は、タブ区切り値の貼り付け方を設定するためのダイアログ画面を示す。貼り付け方法として、既に入力されているデータを残して新たにデータを挿入するか、既に入力されているデータに上書きするかを選択することができる。また、空白データの扱い方として、データの無い状態とするか、空の文字列を入力するかを選択することができる。また、各列のデータをその順番で貼り付けるか、タブ区切り値のヘッダ行とスキーマの情報とを比較して対応づけて貼り付けるかを選択することができる。このとき、要素名と通称名のいずれを優先するかを選択することができる。
【0240】
図49は、図46に示したデータを貼り付けた画面を示す。ヘッダ解析部3094は、ヘッダ行に記入された、「名前」、「国語」、「数学」、「理科」、「社会」の各文字列と、「生徒」要素の下位の要素の要素名とを比較して、「国語」の列のデータを「国語」要素へ、「数学」の列のデータを「数学」要素へ、「理科」の列のデータを「理科」要素へ、「社会」の列のデータを「社会」要素へ、それぞれ対応づける。データ設定部3096は、ヘッダ解析部3094により対応づけられた要素のそれぞれへ各データを入力する。
【0241】
図50は、データが貼り付けられた文書のソースを示す。「生徒」要素が2つ設けられており、それぞれの「生徒」要素の下位の「国語」、「数学」、「理科」、「社会」の各要素には、貼り付けられたデータが設定されている。
【0242】
図51は、表計算ソフトにおいて成績表のデータが入力された画面の別の例を示す。図51では、「名前」、「理科」、「社会」、「数学」、「国語」の順に列が設けられている。
【0243】
図52は、図50に示したデータを貼り付けた画面を示す。ヘッダ解析部3094により、貼り付けられるデータの各列と、貼り付ける先のノードとが適切に対応づけられるので、「国語」要素には「国語」の列のデータが、「数学」要素には「数学」の列のデータが、「理科」要素には「理科」の列のデータが、「社会」要素には「社会」の列のデータが、それぞれ入力されている。
【0244】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【0245】
実施の形態では、XML文書を処理する例について説明したが、本実施の形態の文書処理装置20は、他のマークアップ言語、例えば、SGML、HTMLなどで記述された文書も同様に処理可能である。
【図面の簡単な説明】
【0246】
【図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】帳票デザイン端末装置の機能ブロック図である。
【図32】帳票デザイン端末装置においてフォーム設定者が入力フォームを編集するための帳票フォーム設計画面を示す図である。
【図33】タグの制約条件を設定するための画面図の一例である。
【図34】タグの制約条件を設定するための画面図の別例である。
【図35】帳票入力端末装置においてデータ入力者がデータを入力するための帳票入力画面を示す図である。
【図36】帳票デザイン端末装置において制約条件を一覧表示させるための画面の一例である。
【図37】帳票デザイン端末装置において制約条件を一覧表示させるための画面の別例である。
【図38】帳票デザイン端末装置の構成の例を示す図である。
【図39】入力フォームに付加されるデータ入力部の機能ブロックを示す図である。
【図40】帳票デザイン端末装置においてフォーム設定者が入力フォームを編集するための帳票フォーム設計画面を示す図である。
【図41】「生徒」要素のプロパティを設定するためのダイアログ画面を示す図である。
【図42】「生徒」要素の下位に含まれるデータの入力フォームのレイアウトを設定するためのダイアログ画面を示す図である。
【図43】自動レイアウトされた「生徒」要素の入力フォームを示す図である。
【図44】帳票入力端末装置において入力フォームにデータを入力するための帳票フォーム入力画面を示す図である。
【図45】帳票入力端末装置により編集される文書のソースを示す図である。
【図46】表計算ソフトにおいて成績表のデータが入力された画面を示す図である。
【図47】コピーしたデータを貼り付けるためのダイアログ画面を示す図である。
【図48】タブ区切り値の貼り付け方を設定するためのダイアログ画面を示す図である。
【図49】図46に示したデータを貼り付けた画面を示す図である。
【図50】データが貼り付けられた文書のソースを示す図である。
【図51】表計算ソフトにおいて成績表のデータが入力された画面の別の例を示す図である。
【図52】図50に示したデータを貼り付けた画面を示す図である。
【符号の説明】
【0247】
20 文書処理装置、22 主制御ユニット、24 編集ユニット、30 DOMユニット、32 DOM提供部、34 DOM生成部、36 出力部、40 CSSユニット、42 CSS解析部、44 CSS提供部、46 レンダリング部、50 HTMLユニット、52,62 制御部、54,64 編集部、56,66 表示部、60 SVGユニット、80 VCユニット、82 マッピング部、84 定義ファイル取得部、86 定義ファイル生成部、300 帳票デザイン端末装置、302 帳票管理システム、304 帳票入力端末装置、308 帳票データ管理サーバ、310 ユーザインタフェース処理部、312 画面表示部、314 操作検出部、320 通信部、330 データ処理部、332 スキーマ設定部、334 レイアウト設定部、336 プロパティ設定部、340 フォームデータ保持部、350 帳票フォーム設計画面、360 レイアウト編集領域、400 スキーマ編集領域、430 制約条件設定画面、440 制約条件設定画面、460 帳票入力画面、500 入力規則一覧画面、502 表示条件設定領域、504 リスト表示領域、510 データ規則一覧画面。
【技術分野】
【0001】
本発明は、データ処理技術に関し、特に、マークアップ言語により記述されたデータを処理するデータ処理装置及び方法に関する。
【背景技術】
【0002】
近年、コンピュータの普及とネットワーク技術の進展に伴い、ネットワークを介した電子情報の交換が盛んになっている。これにより、従来においては紙ベースで行われていた事務処理の多くが、ネットワークベースの処理に置き換えられつつある。
【0003】
企業においても、個人の知識や情報を組織全体で活用する、いわゆるナレッジマネジメントが、重要な経営手法となってきている。多くの企業においては、社内にデータベースシステムを有し、従業員からの情報を電子ファイル化して蓄積する。その一方で、従業員も、この社内データベースに蓄積されたファイルにネットワークを介してアクセスする。これによって、組織全体としての業務効率の向上が図られる。
【0004】
この社内データベースに蓄積されるファイルの多くは、HTML(Hyper Text Markup Language)とよばれる言語によって作成されている。また、近年においては、XML(eXtensible Markup Language)とよばれる言語を用いて、これらのファイルが作成される例も多くなってきている。
【0005】
HTMLは、ウェブページを記述するための言語である。すなわち、HTMLは文書ファイルの表示方法を定義するマークアップ言語の一種である。これに対して、XMLはHTMLの様に、直接的にウェブページを記述することを目的とする言語というよりは、むしろ、文書ファイルに含まれるデータのデータ構造を定義する機能を有する言語といえる。XMLによって作成された文書ファイルは、別に表示レイアウト情報を与えることによって、ウェブページとして表示される。すなわち、XML文書においては、データの構造とその表示レイアウトが別々のものとして扱うことができる。XMLのように、マークアップ言語を生成するための言語はメタ言語ともよばれる。
【0006】
XMLは、ネットワークなどを介して他者とデータを共有するのに適した形式として注目されており、XML文書を作成、表示、編集するためのアプリケーションが開発されている(たとえば、特許文献1参照)。XML文書は、文書型定義などにより定義されたボキャブラリ(タグセット)に基づいて作成されている。
【特許文献1】特開2001−290804号公報
【発明の開示】
【発明が解決しようとする課題】
【0007】
通常、XMLにより文書ファイルを作成するに際しては、まず、データ構造を定義し、更に、その表示レイアウトを定義する。このため、XMLによって作成された文書ファイルは、同一内容のデータであっても、複数の表示レイアウトを定義できる。
【0008】
XMLにより作成された文書ファイルの表示レイアウトは、たとえば、XSL(eXtensible Stylesheet Language)のようなスタイルシートを記述するための言語によって定義される。あるいは、XSLT(XML Stylesheet Language Transform)とよばれる言語によって、XML文書ファイルをHTML文書ファイルに変換する方法もある。
【0009】
XMLのようなメタ言語によって作成された文書ファイル(以下、このようなメタ言語によって作成された、データ構造を有する文書ファイルを、特に「構造化文書ファイル」とよぶ)は、データベースとの親和性が高いというメリットがある。なぜならば、構造化文書ファイルに含まれるデータは構造化されているため、データ検索などの処理になじみやすいからである。しかし、その一方で、一般にはXMLのようなメタ言語によって文書ファイルを作成しその表示レイアウトを定義するプロセスには多くの専門知識が必要であり、ユーザは多大な負担を強いられる。
【0010】
換言すれば、XMLのようなメタ言語は、複数のアプリケーションソフトウェアが扱うべきデータを統一したスキームで取り扱うことができるという潜在能力を有しながら、その習得の難しさが、往々にしてこの能力を発揮させる上での阻害要因となっている。
【0011】
本発明はこうした状況に鑑みてなされたものであり、その主たる目的は、構造化文書を作成する際のユーザの利便性を向上させる技術を提供することにある。
【課題を解決するための手段】
【0012】
本発明のある態様は、データ処理装置に関する。このデータ処理装置は、所定のタグセットで記述された構造化文書の要素構造を示す情報を取得する要素構造情報取得部と、前記構造化文書に含まれるデータを、編集用の別のタグセットで記述されたデータに変換することにより、前記構造化文書の編集用ユーザインタフェース画面を表示するための定義データを、前記要素構造を示す情報に基づいて生成する定義データ生成部と、前記構造化文書が繰り返し可能な要素を有する場合、外部から与えられる表形式データの少なくとも一部を、前記繰り返し可能な要素又はその要素の下位に存在するノードのノード値として入力するデータ入力機能を前記定義データに付加するデータ入力機能付加部と、を備えることを特徴とする。
【0013】
データ入力機能は、前記表形式データにヘッダ行が含まれる場合、前記ヘッダ行を解析することにより、前記表形式データの列と、前記ノードとの対応関係を決定してもよい。データ入力機能は、前記ヘッダ行に記載された前記表形式データの列の内容を示す文字列と、前記ノードの名称とを比較することにより、前記表形式データの列と、前記ノードとの対応関係を決定してもよい。
【0014】
前記定義データ生成部は、前記ノードに対して別名を設定する機能を有してもよく、前記データ入力機能は、前記ヘッダ行に記載された前記表形式データの列の内容を示す文字列と、前記ノードの別名とを比較することにより、前記表形式データの列と、前記ノードとの対応関係を決定してもよい。
【0015】
本発明の別の態様は、データ処理装置に関する。このデータ処理装置は、所定のタグセットで記述される構造化文書を処理する処理部と、前記構造化文書が繰り返し可能な要素を有する場合、外部から与えられる表形式データの少なくとも一部を、前記繰り返し可能な要素又はその要素の下位に存在するノードのノード値として入力するデータ入力部と、を備えることを特徴とする。
【0016】
本発明の更に別の態様は、データ処理方法に関する。このデータ処理方法は、所定のタグセットで記述された構造化文書の要素構造を示す情報を取得するステップと、前記構造化文書に含まれるデータを、編集用の別のタグセットで記述されたデータに変換することにより、前記構造化文書の編集用ユーザインタフェース画面を表示するための定義データを、前記要素構造を示す情報に基づいて生成するステップと、前記構造化文書が繰り返し可能な要素を有する場合、外部から与えられる表形式データの少なくとも一部を、前記繰り返し可能な要素又はその要素の下位に存在するノードのノード値として入力するデータ入力機能を前記定義データに付加するステップと、を備えることを特徴とする。
【0017】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システムなどの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【0018】
本発明によれば、構造化文書を作成する際のユーザの利便性を向上させる技術を提供することができる。
【発明を実施するための最良の形態】
【0019】
(前提技術)
図1は、前提技術に係る文書処理装置20の構成を示す。文書処理装置20は、文書内のデータが階層構造を有する複数の構成要素に分類された構造化文書を処理するが、本前提技術では構造化文書の一例としてXML文書を処理する例について説明する。文書処理装置20は、主制御ユニット22、編集ユニット24、DOMユニット30、CSSユニット40、HTMLユニット50、SVGユニット60、及び変換部の一例であるVCユニット80を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのCPU、メモリ、メモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【0020】
主制御ユニット22は、プラグインのロードや、コマンド実行のフレームワークを提供する。編集ユニット24は、XML文書を編集するためのフレームワークを提供する。文書処理装置20における文書の表示及び編集機能は、プラグインにより実現されており、文書の種別に応じて必要なプラグインが主制御ユニット22又は編集ユニット24によりロードされる。主制御ユニット22又は編集ユニット24は、処理対象となるXML文書の名前空間を参照して、XML文書がいずれのボキャブラリにより記述されているかを判別し、そのボキャブラリに対応した表示又は編集用のプラグインをロードして表示や編集を実行させる。例えば、文書処理装置20には、HTML文書の表示及び編集を行うHTMLユニット50、SVG文書の表示及び編集を行うSVGユニット60など、ボキャブラリ(タグセット)ごとに表示系及び編集系がプラグインとして実装されており、HTML文書を編集するときはHTMLユニット50が、SVG文書を編集するときはSVGユニット60が、それぞれロードされる。後述するように、HTMLとSVGの双方の構成要素を含む複合文書が処理対象となっている場合は、HTMLユニット50とSVGユニット60の双方がロードされる。
【0021】
このような構成によれば、ユーザは、必要な機能のみを選択してインストールし、後から適宜機能を追加又は削除することができるので、プログラムを格納するハードディスクなどの記録媒体の記憶領域を有効に活用することができ、また、プログラム実行時にも、メモリの浪費を防ぐことができる。また、機能拡張性に優れており、開発主体としても、プラグインの形で新たなボキャブラリに対応することが可能なので開発が容易となり、ユーザとしても、プラグインの追加により容易かつ低コストにて機能を追加することができる。
【0022】
編集ユニット24は、ユーザインターフェースを介してユーザから編集指示のイベントを受け付け、そのイベントを適切なプラグインなどに通知するともに、イベントの再実行(リドゥ)又は実行の取消(アンドゥ)などの処理を制御する。
【0023】
DOMユニット30は、DOM提供部32、DOM生成部34、及び出力部36を含み、XML文書をデータとして扱うときのアクセス方法を提供するために定められた文書オブジェクトモデル(Document Object Model:DOM)に準拠した機能を実現する。DOM提供部32は、編集ユニット24に定義されているインタフェースを満たすDOMの実装である。DOM生成部34は、XML文書からDOMツリーを生成する。後述するように、処理対象となるXML文書が、VCユニット80により他のボキャブラリにマッピングされる場合は、マッピング元のXML文書に対応するソースツリーと、マッピング先のXML文書に対応するデスティネーションツリーが生成される。出力部36は、例えば編集終了時に、DOMツリーをXML文書として出力する。
【0024】
CSSユニット40は、CSS解析部42、CSS提供部44、及びレンダリング部46を含み、CSSに準拠した表示機能を提供する。CSS解析部42は、CSSの構文を解析するパーサの機能を有する。CSS提供部44は、CSSオブジェクトの実装であり、DOMツリーに対してCSSのカスケード処理を行う。レンダリング部46は、CSSのレンダリングエンジンであり、CSSを用いてレイアウトされるHTMLなどのボキャブラリで記述された文書の表示に用いられる。
【0025】
HTMLユニット50は、HTMLにより記述された文書を表示又は編集する。SVGユニット60は、SVGにより記述された文書を表示又は編集する。これらの表示/編集系は、プラグインの形で実現されており、それぞれ、文書を表示する表示部(Canvas)56、66、編集指示を含むイベントを送受信する制御部(Editlet)52、62、編集コマンドを受けてDOMに対して編集を行う編集部(Zone)54、64を備える。制御部52又は62が外部からDOMツリーの編集コマンドを受け付けると、編集部54又は64がDOMツリーを変更し、表示部56又は66が表示を更新する。これらは、MVC(Model-View-Controller)と呼ばれるフレームワークに類似する構成をとっており、概ね、表示部56及び66が「View」に、制御部52及び62が「Controller」に、編集部54及び64とDOMの実体が「Model」に、それぞれ対応する。本前提技術の文書処理装置20では、XML文書をツリー表示形式で編集するだけでなく、それぞれのボキャブラリに応じた編集を可能とする。例えば、HTMLユニット50は、HTML文書をワードプロセッサに類似した方式で編集するためのユーザインターフェースを提供し、SVGユニット60は、SVG文書を画像描画ツールに類似した方式で編集するためのユーザインターフェースを提供する。
【0026】
VCユニット80は、マッピング部82、定義ファイル取得部84、及び定義ファイル生成部86を含み、あるボキャブラリにより記述された文書を、他のボキャブラリにマッピングすることにより、マッピング先のボキャブラリに対応した表示編集用プラグインで文書を表示又は編集するためのフレームワークを提供する。本前提技術では、この機能を、ボキャブラリコネクション(Vocabulary Connection:VC)と呼ぶ。定義ファイル取得部84は、マッピングの定義を記述したスクリプトファイルを取得する。この定義ファイルは、ノードごとに、ノード間の対応(コネクション)を記述する。このとき、各ノードの要素値や属性値の編集の可否を指定してもよい。また、ノードの要素値や属性値を用いた演算式を記述してもよい。これらの機能については、後で詳述する。マッピング部82は、定義ファイル取得部84が取得したスクリプトファイルを参照して、DOM生成部34にデスティネーションツリーを生成させ、ソースツリーとデスティネーションツリーの対応関係を管理する。定義ファイル生成部86は、ユーザが定義ファイルを生成するためのグラフィカルユーザインターフェースを提供する。
【0027】
VCユニット80は、ソースツリーとデスティネーションツリーの間のコネクションを監視し、表示を担当するプラグインにより提供されるユーザインタフェースを介してユーザから編集指示を受け付けると、まずソースツリーの該当するノードを変更する。DOMユニット30が、ソースツリーが変更された旨のミューテーションイベントを発行すると、VCユニット80は、そのミューテーションイベントを受けて、ソースツリーの変更にデスティネーションツリーを同期させるべく、変更されたノードに対応するデスティネーションツリーのノードを変更する。デスティネーションツリーを表示/編集するプラグイン、例えばHTMLユニット50は、デスティネーションツリーが変更された旨のミューテーションイベントを受けて、変更されたデスティネーションツリーを参照して表示を更新する。このような構成により、少数のユーザにより利用されるローカルなボキャブラリにより記述された文書であっても、他のメジャーなボキャブラリに変換することで、文書を表示することができるとともに、編集環境が提供される。
【0028】
文書処理装置20により文書を表示又は編集する動作について説明する。文書処理装置20が処理対象となる文書を読み込むと、DOM生成部34が、そのXML文書からDOMツリーを生成する。また、主制御ユニット22又は編集ユニット24は、名前空間を参照して文書を記述しているボキャブラリを判別する。そのボキャブラリに対応したプラグインが文書処理装置20にインストールされている場合は、そのプラグインをロードして、文書を表示/編集させる。プラグインがインストールされていない場合は、マッピングの定義ファイルが存在するか否かを確認する。定義ファイルが存在する場合、定義ファイル取得部84が定義ファイルを取得し、その定義に従って、デスティネーションツリーが生成され、マッピング先のボキャブラリに対応するプラグインにより文書が表示/編集される。複数のボキャブラリを含む複合文書である場合は、後述するように、それぞれのボキャブラリに対応したプラグインにより、文書の該当箇所がそれぞれ表示/編集される。定義ファイルが存在しない場合は、文書のソース又はツリー構造を表示し、その表示画面において編集が行われる。
【0029】
図2は、処理対象となるXML文書の例を示す。このXML文書は、生徒の成績データを管理するために用いられる。XML文書のトップノードである構成要素「成績」は、配下に、生徒ごとに設けられた構成要素「生徒」を複数有する。構成要素「生徒」は、属性値「名前」と、子要素「国語」、「数学」、「理科」、「社会」を有する。属性値「名前」は、生徒の名前を格納する。構成要素「国語」、「数学」、「理科」、「社会」は、それぞれ、国語、数学、理科、社会の成績を格納する。例えば、名前が「A」である生徒の国語の成績は「90」、数学の成績は「50」、理科の成績は「75」、社会の成績は「60」である。以下、この文書で使用されているボキャブラリ(タグセット)を、「成績管理ボキャブラリ」と呼ぶ。
【0030】
本前提技術の文書処理装置20は、成績管理ボキャブラリの表示/編集に対応したプラグインを有しないので、この文書をソース表示、ツリー表示以外の方法で表示するためには、前述したVC機能が用いられる。すなわち、成績管理ボキャブラリを、プラグインが用意された別のボキャブラリ、例えば、HTMLやSVGなどにマッピングするための定義ファイルを用意する必要がある。ユーザ自身が定義ファイルを作成するためのユーザインターフェースについては後述することにして、ここでは、既に定義ファイルが用意されているとして説明を進める。
【0031】
図3は、図2に示したXML文書をHTMLで記述された表にマッピングする例を示す。図3の例では、成績管理ボキャブラリの「生徒」ノードを、HTMLにおける表(「TABLE」ノード)の行(「TR」ノード)に対応づけ、各行の第1列には属性値「名前」を、第2列には「国語」ノードの要素値を、第3列には「数学」ノードの要素値を、第4列には「理科」ノードの要素値を、第5列には「社会」ノードの要素値を、それぞれ対応付ける。これにより、図2に示したXML文書を、HTMLの表形式で表示することができる。また、これらの属性値及び要素値は、編集可能であることが指定されており、ユーザがHTMLによる表示画面上で、HTMLユニット50の編集機能により、これらの値を編集することができる。第6列には、国語、数学、理科、社会の成績の加重平均を算出する演算式が指定されており、生徒の成績の平均点が表示される。このように、定義ファイルに演算式を指定可能とすることにより、より柔軟な表示が可能となり、編集時のユーザの利便性を向上させることができる。なお、第6列は、編集不可であることが指定されており、平均点のみを個別に編集することができないようにしている。このように、マッピング定義において、編集の可否を指定可能とすることにより、ユーザの誤操作を防ぐことができる。
【0032】
図4(a)及び図4(b)は、図2に示したXML文書を図3に示した表にマッピングするための定義ファイルの例を示す。この定義ファイルは、定義ファイル用に定義されたスクリプト言語により記述される。定義ファイルには、コマンドの定義と、表示のテンプレートが記述されている。図4(a)(b)の例では、コマンドとして、「生徒の追加」と「生徒の削除」が定義されており、それぞれ、ソースツリーにノード「生徒」を挿入する操作と、ソースツリーからノード「生徒」を削除する操作が対応付けられている。また、テンプレートとして、表の第1行に「名前」、「国語」などの見出しが表示され、第2行以降に、ノード「生徒」の内容が表示されることが記述されている。ノード「生徒」の内容を表示するテンプレート中、「text-of」と記述された項は「編集可能」であることを意味し、「value-of」と記述された項は「編集不可能」であることを意味する。また、ノード「生徒」の内容を表示する行のうち、第6列には、「(src:国語 + src:数学 + src:理科 + src:社会) div 4」という計算式が記述されており、生徒の成績の平均が表示されることを意味する。
【0033】
図5は、図2に示した成績管理ボキャブラリで記述されたXML文書を、図3に示した対応によりHTMLにマッピングして表示した画面の例を示す。表90の各行には、左から、各生徒の名前、国語の成績、数学の成績、理科の成績、社会の成績、及び平均点が表示されている。ユーザは、この画面上で、XML文書を編集することができる。たとえば、第2行第3列の値を「70」に変更すると、このノードに対応するソースツリーの要素値、すなわち、生徒「B」の数学の成績が「70」に変更される。このとき、VCユニット80は、デスティネーションツリーをソースツリーに追従させるべく、デスティネーションツリーの該当箇所を変更し、HTMLユニット50が、変更されたデスティネーションツリーに基づいて表示を更新する。したがって、画面上の表においても、生徒「B」の数学の成績が「70」に変更され、更に、平均点が「55」に変更される。
【0034】
図5に示した画面には、図4(a)(b)に示した定義ファイルに定義されたように、「生徒の追加」及び「生徒の削除」のコマンドがメニューに表示される。ユーザがこれらのコマンドを選択すると、ソースツリーにおいて、ノード「生徒」が追加又は削除される。このように、本前提技術の文書処理装置20では、階層構造の末端の構成要素の要素値を編集するのみではなく、階層構造を編集することも可能である。このようなツリー構造の編集機能は、コマンドの形でユーザに提供されてもよい。また、例えば、表の行を追加又は削除するコマンドが、ノード「生徒」を追加又は削除する操作に対応づけられてもよい。また、他のボキャブラリを埋め込むコマンドがユーザに提供されてもよい。この表を入力用テンプレートとして、穴埋め形式で新たな生徒の成績データを追加することもできる。以上のように、VC機能により、HTMLユニット50の表示/編集機能を利用しつつ、成績管理ボキャブラリで記述された文書を編集することが可能となる。
【0035】
図6は、ユーザが定義ファイルを生成するために、定義ファイル生成部86がユーザに提示するグラフィカルユーザインタフェースの例を示す。画面左側の領域91には、マッピング元のXML文書がツリー表示されている。画面右側の領域92には、マッピング先のXML文書の画面レイアウトが示されている。この画面レイアウトは、HTMLユニット50により編集可能となっており、ユーザは、画面右側の領域92において、文書を表示するための画面レイアウトを作成する。そして、例えば、マウスなどのポインティングデバイスにより、画面左側の領域91に表示されたマッピング元のXML文書のノードを、画面右側の領域92に表示されたHTMLによる画面レイアウト中へドラッグ&ドロップ操作を行うことにより、マッピング元のノードと、マッピング先のノードとのコネクションが指定される。例えば、要素「生徒」の子要素である「数学」を、HTML画面の表90の第1行第3列にドロップすると、「数学」ノードと、3列目の「TD」ノードの間にコネクションが張られる。各ノードには、編集の可否が指定できるようになっている。また、表示画面中には、演算式を埋め込むこともできる。画面の編集が終わると、定義ファイル生成部86は、画面レイアウトとノード間のコネクションを記述した定義ファイルを生成する。
【0036】
XHTML、MathML、SVGなどの主要なボキャブラリに対応したビューワやエディタは既に開発されているが、図2に示した文書のようなオリジナルなボキャブラリで記述された文書に対応したビューワやエディタを開発するのは現実的でない。しかし、上記のように、他のボキャブラリにマッピングするための定義ファイルを作成すれば、ビューワやエディタを開発しなくても、VC機能を利用して、オリジナルなボキャブラリで記述された文書を表示・編集することができる。
【0037】
図7は、定義ファイル生成部86により生成された画面レイアウトの他の例を示す。図7の例では、成績管理ボキャブラリで記述されたXML文書を表示するための画面に、表90と、円グラフ93が作成されている。この円グラフ93は、SVGにより記述される。後述するように、本前提技術の文書処理装置20は、一つのXML文書内に複数のボキャブラリを含む複合文書を処理することができるので、この例のように、HTMLで記述された表90と、SVGで記述された円グラフ93とを、一つの画面上に表示することができる。
【0038】
図8は、文書処理装置20によるXML文書の編集画面の一例を示す。図8の例では、一つの画面が複数に分割されており、それぞれの領域において、処理対象となるXML文書を異なる複数の表示形式により表示している。領域94には、文書のソースが表示されており、領域95には、文書のツリー構造が表示されており、領域96には、図5に示したHTMLにより記述された表が表示されている。これらのいずれの画面上においても、文書の編集が可能であり、いずれかの画面上でユーザが編集を行うと、ソースツリーが変更され、それぞれの画面の表示を担当するプラグインが、ソースツリーの変更を反映すべく画面を更新する。具体的には、ソースツリーの変更を通知するミューテーションイベントのリスナーとして、それぞれの編集画面の表示を担当するプラグインの表示部を登録しておき、いずれかのプラグイン又はVCユニット80によりソースツリーが変更されたときに、編集画面を表示中の全ての表示部が、発行されたミューテーションイベントを受け取って画面を更新する。このとき、プラグインがVC機能により表示を行っている場合は、VCユニット80がソースツリーの変更に追従してデスティネーションツリーを変更した後、変更されたデスティネーションツリーを参照してプラグインの表示部が画面を更新する。
【0039】
例えば、ソース表示及びツリー表示を、専用のプラグインにより実現している場合は、ソース表示用プラグインとツリー表示用プラグインは、デスティネーションツリーを用いず、直接ソースツリーを参照して表示を行う。この場合、いずれかの画面において編集が行われると、ソース表示用プラグインとツリー表示用プラグインは、変更されたソースツリーを参照して画面を更新し、領域96の画面を担当しているHTMLユニット50は、ソースツリーの変更に追従して変更されたデスティネーションツリーを参照して画面を更新する。
【0040】
ソース表示及びツリー表示は、VC機能を利用して実現することもできる。すなわち、ソース、ツリー構造をHTMLによりレイアウトし、そのHTMLにXML文書をマッピングして、HTMLユニット50により表示してもよい。この場合、ソース形式、ツリー形式、表形式の3つのデスティネーションツリーが生成されることになる。いずれかの画面において編集が行われると、VCユニット80は、ソースツリーを変更した後、ソース形式、ツリー形式、表形式の3つのデスティネーションツリーをそれぞれ変更し、HTMLユニット50は、それらのデスティネーションツリーを参照して、3つの画面を更新する。
【0041】
このように、一つの画面上に複数の表示形式で文書を表示することにより、ユーザの利便性を向上させることができる。例えば、ユーザは、ソース表示又はツリー表示により文書の階層構造を把握しつつ、表90などを用いて視覚的に分かりやすい形式で文書を表示し、編集することができる。上記の例では、一つの画面を分割して複数の表示形式による画面を同時に表示したが、一つの画面に一つの表示形式による画面を表示し、表示形式をユーザの指示により切り替え可能としてもよい。この場合、主制御ユニット22が、ユーザから表示形式の切り替え要求を受け付け、各プラグインに指示して表示を切り替える。
【0042】
図9は、文書処理装置20により編集されるXML文書の他の例を示す。図9に示したXML文書では、SVG文書の「foreignObject」タグの中にXHTML文書が埋め込まれており、さらに、XHTML文書の中にMathMLで記述された数式が入っている。このような場合、編集ユニット24が、名前空間を参照して、適切な表示系に描画作業を振り分ける。図9の例では、編集ユニット24は、まず、SVGユニット60に四角形を描画させ、つづいて、HTMLユニット50にXHTML文書を描画させる。さらに、図示しないMathMLユニットに、数式を描画させる。こうして、複数のボキャブラリを包含する複合文書が適切に表示される。表示結果を図10に示す。
【0043】
文書編集中、カーソル(キャリッジ)の位置に応じて、表示されるメニューを切り替えてもよい。すなわち、カーソルが、SVG文書が表示された領域内に存在するときは、SVGユニット60が提供するメニュー、又はSVG文書をマッピングするための定義ファイルに定義されたコマンドを表示し、カーソルが、XHTML文書が表示された領域内に存在するときは、HTMLユニット50が提供するメニュー、又はXHTML文書をマッピングするための定義ファイルに定義されたコマンドを表示する。これにより、編集位置に応じて適切なユーザインターフェースを提供することができる。
【0044】
複合文書において、あるボキャブラリに対応する適切なプラグイン又はマッピング定義ファイルがなかった場合は、そのボキャブラリにより記述された部分は、ソース表示又はツリー表示されてもよい。従来、ある文書に他の文書を埋め込んだ複合文書を開くとき、埋め込まれた文書を表示するアプリケーションがインストールされていないと、その内容を表示することができなかったが、本前提技術では、表示用のアプリケーションが存在しなくても、テキストデータにより構成されたXML文書をソース表示又はツリー表示することにより内容を把握することができる。これは、テキストベースであるXMLなどの文書ならではの特徴といえる。
【0045】
データがテキストベースで記述されることの他の利点として、例えば、複合文書中の、あるボキャブラリにより記述される部分において、同一文書内の他のボキャブラリで記述された部分のデータを参照してもよい。また、文書内で検索を実行する時に、SVGなどの図に埋め込まれた文字列も検索対象とすることができる。
【0046】
あるボキャブラリにより記述された文書内に、他のボキャブラリのタグを用いてもよい。このXML文書は、妥当(valid)ではないが、整形式(well-formed)であれば、有効なXML文書として処理可能である。この場合、挿入された他のボキャブラリのタグは、定義ファイルによりマッピングされてもよい。例えば、XHTML文書中に、「重要」、「最重要」などのタグを使用し、これらのタグで囲まれた部分を強調表示してもよいし、重要度の順にソートして表示してもよい。
【0047】
図10に示した編集画面において、ユーザにより文書が編集されると、編集された部分を担当するプラグイン又はVCユニット80がソースツリーを変更する。ソースツリーには、ノードごとにミューテーションイベントのリスナーを登録できるようになっており、通常は、各ノードが属するボキャブラリに対応したプラグインの表示部又はVCユニット80がリスナーとして登録される。DOM提供部32は、ソースツリーが変更されると、変更されたノードから上位の階層へたどって、登録されたリスナーがあれば、そのリスナーへミューテーションイベントを発行する。例えば、図9に示した文書において、<html>ノードの下位のノードが変更された場合、<html>ノードにリスナーとして登録されたHTMLユニット50にミューテーションイベントが通知されるとともに、その上位の<svg>ノードにリスナーとして登録されたSVGユニット60にもミューテーションイベントが通知される。このとき、HTMLユニット50は、変更されたソースツリーを参照して表示を更新する。SVGユニット60は、自身のボキャブラリに属するノードが変更されていないので、ミューテーションイベントを無視してもよい。
【0048】
編集の内容によっては、HTMLユニット50による表示の更新に伴って、全体のレイアウトが変わる可能性がある。この場合は、画面のレイアウトを管理する構成、例えば最上位のノードの表示を担当するプラグインにより、プラグインごとの表示領域のレイアウトが更新される。例えば、HTMLユニット50による表示領域が以前より大きくなった場合、HTMLユニット50は、まず自身の担当する部分を描画して、表示領域の大きさを決定する。そして、画面のレイアウトを管理する構成に、変更後の表示領域の大きさを通知し、レイアウトの更新を依頼する。画面のレイアウトを管理する構成は、通知を受けて、プラグインごとの表示領域を再レイアウトする。こうして、編集された部分の表示が適切に更新されるとともに、画面全体のレイアウトが更新される。
【0049】
つづいて、前提技術の文書処理装置20を実現する機能構成について更に詳細に説明する。以下の説明では、クラス名などを記載する際には、英字をそのまま用いて記載することにする。
【0050】
A.概要
インターネットの出現により、ユーザによって処理され管理される文書の数が、ほぼ指数関数的に増加してきた。インターネットの核を形成するウェブ(World Wide Web)は、そのような文書データの大きな受け皿となっている。ウェブは、文書に加えて、このような文書の情報検索システムを提供する。これらの文書は、通常、マークアップ言語により記述される。マークアップ言語のシンプルかつポピュラーな例の一つにHTML(HyperText Markup Language)がある。このような文書は、ウェブの他の位置に格納されている他の文書へのリンクをさらに含む。XML(eXtensible Markup Language)は、さらに高度でポピュラーなマークアップ言語である。ウェブ文書にアクセスし、閲覧するためのシンプルなブラウザが、Java(登録商標)のようなオブジェクト指向のプログラミング言語で開発されている。
【0051】
マークアップ言語により記述された文書は、通常、ブラウザや他のアプリケーションの中では、ツリーデータ構造の形で表現される。この構造は、文書を構文解析した結果のツリーに相当する。DOM(Document Object Model)は、文書を表現し、操作するために使用される、よく知られたツリーベースのデータ構造モデルである。DOMは、HTMLやXML文書などを含む文書を表現するための標準的なオブジェクトのセットを提供する。DOMは、文書内のコンポーネントを表現するオブジェクトがどのようにつながっているかという標準モデルと、それらのオブジェクトにアクセスしたり操作したりするための標準インタフェイスという、2つの基本的なコンポーネントを含む。
【0052】
アプリケーション開発者は、独自のデータ構造やAPI(Application Program Interface)へのインタフェイスとしてDOMをサポートすることができる。他方、文書を作成するアプリケーション開発者は、彼らのAPIの独自インタフェイスではなく、DOMの標準インタフェイスを使用することができる。したがって、標準を提供するというその能力により、DOMは、様々な環境、特にウェブにおいて、文書の相互利用を促進させるために有効である。DOMのいくつかのバージョンが定義されており、異なるプログラミング環境及びアプリケーションによって使用されている。
【0053】
DOMツリーは、対応するDOMの内容に基づいた文書の階層的表現である。DOMツリーは「根(ルート)」、及びルートから発生する1つ以上の「節(ノード)」を含む。ルートが文書全体を表す場合もある。中間のノードは、例えば、テーブル及びそのテーブル中の行及び列のような要素を表すことができる。DOMツリーの「葉」は、通常、それ以上分解できないテキストや画像のようなデータを表す。DOMツリーの各ノードは、フォント、サイズ、色、インデントなど、ノードによって表される要素のパラメータを記述する属性に関連付けられてもよい。
【0054】
HTMLは、文書を作成するために一般に用いられる言語であるが、フォーマット及びレイアウト用の言語であり、データ記述のための言語ではない。HTMLドキュメントを表現するDOMツリーのノードは、HTMLのフォーマッティングタグとして予め定義されたエレメントであって、通常、HTMLは、データの詳述や、データのタギング/ラベリングのための機能を提供しないので、HTMLドキュメント中のデータに対するクエリを定式化することは多くの場合困難である。
【0055】
ネットワーク設計者たちの目指すものは、ウェブ上の文書がソフトウェアアプリケーションによってクエリされたり処理されたりできるようにすることである。表示方法とは無関係で、階層的に構造化された言語であれば、そのようにクエリされ処理されることができる。XML(eXtensible Markup Language)のようなマークアップ言語は、これらの特徴を提供することができる。
【0056】
HTMLとは逆に、XMLのよく知られた利点は、文書の設計者が自由に定義可能な「タグ」を使用して、データ要素にラベルを付けることが可能である点である。このようなデータ要素は、階層的に構造化することができる。さらに、XML文書は、文書内で用いられるタグ及びそれらの相互関係の「文法」を記述した文書型定義を含むことができる。構造化されたXML文書の表示方法を定義するために、CSS(Cascading Style Sheet)又はXSL(XML Style Language)が使用される。DOM、HTML、XML、CSS、XSL及び関連する言語の特徴に関する付加的な情報は、ウェブからも得ることができる。(例えば、http://www.w3.org/TR/)
【0057】
Xpathは、XML文書の部分の位置を指定するために共通のシンタックス及びセマンティクスを提供する。機能性の例として、XML文書に対応するDOMツリーのトラバース(移動)がある。それは、XML文書の様々な表現に関連した文字列、数、及びブーリアン文字の操作のための基本的な機能を提供する。Xpathは、XML文書の見た目のシンタックス、例えば、テキストとしてみたときに何行目であるとか何文字目であるとかといった文法ではなく、DOMツリーなどの抽象的・論理的な構造において動作する。Xpathを使用することにより、例えばXML文書のDOMツリー内の階層的構造を通じて場所を指定することができる。アドレシングのための使用の他に、Xpathは、DOMツリー中のノードがパターンにマッチするか否かをテストするために使用されるようにも設計されている。XPathに関する更なる詳細は、http://www.w3.org/TR/xpathで得ることができる。
【0058】
XMLの既知の利点及び特徴により、マークアップ言語(例えばXML)で記述された文書を扱うことができ、文書を作成及び修正するためのユーザフレンドリーなインタフェイスを提供することができる、効果的な文書処理システムが求められる。
【0059】
ここで説明されるシステムの構成のうちのいくつかは、MVC(Model-View-Controller)と呼ばれる、よく知られたGUI(Graphical User Interface)パラダイムを用いて説明される。MVCパラダイムは、アプリケーション又はアプリケーションのインタフェイスの一部を、3つの部分、すなわち、モデル、ビュー、コントローラに分割する。MVCは、元は、GUIの世界に、従来の入力、処理、出力の役割を割り当てるために開発された。
[入力] → [処理] → [出力]
[コントローラ]→ [モデル] → [ビュー]
【0060】
MVCパラダイムによれば、外界のモデリング、ユーザへの視覚的なフィードバック、及びユーザの入力は、モデル(M)、ビュー(V)、及びコントローラ(C)オブジェクトにより分離されて扱われる。コントローラは、ユーザからのマウスとキーボード入力のような入力を解釈し、これらのユーザアクションを、適切な変更をもたらすためにモデル及び/又はビューに送られるコマンドにマップするように作用する。モデルは、1以上のデータ要素を管理するように作用し、その状態に関するクエリに応答し、状態を変更する指示に応答する。ビューは、ディスプレイの長方形の領域を管理するように作用し、グラフィクスとテキストの組合せによりユーザにデータを提示する機能を有する。
【0061】
B.文書処理システムの全体構成
文書処理システムの実施例は、図11−29に関連して明らかにされる。
【0062】
図11(a)は、後述するタイプの文書処理システムの基礎として機能する要素の従来の構成例を示す。構成10は、通信経路13によりメモリ12に接続されたCPU又はマイクロプロセッサ11などの形式のプロセッサを含む。メモリ12は、現在又は将来に利用可能な任意のROM及び/又はRAMの形式であってもよい。通信経路13は、典型的にはバスとして設けられる。マウス、キーボード、音声認識システムなどのユーザ入力装置14及び表示装置15(又は他のユーザインタフェイス)に対する入出力インタフェイス16も、プロセッサ11とメモリ12の通信のためのバスに接続される。この構成は、スタンドアロンであってもよいし、複数の端末及び1以上のサーバが接続されてネットワーク化された形式であってもよいし、既知のいかなる方式により構成されてもよい。本発明は、これらのコンポーネントの配置、集中又は分散されたアーキテクチャー、あるいは様々なコンポーネントの通信方法により制限されない。
【0063】
さらに、本システム及びここで議論される実施例は、様々な機能性を提供するいくつかのコンポーネント及びサブコンポーネントを含むものとして議論される。これらのコンポーネント及びサブコンポーネントは、注目された機能性を提供するために、ハードウェアとソフトウェアの組合せだけでなく、ハードウェアのみ、ソフトウェアのみによっても実現されうる。さらに、ハードウェア、ソフトウェア、及びそれらの組合せは、汎用の計算装置、専用のハードウェア、又はそれらの組合せにより実現されうる。したがって、コンポーネント又はサブコンポーネントの構成は、コンポーネント又はサブコンポーネントの機能性を提供するための特定のソフトウェアを実行する汎用/専用の計算装置を含む。
【0064】
図11(b)は、文書処理システムの一例の全体のブロック図を示す。このような文書処理システムにおいて文書が生成され編集される。これらの文書は、例えばXMLなど、マークアップ言語の特徴を有する任意の言語により記述されてもよい。また、便宜上、特定のコンポーネント及びサブコンポーネントの用語及び表題を創造した。しかしながら、これらは、この開示の一般的な教示の範囲を制限するために解釈されるべきではない。
【0065】
文書処理システムは、2つの基本的な構成を有するものととらえることができる。第1の構成は、文書処理システムが動作する環境である「実行環境」101である。例えば、実行環境は、文書の処理中及び管理中に、ユーザだけでなくシステムも支援する、基本的なユーティリティ及び機能を提供する。第2の構成は、実行環境において走るアプリケーションから構成される「アプリケーション」102である。これらのアプリケーションは、文書自身及び文書の様々な表現を含む。
【0066】
1.実行環境
実行環境101のキーとなるコンポーネントはProgramInvoker(プログラムインボーカ:プログラム起動部)103である。ProgramInvoker103は、文書処理システムを起動するためにアクセスされる基本的なプログラムである。例えば、ユーザが文書処理システムにログオンして開始するとき、ProgramInvoker103が実行される。ProgramInvoker103は、例えば、文書処理システムにプラグインとして加えられた機能を読み出して実行させたり、アプリケーションを開始して実行させたり、文書に関連するプロパティを読み出すことができる。ProgramInvoker103の機能はこれらに限定されない。ユーザが実行環境内で実行されるように意図されたアプリケーションを起動したいとき、ProgramInvoker103は、そのアプリケーションを見つけ、それを起動して、アプリケーションを実行する。
【0067】
ProgramInvoker103には、プラグインサブシステム104、コマンドサブシステム105、及びResource(リソース)モジュール109などのいくつかのコンポーネントがアタッチされている。これらの構成については、以下に詳述する。
【0068】
a)プラグインサブシステム
プラグインサブシステム104は、文書処理システムに機能を追加するための高度に柔軟で効率的な構成として使用される。プラグインサブシステム104は、また、文書処理システムに存在する機能を修正又は削除するために使用することができる。さらに、種々様々の機能をプラグインサブシステムを使用して追加又は修正することができる。例えば、画面上への文書の描画を支援するように作用するEditlet(エディットレット:編集部)機能を追加することもできる。Editletプラグインは、システムに追加されるボキャブラリの編集も支援する。
【0069】
プラグインサブシステム104は、ServiceBroker(サービスブローカ:サービス仲介部)1041を含む。ServiceBroker1041は、文書処理システムに加えられるプラグインを管理することにより、文書処理システムに加えられるサービスを仲介する。
【0070】
所望の機能性を実現する個々の機能は、Service(サービス)1042の形でシステムに追加される。利用可能なService1042のタイプは、Application(アプリケーション)サービス、ZoneFactory(ゾーンファクトリ:ゾーン生成部)Service、Editlet(エディットレット:編集部)Service、CommandFactory(コマンドファクトリ:コマンド生成部)Service、ConnectXPath(コネクトXPath:XPath管理部)Service、CSSComputation(CSSコンピューテーション:CSS計算部)Serviceなどを含むが、これらに限定されない。これらのService、及びシステムの他の構成とそれらとの関係は、文書処理システムについてのよりよい理解のために、以下に詳述される。
【0071】
プラグインとServiceの関係は以下の通りである。プラグインは、1以上のServiceProvider(サービスプロバイダ:サービス提供部)を含むことができるユニットである。それぞれのServiceProviderは、それに関連したServiceの1以上のクラスを有する。例えば、適切なソフトウェアアプリケーションを有する単一のプラグインを使用することにより、1以上のServiceをシステムに追加することができ、これにより、対応する機能をシステムに追加することができる。
【0072】
b)コマンドサブシステム
コマンドサブシステム105は、文書の処理に関連したコマンドの形式の命令を実行するために使用される。ユーザは、一連の命令を実行することにより、文書に対する操作を実行することができる。例えば、ユーザは、コマンドの形で命令を発行することにより、文書処理システム中のXML文書に対応するXMLのDOMツリーを編集し、XML文書を処理する。これらのコマンドは、キーストローク、マウスクリック、又は他の有効なユーザインタフェイスアクションを使用して入力されてもよい。1つのコマンドにより1以上の命令が実行されることもある。この場合、これらの命令が1つのコマンドにラップ(包含)され、連続して実行される。例えば、ユーザが、誤った単語を正しい単語に置換したいとする。この場合、第1の命令は、文書中の誤った単語を発見することであり、第2の命令は、誤った単語を削除することであり、第3の命令は、正しい単語を挿入することであってもよい。これらの3つの命令が1つのコマンドにラップされてもよい。
【0073】
コマンドは、関連した機能、例えば、後で詳述する「アンドゥ」機能を有してもよい。これらの機能は、オブジェクトを生成するために使用されるいくつかの基本クラスにも割り当てられてもよい。
【0074】
コマンドサブシステム105のキーとなるコンポーネントは、選択的にコマンドを与え、実行するように作用するCommandInvoker(コマンドインボーカ:コマンド起動部)1051である。図11(b)には、1つのCommandInvokerのみが示されているが、1以上のCommandInvokerが使用されてもよく、1以上のコマンドが同時に実行されてもよい。CommandInvoker1051は、コマンドを実行するために必要な機能及びクラスを保持する。動作において、実行されるべきCommand(コマンド:命令)1052は、Queue(キュー)1053に積まれる。CommandInvokerは、連続的に実行するコマンドスレッドを生成する。CommandInvoker内で既に実行中のCommandがなければ、CommandInvoker1051により実行されるように意図されたCommand1052が実行される。CommandInvokerが既にコマンドを実行している場合、新しいCommandは、Queue1053の最後に積まれる。しかしながら、それぞれのCommandInvoker1051では、一度に1つのCommandのみが実行される。指定されたCommandの実行に失敗した場合、CommandInvoker1051は例外処理を実行する。
【0075】
CommandInvoker1051により実行されるCommandの型は、UndoableCommand(取消可能コマンド)1054、AsynchronousCommand(非同期コマンド)1055、及びVCCommand(VCコマンド)1056を含むが、これらに限定されない。UndoableCommand1054は、ユーザが望めば、そのCommandの結果を取り消すことが可能なCommandである。UndoableCommandの例として、切り取り、コピー、テキストの挿入、などがある。動作において、ユーザが文書の一部を選択し、その部分に切り取りコマンドを適用するとき、UndoableCommandを用いることにより、切り取られた部分は、必要であれば、「切り取られていない」ようにすることができる。
【0076】
VCCommand1056は、ボキャブラリコネクション記述子(Vocabulary Connection Descriptor:VCD)スクリプトファイルに格納される。これらは、プログラマにより定義されうるユーザ指定のCommandである。Commandは、例えば、XMLフラグメントを追加したり、XMLフラグメントを削除したり、属性を設定したりするための、より抽象的なCommandの組合せであってもよい。これらのCommandは、特に、文書の編集に焦点を合わせている。
【0077】
AsynchronousCommand1055は、文書のロードや保存など、システムよりのCommandであり、UndoableCommandやVCCommandとは別に、非同期的に実行される。AsynchronousCommandは、UndoableCommandではないので、取り消すことはできない。
【0078】
c)リソース
Resource109は、様々なクラスに、いくつかの機能を提供するオブジェクトである。例えば、ストリングリソース、アイコン、及びデフォルトキーバインドは、システムで使用されるResourceの例である。
【0079】
2.アプリケーションコンポーネント
文書処理システムの第2の主要な特徴であるアプリケーションコンポーネント102は、実行環境101において実行される。アプリケーションコンポーネント102は、実際の文書と、システム内における文書の様々な論理的、物理的な表現を含む。さらに、アプリケーションコンポーネント102は、文書を管理するために使用されるシステムの構成を含む。アプリケーションコンポーネント102は、さらに、UserApplication(ユーザアプリケーション)106、アプリケーションコア108、ユーザインタフェイス107、及びCoreComponent(コアコンポーネント)110を含む。
【0080】
a)ユーザアプリケーション
UserApplication106は、ProgramInvoker103と共にシステム上にロードされる。UserApplication106は、文書と、文書の様々な表現と、文書と対話するために必要なユーザインタフェイスとをつなぐ接着剤となる。例えば、ユーザが、プロジェクトの一部である文書のセットを生成したいとする。これらの文書がロードされると、文書の適切な表現が生成される。ユーザインタフェイス機能は、UserApplication106の一部として追加される。言いかえれば、UserApplication106は、ユーザがプロジェクトの一部を形成する文書と対話することを可能とする文書の表現と、文書の様々な態様とを、共に保持する。一旦UserApplication106が生成されると、ユーザがプロジェクトの一部を形成する文書との対話を望むたびに、ユーザは簡単に実行環境上にUserApplication106をロードすることができる。
【0081】
b)コアコンポーネント
CoreComponent110は、複数のPane(ペイン)の間で文書を共有する方法を提供する。後で詳述するように、Paneは、DOMツリーを表示し、画面の物理的なレイアウトを扱う。例えば、物理的な画面は、個々の情報の断片を描写する画面内の複数のPaneからなる。ユーザから画面上に見える文書は、1又はそれ以上のPaneに出現しうる。また、2つの異なる文書が画面上で2つの異なるPaneに現れてもよい。
【0082】
図11(c)に示されるように、画面の物理的なレイアウトもツリーの形式になっている。Paneは、RootPane(ルートペイン)1084にもなり得るし、SubPane(サブペイン)1085にもなり得る。RootPane1084は、Paneのツリーの根に当たるPaneであり、SubPane1085は、RootPane1084以外の任意のPaneである。
【0083】
CoreComponent110は、さらに、フォントを提供し、ツールキットなど、文書のための複数の機能的な操作のソースの役割を果たす。CoreComponent110により実行されるタスクの一例に、複数のPane間におけるマウスカーソルの移動がある。実行されるタスクの他の例として、あるPane中の文書の一部をマークし、それを異なる文書を含む別のPane上にコピーする。
【0084】
c)アプリケーションコア
上述したように、アプリケーションコンポーネント102は、システムにより処理され管理される文書から構成される。これは、システム内における文書の様々な論理的及び物理的な表現を含む。アプリケーションコア108は、アプリケーションコンポーネント102の構成である。その機能は、実際の文書を、それに含まれる全てのデータとともに保持することである。アプリケーションコア108は、DocumentManager(ドキュメントマネージャ:文書管理部)1081及びDocument(ドキュメント:文書)1082自身を含む。
【0085】
DocumentManager1081の様々な態様を以下に詳述する。DocumentManager1081は、Document1082を管理する。DocumentManager1081は、RootPane1084、SubPane1085、ClipBoard(クリップボード)ユーティリティ1087、及びSnapShot(スナップショット)ユーティリティ1088にも接続される。ClipBoardユーティリティ1087は、ユーザがクリップボードに加えることを決定した文書の部分を保持する方法を提供する。例えば、ユーザが、文書の一部を切り取り、後で再考するために新規文書にそれを保存することを望んだとする。このような場合、切り取られた部分がClipBoardに追加される。
【0086】
つづいて、SnapShotユーティリティ1088についても説明する。SnapShotユーティリティ1088は、アプリケーションがある状態から別の状態まで移行するときに、アプリケーションの現在の状態を記憶することを可能とする。
【0087】
d)ユーザインタフェイス
アプリケーションコンポーネント102の別の構成は、ユーザがシステムと物理的に対話する手段を提供するユーザインタフェイス107である。例えば、ユーザインタフェイスは、ユーザが文書をアップロードしたり、削除したり、編集したり、管理したりするために使用される。ユーザインタフェイスは、Frame(フレーム)1071、MenuBar(メニューバー)1072、StatusBar(ステータスバー)1073、及びURLBar(URLバー)1074を含む。
【0088】
Frame1071は、一般に知られているように、物理的な画面のアクティブな領域であるとみなされる。MenuBar1072は、ユーザに選択を提供するメニューを含む画面領域である。StatusBar1073は、アプリケーションの実行状態を表示する画面領域である。URLBar1074は、インターネットをナビゲートするためにURLアドレスを入力する領域を提供する。
【0089】
C.文書管理及び関連するデータ構造
図12は、DocumentManager1081の詳細を示す。これは、文書処理システム内で文書を表現するために用いられるデータ構造及び構成を含む。分かりやすくするために、このサブセクションで説明される構成は、MVCパラダイムを用いて説明される。
【0090】
DocumentManager1081は、文書処理システム内にある全ての文書を保持しホストするDocumentContainer(ドキュメントコンテナ:文書コンテナ)203を含む。DocumentManager1081にアタッチされたツールキット201は、DocumentManager1081により使用される様々なツールを提供する。例えば、DomService(DOMサービス)は、文書に対応するDOMを生成し、保持し、管理するために必要とされる全ての機能を提供するために、ツールキット201により提供されるツールである。ツールキット201により提供される別のツールであるIOManager(入出力管理部)は、システムへの入力及びシステムからの出力を管理する。同様に、StreamHandler(ストリームハンドラ)は、ビットストリームによる文書のアップロードを扱うツールである。これらのツールは、図中に特に示さず、参照番号を割り当てないが、ツールキット201のコンポーネントを形成する。
【0091】
MVCパラダイムの表現によれば、モデル(M)は、文書のDOMツリーモデル202を含む。前述したように、全ての文書は、文書処理システムにおいてDOMツリーとして表現される。文書は、また、DocumentContainer203の一部を形成する。
【0092】
1.DOMモデル及びゾーン
文書を表現するDOMツリーは、Node(ノード)2021を有するツリーである。DOMツリーの部分集合であるZone(ゾーン)209は、DOMツリー内の1以上のNodeの関連領域を含む。例えば、画面上で文書の一部のみを表示し得るが、この可視化された文書の一部はZone209を用いて表示される。Zoneは、ZoneFactory(ゾーンファクトリ:ゾーン生成部)205と呼ばれるプラグインを用いて、生成され、取り扱われ、処理される。ZoneはDOMの一部を表現するが、1以上の「名前空間」を使用してもよい。よく知られているように、名前空間は、名前空間内でユニークな名前の集合である。換言すれば、名前空間内に同じ名前は存在しない。
【0093】
2.Facet及びFacetとZoneとの関係
Facet(ファセット)2022は、MVCパラダイムのモデル(M)部分内の別の構成である。Facetは、ZoneにおいてNodeを編集するために使用される。Facet2022は、Zone自身の内容に影響を与えずに実行することができる手続(プロシージャ)を使用して、DOMへのアクセスを編成する。次に説明するように、これらの手続は、Nodeに関連した重要で有用な操作を実行する。
【0094】
各Nodeは、対応するFacetを有する。DOMの中のNodeを直接操作する代わりに、操作を実行するためにFacetを使用することによって、DOMの保全性は保護される。操作がNode上で直接実行される場合、いくつかのプラグインがDOMを同時に変更することができ、その結果矛盾を引き起こす。
【0095】
W3Cが策定したDOMの標準規格は、Nodeを操作するための標準的なインタフェイスを定義するが、実際には、ボキャブラリごと又はNodeごとに特有の操作があるので、これらの操作をAPIとして用意しておくのが好都合である。文書処理システムでは、このような各Nodeに特有のAPIをFacetとして用意し、各Nodeにアタッチする。これにより、DOMの標準規格に準拠しつつ、有用なAPIを付加することができる。また、ボキャブラリごとに特有のDOMを実装するのではなく、標準的なDOMの実装に、後から特有のAPIを付加するようにすることで、多様なボキャブラリを統一的に処理することができるともに、複数のボキャブラリが任意の組合せで混在した文書を適切に処理することができる。
【0096】
ボキャブラリは、名前空間に属するタグ(例えばXMLのタグ)のセットである。上述したように、名前空間は、ユニークな名前(ここではタグ)のセットを有する。ボキャブラリは、XML文書を表現するDOMツリーのサブツリーとして現れる。このサブツリーはZoneを含む。特定の例においては、タグセットの境界はZoneによって定義される。Zone209は、ZoneFactory205と呼ばれるServiceを利用して生成される。上述したように、Zone209は、文書を表現するDOMツリーの一部の内部表現である。このような文書の一部へのアクセスを提供するために、論理的な表現が要求される。この論理的表現は、文書が画面上で論理的にどのように表現されるかについてコンピュータに通知する。Canvas(キャンバス)210は、Zoneに対応する論理的なレイアウトを提供するように作用するServiceである。
【0097】
他方、Pane211は、Canvas210により提供される論理的なレイアウトに対応する物理的な画面レイアウトである。実際、ユーザは表示画面上で文字や画像によって文書のレンダリングのみを見る。したがって、文書は、画面上に文字や画像を描画するプロセスにより、画面上に描写されなければならない。文書は、Pane211により提供される物理的なレイアウトに基づいて、Canvas210により画面上に描写される。
【0098】
Zone209に対応するCanvas210は、Editlet206を使用して生成される。文書のDOMは、Editlet206及びCanvas210を使用して編集される。元の文書の完全性を維持するために、Editlet206及びCanvas210は、Zone209における1以上のNodeに対応するFacetを使用する。これらのServiceは、Zone及びDOM内のNodeを直接操作しない。Facetは、Command207を利用して操作される。
【0099】
ユーザは、一般に、画面上のカーソルを移動させたり、コマンドをタイプしたりすることによって、画面と対話する。画面上の論理的なレイアウトを提供するCanvas210は、このカーソル操作を受け付ける。Canvas210は、対応するアクションをFacetに実行させることができる。この関係により、カーソルサブシステム204は、DocumentManager1081に対して、MVCパラダイムのコントローラ(C)として機能する。Canvas210は、イベントを扱うタスクも有する。例えば、Canvas210は、マウスクリック、フォーカス移動、及びユーザにより起こされた同様のアクションなどのイベントを扱う。
【0100】
3.Zone、Facet、Canvas及びPaneの間の関係の概要
文書処理システム内の文書は、少なくとも4つの観点から見ることができる。すなわち、1)文書処理システムにおいて文書の内容及び構造を保持するために用いられるデータ構造、2)文書の保全性に影響を与えずに文書の内容を編集する手段、3)文書の画面上の論理的なレイアウト、4)文書の画面上の物理的なレイアウト、である。Zone、Facet、Canvas及びPaneは、前述の4つの観点に相当する、文書処理システムのコンポーネントをそれぞれ表す。
【0101】
4.アンドゥサブシステム
上述したように、文書に対するいかなる変更(例えば編集)も取消可能であることが望ましい。例えば、ユーザが編集操作を実行し、次に、その変更の取消を決定したとする。図12に関連して、アンドゥサブシステム212は、文書管理部の取消可能なコンポーネントを実現する。UndoManager(アンドゥマネージャ:アンドゥ管理部)2121は、ユーザによって取り消される可能性のある全ての文書に対する操作を保持する。
【0102】
例えば、ユーザが、文書中の単語を別の単語に置換するコマンドを実行したとする。その後、ユーザは考え直し、元の単語に戻すことを決定したとする。アンドゥサブシステム212は、このような操作を支援する。UndoManager2121は、このようなUndoableEdit(アンドゥアブルエディット:取消可能な編集)2122の操作を保持する。
【0103】
5.カーソルサブシステム
前述したように、MVCのコントローラ部分は、カーソルサブシステム204を備えてもよい。カーソルサブシステム204は、ユーザから入力を受け付ける。これらの入力は、一般にコマンド及び/又は編集操作の性格を有している。したがって、カーソルサブシステム204は、DocumentManager1081に関連したMVCパラダイムのコントローラ(C)部分であると考えることができる。
【0104】
6.ビュー
前述したように、Canvas210は、画面上に提示されるべき文書の論理的なレイアウトを表す。XHTML文書の例では、Canvas210は、文書が画面上でいかに見えるかを論理的に表現したボックスツリー208を含んでもよい。このボックスツリー208は、DocumentManager1081に関連したMVCパラダイムのビュー(V)部分に含まれよう。
【0105】
D.ボキャブラリコネクション
文書処理システムの重要な特徴は、XML文書を、他の表現にマップして取り扱うことが可能で、かつ、マップした先の表現を編集すると、その編集が元のXML文書に整合性を保ちつつ反映される環境を提供することにある。
【0106】
マークアップ言語により記述された文書、例えばXML文書は、文書型定義により定義されたボキャブラリに基づいて作成されている。ボキャブラリは、タグのセットである。ボキャブラリは、任意に定義されてもよいため、無限に多くのボキャブラリが存在しうる。しかしながら、多数の可能なボキャブラリのそれぞれに対して専用の処理/管理環境を提供するのは現実的ではない。ボキャブラリコネクションは、この問題を解決する方法を提供する。
【0107】
例えば、文書は2以上のマークアップ言語により記述されてもよい。文書は、例えば、XHTML(eXtensible HyperText Markup Language)、SVG(Scalable Vector Graphics)、MathML(Mathematical Markup Language)、その他のマークアップ言語により記述されてもよい。換言すれば、マークアップ言語は、XMLにおけるボキャブラリやタグセットと同様に見なされてもよい。
【0108】
ボキャブラリは、ボキャブラリプラグインを用いて処理される。文書処理システムにおいてプラグインが利用不可能であるボキャブラリにより記述された文書は、プラグインが利用可能である別のボキャブラリの文書にマッピングすることにより表示される。この特徴により、プラグインが用意されていないボキャブラリの文書も適切に表示することができる。
【0109】
ボキャブラリコネクションは、定義ファイルを取得し、取得した定義ファイルに基づいて2つの異なるボキャブラリの間でマッピングする能力を含む。あるボキャブラリで記述された文書は、別のボキャブラリにマッピングすることができる。このように、ボキャブラリコネクションは、文書がマッピングされるボキャブラリに対応した表示/編集プラグインにより文書を表示し編集することを可能にする。
【0110】
上述したように、各文書は、一般に複数のノードを有するDOMツリーとして文書処理システムにおいて記述される。「定義ファイル」は、それぞれのノードについて、そのノードと他のノードとの対応を記述する。各ノードの要素値及び属性値が編集可能か否かが指定される。ノードの要素値又は属性値を用いた演算式が記述されてもよい。
【0111】
マッピングという特徴を利用して、定義ファイルを適用したデスティネーションDOMツリーが生成される。このように、ソースDOMツリーとデスティネーションDOMツリーの関係が構築され保持される。ボキャブラリコネクションは、ソースDOMツリーとデスティネーションDOMツリーの対応を監視する。ユーザから編集指示を受けると、ボキャブラリコネクションは、ソースDOMツリーの関連したノードを変更する。ソースDOMツリーが変更されたことを示す「ミューテーションイベント」が発行され、デスティネーションDOMツリーがそれに応じて変更される。
【0112】
ボキャブラリコネクションの使用により、少数のユーザのみに知られていた比較的マイナーなボキャブラリを、別のメジャーなボキャブラリに変換することができる。したがって、少数のユーザによって利用されるマイナーなボキャブラリであっても、文書を適切に表示し、望ましい編集環境を提供することができる。
【0113】
このように、文書処理システムの一部であるボキャブラリコネクションサブシステムは、文書の複数の表現を可能にする機能を提供する。
【0114】
図13は、ボキャブラリコネクション(VC:Vocabulary Connection)サブシステム300を示す。VCサブシステム300は、同一の文書の2つの代替表現の整合性を維持する方法を提供する。例えば、2つの表現は、同一文書の、2つの異なるボキャブラリによる表現であってもよい。前述したように、一方はソースDOMツリーであってもよく、他方はデスティネーションDOMツリーであってもよい。
【0115】
1.ボキャブラリコネクションサブシステム
ボキャブラリコネクションサブシステム300の機能は、VocabularyConnection301と呼ばれるプラグインを使用して、文書処理システムにおいて実現される。文書が表現されるVocabulary305ごとに、対応するプラグインが要求される。例えば、文書の一部がHTMLで記述され、残りがSVGで記述されている場合、HTMLとSVGに対応するボキャブラリプラグインが要求される。
【0116】
VocabularyConnectionプラグイン301は、適切なVocabulary305の文書に対応した、Zone209又はPane211のための適切なVCCanvas(ボキャブラリコネクションキャンバス)310を生成する。VocabularyConnection301を用いて、ソースDOMツリー内のZone209に対する変更は、変換ルールにより、別のDOMツリー306の対応するZoneに伝達される。変換ルールは、ボキャブラリコネクション記述子(Vocabulary Connection Descriptor:VCD)の形式で記述される。このようなソースDOMとデスティネーションDOMの間の変換に対応するそれぞれのVCDファイルについて、対応するVCManager(ボキャブラリコネクションマネージャ)302が生成される。
【0117】
2.Connector
Connector304は、ソースDOMツリーのソースノードと、デスティネーションDOMツリーのデスティネーションノードとを接続する。Connector304は、ソースDOMツリー中のソースノード、及びソースノードに対応するソース文書に対する修正(変更)を見るために作用する。そして、対応するデスティネーションDOMツリーのノードを修正する。Connector304は、デスティネーションDOMツリーを修正することができる唯一のオブジェクトである。例えば、ユーザは、ソース文書、及び対応するソースDOMツリーに対してのみ修正を行うことができる。その後、Connector304がデスティネーションDOMツリーに、対応する修正を行う。
【0118】
Connector304は、ツリー構造を形成するために、論理的にリンクされる。Connector304により形成されたツリーは、ConnectorTree(コネクタツリー)と呼ばれる。Connector304は、ConnectorFactory(コネクタファクトリ:コネクタ生成部)303と呼ばれるServiceを用いて生成される。ConnectorFactory303は、ソース文書からConnector304を生成し、それらをリンクしてConnectorTreeを形成する。VocabularyConnectionManager302は、ConnectorFactory303を保持する。
【0119】
前述したように、ボキャブラリは名前空間におけるタグのセットである。図示されるように、Vocabulary305は、VocabularyConnection301によって文書に対して生成される。これは、文書ファイルを解析し、ソースDOMとデスティネーションDOMの間の写像のための適切なVocabularyConnectionManager302を生成することにより行われる。さらに、Connectorを生成するConnectorFactory303と、Zone209を生成するZoneFactory205と、Zone内のノードに対応するCanvasを生成するEditlet206との間の適切な関係が作られる。ユーザがシステムから文書を処分又は削除するとき、対応するVocabularyConnectionManager302が削除される。
【0120】
Vocabulary305は、VCCanvas310を生成する。さらに、Connector304及びデスティネーションDOMツリー306が対応して生成される。
【0121】
ソースDOM及びCanvasは、それぞれ、モデル(M)及びビュー(V)に対応する。しかしながら、このような表現は、ターゲットのボキャブラリが画面上に描写可能である場合に限って意味がある。描写は、ボキャブラリプラグインにより行われる。ボキャブラリプラグインは、主要なボキャブラリ、例えば、XHTML、SVG、MathMLについて提供される。ボキャブラリプラグインは、ターゲットのボキャブラリに関連して使用される。これらは、ボキャブラリコネクション記述子を用いてボキャブラリ間でマッピングする方法を提供する。
【0122】
このようなマッピングは、ターゲットのボキャブラリが、マッピング可能で、画面上に描写される方法が予め定義されたものである場合にのみ意味がある。このようなレンダリング方法は、例えばXHTMLなどのように、W3Cなどの組織により定義された標準規格となっている。
【0123】
ボキャブラリコネクションが必要であるとき、VCCanvasが使用される。この場合、ソースのビューを直接生成することができないので、ソースのCanvasは生成されない。この場合、VCCanvasが、ConnectorTreeを使用して生成される。このVCCanvasは、イベントの変換のみを扱い、画面上の文書の描写を援助しない。
【0124】
3.DestinationZone、Pane、及びCanvas
上述したように、ボキャブラリコネクションサブシステムの目的は、同一の文書の2つの表現を同時に生成し保持することである。第2の表現も、DOMツリーの形式であり、これはデスティネーションDOMツリーとして既に説明した。第2の表現における文書を見るために、DestinationZone、Canvas及びPaneが必要である。
【0125】
VCCanvasが作成されると、対応するDestinationPane307が生成される。さらに、関連するDestinationCanvas308と、対応するBoxTree309が生成される。同様に、VCCanvas310も、ソース文書に対するPane211及びZone209に関連づけられる。
【0126】
DestinationCanvas308は、第2の表現における文書の論理的なレイアウトを提供する。特に、DestinationCanvas308は、デスティネーション表現における文書を描写するために、カーソルや選択のようなユーザインタフェイス機能を提供する。DestinationCanvas308に生じたイベントは、Connectorに供給される。DestinationCanvas308は、マウスイベント、キーボードイベント、ドラッグアンドドロップイベント、及び文書のデスティネーション(第2)表現のボキャブラリに特有なイベントを、Connector304に通知する。
【0127】
4.ボキャブラリコネクションコマンドサブシステム
ボキャブラリコネクション(VC)サブシステム300の要素として、ボキャブラリコネクション(VC)コマンドサブシステム313がある。ボキャブラリコネクションコマンドサブシステム313は、ボキャブラリコネクションサブシステム300に関連した命令の実行のために使用されるVCCommand(ボキャブラリコネクションコマンド)315を生成する。VCCommandは、内蔵のCommandTemplate(コマンドテンプレート)318を使用して、及び/又は、スクリプトサブシステム314においてスクリプト言語を使用してスクラッチからコマンドを生成することにより、生成することができる。
【0128】
コマンドテンプレートには、例えば、「If」コマンドテンプレート、「When」コマンドテンプレート、「挿入(Insert)」コマンドテンプレートなどがある。これらのテンプレートは、VCCommandを作成するために使用される。
【0129】
5.XPathサブシステム
XPathサブシステム316は、文書処理システムの重要な構成であり、ボキャブラリコネクションの実現を支援する。Connector304は、一般にxpath情報を含む。上述したように、ボキャブラリコネクションのタスクの1つは、ソースDOMツリーの変化をデスティネーションDOMツリーに反映させることである。xpath情報は、変更/修正を監視されるべきソースDOMツリーのサブセットを決定するために用いられる1以上のxpath表現を含む。
【0130】
6.ソースDOMツリー、デスティネーションDOMツリー、及びConnectorTreeの概要
ソースDOMツリーは、別のボキャブラリに変換される前のボキャブラリで文書を表現したDOMツリー又はZoneである。ソースDOMツリーのノードは、ソースノードと呼ばれる。
【0131】
それに対して、デスティネーションDOMツリーは、ボキャブラリコネクションに関連して前述したように、同一の文書を、マッピングにより変換された後の異なるボキャブラリで表現したDOMツリー又はZoneである。デスティネーションDOMツリーのノードは、デスティネーションノードと呼ばれる。
【0132】
ConnectorTreeは、ソースノードとデスティネーションノードの対応を表すConnectorに基づく階層的表現である。Connectorは、ソースノードと、ソース文書になされた修正を監視し、デスティネーションDOMツリーを修正する。Connectorは、デスティネーションDOMツリーを修正することを許された唯一のオブジェクトである。
【0133】
E.文書処理システムにおけるイベントフロー
実用のためには、プログラムはユーザからのコマンドに応答しなければならない。イベントは、プログラム上で実行されたユーザアクションを記述し実行する方法である。多くの高級言語、例えばJava(登録商標)は、ユーザアクションを記述するイベントに頼っている。従来、プログラムは、ユーザアクションを理解し、それを自身で実行するために、積極的に情報を集める必要があった。これは、例えば、プログラムが自身を初期化した後、ユーザが画面、キーボード、マウスなどでアクションを起こしたときに適切な処理を講じるために、ユーザのアクションを繰り返し確認するループに入ることを意味する。しかしながら、このプロセスは扱いにくい。さらに、それは、ユーザが何かをするのを待つ間、CPUサイクルを消費してループするプログラムを必要とする。
【0134】
多くの言語が、異なるパラダイムを採用することにより、これらの問題を解決している。そのうちの一つは、現代の全てのウィンドウシステムの基礎となっている、イベントドリブンプログラミングである。このパラダイムでは、全てのユーザアクションは、「イベント」と呼ばれる抽象的な事象の集合に属する。イベントは、十分詳細に、特定のユーザアクションを記述する。プログラムがユーザにより生成されたイベントを積極的に収集するのではなく、監視すべきイベントが生じたときに、システムがプログラムに通知する。この方法によりユーザとの対話を扱うプログラムは「イベントドリブン」であると言われる。
【0135】
これは、多くの場合、全てのユーザにより生成されたイベントの基本特性を獲得する「Event(イベント)」クラスを使用して扱われる。
【0136】
文書処理システムは、自身のイベント、及びこれらのイベントを扱う方法を定義して使用する。いくつかの型のイベントが使用される。例えば、マウスイベントは、ユーザのマウスアクションから起こるイベントである。マウスを含むユーザアクションは、Canvas210によって、マウスイベントに渡される。このように、Canvasは、システムのユーザによる相互作用の最前部にあると言える。必要であれば、最前部にあるCanvasは、そのイベントに関連した内容を子へ渡す。
【0137】
それに対して、キーストロークイベントは、Canvas210から流れる。キーストロークイベントは、即時的なフォーカスを有する。すなわち、それは、いかなる瞬間でも作業に関連する。Canvas210上に入力されたキーストロークイベントは、その親に渡される。キー入力は、文字列挿入を扱うことが可能な、異なるイベントによって処理される。文字列の挿入を扱うイベントは、キーボードを使用して文字が挿入されたときに発生する。他の「イベント」は、例えば、ドラッグイベント、ドロップイベント、マウスイベントと同様に扱われる他のイベントを含む。
【0138】
1.ボキャブラリコネクション外のイベントの取り扱い
イベントは、イベントスレッドを用いて渡される。Canvas210は、イベントを受け取ると、その状態を変更する。必要であれば、Command1052がCanvas210によりCommandQueue1053にポストされる。
【0139】
2.ボキャブラリコネクション内のイベントの取り扱い
VocabularyConnectionプラグイン301を用いて、DestinationCanvasの一例であるXHTMLCanvas1106は、発生したイベント、例えば、マウスイベント、キーボードイベント、ドラッグアンドドロップイベント、及びボキャブラリに特有のイベントなどを受け取る。これらのイベントは、コネクタ304に通知される。より詳細には、図21(b)に図示されるように、VocabularyConnectionプラグイン301内のイベントフローは、SourcePane1103、VCCanvas1104、DestinationPane1105、DestinationCanvasの一例であるDestinationCanvas1106、デスティネーションDOMツリー及びConnectorTreeを通過する。
【0140】
F.ProgramInvoker及びProgramInvokerと他の構成との関係
ProgramInvoker103及びそれと他の構成との関係は、図14(a)に更に詳細に示される。ProgramInvoker103は、文書処理システムを開始するために実行される実行環境中の基本的なプログラムである。図11(b)及び図11(c)に図示されるように、UserApplication106、ServiceBroker1041、CommandInvoker1051、及びResource109は、全てProgramInvoker103に接続される。前述したように、アプリケーション102は、実行環境中で実行されるコンポーネントである。同様に、ServiceBroker1041は、システムに様々な機能を加えるプラグインを管理する。他方、CommandInvoker1051は、ユーザにより提供される命令を実行して、コマンドを実行するために使用されるクラス及びファンクションを保持する。
【0141】
1.プラグイン及びサービス
ServiceBroker1041について、図14(b)を参照して更に詳細に説明する。前述したように、ServiceBroker1041は、システムに様々な機能を追加するプラグイン(及び関連するサービス)を管理する。Service1042は、文書処理システムに特徴を追加又は変更可能な最も下の層である。「Service」は、ServiceCategory401とServiceProvider402の2つの部分からなる。図14(c)に図示されるように、1つのServiceCategory401は、複数の関連するServiceProvider402を持ちうる。それぞれのServiceProviderは、特定のServiceCategoryの一部または全部を実行するように作用する。ServiceCategory401は、他方では、Serviceの型を定義する。
【0142】
Serviceは、1)文書処理システムに特定の特色を提供する「特色サービス」、2)文書処理システムにより実行されるアプリケーションである「アプリケーションサービス」、3)文書処理システムの全体にわたって必要な特色を提供する「環境サービス」、の3つの型に分類することができる。
【0143】
Serviceの例は、図14(d)に示される。アプリケーションServiceのCategoryにおいては、システムユーティリティが対応するServiceProviderの例である。同様に、Editlet206はCategoryであり、HTMLEditlet及びSVGEditletは対応するServiceProviderである。ZoneFactory205は、Serviceの別のCategoryであり、対応するServiceProvider(図示せず)を有する。
【0144】
プラグインは、文書処理システムに機能性を加えると既に説明したが、いくつかのServiceProvider402及びそれらに関連するクラスからなるユニットと見なされてもよい。各プラグインは、宣言ファイルに記述された依存性及びServiceCategory401を有する。
【0145】
2.ProgramInvokerとアプリケーションとの関係
図14(e)は、ProgramInvoker103とUserApplication106との関係についての更なる詳細を示す。必要な文書やデータなどは、ストレージからロードされる。必要なプラグインは、全てServiceBroker1041上にロードされる。ServiceBroker1041は、全てのプラグインを保持し管理する。プラグインは、システムに物理的に追加することができ、又、その機能はストレージからロードすることができる。プラグインの内容がロードされると、ServiceBroker1041は、対応するプラグインを定義する。つづいて、対応するUserApplication106が生成され、実行環境101にロードされ、ProgramInvoker103にアタッチされる。
【0146】
G.アプリケーションサービスと環境との関係
図15(a)は、ProgramInvoker103上にロードしたアプリケーションサービスの構成についての更なる詳細を示す。コマンドサブシステム105のコンポーネントであるCommandInvoker1051は、ProgramInvoker103内のCommand1052を起動又は実行する。Command1052は、文書処理システムにおいて、XMLなどの文書を処理し、対応するXMLDOMツリーを編集するために用いられる命令である。CommandInvoker1051は、Command1052を実行するために必要なクラス及びファンクションを保持する。
【0147】
ServiceBroker1041も、ProgramInvoker103内で実行される。UserApplication106は、ユーザインタフェイス107及びCoreComponent110に接続される。CoreComponent110は、全てのPaneの間で文書を共有する方法を提供する。CoreComponent110は、さらにフォントを提供し、Paneのためのツールキットの役割を果たす。
【0148】
図15(b)は、Frame1071、MenuBar1072、及びStatusBar1073の関係を示す。
【0149】
H.アプリケーションコア
図16(a)は、全ての文書、及び文書の一部及び文書に属するデータを保持するアプリケーションコア108についての更なる説明を提供する。CoreComponent110は、文書1082を管理するDocumentManager1081にアタッチされる。DocumentManager1081は、文書処理システムに関連づけられたメモリに格納される全ての文書1082の所有者である。
【0150】
画面上の文書の表示を容易にするために、DocumentManager1081はRootPane1084にも接続される。ClipBoard1087、SnapShot1088、Drag&Drop601、及びOverlay602の機能も、CoreComponent110にアタッチされる。
【0151】
SnapShot1088は、アプリケーションの状態を元に戻すために使用される。ユーザがSnapShot1088を起動したとき、アプリケーションの現状が検知され、格納される。その後、アプリケーションの状態が別の状態に変わるとき、格納された状態の内容は保存される。SnapShot1088は、図16(b)に図示される。動作において、アプリケーションがあるURLから他へ移動するときに、前に戻る動作及び先に進む動作をシームレスに実行可能とするために、SnapShot1088は以前の状態を記憶する。
【0152】
I.DocumentManager内における文書の構成
図17(a)は、DocumentManager1081の更なる説明と、DocumentManagerにおいて文書が構成され保持される様子を示す。図11(b)に示したように、DocumentManager1081は、文書1082を管理する。図17(a)に示される例において、複数の文書のうちの1つはRootDocument(ルート文書)701であり、残りの文書はSubDocument(サブ文書)702である。DocumentManager1081は、RootDocument701に接続され、RootDocument701は、全てのSubDocument702に接続される。
【0153】
図12及び図17(a)に示すように、DocumentManager1081は、全ての文書1082を管理するオブジェクトであるDocumentContainer203に結合される。DOMService703及びIOManager704を含むツールキット201(例えばXMLツールキット)の一部を形成するツールも、DocumentManager1081に供給される。再び図17(a)を参照して、DOMService703は、DocumentManager1081により管理される文書に基づいたDOMツリーを生成する。各Document705は、それがRootDocument701であってもSubDocument702であっても、対応するDocumentContainer203によって管理される。
【0154】
図17(b)は、文書A−Eが階層的に配置される様子を示す。文書AはRootDocumentである。文書B−Dは、文書AのSubDocumentである。文書Eは、文書DのSubDocumentである。図17(b)の左側は、これと同じ文書の階層が画面上に表示された例を示す。RootDocumentである文書Aは、基本フレームとして表示される。文書AのSubDocumentである文書B−Dは、基本フレームAの中のサブフレームとして表示される。文書DのSubDocumentである文書Eは、サブフレームDのサブフレームとして画面に表示される。
【0155】
再び図17(a)を参照して、UndoManager(アンドゥマネージャ:アンドゥ管理部)706及びUndoWrapper(アンドゥラッパー)707は、それぞれのDocumentContainer203に対して生成される。UndoManager706及びUndoWrapper707は、取消可能なコマンドを実行するために使用される。この特徴を使用することにより、編集操作を使用して文書に対して実行された変更を取り消すことができる。SubDocumentの変更は、RootDocumentとも密接な関係を有する。アンドゥ操作は、階層内の他の文書に影響する変更を考慮に入れて、例えば、図17(b)に示されるような連鎖状の階層における全ての文書の間で整合性が維持されることを保証する。
【0156】
UndoWrapper707は、DocumentContainer203内のSubDocumentに関連するアンドゥオブジェクトをラップし、それらをRootDocumentに関連するアンドゥオブジェクトに結合させる。UndoWrapper707は、UndoableEditAcceptor(アンドゥアブルエディットアクセプタ:アンドゥ可能編集受付部)709に利用可能なアンドゥオブジェクトの収集を実行する。
【0157】
UndoManager706及びUndoWrapper707は、UndoableEditAcceptor709及びUndoableEditSource(アンドゥアブルエディットソース)708に接続される。当業者には理解されるように、Document705がUndoableEditSource708であってもよく、取消可能な編集オブジェクトのソースであってもよい。
【0158】
J.アンドゥコマンド及びアンドゥフレームワーク
図18(a)及び図18(b)は、アンドゥフレームワーク及びアンドゥコマンドについて更なる詳細を提供する。図18(a)に示されるように、UndoCommand801、RedoCommand802、及びUndoableEditCommand803は、図11(b)に示したようにCommandInvoker1051に積むことができるコマンドであり、順に実行される。UndoableEditCommand803は、UndoableEditSource708及びUndoableEditAcceptor709に更にアタッチされる。「foo」EditCommand804及び「bar」EditCommand805は、UndoableEditCommandの例である。
【0159】
1.UndoableEditCommandの実行
図18(b)は、UndoableEditCommandの実行を示す。まず、ユーザが編集コマンドを使用してDocument705を編集すると仮定する。第1ステップS1では、UndoableEditAcceptor709が、Document705のDOMツリーであるUndoableEditSource708にアタッチされる。第2ステップS2では、ユーザにより発行されたコマンドに基づいて、Document705がDOMのAPIを用いて編集される。第3ステップS3では、ミューテーションイベントのリスナーが、変更がなされたことを通知される。すなわち、このステップでは、DOMツリーの全ての変更を監視するリスナーが編集操作を検知する。第4ステップS4では、UndoableEditがUndoManager706のオブジェクトとして格納される。第5ステップS5では、UndoableEditAcceptor709がUndoableEditSource708からデタッチされる。UndoableEditSource708は、Document705自身であってもよい。
【0160】
K.システムへの文書のロードに関する手順
上記のサブセクションでは、システムの様々なコンポーネント及びサブコンポーネントについて説明した。以下、これらのコンポーネントの使用に関する方法論について説明する。図19(a)は、文書処理システムに文書がロードされる様子の概要を示す。それぞれのステップは、図24−28において、特定の例に関連して詳述される。
【0161】
簡単には、文書処理システムは、文書に含まれるデータからなるバイナリデータストリームからDOMを生成する。ApexNode(エイペックスノード:頂点ノード)が、注目対象でありZoneに属する文書の一部のために生成される。つづいて、対応するPaneが同定される。同定されたPaneは、ApexNode及び物理的な画面表面からZone及びCanvasを生成する。Zoneは、次に、それぞれのノードにFacetを生成し、それらに必要とされる情報を提供する。Canvasは、DOMツリーから、ノードをレンダリングするためのデータ構造を生成する。
【0162】
より詳細には、文書はストレージ901からロードされる。文書のDOMツリー902が生成される。文書を保持するための、対応するDocumentContainer903が生成される。DocumentContainer903は、DocumentManager904にアタッチされる。DOMツリーは、ルートノードと、ときには複数のセカンダリノードを含む。
【0163】
一般に、このような文書は、テキスト及びグラフィクスの双方を含む。したがって、DOMツリーは、例えば、XHTMLサブツリーだけでなくSVGサブツリーを有してもよい。XHTMLサブツリーは、XHTMLのApexNode905を有する。同様に、SVGサブツリーは、SVGのApexNode906を有する。
【0164】
ステップ1では、ApexNode906が、画面の論理的なレイアウトであるPane907にアタッチされる。ステップ2では、Pane907は、PaneOwner(ペインオーナー:ペインの所有者)908であるCoreComponentに、ApexNode906のためのZoneFactoryを要求する。ステップ3では、PaneOwner908は、ZoneFactoryと、ApexNode906のためのCanvasFactoryであるEditletとを返す。
【0165】
ステップ4では、Pane907がZone909を生成する。Zone909はPane907にアタッチされる。ステップ5では、Zone909がそれぞれのノードに対してFacetを生成し、対応するノードにアタッチする。ステップ6では、Pane907がCanvas910を生成する。Canvas910はPane907にアタッチされる。Canvas910には様々なCommandが含まれる。ステップ7では、Canvas910が文書を画面にレンダリングするためのデータ構造を構築する。XHTMLの場合、これはボックスツリー構造を含む。
【0166】
1.ZoneのMVC
図19(b)は、MVCパラダイムを用いてZoneの構成の概要を示す。この場合、Zone及びFacetは文書に関連した入力であるから、モデル(M)はZone及びFacetを含む。Canvasと、文書を画面にレンダリングするためのデータ構造体は、ユーザが画面上に見る出力であるから、ビュー(V)はCanvas及びデータ構造体に対応する。Commandは、文書とその様々な関係に対して制御操作を実行するので、コントロール(C)はCanvasに含まれるCommandを含む。
【0167】
L.文書の表現
図20を用いて、文書及びその様々な表現の例について以下に説明する。この例で使用される文書は、テキストと画像の双方を含む。テキストは、XHTMLを用いて表され、画像は、SVGを用いて表される。図20は、文書のコンポーネント及び対応するオブジェクトの関係のMVC表現を詳細に示す。この例において、Document1001は、Document1001を保持するDocumentContainer1002にアタッチされる。文書はDOMツリー1003により表現される。DOMツリーは、ApexNode1004を含む。
【0168】
ApexNodeは、黒丸で表される。頂点でないノードは、白丸で表される。ノードを編集するために用いられるFacetは、三角形で表され、対応するノードにアタッチされる。文書がテキストと画像を有するので、この文書のDOMツリーは、XHTML部分とSVG部分を含む。ApexNode1004は、XHTMLサブツリーの最上のノードである。これは、文書のXHTML部分の物理的な表現のための最上PaneであるXHTMLPane1005にアタッチされる。ApexNode1004は、文書のDOMツリーの一部であるXHTMLZone1006にもアタッチされる。
【0169】
Node1004に対応するFacetも、XHTMLZone1006にアタッチされる。XHTMLZone1006は、XHTMLPane1005にアタッチされる。XHTMLEditletは、文書の論理的な表現であるXHTMLCanvas1007を生成する。XHTMLCanvas1007は、XHTMLPane1005にアタッチされる。XHTMLCanvas1007は、Document1001のXHTMLコンポーネントのためのBoxTree1009を生成する。文書のXHTML部分を保持し描画するために必要な様々なCommand1008も、XHTMLCanvas1007に追加される。
【0170】
同様に、文書のSVGサブツリーのApexNode1010は、文書のSVGコンポーネントを表現するDocument1001のDOMツリーの一部であるSVGZone1011にアタッチされる。ApexNode1010は、文書のSVG部分の物理的な表現の最上のPaneであるSVGPane1013にアタッチされる。文書のSVG部分の論理的な表現を表すSVGCanvas1012は、SVGEditletにより生成され、SVGPane1013にアタッチされる。画面上に文書のSVG部分をレンダリングするためのデータ構造及びコマンドは、SVGCanvasにアタッチされる。例えば、このデータ構造は、図示されるように、円、線、長方形などを含んでもよい。
【0171】
図20に関連して説明された文書例の表現の一部について、図21(a)に関連して、前述したMVCパラダイムを用いて更に説明する。図21(a)は、文書1001のXHTMLコンポーネントにおけるMVの関係を簡略化して示す。モデルは、Document1001のXHTMLコンポーネントのためのXHTMLZone1101である。XHTMLZoneのツリーには、いくつかのNode及びそれらに対応するFacetが含まれる。対応するXHTMLZone及びPaneは、MVCパラダイムのモデル(M)部分の一部である。MVCパラダイムのビュー(V)部分は、Document1001のXHTMLコンポーネントの、対応するXHTMLCanvas1102及びBoxTreeである。文書のXHTML部分は、Canvasと、それに含まれるCommandを使用して画面に描写される。キーボードやマウス入力などのイベントは、図示されるように、逆方向へ進む。
【0172】
SourcePaneは、更なる機能、すなわち、DOMの保有者としての役割を有する。図21(b)は、図21(a)に示したDocument1001のコンポーネントに対するボキャブラリコネクションを提供する。DOMホルダーとして機能するSourcePane1103は、文書のソースDOMツリーを含む。ConnectorTreeは、ConnectorFactoryにより生成され、デスティネーションDOMの保有者としても機能するDestinationPane1105を生成する。DestinationPane1105は、XHTMLDestinationCanvas1106としてボックスツリーの形式でレイアウトされる。
【0173】
M.プラグインサブシステム、ボキャブラリコネクション、及びコネクタの関係
図22(a)−(c)は、それぞれ、プラグインサブシステム、ボキャブラリコネクション、及びConnectorに関連する更なる詳細を示す。プラグインサブシステムは、文書処理システムに機能を追加又は交換するために用いられる。プラグインサブシステムは、ServiceBroker1041を含む。ServiceBroker1041にアタッチされるZoneFactoryService1201は、文書の一部に対するZoneを生成する。EditletService1202も、ServiceBroker1041にアタッチされる。EditletService1202は、Zone中のNodeに対応するCanvasを生成する。
【0174】
ZoneFactoryの例は、XHTMLZone及びSVGZoneをそれぞれ生成するXHTMLZoneFactory1211及びSVGZoneFactory1212である。文書例に関連して前述したように、文書のテキストコンポーネントは、XHTMLZoneを生成することにより表現されてもよいし、画像はSVGZoneを用いて表現されてもよい。EditletServiceの例は、XHTMLEditlet1221及びSVGEditlet1222を含む。
【0175】
図22(b)は、ボキャブラリコネクションに関連する更なる詳細を示す。ボキャブラリコネクションは、前述したように、文書処理システムの重要な特徴であり、2つの異なる方法で文書の整合のとれた表現及び表示を可能とする。ConnectorFactory303を保持するVCManager302は、ボキャブラリコネクションサブシステムの一部である。ConnectorFactory303は、文書のConnector304を生成する。前述したように、Connectorは、ソースDOM中のノードを監視し、2つの表現の間の整合性を維持するために、デスティネーションDOM中のノードを修正する。
【0176】
Template317は、いくつかのノードの変換ルールを表す。ボキャブラリコネクション記述子(VCD)ファイルは、特定のパス又はルールを満たす要素又は要素の集合を他の要素に変換するいくつかのルールを表すTemplateのリストである。Template317及びCommandTemplate318は、全てVCManager302にアタッチされる。VCManagerは、VCDファイル中の全てのセクションを管理するオブジェクトである。1つのVCDファイルに対して、1つのVCManagerオブジェクトが生成される。
【0177】
図22(c)は、Connectorに関連する更なる詳細を提供する。ConnectorFactory303は、ソース文書からConnectorを生成する。ConnectorFactory303は、Vocabulary、Template、及びElementTemplateにアタッチされ、それぞれ、VocabularyConnector、TemplateConnector、ElementConnectorを生成ずる。
【0178】
VCManager302は、ConnectorFactory303を保持する。Vocabularyを生成するために、対応するVCDファイルが読み込まれる。こうして、ConnectorFactory303が生成される。このConnectorFactory303は、Zoneを生成するZoneFactory及びCanvasを生成するEditletに関連する。
【0179】
つづいて、ターゲットボキャブラリのEditletServiceが、VCCanvasを生成する。VCCanvasも、ソースDOMツリー又はZoneにおけるApexNodeのConnectorを生成する。必要に応じて、子のConnectorが再帰的に生成される。ConnectorTreeは、VCDファイル中のテンプレートの集合により生成される。
【0180】
テンプレートは、マークアップ言語の要素を他の要素に変換するためのルールの集合である。例えば、各テンプレートは、ソースDOMツリー又はZoneにマッチされる。適切にマッチした場合には、頂点Connectorが生成される。例えば、テンプレート「A/*/D」は、間にどんなノードがあるかに関係なく、ノードAで始まりノードDで終わる全ての枝に合致する。同様に、「//B」は、ルートからの全ての「B」ノードに一致する。
【0181】
N.ConnectorTreeに関係するVCDファイルの例
特定の文書と関係する処理を説明する例を続ける。ドキュメントタイトルのある「MySampleXML」というタイトルの文書が文書処理システムにロードされる。図23は、「MySampleXML」ファイルのための、VCManager及びConnectorFactoryTreeを用いたVCDスクリプトの例を示す。スクリプトファイル中のボキャブラリセクション、テンプレートセクションと、VCManagerにおける対応するコンポーネントが示される。タグ「vcd:vocabulary」において、属性「match」は「sample:root」、「label」は「MySampleXML」、「call-template」は「sample template」となっている。
【0182】
この例では、Vocabularyは、「MySampleXML」のVCManagerにおいて「sample:root」として頂点要素を含む。対応するUIラベルは、「MySampleXML」である。テンプレートセクションにおいて、タグは「vcd:template」であり、名前は「sample:template」である。
【0183】
O.ファイルがシステムにロードされる方法の詳細な例
図24−28は、文書「MySampleXML」のロードについての詳細な記述を示す。図24(a)に示されるステップ1では、文書がストレージ1405からロードされる。DOMServiceは、DOMツリー及びDocumentManager1406と対応するDocumentContainer1401を生成する。DocumentContainer1401は、DocumentManager1406にアタッチされる。文書は、XHTML及びMySampleXMLのサブツリーを含む。XHTMLのApexNode1403は、タグ「xhtml:html」が付されたXHTMLの最上のノードである。「MySampleXML」のApexNode1404は、タグ「sample:root」が付された「MySampleXML」の最上ノードである。
【0184】
図24(b)に示されるステップ2では、RootPaneが文書のXHTMLZone、Facet、及びCanvasを生成する。Pane1407、XHTMLZone1408、XHTMLCanvas1409、及びBoxTree1410が、ApexNode1403に対応して生成される。
【0185】
図24(c)に示されるステップ3では、XHTMLZoneが知らないタグ「sample:root」を発見し、XHTMLCanvasの領域からSubPaneを生成する。
【0186】
図25に示されるステップ4では、SubPaneが「sample:root」を扱うことができ、適切なZoneを生成可能なZoneFactoryを得る。このZoneFactoryは、ZoneFactoryを実行可能なVocabulary内にある。それは、「MySampleXML」のVocabularySectionの内容を含む。
【0187】
図26に示されるステップ5では、「MySampleXML」に対応するVocabularyがDefaultZone1601を生成する。対応するEditletが生成され、対応するCanvasを生成するためにSubPane1501が提供される。Editletは、VCCanvasを生成する。そして、それはTemplateSectionを呼ぶ。ConnectorFactoryTreeも含まれている。ConnectorFactoryTreeは、ConnectorTreeとなる全てのConnectorを生成する。
【0188】
図27に示されるステップ6では、各ConnectorがデスティネーションDOMオブジェクトを生成する。コネクタのうちのいくつかはxpath情報を含んでいる。xpath情報は、変更/修正を監視する必要のあるソースDOMツリーの部分集合を決定するために使用される1以上のxpath表現を含む。
【0189】
図28に示されるステップ7では、ボキャブラリは、ソースDOMのペインからデスティネーションDOMツリーのDestinationPaneを作成する。これは、SourcePaneに基づいてなされる。デスティネーションツリーのApexNodeは、DestinationPane及び対応するZoneにアタッチされる。DestinationPaneは、DestinationCanvasを生成し、文書をデスティネーションのフォーマットでレンダリングするためのデータ構造及びコマンドを構築する、自身のEditletを提供される。
【0190】
図29(a)は、対応するソースノードを持たず、デスティネーションツリーにのみ存在するノード上でイベントが発生したときのフローを示す。マウスイベント、キーボードイベントなど、Canvasが取得したイベントは、デスティネーションツリーを通過して、ElementTemplateConnectorに伝達される。ElementTemplateConnectorは対応するソースノードを持たないので、伝達されたイベントはソースノードに対する編集操作ではない。ElementTemplateConnectorは、伝達されたイベントがCommandTemplateに記述されたコマンドに合致すれば、それに対応するActionを実行する。合致するコマンドがなければ、ElementTemplateConnectorは、伝達されたイベントを無視する。
【0191】
図29(b)は、TextOfConnectorによりソースノードに対応づけられているデスティネーションツリーのノード上でイベントが発生したときのフローを示す。TextOfConnectorは、ソースDOMツリーのXPathで指定されたノードからテキストノードを取得して、デスティネーションDOMツリーのノードにマッピングする。マウスイベント、キーボードイベントなど、Canvasが取得したイベントは、デスティネーションツリーを通過して、TextOfConnectorに伝達される。TextOfConnectorは、伝達されたイベントを、対応するソースノードの編集コマンドにマッピングし、Queue1053に積む。編集コマンドは、Facetを介して実行されるDOMのAPIコールの集合である。キューに積まれたコマンドが実行されると、ソースノードが編集される。ソースノードが編集されると、ミューテーションイベントが発行され、リスナーとして登録されたTextOfConnectorにソースノードの変更が通知される。TextOfConnectorは、ソースノードの変更を、対応するデスティネーションノードに反映させるように、デスティネーションツリーを再構築する。このとき、TextOfConnectorを含むテンプレートに、「for each」や「for loop」などの制御文が含まれている場合、ConnectorFactoryがこの制御文を再評価し、TextOfConnectorを再構築した後、デスティネーションツリーが再構築される。
【0192】
(実施例)
図30は、本実施例における帳票管理システムのハードウェア構成図である。
この帳票管理システム302においては、フォーム設定者がデザインした帳票の入力フォームに応じて、データ入力者が各種のデータを入力する。本実施例では、会社などの業務組織において、データ入力者としての社員が業務に必要な部材を発注するための帳票を題材として説明する。
【0193】
帳票管理システム302において、帳票データ管理サーバ308、帳票入力端末装置304および帳票デザイン端末装置300はLAN306を介して接続されている。
フォーム設定者は、帳票デザイン端末装置300において電子的な帳票の入力フォームをデザインする。この入力フォームの内容を定義するデータ(以下、「フォームデータ」とよぶ)は、帳票デザイン端末装置300から帳票データ管理サーバ308にアップロードされる。ここでいうフォームデータは、入力フォームのデータ構造(以下、「スキーマ」とよぶ)と、表示レイアウトが定義されたXML文書ファイルである。これは、例えば、前提技術に記載した「定義ファイル」に相当するファイルである。
【0194】
データ入力者となる社員は、帳票データ管理サーバ308に保存されているフォームデータを、帳票入力端末装置304にダウンロードする。定義された表示レイアウトにしたがって帳票入力のための入力フォームが帳票入力端末装置304に画面表示される。データ入力者は、この入力フォームを介して発注対象の部材に関連して各種データを入力する。たとえば、発注者として自己を特定するための情報や、発注部材に関する情報などである。こうして入力されたデータは、定義されたスキーマにしたがったXML文書ファイルとして保管される。ちょうど、図2に関連して説明したようなXML文書ファイル(以下、「入力データファイル」ともよぶ)が成果物として生成されることになる。
帳票入力端末装置304は、前提技術における文書処理装置20によって実現されるといえる。フォームデータである定義ファイルに基づいて、主として、VCユニット80により、データの編集が実行されることになる。
【0195】
入力データファイルは、帳票入力端末装置304から帳票データ管理サーバ308に送信される。帳票データ管理サーバ308は、帳票ごとに入力データファイルを保持する。すなわち、帳票データ管理サーバ308には、帳票ごとにデータが集積されることになる。フォーム設定者により作成された入力フォームという「型」を通して、入力データが取得され、かつ、そのスキーマにしたがって入力データが構造化されることになる。
【0196】
フォームデータに定義されたスキーマにしたがって入力データが構造化されるため、帳票データ管理サーバ308は、入力データの検索や統計などのデータ処理を容易に実行できる。これは、スキーマを定義できるXMLの利点でもある。また、データ入力者にとっても、あらかじめ設定された表示レイアウトにしたがってデータを入力すればよいため、帳票の作成作業が容易となっている。
このような帳票管理システム302の利便性を高めるためには、フォーム設定者が容易に帳票の入力フォームを作成できる必要がある。いいかえれば、フォームデータにおける表示レイアウトとスキーマの設計を容易に行うためのユーザインタフェースが必要である。
以下、フォームデータ、特に、フォームデータの編集処理に関して詳細に説明する。
【0197】
なお、フォーム設定者は帳票デザイン端末装置300にてフォームデータをローカルに作成し、作成された後のフォームデータが帳票データ管理サーバ308にアップロードされる形態として本実施例を説明する。
このほかにも、フォーム設定者は、帳票デザイン端末装置300のウェブブラウザを介して、帳票データ管理サーバ308のフォームデータ、特に、スキーマにアクセスしてもよい。すなわち、フォーム設定者は、LAN306を介して帳票データ管理サーバ308に編集コマンドを送信することにより、帳票データ管理サーバ308において一元的に管理されるフォームデータを編集するとしてもよい。
同様に、データ入力者も、帳票入力端末装置304のウェブブラウザを介して、帳票データ管理サーバ308のフォームデータにアクセスしてもよい。このときには、データ入力者はLAN306を介して入力データを送信することにより、帳票データ管理サーバ308において入力データファイルが生成されてもよい。
【0198】
図31は、帳票デザイン端末装置の機能ブロック図である。
ここに示す各ブロックは、ハードウェア的には、コンピュータのCPUをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
ここでは、主として各ブロックの発揮すべき機能について述べ、その具体的な作用については、図32以降に関連して説明する。
【0199】
帳票デザイン端末装置300は、ユーザインタフェース処理部310、通信部320、データ処理部330およびフォームデータ保持部340を含む。
ユーザインタフェース処理部310は、フォーム設定者に対するユーザインタフェース処理全般を担当する。通信部320は、フォームデータのアップロードなどに関して、帳票データ管理サーバ308との通信処理を担当する。フォームデータ保持部340は、作成されたフォームデータを保持する。データ処理部330は、フォーム設定者による操作入力に応じて、フォームデータを編集するためのデータ処理を実行する。データ処理部330は、ユーザインタフェース処理部310、通信部320およびフォームデータ保持部340を統合的に制御する。
データ処理部330の主たる機能は、前提技術で説明した定義ファイル生成部86により実現される。
【0200】
ユーザインタフェース処理部310は、画面表示部312と操作検出部314を含む。
画面表示部312は、入力フォームを編集するための設計画面を表示させる。本実施例においては、いわゆるウェブブラウザ態様にて設計画面が表示される。操作検出部314は、フォーム設定者によるマウスやキーボードなどの入力デバイスを介した編集のための操作入力を検出する。
【0201】
データ処理部330は、スキーマ設定部332、レイアウト設定部334およびプロパティ設定部336を含む。
後に図示するが、帳票の入力フォームにはデータ入力者がデータを入力するための項目が設定される。レイアウト設定部334は、入力フォームの表示レイアウトを設定する。この表示レイアウトに関する情報はフォームデータの一部として、レイアウト設定部334によりフォームデータ保持部340に格納される。この表示レイアウト情報にしたがって、帳票の入力フォームがデータ入力者に表示されることになる。
【0202】
入力フォームの各項目に入力されたデータは、所定のデータ構造にしたがって構造化される。これも後に図示するが、フォーム設定者は、この入力されたデータを仕分けするためのスキーマも設定する。スキーマ設定部332は、この入力データについてのスキーマを設定する。この設定されたスキーマに関する情報もフォームデータの一部として、スキーマ設定部332によりフォームデータ保持部340に格納される。このスキーマ情報にしたがって、データ入力者により入力されたデータが構造化されることになる。スキーマは、XMLのタグ構造に相当するといえる。
【0203】
また、各項目には、入力データのフォーマットなどについて各種のプロパティが設定される。プロパティ設定部336は、この項目についてのプロパティに関する情報もフォームデータの一部としてフォームデータ保持部340に格納する。このプロパティ情報にしたがって、各項目の入力データに関する規約が設定されることになる。
【0204】
ここで、フォームデータ作成に関する流れをまとめておく。
通信部320は、帳票データ管理サーバ308からフォームデータのテンプレートをダウンロードすると、フォームデータ保持部340に格納する。なお、帳票デザイン端末装置300は、フォームデータを最初から作成してもよい。フォーム設定者は、ユーザインタフェース処理部310を介してフォームデータの表示レイアウトやスキーマを編集するための画面表示をさせる。データ処理部330は、フォーム設定者からの入力に応じてフォームデータの内容を変更する。変更後のフォームデータは、フォームデータ保持部340に格納される。通信部320は、フォーム設定者による指示により、フォームデータ保持部340のフォームデータを帳票データ管理サーバ308にアップロードする。このようにして、作成された帳票の入力フォームがデータ入力者に提供される。
【0205】
図32は、帳票デザイン端末装置においてフォーム設定者が入力フォームを編集するための帳票フォーム設計画面を示す図である。
帳票デザイン端末装置300の画面表示部312は、帳票フォーム設計画面350に示す形態にて、入力フォームを編集するための画面を表示させる。帳票フォーム設計画面350は、レイアウト編集領域360とスキーマ編集領域400に分かれる。レイアウト編集領域360は、入力フォームの表示レイアウトを編集するための領域である。スキーマ編集領域400は、入力されたデータのスキーマ、すなわち、タグ構造を編集するための領域である。
【0206】
この帳票は、データ入力者が発注する予定の部材を記入するためのものである。図35に関連しても説明するが、レイアウト編集領域360に示される表示レイアウトにて、帳票の入力フォームが帳票入力端末装置304に表示されることになる。
【0207】
まず、レイアウト編集領域360から説明する。
社員情報欄370は、社員を特定するための情報を記入させるための欄である。
社員情報欄370は、社員ID欄372、社員名欄374、社員所属欄376および社員写真欄378の4つの入力項目を含む。
社員ID欄372は、社員IDを選択させるための項目である。社員ID欄372は、コンボボックスで形成されており、データ入力者はこのコンボボックスをプルダウンしたときに表示される社員IDの一覧から、所望の社員IDを選択する。社員名欄374は、社員の氏名を表示する項目である。社員所属欄376は、社員の所属部署を示す項目である。社員写真欄378は、社員の顔写真を示す項目である。
【0208】
発注部材情報欄380は、発注すべき部材を特定するための情報を記入させるための欄である。
発注部材情報欄380は、部材名欄382、部材説明欄384、部材単価欄386、部材発注量欄388および部材小計欄390の5つの項目を含む。
部材名欄382は、発注の対象となる部材名を記入するための項目である。部材説明欄384は、発注部材の内容に関する説明を記入させるための項目である。部材単価欄386は、部材の単価を示し、部材発注量欄388は、部材の発注量を示す。部材小計欄390は、部材単価欄386の単価と部材発注量欄388の発注量を乗算した小計値を示す。このように、部材小計欄390は、部材単価欄386と部材発注量欄388の入力データに基づいてその値が算出されるべき項目である。これは、図4に関連して説明した、生徒の平均点を算出するための編集不可能な「value-of」の項目と同様である。
【0209】
発注部材情報欄380は、発注する部材の種類に応じて行を追加することもできる。発注部材情報欄380には、そのような行の追加削除を実行するためのコマンドが割り当てられている。合計発注額欄392は、この帳票において各種部材を発注するときの合計額を示す。備考欄394は、データ入力者に発注に関する備考を記入させるための項目である。
【0210】
これらの項目の中には、データ入力者にデータを入力させるための編集可能項目や、その入力されたデータを変数として実行される計算結果を表示させるための編集不可能項目がある。いずれにせよ、これらの各項目を介して、さまざまなフォーマットのデータが取得されることになる。スキーマ編集領域400は、こうして得られたデータを構造化して管理するためのスキーマを編集するための領域である。
【0211】
スキーマ編集領域400において、「Person」とあるのは、レイアウト編集領域360の社員情報欄370に対応するXMLのタグである。社員情報欄370が4つの項目をもっていたように、「Person」も、「ID」、「Name」、「Post」および「Snapshot」の4つのタグをもっている。これらは、それぞれ、社員ID欄372、社員名欄374、社員所属欄376および社員写真欄378に対応する。
「Item」タグは、発注部材情報欄380に対応する。「Item」の下にある5つのタグ「Name」、「Description」、「ItemCost」、「Quantity」および「SubTotal」は、発注部材情報欄380の部材名欄382、部材説明欄384、部材単価欄386、部材発注量欄388および部材小計欄390にそれぞれ対応する。
また、「TotalCost」タグは合計発注額欄392、「Notice」タグは備考欄394に対応する。
【0212】
フォーム設定者は、スキーマ編集領域400にてタグを定義する。タグをレイアウト編集領域360にドラッグ&ドロップすることにより、レイアウト編集領域360に対応する項目を作ることができる。このとき、レイアウト設定部334は、タグに対応した項目のグラフィクスを、レイアウト編集領域360に設定する。また、たとえば、コンボボックスとするかテキストボックスとするかといったタグの表示形態に関しても、帳票フォーム設計画面350において設定できる。
このような表示レイアウトとスキーマの対応づけは、ちょうど、図2に示した成績データのデータ構造に含まれる構成要素を、図4に示した表形式テンプレートに割り当てる方式と同様である。帳票フォーム設計画面350において、フォーム設定者は、直接XMLのソースファイルや定義ファイルを編集しなくとも、GUI(Graphical User Interface)を介してフォームデータを作成できる。いいかえれば、GUIを介して、タグの定義、構造化および表示レイアウトを同一画面上にて作成できる。
【0213】
図33は、タグの制約条件を設定するための画面図の一例である。
この制約条件設定画面430は、「Person:Snapshot」タグについての制約条件を設定するための画面である。ここでいう制約条件としては、主なものとしては、以下の諸条件を挙げることができる。
1.入力形式条件
編集可能項目に入力されるデータのフォーマットに関する条件である。たとえば、入力されるデータが、文字列型であるか整数型であるかといったデータ入力形式についての条件が該当する。
2.入力範囲条件
編集可能項目または編集不可能項目において、入力データとして許容される範囲を指定するための条件である。
3.データ処理条件
項目の入力データを算出するために実行されるべき処理内容を示す条件である。また、他の項目における入力データを変数として実行される処理であってもよい。
4.エラー処理条件
入力データが入力フォーマット条件や入力データ範囲条件に違反したときに、実行すべき処理内容を示すための条件である。
5.入力権限条件
データを入力する権限を有するデータ入力者を特定するための条件である。
【0214】
制約条件設定画面430においては、社員写真欄378についての制約条件が設定される。入力ガイド欄432におけるデータは、カーソルが社員写真欄378に合わせられたときにツールチップ(ToolTip)として表示されるべきメッセージである。データ位置欄434は、社員写真欄378に表示されるべき社員の顔写真データの所在を示す。本実施例においては、社員IDや、名前、所属、顔写真などの社員に関するデータは、帳票データ管理サーバ308のデータベースに格納されている。ここでは、そのデータベースにおいて顔写真データが所在する位置を示している。表示名欄436は、社員写真欄378において表示されている項目名「写真」を示している。
OKボタン456がオンされると、プロパティ設定部336は設定を有効化する。キャンセルボタン458がオンされると、設定が有効化されずに帳票フォーム設計画面350に戻る。
【0215】
図34は、タグの制約条件を設定するための画面図の別例である。
この制約条件設定画面440は、「TotalCost」タグについての制約条件を設定するための画面である。
項目欄442は、制約条件を設定する対象となっているタグを示す。条件欄444は、入力範囲条件を示し、変数欄446は、その範囲を特定するための変数を示す。ここでは、「TotalCost」、すなわち、合計発注額欄392に入力される数値が30000(円)以下でなければならないという入力範囲条件が設定されている。この入力範囲条件に違反すると、メッセージ欄448に示されるメッセージが表示されることになる。ここでいうメッセージ欄448は、エラー処理条件に相当するといえる。関数欄450は、この項目の入力データを計算するための演算式を示す。ここでは、「Item:SubTotal」として示される項目の入力データ、すなわち、発注部材の小計をトータルした値を合計発注額欄392に入力されるべき値として設定している。いわば、この関数欄450は、制約条件のうちデータ処理条件を示しているといえる。
このほかにも、項目によっては、データを入力する権限が与えられるべきデータ入力者を特定するための入力権限条件を指定するための欄が設けられてもよい。
【0216】
図35は、帳票入力端末装置においてデータ入力者がデータを入力するための帳票の入力フォームを示す図である。
帳票デザイン端末装置300の通信部320は、作成されたフォームデータを帳票データ管理サーバ308にアップロードする。帳票入力端末装置304は、このフォームデータにおける表示レイアウトにしたがって、帳票入力画面460を表示させる。
【0217】
図32と比較しながら説明する。社員情報欄470は、レイアウト編集領域360の社員情報欄370に対応する。社員ID欄462、社員名欄464、社員所属欄466および社員写真欄468は、レイアウト編集領域360における社員ID欄372、社員名欄374、社員所属欄376および社員写真欄378に対応する。
データ入力者は、社員ID欄462にプルダウン表示される社員IDリストから、自分の社員IDを選択する。こうして、社員ID欄462に対応する「Person:ID」タグには、選択された社員IDが対応データとして保持されることになる。ここで社員名欄464に対応する「Person:Name」タグについては、社員IDが入力されたときには対応する社員名を表示させるというデータ処理条件が設定されている。社員IDの入力が検出されると、帳票入力端末装置304は、帳票データ管理サーバ308の社員データベースから、社員IDに対応する社員名を取得し、「Person:Name」タグの入力データとして格納する。こうして、データ入力者が社員IDを入力すると、社員名欄464に自動的に社員氏名が表示される。社員所属欄466や社員写真欄468についても同様である。すなわち、データ入力者が社員IDを入力するだけで、社員名、所属、顔写真データが自動的に入力フォームに表示される。
【0218】
発注部材情報欄480は、レイアウト編集領域360の発注部材情報欄380に対応する。部材名欄482、部材説明欄484、部材単価欄486、部材発注量欄488および部材小計欄490は、レイアウト編集領域360における部材名欄382、部材説明欄384、部材単価欄386、部材発注量欄388および部材小計欄390に対応する。
データ入力者は、部材名欄482に発注部材名を記入し、部材説明欄484に部材の説明を記入する。部材単価欄486に単価、部材発注量欄488に量を記入すると、部材小計欄490に自動的に小計が表示される。
この部材小計欄490に対応する「Item:SubTotal」タグには、部材単価欄486の単価と部材発注量欄488の量の乗算値が入力データとなるようにデータ処理条件が設定されている。帳票入力端末装置304は、部材単価欄486と部材発注量欄488の入力値を変数として、部材小計欄490に設定された演算を実行することにより、部材小計欄490における入力値を演算する。こうして、部材小計欄490に小計値が表示される。
行削除ボタン494は、発注部材情報欄480において行を削除するためのボタンであり、行追加ボタン492は、発注部材情報欄480において行を追加するためのボタンである。「Item」タグには、このような行の追加や削除のためのコマンドが追加されている。図4の定義ファイルにおいて示した「生徒の追加」や「生徒の削除」についてのコマンドと同様である。
【0219】
合計発注額欄495には、部材小計欄490における金額の合計値が表示される。これは、図34の関数欄450に関連してすでに説明したとおりである。ここで、合計発注額欄495について設定されていたエラー処理条件、すなわち、「合計金額が30000円以内」という条件に違反したので、メッセージ欄448に示されていたメッセージがアノテーション498として表示されている。備考欄496はレイアウト編集領域360おける備考欄394に対応する。
このようにして、フォーム設定者により設計されたスキーマに沿って、データ入力者から各種データが取得されることになる。
【0220】
図36は、帳票デザイン端末装置において制約条件を一覧表示させるための画面の一例である。
フォーム設定者は、帳票フォーム設計画面350において複数の項目に制約条件を設定できる。しかし、入力フォームに多くの項目が含まれるときには、どの項目にどのような制約条件を設定したかを把握することが困難になってくると考えられる。
このような課題を解決するために、帳票デザイン端末装置300は、制約条件を一覧表示させる機能を備えている。
【0221】
表示条件設定領域502は、制約条件のうち、一覧表示の対象となる条件を設定する為の領域である。同図においては、入力範囲条件とそれに関連するエラー処理条件について「入力規則に関する一覧」として一覧表示の対象とされている。操作検出部314は、フォーム設定者からのこのような指示入力を受け付けると、プロパティ設定部336は、その指示に応じた制約条件が設定されているタグをフォームデータ保持部340から検出する。画面表示部312は、入力規則一覧画面500に示すように項目と制約条件を対応づけたリストを表示する。すなわち、入力規則一覧画面500のリスト表示領域504に、そのリストが一覧表示される。
【0222】
また、入力権限条件が指定されているときには、データ入力者に応じた制約条件が表示されてもよい。たとえば、ある項目について、社員IDが「0100」〜「0200」のデータ入力者に対する制約条件と、社員ID「0201」〜「0300」のデータ入力者による制約条件が異なるときには、一つの項目についてのこれら複数種類の制約条件がリスト表示領域504に並置して表示されてもよい。たとえば、係長クラスで承認される部材発注額と課長クラスで承認される部材発注額が異なる場合が想定される。このようなときには、データ入力者に応じて制約条件が設定されてもよい。
【0223】
図37は、帳票デザイン端末装置において制約条件を一覧表示させるための画面の別例である。
ここでは、表示条件設定領域502は、帳票管理システム302においてデータが格納される位置を特定するための情報が示される。
このほかにも、入力フォーマット条件や入力権限条件など、さまざまな、観点から一覧表示させてもよい。なお、フォーム設定者は、入力規則一覧画面500やデータ規則一覧画面510においても、各タグの制約条件を設定できる。
【0224】
以上、帳票入力用のフォームを設計する例について説明したが、本実施の形態の帳票デザイン端末装置300を利用して、表形式やリスト形式のデータを効率よく処理する技術について更に説明する。
【0225】
図38は、帳票デザイン端末装置の構成の例を示す。図38に示した帳票デザイン端末装置300は、図31に示した帳票デザイン端末装置300の構成に加えて、データ入力機能付加部338を更に備える。その他の構成及び動作は、図31に示した帳票デザイン端末装置300と同様である。
【0226】
データ入力機能付加部338は、データ処理部330が生成する入力フォームの定義ファイルに、表形式データを外部から入力する機能を付加する。表形式データは、例えば、TSV(Tab Separated Values)又はCSV(Comma Separated Values)などの形式で与えられてもよいし、表計算ソフトやデータベースソフトなどのデータエクスポート機能により与えられてもよいし、表計算ソフトやデータベースソフトなどからドラッグ&ドロップ又はコピー&ペーストなどの機能を利用して与えられてもよいし、HTTPなどの通信プロトコルにより外部装置から与えられてもよい。データ入力機能付加部338により付加されるデータ入力機能は、入力フォームにより入力されるデータのうち、プロパティ設定部336において、繰り返し可能と定義されたデータに対して適用される。すなわち、このデータ入力機能は、入力フォームに対して外部から表形式のデータが与えられたとき、与えられた表形式のデータの各行を、繰り返し可能と定義された要素、又は、その要素の下位の要素のデータとして入力する。このような機能を付加することにより、入力フォームにデータを入力する際の利便性を飛躍的に向上させることができる。
【0227】
図39は、入力フォームに付加されるデータ入力部の機能ブロックを示す。データ入力部3090は、入力データ取得部3092、ヘッダ解析部3094、及びデータ設定部3096を含む。入力データ取得部3092は、表計算ソフト、データベースソフト、クリップボードなどから、表形式の入力データを取得する。ヘッダ解析部3094は、取得した入力データを解析して、どの列のデータを入力フォームのどのノードに設定するかを決定する。データ設定部3096は、ヘッダ解析部3094により決定されたノードにデータを設定する。
【0228】
ヘッダ解析部3094は、取得した表形式データの中にヘッダ行があれば、そのヘッダ行の内容を解析することにより、表形式データの列と、入力フォームのノードとの対応関係を決定する。例えば、表形式データの第1行に各列のデータの内容を記述した行があれば、その文字列と、入力フォームのノードの要素名又は属性名とを比較し、一致又は類似するものがあれば、それらを対応づける。取得した表形式データの第1行に限らず、例えば、いずれかの行にテキストデータが存在する場合は、その行をヘッダ行として解析してもよい。このとき、辞書を参照して同義語や翻訳語などを取得して、更に比較してもよい。また、帳票デザイン端末装置300のプロパティ設定部336が、入力フォームの繰り返し要素の下位にある要素や属性などに対して、表形式データのヘッダとして記述される可能性のある文字列を設定しておいてもよい。例えば、各要素や属性に対して通称名を設定し、その通称名と表形式データのヘッダ情報とを比較してもよい。ヘッダ解析部3094は、取得した表形式データをダイアログなどによりユーザに提示し、表形式データの列と、入力フォームのノードとの対応関係の指定をユーザから受け付けてもよい。このように、本実施の形態のデータ入力部3090によれば、表形式データの各列と、データを設定すべき要素又は属性などとの対応関係を自動的に又はユーザの指定により決定するので、表形式データの各列の並び順と、入力フォームのノードの並び順が一致していなくても、適切にデータを入力することができる。データを設定する要素又は属性をロケーションパスにより指定できるようにしてもよい。
【0229】
データ設定部3096は、ヘッダ解析部3094により決定された対応関係にしたがって、取得したデータを入力フォームに設定する。このとき、既に入力されたデータが存在する場合、それらを上書きしてもよいし、新たに繰り返し要素を追加してデータを挿入してもよい。
【0230】
図40は、帳票デザイン端末装置においてフォーム設定者が入力フォームを編集するための帳票フォーム設計画面を示す。画面右側のスキーマ定義領域において、「成績」ボキャブラリの構成要素が定義されている。「成績」ボキャブラリにおいて、ルート要素である「成績」要素は、下位に「生徒」要素を有しており、「生徒」要素は、下位に「国語」、「数学」、「理科」、「社会」の各要素を有している。
【0231】
図41は、「生徒」要素のプロパティを設定するためのダイアログ画面を示す。「生徒」要素のプロパティとして、「繰り返し」欄にチェックを入れ、繰り返し回数の最小数と最大数を指定すると、「生徒」要素が繰り返し要素として設定される。
【0232】
図42は、「生徒」要素の下位に含まれるデータの入力フォームのレイアウトを設定するためのダイアログ画面を示す。スキーマ定義領域に表示されている「生徒」要素をドラッグしてレイアウト領域にドロップすると、「生徒」要素の入力フォームを自動レイアウトするためのダイアログ画面が提示される。ここでは、「生徒」要素の下位に含まれるデータを表形式で入力する入力フォームを生成する。
【0233】
図43は、自動レイアウトされた「生徒」要素の入力フォームを示す。「生徒」要素の下位に含まれる「国語」、「数学」、「理科」、「社会」の各要素の要素値を入力するための表形式の入力フォームが生成されている。表の最上段には、各要素の要素名がヘッダとして表示されている。
【0234】
ここで、入力フォームの設定を終了すると、データ処理部330が入力フォームの画面を表示して、受け付けた入力データを文書として保存する機能を提供する定義データを生成する。データ入力機能付加部338は、この定義データに、表形式のデータをこの入力フォームに入力する機能を有するデータ入力部3090を付加する。
【0235】
図44は、帳票入力端末装置において入力フォームにデータを入力するための帳票フォーム入力画面を示す。画面左側のテンプレート領域において、「成績表」のテンプレートを選択すると、上記のように生成された定義データが呼び出され、成績表の入力フォーム画面が提示される。
【0236】
図45は、帳票入力端末装置により編集される文書のソースを示す。図44において、「成績表」のテンプレートを選択すると、図45に示したテンプレートが呼び出される。図44の帳票フォーム入力画面において、各セルにデータが入力されると、対応する要素の要素値としてデータが書き込まれる。
【0237】
図46は、表計算ソフトにおいて成績表のデータが入力された画面を示す。データ入力部3090は、これらのデータを帳票入力端末装置の入力フォームへコピーする機能を提供する。ユーザは、入力したいデータを選択して、コピー&ペースト、ドラッグ&ドロップなどの操作により、帳票入力端末装置の入力フォームへデータをコピーする。
【0238】
図47は、コピーしたデータを貼り付けるためのダイアログ画面を示す。マウスの右クリックにより提示されるコンテキストメニューにおいて、「タブ区切り値の貼り付け」を選択すると、クリップボードにコピーされている、タブにより区切られたデータが、繰り返し要素の下位のノードに貼り付けられる。このとき、カーソル位置が繰り返し要素の入力フォーム以外の位置にあっても、繰り返し要素に対してデータが貼り付けられる。
【0239】
図48は、タブ区切り値の貼り付け方を設定するためのダイアログ画面を示す。貼り付け方法として、既に入力されているデータを残して新たにデータを挿入するか、既に入力されているデータに上書きするかを選択することができる。また、空白データの扱い方として、データの無い状態とするか、空の文字列を入力するかを選択することができる。また、各列のデータをその順番で貼り付けるか、タブ区切り値のヘッダ行とスキーマの情報とを比較して対応づけて貼り付けるかを選択することができる。このとき、要素名と通称名のいずれを優先するかを選択することができる。
【0240】
図49は、図46に示したデータを貼り付けた画面を示す。ヘッダ解析部3094は、ヘッダ行に記入された、「名前」、「国語」、「数学」、「理科」、「社会」の各文字列と、「生徒」要素の下位の要素の要素名とを比較して、「国語」の列のデータを「国語」要素へ、「数学」の列のデータを「数学」要素へ、「理科」の列のデータを「理科」要素へ、「社会」の列のデータを「社会」要素へ、それぞれ対応づける。データ設定部3096は、ヘッダ解析部3094により対応づけられた要素のそれぞれへ各データを入力する。
【0241】
図50は、データが貼り付けられた文書のソースを示す。「生徒」要素が2つ設けられており、それぞれの「生徒」要素の下位の「国語」、「数学」、「理科」、「社会」の各要素には、貼り付けられたデータが設定されている。
【0242】
図51は、表計算ソフトにおいて成績表のデータが入力された画面の別の例を示す。図51では、「名前」、「理科」、「社会」、「数学」、「国語」の順に列が設けられている。
【0243】
図52は、図50に示したデータを貼り付けた画面を示す。ヘッダ解析部3094により、貼り付けられるデータの各列と、貼り付ける先のノードとが適切に対応づけられるので、「国語」要素には「国語」の列のデータが、「数学」要素には「数学」の列のデータが、「理科」要素には「理科」の列のデータが、「社会」要素には「社会」の列のデータが、それぞれ入力されている。
【0244】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【0245】
実施の形態では、XML文書を処理する例について説明したが、本実施の形態の文書処理装置20は、他のマークアップ言語、例えば、SGML、HTMLなどで記述された文書も同様に処理可能である。
【図面の簡単な説明】
【0246】
【図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】帳票デザイン端末装置の機能ブロック図である。
【図32】帳票デザイン端末装置においてフォーム設定者が入力フォームを編集するための帳票フォーム設計画面を示す図である。
【図33】タグの制約条件を設定するための画面図の一例である。
【図34】タグの制約条件を設定するための画面図の別例である。
【図35】帳票入力端末装置においてデータ入力者がデータを入力するための帳票入力画面を示す図である。
【図36】帳票デザイン端末装置において制約条件を一覧表示させるための画面の一例である。
【図37】帳票デザイン端末装置において制約条件を一覧表示させるための画面の別例である。
【図38】帳票デザイン端末装置の構成の例を示す図である。
【図39】入力フォームに付加されるデータ入力部の機能ブロックを示す図である。
【図40】帳票デザイン端末装置においてフォーム設定者が入力フォームを編集するための帳票フォーム設計画面を示す図である。
【図41】「生徒」要素のプロパティを設定するためのダイアログ画面を示す図である。
【図42】「生徒」要素の下位に含まれるデータの入力フォームのレイアウトを設定するためのダイアログ画面を示す図である。
【図43】自動レイアウトされた「生徒」要素の入力フォームを示す図である。
【図44】帳票入力端末装置において入力フォームにデータを入力するための帳票フォーム入力画面を示す図である。
【図45】帳票入力端末装置により編集される文書のソースを示す図である。
【図46】表計算ソフトにおいて成績表のデータが入力された画面を示す図である。
【図47】コピーしたデータを貼り付けるためのダイアログ画面を示す図である。
【図48】タブ区切り値の貼り付け方を設定するためのダイアログ画面を示す図である。
【図49】図46に示したデータを貼り付けた画面を示す図である。
【図50】データが貼り付けられた文書のソースを示す図である。
【図51】表計算ソフトにおいて成績表のデータが入力された画面の別の例を示す図である。
【図52】図50に示したデータを貼り付けた画面を示す図である。
【符号の説明】
【0247】
20 文書処理装置、22 主制御ユニット、24 編集ユニット、30 DOMユニット、32 DOM提供部、34 DOM生成部、36 出力部、40 CSSユニット、42 CSS解析部、44 CSS提供部、46 レンダリング部、50 HTMLユニット、52,62 制御部、54,64 編集部、56,66 表示部、60 SVGユニット、80 VCユニット、82 マッピング部、84 定義ファイル取得部、86 定義ファイル生成部、300 帳票デザイン端末装置、302 帳票管理システム、304 帳票入力端末装置、308 帳票データ管理サーバ、310 ユーザインタフェース処理部、312 画面表示部、314 操作検出部、320 通信部、330 データ処理部、332 スキーマ設定部、334 レイアウト設定部、336 プロパティ設定部、340 フォームデータ保持部、350 帳票フォーム設計画面、360 レイアウト編集領域、400 スキーマ編集領域、430 制約条件設定画面、440 制約条件設定画面、460 帳票入力画面、500 入力規則一覧画面、502 表示条件設定領域、504 リスト表示領域、510 データ規則一覧画面。
【特許請求の範囲】
【請求項1】
所定のタグセットで記述された構造化文書の要素構造を示す情報を取得する要素構造情報取得部と、
前記構造化文書に含まれるデータを、編集用の別のタグセットで記述されたデータに変換することにより、前記構造化文書の編集用ユーザインタフェース画面を表示するための定義データを、前記要素構造を示す情報に基づいて生成する定義データ生成部と、
前記構造化文書が繰り返し可能な要素を有する場合、外部から与えられる表形式データの少なくとも一部を、前記繰り返し可能な要素又はその要素の下位に存在するノードのノード値として入力するデータ入力機能を前記定義データに付加するデータ入力機能付加部と、
を備えることを特徴とするデータ処理装置。
【請求項2】
前記データ入力機能は、前記表形式データにヘッダ行が含まれる場合、前記ヘッダ行を解析することにより、前記表形式データの列と、前記ノードとの対応関係を決定することを特徴とする請求項1に記載のデータ処理装置。
【請求項3】
前記データ入力機能は、前記ヘッダ行に記載された前記表形式データの列の内容を示す文字列と、前記ノードの名称とを比較することにより、前記表形式データの列と、前記ノードとの対応関係を決定することを特徴とする請求項2に記載のデータ処理装置。
【請求項4】
前記定義データ生成部は、前記ノードに対して別名を設定する機能を有し、
前記データ入力機能は、前記ヘッダ行に記載された前記表形式データの列の内容を示す文字列と、前記ノードの別名とを比較することにより、前記表形式データの列と、前記ノードとの対応関係を決定することを特徴とする請求項2又は3に記載のデータ処理装置。
【請求項5】
所定のタグセットで記述される構造化文書を処理する処理部と、
前記構造化文書が繰り返し可能な要素を有する場合、外部から与えられる表形式データの少なくとも一部を、前記繰り返し可能な要素又はその要素の下位に存在するノードのノード値として入力するデータ入力部と、
を備えることを特徴とするデータ処理装置。
【請求項6】
所定のタグセットで記述された構造化文書の要素構造を示す情報を取得するステップと、
前記構造化文書に含まれるデータを、編集用の別のタグセットで記述されたデータに変換することにより、前記構造化文書の編集用ユーザインタフェース画面を表示するための定義データを、前記要素構造を示す情報に基づいて生成するステップと、
前記構造化文書が繰り返し可能な要素を有する場合、外部から与えられる表形式データの少なくとも一部を、前記繰り返し可能な要素又はその要素の下位に存在するノードのノード値として入力するデータ入力機能を前記定義データに付加するステップと、
を備えることを特徴とするデータ処理方法。
【請求項7】
所定のタグセットで記述された構造化文書の要素構造を示す情報を取得する機能と、
前記構造化文書に含まれるデータを、編集用の別のタグセットで記述されたデータに変換することにより、前記構造化文書の編集用ユーザインタフェース画面を表示するための定義データを、前記要素構造を示す情報に基づいて生成する機能と、
前記構造化文書が繰り返し可能な要素を有する場合、外部から与えられる表形式データの少なくとも一部を、前記繰り返し可能な要素又はその要素の下位に存在するノードのノード値として入力するデータ入力機能を前記定義データに付加する機能と、
を備えることを特徴とするプログラム。
【請求項1】
所定のタグセットで記述された構造化文書の要素構造を示す情報を取得する要素構造情報取得部と、
前記構造化文書に含まれるデータを、編集用の別のタグセットで記述されたデータに変換することにより、前記構造化文書の編集用ユーザインタフェース画面を表示するための定義データを、前記要素構造を示す情報に基づいて生成する定義データ生成部と、
前記構造化文書が繰り返し可能な要素を有する場合、外部から与えられる表形式データの少なくとも一部を、前記繰り返し可能な要素又はその要素の下位に存在するノードのノード値として入力するデータ入力機能を前記定義データに付加するデータ入力機能付加部と、
を備えることを特徴とするデータ処理装置。
【請求項2】
前記データ入力機能は、前記表形式データにヘッダ行が含まれる場合、前記ヘッダ行を解析することにより、前記表形式データの列と、前記ノードとの対応関係を決定することを特徴とする請求項1に記載のデータ処理装置。
【請求項3】
前記データ入力機能は、前記ヘッダ行に記載された前記表形式データの列の内容を示す文字列と、前記ノードの名称とを比較することにより、前記表形式データの列と、前記ノードとの対応関係を決定することを特徴とする請求項2に記載のデータ処理装置。
【請求項4】
前記定義データ生成部は、前記ノードに対して別名を設定する機能を有し、
前記データ入力機能は、前記ヘッダ行に記載された前記表形式データの列の内容を示す文字列と、前記ノードの別名とを比較することにより、前記表形式データの列と、前記ノードとの対応関係を決定することを特徴とする請求項2又は3に記載のデータ処理装置。
【請求項5】
所定のタグセットで記述される構造化文書を処理する処理部と、
前記構造化文書が繰り返し可能な要素を有する場合、外部から与えられる表形式データの少なくとも一部を、前記繰り返し可能な要素又はその要素の下位に存在するノードのノード値として入力するデータ入力部と、
を備えることを特徴とするデータ処理装置。
【請求項6】
所定のタグセットで記述された構造化文書の要素構造を示す情報を取得するステップと、
前記構造化文書に含まれるデータを、編集用の別のタグセットで記述されたデータに変換することにより、前記構造化文書の編集用ユーザインタフェース画面を表示するための定義データを、前記要素構造を示す情報に基づいて生成するステップと、
前記構造化文書が繰り返し可能な要素を有する場合、外部から与えられる表形式データの少なくとも一部を、前記繰り返し可能な要素又はその要素の下位に存在するノードのノード値として入力するデータ入力機能を前記定義データに付加するステップと、
を備えることを特徴とするデータ処理方法。
【請求項7】
所定のタグセットで記述された構造化文書の要素構造を示す情報を取得する機能と、
前記構造化文書に含まれるデータを、編集用の別のタグセットで記述されたデータに変換することにより、前記構造化文書の編集用ユーザインタフェース画面を表示するための定義データを、前記要素構造を示す情報に基づいて生成する機能と、
前記構造化文書が繰り返し可能な要素を有する場合、外部から与えられる表形式データの少なくとも一部を、前記繰り返し可能な要素又はその要素の下位に存在するノードのノード値として入力するデータ入力機能を前記定義データに付加する機能と、
を備えることを特徴とするプログラム。
【図1】
【図2】
【図3】
【図4(a)】
【図4(b)】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11(a)】
【図11(b)】
【図11(c)】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【図36】
【図37】
【図38】
【図39】
【図45】
【図50】
【図40】
【図41】
【図42】
【図43】
【図44】
【図46】
【図47】
【図48】
【図49】
【図51】
【図52】
【図2】
【図3】
【図4(a)】
【図4(b)】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11(a)】
【図11(b)】
【図11(c)】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【図36】
【図37】
【図38】
【図39】
【図45】
【図50】
【図40】
【図41】
【図42】
【図43】
【図44】
【図46】
【図47】
【図48】
【図49】
【図51】
【図52】
【公開番号】特開2009−59250(P2009−59250A)
【公開日】平成21年3月19日(2009.3.19)
【国際特許分類】
【出願番号】特願2007−227186(P2007−227186)
【出願日】平成19年8月31日(2007.8.31)
【出願人】(390024350)株式会社ジャストシステム (123)
【Fターム(参考)】
【公開日】平成21年3月19日(2009.3.19)
【国際特許分類】
【出願日】平成19年8月31日(2007.8.31)
【出願人】(390024350)株式会社ジャストシステム (123)
【Fターム(参考)】
[ Back to top ]