(57)【要約】【課題】マークアップ言語により記述された文書内にタグや属性を作成する柔軟性の高い技術を提供する。【解決手段】マークアップ言語で記述された文書に対応した操作性の高いユーザインタフェイスを提供し、ユーザの文書処理作業を支援する。例えば、ユーザインタフェイス内の編集可能領域に対する情報入力をもとにソース文書にその内容を反映する。また、ユーザの簡単なキー操作をもとに編集可能領域間の移動を可能にし容易な文書編集を実現する。【選択図】図１（ａ）
2008508643.tif 000002
【特許請求の範囲】
【請求項１】
マークアップ言語により記述された文書内にタグ又は属性を作成する方法であって、
インタフェイスの編集可能領域で情報が受け付けられたか否かを決定する工程と、
前記情報が受け付けられた場合、その情報をもとに前記タグ又は前記属性を作成する工程と、
を含むことを特徴とする方法。
【請求項２】
前記情報が前記編集可能領域で受け付けられた場合に限り、前記タグ又は前記属性が作成されることを特徴とする請求項１に記載の方法。
【請求項３】
前記マークアップ言語は、ＸＭＬであることを特徴とする請求項１に記載の方法。
【請求項４】
前記インタフェイスは、ユーザインタフェイスであることを特徴とする請求項１に記載の方法。
【請求項５】
カーソルが前記編集可能領域にある場合には、キーの押下により前記カーソルを次の編集可能領域に移動させることを特徴とする請求項１に記載の方法。
【請求項６】
前記キーは、右矢印キーであることを特徴とする請求項１に記載の方法。
【請求項７】
前記編集可能領域に何らの情報がない場合には、タグが自動で作成されることを特徴とする請求項１に記載の方法。
【請求項８】
マークアップ言語で記述された前記文書内にフラグメントが挿入された場合には、前記インタフェイス内に前記フラグメントに対応する編集可能領域が作成されることを特徴とする請求項１に記載の方法。
【請求項９】
前記マークアップ言語は、ＸＭＬであることを特徴とする請求項８に記載の方法。
【請求項１０】
マークアップ言語により記述された前記文書は、ＤＯＭで表現されていることを特徴とする請求項１に記載の方法。
【請求項１１】
前記フラグメントは、少なくとも一つのタグであることを特徴とする請求項８に記載の方法。
【請求項１２】
前記フラグメントは、少なくとも一つの属性であることを特徴とする請求項８に記載の方法。
【請求項１３】
前記フラグメントは、テキストであることを特徴とする請求項８に記載の方法。
【請求項１４】
前記フラグメントは、１以上のマークアップ言語のコンポーネントを含むことを特徴とする請求項８に記載の方法。
【請求項１５】
前記編集可能領域の設定により、前記タグや前記属性のどちらが作成されるかを決定することを特徴とする請求項１に記載の方法。
【請求項１６】
前記編集可能領域の設定により、マークアップ言語で記述された前記文書のどこに前記タグ又は前記属性が作成されるかを決定することを特徴とする請求項１に記載の方法。
【請求項１７】
ユーザがマークアップ言語で記述された文書の編集を行うためのシステムであって、
編集可能領域を有する表示部と、
前記編集可能領域が編集されたかどうかをもとに、マークアップ言語で記述された前記文書にタグ又は属性を追加する変換部と、
を備えることを特徴とするシステム。
【請求項１８】
前記編集可能領域に情報が追加された場合に限り、前記タグや前記属性を作成することを特徴とする請求項１７に記載のシステム。
【請求項１９】
前記マークアップ言語は、ＸＭＬであることを特徴とする請求項１７に記載のシステム。
【請求項２０】
カーソルが前記編集可能領域にある場合には、キーの押下により前記カーソルを次の編集可能領域に移動させることを特徴とする請求項１７に記載のシステム。
【請求項２１】
前記キーは、右矢印キーであることを特徴とする請求項２０に記載のシステム。
【請求項２２】
マークアップ言語で記述された第一の文書を編集することで、マークアップ言語で記述された第二の文書に変更を反映するシステムであって、
編集可能領域を有する、マークアップ言語で記述された前記第一の文書と、
前記編集可能領域が編集されたかどうかをもとに、マークアップ言語で記述された前記第二の文書にタグや属性を追加する変換部と、
を備えることを特徴とするシステム。
【請求項２３】
前記編集可能領域に情報が追加された場合に限り、前記タグや前記属性を作成することを特徴とする請求項２２に記載のシステム。
【請求項２４】
前記マークアップ言語はＸＭＬであることを特徴とする請求項２２に記載のシステム。
【請求項２５】
前記編集可能領域に何らの情報がない場合には、前記タグが自動で作成されることを特徴とする請求項１７に記載のシステム。
【請求項２６】
前記編集可能領域に何らの情報が提供されない場合には、前記タグが自動で作成されることを特徴とする請求項２２に記載のシステム。
【請求項２７】
カーソルが前記編集可能領域にある場合には、キーの押下により前記カーソルを次の編集可能領域に移動させることを特徴とする請求項２２に記載のシステム。
【請求項２８】
前記キーは、右矢印キーであることを特徴とする請求項２６に記載のシステム。
【請求項２９】
マークアップ言語で記述された前記文書内にフラグメントが挿入された場合には、前記表示部において前記フラグメントに対応する編集可能領域が作成されることを特徴とする請求項１７に記載のシステム。
【請求項３０】
前記マークアップ言語は、ＸＭＬであることを特徴とする請求項２８に記載のシステム。
【請求項３１】
マークアップ言語により記述された前記文書は、ＤＯＭで表現されていることを特徴とする請求項１７に記載のシステム。
【請求項３２】
前記フラグメントは、少なくとも一つのタグであることを特徴とする請求項２８に記載のシステム。
【請求項３３】
前記フラグメントは、少なくとも一つの属性であることを特徴とする請求項２８に記載のシステム。
【請求項３４】
前記フラグメントは、テキストであることを特徴とする請求項２８に記載のシステム。
【請求項３５】
前記フラグメントは、１以上のマークアップ言語のコンポーネントを含むことを特徴とする請求項２８に記載のシステム。
【請求項３６】
前記編集可能領域の設定により、前記タグや前記属性のどちらが作成されるかを決定することを特徴とする請求項１７に記載のシステム。
【請求項３７】
前記編集可能領域の設定により、マークアップ言語で記述された前記文書のどこに前記タグや前記属性が作成されるかを決定することを特徴とする請求項１７に記載のシステム。
【請求項３８】
当該システムはさらに、マークアップ言語により記述された前記文書に入力された情報をもとに、前記表示部に１つ以上の編集可能領域を作成する編集可能領域構成部を備えることを特徴とする請求項１７に記載のシステム。
【請求項３９】
タグや属性を作成するかどうかを決定する編集可能領域を備えることを特徴とする、マークアップ言語により構築されたインタフェイス。
【請求項４０】
ソース文書にタグや属性を作成するかどうかを決定する編集可能領域を備えることを特徴とする、ＸＭＬにより構築されたユーザインタフェイス。
【請求項４１】
前記編集可能領域に情報が追加された場合に限り、前記タグや前記属性を作成することを特徴とする請求項３８に記載のインタフェイス。
【請求項４２】
前記マークアップ言語は、ＸＭＬであることを特徴とする請求項３８に記載のインタフェイス。
【請求項４３】
インタフェイスは、ユーザインタフェイスであることを特徴とする請求項３８に記載のインタフェイス。
【請求項４４】
カーソルが前記編集可能領域にある場合には、キーの押下により前記カーソルを次の編集可能領域に移動させることを特徴とする請求項３８に記載のインタフェイス。
【請求項４５】
前記キーは、右矢印キーであることを特徴とする請求項４３に記載のシステム。
【請求項４６】
前記情報が追加される前に、前記編集可能領域に文字データが表示されることを特徴とする請求項４０に記載のインタフェイス。
【請求項４７】
前記情報は、文字データであることを特徴とする請求項３８に記載のインタフェイス。
【請求項４８】
前記情報が追加されると、前記文字データは消失することを特徴とする請求項４５に記載のインタフェイス。
【請求項４９】
前記編集可能領域に何らの情報が与えられない場合には、前記タグが自動で作成されることを特徴とする請求項３８に記載のインタフェイス。
【請求項５０】
マークアップ言語で記述された前記文書内にフラグメントが挿入された場合には、対応する編集可能領域が作成されることを特徴とする請求項３８に記載のインタフェイス。
【請求項５１】
前記マークアップ言語は、ＸＭＬであることを特徴とする請求項４９に記載のインタフェイス。
【請求項５２】
マークアップ言語により記述された前記文書は、ＤＯＭで表現されていることを特徴とする請求項３８に記載のインタフェイス。
【請求項５３】
前記フラグメントは、少なくとも一つのタグであることを特徴とする請求項４９に記載のインタフェイス。
【請求項５４】
前記フラグメントは、少なくとも一つの属性であることを特徴とする請求項４９に記載のインタフェイス。
【請求項５５】
前記フラグメントは、テキストであることを特徴とする請求項４９に記載のインタフェイス。
【請求項５６】
前記フラグメントは、１以上のマークアップ言語のコンポーネントを含むことを特徴とする請求項４９に記載のインタフェイス。
【請求項５７】
マークアップ言語を使用して、タグや属性を作成するための環境を構築する方法であって、
前記マークアップ言語を使用して、前記環境の一部として、編集可能領域を含むインタフェイスを構築する工程を備え、
前記編集可能領域は前記タグや前記属性を作成するかどうかを決定することを特徴とする方法。
【請求項５８】
前記編集可能領域への情報の追加により、前記タグや前記属性を作成するかどうかを決定することを特徴とする請求項５６に記載の方法。
【請求項５９】
前記マークアップ言語は、ＸＭＬであることを特徴とする請求項５６に記載の方法。
【請求項６０】
前記インタフェイスは、ユーザインタフェイスであることを特徴とする請求項５６に記載の方法。
【請求項６１】
カーソルが前記編集可能領域にある場合には、キーの押下により前記カーソルを次の編集可能領域に移動させることを特徴とする請求項５６に記載の方法。
【請求項６２】
前記キーは、右矢印キーであることを特徴とする請求項５６に記載の方法。
【請求項６３】
前記編集可能領域に何らの情報も与えられない場合には、前記タグが自動で作成されることを特徴とする請求項５６に記載の方法。
【請求項６４】
コンピュータを、マークアップ言語で記述された文書内にタグや属性を作成する手段として機能させるための命令を備えた、コンピュータ読み取り可能な記録媒体を含むコンピュータプログラム製品であって、
前記手段は、
インタフェイスの編集可能領域で情報を受け付ける手段と、
受け付けた情報をもとに、前記タグや前記属性を作成する手段と、
を含むことを特徴とするコンピュータプログラム製品。
【請求項６５】
前記情報を受け付けた場合に限り、前記タグや前記属性を作成することを特徴とする請求項６３に記載のコンピュータプログラム製品。
【請求項６６】
前記マークアップ言語はＸＭＬであることを特徴とする請求項６３に記載のコンピュータプログラム製品。
【請求項６７】
前記インタフェイスは、ユーザインタフェイスであることを特徴とする請求項６３に記載のコンピュータプログラム製品。
【請求項６８】
カーソルが前記編集可能領域にある場合には、キーの押下により前記カーソルを次の編集可能領域に移動させることを特徴とする請求項６３に記載のコンピュータプログラム製品。
【請求項６９】
前記キーは、右矢印キーであることを特徴とする請求項６３に記載のコンピュータプログラム製品。
【請求項７０】
前記編集可能領域に何らの情報も与えられない場合には、前記タグが自動で作成されることを特徴とする請求項６３に記載のコンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マークアップ言語で記述された文書内にタグまたは属性を作成するためのシステム、方法、インタフェイスに関する。マークアップ言語は例えばＸＭＬであってもよい。
【背景技術】
【０００２】
インターネットの出現により、ユーザによって処理され管理される文書の数が、ほぼ指数関数的に増加してきた。インターネットの核を形成するウェブ（World Wide Web）は、そのような文書データの大きな受け皿となっている。ウェブは、文書に加えて、このような文書の情報検索システムを提供する。これらの文書は、通常、マークアップ言語により記述される。マークアップ言語のシンプルかつポピュラーな例の一つにＨＴＭＬ（HyperText Markup Language）がある。このような文書は、ウェブの他の位置に格納されている他の文書へのリンクをさらに含む。ＸＭＬ（eXtensible Markup Language）は、さらに高度でポピュラーなマークアップ言語である。ウェブ文書にアクセスし、閲覧するためのシンプルなブラウザが、Ｊａｖａ（登録商標）のようなオブジェクト指向のプログラミング言語で開発されている。
【０００３】
マークアップ言語により記述された文書は、通常、ブラウザや他のアプリケーションの中では、ツリーデータ構造の形で表現される。この構造は、文書を構文解析した結果のツリーに相当する。ＤＯＭ（Document Object Model）は、文書を表現し、操作するために使用される、よく知られたツリーベースのデータ構造モデルである。ＤＯＭは、ＨＴＭＬやＸＭＬ文書などを含む文書を表現するための標準的なオブジェクトのセットを提供する。ＤＯＭは、文書内のコンポーネントを表現するオブジェクトがどのようにつながっているかという標準モデルと、それらのオブジェクトにアクセスしたり操作したりするための標準インタフェイスという、２つの基本的なコンポーネントを含む。
【０００４】
アプリケーション開発者は、独自のデータ構造やＡＰＩ（Application Program Interface）へのインタフェイスとしてＤＯＭをサポートすることができる。他方、文書を作成するアプリケーション開発者は、彼らのＡＰＩの独自インタフェイスではなく、ＤＯＭの標準インタフェイスを使用することができる。したがって、標準を提供するというその能力により、ＤＯＭは、様々な環境、特にウェブにおいて、文書の相互利用を促進させるために有効である。ＤＯＭのいくつかのバージョンが定義されており、異なるプログラミング環境及びアプリケーションによって使用されている。
【０００５】
ＤＯＭツリーは、対応するＤＯＭの内容に基づいた文書の階層的表現である。ＤＯＭツリーは「根（ルート）」、及びルートから発生する１つ以上の「節（ノード）」を含む。ルートが文書全体を表す場合もある。中間のノードは、例えば、テーブル及びそのテーブル中の行及び列のような要素を表すことができる。ＤＯＭツリーの「葉」は、通常、それ以上分解できないテキストや画像のようなデータを表す。ＤＯＭツリーの各ノードは、フォント、サイズ、色、インデントなど、ノードによって表される要素のパラメータを記述する属性に関連付けられてもよい。
【０００６】
ＨＴＭＬは、文書を作成するために一般に用いられる言語であるが、フォーマット及びレイアウト用の言語であり、データ記述のための言語ではない。ＨＴＭＬドキュメントを表現するＤＯＭツリーのノードは、ＨＴＭＬのフォーマッティングタグとして予め定義されたエレメントであって、通常、ＨＴＭＬは、データの詳述や、データのタギング／ラベリングのための機能を提供しないので、ＨＴＭＬドキュメント中のデータに対するクエリを定式化することは多くの場合困難である。
【０００７】
ネットワーク設計者たちの目指すものは、ウェブ上の文書がソフトウェアアプリケーションによってクエリされたり処理されたりできるようにすることである。表示方法とは無関係で、階層的に構造化された言語であれば、そのようにクエリされ処理されることができる。ＸＭＬ（eXtensible Markup Language）のようなマークアップ言語は、これらの機能を提供することができる。
【０００８】
ＨＴＭＬとは逆に、ＸＭＬのよく知られた利点は、文書の設計者が自由に定義可能な「タグ」を使用して、データ要素にラベルを付けることが可能である点である。このようなデータ要素は、階層的に構造化することができる。さらに、ＸＭＬ文書は、文書内で用いられるタグ及びそれらの相互関係の「文法」を記述した文書型定義を含むことができる。構造化されたＸＭＬ文書の表示方法を定義するために、ＣＳＳ（Cascading Style Sheet）又はＸＳＬ（XML Style Language）が使用される。ＤＯＭ、ＨＴＭＬ、ＸＭＬ、ＣＳＳ、ＸＳＬ及び関連する言語の特徴に関する付加的な情報は、ウェブからも得ることができる。（例えば、http://www.w3.org/TR/）
【０００９】
Ｘｐａｔｈは、ＸＭＬ文書の部分の位置を指定するために共通のシンタックス及びセマンティクスを提供する。機能性の例として、ＸＭＬ文書に対応するＤＯＭツリーのトラバース（移動）がある。それは、ＸＭＬ文書の様々な表現に関連した文字列、数、及びブーリアン文字の操作のための基本的な機能を提供する。Ｘｐａｔｈは、ＸＭＬ文書の見た目のシンタックス、例えば、テキストとしてみたときに何行目であるとか何文字目であるとかといった文法ではなく、ＤＯＭツリーなどの抽象的・論理的な構造において動作する。Ｘｐａｔｈを使用することにより、例えばＸＭＬ文書のＤＯＭツリー内の階層的構造を通じて場所を指定することができる。アドレシングのための使用の他に、Ｘｐａｔｈは、ＤＯＭツリー中のノードがパターンにマッチするか否かをテストするために使用されるようにも設計されている。
【００１０】
ＸＰａｔｈに関する更なる詳細は、http://www.w3.org/TR/xpathで得ることができる。
【００１１】
ＸＭＬの既知の利点及び特徴により、マークアップ言語（例えばＸＭＬ）で記述された文書を扱うことができ、文書を作成及び修正するためのユーザフレンドリーなインタフェイスを提供することができる、効果的な文書処理システムが求められる。
【００１２】
ＸＭＬは、複雑な文書のための、またネットワークなどを介して複数のドキュメントにまたがってデータを共有するのに特に適した形式である。ＸＭＬ文書を作成、表示、編集するための多くのアプリケーションが開発されている（たとえば、特許文献１参照）。
【特許文献１】特開２００１−２９０８０４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
ボキャブラリは、任意に定義することが許されており、理論上、無限に多くのボキャブラリが存在しうる。これらのボキャブラリの全てに対応して専用の表示・編集環境を提供するのは現実的ではない。従来、専用の編集環境が用意されていないボキャブラリにより記述された文書を編集する場合、テキストデータにより構成された文書のソースを直接テキストエディタなどで編集していた。
【００１４】
既存のアプリケーションは、処理・管理できるＸＭＬ文書に大きな制限があったため、幅広く文書を受け入れることができなかった。例えばＸＭＬ文書処理システムの中には、ＸＭＬ文書の中で、文書の内容を表し、表示メソッドとは関係ない文字列を表示することができるものがある。この機能は一見優れているようであるが、実際にはユーザがＸＭＬ文書を直接編集できないという不都合な点も持つ。この問題を解決するために、ＸＭＬ文書処理システムの中には、ＸＭＬの入力を受け付ける画面を特別にデザインするものもある。しかし、画面デザインの柔軟性は限られていた。それらのＸＭＬ文書処理システムにおいては、前述の画面デザインは事前にハードコーディングされている必要があったからである。
【００１５】
この制限を考慮して、ＸＳＬＴは標準的なスタイルシート言語の一つとして開発された。このような技術によりユーザはハードコーディングから解放され、ＸＭＬ文書を表示するために適用されるメソッドとも混在可能になった。しかし、ＸＳＬＴを使用しても、特定の形式のＸＭＬ文書の編集はできない場合があった。
【００１６】
さらに、それらのＸＭＬ文書処理システムは、「スキーマ」に定義された順序をあてにしている。そのため、一旦スキーマが決定されると、処理システムで処理可能なのは、そのスキーマの構造に最上位から合致するＸＭＬ文書のみであった。換言すると、それらのシステムは過度に制限的で柔軟性を欠いている。
【課題を解決するための手段】
【００１７】
今回開示するシステムは、前述のような制限が無い。完全なＸＭＬ文書の構造は固定的に決定される必要はない。様々な構造が複合したＸＭＬ文書であっても、ＸＭＬ文書をより小さな部分に分割して安全に処理できる。それぞれの小さい部分は、より柔軟性を高めるため、個別に編集モジュールに振り分けられる。加えて、編集モジュールは、プラグインとして提供されるのが望ましい。さらにユーザは、何らのハードコーディングをすることなく柔軟性のある画面デザインを実装できる。いわゆるＷＹＳＩＷＹＧ（What You See Is What You Get）を実現できる。
【００１８】
ここで説明されるシステムの構成のうちのいくつかは、ＭＶＣ（Model-View-Controller）と呼ばれる、よく知られたＧＵＩ（Graphical User Interface）パラダイムを用いて説明される。ＭＶＣパラダイムは、アプリケーション又はアプリケーションのインタフェイスの一部を、３つの部分、すなわち、モデル、ビュー、コントローラに分割する。ＭＶＣは、元は、ＧＵＩの世界に、従来の入力、処理、出力の役割を割り当てるために開発された。
【００１９】
［入力］ → ［処理］ → ［出力］
【００２０】
［コントローラ］→ ［モデル］ → ［ビュー］
【００２１】
ＭＶＣパラダイムによれば、外界のモデリング、ユーザへの視覚的なフィードバック、及びユーザの入力は、モデル（Ｍ）、ビュー（Ｖ）、及びコントローラ（Ｃ）オブジェクトにより分離されて扱われる。コントローラは、ユーザからのマウスとキーボード入力のような入力を解釈し、これらのユーザアクションを、適切な変更をもたらすためにモデル及び／又はビューに送られるコマンドにマップするように作用する。モデルは、１以上のデータ要素を管理するように作用し、その状態に関するクエリに応答し、状態を変更する指示に応答する。ビューは、ディスプレイの長方形の領域を管理するように作用し、グラフィクスとテキストの組合せによりユーザにデータを提示する機能を有する。
【００２２】
ＸＭＬに必要な要素を入力する際、従来の方法ではテキストのない要素を作成し、その中にテキストを追加する。この方法にはユーザが文書を保存するときに、この空の要素もファイルに出力されるという負の副作用がある。従来の技術では、ユーザがその要素に対応するテキストフィールドにテキストを入力するかどうかに関わらず、要素が事前に作成される。そのため、要素に対応するテキストフィールドが不必要に作成され、事前に作成された要素がメモリ領域を占有することもある。
【００２３】
本発明の典型的な実施形態によれば、マークアップ言語で記述された文書内にタグまたは属性を作成する方法であって、インタフェイスの編集可能領域内の情報を受け付け、その情報をもとにタグまたは属性を作成することを含む方法を、本発明は提供する。
【００２４】
また、典型的な実施形態によれば、マークアップ言語で記述された文書をユーザが編集するためのシステムであって、編集可能領域を有する表示部と、前記編集可能領域が編集されたかどうかをもとにマークアップ言語で記述された文書にタグまたは属性を追加する変換部を含むことを特徴とするシステムを、本発明は提供する。
【００２５】
さらに、典型的な実施形態によれば、マークアップ言語に基づき構築されたインタフェイスであって、タグや属性を作成するかどうかを決定する編集可能領域を含むインタフェイスを、本発明は提供する。
【００２６】
さらに、典型的な実施形態によれば、ＸＭＬに基づき構築されたユーザインタフェイスであって、ソース文書にタグまたは属性を作成するかどうかを決定する編集可能領域を含むユーザインタフェイスを、本発明は提供する。
【００２７】
さらに、典型的な実施形態によれば、タグまたは属性を作成するための環境を、マークアップ言語を用いて作成する方法であって、タグまたは属性を作成するかどうかを決定する編集可能領域を有するインタフェイスを、構築された環境の一部として、前記マークアップ言語を用いて作成することを含む方法を、本発明は提供する。
【００２８】
最後に、この開示の中で説明した技術をコンピュータに実現させるための命令を備えた、コンピュータ読み取り可能な記録媒体を含むコンピュータプログラム製品も、開示した教示内容の他の態様として含んでいる。
【発明を実施するための最良の形態】
【００２９】
以下に、添付した図面を参照して、開示される教示の詳細な実施例を説明する。
【００３０】
本発明の境界は特許請求の範囲のみが表現する。実施例及び効果は単なる例示であり、本発明を限定するために解釈されるべきではない。開示される教示は説明を意図しており、特許請求の範囲を限定することを意図していない。種々の代替例、修正例、変更例は、当業者には明らかである。
【００３１】
Ａ．文書処理システムの全体構成
図１（ａ）は、後述するタイプの文書処理システムの基礎として機能する要素の標準的な構成例を示す。構成１０は、通信経路によりメモリ１２に接続されたＣＰＵ又はマイクロプロセッサ１１などの形式のプロセッサを含む。メモリ１２は、現在又は将来に利用可能な任意のＲＯＭ及び／又はＲＡＭの形式であってもよい。通信経路は、典型的にはバスとして設けられる。マウス、キーボード、音声認識システムなどのユーザ入力装置１４及び表示装置１５（又は他のユーザインタフェイス）に対する入出力インタフェイス１６も、プロセッサ１１とメモリ１２の通信のためのバスに接続される。この構成は、スタンドアロンであってもよいし、複数の端末及び１以上のサーバが接続されてネットワーク化された形式であってもよいし、既知のいかなる方式により構成されてもよい。本発明は、これらのコンポーネントの配置、集中又は分散されたアーキテクチャー、あるいは様々なコンポーネントの通信方法により制限されない。
【００３２】
さらに、本システム及びここで議論される実施例は、様々な機能性を提供するいくつかのコンポーネント及びサブコンポーネントを含むものとして議論される。これらのコンポーネント及びサブコンポーネントは、注目された機能性を提供するために、ハードウェアとソフトウェアの組合せだけでなく、ハードウェアのみ、ソフトウェアのみによっても実現されうる。さらに、ハードウェア、ソフトウェア、及びそれらの組合せは、汎用の計算装置、専用のハードウェア、又はそれらの組合せにより実現されうる。したがって、コンポーネント又はサブコンポーネントの構成は、コンポーネント又はサブコンポーネントの機能性を提供するための特定のソフトウェアを実行する汎用／専用の計算装置を含む。
【００３３】
図１（ｂ）は、文書処理システムの一例の全体のブロック図を示す。このような文書処理システムにおいて文書が生成され編集される。これらの文書は、例えばＸＭＬなど、マークアップ言語の特徴を有する任意の言語により記述されてもよい。また、便宜上、特定のコンポーネント及びサブコンポーネントの用語及び表題を創造した。しかしながら、これらは、この開示の一般的な教示の範囲を制限するために解釈されるべきではない。
【００３４】
文書処理システムは、２つの基本的な構成を有するものととらえることができる。第１の構成は、文書処理システムが動作する環境である「実行環境」１０１である。例えば、実行環境は、文書の処理中及び管理中に、ユーザだけでなくシステムも支援する、基本的なユーティリティ及び機能を提供する。第２の構成は、図１（ｃ）に示す、実行環境において走るアプリケーションから構成される「アプリケーション」１０２である。これらのアプリケーションは、文書自身及び文書の様々な表現を含む。
【００３５】
１．実行環境
実行環境１０１のキーとなるコンポーネントはProgramInvoker（プログラムインボーカ：プログラム起動部）１０３である。ProgramInvoker１０３は、文書処理システムを起動するためにアクセスされる基本的なプログラムである。例えば、ユーザが文書処理システムにログオンして開始するとき、ProgramInvoker１０３が実行される。ProgramInvoker１０３は、例えば、文書処理システムにプラグインとして加えられた機能を読み出して実行させたり、アプリケーションを開始して実行させたり、文書に関連するプロパティを読み出すことができる。ProgramInvoker１０３の機能はこれらに限定されない。ユーザが実行環境内で実行されるように意図されたアプリケーションを起動したいとき、ProgramInvoker１０３は、そのアプリケーションを見つけ、それを起動して、アプリケーションを実行する。例えばユーザが文書（実行環境ではアプリケーションとして扱われる）を編集したいときには、ProgramInvoker１０３は最初にその文書を発見し、文書を展開し、編集するために必要な機能を実行する。
【００３６】
ProgramInvoker１０３には、プラグインサブシステム１０４、コマンドサブシステム１０５、及びResource（リソース）モジュール１０９などのいくつかのコンポーネントがアタッチされている。これらの構成については、以下に詳述する。
【００３７】
ａ）プラグインサブシステム
プラグインサブシステム１０４は、文書処理システムに機能を追加するための高度に柔軟で効率的な構成として使用される。プラグインサブシステム１０４は、また、文書処理システムに存在する機能を修正又は削除するために使用することができる。さらに、種々様々の機能をプラグインサブシステムを使用して追加又は修正することができる。例えば、画面上への文書の描画を支援するように作用するEditlet（エディットレット：編集部）機能を追加することもできる。Editletプラグインは、システムに追加されるボキャブラリの編集も支援する。
【００３８】
プラグインサブシステム１０４は、ServiceBroker（サービスブローカ：サービス仲介部）１０４１を含む。ServiceBroker１０４１は、文書処理システムに加えられるプラグインを管理することにより、文書処理システムに加えられるサービスを仲介する。
【００３９】
所望の機能性を実現する個々の機能は、Service（サービス）１０４２の形でシステムに追加される。利用可能なService１０４２のタイプは、Application（アプリケーション）Service、ZoneFactory（ゾーンファクトリ：ゾーン生成部）Service、Editlet（エディットレット：編集部）Service、CommandFactory（コマンドファクトリ：コマンド生成部）Service、ConnectXPath（コネクトＸＰａｔｈ：ＸＰａｔｈ管理部）Service、CSSComputation（ＣＳＳコンピューテーション：ＣＳＳ計算部）Serviceなどを含むが、これらに限定されない。これらのService、及びシステムの他の構成とそれらとの関係は、文書処理システムについてのよりよい理解のために、以下に詳述される。
【００４０】
プラグインとServiceの関係は以下の通りである。プラグインは、１以上のServiceProvider（サービスプロバイダ：サービス提供部）を含むことができるユニットである。それぞれのServiceProviderは、それに関連したServiceの１以上のクラスを有する。例えば、適切なソフトウェアアプリケーションを有する単一のプラグインを使用することにより、１以上のServiceをシステムに追加することができ、これにより、対応する機能をシステムに追加することができる。
【００４１】
ｂ）コマンドサブシステム
コマンドサブシステム１０５は、文書の処理に関連したコマンドの形式の命令を実行するために使用される。ユーザは、一連の命令を実行することにより、文書に対する操作を実行することができる。例えば、ユーザは、コマンドの形で命令を発行することにより、文書処理システム中のＸＭＬ文書に対応するＸＭＬのＤＯＭツリーを編集し、ＸＭＬ文書を処理する。これらのコマンドは、キーストローク、マウスクリック、又は他の有効なユーザインタフェイスアクションを使用して入力されてもよい。１つのコマンドにより１以上の命令が実行されることもある。この場合、これらの命令が１つのコマンドにラップ（包含）され、連続して実行される。例えば、ユーザが、誤った単語を正しい単語に置換したいとする。この場合、第１の命令は、文書中の誤った単語を発見することであり、第２の命令は、誤った単語を削除することであり、第３の命令は、正しい単語を挿入することであってもよい。これらの３つの命令が１つのコマンドにラップされてもよい。
【００４２】
コマンドは、関連した機能、例えば、後で詳述する「アンドゥ」機能を有してもよい。これらの機能は、オブジェクトを生成するために使用されるいくつかの基本クラスにも割り当てられてもよい。
【００４３】
コマンドサブシステム１０５のキーとなるコンポーネントは、選択的にコマンドを与え、実行するように作用するCommandInvoker（コマンドインボーカ：コマンド起動部）１０５１である。図１（ｂ）には、１つのCommandInvokerのみが示されているが、１以上のCommandInvokerが使用されてもよく、１以上のコマンドが同時に実行されてもよい。CommandInvoker１０５１は、コマンドを実行するために必要な機能及びクラスを保持する。動作において、実行されるべきCommand（コマンド：命令）１０５２は、Queue（キュー）１０５３に積まれる。CommandInvokerは、連続的に実行するコマンドスレッドを生成する。CommandInvoker内で既に実行中のCommandがなければ、CommandInvoker１０５１により実行されるように意図されたCommand１０５２が実行される。CommandInvokerが既にコマンドを実行している場合、新しいCommandは、Queue１０５３の最後に積まれる。しかしながら、それぞれのCommandInvoker１０５１では、一度に１つのCommandのみが実行される。指定されたCommandの実行に失敗した場合、CommandInvoker１０５１は例外処理を実行する。
【００４４】
CommandInvoker１０５１により実行されるCommandの型は、UndoableCommand（取消可能コマンド）１０５４、AsynchronousCommand（非同期コマンド）１０５５、及びVCCommand（ＶＣコマンド）１０５６を含むが、これらに限定されない。UndoableCommand１０５４は、ユーザが望めば、そのCommandの結果を取り消すことが可能なCommandである。UndoableCommandの例として、切り取り、コピー、テキストの挿入、などがある。動作において、ユーザが文書の一部を選択し、その部分に切り取りコマンドを適用するとき、UndoableCommandを用いることにより、切り取られた部分は、必要であれば、「切り取られていない」ようにすることができる。
【００４５】
VCCommand１０５６は、ボキャブラリコネクション記述子（Vocabulary Connection Descriptor：ＶＣＤ）スクリプトファイルに格納される。これらは、プログラマにより定義されうるユーザ指定のCommandである。Commandは、例えば、ＸＭＬフラグメントを追加したり、ＸＭＬフラグメントを削除したり、属性を設定したりするための、より抽象的なCommandの組合せであってもよい。これらのCommandは、特に、文書の編集に焦点を合わせている。
【００４６】
AsynchronousCommand１０５５は、文書のロードや保存など、システムよりのCommandであり、UndoableCommandやVCCommandとは別に、非同期的に実行される。AsynchronousCommandは、UndoableCommandではないので、取り消すことはできない。
【００４７】
AsynchronousCommands１０５５は、ボキャブラリコネクションの下位のレベルに存在する。それらは文書処理システムに対するより特別なコマンドである。AsynchronousCommandsはCommandInvoker１０５１に直接届けられる。一方で、VocabularyConnectionCommands１０５６は解釈され、AsynchronousCommandsに変換されたのち、CommandInvoker１０５１に届けられる。
【００４８】
ｃ）リソース
Resource１０９は、様々なクラスに、いくつかの機能を提供するオブジェクトである。例えば、ストリングリソース、アイコン、及びデフォルトキーバインドは、システムで使用されるResourceの例である。
【００４９】
２．アプリケーションコンポーネント
文書処理システムの第２の主要な特徴であるアプリケーションコンポーネント１０２は、実行環境１０１において実行される。アプリケーションコンポーネント１０２は、実際の文書と、システム内における文書の様々な論理的、物理的な表現を含む。さらに、アプリケーションコンポーネント１０２は、文書を管理するために使用されるシステムの構成を含む。アプリケーションコンポーネント１０２は、さらに、UserApplication（ユーザアプリケーション）１０６、アプリケーションコア１０８、ユーザインタフェイス１０７、及びCoreComponent（コアコンポーネント）１１０を含む。
【００５０】
ａ）ユーザアプリケーション
UserApplication１０６は、ProgramInvoker１０３と共にシステム上にロードされる。UserApplication１０６は、文書と、文書の様々な表現と、文書と対話するために必要なユーザインタフェイスとをつなぐ接着剤となる。例えば、ユーザが、プロジェクトの一部である文書のセットを生成したいとする。これらの文書がロードされると、文書の適切な表現が生成される。ユーザインタフェイス機能は、UserApplication１０６の一部として追加される。言いかえれば、UserApplication１０６は、ユーザがプロジェクトの一部を形成する文書と対話することを可能とする文書の表現と、文書の様々な態様とを、共に保持する。一旦UserApplication１０６が生成されると、ユーザがプロジェクトの一部を形成する文書との対話を望むたびに、ユーザは簡単に実行環境上にUserApplication１０６をロードすることができる。
【００５１】
ｂ）コアコンポーネント
CoreComponent１１０は、複数のPane（ペイン）の間で文書を共有する方法を提供する。後で詳述するように、Paneは、ＤＯＭツリーを表示し、画面の物理的なレイアウトを扱う。例えば、物理的な画面は、個々の情報の断片を描写する画面内の複数のPaneからなる。ユーザから画面上に見える文書は、１又はそれ以上のPaneに出現しうる。また、２つの異なる文書が画面上で２つの異なるPaneに現れてもよい。
【００５２】
図１（ｃ）に示されるように、画面の物理的なレイアウトもツリーの形式になっている。Paneは、RootPane（ルートペイン）１０８４にもなり得るし、SubPane（サブペイン）１０８５にもなり得る。RootPane１０８４は、Paneのツリーの根に当たるPaneであり、SubPane１０８５は、RootPane１０８４以外の任意のPaneである。
【００５３】
CoreComponent１１０は、さらに、フォントを提供し、ツールキットなど、文書のための複数の機能的な操作のソースの役割を果たす。CoreComponent１１０により実行されるタスクの一例に、複数のPane間におけるマウスカーソルの移動がある。実行されるタスクの他の例として、あるPane中の文書の一部をマークし、それを異なる文書を含む別のPane上にコピーする。
【００５４】
ｃ）アプリケーションコア
上述したように、アプリケーションコンポーネント１０２は、システムにより処理され管理される文書から構成される。これは、システム内における文書の様々な論理的及び物理的な表現を含む。アプリケーションコア１０８は、アプリケーションコンポーネント１０２の構成である。その機能は、実際の文書を、それに含まれる全てのデータとともに保持することである。アプリケーションコア１０８は、DocumentManager（ドキュメントマネージャ：文書管理部）１０８１及びDocument（ドキュメント：文書）１０８２自身を含む。
【００５５】
DocumentManager１０８１の様々な態様を以下に詳述する。DocumentManager１０８１は、Document１０８２を管理する。DocumentManager１０８１は、RootPane１０８４、SubPane１０８５、ClipBoard（クリップボード）ユーティリティ１０８６、及びSnapShot（スナップショット）ユーティリティ１０８７にも接続される。ClipBoardユーティリティ１０８６は、ユーザがクリップボードに加えることを決定した文書の部分を保持する方法を提供する。例えば、ユーザが、文書の一部を切り取り、後で再考するために新規文書にそれを保存することを望んだとする。このような場合、切り取られた部分がClipBoardに追加される。
【００５６】
つづいて、SnapShotユーティリティ１０８７についても説明する。SnapShotユーティリティ１０８７は、アプリケーションがある状態から別の状態まで移行するときに、アプリケーションの現在の状態を記憶することを可能とする。
【００５７】
ｄ）ユーザインタフェイス
アプリケーションコンポーネント１０２の別の構成は、ユーザがシステムと物理的に対話する手段を提供するユーザインタフェイス１０７である。例えば、ユーザインタフェイスは、ユーザが文書をアップロードしたり、削除したり、編集したり、管理したりするために使用される。ユーザインタフェイスは、Frame（フレーム）１０７１、MenuBar（メニューバー）１０７２、StatusBar（ステータスバー）１０７３、及びURLBar（ＵＲＬバー）１０７４を含む。
【００５８】
Frame１０７１は、一般に知られているように、物理的な画面のアクティブな領域であると考えてもよい。MenuBar１０７２は、ユーザに選択を提供するメニューを含む画面領域である。StatusBar１０７３は、アプリケーションの実行状態を表示する画面領域である。URLBar１０７４は、インターネットをナビゲートするためにＵＲＬアドレスを入力する領域を提供する。
【００５９】
Ｂ．文書管理及び関連するデータ構造
図２は、DocumentManager１０８１の詳細を示す。これは、文書処理システム内で文書を表現するために用いられるデータ構造及び構成を含む。分かりやすくするために、このサブセクションで説明される構成は、ＭＶＣパラダイムを用いて説明される。
【００６０】
DocumentManager１０８１は、文書処理システム内にある全ての文書を保持しホストするDocumentContainer（ドキュメントコンテナ：文書コンテナ）２０３を含む。DocumentManager１０８１にアタッチされたツールキット２０１は、DocumentManager１０８１により使用される様々なツールを提供する。例えば、DomService（ＤＯＭサービス）は、文書に対応するＤＯＭを生成し、保持し、管理するために必要とされる全ての機能を提供するために、ツールキット２０１により提供されるツールである。ツールキット２０１により提供される別のツールであるIOManager（入出力管理部）は、システムへの入力及びシステムからの出力を管理する。同様に、StreamHandler（ストリームハンドラ）は、ビットストリームによる文書のアップロードを扱うツールである。これらのツールは、図中に特に示さず、参照番号を割り当てないが、ツールキット２０１のコンポーネントを形成する。
【００６１】
ＭＶＣパラダイムの表現によれば、モデル（Ｍ）は、文書のＤＯＭツリーモデル２０２を含む。前述したように、全ての文書は、文書処理システムにおいてＤＯＭツリーとして表現される。文書は、また、DocumentContainer２０３の一部を形成する。
【００６２】
１．ＤＯＭモデル及びゾーン
ＤＯＭはＷ３Ｃが策定した標準規格であり、Nodeを操作するための標準的なインタフェイスを定義するが、実際には、ボキャブラリごと又はNodeごとに特有の操作があるので、これらの操作をＡＰＩとして用意しておくのが好都合である。文書処理システムでは、このような各Nodeに特有のＡＰＩをFacetとして用意し、各Nodeにアタッチする。これにより、ＤＯＭの標準規格に準拠しつつ、有用なＡＰＩを付加することができる。また、ボキャブラリごとに特有のＤＯＭを実装するのではなく、標準的なＤＯＭの実装に、後から特有のＡＰＩを付加するようにすることで、多様なボキャブラリを統一的に処理することができるともに、複数のボキャブラリが任意の組合せで混在した文書を適切に処理することができる。標準的にはＤＯＭはＤＯＭツリー形式で表現される。
【００６３】
文書を表現するＤＯＭツリーは、Node（ノード）２０２１を有するツリーである。ＤＯＭツリーの部分集合であるZone（ゾーン）２０９は、ＤＯＭツリー内の１以上のNodeの関連領域を含む。例えば、画面上で文書の一部のみを表示し得るが、この可視化された文書の一部はZone２０９を用いて表示される。Zoneは、ZoneFactory（ゾーンファクトリ：ゾーン生成部）２０５と呼ばれるプラグインを用いて、生成され、取り扱われ、処理される。ZoneはＤＯＭの一部を表現するが、１以上の「名前空間」を使用してもよい。よく知られているように、名前空間は、名前空間内でユニークな名前の集合である。換言すれば、名前空間内に同じ名前は存在しない。
【００６４】
２．Facet及びFacetとZoneとの関係
Facet（ファセット）２０２２は、ＭＶＣパラダイムのモデル（Ｍ）部分内の別の構成である。Facetは、ZoneにおいてNodeを編集するために使用される。Facet２０２２は、Zone自身の内容に影響を与えずに実行することができる手続（プロシージャ）を使用して、ＤＯＭへのアクセスを編成する。次に説明するように、これらの手続は、Nodeに関連した重要で有用な操作を実行する。
【００６５】
各Node２０２１は、対応するFacet２０２２を有する。ＤＯＭの中のNodeを直接操作する代わりに、操作を実行するためにFacetを使用することによって、ＤＯＭの保全性は保護される。そうでなく、操作がNode上で直接実行される場合、いくつかのプラグインがＤＯＭを同時に変更することができ、その結果矛盾を引き起こす。
【００６６】
ボキャブラリは、名前空間に属するタグ（例えばＸＭＬのタグ）のセットである。上述したように、名前空間は、ユニークな名前（ここではタグ）のセットを有する。ボキャブラリは、ＸＭＬ文書を表現するＤＯＭツリーのサブツリーとして現れる。このサブツリーはZoneを含む。特定の例においては、タグセットの境界はZoneによって定義される。Zone２０９は、ZoneFactory２０５と呼ばれるServiceを利用して生成される。上述したように、Zone２０９は、文書を表現するＤＯＭツリーの一部の内部表現である。このような文書の一部へのアクセスを提供するために、論理的な表現が要求される。この論理的表現は、文書が画面上で論理的にどのように表現されるかについてコンピュータに通知する。Canvas（キャンバス）２１０は、Zoneに対応する論理的なレイアウトを提供するように作用するServiceである。
【００６７】
他方、Pane２１１は、Canvas２１０により提供される論理的なレイアウトに対応する物理的な画面レイアウトである。実際、ユーザは表示画面上で文字や画像によって文書のレンダリングのみを見る。したがって、文書は、画面上に文字や画像を描画するプロセスにより、画面上に描写されなければならない。文書は、Pane２１１により提供される物理的なレイアウトに基づいて、Canvas２１０により画面上に描写される。
【００６８】
Zone２０９に対応するCanvas２１０は、Editlet２０６を使用して生成される。文書のＤＯＭは、Editlet２０６及びCanvas２１０を使用して編集される。元の文書の完全性を維持するために、Editlet２０６及びCanvas２１０は、Zone２０９における１以上のNodeに対応するFacetを使用する。これらのServiceは、Zone及びＤＯＭ内のNodeを直接操作しない。Facetは、Command２０７を利用して操作される。
【００６９】
ユーザは、一般に、画面上のカーソルを移動させたり、コマンドをタイプしたりすることによって、画面と対話する。画面上の論理的なレイアウトを提供するCanvas２０１０は、このカーソル操作を受け付ける。Canvas２０１０は、対応するアクションをFacetに実行させることができる。この関係により、カーソルサブシステム２０４は、DocumentManager１０８１に対して、ＭＶＣパラダイムのコントローラ（Ｃ）として機能する。Canvas２０１０は、イベントを扱うタスクも有する。例えば、Canvas２０１０は、マウスクリック、フォーカス移動、及びユーザにより起こされた同様のアクションなどのイベントを扱う。
【００７０】
３．Zone、Facet、Canvas及びPaneの間の関係の概要
文書処理システム内の文書は、少なくとも４つの観点から見ることができる。すなわち、１）文書処理システムにおいて文書の内容及び構造を保持するために用いられるデータ構造、２）文書の保全性に影響を与えずに文書の内容を編集する手段、３）文書の画面上の論理的なレイアウト、４）文書の画面上の物理的なレイアウト、である。Zone、Facet、Canvas及びPaneは、前述の４つの観点に相当する、文書処理システムのコンポーネントをそれぞれ表す。
【００７１】
４．アンドゥサブシステム
上述したように、文書に対するいかなる変更（例えば編集）も取消可能であることが望ましい。例えば、ユーザが編集操作を実行し、次に、その変更の取消を決定したとする。図２に関連して、アンドゥサブシステム２１２は、文書管理部の取消可能なコンポーネントを実現する。UndoManager（アンドゥマネージャ：アンドゥ管理部）２１２１は、ユーザによって取り消される可能性のある全ての文書に対する操作を保持する。
【００７２】
例えば、ユーザが、文書中の単語を別の単語に置換するコマンドを実行したとする。その後、ユーザは考え直し、元の単語に戻すことを決定したとする。アンドゥサブシステム２１２は、このような操作を支援する。UndoManager２１２１は、このようなUndoableEdit（アンドゥアブルエディット：取消可能な編集）２１２２の操作を保持する。
【００７３】
５．カーソルサブシステム
前述したように、ＭＶＣのコントローラ部分は、カーソルサブシステム２０４を備えてもよい。カーソルサブシステム２０４は、ユーザから入力を受け付ける。これらの入力は、一般にコマンド及び／又は編集操作の性格を有している。したがって、カーソルサブシステム２０４は、DocumentManager１０８１に関連したＭＶＣパラダイムのコントローラ（Ｃ）部分であると考えることができる。
【００７４】
６．ビュー
前述したように、Canvas２０１０は、画面上に提示されるべき文書の論理的なレイアウトを表す。ＸＨＴＭＬ文書の例では、Canvasは、文書が画面上でいかに見えるかを論理的に表現したボックスツリー２０８を含んでもよい。このボックスツリー２０８は、DocumentManager１０８１に関連したＭＶＣパラダイムのビュー（Ｖ）部分に含まれよう。
【００７５】
Ｃ．ボキャブラリコネクション
文書処理システムの重要な特徴は、ＸＭＬ文書を、他の表現にマップして取り扱うことが可能で、かつ、マップした先の表現を編集すると、その編集が元のＸＭＬ文書に整合性を保ちつつ反映される環境を提供することにある。
【００７６】
マークアップ言語により記述された文書、例えばＸＭＬ文書は、文書型定義により定義されたボキャブラリに基づいて作成されている。ボキャブラリは、タグのセットである。ボキャブラリは、任意に定義されてもよいため、無限に多くのボキャブラリが存在しうる。しかしながら、多数の可能なボキャブラリのそれぞれに対して専用の処理／管理環境を提供するのは現実的ではない。ボキャブラリコネクションは、この問題を解決する方法を提供する。
【００７７】
例えば、文書は２以上のマークアップ言語により記述されてもよい。文書は、例えば、ＸＨＴＭＬ（eXtensible HyperText Markup Language）、ＳＶＧ（Scalable Vector Graphics）、ＭａｔｈＭＬ（Mathematical Markup Language）、その他のマークアップ言語により記述されてもよい。換言すれば、マークアップ言語は、ＸＭＬにおけるボキャブラリやタグセットと同様に見なされてもよい。
【００７８】
ボキャブラリは、ボキャブラリプラグインを用いて処理される。文書処理システムにおいてプラグインが利用不可能であるボキャブラリにより記述された文書は、プラグインが利用可能である別のボキャブラリの文書にマッピングすることにより表示される。この特徴により、プラグインが用意されていないボキャブラリの文書も適切に表示することができる。
【００７９】
ボキャブラリコネクションは、定義ファイルを取得し、取得した定義ファイルに基づいて２つの異なるボキャブラリの間でマッピングする能力を含む。あるボキャブラリで記述された文書は、別のボキャブラリにマッピングすることができる。このように、ボキャブラリコネクションは、文書がマッピングされるボキャブラリに対応した表示／編集プラグインにより文書を表示し編集することを可能にする。
【００８０】
上述したように、各文書は、一般に複数のノードを有するＤＯＭツリーとして文書処理システムにおいて記述される。「定義ファイル」は、それぞれのノードについて、そのノードと他のノードとの対応を記述する。各ノードの要素値及び属性値が編集可能か否かが指定される。ノードの要素値又は属性値を用いた演算式が記述されてもよい。
【００８１】
マッピングという特徴を利用して、定義ファイルを適用したデスティネーションＤＯＭツリーが生成される。このように、ソースＤＯＭツリーとデスティネーションＤＯＭツリーの関係が構築され保持される。ボキャブラリコネクションは、ソースＤＯＭツリーとデスティネーションＤＯＭツリーの対応を監視する。ユーザから編集指示を受けると、ボキャブラリコネクションは、ソースＤＯＭツリーの関連したノードを変更する。ソースＤＯＭツリーが変更されたことを示す「ミューテーションイベント」が発行され、デスティネーションＤＯＭツリーがそれに応じて変更される。
【００８２】
ボキャブラリコネクションの使用により、少数のユーザのみに知られていた比較的マイナーなボキャブラリを、別のメジャーなボキャブラリに変換することができる。したがって、少数のユーザによって利用されるマイナーなボキャブラリであっても、文書を適切に表示し、望ましい編集環境を提供することができる。
【００８３】
このように、文書処理システムの一部であるボキャブラリコネクションサブシステムは、文書の複数の表現を可能にする機能を提供する。
【００８４】
図３は、ボキャブラリコネクション（ＶＣ：Vocabulary Connection）サブシステム３００を示す。ＶＣサブシステム３００は、同一の文書の２つの代替表現の整合性を維持する方法を提供する。例えば、２つの表現は、同一文書の、２つの異なるボキャブラリによる表現であってもよい。前述したように、一方はソースＤＯＭツリーであってもよく、他方はデスティネーションＤＯＭツリーであってもよい。
【００８５】
１．ボキャブラリコネクションサブシステム
ボキャブラリコネクションサブシステム３００の機能は、VocabularyConnection３０１と呼ばれるプラグインを使用して、文書処理システムにおいて実現される。文書が表現されるVocabulary３０５ごとに、対応するプラグインが要求される。例えば、文書の一部がＨＴＭＬで記述され、残りがＳＶＧで記述されている場合、ＨＴＭＬとＳＶＧに対応するボキャブラリプラグインが要求される。
【００８６】
VocabularyConnectionプラグイン３０１は、適切なVocabulary３０５の文書に対応した、Zone２０９又はPane２１１のための適切なVCCanvas（ボキャブラリコネクションキャンバス）３１０を生成する。VocabularyConnection３０１を用いて、ソースＤＯＭツリー内のZone２０９に対する変更は、変換ルールにより、別のＤＯＭツリー３０６の対応するZoneに伝達される。変換ルールは、ボキャブラリコネクション記述子（Vocabulary Connection Descriptor：ＶＣＤ）の形式で記述される。このようなソースＤＯＭとデスティネーションＤＯＭの間の変換に対応するそれぞれのＶＣＤファイルについて、対応するVCManager（ボキャブラリコネクションマネージャ）３０２が生成される。
【００８７】
２．Connector
Connector３０４は、ソースＤＯＭツリーのソースノードと、デスティネーションＤＯＭツリーのデスティネーションノードとを接続する。Connector３０４は、ソースＤＯＭツリー中のソースノード、及びソースノードに対応するソース文書に対する修正（変更）を見るために作用する。そして、対応するデスティネーションＤＯＭツリーのノードを修正する。Connector３０４は、デスティネーションＤＯＭツリーを修正することができる唯一のオブジェクトである。例えば、ユーザは、ソース文書、及び対応するソースＤＯＭツリーに対してのみ修正を行うことができる。その後、Connector３０４がデスティネーションＤＯＭツリーに、対応する修正を行う。
【００８８】
Connector３０４は、ツリー構造を形成するために、論理的にリンクされる。Connector３０４により形成されたツリーは、ConnectorTree（コネクタツリー）と呼ばれる。Connector３０４は、ConnectorFactory（コネクタファクトリ：コネクタ生成部）３０３と呼ばれるServiceを用いて生成される。ConnectorFactory３０３は、ソース文書からConnector３０４を生成し、それらをリンクしてConnectorTreeを形成する。VocabularyConnectionManager３０２は、ConnectorFactory３０３を保持する。
【００８９】
前述したように、ボキャブラリは名前空間におけるタグのセットである。図示されるように、Vocabulary３０５は、VocabularyConnection３０１によって文書に対して生成される。これは、文書ファイルを解析し、ソースＤＯＭとデスティネーションＤＯＭの間の写像のための適切なVocabularyConnectionManager３０２を生成することにより行われる。さらに、Connectorを生成するConnectorFactory３０３と、Zone２０９を生成するZoneFactory２０５と、Zone内のノードに対応するCanvasを生成するEditlet２０６との間の適切な関係が作られる。ユーザがシステムから文書を処分又は削除するとき、対応するVocabularyConnectionManager３０２が削除される。
【００９０】
Vocabulary３０５は、VCCanvas３１０を生成する。さらに、Connector３０４及びデスティネーションＤＯＭツリー３０６が対応して生成される。
【００９１】
ソースＤＯＭ及びCanvasは、それぞれ、モデル（Ｍ）及びビュー（Ｖ）に対応する。しかしながら、このような表現は、ターゲットのボキャブラリが画面上に描写可能である場合に限って意味がある。描写は、ボキャブラリプラグインにより行われる。ボキャブラリプラグインは、主要なボキャブラリ、例えば、ＸＨＴＭＬ、ＳＶＧ、ＭａｔｈＭＬについて提供される。ボキャブラリプラグインは、ターゲットのボキャブラリに関連して使用される。これらは、ボキャブラリコネクション記述子を用いてボキャブラリ間でマッピングする方法を提供する。
【００９２】
このようなマッピングは、ターゲットのボキャブラリが、マッピング可能で、画面上に描写される方法が予め定義されたものである場合にのみ意味がある。このようなレンダリング方法は、例えばＸＨＴＭＬなどのように、Ｗ３Ｃなどの組織により定義された標準規格となっている。
【００９３】
ボキャブラリコネクションが必要であるとき、VCCanvasが使用される。この場合、ソースのビューを直接生成することができないので、ソースのCanvasは生成されない。この場合、VCCanvasが、ConnectorTreeを使用して生成される。このVCCanvasは、イベントの変換のみを扱い、画面上の文書の描写を援助しない。
【００９４】
３．DestinationZone、Pane、及びCanvas
上述したように、ボキャブラリコネクションサブシステムの目的は、同一の文書の２つの表現を同時に生成し保持することである。第２の表現も、ＤＯＭツリーの形式であり、これはデスティネーションＤＯＭツリーとして既に説明した。第２の表現における文書を見るために、DestinationZone、Canvas及びPaneが必要である。
【００９５】
VCCanvasが作成されると、対応するDestinationPane３０７が生成される。さらに、関連するDestinationCanvas３０８と、対応するBoxTree３０９が生成される。同様に、VCCanvas３１０も、ソース文書に対するPane２１１及びZone２０９に関連づけられる。
【００９６】
DestinationCanvas３０８は、第２の表現における文書の論理的なレイアウトを提供する。特に、DestinationCanvas３０８は、デスティネーション表現における文書を描写するために、カーソルや選択のようなユーザインタフェイス機能を提供する。DestinationCanvas３０８に生じたイベントは、Connectorに供給される。DestinationCanvas３０８は、マウスイベント、キーボードイベント、ドラッグアンドドロップイベント、及び文書のデスティネーション（第２）表現のボキャブラリに特有なイベントを、Connector３０４に通知する。
【００９７】
４．ボキャブラリコネクションコマンドサブシステム
ボキャブラリコネクション（ＶＣ）サブシステム３００の要素として、ボキャブラリコネクション（ＶＣ）コマンドサブシステム３１３がある。ボキャブラリコネクションコマンドサブシステム３１３は、ボキャブラリコネクションサブシステム３００に関連した命令の実行のために使用されるVCCommand（ボキャブラリコネクションコマンド）３１５を生成する。VCCommandは、内蔵のCommandTemplate（コマンドテンプレート）３１３１を使用して、及び／又は、スクリプトサブシステム３１４においてスクリプト言語を使用してスクラッチからコマンドを生成することにより、生成することができる。
【００９８】
コマンドテンプレートには、例えば、「If」コマンドテンプレート、「When」コマンドテンプレート、「挿入（Insert）」コマンドテンプレートなどがある。これらのテンプレートは、VCCommandを作成するために使用される。
【００９９】
５．ＸＰａｔｈサブシステム
ＸＰａｔｈサブシステム３１６は、文書処理システムの重要な構成であり、ボキャブラリコネクションの実現を支援する。Connector３０４は、一般にxpath情報を含む。上述したように、ボキャブラリコネクションのタスクの１つは、ソースＤＯＭツリーの変化をデスティネーションＤＯＭツリーに反映させることである。xpath情報は、変更／修正を監視されるべきソースＤＯＭツリーのサブセットを決定するために用いられる１以上のxpath表現を含む。
【０１００】
６．ソースＤＯＭツリー、デスティネーションＤＯＭツリー、及びConnectorTreeの概要
ソースＤＯＭツリーは、別のボキャブラリに変換される前のボキャブラリで文書を表現したＤＯＭツリー又はZoneである。ソースＤＯＭツリーのノードは、ソースノードと呼ばれる。
【０１０１】
それに対して、デスティネーションＤＯＭツリーは、ボキャブラリコネクションに関連して前述したように、同一の文書を、マッピングにより変換された後の異なるボキャブラリで表現したＤＯＭツリー又はZoneである。デスティネーションＤＯＭツリーのノードは、デスティネーションノードと呼ばれる。
【０１０２】
ConnectorTreeは、ソースノードとデスティネーションノードの対応を表すConnectorに基づく階層的表現である。Connectorは、ソースノードと、ソース文書になされた修正を監視し、デスティネーションＤＯＭツリーを修正する。Connectorは、デスティネーションＤＯＭツリーを修正することを許された唯一のオブジェクトである。
【０１０３】
Ｄ．文書処理システムにおけるイベントフロー
実用のためには、プログラムはユーザからのコマンドに応答しなければならない。イベントは、プログラム上で実行されたユーザアクションを記述し実行する方法である。多くの高級言語、例えばＪａｖａ（登録商標）は、ユーザアクションを記述するイベントに頼っている。従来、プログラムは、ユーザアクションを理解し、それを自身で実行するために、積極的に情報を集める必要があった。これは、例えば、プログラムが自身を初期化した後、ユーザが画面、キーボード、マウスなどでアクションを起こしたときに適切な処理を講じるために、ユーザのアクションを繰り返し確認するループに入ることを意味する。しかしながら、このプロセスは扱いにくい。さらに、それは、ユーザが何かをするのを待つ間、ＣＰＵサイクルを消費してループするプログラムを必要とする。
【０１０４】
多くの言語が、異なるパラダイムを採用することにより、これらの問題を解決している。そのうちの一つは、現代の全てのウィンドウシステムの基礎となっている、イベントドリブンプログラミングである。このパラダイムでは、全てのユーザアクションは、「イベント」と呼ばれる抽象的な事象の集合に属する。イベントは、十分詳細に、特定のユーザアクションを記述する。プログラムがユーザにより生成されたイベントを積極的に収集するのではなく、監視すべきイベントが生じたときに、システムがプログラムに通知する。この方法によりユーザとの対話を扱うプログラムは「イベントドリブン」であると言われる。
【０１０５】
これは、多くの場合、全てのユーザにより生成されたイベントの基本特性を獲得する「Event（イベント）」クラスを使用して扱われる。
【０１０６】
文書処理システムは、自身のイベント、及びこれらのイベントを扱う方法を定義して使用する。いくつかの型のイベントが使用される。例えば、マウスイベントは、ユーザのマウスアクションから起こるイベントである。マウスを含むユーザアクションは、Canvas２１０によって、マウスイベントに渡される。このように、Canvasは、システムのユーザによる相互作用の最前部にあると言える。必要であれば、最前部にあるCanvasは、そのイベントに関連した内容を子へ渡す。
【０１０７】
それに対して、キーストロークイベントは、Canvas２１０から流れる。キーストロークイベントは、即時的なフォーカスを有する。すなわち、それは、いかなる瞬間でも作業に関連する。Canvas２１０上に入力されたキーストロークイベントは、その親に渡される。キー入力は、文字列挿入を扱うことが可能な、異なるイベントによって処理される。文字列の挿入を扱うイベントは、キーボードを使用して文字が挿入されたときに発生する。他の「イベント」は、例えば、ドラッグイベント、ドロップイベント、マウスイベントと同様に扱われる他のイベントを含む。
【０１０８】
１．ボキャブラリコネクション外のイベントの取り扱い
イベントは、イベントスレッドを用いて渡される。Canvas２１０は、イベントを受け取ると、その状態を変更する。必要であれば、Command１０５２がCanvas２１０によりCommandQueue１０５３にポストされる。
【０１０９】
２．ボキャブラリコネクション内のイベントの取り扱い
VocabularyConnectionプラグイン３０１を用いて、DestinationCanvasの一例であるXHTMLCanvas１１０６は、発生したイベント、例えば、マウスイベント、キーボードイベント、ドラッグアンドドロップイベント、及びボキャブラリに特有のイベントなどを受け取る。これらのイベントは、Connector１１０４に通知される。より詳細には、図１１に図示されるように、VocabularyConnectionプラグイン３０１内のイベントフローは、SourcePane１１０３、VCCanvas１１０４、DestinationPane１１０５、DestinationCanvasの一例であるDestinationCanvas１１０６、デスティネーションＤＯＭツリー及びConnectorTreeを通過する。
【０１１０】
Ｅ．ProgramInvoker及びProgramInvokerと他の構成との関係
ProgramInvoker１０３及びそれと他の構成との関係は、図４（ａ）に更に詳細に示される。ProgramInvoker１０３は、文書処理システムを開始するために実行される実行環境中の基本的なプログラムである。図１（ｂ）に図示されるように、UserApplication１０６、ServiceBroker１０４１、CommandInvoker１０５１、及びResource１０９は、全てProgramInvoker１０３に接続される。前述したように、アプリケーション１０２は、実行環境中で実行されるコンポーネントである。同様に、ServiceBroker１０４１は、システムに様々な機能を加えるプラグインを管理する。他方、CommandInvoker１０５１は、ユーザにより提供される命令を実行して、コマンドを実行するために使用されるクラス及びファンクションを保持する。
【０１１１】
１．プラグイン及びサービス
ServiceBroker１０４１について、図４（ｂ）を参照して更に詳細に説明する。前述したように、ServiceBroker１０４１は、システムに様々な機能を追加するプラグイン（及び関連するサービス）を管理する。Service１０４２は、文書処理システムに特徴を追加又は変更可能な最も下の層である。「Service」は、ServiceCategory４０１とServiceProvider４０２の２つの部分からなる。図４（ｃ）に図示されるように、１つのServiceCategory４０１は、複数の関連するServiceProvider４０２を持ちうる。それぞれのServiceProviderは、特定のServiceCategoryの一部または全部を実行するように作用する。ServiceCategory４０１は、他方では、Serviceの型を定義する。
【０１１２】
Serviceは、１）文書処理システムに特定の特色を提供する「特色サービス」、２）文書処理システムにより実行されるアプリケーションである「アプリケーションサービス」、３）文書処理システムの全体にわたって必要な特色を提供する「環境サービス」、の３つの型に分類することができる。
【０１１３】
Serviceの例は、図４（ｄ）に示される。アプリケーションServiceのCategoryにおいては、システムユーティリティが対応するServiceProviderの例である。同様に、Editlet２０６はCategoryであり、HTMLEditlet及びSVGEditletは対応するServiceProviderである。ZoneFactory２０５は、Serviceの別のCategoryであり、対応するServiceProvider（図示せず）を有する。
【０１１４】
プラグインは、文書処理システムに機能性を加えると既に説明したが、いくつかのServiceProvider４０２及びそれらに関連するクラスからなるユニットと見なされてもよい。各プラグインは、宣言ファイルに記述された依存性及びServiceCategory４０１を有する。
【０１１５】
２．ProgramInvokerとアプリケーションとの関係
図４（ｅ）は、ProgramInvoker１０３とUserApplication１０６との関係についての更なる詳細を示す。必要な文書やデータなどは、ストレージからロードされる。必要なプラグインは、全てServiceBroker１０４１上にロードされる。ServiceBroker１０４１は、全てのプラグインを保持し管理する。プラグインは、システムに物理的に追加することができ、又、その機能はストレージからロードすることができる。プラグインの内容がロードされると、ServiceBroker１０４１は、対応するプラグインを定義する。つづいて、対応するUserApplication１０６が生成され、実行環境１０１にロードされ、ProgramInvoker１０３にアタッチされる。
【０１１６】
Ｆ．アプリケーションサービスと環境との関係
図５（ａ）は、ProgramInvoker１０３上にロードしたアプリケーションサービスの構成についての更なる詳細を示す。コマンドサブシステム１０５のコンポーネントであるCommandInvoker１０５１は、ProgramInvoker１０３内のCommand１０５２を起動又は実行する。Command１０５２は、文書処理システムにおいて、ＸＭＬなどの文書を処理し、対応するＸＭＬＤＯＭツリーを編集するために用いられる命令である。CommandInvoker１０５１は、Command１０５２を実行するために必要なクラス及びファンクションを保持する。
【０１１７】
ServiceBroker１０４１も、ProgramInvoker１０３内で実行される。UserApplication１０６は、ユーザインタフェイス１０７及びCoreComponent１１０に接続される。CoreComponent１１０は、全てのPaneの間で文書を共有する方法を提供する。CoreComponent１１０は、さらにフォントを提供し、Paneのためのツールキットの役割を果たす。
【０１１８】
図５（ａ）及び図５（ｂ）は、Frame１０７１、MenuBar１０７２、及びStatusBar１０７３の関係を示す。
【０１１９】
Ｇ．アプリケーションコア
図６（ａ）は、全ての文書、及び文書の一部及び文書に属するデータを保持するアプリケーションコア１１０についての更なる説明を提供する。CoreComponent１１０は、Document１０８２を管理するDocumentManager１０８１にアタッチされる。DocumentManager１０８１は、文書処理システムに関連づけられたメモリに格納される全てのDocument１０８２の所有者である。
【０１２０】
画面上の文書の表示を容易にするために、DocumentManager１０８１はRootPane１０８４にも接続される。ClipBoard１０８６、SnapShot１０８７、Drag&Drop６０１、及びOverlay６０２の機能も、アプリケーションコアにアタッチされる。
【０１２１】
SnapShot１０８７は、図６（ａ）で示したように、アプリケーションの状態を元に戻すために使用される。ユーザがSnapShot１０８７を起動したとき、アプリケーションの現状が検知され、格納される。その後、アプリケーションの状態が別の状態に変わるとき、格納された状態の内容は保存される。SnapShotは、図６（ｂ）に図示される。動作において、アプリケーションがあるＵＲＬから他へ移動するときに、前に戻る動作及び先に進む動作をシームレスに実行可能とするために、SnapShotは以前の状態を記憶する。
【０１２２】
Ｈ．DocumentManager内における文書の構成
図７（ａ）は、DocumentManager１０８１の更なる説明と、DocumentManagerにおいて文書が構成され保持される様子を示す。図１（ｂ）に示したように、DocumentManager１０８１は、Document１０８２を管理する。図７（ａ）に示される例において、複数のDocumentのうちの１つはRootDocument（ルート文書）７０１であり、残りの文書はSubDocument（サブ文書）７０２である。DocumentManager１０８１は、RootDocument７０１に接続され、RootDocument７０１は、全てのSubDocument７０２に接続される。
【０１２３】
図２及び図７（ａ）に示すように、DocumentManager１０８１は、全ての文書１０８２を管理するオブジェクトであるDocumentContainer２０３に結合される。DOMService７０３及びIOManager７０４を含むツールキット２０１（例えばＸＭＬツールキット）の一部を形成するツールも、DocumentManager１０８１に供給される。再び図７（ａ）を参照して、DOMService７０３は、DocumentManager１０８１により管理される文書に基づいたＤＯＭツリーを生成する。各Document７０５は、それがRootDocument７０１であってもSubDocument７０２であっても、対応するDocumentContainer２０３によって管理される。
【０１２４】
図７（ｂ）は、文書Ａ−Ｅが階層的に配置される様子を示す。文書ＡはRootDocumentである。文書Ｂ−Ｄは、文書ＡのSubDocumentである。文書Ｅは、文書ＤのSubDocumentである。図７（ｃ）では、これと同じ文書の階層が画面上に表示された例を示す。RootDocumentである文書Ａは、基本フレームとして表示される。文書ＡのSubDocumentである文書Ｂ−Ｄは、基本フレームＡの中のサブフレームとして表示される。文書ＤのSubDocumentである文書Ｅは、サブフレームＤのサブフレームとして画面に表示される。
【０１２５】
再び図７（ａ）を参照して、UndoManager（アンドゥマネージャ：アンドゥ管理部）７０６及びUndoWrapper（アンドゥラッパー）７０７は、それぞれのDocumentContainer２０３に対して生成される。UndoManager７０６及びUndoWrapper７０７は、取消可能なコマンドを実行するために使用される。この特徴を使用することにより、編集操作を使用して文書に対して実行された変更を取り消すことができる。SubDocumentの変更は、RootDocumentとも密接な関係を有する。アンドゥ操作は、階層内の他の文書に影響する変更を考慮に入れて、例えば、図１７（ｃ）に示されるような連鎖状の階層における全ての文書の間で整合性が維持されることを保証する。
【０１２６】
UndoWrapper７０７は、DocumentContainer２０３内のSubDocumentに関連するアンドゥオブジェクトをラップし、それらをRootDocumentに関連するアンドゥオブジェクトに結合させる。UndoWrapper７０７は、UndoableEditAcceptor（アンドゥアブルエディットアクセプタ：アンドゥ可能編集受付部）７０９に利用可能なアンドゥオブジェクトを収集させる。
【０１２７】
UndoManager７０６及びUndoWrapper７０７は、UndoableEditAcceptor７０８及びUndoableEditSource（アンドゥアブルエディットソース）７０８に接続される。当業者には理解されるように、Document７０５がUndoableEditSource７０８であってもよく、取消可能な編集オブジェクトのソースであってもよい。
【０１２８】
Ｉ．アンドゥコマンド及びアンドゥフレームワーク
図８（ａ）及び図８（ｂ）は、アンドゥフレームワーク及びアンドゥコマンドについて更なる詳細を提供する。図８（ａ）に示されるように、UndoCommand８０１、RedoCommand８０２、及びUndoableEditCommand８０３は、図１（ｂ）に示したようにCommandInvoker１０５１に積むことができるコマンドであり、順に実行される。UndoableEditCommand８０３は、UndoableEditSource７０８及びUndoableEditAcceptor７０９に更にアタッチされる。「foo」EditCommand８０３及び「bar」EditCommand８０４は、UndoableEditCommandの例である。
【０１２９】
１．UndoableEditCommandの実行
図８（ｂ）は、UndoableEditCommandの実行を示す。まず、ユーザが編集コマンドを使用してDocument７０５を編集すると仮定する。第１ステップＳ１では、UndoableEditAcceptor７０９が、Document７０５のＤＯＭツリーであるUndoableEditSource７０８にアタッチされる。第２ステップＳ２では、ユーザにより発行されたコマンドに基づいて、Document７０５がＤＯＭのＡＰＩを用いて編集される。第３ステップＳ３では、ミューテーションイベントのリスナーが、変更がなされたことを通知される。すなわち、このステップでは、ＤＯＭツリーの全ての変更を監視するリスナーが編集操作を検知する。第４ステップＳ４では、UndoableEditがUndoManager７０６のオブジェクトとして格納される。第５ステップＳ５では、UndoableEditAcceptor７０９がUndoableEditSource７０８からデタッチされる。UndoableEditSource７０８は、Document７０５自身であってもよい。
【０１３０】
Ｊ．システムへの文書のロードに関する手順
上記のサブセクションでは、システムの様々なコンポーネント及びサブコンポーネントについて説明した。以下、これらのコンポーネントの使用に関する方法論について説明する。図９は、文書処理システムに文書がロードされる様子の概要を示す。それぞれのステップは、図１４−１８において、特定の例に関連して詳述される。
【０１３１】
簡単には、文書処理システムは、文書に含まれるデータからなるバイナリデータストリームからＤＯＭを生成する。ApexNode（エイペックスノード：頂点ノード）が、注目対象でありZoneに属する文書の一部のために生成される。つづいて、対応するPaneが特定される。特定されたPaneは、ApexNode及び物理的な画面表面からZone及びCanvasを生成する。Zoneは、次に、それぞれのノードにFacetを生成し、それらに必要とされる情報を提供する。Canvasは、ＤＯＭツリーから、ノードをレンダリングするためのデータ構造を生成する。
【０１３２】
図１９（ａ）で示すように、ＳＨＴＭＬやＳＶＧコンテンツの両方で記述された複雑な文書はストレージ９０１からステップ０としてロードされる。その文書のＤＯＭツリー９０２が作成される。ＤＯＭツリー９０２が一つの頂点ノード９０５を有し、そして木が他の枝に降りるように、境界では２方向に分かれる。他のボキャブラリ、例えばＳＶＧの一つの頂点ノードもこれに従う。複雑な文書をこのように表現することは、文書を描写し、最終的に表示する方法を理解するのに有益である。
【０１３３】
次に、文書を保持するための、対応するDocumentContainer９０３が生成される。DocumentContainer９０３は、DocumentManager９０４にアタッチされる。ＤＯＭツリーは、ルートノードと、ときには複数のセカンダリノードを含む。
【０１３４】
一般に、このような文書は、テキスト及びグラフィクスの双方を含む。したがって、ＤＯＭツリーは、例えば、ＸＨＴＭＬサブツリーだけでなくＳＶＧサブツリーを有してもよい。ＸＨＴＭＬサブツリーは、ＸＨＴＭＬのApexNode９０５を有する。同様に、ＳＶＧサブツリーは、ＳＶＧのApexNode９０６を有する。
【０１３５】
ステップ１では、ApexNode９０６が、画面の論理的なレイアウトであるPane９０７にアタッチされる。ステップ２では、Pane９０７は、PaneOwner（ペインオーナー：ペインの所有者）９０８であるCoreComponentに、ApexNode９０６のためのZoneFactoryを要求する。ステップ３では、PaneOwner９０８は、ZoneFactoryと、ApexNode９０６のためのCanvasFactoryであるEditletとを返す。
【０１３６】
ステップ４では、Pane９０７がZone９０９を生成する。Zone９０９はPane９０７にアタッチされる。ステップ５では、Zone９０９がそれぞれのノードに対してFacetを生成し、対応するノードにアタッチする。ステップ６では、Pane９０７がCanvas９１０を生成する。Canvas９１０はPane９０７にアタッチされる。Canvas９１０には様々なCommandが含まれる。ステップ７では、Canvas９１０が文書を画面にレンダリングするためのデータ構造を構築する。ＸＨＴＭＬの場合、これはボックスツリー構造を含む。
【０１３７】
１．ZoneのＭＶＣ
図９（ｂ）は、ＭＶＣパラダイムを用いてZoneの構成の概要を示す。この場合、Zone及びFacetは文書に関連した入力であるから、モデル（Ｍ）はZone及びFacetを含む。Canvasと、文書を画面にレンダリングするためのデータ構造体は、ユーザが画面上に見る出力であるから、ビュー（Ｖ）はCanvas及びデータ構造体に対応する。Commandは、文書とその様々な関係に対して制御操作を実行するので、コントロール（Ｃ）はCanvasに含まれるCommandを含む。
【０１３８】
Ｋ．文書の表現
図１０を用いて、文書及びその様々な表現の例について以下に説明する。この例で使用される文書は、テキストと画像の双方を含む。テキストは、ＸＨＴＭＬを用いて表され、画像は、ＳＶＧを用いて表される。図１０は、文書のコンポーネント及び対応するオブジェクトの関係のＭＶＣ表現を詳細に示す。この例において、Document１００１は、Document１００１を保持するDocumentContainer１００２にアタッチされる。文書はＤＯＭツリー１００３により表現される。ＤＯＭツリーは、ApexNode１００４を含む。
【０１３９】
ApexNodeは、黒丸で表される。頂点でないノードは、白丸で表される。ノードを編集するために用いられるFacetは、三角形で表され、対応するノードにアタッチされる。文書がテキストと画像を有するので、この文書のＤＯＭツリーは、ＸＨＴＭＬ部分とＳＶＧ部分を含む。ApexNode１００４は、ＸＨＴＭＬサブツリーの最上のノードである。これは、文書のＸＨＴＭＬ部分の物理的な表現のための最上PaneであるXHTMLPane１００５にアタッチされる。ApexNode１００４は、文書のＤＯＭツリーの一部であるXHTMLZone１００６にもアタッチされる。
【０１４０】
Node１００４に対応するFacetも、XHTMLZone１００６にアタッチされる。XHTMLZone１００６は、XHTMLPane１００５にアタッチされる。XHTMLEditletは、文書の論理的な表現であるXHTMLCanvas１００７を生成する。XHTMLCanvas１００７は、XHTMLPane１００５にアタッチされる。XHTMLCanvas１００７は、Document１００１のＸＨＴＭＬコンポーネントのためのBoxTree１００９を生成する。文書のＸＨＴＭＬ部分を保持し描画するために必要な様々なCommand１００８も、XHTMLCanvas１００５に追加される。
【０１４１】
同様に、文書のＳＶＧサブツリーのApexNode１０１０は、文書のＳＶＧコンポーネントを表現するDocumentのＤＯＭツリーの一部であるSVGZone１０１１にアタッチされる。ApexNode１０１０は、文書のＳＶＧ部分の物理的な表現の最上のPaneであるSVGPane１０１３にアタッチされる。文書のＳＶＧ部分の論理的な表現を表すSVGCanvas１０１２は、SVGEditletにより生成され、SVGPane１０１３にアタッチされる。画面上に文書のＳＶＧ部分をレンダリングするためのデータ構造及びコマンドは、SVGCanvasにアタッチされる。例えば、このデータ構造は、図示されるように、円、線、長方形などを含んでもよい。
【０１４２】
図１０に関連して説明された文書例の表現の一部について、図１１（ａ）、図１１（ｂ）に関連して、前述したＭＶＣパラダイムを用いて更に説明する。図１１（ａ）は、文書１００１のＸＨＴＭＬコンポーネントにおけるＭＶの関係を簡略化して示す。モデルは、Document１００１のＸＨＴＭＬコンポーネントのためのXHTMLZone１１０３である。XHTMLZoneのツリーには、いくつかのNode及びそれらに対応するFacetが含まれる。対応するXHTMLZone及びPaneは、ＭＶＣパラダイムのモデル（Ｍ）部分の一部である。ＭＶＣパラダイムのビュー（Ｖ）部分は、Document１００１のＨＴＭＬコンポーネントの、対応するXHTMLCanvas１１０２及びBoxTreeである。文書のＸＨＴＭＬ部分は、Canvasと、それに含まれるCommandを使用して画面に描写される。キーボードやマウス入力などのイベントは、図示されるように、逆方向へ進む。
【０１４３】
SourcePaneは、更なる機能、すなわち、ＤＯＭの保有者としての役割を有する。図１１（ｂ）は、図１１（ａ）に示したDocument１００１のコンポーネントに対するボキャブラリコネクションを提供する。ＤＯＭホルダーとして機能するSourcePane１１０３は、文書のソースＤＯＭツリーを含む。ConnectorTreeは、ConnectorFactoryにより生成され、デスティネーションＤＯＭの保有者としても機能するDestinationPane１１０５を生成する。DestinationPane１１０５は、XHTMLDestinationCanvas１１０６としてボックスツリーの形式でレイアウトされる。
【０１４４】
Ｌ．プラグインサブシステム、ボキャブラリコネクション、及びコネクタの関係
図１２（ａ）−（ｃ）は、それぞれ、プラグインサブシステム、ボキャブラリコネクション、及びConnectorに関連する更なる詳細を示す。プラグインサブシステムは、文書処理システムに機能を追加又は交換するために用いられる。プラグインサブシステムは、ServiceBroker１０４１を含む。図１２（ａ）で示すように、「My Own XML vocabulary」はVcBasePlugInとして提供され、そのプラグインには、MyOwnXMLConnectorFactoryTree及びボキャブラリ（ZoneFactoryBuilder）を含む。ServiceBroker１０４１にアタッチされるZoneFactoryService１２０１は、文書の一部に対するZoneを生成する。EditletService１２０２も、ServiceBrokerにアタッチされる。EditletService１２０２は、Zone中のNodeに対応するCanvasを生成する。
【０１４５】
ZoneFactoryの例は、XHTMLZone及びSVGZoneをそれぞれ生成するXHTMLZoneFactory１２１１及びSVGZoneFactory１２１２である。文書例に関連して前述したように、文書のテキストコンポーネントは、XHTMLZoneを生成することにより表現されてもよいし、画像はSVGZoneを用いて表現されてもよい。EditletServiceの例は、XHTMLEditlet１２２１及びSVGEditlet１２２２を含む。
【０１４６】
図１２（ｂ）は、ボキャブラリコネクションに関連する更なる詳細を示す。ボキャブラリコネクションは、前述したように、文書処理システムの重要な特徴であり、２つの異なる方法で文書の整合のとれた表現及び表示を可能とする。ConnectorFactory３０３を保持するVCManager３０２は、ボキャブラリコネクションサブシステムの一部である。図１２（ｃ）で示すように、ConnectorFactory３０３は、文書のConnector３０４を生成する。前述したように、Connectorは、ソースＤＯＭ中のノードを監視し、２つの表現の間の整合性を維持するために、デスティネーションＤＯＭ中のノードを修正する。
【０１４７】
Template３１７は、いくつかのノードの変換ルールを表す。ボキャブラリコネクション記述子（ＶＣＤ）ファイルは、特定のパス又はルールを満たす要素又は要素の集合を他の要素に変換するいくつかのルールを表すTemplateのリストである。Template３１７及びCommandTemplate３１３１は、全てVCManager３０２にアタッチされる。VCManagerは、ＶＣＤファイル中の全てのセクションを管理するオブジェクトである。１つのＶＣＤファイルに対して、１つのVCManagerオブジェクトが生成される。
【０１４８】
図１２（ｃ）は、Connectorに関連する更なる詳細を提供する。ConnectorFactory３０３は、ソース文書からConnectorを生成する。ConnectorFactory３０３は、Vocabulary、Template、及びElementTemplateにアタッチされ、それぞれ、VocabularyConnector、TemplateConnector、ElementConnectorを生成ずる。
【０１４９】
VCManager３０２は、ConnectorFactory３０３を保持する。Vocabularyを生成するために、対応するＶＣＤファイルが読み込まれる。こうして、ConnectorFactory３０３が生成される。このConnectorFactory３０３は、Zoneを生成するZoneFactory及びCanvasを生成するEditletに関連する。
【０１５０】
つづいて、ターゲットボキャブラリのEditletServiceが、VCCanvasを生成する。VCCanvasも、ソースＤＯＭツリー又はZoneにおけるApexNodeのConnectorを生成する。必要に応じて、子のConnectorが再帰的に生成される。ConnectorTreeは、ＶＣＤファイル中のテンプレートの集合により生成される。
【０１５１】
テンプレートは、マークアップ言語の要素を他の要素に変換するためのルールの集合である。例えば、各テンプレートは、ソースＤＯＭツリー又はZoneにマッチされる。適切にマッチした場合には、頂点Connectorが生成される。例えば、テンプレート「A/*/D」は、間にどんなノードがあるかに関係なく、ノードＡで始まりノードＤで終わる全ての枝に合致する。同様に、「//B」は、ルートからの全ての「B」ノードに一致する。
【０１５２】
Ｍ．ConnectorTreeに関係するＶＣＤファイルの例
特定の文書と関係する処理を説明する例を続ける。ドキュメントタイトルのある「MySampleXML」というタイトルの文書が文書処理システムにロードされる。図１３は、「MySampleXML」ファイルのための、VCManager及びConnectorFactoryTreeを用いたＶＣＤスクリプトの例を示す。スクリプトファイル中のボキャブラリセクション、テンプレートセクションと、VCManagerにおける対応するコンポーネントが示される。タグ「vcd:vocabulary」において、属性「match」は「sample:root」、「label」は「MySampleXML」、「call-template」は「sample template」となっている。
【０１５３】
この例では、Vocabularyは、「MySampleXML」のVCManagerにおいて「sample:root」として頂点要素を含む。対応するＵＩラベルは、「MySampleXML」である。テンプレートセクションにおいて、タグは「vcd:template」であり、名前は「sample:template」である。
【０１５４】
Ｎ．ファイルがシステムにロードされる方法の詳細な例
図１４−１８は、文書「MySampleXML」のロードについての詳細な記述を示す。図１４（ａ）に示されるステップ１では、文書がストレージ１４０５からロードされる。DOMServiceは、DocumentContainer１４０１と対応するＤＯＭツリー及びDocumentManager１４０６を生成する。DocumentContainer１４０１は、DocumentManager１４０６にアタッチされる。文書は、ＸＨＴＭＬ及びMySampleXMLのサブツリーを含む。ＸＨＴＭＬのApexNode１４０３は、タグ「xhtml:html」が付されたＸＨＴＭＬの最上のノードである。「MySampleXML」のApexNode１４０４は、タグ「sample:root」が付された「MySampleXML」の最上ノードである。
【０１５５】
図１４（ｂ）に示されるステップ２では、RootPaneが文書のXHTMLZone、Facet、及びCanvasを生成する。Pane１４０７、XHTMLZone１４０８、XHTMLCanvas１４０９、及びBoxTree１４１０が、ApexNode１４０３に対応して生成される。
【０１５６】
図１４（ｃ）に示されるステップ３では、XHTMLZoneが知らないタグ「sample:root」を発見し、HTMLCanvasの領域からSubPaneを生成する。
【０１５７】
図１５に示されるステップ４では、SubPaneが「sample:root」を扱うことができ、適切なZoneを生成可能なZoneFactoryを得る。このZoneFactoryは、ZoneFactoryを実行可能なVocabulary内にある。それは、「MySampleXML」のVocabularySectionの内容を含む。
【０１５８】
図１６に示されるステップ５では、「MySampleXML」に対応するVocabularyがDefaultZone１６０１を生成する。対応するEditletが生成され、対応するCanvasを生成するためにSubPane１５０１が提供される。Editletは、VCCanvasを生成する。そして、それはTemplateSectionを呼ぶ。ConnectorFactoryTreeも含まれている。ConnectorFactoryTreeは、ConnectorTreeとなる全てのConnectorを生成する。文書のＸＨＴＭＬコンテンツに関係するApexNodeに対するBoxTreeとXHTMLCanvas同様に、RootPaneとXHTMLZoneとの関係も前述の内容からすぐに理解されよう。
【０１５９】
図１７（ａ）に示されるステップ６では、ソースＤＯＭツリー間の対応をもとに、各ConnectorがデスティネーションＤＯＭオブジェクトを生成する。コネクタのうちのいくつかはxpath情報を含んでいる。xpath情報は、変更／修正を監視する必要のあるソースＤＯＭツリーの部分集合を決定するために使用される１以上のxpath表現を含む。
【０１６０】
図１７（ｂ）に示されるステップ７では、ソース・ＶＣ・ディスティネーションの関係に従って、ボキャブラリは、ソースＤＯＭのペインからデスティネーションＤＯＭツリーのDestinationPaneを作成する。これは、SourcePaneに基づいてなされる。デスティネーションツリーのApexNodeは、DestinationPane及び対応するZoneにアタッチされる。DestinationPaneは、DestinationCanvasを生成し、文書をデスティネーションのフォーマットでレンダリングするためのデータ構造及びコマンドを構築する、自身のEditletを提供される。
【０１６１】
図１８（ａ）は、対応するソースノードを持たず、デスティネーションツリーにのみ存在するノード上でイベントが発生したときのフローを示す。マウスイベント、キーボードイベントなど、Canvasが取得したイベントは、デスティネーションツリーを通過して、ElementTemplateConnectorに伝達される。ElementTemplateConnectorは対応するソースノードを持たないので、伝達されたイベントはソースノードに対する編集操作ではない。ElementTemplateConnectorは、伝達されたイベントがCommandTemplateに記述されたコマンドに合致すれば、それに対応するActionを実行する。合致するコマンドがなければ、ElementTemplateConnectorは、伝達されたイベントを無視する。
【０１６２】
図１８（ｂ）は、TextOfConnectorによりソースノードに対応づけられているデスティネーションツリーのノード上でイベントが発生したときのフローを示す。TextOfConnectorは、ソースＤＯＭツリーのＸＰａｔｈで指定されたノードからテキストノードを取得して、デスティネーションＤＯＭツリーのノードにマッピングする。マウスイベント、キーボードイベントなど、Canvasが取得したイベントは、デスティネーションツリーを通過して、TextOfConnectorに伝達される。TextOfConnectorは、伝達されたイベントを、対応するソースノードの編集コマンドにマッピングし、Queue１０５３に積む。編集コマンドは、Facetを介して実行されるＤＯＭのＡＰＩコールの集合である。キューに積まれたコマンドが実行されると、ソースノードが編集される。ソースノードが編集されると、ミューテーションイベントが発行され、リスナーとして登録されたTextOfConnectorにソースノードの変更が通知される。TextOfConnectorは、ソースノードの変更を、対応するデスティネーションノードに反映させるように、デスティネーションツリーを再構築する。このとき、TextOfConnectorを含むテンプレートに、「for each」や「for loop」などの制御文が含まれている場合、ConnectorFactoryがこの制御文を再評価し、TextOfConnectorを再構築した後、デスティネーションツリーが再構築される。
【０１６３】
（タグ又は属性を生成する動作の詳細）
図１９は、分割画面１９００を示しており、ユーザインタフェイス１９１０が図の右側に示されており、それに対応するマークアップ言語で記述されたコード１９２０が図の左側に示されている。示されたインタフェイスは日報ファイルである。図のマークアップ言語はＸＭＬである。ユーザインタフェイス１９１０は、いくつかのフィールドを有しており、図４のInterfacePortion４１０の最上位部分に「*log book title」フィールド１９４０を含んでいる。この「*log book title」フィールド４４０については後述する。
【０１６４】
「*log book title」フィールド１９４０は以下「FallbackSection」と記述する。何らかの文字がFallbackSectionに入力されると、「*log book title」の語句は消失する。そしてもしもFallbackSectionに合致する「title」タグ（ＸＭＬの場合）が事前になかった場合、titleタグが作成される。
【０１６５】
文字（ここでは「Ｔ」）がFallbackSection５４０に入れられた場合の例を図２０で示す。情報が入力されたかを判定（図２３のＳ２３１０）をした後、タイトルタグ（ここでは「diary:title」）が作成される。そして、「Ｔ」が作成されたタグの文字列値として入力される。図２１で示すように、さらなる文字列がFallbackSection２１４０に入れられると、作成されたタイトルタグの文字列値として同じ文字列が入れられる。本発明の典型的な実施形態によれば、文字列がそれと対応するFallbackSectionに入力されるまではタイトルタグは作成されない（図２３のＳ２３２０）。
【０１６６】
変形例として、編集可能領域で何らの情報を受け付けなかった場合には、タグが自動作成されるようにしてもよい。
【０１６７】
典型的な実施形態によれば、本発明の他の態様として、モーダルダイアログを含む従来の技術とは異なるカーソル移動がある。本発明の典型的な実施形態によれば、例えば、カーソルがFallbackSection２２４０にあり、そこで右矢印キーが押下されると、FallbackSection２２４０の外にカーソルを移動させる。例えば図２２に示すように、カーソルがFallbackSection「*lob\g book title」にあり、そこで右矢印キーが押下されたとする。そうすると、カーソルは次の編集可能領域２２５０に移動する。図２２で示すように、この例では、カーソルはプレーンテキストを含むフィールド２２５０に移動する。もし再度右矢印キーが押下されると、カーソルは「*paragraph」とラベル付けされた次のFallbackSection２２６０に移動する。さらに右矢印キーが押下されると、カーソルは、「So that every mounting...」で始まるプレーンテキスト部分に移動する。このように、フィールドに含まれる文字列から文字列へと移動する代わりに、右矢印キーのようなキー操作により、ある編集可能フィールドから別の編集可能フィールドへカーソルを移動させることができる。
【０１６８】
本発明のさらに別の態様として、ＶＣＤに基づくソース文書に従ってユーザインタフェイスが形成されてもよい。
【０１６９】
本発明の他の改良や変更は、上記の開示及び教示から当業者には明らかである。したがって、本発明の特定の実施例のみをとくに例示したが、本発明の趣旨及び範囲から逸脱することなく、それらに種々の変更が可能であることは明らかである。
【図面の簡単な説明】
【０１７０】
【図１（ａ）】開示した文書処理システムの典型的な実装の基本となるコンポーネントの標準的な配置を示す図である。
【図１（ｂ）】典型的な文書処理システムの全体的なブロック図である。
【図１（ｃ）】典型的な文書処理システムの全体的なブロック図である。
【図２】「Document Manager」の典型的な実装について詳細を示す図である。
【図３】「Vocabulary Connection」サブシステム３００の典型的な実装について詳細を示す図である。
【図４】図４（ａ）は、「Program Invoker」及びそれに関連する他のコンポーネントの典型的な実装について詳細を示す図であり、図４（ｂ）は、「Service Broker」及びそれに関連する他のコンポーネントの典型的な実装について詳細を示す図であり、図４（ｃ）は、「Service」の典型的な実装について詳細を示す図であり、図４（ｄ）は、「Service」の例を示す図であり、図４（ｅ）は、「Program Invoker」１０３と「User Application」１０６との関係について詳細を示す図である。
【図５】図５（ａ）は、「Program Invoker」上に展開される「Application Service」の構造について詳細を示す図であり、図５（ｂ）は、「Frame」、「MenuBar」、「StatusBar」の関係の例を示す図であり、
【図６】図６（ａ）は、「Application Core」の典型的な実装について詳細を示す図であり、図６（ｂ）は、「Snap Shot」の典型的な実装について詳細を示す図である。
【図７】図７（ａ）は、「Application Core」の典型的な実装について詳細を示す図であり、図７（ｂ）は、ＡからＥの「Document」の組がどのように階層化されるのかの例を示す図であり、図７（ｃ）は、図７（ｂ）で示した「Document」の階層がスクリーン上でどのように見えるのかの例を示す図である。
【図８】「Undo Framework」及び「Undo Command」の典型的な実装の詳細を示す図である。
【図９】図９（ａ）は、図１（ｂ）、図１（ｃ）で示す文書処理システム内に「Document」がどのように展開されるかの全体像を示す図であり、図９（ｂ）は、ＭＶＣパラダイムを使って、「Zone」の構造の概要を示す図である。
【図１０】本発明に従って、「Document」とその様々な表現の例を示す図である。
【図１１】図１１（ａ）は、図１０で示す「Document」のＸＨＴＭＬコンポーネントに対する「MV」関係の概要を示す図であり、図１１（ｂ）は、図１１（ａ）で示す「Document」に対するボキャブラリコネクションを示す図である。
【図１２】プラグインサブシステム、ボキャブラリコネクション、コネクタそれぞれの典型的な実装について詳細を示す図である。
【図１３】MySampleXMLに対して、ボキャブラリコネクションマネージャとコネクタファクトリーツリーを使用するＶＣＤスクリプトの例を示す図である。
【図１４】図１（ｂ）の典型的な文書処理システムの中に、文書例MySampleXMLが展開されるステップ０から３を示した図である。
【図１５】図１（ｂ）の典型的な文書処理システムの中に、文書例MySampleXMLが展開されるステップ４を示した図である。
【図１６】図１（ｂ）の典型的な文書処理システムの中に、文書例MySampleXMLが展開されるステップ５を示した図である。
【図１７（ａ）】図１（ｂ）の典型的な文書処理システムの中に、文書例MySampleXMLが展開されるステップ６を示した図である。
【図１７（ｂ）】図１（ｂ）の典型的な文書処理システムの中に、文書例MySampleXMLが展開されるステップ７を示した図である。
【図１８】図１８（ａ）は、対応するソースノードを持たず、ディスティネーションツリーのみに依存するノードで発生するイベントのフローを示す図であり、図１８（ｂ）は、「TextOfConnector」によりソースノードと連動するディスティネーションツリーのノードで発生するイベントのフローを示す図である。
【図１９】実施の形態に係る文書処理装置の編集可能領域と対応するＸＭＬを示した画面のスナップショットである。
【図２０】文字入力のプロセスを示した画面のスナップショットである。
【図２１】図２１に続く画面スナップショットである。
【図２２】編集可能領域から次の編集可能領域に移動するプロセスを示した画面のスナップショットである。
【図２３】タグまたは属性を作成するプロセスの例である。
【図２４】タグまたは属性を作成するプロセスの例である。
【符号の説明】
【０１７１】
１９００  画面スナップショット、１９１０  ユーザインタフェイス、１９２０  マークアップ言語コード、１９４０  フィールド（FallbackSection）、２１４０  フィールド（FallbackSection）、２２４０  フィールド（FallbackSection）、２２５０  フィールド（FallbackSection）、２２６０  フィールド（FallbackSection）、Ｓ２３１０  編集可能領域での情報受付の判定、２３２０  タグもしくは属性の作成。
【図１（ａ）】
2008508643.tif 000003
【図１（ｂ）】
2008508643.tif 000004
【図１（ｃ）】
2008508643.tif 000005
【図２】
2008508643.tif 000006
【図３】
2008508643.tif 000007
【図４】
2008508643.tif 000008
【図５】
2008508643.tif 000009
【図６】
2008508643.tif 000010
【図７】
2008508643.tif 000011
【図８】
2008508643.tif 000012
【図９】
2008508643.tif 000013
【図１０】
2008508643.tif 000014
【図１１】
2008508643.tif 000015
【図１２】
2008508643.tif 000016
【図１３】
2008508643.tif 000017
【図１４】
2008508643.tif 000018
【図１５】
2008508643.tif 000019
【図１６】
2008508643.tif 000020
【図１７（ａ）】
2008508643.tif 000021
【図１７（ｂ）】
2008508643.tif 000022
【図１８】
2008508643.tif 000023
【図２３】
2008508643.tif 000024
【図２４】
2008508643.tif 000025
【図１９】
2008508643.tif 000026
【図２０】
2008508643.tif 000027
【図２１】
2008508643.tif 000028
【図２２】
2008508643.tif 000029
【手続補正書】
【提出日】平成19年9月27日(2007.9.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ユーザがマークアップ言語で記述された文書の編集を行うためのシステムであって、
編集可能領域を有する表示部と、
前記編集可能領域が編集されたかどうかをもとに、マークアップ言語で記述された前記文書にタグ又は属性を追加する変換部と、
を備えることを特徴とするシステム。
【請求項２】
マークアップ言語で記述された第一の文書を編集することで、マークアップ言語で記述された第二の文書に変更を反映するシステムであって、
編集可能領域を有する、マークアップ言語で記述された前記第一の文書と、
前記編集可能領域が編集されたかどうかをもとに、マークアップ言語で記述された前記第二の文書にタグや属性を追加する変換部と、
を備えることを特徴とするシステム。
【請求項３】
前記編集可能領域に情報が追加された場合に限り、前記タグや前記属性を作成することを特徴とする請求項１又は２に記載のシステム。
【請求項４】
前記情報は、文字データであることを特徴とする請求項３に記載のシステム。
【請求項５】
前記情報が追加される前に、前記編集可能領域に文字データが表示されることを特徴とする請求項３又は４に記載のシステム。
【請求項６】
前記情報が追加されると、前記文字データは消失することを特徴とする請求項５に記載のシステム。
【請求項７】
前記編集可能領域に何らの情報が提供されない場合には、前記タグが自動で作成されることを特徴とする請求項１から６のいずれかに記載のシステム。
【請求項８】
カーソルが前記編集可能領域にある場合には、キーの押下により前記カーソルを次の編集可能領域に移動させることを特徴とする請求項１から７のいずれかに記載のシステム。
【請求項９】
マークアップ言語により記述された前記文書は、ＤＯＭで表現されていることを特徴とする請求項１から８のいずれかに記載のシステム。
【請求項１０】
マークアップ言語で記述された前記文書内にフラグメントが挿入された場合には、前記表示部において前記フラグメントに対応する編集可能領域が作成されることを特徴とする請求項１から９のいずれかに記載のシステム。
【請求項１１】
前記フラグメントは、タグ、属性、テキスト、及びマークアップ言語の要素のうち少なくとも一つを含むことを特徴とする請求項１０に記載のシステム。
【請求項１２】
前記編集可能領域の設定により、前記タグ及び前記属性のうちいずれが作成されるかが決定されることを特徴とする請求項１から１１のいずれかに記載のシステム。
【請求項１３】
前記編集可能領域の設定により、マークアップ言語で記述された前記文書のどこに前記タグや前記属性が作成されるかが決定されることを特徴とする請求項１から１２のいずれかに記載のシステム。
【請求項１４】
当該システムはさらに、マークアップ言語により記述された前記文書に入力された情報をもとに、前記表示部に１つ以上の編集可能領域を作成する編集可能領域構成部を備えることを特徴とする請求項１から１３のいずれかに記載のシステム。
【請求項１５】
マークアップ言語により記述された文書内にタグ又は属性を作成する方法であって、
インタフェイスの編集可能領域で情報が受け付けられたか否かを決定する工程と、
前記情報が受け付けられた場合、その情報をもとに前記タグ又は前記属性を作成する工程と、
を含むことを特徴とする方法。
【請求項１６】
マークアップ言語を使用して、タグや属性を作成するための環境を構築する方法であって、
前記マークアップ言語を使用して、前記環境の一部として、編集可能領域を含むインタフェイスを構築する工程を備え、
前記編集可能領域は前記タグや前記属性を作成するかどうかを決定することを特徴とする方法。
【請求項１７】
コンピュータを、マークアップ言語で記述された文書内にタグや属性を作成する手段として機能させるためのコンピュータプログラムであって、
前記手段は、
インタフェイスの編集可能領域で情報を受け付ける手段と、
受け付けた情報をもとに、前記タグや前記属性を作成する手段と、
を含むことを特徴とするコンピュータプログラム。
【請求項１８】
タグや属性を作成するかどうかを決定する編集可能領域を備えることを特徴とする、マークアップ言語により構築されたインタフェイスとしてコンピュータを機能させるためのコンピュータプログラム。
【請求項１９】
ソース文書にタグや属性を作成するかどうかを決定する編集可能領域を備えることを特徴とする、ＸＭＬにより構築されたユーザインタフェイスとしてコンピュータを機能させるためのコンピュータプログラム。
【手続補正２】
【補正対象書類名】図面
【補正対象項目名】図１９
【補正方法】変更
【補正の内容】
【図１９】
2008508643.tif 000030
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】図２０
【補正方法】変更
【補正の内容】
【図２０】
2008508643.tif 000031
【手続補正４】
【補正対象書類名】図面
【補正対象項目名】図２１
【補正方法】変更
【補正の内容】
【図２１】
2008508643.tif 000032
【手続補正５】
【補正対象書類名】図面
【補正対象項目名】図２２
【補正方法】変更
【補正の内容】
【図２２】
2008508643.tif 000033
【国際調査報告】
2008508643.tif 000034