複合ドキュメント・フレームワーク
【課題】オブジェクト指向複合ドキュメント・アーキテクチャがドキュメント処理機能に対するシステム・レベルのサポートを提供する。
【解決手段】オブジェクト指向複合ドキュメント・フレームワークは様々なドキュメント処理関数をサポートしている。このフレームワークは、なかんずく、コラボレーション（共同作業）、リンキング、エターナル・アンドゥ（永続的取消し）、および内容ベース検索(content based retrieval)をシステム・レベルでサポートしている。システム・レベルのサポートはドキュメント変更、モデルとリンキングによる注釈、アンカ、モデル階層、機能強化されたコピーとペースト、コマンド・オブジェクト、および汎用検索フレームワークに対するものが用意されている。
【解決手段】オブジェクト指向複合ドキュメント・フレームワークは様々なドキュメント処理関数をサポートしている。このフレームワークは、なかんずく、コラボレーション（共同作業）、リンキング、エターナル・アンドゥ（永続的取消し）、および内容ベース検索(content based retrieval)をシステム・レベルでサポートしている。システム・レベルのサポートはドキュメント変更、モデルとリンキングによる注釈、アンカ、モデル階層、機能強化されたコピーとペースト、コマンド・オブジェクト、および汎用検索フレームワークに対するものが用意されている。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般的にはコンピュータ・システムに関し、より具体的にはオブジェクト指向複合ドキュメント処理のための方法およびシステムに関する。
【背景技術】
【０００２】
本特許出願の一部には、著作権保護の対象となる内容が含まれている。著作権所有者は、米国特許商標庁の特許ファイルまたはレコードに記録されている特許文書または特許開示内容を何人もが原文通りに複製することを妨げるものではないが、その他の場合には、一切の著作権を所有することを留保する。
【０００３】
ドキュメント処理は、社会が紙を作り出す仕方に大変革をもたらした。従来の代表的ドキュメント処理システムはＤＯＳやＯＳ／２などの、オペレーティング・システム上で稼働している。最近では、これらのドキュメント処理システムはウィンドウズ環境で稼働する設計になっている。これらのドキュメント処理システムの多くは市販されている。
【０００４】
「インタメディア：シームレス情報環境の概念と構造（Intermedia：The Concept and the Construction of a Seamless Information Environment) 」という文献には、直接操作エディタとアプリケーションをサポートするオブジェクト指向フレームワークを備えたハイパメディア・システムが開示されている。ハイパメディア・システムはハイパテキスト・システムを拡張したもので、作成者または作成者グループが情報をリンクで１つに結合し、グラフィックス、テキスト、サウンドおよびビデオを含む関連マテリアルの本体を通るパス(path)を作成することを可能にしている。この機能は、ハイパメディア機能を、ハイパメディア・システムを構成する各アプリケーションに統合化することにより達成される。このハイパメディア機能は、アプリケーション開発者のためにビルディング・ブロックを提供するように基本的MacAppクラスを拡張することにより作られていた。これらのクラスは、インタメディア層を作成するようにサブクラス化されていた。この文献には、オペレーティング・システム層は言及されていない。
【０００５】
「SEPIA におけるハイパドキュメントの共同著作のサポート(Supporting Collaborative Writing of Hyperdocuments in SEPIA) 」という別の文献には、(1) ハイパテキスト共同作業に関係する背景、(2) SEPIA ハイパテキスト著作システム、(3) SEPIA による共同作業のサポートが開示されている。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上記に挙げたドキュメント処理システムはドキュメントやテキストを処理する能力を大幅に向上したが、他方では、具体的処理方法に関してドキュメント・プロセッサ間に大きな不統一性がある。これらの不統一性は、アプリケーション 開発者とアプリケーションのユーザの双方に問題を引き起こす結果になっている。
【０００７】
アプリケーション開発者にとっては、新しいドキュメント・プロセッサを構築するとき、絶えず「一からやり直さなければならない」という問題がある。オペレーティング・システムおよびインタフェース・プログラムには、使用できるツールがいくつか用意されているが、特定のドキュメント・プロセッサを設計するときの作業の大半は、ユーザがドキュメントを処理できるように相互に作用し合う処理モジュール群を作成することが中心になっている。アプリケーション開発者は、別の会社によってすでに開発されている処理モジュールを設計することがよく起こっている。そのために、作業の多くは重複することになり、各開発者は、必要とする種々の関数（機能）をどのようにインプリメント（実装）するかの詳細を取り扱うことが要求されている。
【０００８】
アプリケーション・ユーザには、他の問題が起こっている。特定の関数があるアプリケーションに存在していても、別のアプリケーションに存在しないことがある。また、あるアプリケーションで利用できる関数は、別のアプリケーションではその使い方や実行方法が若干異なっている場合もある。例えば、アプリケーションＡの関数は、その関数をアクチベートするにはある種のユーザとのやりとり（インタラクション）と入力を要求するのに対し、アプリケーションＢの同種の関数は若干異なった、あるいはまったく異なったユーザとのやりとりと入力を要求する場合がある。
【課題を解決するための手段】
【０００９】
本発明の目的は、オブジェクト指向フレームワークを利用して、特定のドキュメント処理手法をインプリメント（実装）するためのドキュメント処理システムを提供することであり、この中には、オブジェクト指向複合ドキュメント・システムが含まれる。本発明の上記目的および他の目的は、種々の複合ドキュメント処理関数（機能）をシステム・レベルでサポートするドキュメント・フレームワークによって実現されている。フレームワークはコラボレーション（共同作業）、リンキング、エターナル・アンドゥ (eternal undo−永続的取消し）、および内容ベース検索(content based retrieval) をシステム・レベルでサポートする機能を備えている。これらの目的および他の目的は、ドキュメント変更、モデルとリンキングによる注釈(annotation)、アンカ(anchor)、モデル階層(model hierarchy)、機能強化されたコピーとペースト(enhanced copy and pasting)、コマンド・オブジェクト、および汎用検索フレームワーク(generic retrieval framework)をシステム・レベルでサポートすることにより達成されている。
【発明を実施するための最良の形態】
【００１０】
以下、本発明の実施例について詳しく説明する。なお、以下に開示されている実施例は本発明を単に例示したものにすぎず、種々態様に実現することが可能であることは勿論である。従って、以下に詳述する開示内容は限定的なものではなく、請求の範囲を判断するときの基礎となり、本発明を製造および／または使用する方法を、当業者に教示するときの基礎となるにすぎないものと理解すべきである。
【００１１】
オブジェクト指向プログラミングおよびフレームワーク開発の歴史は文献に記載されている。Ｃ++とSmallTalk は文献に説明されているので、ここで詳しく説明することは省略する。同様に、カプセル化(encapsulation)、多様性(polymorphism)および継承(inheritance)といった、オブジェクトの特性は文献や特許明細書に詳しく論じられている。オブジェクト指向システムを詳しく論じた文献としては、Grady Booch 著「オブジェクト指向設計とアプリケーション(Object Oriented Design with Applications)」(ISBN 0-8053-0091-0(1991) がある。
【００１２】
多くのオブジェクト指向システムは、基本的入出力を実行する基本的オペレーティング・システム上で稼働する設計になっているが、本発明を使用すると、特定の機能（フィーチャ）をシステム・レベルでサポートすることができる。
【００１３】
本発明は、好ましくは、ＩＢＭ（登録商標）PS/2（登録商標）またはアップル社（登録商標）マッキントッシュ（登録商標）コンピュータなどのパーソナル・コンピュータに常駐したオペレーティング・システムを背景に実施される。図１は代表的なハードウェア環境を示したもので、本発明によるコンピュータの代表的なハードウェア構成を示している。このハードウェア構成は、従来のマイクロプロセッサなどの中央処理ユニット１０、およびシステム・バス１２を介して相互接続された複数の他のユニットを含んでいる。図１に示すコンピュータはリード・オンリ・メモリ（ＲＯＭ）１６、ランダム・アクセス・メモリ（ＲＡＭ）１４、ディスク・ユニット２０などの周辺デバイスおよび２１で示す他の入出力周辺デバイスをシステム・バス１２に接続するための入出力アダプタ１８、キーボード２４、マウス３２、スピーカ２８、マイクロホン２６および／またはタッチ・スクリーン・デバイス（図示せず）などの他のユーザ・インタフェース・デバイスをバス１２に接続するためのユーザ・インタフェース・アダプタ２２、ワークステーションを２３で示すデータ処理ネットワークに接続するための通信アダプタ３４、およびバスをディスプレイ・デバイス３８に接続するためのディスプレイ・アダプタ３６を装備している。ワークステーションには、アップル・システム７（登録商標）オペレーティング・システムなどのオペレーティング・システムが常駐している。
【００１４】
本明細書に開示されているドキュメント・フレームワークの主目標は、いくつかの新しい機能（フィーチャ）をシステム・レベルで使用可能にすることによりアプリケーションの基本レベルを向上することにある。加えて、これらの機能に対するシステム・サポートがないと、インプリメンテーションを制限することになる。例えば、ユーザはどのドキュメントでも、その静的表現(picture：ピクチャ）に注釈をつけることができるが、「生の(live)」ドキュメント自体には注釈をつけることができないようなアプリケーションがある。内容ベース検索アプリケーションはドキュメントの内容をアクセスするときトラブルを引き起こしているが、これは、各アプリケーションがカスタム・ファイル・フォーマットになっているためである。また、アプリケーションがドキュメントを見つけたあと、そのドキュメントになんらかの処理を行うことが困難になっている。例えば、ドキュメントをオープンすることがシステム・レベルでサポートされていない。ドキュメント・フレームワークは、注釈サポート(annotation support)のように、これらの基本サービスを基礎にして作られたいくつかのハイレベル機能を備えている。可能な限りの範囲において、ドキュメント・フレームワークは、ポリシまたはユーザ・インタフェース決定に関してはなにも規定していない。これらの詳細は、ドキュメント・フレームワークを使用して特定のアプリケーションから与えられるようになっている。
【００１５】
コラボレーション（共同作業）
スクリーン共有(screen sharing)は、マッキントッシュではコラボレーションの一種として普及しているが、これはインプリメント（実装）が比較的容易であり、その用途が多数あるためである。その主な欠点は、ある種のアプリケーションはスクリーンに直接にドローイング(drawing) し（実装を複雑化している）、すべてのドローイング操作をあるマシンから別のマシンへ伝送するのに大きなバンド幅を必要とすることである。また、これは、すべてのコラボレータがドキュメントをまったく同じ見方で見ることに基づいているので、非常に制約的になっている。
【００１６】
スクリーン共有は、同時リアルタイム・コラボレーションの一種である。ドキュメント・フレームワークでは、異種の同時リアルタイム・コラボレーションをサポートしている。これは、スクリーンの変更ではなく、ドキュメントの変更というレベルで動作するので、ドキュメント変更を指定するのに必要なデータ量がスクリーンを更新するのに必要なデータ量よりも少ないのが通常であるため、より効率的になっている。
【００１７】
また、コラボレーションを非同期（つまり、非リアルタイム）で行なうことも有用である。これの１つ形体として、ドキュメントに注釈をつける機能がある。ドキュメント・フレームワークでは、そのモデルとリンキング・メカニズム（下述する）を通して注釈をつけることを低レベルでサポートしている。
【００１８】
ハイパメディア・リンキング
図２は、本発明の実施例を示す図である。ブロックは、システムに関係する装置とメソッドの両方を表わしている。図２に示すように、ドキュメント・フレームワークでは、リンク２０４はアンカ２０２と２０６との間を双方向で結合している。アンカの意味はアプリケーションによって異なるが、殆どの場合、アンカはスティッキ・セレクション(sticky selection)を表わしている。アンカがスティッキであるのは、ユーザの編集上の変更とは無関係に、同じデータを常に参照しているからである。例えば、アンカがテキスト・ブロック内のあるワードを参照している場合、その前後のテキストが変更されても、アンカは常にそのワードを参照している。アンカは、カプセル化された特定のデータ・ブロック（モデルと呼ばれる）２００と関連づけられている。システム内のデータの各種類は、TModelの特定サブクラスで表わされている。抽象基底クラスであるTModelは、他のモデルがそのデータを「ブラック・ボックス」として組み込み、表示し、操作することを可能にする汎用プロトコル(generic protocol)を定義している。例えば、アプリケーションはデータのプレゼンテーション（view：ビュウ）を作成するようにモデルに要求することができる。これらのプレゼンテーションは小さなもの(thumbnail) から完全に編集可能なプレゼンテーションまでにわたっている。モデルのデータに関連するアンカをアクセスし、そのモデルに組み込まれた他のモデルをアクセスするときのプロトコルもある。ドキュメントのデータはモデル階層で表され、「ルート・モデル(root model)」と呼ばれるルートには、単一のモデルが置かれている。
【００１９】
ユーザはリンクを作成したあと、その操作を行うことができる。まず、ユーザはリンクの一方の端から他方の端までナビゲート（たどっていくこと）することができる。一般的に、これは、ターゲット・アンカを収めているドキュメントをオープンし、アンカをビュウまでスクロールし、対応するセレクションをハイライトにすることにより行われる。アプリケーションはこの動作（behavior：振舞い）を変更することができる。例えば、サウンド・ドキュメントまでナビゲートするだけでドキュメントをオープンしなくても、サウンドが演奏される。また、リンク間を両方向にデータを転送することも可能である。データを転送することは、意味的には、ソース・データをコピーし、デスティネーション・アンカまでナビゲートし、既存のデータを転送データで置き換えるのと（ほぼ）同じである。データをリンク経由でプッシュするか、プルするかは（つまり、転送を開始するのがソースであるか、デスティネーションであるかは）、ドキュメント・フレームワークでは大した問題ではない。
【００２０】
ドキュメント・フレームワークでは、１つのアプリケーションはリンクを介して任意のコマンドを送ることも可能である。そのようにすると、相互に協力し合うアプリケーションは、同じ基本リンキング・メカニズムを使用してカスタム機能を実装することが可能になる。ドキュメント・フレームワークの低レベル・リンキング・メカニズムは回りくどい使い方をしなくても、ユーザはドキュメント間のリンクを作成し、これらのリンクをナビゲートし、リンク間でデータを転送し、その他を行うことができる。しかしながら、これはリンクの唯一の使用法ではない。リンクは、他のアプリケーション機能を実装するためにも使用される。これらの機能では、リンクが作成され、操作されることはユーザに気づかないようになっている。
【００２１】
例えば、システム・ワイドの注釈機能はリンクを使用して、注釈をそれが参照しているベース・ドキュメントの部分と関連づけている。システムは、通知ノート・アイコン(posted note icon)（注釈を表している）を、それが参照しているドキュメントの部分の近くに位置付ける。さらに、注釈がドキュメント変更の提案を含んでいれば、作成者はその提案を「受け入れて」、システムにリンクを介してデータを注釈からドキュメントへ自動的に転送させることが可能である。
【００２２】
ユーザに見えないリンキングのもう１つの使い方は、システム７のエディション・マネージャ(Edition Manager) によって実行される関数を実装することである。ユーザはドローイングの一部を公表し、ワード・プロセッシング・ドキュメントの中でそのデータに署名することが可能である。内部的には、システムはドキュメント間のリンクを作成し、おそらく、リンクの性質（例えば、どちらの端がデータのソースであるか）を示す属性をリンクに付けることになる。リンクの存在はユーザに見えないようにすることができる。
【００２３】
ドローイングの変更は、リンクを介してワード・プロセッシング・ドキュメントに送られる。ドキュメント・フレームワークでは、リンクのどちらの端が転送を開始するかを制限していない。ユーザはデスティネーションからデータのソースへ（ワード・プロセッシング・ドキュメントからドローイング・ドキュメントへ）ナビゲート（たどっていくこと）することができる。ドキュメント・フレームワークでは、すべてのリンクが双方向であるので、反対方向へナビゲートすることもサポートしている。
【００２４】
ドキュメント・フレームワークのモデルは、単純コピーとペーストの働き方も向上する。マッキントッシュでは、アプリケーションはクリップボード(Clipboard) 内のデータ・モデルのタイプに応じて、ペースト・コマンドを３通りの方法で取り扱っている。(1) ドキュメントはペースト・データを完全に理解できるので、そのデータはドキュメントのファースト・クラス部分となる。(2) 受入れ側ドキュメントは受け入れたデータを表示できるが、それを操作することはできない。代表例として、テキスト・ドキュメントの中にペーストされた絵がある。この場合、受け入れたデータは表示できるが、編集することはできない。(3) 受け入れたデータ・タイプは受入れ側ドキュメントには理解されない。この例では、ペースト・コマンドは完了できないので、使用禁止にされるはずである。
【００２５】
データを取り込むことができない場合は、モデルの形で受入れ側ドキュメントに組み込むことができる。モデルはデータの編集可能プレゼンテーションを作成するときの汎用プロトコルをサポートしているので、組み込まれたデータは、マッキントッシュでそうであるように「デッド(dead)」になっていない。その代わりに、ユーザは組込みモデル(embedded model)をオープンして、そこに入っているデータを表示または編集することができる。この機能はＨＰ社のNew WaveシステムまたはMicrosoft 社のＯＬＥ仕様に用意されているものと似ている。重要な違いは、オブジェクト指向ドキュメント・フレームワークによると、開発者が新しいデータ・タイプを実装することが容易化されることである。最後に、アプリケーションが組込みモデルをサポートしていれば、すべてのタイプのデータをペーストすることができる。ペースト・コマンドは、クリップボードが空になっていない限り、使用禁止にされることはない。
【００２６】
エターナル・アンドゥ
（永続的取消し）
大部分のマッキントッシュ・アプリケーションでは、アンドゥ・コマンドは、最後の変更だけがアンドゥできる（取り消しできる）ことから貴重になっている。ドキュメント・フレームワークでは、MacAppと同じ種類のコマンド・オブジェクトを使用しているが、可能な限り多くのコマンド・オブジェクトをセーブしている。
【００２７】
この決定には、いくつかの利点がある。第一に、どのコマンドをアンドゥ可能にするかは好みの問題であり、その選択は大して重要ではない。例えば、既存のマッキントッシュ・アプリケーションでは、作成が困難なセレクションがあったとしても、セレクションに対する変更はアンドゥ可能になっていない。ドローイング・プログラム(drawing program) では、ユーザは形状の正しい組合せを選択するのに大量の時間を消費し、余計なクリックを行ったためにすべてを失うことがある。システムが１レベルのアンドゥだけをサポートしているときは、セレクションの変更をセーブすることは、例えば、最後の Cutコマンドのことを忘れることを意味するので賢明な方法ではない。アンドゥが多重レベルになっているときは、セレクションの変更をセーブすることは実現可能である。
【００２８】
コマンド・オブジェクトを使用することから得られるもう１つの利点は、信頼性の向上である。すべてのコマンドをセーブしておけば、アプリケーションまたはシステムにクラッシュが起こったとき、これらのコマンドを復元することが可能になる。ドキュメント・フレームワークでは、並行性制御(concurrency control)と回復クラスを使用して、コマンド・オブジェクトをクラッシュに強い方法でセーブしている。クラッシュが起こった場合、ユーザが失うのは、最後のカップルのコマンドだけである。マルチレベル・アンドゥによると、正しい方法でコマンド・リストを可視化し、ナビゲートする負担が増加することになる。セレクションの変更が含まれていると、ユーザが非常に多数のコマンドを作ることが容易になるので、このことが特に起こる。
【００２９】
図３は、ドキュメント・フレームワークによるコマンド・オブジェクト３０２のリニア・リスト(linear list) ３００を示したもので、これはスタックに似ている。アンドゥ処理を行う方法は他にも多数ある。このことは、アンドゥ３０６はドキュメントを以前の状態（ステート）に戻すことを意味する。また、その意図は、ユーザがコマンド３０４を選択的にアンドゥできるようにすることである（つまり、Cut コマンドがアンドゥされても、そのあとに続くコマンドはすべてそのまま残されている）。ここで注意すべきことは、コマンドが相互に依存することである。ある形状をコピーするコマンドは、その形状を最初に作成したコマンドに依存する。これらの依存関係は、アンドゥするユーザ・インタフェースだけでなく、その基礎となるインプリメンテーションも複雑化することになる。
【００３０】
上記の解決法は、例えば、アンドゥとスクリプティング(scripting) メカニズムを統合化して、完了したすべてのもののスクリプトを自動的に作成するようにすることである。そうすれば、ユーザは恣意的なコマンドを除去し、コマンドを並べ換える、といったことを行うようにスクリプトを編集し、そのスクリプトを実行することができる。このようにすると、ユーザは最大の柔軟性が得られ、制御を強化することができる。
【００３１】
内容ベース検索
ユーザがコンピュータで利用できる情報はますます増加している。ローカル・ハード・ディスクは大容量化し、数百メガバイトのデータを収容できるCD-ROMが多数出現している。システムからのなんらかの援助がなければ、このデータをブラウズ(browse)することは不可能である。マッキントッシュでは、標準ツールとしてFind File が使用され、これはドキュメント名に基づいてドキュメントを探索していた。システム７にはFind（探索）コマンドが用意されているが、これはFinderに組み込まれている。サード・パーティ開発者もFind File の機能を越えるツールを提供している。このツールはドキュメントの内容に基づいてドキュメントを探索するが、システムと一体化するのに適していない。
【００３２】
重要なことは、これらの検索ツールをシステムに一体化しておくことである。ユーザがドキュメントを扱うことができなければ、ドキュメントを探し出しても殆ど意味がない。マッキントッシュで使用されるサード・パーティの内容ベース検索ツールは、ドキュメントの内容を調べるとき、あるいは該当のアプリケーションでドキュメントをオープンするときでも、システムがサポートしていない。
【００３３】
図４はドキュメント・フレームワークの汎用検索フレームワークを示し、情報のソース４００から検索するものである。このフレームワークはインデクシング４０２と照会(query) ４０４の両方を取り扱っている。将来、多数のオペレーティング・システムがデフォルトのインデクシングと照会パッケージと共に発表されることがあっても、ユーザが望んでいることは、新しい探索パッケージを基本フレームワークにプラグインできることである。フレームワークを設計するときの主眼点は、バックグランドのインデクシング・メカニズムと照会ユーザ・インタフェースがその基礎となる検索テクノロジに関係なく、同じになるようにすることである。
【００３４】
フレームワークは、ドキュメントがボリュームに追加されたり、変更されたときドキュメントのインデクシングをバックグランドで自動的に行うようになっている。検索システムは、ドキュメントの一部だけがインデクシングされるようでは価値がないものとなり、この負担をユーザに負わせることは合理的でない。汎用照会フロントエンド(generic query front-end) によると、ユーザは新しい検索エンジンをインストールできるので、新しいフロントエンドを学ぶ必要がなくなる。
【００３５】
開発者側から見たクラス
このセクションでは、クラスとメンバ関数について説明する。ある種の規則に従っている。すべてのクラスは仮想デストラクタ(virtual destructor)をもっている。ここで説明するデストラクタは、ストレージの解放以上のことを行うデストラクタである。それ以外のデストラクタは説明されていない。ストリーミング演算子のように、MCollectible（図５のエレメント５００）から継承されたメソッドはここでは説明していない。クラスの多くはゲッタ(getter)とセッタ (setter)をもち、これらはフィールド・アクセスを行うだけである。
【００３６】
オブジェクト・サロゲート
(Object Surrogates)
ドキュメント・フレームワークのいくつかのオブジェクトには、オブジェクト・サロゲート（代理）が用意されており、これらは、現実オブジェクトへのコンパクトな、アドレス空間独立な参照として働く。このようなサロゲートの使い方は「明示のマスタとサロゲート」と言うことができる。数少ないケースでは、サロゲートと現実オブジェクトは互換性のある使い方が可能であるが、大部分のケースでは、サロゲートは現実オブジェクトを探すときの「キー」の働きをする。すべてのケースでは、サロゲートと現実オブジェクトとの関係は共通の抽象基底クラスによって定義される。抽象基底クラスは、オブジェクトに対するアドレス空間独立な識別を提供し、オブジェクト間を比較するときのプロトコル(IsEqual) を実装している。これにより、サロゲートを現実オブジェクトと直接に突き合わせて比較し、現実オブジェクト群までのキーとして使用して探索(lookup)を行うことができる。サロゲート・オブジェクトは、現実オブジェクトからサロゲートを作成するコンストラクタ(constructor) を提供することにより、サロゲートの作成を容易化している。
【００３７】
例えば、TModelSelectionsはアドレス空間独立な方法でTModelオブジェクトを識別して、コマンドが複数のコラボレータのアドレス空間に置かれたデータをアクセスできるようにする必要がある。TModelとTModelSurrogate は共に共通の基底クラスTAbstractModelから派生している。TAbstractModelはオブジェクトのアドレス空間独立な識別を提供し、オブジェクト間の比較を行うプロトコルを実装している。TModelは、現実モデルをサロゲートから探索(lookup)するための静的メンバ関数を用意している。セレクションがストリーム化されるとき、それが参照するモデルのサロゲートだけをストリーム化する。コマンドがそのセレクションを通してデータをアクセスしようとすると、現実モデルはサロゲートを使用して探索されて、コマンドが現実モデル・データをアクセスできるようにする。
【００３８】
データ表現
(Data Representation)
図５は表現クラス(Representation class)を示している。特定のデータ・タイプのデータをカプセル化する抽象基底クラスはTModel５０６である。TModel５０６の派生クラス(derived class) は「ドキュメント」データのコンテナ(container) である。これらは、モデルに収められたデータをアクセスして変更するときのタイプ別のプロトコルを用意している。また、これらは、他のモデルを組み込むことと、他のモデルに組み込まれることをサポートする汎用プロトコルをオーバライドしなければならない。これは大部分が、セレクションとユーザ・インタフェースをデータに基づいて作成するプロトコルをオーバライドすることにより行われる。
【００３９】
TModelオブジェクト５０６は、そこに収められたデータの変更の通知を、関係するオブジェクト（代表例としてプレゼンテーション）へ送る働きもする。この通知は、基礎となるシステムに標準通知機能が用意されていれば、その機能を使用して与えることが可能である。モデル通知の詳しい説明は、「データ・プレゼンテーション」のセクションに下述されている。
【００４０】
クラスTModelSurrogate ５０４は、実際のTModel５０６のライトウェイト・スタンドイン(lightweight stand-in)、つまり、それを表す「名前」の働きをする。これは実際にはデータを収めていない。現実モデルだけがデータを収めているが、TModelによってサポートされる動作（振舞い）のサブセットに関するプロトコルを用意している。具体的には、「ワークスペース」内に現れて、操作するために必要な動作である。TModelSurrogate ５０４とTModel５０６が共有する動作は共通の基底クラスTAbstractModel５０２によって定義されている。
【００４１】
複合ドキュメント構造
図６にエレメント６００で示すように、ドキュメントは多数のモデルを収容することができ、これらのモデルは多数の異なるクラスにすることができる。ドキュメントの基本構造は、ドキュメントの包含階層(containership hierarchy) を反映したモデル階層である。単一モデルが階層のルートに存在し、これは「ルート・モデル(root model)」と呼ばれる。階層内の各モデルは、そこに組み込まれた他のモデルのコンテナとなることできる。コンテナ・モデルは、その組込みモデルへの参照をモデル・サロゲートにより行う。Ｃ++ポインタを使用してはならないのは、組込みモデルが別々のコンテキストを使用してコンテナからファイルされることがあり、必ずしもコンテナと一緒にメモリに置かれているとは限らないためである。サロゲートを通してモデルをアクセスすると、モデルはそれがまだメモリになければ、自動的にファイル・インされる。オプションとして、組込みドキュメントは、有向非循環グラフ(directed acyclic graph)にすることができる。マルチカラム・テキストは次のように実現することができる。つまり、テキストの個別カラムは、すべてが単一の共有テキストフロー・モデルを組み込んでいるモデルとなっていく。また、各モデルを相互に独立してロックするようにすると、複雑化するという犠牲を伴うが、潜在的並行性を強化することができる。
【００４２】
図６に示す「標準例」は、特定のモデル階層を示している。ドキュメントに含まれたプレゼンテーションをもつ、階層内の各モデルは関連のTUserInterface（これ自身も、ユーザ・インタフェース・モデルを収めているモデルである）をもっている。特定モデルのTUserInterfaceはそのモデルによって管理され、そのモデルを通してのみアクセス可能である。直接には表示されず、別の「プレゼンテーション・モデル」を通して表示されるモデルは、関連のTUserInterfaceをもっていない。例えば、TGraphModel を通してのみ分布図(scatter plot)として表示されるTTableModel はTUserInterfaceをもたないのに対し、TGraphModel がTUserInterfaceをもっているのは、プレゼンテーションをユーザに提供するからである。
【００４３】
図７は図６のドキュメントの階層的性質を示している。具体的には、セクション０〜５は他のタイプの情報内に組み込むことができる種々タイプの情報を表している。例えば、セクション１はTaligent（登録商標）のテキストであり、これは、セクション２に示すTaligent（登録商標）というロゴに組み込まれている。図７の右下隅は図６のドキュメントの階層構造を示している。
【００４４】
データ・タイプ
複合ドキュメント・アーキテクチャは、多数のデータ・タイプをシームレス(seamless)に統合化することをサポートしている。データ・タイプとしては、音声、グラフィックス、ビットマップ・イメージ、ピクチャ、テーブル、ビデオ、テキスト、財務データ、ファイル、プログラム・コンポーネントがあるが、これらに限定されるものではない。ほとんどどのような可視または音響データ・タイプでも、シームレスに複合ドキュメントに組み入れることが可能である。
【００４５】
組込みモデルの管理
TModelに収められた組込みモデルを管理する実装を用意するのは、TModelの派生クラスの責任である。TModelがそのための実装を用意しないのは、組込みモデルがコンテナのデータ構造に収まるようにする方法が非常にデータに依存するためである。ドキュメント・フレームワークには、単純化した組込みを行う実装を提供するTContainerModel が含まれおり、この実装では、組込みモデルのプレゼンテーションは、収容するプレゼンテーション上を「浮動(float) 」するだけになっている。
【００４６】
コピー、ストリーミングおよびファイリング
別のモデルに組み込まれているモデルは、コピーとストリーミングを行う目的上、収容するモデルのデータの一部であるとみなされる。あるモデルがコピー、ストリーミングまたはファイリングされるとき、そのモデルに収められた組込みモデルはその目的に合った方法で扱わなければならない。TModelにはデフォルトの実装が用意されているので、組込みモデルは、これらのケースではその通りに扱われる。
【００４７】
ストリーミング
TModelに用意されている標準ストリーミング演算子(operator>>=およびoperator<<=)は、アンカとリンクを含めて、TModelが所有するすべてのデータをストリーム化する。これらのストリーミング演算子は、ストリーム化しようとするモデル内に収められた組込みモデルをストリーム化することも取り扱う。派生クラスはこれらの演算子をオーバライドして自身のデータをストリーム化する。モデルが組込みモデルを収めているときは、これらのモデルのサロゲートだけをストリーム化する必要がある。継承されたストリーミング演算子は現実の組込みモデルをストリーム化することを取り扱う。ストリーミングによってデータをファイルするモデルの場合は、これらのメソッドはファイリング・メソッドと同じにすることができる。そのような場合には、通常望ましいことは、ストリーミング演算子とファイリング・メソッドの両方によってコールできるプライベート・ヘルパ関数(private helper function) を作成することである。
【００４８】
コピー
モデル全体をコピーするとき、あるいは選択したデータをモデルからコピーするときは、組込みモデルをコンテナによってコピーしなければならない。これは組込みモデルのTModelSurrogate の"CopyModel" メソッドを使用すると、簡単に行われる。このメソッドはサロゲートと現実モデルをコピーして、一貫性のある新しいモデル／サロゲートのペアが得られるようにする。
【００４９】
ファイリング
モデルをファイリングするときは、その組込みモデルもファイリングしなければならない。組込みモデルはコンテナから独立にファイリングして、組込みモデル用のストレージをカストマイズできるようにしなければならない。あるモデルがそのデータをFileOutData() にファイルすることを要求されたときは、そこに収められた組込みモデルのサロゲートだけをファイルする。組込みモデルはドキュメント・フレームワークによって自動的にファイルされる。ファイルされたサロゲートはFileInData()に読み戻されて、現実モデルをアクセスするために使用できる。ドキュメント内のダーティ(dirty) モデルはすべて、常に一緒にファイル・アウトされる。このようにすると、ロールフォワード(Roll-Forward)ログの取扱いが単純化される。モデルはモデル・サロゲートから要求されたとき個別にファイル・インされる。
【００５０】
新しいモデルがドキュメントに追加されるときは、自分用の新しいストアを作成する機会をそのモデルに与えなければならない。メソッドCreateModelStore()がコールされ、ドキュメント・ルート・モデルのストアが渡される。このストアがモデルに見合ったものであれば、新しいストアは作成されない。そうでないときは、組込みモデルは、そのストレージ要求量に見合った新しいストアを作成して使用する。ストアの実際の作成はゆっくりと行なわれるので、一時的使用を目的にメモリに作成され、ストアを必要としないモデルはストアを作成しない。
【００５１】
あるモデルがドキュメントから除去されるときは、メモリとストレージの両方からそのモデルを削除しなければならない。モデルを削除すると、そのモデルはメモリとストアの両方から削除される。モデルをメモリだけから削除するときは削除をコールしなくても、メソッドTModel::DeleteFromMemoryOnly()が使用できる。
【００５２】
並行性制御
単一のモニタはドキュメント内のすべてのデータを保護する。TModelEntry オブジェクトをスタック上に作成すると、このモニタに入る。
【００５３】
属性
TModelには、モデルに属性を付けるための拡張可能インタフェースと実装が用意されている。属性はモデル階層を通して継承可能である。つまり、あるモデルはその先祖から属性を継承することができる。TModelは、モデル内の特定のセレクションで属性を調べ、先祖をその調査に含めたり、除外したりすることをサポートする。属性は単純属性グループ内で維持され、TInheritableAttributeGroupを使用しないで、独自に継承を行なうことをサポートしている。これは、階層内のすべてのモデルが同時にメモリに置かれているとは限らず、この動作はTInheritableAttributeGroup によってサポートされないからである。
【００５４】
TAbstractModel
TAbstractModelは、TModelと TModelSurrogateの基底クラスである。これはこれらのクラスの両方に共通のプロトコルを用意し、現実クラスとサロゲート・クラス間の共通基底クラスを用意している。これについては、本明細書の「オブジェクト・サロゲート」セクションに説明されている。TAbstractModelは抽象基底クラスである。これは、派生クラスの一部としてのみインスタンシエイト(instantiate) される。モデルのストレージへのアクセスを可能にするメソッドとしては、次のものがある。１）SetModelStoreReference、２）AdoptModelStoreReference、３）CopyModelStoreReference 、４）GetModelStore 。TModelとTModelSurrogate はTAbstractModelから派生する唯一のクラスである。TAbstractModelは抽象クラスであるので、常に派生クラスの一部として作成され、削除される。TAbstractModelによってその実装の一部として作成されたデータはそのクラスによって管理される。
【００５５】
TModelSurrogate
TModelSurrogate は、TModelのライトウェイト「スタンドイン」または「名前」となるもので、ストレージに置かれた現実モデルを完全にアドレスできる機能を備えている。TModelSurrogate は、１つのTModelに対していくつでも存在することができる。TModelSurrogate は、コラボレーションの目的のために、TModelのアドレス空間独立な指定子としての働きもする。TModelSurrogate は具象クラス(concrete class)であり、自由にインスタンシエイトし、壊すことができる。TModelSurrogate は、TAbstractModelの抽象関数のすべてに対する具体的実装を用意している。このサロゲートによって表わされた現実モデルへのアクセスと管理をサポートするメソッドとしては、１）GetModel、２）CopyModel 、３）DeleteModel がある。モデルのアンカへのアクセスを可能にするメソッドとしては、１）CopyAnchor、２）CreateAnchorIteratorがある。サロゲートによって表わされたモデルのプレゼンテーションをサポートするメソッドとしては、次のものがある。これらのプレゼンテーションは静的であり、現実モデルの内容に対する変更を反映していない。１）CreateIcon、２）CreateThumbnail 。
【００５６】
TModel
図８はTModel８００を示しているが、これは、アンカとリンクを含めてすべてのドキュメント・データ８０２のコンテナであり、カット／コピー／ペーストを行なうときのデータ交換の単位となるものである。ここには、データを異質のデータ・モデルに組み込むこと８０４および／または異質のデータ・モデルをそこに組み込むことをサポートするプロトコルが用意されている。基底クラスTModelは、モデルのアンカ８０６とリンク８０８を管理するための実装を用意している。サブクラスは、タイプ別のデータをアクセスし、管理するためのプロトコルと実装を用意している。さらに、サブクラスはユーザ・インタフェース、セレクションを作成し、組込みモデルをアクセスするための基底クラス・プロトコルを実装していなければならない。TModelはMDelegatingNotifier から派生しているので、そこに結合すると、モデルのデータ８１０に対する変更の通知を得ることができる。TDocument 内のすべてのモデルはTModelクラス通知子(notifier)を共有し、すべてのコールをその通知子に委任する。いくつかのメンバ関数は、モデルのユーザ・インタフェース・モデルの管理をサポートしている。サブクラスはCreateUserInterface をオーバライドして、そのモデル用の該当ユーザ・インタフェースを作成しなければならない。将来は、インタフェースの選択は、ユーザの好みに合わせて判断できるようになるはずである。メンバ関数には、次のものがある。１）CreateUserInterface 、２）AdoptUserInterface、３）GetUserInterface、４）GetUserInterfaceSurrogate 。モデルのアンカとリンク群をアクセスし、変更することをサポートすると共に、モデルに関連する属性をアクセスし、変更することをサポートするメンバ関数も、非常に多数ある。
【００５７】
データ・プレゼンテーション
通知クラス
TModelに収められたデータは、ユーザが表示しおよび／または変更できるものでなければ、ほとんど無価値である。ドキュメント・フレームワークは、データ・プレゼンテーションを実装するために必要なクラスを直接には提供していないが、ドキュメント・フレームワークはモデルでプレゼンテーションを管理することをサポートしている。このセクションで通知を中心に説明しているのは、これがドキュメント・フレームワークによって直接に提供されるプレゼンテーション・サポートの範囲であるためである。例えば、他のプレゼンテーション・サポートはすべて、オブジェクト指向ユーザ・インタフェース・ツールボックス(User Interface ToolBox)から得ることができる。
【００５８】
ユーザ・インタフェースの管理
ドキュメント・フレームワークは、モデルのユーザ・インタフェースを管理することをサポートしている。モデルの関連ユーザ・インタフェースを作成し、ストアし、検索するときのプロトコルはTModelから提供される。TModelのクライアントは、モデルにそのユーザ・インタフェースを要求することができる。そのあと、クライアントはユーザ・インタフェースに対し組み込まれたプレゼンテーションまたはウィンドウ・プレゼンテーションを要求することができる。ドキュメント・フレームワークは、ユーザ・インタフェースの内容をサポートしていない。そのアクセスとストレージを管理することをサポートしているだけである。TModelのこの機能の説明については、「データ表現」のセクションに記載されている。
【００５９】
通知
図９は、ドキュメント・フレームワークの通知システムを示している。ドキュメント・フレームワークによれば、モデルに収められたデータに行われたすべての変更の変更通知は、TModelのクライアント（クライアントの代表例としては、プレゼンテーション・ビュウがある）に対して行なわれる。プレゼンテーションをモデルに結合すると、モデルのデータに対する特定の変更またはすべての変更の通知が得られる。通知を受けたときプレゼンテーションに正しい更新を行うことにより、プレゼンテーションは基礎となるデータとの同期が保たれる。TModelはそれが管理するデータ、具体的には、アンカとリンクに対する変更の通知をTLinkNotification ９０６とTAnchorNotification ９０８を通して、セレクションに対する変更の通知をTSelectionNotification９０２を通して行う。標準通知はカット／コピー／ペースト操作に関するものが用意されている（これは図に示されていない）。ドキュメント・フレームワークに関係する他の通知も用意されている。例えば、TDualSelectionNotificationは、デュアル・セレクション(dual selection)の通知を行う。そのモデルのデータに特定する通知を行うのはTModelのサブクラスの責任である。これらの通知はプレゼンテーションが基礎となるデータと統一性を保つように十分になっていなければならない。
【００６０】
データ指定
(Data Specification)
ドキュメント・フレームワークでは、ドキュメント・データの指定をサポートするクラスはTModelSelection である。ここで注意すべきことは、モデル・セレクションは実際には選択したデータを指定することであり、実際にはデータを収めていないことである。さらに、この指定はアドレス空間から独立した方法でデータを識別して、セレクションが複数のコラボレータのアドレス空間で適用できるようになっていなければならない。ドキュメント・フレームワークはデータを全モデルの粒度(glanularity) で管理し、全モデルに作用を及ぼすデフォルトの機能を用意している。TModelSelection も例外でない。TModelSelection は選択したモデルを指定するときのプロトコルと実装を用意している。代表例として、TModelの派生クラスの実装には、TModelSelection の対応する派生クラスが用意され、モデルに収められたデータを、全モデルよりも細い粒度で指定することをサポートしている。これにより、全モデルにではなく、あるモデル内のデータのサブセットにコマンドを適用することが可能になっている。
【００６１】
データ交換
図１０は指定クラス(specification class) を示し、これにはTModelSelection １００２とMCollectible１０００が含まれている。TModelSelection １００２は、データをセレクション・オブジェクト間でやりとりするときのプロトコルを定義している。このプロトコルは、ドキュメント・フレームワークに用意されている、複数の標準コマンドによって使用される。そのようなコマンドとしては、カット、コピー、ペースト、プッシュおよびプル・コマンドがある。TModelSelection １００２はセレクション間でやりとりされるデータ・タイプを交渉するときのプロトコルを用意している。ソース・セレクションは、そこから選択したデータを得ることができるモデル・タイプのリストを作成する。デスティネーション・セレクションは、どのタイプのモデルの中のデータを受信し、そのデータをどのように受信するか（取り込むか、組み込むか）を選択する。タイプ交渉プロセスを通してタイプが選択されたあと、選択したタイプの中のデータのコピーを、CopyDataをコールすることによってソース・セレクションに要求する。返されたモデルは、タイプ交渉でデータをどのように受信するかをセレクションが示していたかに応じて、AbsorbDataまたはEmbedData に入れてデスティネーション・セレクションに渡される。この交渉は、アンカ間でデータをやりとりするときドキュメント・チーム間で行うことができる。その場合は、TRemoteDocument のサービスはリモート情報をアクセスするために使用される。上述した交換プロセス全体は、TPasteCommand またはTPushDataCommandなどの、コマンド・オブジェクトによって行われるのが代表的である。
【００６２】
TModelSelection
クラスTModelSelection １００２は、ドキュメント・セレクションおよびアンカ（持続的セレクション）が実装するものと予想されるプロトコルの大部分を用意している。これは、すべてのセレクション・オブジェクトの基底クラスの働きをする。TModelSelection オブジェクトは、カット、コピー、およびペーストを使用してまたはプッシュ／プル（アンカ上で）を使用して、セレクション間でデータをやりとりするときのプロトコルを収めている。この中には、タイプ交渉（どのタイプでこのデータを公表できるか、どのタイプでデータを受け取ることができるかといったこと）のプロトコルおよび特定のタイプでデータを公表または受け取るときのプロトコルが含まれている。
【００６３】
メンバ関数CreatePreferredType、 ChoosePreferredType 、およびGetTypeAcceptKind はMTypteNegotiatorから継承され、セレクション間でデータをやりとりするときのタイプ交渉をサポートしている。アンカをセレクションに追加し、除去し、作成するためのメンバ関数も用意されている。また、関連モデルの特定タイプのデータのやりとりをサポートするメンバ関数も用意されている。サブクラスは、アンカおよびリンクをコピーすることについては気にする必要がない。これはTModelSelection によって自動的に処理される。インポートまたはエクスポート時にアンカを調整する必要があるとき、オーバライドするためのメンバ関数も用意されている（例えば、テキスト内のアンカは、エクスポート時にはエクスポートされるデータに、インポート時には収容するテキストに相対するように調整する必要がある）。
【００６４】
データ変更
図１１は、データ変更を行うときに必要な基本的関係を示す図である。
TModelCommandGroup１１０４、 TModelCommand１１０２およびTCommand１１００は相互に協力しあって、システム内で要求される必要な変更を提供する。
【００６５】
変更クラス
ドキュメント・フレームワークでは、ユーザによって作られるコマンドを表す抽象クラスは TModelCommand１１０２である。TModelCommand １１０２のサブクラスはユーザ・アクションのセマンティックスをカプセル化しており、ユーザ・アクションに基づいてモデルを変更することができる。コマンド・オブジェクトは「実行(done)」、「取消し(undone)」および「やり直し(redone)」することができ、これらを作成するときに使用されるユーザ・インタフェース手法から独立しているのが代表的である。
【００６６】
TModelCommand １１０２
TModelCommand １１０２は TCommand １１００クラスの派生クラスである。TModelCommand １１０２オブジェクトはモデルを変更するユーザ・アクションをカプセル化している。TModelCommand は、モデルに対する変更を実行し、取り消しおよびやり直し、コマンドを出したコラボレータを識別し、変更を増分的に (incrementally) 実行することを、ドラッグやタイピングのときと同じように行うためのプロトコルをもっている。
【００６７】
TModelCommand オブジェクト１１０２はコマンド・オブジェクトの一部となり得るセレクションに作用するのが一般であり、より一般的には、現ドキュメント・セレクションに作用する。基底クラスTModelCommand １１０２は、すべてのモデル・コマンド・オブジェクトが応答するプロトコルを用意している。サブクラスは"HandleXXX" メソッドをオーバライドして特定の動作を提供する。
【００６８】
いくつかのTModelCommand は増分的に実行されることを目的としている。これらのコマンドを使用すると、ユーザはモデルを増分的に変更していくことができる。これらのコマンドは反復コマンド(repeating command) と呼ばれる。反復コマンドの一例として、ドローイング・プログラムの形状ドラッギング(shape dragging) コマンドがある。トラッキング(tracking)コマンドはモデルを多くの中間状態を通過させることがあっても、このコマンドは１つのコマンドとしてカウントされる。このことは、コマンドの全体効果は１つのアトミック・アクション(atomic action) として取り消され(undo)、やり直される(redo)ことを意味する。
【００６９】
ドキュメント・フレームワークは、Undoのフレームワークではコマンド・オブジェクトの考え方を採用している。コマンド・オブジェクトはドキュメント・フレームワークのコラボレーション機能の中心にもなっている。
【００７０】
モデル・ベース・トラッキングの詳細
図１２は、ドキュメント・フレームワークでトラッキング・オペレーションのある部分を実行するときの、起こり得る処理の流れを示す概略図である。１２００に示すように、トラッカ(tracker) がDoBegin() をコールすると、コマンド引数はフラット化され（１２０２）、１２０４でコラボレーション・サーバへ送られる。そこから、この引数は再びフラット化され、コラボレータの各々へ送られる。各コラボレータでは、コマンドのHandleDoBegin() メソッドが１２０６に示すように実行される。
【００７１】
図１３は、ドキュメント・フレームワークでトラッキング・オペレーションの別の部分を実行するときの、起こり得る処理の流れを示す概略図である。トラッカが１３００に示すようにDoRepeat()をコールすると、コマンド引数はデルタ情報１３０２をストリーム・アウトするように要求される。コマンド・デルタは１３０４でコラボレーション・サーバへ送られる。そこから、デルタはコラボレータの各々へ送られる。各コラボレータでは、デルタは、１３０６に示すように、コマンドのローカル・コピーにストリーム・インされる。そのあと、コマンドのHandleDoRepeat()メソッドが実行される。
【００７２】
トラッカがDoEnd() をコールすると、図１３に示すものと同じようなオペレーションが実行される。コマンド引数はデルタ情報をストリーム・アウトするように要求される。コマンド・デルタはコラボレーション・サーバへ送られる。そこから、デルタはコラボレータの各々へ送られる。各コラボレータでは、デルタはコマンドのローカル・コピーにストリーム・インされる。そのあと、コマンドのHandleDoEnd() メソッドが実行される。増分コマンド(incremental command) がその拡張Ｄｏフェーズを終了できる方法は２つある。標準的方法はDoEnd() がコールされる場合である。もう１つの方法は、トラッキングを行っているコラボレータが予期しないでコラボレーションから出る場合である。その場合は、コラボレーション・サーバ側のコマンドはそのHandleCollaboratorDied()メソッドがコールされている。拡張Ｄｏフェーズが終了すると、コマンドはそのHandleDo()メソッドがコールされたのと同じ状態にあるものと期待される。
【００７３】
TModelCommandGroup: TModelCommandGroupは TModelCommandのサブクラスであり、複雑なコマンドを複数の単純コマンドから作ることを容易化する。TModelCommandGroupは大部分のメソッド（例えば、HandleDo）をグループ内のコマンドの各々に委任する。すべてのコマンドでHandleLocalDo がコールされ、そのあとすべてのコマンドでHandleDoがコールされるという意味で、コマンドは逐次化されていない。あるコマンドのHandleLocalDo がそれより以前のコマンドのHandleDoでセットされた状態に依存する場合は、これは働かないことになる。コマンド・グループに含まれるコマンドの管理をサポートするメンバ関数には、AdoptFirst、 AdoptLast、Orphan、OrphanAll がある。
【００７４】
標準コマンド
以下に示すコマンドはすべて、ドキュメント・フレームワークに用意されている標準コマンドである。
【００７５】
TSelectCommand: TSelectCommandが出されるのは、セレクションを変更するときである。TSelectCommandは、セレクションを直接に操作することをサポートする増分コマンドである。このコマンドはコマンドを開始するコラボレーション用にセレクションをセットし、他のコラボレータのセレクションには影響しない。
【００７６】
TCutCommand: TCutCommandには、現セレクションをドキュメントからカットするというローカル効果がある。また、なにかをクリップボードに追加するというグローバル効果がある。ローカル効果は TReplaceSelectionコマンドをサブクラス化することにより達成される。
【００７７】
TCopyCommand: TCopyCommandにはローカル効果はない。なにかをクリップボード上に置くというグローバル効果がある。
【００７８】
TPasteCommand: TPasteCommandは、現セレクションをクリップボード上のデータで置き換える。これは、TReplaceSelection コマンドをサブクラス化することにより達成される。
【００７９】
TReplaceSelectionCommand: TReplaceSelectionCommandは、セレクションまたはアンカによって指定されたデータを、コマンド・オブジェクトにカプセル化されたデータで置き換える。コマンド・オブジェクトは、セレクションのデータを置き換えるために使用される TModel を収めている。TReplaceSelectionCommandはユーザが作成しないのが通例である。ドキュメント・フレームワークはこのコマンド・オブジェクトをカット、ペースト、プッシュ、プルなどで使用する。
【００８０】
TNewAnchorCommand: TNewAnchorCommandが出されるのは、新しいアンカが作成されたときである。TStartLinkCommand は、TStartLinkのグローバル効果が行なわれたあとではTNewAnchorCommand の働きをする。
【００８１】
TNewLinkCommand: TNewLinkCommandが出されるのは、新しいリンクが作成されたときである。TCompleteLinkCommandは、そこに組み込まれている
TNewLinkCommandsを使用して TModelCommandGroup をサブクラス化する。
【００８２】
TStartLinkCommand: TStartLinkCommandには、新しいアンカを「リンクボード」上に置くというグローバル効果と、新しいアンカをドキュメントに追加するというローカル効果がある。ローカル効果はTNewAnchorCommand をサブクラス化することにより達成される。
【００８３】
TCompleteLinkCommand: TCompleteLinkCommandが行なう仕事は多数である。このコマンドには、新しいリンク・コマンドを別のドキュメント（リンク開始コマンドを出したドキュメント）に通知するという非ローカル効果（可能な場合）がある。また、アンカとリンクを現ドキュメントに追加するというローカル効果がある。これは該当のコマンド・オブジェクト(TNewAnchor とTNewLink) をその実装の中で使用して達成される。
【００８４】
TPushDataCommand: TPushDataCommandには、TPushedData コマンドをデスティネーション・アンカに通知するという非ローカル効果（可能である場合）がある。すべてのタイプ交渉はセレクション・プロトコルを通して処理される。
【００８５】
TPullDataCommand: TPullDataCommandコマンドはプル・コマンドと呼ばれることもある。これは、リンクの他端側のアンカからデータを取り出す。
【００８６】
TFollowCommand: TFollowCommandは「リンク」をたどっていく。これは、リンクの他端側のアンカを収めているドキュメントへTFollowedCommandを通知することにより行われる。
【００８７】
TFollowedCommand: TFollowedCommandは、リンク内のデスティネーション・アンカを収めているドキュメントに通知される。TFollowedCommandに組み込まれているTModelLinkの「そちら」側はデスティネーション・アンカである。デスティネーション・アンカのFollowメソッドがコールされる。このメソッドをオーバライドすると、正しいfollow動作が実装される（アンカとそのセレクションをビュウまでスクロールするのが代表例）。
【００８８】
アンカおよびリンク
図１４は、MCollectible１４００、MAbstractModeler１１０２、TModelSelection １４０４、 TModelAnchorSurrogate １１０６、およびTModelAnchor１４０８間の関係を示す図である。
【００８９】
図１５は、MCollectible１５００、 TAbstractModelLink１５０２、 TModelLinkSurrogate １５０４、およびTModelLink１５０６間の関係を示す図である。
【００９０】
アンカおよびリンク・クラス
アンカは、「スティッキ」ドキュメント・セレクションであるのが代表的である。「スティッキ(sticky)」とは、アンカによって選択されたデータがモデルで編集される変更の間で統一性があることを意味する。
【００９１】
リンクは２つのアンカを結合するコネクションである。リンクに対するオペレーションとしては、リンクの作成、リンクの除去、リンクを「たどっていく」こと、データを一方のスティッキ・セレクションから他方へプッシュすること、またはデータをプルすることがある。２つのアンカ間のリンクを作成するには、ユーザはそのアンカを指定しなければならない。これは、データをコピーしたり、ペーストするのと似ているので（ユーザはソースとデステイネーションを指定する必要がある）、これを行う１つの方法は、クリップボードに似た一種の「リンクボード」を維持することである。
【００９２】
図１６の１６００から１６０６までは、Start Linkコマンドの処理の流れを示す図である。Start Linkコマンドは、１６０２で現セレクションからアンカを作成し、そのアンカを１６０４でリンクボード上に置く。
【００９３】
図１７の１７００から１７１０までは、Complete Link コマンドの処理の流れを示す図である。Complete Link コマンドも１７０２でアンカを作成し、そのあと、新しいアンカとリンクボード上のアンカ間のリンクを１７０４で作成する。Complete Link を１７０６で何度も選択すると、処理の流れの１７０８に示すように、共通アンカを共有する複数のリンクを作ることが可能である。
【００９４】
図１８はドキュメント１８００内のリンクを示し、これはプログラムに従ってアプリケーションにより作成されたものである。リンキングの「興味のある」使い方の大部分はこのカテゴリに属するものである。例えば、リンク１８０４をもつドキュメントの影響を受ける部分に注釈１８０２を付けることができる。スクリプト１８０６はリンク１８０８をもつドキュメントの部分を参照することもできる。ここで注意すべきことは、図１８のリンクはソフトウェア構造を表したものにすぎず、リンク、スクリプト、注釈の特定のビジュアル特性、またはリンクで結合されたドキュメント部分を伝達することを目的としていないことである。ドキュメント・フレームワークには一種類のリンクしか存在しない。これは双方向リンク１８０４と１８０８で示すように双方向であり、ナビゲーション（リンクの他端を探す）とデータ転送の両方をサポートしている。
【００９５】
図１９は、リンクの特性の一部を示す図である。リンクはプロパティ１９００ももっており、これはアプリケーションが使用して、リンクを分類したり（１９０２）、リンクの使い方を制限したり（１９０４）することができる。例えば、ユーザ１９０８がリンクに対してなにを行う（１９０６）ことができるかを指定するプロパティをもつことが可能である。あるユーザだけがスプレッドシートからデータをプルすることを許し、スプレッドシートまでナビゲートしたり、データをそこにプッシュしたりするのを許さないようにすることが望ましい場合がある。注釈を実装するために使用されるリンクはある種のプロパティによって識別される。このプロパティはリンクが注釈の一部であること、該当の注釈コマンドが使用可能であることを示している。
【００９６】
最後の例は、マスタとコピーとの関係を示すリンクである。これはインポート・データで使用される。グラフの静的表現をコピーし、ペーストする代わりに、ユーザはオリジナル・グラフと、ワード・プロセッサ・ドキュメントに入っているコピーとの間のリンクを作成することができる。
【００９７】
TModelAnchorSurrogate
図１４にエレメント１４０６として示されているTModelAnchorSurrogateは、TModelAnchor１４０８のサロゲート・クラスである。これは、TModelAnchor１４０８から利用できるプロトコルのサブセットを用意している。具体的には、アンカ間のデータのやりとりをサポートするプロトコルを用意している。サロゲートのプロトコルを使用すると、クライアントはローカル・ドキュメントまたはリモート・ドキュメント内のアンカを区別しないですむ。TModelAnchor１４０８は、どのオペレーションが実行可能であるか（例えば、プッシュ、プル）といった、リンクの属性を記述した属性のリストを維持している。属性は単純属性グループ(simple attribute group)として管理される。属性を追加し、除去し、調べるためのプロトコルが用意されている。TModelAnchor１４０８はその作成者が所有し、所有権がTModelなどの別のオブジェクトに渡されていない限り、それを削除するのは作成者の責任である。重要なメンバ関数として、CreatePreferredTypelist、 ChoosePreferredTypeおよびCopyDataがある。
【００９８】
TModelAnchor
図１４にエレメント１４０８として示されているTModelAnchorは、ハイパリンクのアンカの働きをするすべての持続的セレクションの基底クラスである。TModelAnchor１４０８のデフォルト実装は、それからすべてのTModelSelection コールが委任されるTModelSelection １１０４を収めている。TModelAnchor１４０８は、どのオペレーションが実行可能であるか（例えば、プッシュ、プル）といった、リンクの属性を記述した属性のリストを維持している。属性は単純属性グループとして管理される。属性を追加し、除去し、調べるためのプロトコルが用意されている。重要なメンバ関数として、SetSelection、Follow、 Execute 、AddAttribute、スクリプティング(scripting) 、自動化テストおよびAdoptLink がある。
【００９９】
TModelLink
図１５にエレメント１５０６として示されているTModelLinkクラスは、リンクの表現を用意している。特殊化は、TModelAnchorをサブクラス化することにより行われる。TModelLink１５０６のサブクラスはない。「こちらの(here)」アンカと「そちらの(there) 」アンカは、リンク内の２つのアンカを表す名前にすぎない。TModelLink１５０６内の「こちらの」アンカは現ドキュメントの一部であるのが代表的であり、TModelのメソッドを使用すると現実のアンカに変えることができる。「そちらの」アンカは現ドキュメントの一部になることも、別のドキュメントに属することもあり得る。
【０１００】
TModelLinks １５０６も、どのオペレーションが実行できるか（例えば、プッシュ、プル）といったリンクの属性を記述したプロパティのリストを維持している。プロパティはプロパティ名と値のディクショナリとして管理される。プロパティを追加し、除去し、調べるためのプロトコルが用意されている。重要なメンバ関数として、GetHere、 GetThere、 AddAttribute およびRemoveAttribute がある。
【０１０１】
TDynamicModelAnchor
TDynamicModelAnchor は、そのデータ指定が静的でなく動的であるアンカの基底クラスである。アンカが「動的」と呼ばれるのは、アンカはアクセスされるたびに異なるドキュメント・データを指定できるためである。通常のアンカは常にドキュメント内の同じデータを参照する。例えば、動的アンカはドキュメント内の現セレクションを表すことができる。データがアンカからプッシュされたときは、そのデータはその時に現セレクションで表されていたデータになる。
【０１０２】
ドキュメントの制御と通信
このセクションでのクラスをここに含めたのは、ドキュメントがプロセス・モデルをどのように使用するかを理解しやすくするためである。クラスTDocument はチームのドキュメントを始動するために作成される。このクラスは、ドキュメント・チームのローカル制御のために必要な種々のフレームワークとサービスを作成することを担当する。この中には、コラボレーションと外部ドキュメント制御のためにサーバを開始すること、ドキュメント・ファイリング・オペレーションの制御を行うことが含まれる。クラスTRemoteDocument は他のチームのドキュメントとのリモート・インタフェースとなるものである。このクラスによると他のチームのドキュメントからデータをアクセスすることができ、これらのドキュメントをコマンドで制御することがサポートされる。
【０１０３】
モデル・ファイリング
TDocument は、ドキュメントのファイリング・オペレーションを開始することをサポートする。モデルにファイリングするとき、実際に行うべき作業はない。TModelはサロゲートから初めて要求されたとき自動的にファイルされる。モデルは、その必要があれば、コンテナによっていつでもメモリから削除することが可能である。当然のことであるが、モデルを削除するには、モデルの排他的ロックを獲得する必要があり、モデルを指すポインタをキャッシュして、モデルのロック持続期間を越えて保持していてはならない。モデル・サロゲートはモデル・ポインタをキャッシュできるが、このことはクライアントには見えないようになっている。
【０１０４】
ファイリング・アウトのときは、役割はもっと大きくなる。セーブレスのモデルをサポートし、ストレージの一貫性を維持するために、ドキュメント・フレームワークは、ストアに置かれたすべてのモデルのコマンドをそのストアにログ (log：記録）する。モデルは個別に書くことはできないが、ダーティ・モデルはすべて常に一緒に書かれる。このようにすると、モデルが書かれるときコマンド・ログ全体が各ストアから除去されるので、コマンド・ログの処理が単純化されることになる。モデルはドキュメントがクローズされると書かれるが、ドキュメントがオープンしているときは定期的にも書かれるので、システム障害が起こったときドキュメントの再始動時間が短縮されることになる。
【０１０５】
ドキュメント間通信
ドキュメント・フレームワークでは、各ドキュメントは各自のチームで実行される。ドキュメント・フレームワークの標準機能の多くをサポートするには、ドキュメントは相互間で通信できるようになっていなければならない。例えば、ハイパテキスト・リンキングによると、ドキュメント間でデータをプッシュし、プルすることができ、ドキュメント間でリンクをたどっていくことができる。この処理を行うために、図２０に示すように、ドキュメント・フレームワーク１７００は外部ドキュメント２００４のためのクライアント／サーバ・インタフェース２００２を用意している。外部ドキュメントと通信するために、ドキュメントのルート・モデルのサロゲートからTRemoteDocument が作成される。TRemoteDocument オブジェクトは、オープン、コマンドの送信、リンクの照会などを行うために使用することができる。
【０１０６】
ドキュメント始動
新しいチームは、始動される各新しいドキュメントごとに作成しなければならない。特定のルート・タイプをもつドキュメントを作成する「アプリケーション」を書くことができるが、必ずしもそのようにする必要はない。ドキュメント・フレームワークは実行時システムによってTTaskProgramの中で提供される機能を使用して、該当のオブジェクトをドキュメント・チームに作成して始動する。ドキュメントは、ドキュメントのルート・モデルのサロゲートをもつTRemoteDocument を作成し、そのあとでドキュメントの要求を行うことにより始動され、代表例としてオープンされる。これにより、ドキュメント・チームが始動され、要求されたドキュメントが用意されたサロゲートを使用してオープンされる。ドキュメントでユーザ・インタフェースをオープンすること（つまり、選択したデータをアンカからコピーすること）を必要としないような、ドキュメントの他の要求を行うことも可能である。
【０１０７】
TDocument
TDocument クラスは、ドキュメント・データのコントローラの働きをする。これは、ドキュメント・チームに必要なフレームワークとサーバを作成する。これはファイリング・プロセスの制御も行う。TDocument は、ドキュメントが始動されたときTModelApplication によって自動的にインスタンシエイトされる。重要なメンバ関数として、SetSelection、 GetSelectionがある。
【０１０８】
TRemoteDocument
このクラスは、別のチームのドキュメントをアクセスすることを可能にする。１つのドキュメントだけがチームで動作できるので、２つのドキュメントがカット／コピー、ペースト、リンキングなどの目的でやりとりするのは、この方法によってのみである。また、ドキュメントを外部から制御することを可能にする。代表的な使用例としては、リンク・ナビゲーションとデータ転送、オープニング／クロージングなどがある。リモート・ドキュメント（別のチームのドキュメント）でコマンドを実行することをサポートするメンバ関数として、Doがある。
【０１０９】
リモート・ドキュメント内のアンカとデータをやりとりすることをサポートするメンバ関数として、CreatePreferredTypeList 、ChoosePreferredType 、Copy/AnchorData およびNotifyLinkがある。リモート・ドキュメントでユーザ・インタフェースをオープンし、クローズすることをサポートするメンバ関数として、Open、Close およびIsOpenがある。ドキュメントのオープン時とクローズ時に通知を受け取ることをサポートするメンバ関数として、CreateOpenInterestとCreateCloseInterest がある。
【０１１０】
図２１は、本システムと方法の全体的システム設計を示す図である。アプリケーション層２１０２はストレージ２１０４に置かれている現ドキュメント２１０６および関連ドキュメント２１０８とフロー２１１２を通してやりとりする。アプリケーション層２１０２は、本発明のシステム・レベル・ドキュメント・フレームワーク２１１０とも、円１で示すフロー２１１４を通してやりとりする。最後に、本発明のドキュメント・フレームワーク２１１０は、ストレージ２１０４に置かれている現ドキュメント２１０６および関連ドキュメント２１０８と、円２で示すフロー２１１６を通してやりとりする。
【０１１１】
ドキュメント・フレームワーク２１１０の詳細は上述した通りである。ドキュメント・フレームワーク２１１０は、アンカとリンク・サポート２１１８、通知２１２０、コラボレーション２１２２、組込み２１２４、データ・プレゼンテーション２１２６、データ変更２１２８、マルチレベル・アンドゥ２１３０、内容ベース検索とインデクシング２１３２、複合ドキュメント・サポート２１３４、データ表現２１３６、データ指定２１３８、モデル処理２１４０、およびドキュメント通信２１４２のオブジェクトが集まったもの（コレクション）である。前述したように、オブジェクトの多くに特別な発明性があるのは、システム・レベルに置かれて、システム・レベルの他のオブジェクトと併用して関数を提供するからであるが、オブジェクトのいくつかはシステムの他のレベルで考慮の対象にすることも可能であることはもちろんである。
【０１１２】
StockTicker の例
本発明のテクノロジの実際の応用を分かりやすくするために、実生活のアプリケーションを例にして説明することにする。まず、舞台を設定するために、複合ドキュメント・テクノロジについてレビュウすることにする。モデルとは、データを収容し、データをアクセスし、変更し、ユーザに提示する機能がデータを利用できるようにするものである。プレゼンテーションとは、モデル上にビュウを提供して、ユーザが読んで編集できるようにする機能である。クリップボードとは、ユーザの環境に関連づけられていて、カット／コピー−ペースト・オペレーションでクリップボード上に置かれているモデルを収めている特殊なモデルである。
【０１１３】
このアプリケーションは、米国内の各地のMerrill Linch オフィスに設置されているストック・チッカ(stock ticker - 株相場受信機）をエミュレートしたストック・チッカを実装している。ストック・チッカは、ニューヨーク証券取引所で取り引きされる種々の株式の現在株価を提示している。これは、ニューヨーク市の証券取引所に最終的に置かれているデータベースから現在株価を入力として受信している。通信リンクはこの分野では周知であるが、例えは、ASCII 文字を伝送する非同期シリアル通信リンクにすることも可能である。ASCII 文字は、ASCII 8 ビット文字と同期するように符号化された任意の数のフォント(font)を使用して、直接にディスプレイから表示されている。ディスプレイ・メカニズムはビュウ(view)と呼ばれ、任意の数の共通ウィンドウまたは他のディスプレイ・メカニズムにすることが可能であるが、これもこの分野では周知である。クリップボード・モデルはStockTicker インスタンスであるモデルを収めている。StockTicker インスタンスとは、ストック・ディスプレイをシミュレートするように準備状態に置かれた通信およびディスプレイ情報のことである。好適実施例をどのように使用すると、異種の情報からなる複合ドキュメントを使用可能にできるかを示すために、デスティネーション・モデルがペースト・オペレーションでStockTicker インスタンスを受信する場合について説明する。
【０１１４】
デスティネーション・モデルはドキュメントの一部であり、ドキュメントの「ルート」モデルのモデルにすることも、組込みモデルにすることも可能である。ペースト・コマンドはデスティネーション・ドキュメントで出される。このコマンドは２つの指定部分を含んでいる。つまり、１）コピーしようとする、クリップボード上のソース・モデルへの参照と、２）デスティネーション・ドキュメントの中でペーストしようとするロケーションの指定である。ペースト・コマンドのオペレーションは次のようなステップで行われる。まず、デスティネーション・モデルとソース・モデルとの間でタイプ交渉のやりとりが行われる。ソースはソースから得られるタイプ・リストを用意しており、デスティネーションは望ましいタイプを選択する。この場合、デスティネーションは特定のStockTicker データ・タイプを認識しないので、それを抽象的にモデルとして受け取ってそれを組み込む。デスティネーション・サイドはStockTicker モデルの新しいコピーを得て、これはデスティネーション・モデルに受け入れられる。デスティネーション・モデルは変更されているので、変更通知メッセージをそこでオープンされたすべてのプレゼンテーションへ送る。各プレゼンテーションは通知を受け取ると、そのステート（状態）を新しいStockTicker を含んでいる新しいモデル・ステートと同期をとり直す。例えば、プレゼンテーションは、そのステートを新しいモデル・ステートから完全に生成することで行うことができる。もっと最適化されたモデル・プレゼンテーション関係では、なにが変更されたかを、もっと特殊な通知でプレゼンテーションに正確に知らせるので、プレゼンテーションは変更されたものだけを更新することができる。その結果として、プレゼンテーションはStockTicker モデルを照会して、それ自身のプレゼンテーションを生成することになる。これは複雑なオペレーションであり、以下に説明する。
【０１１５】
StockTicker モデルがその応答として、プレゼンテーション・ビュウ・インスタンスを構築するとき、このStockTicker ビュウ・サブクラスのコンストラクタ(constructor) は次のようなステップを実行する。コンストラクタはビュウ・サブクラスによって所有されるスレッドを作成し、それを始動する。スレッドは次のようなステップを実行する関数に入る。これはウィンドゥとグラフィック機能がStockTicker プレゼンテーション・ビュウにグラフィックスを表示し、絶えず更新し、アニメーション化する準備状態に置く。これの具体例として「グラフィックス・ポート(graphics port) 」機能があり、これは、このスレッドによってプレゼンテーション・ビュウ上にドローイング（描画）されるグラフィックスの通路(conduit) となるものである。そのあと、ループに入って、データのアニメーション・プレゼンテーションをドローイングし、必要に応じてストック・データについて照会する。StockTicker プレゼンテーション・ビュウが正しく構築されると、これは外側プレゼンテーションのサブビュウ(subview) として採用されるか、あるいは、もっと一般的には、組込みエンティティを全体として管理する機能をサポートする中間ビュウの内側で折り返される。
【０１１６】
以上、特定のシステム環境における好適実施例を中心にして本発明を説明してきたが、この分野に精通した当業者ならば理解されるように、本発明は、請求の範囲に明確化されている本発明の精神と範囲内で、変更を加えることにより、他の異なるハードウェアおよびソフトウェア環境で実施することも可能である。
【図面の簡単な説明】
【０１１７】
【図１】本発明の好適実施例によるパーソナル・コンピュータ・システムを示すブロック図である。
【図２】リンク、アンカ、およびモデルを示すブロック図である。
【図３】アンドゥ（取消し）に関連する関数を示すブロック図である。
【図４】本発明のシステム・レベル・インデクシングと照会処理機能を示す図である。
【図５】本発明によるクラス表現を示すブロック図である。
【図６】本発明を使用して作成できる代表的ドキュメントを示す図である。
【図７】図６に示すドキュメントの階層構造を示す図である。
【図８】TModelの一般的特性を示す図である。
【図９】ドキュメント・フレームワーク・システムと一緒に使用できる通知フレームワークを示す図である。
【図１０】指定クラスを定義している関係を示す図である。
【図１１】TModelコマンド・グループに関連する関係を示す図である。
【図１２】DoBegin() の処理の流れを示す図である。
【図１３】DoRepeat()の処理の流れを示す図である。
【図１４】TModelAnchor用に確立された関係を示す図である。
【図１５】TModelLink用に確立された関係を示す図である。
【図１６】リンクの処理を示す図である。
【図１７】完全リンク(Complete Link) の処理を示す図である。
【図１８】ドキュメントとリンクされる注釈とスクリプトの使い方を示す図である。
【図１９】システムで利用できるリンク・プロパティの一部を示す図である。
【図２０】ドキュメント・フレームワークのクライアント／サーバと外部ドキュメントとの関係を示す図である。
【図２１】本発明の方法とシステムを示すブロック図である。
【符号の説明】
【０１１８】
１０ 中央処理ユニット
１２ システム・バス
１４ ランダム・アクセス・メモリ（ＲＡＭ）
１６ リード・オンリ・メモリ（ＲＯＭ）
１８ 入出力アダプタ
２０ ディスク・ユニット
２１ 入出力周辺デバイス
２２ ユーザ・インタフェース・アダプタ
２３ データ処理ネットワーク
２４ キーボード
２６ マイクロホン
２８ スピーカ
３２ マウス
３４ 通信アダプタ
３６ ディスプレイ・アダプタ
３８ ディスプレイ・デバイス
【技術分野】
【０００１】
本発明は一般的にはコンピュータ・システムに関し、より具体的にはオブジェクト指向複合ドキュメント処理のための方法およびシステムに関する。
【背景技術】
【０００２】
本特許出願の一部には、著作権保護の対象となる内容が含まれている。著作権所有者は、米国特許商標庁の特許ファイルまたはレコードに記録されている特許文書または特許開示内容を何人もが原文通りに複製することを妨げるものではないが、その他の場合には、一切の著作権を所有することを留保する。
【０００３】
ドキュメント処理は、社会が紙を作り出す仕方に大変革をもたらした。従来の代表的ドキュメント処理システムはＤＯＳやＯＳ／２などの、オペレーティング・システム上で稼働している。最近では、これらのドキュメント処理システムはウィンドウズ環境で稼働する設計になっている。これらのドキュメント処理システムの多くは市販されている。
【０００４】
「インタメディア：シームレス情報環境の概念と構造（Intermedia：The Concept and the Construction of a Seamless Information Environment) 」という文献には、直接操作エディタとアプリケーションをサポートするオブジェクト指向フレームワークを備えたハイパメディア・システムが開示されている。ハイパメディア・システムはハイパテキスト・システムを拡張したもので、作成者または作成者グループが情報をリンクで１つに結合し、グラフィックス、テキスト、サウンドおよびビデオを含む関連マテリアルの本体を通るパス(path)を作成することを可能にしている。この機能は、ハイパメディア機能を、ハイパメディア・システムを構成する各アプリケーションに統合化することにより達成される。このハイパメディア機能は、アプリケーション開発者のためにビルディング・ブロックを提供するように基本的MacAppクラスを拡張することにより作られていた。これらのクラスは、インタメディア層を作成するようにサブクラス化されていた。この文献には、オペレーティング・システム層は言及されていない。
【０００５】
「SEPIA におけるハイパドキュメントの共同著作のサポート(Supporting Collaborative Writing of Hyperdocuments in SEPIA) 」という別の文献には、(1) ハイパテキスト共同作業に関係する背景、(2) SEPIA ハイパテキスト著作システム、(3) SEPIA による共同作業のサポートが開示されている。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上記に挙げたドキュメント処理システムはドキュメントやテキストを処理する能力を大幅に向上したが、他方では、具体的処理方法に関してドキュメント・プロセッサ間に大きな不統一性がある。これらの不統一性は、アプリケーション 開発者とアプリケーションのユーザの双方に問題を引き起こす結果になっている。
【０００７】
アプリケーション開発者にとっては、新しいドキュメント・プロセッサを構築するとき、絶えず「一からやり直さなければならない」という問題がある。オペレーティング・システムおよびインタフェース・プログラムには、使用できるツールがいくつか用意されているが、特定のドキュメント・プロセッサを設計するときの作業の大半は、ユーザがドキュメントを処理できるように相互に作用し合う処理モジュール群を作成することが中心になっている。アプリケーション開発者は、別の会社によってすでに開発されている処理モジュールを設計することがよく起こっている。そのために、作業の多くは重複することになり、各開発者は、必要とする種々の関数（機能）をどのようにインプリメント（実装）するかの詳細を取り扱うことが要求されている。
【０００８】
アプリケーション・ユーザには、他の問題が起こっている。特定の関数があるアプリケーションに存在していても、別のアプリケーションに存在しないことがある。また、あるアプリケーションで利用できる関数は、別のアプリケーションではその使い方や実行方法が若干異なっている場合もある。例えば、アプリケーションＡの関数は、その関数をアクチベートするにはある種のユーザとのやりとり（インタラクション）と入力を要求するのに対し、アプリケーションＢの同種の関数は若干異なった、あるいはまったく異なったユーザとのやりとりと入力を要求する場合がある。
【課題を解決するための手段】
【０００９】
本発明の目的は、オブジェクト指向フレームワークを利用して、特定のドキュメント処理手法をインプリメント（実装）するためのドキュメント処理システムを提供することであり、この中には、オブジェクト指向複合ドキュメント・システムが含まれる。本発明の上記目的および他の目的は、種々の複合ドキュメント処理関数（機能）をシステム・レベルでサポートするドキュメント・フレームワークによって実現されている。フレームワークはコラボレーション（共同作業）、リンキング、エターナル・アンドゥ (eternal undo−永続的取消し）、および内容ベース検索(content based retrieval) をシステム・レベルでサポートする機能を備えている。これらの目的および他の目的は、ドキュメント変更、モデルとリンキングによる注釈(annotation)、アンカ(anchor)、モデル階層(model hierarchy)、機能強化されたコピーとペースト(enhanced copy and pasting)、コマンド・オブジェクト、および汎用検索フレームワーク(generic retrieval framework)をシステム・レベルでサポートすることにより達成されている。
【発明を実施するための最良の形態】
【００１０】
以下、本発明の実施例について詳しく説明する。なお、以下に開示されている実施例は本発明を単に例示したものにすぎず、種々態様に実現することが可能であることは勿論である。従って、以下に詳述する開示内容は限定的なものではなく、請求の範囲を判断するときの基礎となり、本発明を製造および／または使用する方法を、当業者に教示するときの基礎となるにすぎないものと理解すべきである。
【００１１】
オブジェクト指向プログラミングおよびフレームワーク開発の歴史は文献に記載されている。Ｃ++とSmallTalk は文献に説明されているので、ここで詳しく説明することは省略する。同様に、カプセル化(encapsulation)、多様性(polymorphism)および継承(inheritance)といった、オブジェクトの特性は文献や特許明細書に詳しく論じられている。オブジェクト指向システムを詳しく論じた文献としては、Grady Booch 著「オブジェクト指向設計とアプリケーション(Object Oriented Design with Applications)」(ISBN 0-8053-0091-0(1991) がある。
【００１２】
多くのオブジェクト指向システムは、基本的入出力を実行する基本的オペレーティング・システム上で稼働する設計になっているが、本発明を使用すると、特定の機能（フィーチャ）をシステム・レベルでサポートすることができる。
【００１３】
本発明は、好ましくは、ＩＢＭ（登録商標）PS/2（登録商標）またはアップル社（登録商標）マッキントッシュ（登録商標）コンピュータなどのパーソナル・コンピュータに常駐したオペレーティング・システムを背景に実施される。図１は代表的なハードウェア環境を示したもので、本発明によるコンピュータの代表的なハードウェア構成を示している。このハードウェア構成は、従来のマイクロプロセッサなどの中央処理ユニット１０、およびシステム・バス１２を介して相互接続された複数の他のユニットを含んでいる。図１に示すコンピュータはリード・オンリ・メモリ（ＲＯＭ）１６、ランダム・アクセス・メモリ（ＲＡＭ）１４、ディスク・ユニット２０などの周辺デバイスおよび２１で示す他の入出力周辺デバイスをシステム・バス１２に接続するための入出力アダプタ１８、キーボード２４、マウス３２、スピーカ２８、マイクロホン２６および／またはタッチ・スクリーン・デバイス（図示せず）などの他のユーザ・インタフェース・デバイスをバス１２に接続するためのユーザ・インタフェース・アダプタ２２、ワークステーションを２３で示すデータ処理ネットワークに接続するための通信アダプタ３４、およびバスをディスプレイ・デバイス３８に接続するためのディスプレイ・アダプタ３６を装備している。ワークステーションには、アップル・システム７（登録商標）オペレーティング・システムなどのオペレーティング・システムが常駐している。
【００１４】
本明細書に開示されているドキュメント・フレームワークの主目標は、いくつかの新しい機能（フィーチャ）をシステム・レベルで使用可能にすることによりアプリケーションの基本レベルを向上することにある。加えて、これらの機能に対するシステム・サポートがないと、インプリメンテーションを制限することになる。例えば、ユーザはどのドキュメントでも、その静的表現(picture：ピクチャ）に注釈をつけることができるが、「生の(live)」ドキュメント自体には注釈をつけることができないようなアプリケーションがある。内容ベース検索アプリケーションはドキュメントの内容をアクセスするときトラブルを引き起こしているが、これは、各アプリケーションがカスタム・ファイル・フォーマットになっているためである。また、アプリケーションがドキュメントを見つけたあと、そのドキュメントになんらかの処理を行うことが困難になっている。例えば、ドキュメントをオープンすることがシステム・レベルでサポートされていない。ドキュメント・フレームワークは、注釈サポート(annotation support)のように、これらの基本サービスを基礎にして作られたいくつかのハイレベル機能を備えている。可能な限りの範囲において、ドキュメント・フレームワークは、ポリシまたはユーザ・インタフェース決定に関してはなにも規定していない。これらの詳細は、ドキュメント・フレームワークを使用して特定のアプリケーションから与えられるようになっている。
【００１５】
コラボレーション（共同作業）
スクリーン共有(screen sharing)は、マッキントッシュではコラボレーションの一種として普及しているが、これはインプリメント（実装）が比較的容易であり、その用途が多数あるためである。その主な欠点は、ある種のアプリケーションはスクリーンに直接にドローイング(drawing) し（実装を複雑化している）、すべてのドローイング操作をあるマシンから別のマシンへ伝送するのに大きなバンド幅を必要とすることである。また、これは、すべてのコラボレータがドキュメントをまったく同じ見方で見ることに基づいているので、非常に制約的になっている。
【００１６】
スクリーン共有は、同時リアルタイム・コラボレーションの一種である。ドキュメント・フレームワークでは、異種の同時リアルタイム・コラボレーションをサポートしている。これは、スクリーンの変更ではなく、ドキュメントの変更というレベルで動作するので、ドキュメント変更を指定するのに必要なデータ量がスクリーンを更新するのに必要なデータ量よりも少ないのが通常であるため、より効率的になっている。
【００１７】
また、コラボレーションを非同期（つまり、非リアルタイム）で行なうことも有用である。これの１つ形体として、ドキュメントに注釈をつける機能がある。ドキュメント・フレームワークでは、そのモデルとリンキング・メカニズム（下述する）を通して注釈をつけることを低レベルでサポートしている。
【００１８】
ハイパメディア・リンキング
図２は、本発明の実施例を示す図である。ブロックは、システムに関係する装置とメソッドの両方を表わしている。図２に示すように、ドキュメント・フレームワークでは、リンク２０４はアンカ２０２と２０６との間を双方向で結合している。アンカの意味はアプリケーションによって異なるが、殆どの場合、アンカはスティッキ・セレクション(sticky selection)を表わしている。アンカがスティッキであるのは、ユーザの編集上の変更とは無関係に、同じデータを常に参照しているからである。例えば、アンカがテキスト・ブロック内のあるワードを参照している場合、その前後のテキストが変更されても、アンカは常にそのワードを参照している。アンカは、カプセル化された特定のデータ・ブロック（モデルと呼ばれる）２００と関連づけられている。システム内のデータの各種類は、TModelの特定サブクラスで表わされている。抽象基底クラスであるTModelは、他のモデルがそのデータを「ブラック・ボックス」として組み込み、表示し、操作することを可能にする汎用プロトコル(generic protocol)を定義している。例えば、アプリケーションはデータのプレゼンテーション（view：ビュウ）を作成するようにモデルに要求することができる。これらのプレゼンテーションは小さなもの(thumbnail) から完全に編集可能なプレゼンテーションまでにわたっている。モデルのデータに関連するアンカをアクセスし、そのモデルに組み込まれた他のモデルをアクセスするときのプロトコルもある。ドキュメントのデータはモデル階層で表され、「ルート・モデル(root model)」と呼ばれるルートには、単一のモデルが置かれている。
【００１９】
ユーザはリンクを作成したあと、その操作を行うことができる。まず、ユーザはリンクの一方の端から他方の端までナビゲート（たどっていくこと）することができる。一般的に、これは、ターゲット・アンカを収めているドキュメントをオープンし、アンカをビュウまでスクロールし、対応するセレクションをハイライトにすることにより行われる。アプリケーションはこの動作（behavior：振舞い）を変更することができる。例えば、サウンド・ドキュメントまでナビゲートするだけでドキュメントをオープンしなくても、サウンドが演奏される。また、リンク間を両方向にデータを転送することも可能である。データを転送することは、意味的には、ソース・データをコピーし、デスティネーション・アンカまでナビゲートし、既存のデータを転送データで置き換えるのと（ほぼ）同じである。データをリンク経由でプッシュするか、プルするかは（つまり、転送を開始するのがソースであるか、デスティネーションであるかは）、ドキュメント・フレームワークでは大した問題ではない。
【００２０】
ドキュメント・フレームワークでは、１つのアプリケーションはリンクを介して任意のコマンドを送ることも可能である。そのようにすると、相互に協力し合うアプリケーションは、同じ基本リンキング・メカニズムを使用してカスタム機能を実装することが可能になる。ドキュメント・フレームワークの低レベル・リンキング・メカニズムは回りくどい使い方をしなくても、ユーザはドキュメント間のリンクを作成し、これらのリンクをナビゲートし、リンク間でデータを転送し、その他を行うことができる。しかしながら、これはリンクの唯一の使用法ではない。リンクは、他のアプリケーション機能を実装するためにも使用される。これらの機能では、リンクが作成され、操作されることはユーザに気づかないようになっている。
【００２１】
例えば、システム・ワイドの注釈機能はリンクを使用して、注釈をそれが参照しているベース・ドキュメントの部分と関連づけている。システムは、通知ノート・アイコン(posted note icon)（注釈を表している）を、それが参照しているドキュメントの部分の近くに位置付ける。さらに、注釈がドキュメント変更の提案を含んでいれば、作成者はその提案を「受け入れて」、システムにリンクを介してデータを注釈からドキュメントへ自動的に転送させることが可能である。
【００２２】
ユーザに見えないリンキングのもう１つの使い方は、システム７のエディション・マネージャ(Edition Manager) によって実行される関数を実装することである。ユーザはドローイングの一部を公表し、ワード・プロセッシング・ドキュメントの中でそのデータに署名することが可能である。内部的には、システムはドキュメント間のリンクを作成し、おそらく、リンクの性質（例えば、どちらの端がデータのソースであるか）を示す属性をリンクに付けることになる。リンクの存在はユーザに見えないようにすることができる。
【００２３】
ドローイングの変更は、リンクを介してワード・プロセッシング・ドキュメントに送られる。ドキュメント・フレームワークでは、リンクのどちらの端が転送を開始するかを制限していない。ユーザはデスティネーションからデータのソースへ（ワード・プロセッシング・ドキュメントからドローイング・ドキュメントへ）ナビゲート（たどっていくこと）することができる。ドキュメント・フレームワークでは、すべてのリンクが双方向であるので、反対方向へナビゲートすることもサポートしている。
【００２４】
ドキュメント・フレームワークのモデルは、単純コピーとペーストの働き方も向上する。マッキントッシュでは、アプリケーションはクリップボード(Clipboard) 内のデータ・モデルのタイプに応じて、ペースト・コマンドを３通りの方法で取り扱っている。(1) ドキュメントはペースト・データを完全に理解できるので、そのデータはドキュメントのファースト・クラス部分となる。(2) 受入れ側ドキュメントは受け入れたデータを表示できるが、それを操作することはできない。代表例として、テキスト・ドキュメントの中にペーストされた絵がある。この場合、受け入れたデータは表示できるが、編集することはできない。(3) 受け入れたデータ・タイプは受入れ側ドキュメントには理解されない。この例では、ペースト・コマンドは完了できないので、使用禁止にされるはずである。
【００２５】
データを取り込むことができない場合は、モデルの形で受入れ側ドキュメントに組み込むことができる。モデルはデータの編集可能プレゼンテーションを作成するときの汎用プロトコルをサポートしているので、組み込まれたデータは、マッキントッシュでそうであるように「デッド(dead)」になっていない。その代わりに、ユーザは組込みモデル(embedded model)をオープンして、そこに入っているデータを表示または編集することができる。この機能はＨＰ社のNew WaveシステムまたはMicrosoft 社のＯＬＥ仕様に用意されているものと似ている。重要な違いは、オブジェクト指向ドキュメント・フレームワークによると、開発者が新しいデータ・タイプを実装することが容易化されることである。最後に、アプリケーションが組込みモデルをサポートしていれば、すべてのタイプのデータをペーストすることができる。ペースト・コマンドは、クリップボードが空になっていない限り、使用禁止にされることはない。
【００２６】
エターナル・アンドゥ
（永続的取消し）
大部分のマッキントッシュ・アプリケーションでは、アンドゥ・コマンドは、最後の変更だけがアンドゥできる（取り消しできる）ことから貴重になっている。ドキュメント・フレームワークでは、MacAppと同じ種類のコマンド・オブジェクトを使用しているが、可能な限り多くのコマンド・オブジェクトをセーブしている。
【００２７】
この決定には、いくつかの利点がある。第一に、どのコマンドをアンドゥ可能にするかは好みの問題であり、その選択は大して重要ではない。例えば、既存のマッキントッシュ・アプリケーションでは、作成が困難なセレクションがあったとしても、セレクションに対する変更はアンドゥ可能になっていない。ドローイング・プログラム(drawing program) では、ユーザは形状の正しい組合せを選択するのに大量の時間を消費し、余計なクリックを行ったためにすべてを失うことがある。システムが１レベルのアンドゥだけをサポートしているときは、セレクションの変更をセーブすることは、例えば、最後の Cutコマンドのことを忘れることを意味するので賢明な方法ではない。アンドゥが多重レベルになっているときは、セレクションの変更をセーブすることは実現可能である。
【００２８】
コマンド・オブジェクトを使用することから得られるもう１つの利点は、信頼性の向上である。すべてのコマンドをセーブしておけば、アプリケーションまたはシステムにクラッシュが起こったとき、これらのコマンドを復元することが可能になる。ドキュメント・フレームワークでは、並行性制御(concurrency control)と回復クラスを使用して、コマンド・オブジェクトをクラッシュに強い方法でセーブしている。クラッシュが起こった場合、ユーザが失うのは、最後のカップルのコマンドだけである。マルチレベル・アンドゥによると、正しい方法でコマンド・リストを可視化し、ナビゲートする負担が増加することになる。セレクションの変更が含まれていると、ユーザが非常に多数のコマンドを作ることが容易になるので、このことが特に起こる。
【００２９】
図３は、ドキュメント・フレームワークによるコマンド・オブジェクト３０２のリニア・リスト(linear list) ３００を示したもので、これはスタックに似ている。アンドゥ処理を行う方法は他にも多数ある。このことは、アンドゥ３０６はドキュメントを以前の状態（ステート）に戻すことを意味する。また、その意図は、ユーザがコマンド３０４を選択的にアンドゥできるようにすることである（つまり、Cut コマンドがアンドゥされても、そのあとに続くコマンドはすべてそのまま残されている）。ここで注意すべきことは、コマンドが相互に依存することである。ある形状をコピーするコマンドは、その形状を最初に作成したコマンドに依存する。これらの依存関係は、アンドゥするユーザ・インタフェースだけでなく、その基礎となるインプリメンテーションも複雑化することになる。
【００３０】
上記の解決法は、例えば、アンドゥとスクリプティング(scripting) メカニズムを統合化して、完了したすべてのもののスクリプトを自動的に作成するようにすることである。そうすれば、ユーザは恣意的なコマンドを除去し、コマンドを並べ換える、といったことを行うようにスクリプトを編集し、そのスクリプトを実行することができる。このようにすると、ユーザは最大の柔軟性が得られ、制御を強化することができる。
【００３１】
内容ベース検索
ユーザがコンピュータで利用できる情報はますます増加している。ローカル・ハード・ディスクは大容量化し、数百メガバイトのデータを収容できるCD-ROMが多数出現している。システムからのなんらかの援助がなければ、このデータをブラウズ(browse)することは不可能である。マッキントッシュでは、標準ツールとしてFind File が使用され、これはドキュメント名に基づいてドキュメントを探索していた。システム７にはFind（探索）コマンドが用意されているが、これはFinderに組み込まれている。サード・パーティ開発者もFind File の機能を越えるツールを提供している。このツールはドキュメントの内容に基づいてドキュメントを探索するが、システムと一体化するのに適していない。
【００３２】
重要なことは、これらの検索ツールをシステムに一体化しておくことである。ユーザがドキュメントを扱うことができなければ、ドキュメントを探し出しても殆ど意味がない。マッキントッシュで使用されるサード・パーティの内容ベース検索ツールは、ドキュメントの内容を調べるとき、あるいは該当のアプリケーションでドキュメントをオープンするときでも、システムがサポートしていない。
【００３３】
図４はドキュメント・フレームワークの汎用検索フレームワークを示し、情報のソース４００から検索するものである。このフレームワークはインデクシング４０２と照会(query) ４０４の両方を取り扱っている。将来、多数のオペレーティング・システムがデフォルトのインデクシングと照会パッケージと共に発表されることがあっても、ユーザが望んでいることは、新しい探索パッケージを基本フレームワークにプラグインできることである。フレームワークを設計するときの主眼点は、バックグランドのインデクシング・メカニズムと照会ユーザ・インタフェースがその基礎となる検索テクノロジに関係なく、同じになるようにすることである。
【００３４】
フレームワークは、ドキュメントがボリュームに追加されたり、変更されたときドキュメントのインデクシングをバックグランドで自動的に行うようになっている。検索システムは、ドキュメントの一部だけがインデクシングされるようでは価値がないものとなり、この負担をユーザに負わせることは合理的でない。汎用照会フロントエンド(generic query front-end) によると、ユーザは新しい検索エンジンをインストールできるので、新しいフロントエンドを学ぶ必要がなくなる。
【００３５】
開発者側から見たクラス
このセクションでは、クラスとメンバ関数について説明する。ある種の規則に従っている。すべてのクラスは仮想デストラクタ(virtual destructor)をもっている。ここで説明するデストラクタは、ストレージの解放以上のことを行うデストラクタである。それ以外のデストラクタは説明されていない。ストリーミング演算子のように、MCollectible（図５のエレメント５００）から継承されたメソッドはここでは説明していない。クラスの多くはゲッタ(getter)とセッタ (setter)をもち、これらはフィールド・アクセスを行うだけである。
【００３６】
オブジェクト・サロゲート
(Object Surrogates)
ドキュメント・フレームワークのいくつかのオブジェクトには、オブジェクト・サロゲート（代理）が用意されており、これらは、現実オブジェクトへのコンパクトな、アドレス空間独立な参照として働く。このようなサロゲートの使い方は「明示のマスタとサロゲート」と言うことができる。数少ないケースでは、サロゲートと現実オブジェクトは互換性のある使い方が可能であるが、大部分のケースでは、サロゲートは現実オブジェクトを探すときの「キー」の働きをする。すべてのケースでは、サロゲートと現実オブジェクトとの関係は共通の抽象基底クラスによって定義される。抽象基底クラスは、オブジェクトに対するアドレス空間独立な識別を提供し、オブジェクト間を比較するときのプロトコル(IsEqual) を実装している。これにより、サロゲートを現実オブジェクトと直接に突き合わせて比較し、現実オブジェクト群までのキーとして使用して探索(lookup)を行うことができる。サロゲート・オブジェクトは、現実オブジェクトからサロゲートを作成するコンストラクタ(constructor) を提供することにより、サロゲートの作成を容易化している。
【００３７】
例えば、TModelSelectionsはアドレス空間独立な方法でTModelオブジェクトを識別して、コマンドが複数のコラボレータのアドレス空間に置かれたデータをアクセスできるようにする必要がある。TModelとTModelSurrogate は共に共通の基底クラスTAbstractModelから派生している。TAbstractModelはオブジェクトのアドレス空間独立な識別を提供し、オブジェクト間の比較を行うプロトコルを実装している。TModelは、現実モデルをサロゲートから探索(lookup)するための静的メンバ関数を用意している。セレクションがストリーム化されるとき、それが参照するモデルのサロゲートだけをストリーム化する。コマンドがそのセレクションを通してデータをアクセスしようとすると、現実モデルはサロゲートを使用して探索されて、コマンドが現実モデル・データをアクセスできるようにする。
【００３８】
データ表現
(Data Representation)
図５は表現クラス(Representation class)を示している。特定のデータ・タイプのデータをカプセル化する抽象基底クラスはTModel５０６である。TModel５０６の派生クラス(derived class) は「ドキュメント」データのコンテナ(container) である。これらは、モデルに収められたデータをアクセスして変更するときのタイプ別のプロトコルを用意している。また、これらは、他のモデルを組み込むことと、他のモデルに組み込まれることをサポートする汎用プロトコルをオーバライドしなければならない。これは大部分が、セレクションとユーザ・インタフェースをデータに基づいて作成するプロトコルをオーバライドすることにより行われる。
【００３９】
TModelオブジェクト５０６は、そこに収められたデータの変更の通知を、関係するオブジェクト（代表例としてプレゼンテーション）へ送る働きもする。この通知は、基礎となるシステムに標準通知機能が用意されていれば、その機能を使用して与えることが可能である。モデル通知の詳しい説明は、「データ・プレゼンテーション」のセクションに下述されている。
【００４０】
クラスTModelSurrogate ５０４は、実際のTModel５０６のライトウェイト・スタンドイン(lightweight stand-in)、つまり、それを表す「名前」の働きをする。これは実際にはデータを収めていない。現実モデルだけがデータを収めているが、TModelによってサポートされる動作（振舞い）のサブセットに関するプロトコルを用意している。具体的には、「ワークスペース」内に現れて、操作するために必要な動作である。TModelSurrogate ５０４とTModel５０６が共有する動作は共通の基底クラスTAbstractModel５０２によって定義されている。
【００４１】
複合ドキュメント構造
図６にエレメント６００で示すように、ドキュメントは多数のモデルを収容することができ、これらのモデルは多数の異なるクラスにすることができる。ドキュメントの基本構造は、ドキュメントの包含階層(containership hierarchy) を反映したモデル階層である。単一モデルが階層のルートに存在し、これは「ルート・モデル(root model)」と呼ばれる。階層内の各モデルは、そこに組み込まれた他のモデルのコンテナとなることできる。コンテナ・モデルは、その組込みモデルへの参照をモデル・サロゲートにより行う。Ｃ++ポインタを使用してはならないのは、組込みモデルが別々のコンテキストを使用してコンテナからファイルされることがあり、必ずしもコンテナと一緒にメモリに置かれているとは限らないためである。サロゲートを通してモデルをアクセスすると、モデルはそれがまだメモリになければ、自動的にファイル・インされる。オプションとして、組込みドキュメントは、有向非循環グラフ(directed acyclic graph)にすることができる。マルチカラム・テキストは次のように実現することができる。つまり、テキストの個別カラムは、すべてが単一の共有テキストフロー・モデルを組み込んでいるモデルとなっていく。また、各モデルを相互に独立してロックするようにすると、複雑化するという犠牲を伴うが、潜在的並行性を強化することができる。
【００４２】
図６に示す「標準例」は、特定のモデル階層を示している。ドキュメントに含まれたプレゼンテーションをもつ、階層内の各モデルは関連のTUserInterface（これ自身も、ユーザ・インタフェース・モデルを収めているモデルである）をもっている。特定モデルのTUserInterfaceはそのモデルによって管理され、そのモデルを通してのみアクセス可能である。直接には表示されず、別の「プレゼンテーション・モデル」を通して表示されるモデルは、関連のTUserInterfaceをもっていない。例えば、TGraphModel を通してのみ分布図(scatter plot)として表示されるTTableModel はTUserInterfaceをもたないのに対し、TGraphModel がTUserInterfaceをもっているのは、プレゼンテーションをユーザに提供するからである。
【００４３】
図７は図６のドキュメントの階層的性質を示している。具体的には、セクション０〜５は他のタイプの情報内に組み込むことができる種々タイプの情報を表している。例えば、セクション１はTaligent（登録商標）のテキストであり、これは、セクション２に示すTaligent（登録商標）というロゴに組み込まれている。図７の右下隅は図６のドキュメントの階層構造を示している。
【００４４】
データ・タイプ
複合ドキュメント・アーキテクチャは、多数のデータ・タイプをシームレス(seamless)に統合化することをサポートしている。データ・タイプとしては、音声、グラフィックス、ビットマップ・イメージ、ピクチャ、テーブル、ビデオ、テキスト、財務データ、ファイル、プログラム・コンポーネントがあるが、これらに限定されるものではない。ほとんどどのような可視または音響データ・タイプでも、シームレスに複合ドキュメントに組み入れることが可能である。
【００４５】
組込みモデルの管理
TModelに収められた組込みモデルを管理する実装を用意するのは、TModelの派生クラスの責任である。TModelがそのための実装を用意しないのは、組込みモデルがコンテナのデータ構造に収まるようにする方法が非常にデータに依存するためである。ドキュメント・フレームワークには、単純化した組込みを行う実装を提供するTContainerModel が含まれおり、この実装では、組込みモデルのプレゼンテーションは、収容するプレゼンテーション上を「浮動(float) 」するだけになっている。
【００４６】
コピー、ストリーミングおよびファイリング
別のモデルに組み込まれているモデルは、コピーとストリーミングを行う目的上、収容するモデルのデータの一部であるとみなされる。あるモデルがコピー、ストリーミングまたはファイリングされるとき、そのモデルに収められた組込みモデルはその目的に合った方法で扱わなければならない。TModelにはデフォルトの実装が用意されているので、組込みモデルは、これらのケースではその通りに扱われる。
【００４７】
ストリーミング
TModelに用意されている標準ストリーミング演算子(operator>>=およびoperator<<=)は、アンカとリンクを含めて、TModelが所有するすべてのデータをストリーム化する。これらのストリーミング演算子は、ストリーム化しようとするモデル内に収められた組込みモデルをストリーム化することも取り扱う。派生クラスはこれらの演算子をオーバライドして自身のデータをストリーム化する。モデルが組込みモデルを収めているときは、これらのモデルのサロゲートだけをストリーム化する必要がある。継承されたストリーミング演算子は現実の組込みモデルをストリーム化することを取り扱う。ストリーミングによってデータをファイルするモデルの場合は、これらのメソッドはファイリング・メソッドと同じにすることができる。そのような場合には、通常望ましいことは、ストリーミング演算子とファイリング・メソッドの両方によってコールできるプライベート・ヘルパ関数(private helper function) を作成することである。
【００４８】
コピー
モデル全体をコピーするとき、あるいは選択したデータをモデルからコピーするときは、組込みモデルをコンテナによってコピーしなければならない。これは組込みモデルのTModelSurrogate の"CopyModel" メソッドを使用すると、簡単に行われる。このメソッドはサロゲートと現実モデルをコピーして、一貫性のある新しいモデル／サロゲートのペアが得られるようにする。
【００４９】
ファイリング
モデルをファイリングするときは、その組込みモデルもファイリングしなければならない。組込みモデルはコンテナから独立にファイリングして、組込みモデル用のストレージをカストマイズできるようにしなければならない。あるモデルがそのデータをFileOutData() にファイルすることを要求されたときは、そこに収められた組込みモデルのサロゲートだけをファイルする。組込みモデルはドキュメント・フレームワークによって自動的にファイルされる。ファイルされたサロゲートはFileInData()に読み戻されて、現実モデルをアクセスするために使用できる。ドキュメント内のダーティ(dirty) モデルはすべて、常に一緒にファイル・アウトされる。このようにすると、ロールフォワード(Roll-Forward)ログの取扱いが単純化される。モデルはモデル・サロゲートから要求されたとき個別にファイル・インされる。
【００５０】
新しいモデルがドキュメントに追加されるときは、自分用の新しいストアを作成する機会をそのモデルに与えなければならない。メソッドCreateModelStore()がコールされ、ドキュメント・ルート・モデルのストアが渡される。このストアがモデルに見合ったものであれば、新しいストアは作成されない。そうでないときは、組込みモデルは、そのストレージ要求量に見合った新しいストアを作成して使用する。ストアの実際の作成はゆっくりと行なわれるので、一時的使用を目的にメモリに作成され、ストアを必要としないモデルはストアを作成しない。
【００５１】
あるモデルがドキュメントから除去されるときは、メモリとストレージの両方からそのモデルを削除しなければならない。モデルを削除すると、そのモデルはメモリとストアの両方から削除される。モデルをメモリだけから削除するときは削除をコールしなくても、メソッドTModel::DeleteFromMemoryOnly()が使用できる。
【００５２】
並行性制御
単一のモニタはドキュメント内のすべてのデータを保護する。TModelEntry オブジェクトをスタック上に作成すると、このモニタに入る。
【００５３】
属性
TModelには、モデルに属性を付けるための拡張可能インタフェースと実装が用意されている。属性はモデル階層を通して継承可能である。つまり、あるモデルはその先祖から属性を継承することができる。TModelは、モデル内の特定のセレクションで属性を調べ、先祖をその調査に含めたり、除外したりすることをサポートする。属性は単純属性グループ内で維持され、TInheritableAttributeGroupを使用しないで、独自に継承を行なうことをサポートしている。これは、階層内のすべてのモデルが同時にメモリに置かれているとは限らず、この動作はTInheritableAttributeGroup によってサポートされないからである。
【００５４】
TAbstractModel
TAbstractModelは、TModelと TModelSurrogateの基底クラスである。これはこれらのクラスの両方に共通のプロトコルを用意し、現実クラスとサロゲート・クラス間の共通基底クラスを用意している。これについては、本明細書の「オブジェクト・サロゲート」セクションに説明されている。TAbstractModelは抽象基底クラスである。これは、派生クラスの一部としてのみインスタンシエイト(instantiate) される。モデルのストレージへのアクセスを可能にするメソッドとしては、次のものがある。１）SetModelStoreReference、２）AdoptModelStoreReference、３）CopyModelStoreReference 、４）GetModelStore 。TModelとTModelSurrogate はTAbstractModelから派生する唯一のクラスである。TAbstractModelは抽象クラスであるので、常に派生クラスの一部として作成され、削除される。TAbstractModelによってその実装の一部として作成されたデータはそのクラスによって管理される。
【００５５】
TModelSurrogate
TModelSurrogate は、TModelのライトウェイト「スタンドイン」または「名前」となるもので、ストレージに置かれた現実モデルを完全にアドレスできる機能を備えている。TModelSurrogate は、１つのTModelに対していくつでも存在することができる。TModelSurrogate は、コラボレーションの目的のために、TModelのアドレス空間独立な指定子としての働きもする。TModelSurrogate は具象クラス(concrete class)であり、自由にインスタンシエイトし、壊すことができる。TModelSurrogate は、TAbstractModelの抽象関数のすべてに対する具体的実装を用意している。このサロゲートによって表わされた現実モデルへのアクセスと管理をサポートするメソッドとしては、１）GetModel、２）CopyModel 、３）DeleteModel がある。モデルのアンカへのアクセスを可能にするメソッドとしては、１）CopyAnchor、２）CreateAnchorIteratorがある。サロゲートによって表わされたモデルのプレゼンテーションをサポートするメソッドとしては、次のものがある。これらのプレゼンテーションは静的であり、現実モデルの内容に対する変更を反映していない。１）CreateIcon、２）CreateThumbnail 。
【００５６】
TModel
図８はTModel８００を示しているが、これは、アンカとリンクを含めてすべてのドキュメント・データ８０２のコンテナであり、カット／コピー／ペーストを行なうときのデータ交換の単位となるものである。ここには、データを異質のデータ・モデルに組み込むこと８０４および／または異質のデータ・モデルをそこに組み込むことをサポートするプロトコルが用意されている。基底クラスTModelは、モデルのアンカ８０６とリンク８０８を管理するための実装を用意している。サブクラスは、タイプ別のデータをアクセスし、管理するためのプロトコルと実装を用意している。さらに、サブクラスはユーザ・インタフェース、セレクションを作成し、組込みモデルをアクセスするための基底クラス・プロトコルを実装していなければならない。TModelはMDelegatingNotifier から派生しているので、そこに結合すると、モデルのデータ８１０に対する変更の通知を得ることができる。TDocument 内のすべてのモデルはTModelクラス通知子(notifier)を共有し、すべてのコールをその通知子に委任する。いくつかのメンバ関数は、モデルのユーザ・インタフェース・モデルの管理をサポートしている。サブクラスはCreateUserInterface をオーバライドして、そのモデル用の該当ユーザ・インタフェースを作成しなければならない。将来は、インタフェースの選択は、ユーザの好みに合わせて判断できるようになるはずである。メンバ関数には、次のものがある。１）CreateUserInterface 、２）AdoptUserInterface、３）GetUserInterface、４）GetUserInterfaceSurrogate 。モデルのアンカとリンク群をアクセスし、変更することをサポートすると共に、モデルに関連する属性をアクセスし、変更することをサポートするメンバ関数も、非常に多数ある。
【００５７】
データ・プレゼンテーション
通知クラス
TModelに収められたデータは、ユーザが表示しおよび／または変更できるものでなければ、ほとんど無価値である。ドキュメント・フレームワークは、データ・プレゼンテーションを実装するために必要なクラスを直接には提供していないが、ドキュメント・フレームワークはモデルでプレゼンテーションを管理することをサポートしている。このセクションで通知を中心に説明しているのは、これがドキュメント・フレームワークによって直接に提供されるプレゼンテーション・サポートの範囲であるためである。例えば、他のプレゼンテーション・サポートはすべて、オブジェクト指向ユーザ・インタフェース・ツールボックス(User Interface ToolBox)から得ることができる。
【００５８】
ユーザ・インタフェースの管理
ドキュメント・フレームワークは、モデルのユーザ・インタフェースを管理することをサポートしている。モデルの関連ユーザ・インタフェースを作成し、ストアし、検索するときのプロトコルはTModelから提供される。TModelのクライアントは、モデルにそのユーザ・インタフェースを要求することができる。そのあと、クライアントはユーザ・インタフェースに対し組み込まれたプレゼンテーションまたはウィンドウ・プレゼンテーションを要求することができる。ドキュメント・フレームワークは、ユーザ・インタフェースの内容をサポートしていない。そのアクセスとストレージを管理することをサポートしているだけである。TModelのこの機能の説明については、「データ表現」のセクションに記載されている。
【００５９】
通知
図９は、ドキュメント・フレームワークの通知システムを示している。ドキュメント・フレームワークによれば、モデルに収められたデータに行われたすべての変更の変更通知は、TModelのクライアント（クライアントの代表例としては、プレゼンテーション・ビュウがある）に対して行なわれる。プレゼンテーションをモデルに結合すると、モデルのデータに対する特定の変更またはすべての変更の通知が得られる。通知を受けたときプレゼンテーションに正しい更新を行うことにより、プレゼンテーションは基礎となるデータとの同期が保たれる。TModelはそれが管理するデータ、具体的には、アンカとリンクに対する変更の通知をTLinkNotification ９０６とTAnchorNotification ９０８を通して、セレクションに対する変更の通知をTSelectionNotification９０２を通して行う。標準通知はカット／コピー／ペースト操作に関するものが用意されている（これは図に示されていない）。ドキュメント・フレームワークに関係する他の通知も用意されている。例えば、TDualSelectionNotificationは、デュアル・セレクション(dual selection)の通知を行う。そのモデルのデータに特定する通知を行うのはTModelのサブクラスの責任である。これらの通知はプレゼンテーションが基礎となるデータと統一性を保つように十分になっていなければならない。
【００６０】
データ指定
(Data Specification)
ドキュメント・フレームワークでは、ドキュメント・データの指定をサポートするクラスはTModelSelection である。ここで注意すべきことは、モデル・セレクションは実際には選択したデータを指定することであり、実際にはデータを収めていないことである。さらに、この指定はアドレス空間から独立した方法でデータを識別して、セレクションが複数のコラボレータのアドレス空間で適用できるようになっていなければならない。ドキュメント・フレームワークはデータを全モデルの粒度(glanularity) で管理し、全モデルに作用を及ぼすデフォルトの機能を用意している。TModelSelection も例外でない。TModelSelection は選択したモデルを指定するときのプロトコルと実装を用意している。代表例として、TModelの派生クラスの実装には、TModelSelection の対応する派生クラスが用意され、モデルに収められたデータを、全モデルよりも細い粒度で指定することをサポートしている。これにより、全モデルにではなく、あるモデル内のデータのサブセットにコマンドを適用することが可能になっている。
【００６１】
データ交換
図１０は指定クラス(specification class) を示し、これにはTModelSelection １００２とMCollectible１０００が含まれている。TModelSelection １００２は、データをセレクション・オブジェクト間でやりとりするときのプロトコルを定義している。このプロトコルは、ドキュメント・フレームワークに用意されている、複数の標準コマンドによって使用される。そのようなコマンドとしては、カット、コピー、ペースト、プッシュおよびプル・コマンドがある。TModelSelection １００２はセレクション間でやりとりされるデータ・タイプを交渉するときのプロトコルを用意している。ソース・セレクションは、そこから選択したデータを得ることができるモデル・タイプのリストを作成する。デスティネーション・セレクションは、どのタイプのモデルの中のデータを受信し、そのデータをどのように受信するか（取り込むか、組み込むか）を選択する。タイプ交渉プロセスを通してタイプが選択されたあと、選択したタイプの中のデータのコピーを、CopyDataをコールすることによってソース・セレクションに要求する。返されたモデルは、タイプ交渉でデータをどのように受信するかをセレクションが示していたかに応じて、AbsorbDataまたはEmbedData に入れてデスティネーション・セレクションに渡される。この交渉は、アンカ間でデータをやりとりするときドキュメント・チーム間で行うことができる。その場合は、TRemoteDocument のサービスはリモート情報をアクセスするために使用される。上述した交換プロセス全体は、TPasteCommand またはTPushDataCommandなどの、コマンド・オブジェクトによって行われるのが代表的である。
【００６２】
TModelSelection
クラスTModelSelection １００２は、ドキュメント・セレクションおよびアンカ（持続的セレクション）が実装するものと予想されるプロトコルの大部分を用意している。これは、すべてのセレクション・オブジェクトの基底クラスの働きをする。TModelSelection オブジェクトは、カット、コピー、およびペーストを使用してまたはプッシュ／プル（アンカ上で）を使用して、セレクション間でデータをやりとりするときのプロトコルを収めている。この中には、タイプ交渉（どのタイプでこのデータを公表できるか、どのタイプでデータを受け取ることができるかといったこと）のプロトコルおよび特定のタイプでデータを公表または受け取るときのプロトコルが含まれている。
【００６３】
メンバ関数CreatePreferredType、 ChoosePreferredType 、およびGetTypeAcceptKind はMTypteNegotiatorから継承され、セレクション間でデータをやりとりするときのタイプ交渉をサポートしている。アンカをセレクションに追加し、除去し、作成するためのメンバ関数も用意されている。また、関連モデルの特定タイプのデータのやりとりをサポートするメンバ関数も用意されている。サブクラスは、アンカおよびリンクをコピーすることについては気にする必要がない。これはTModelSelection によって自動的に処理される。インポートまたはエクスポート時にアンカを調整する必要があるとき、オーバライドするためのメンバ関数も用意されている（例えば、テキスト内のアンカは、エクスポート時にはエクスポートされるデータに、インポート時には収容するテキストに相対するように調整する必要がある）。
【００６４】
データ変更
図１１は、データ変更を行うときに必要な基本的関係を示す図である。
TModelCommandGroup１１０４、 TModelCommand１１０２およびTCommand１１００は相互に協力しあって、システム内で要求される必要な変更を提供する。
【００６５】
変更クラス
ドキュメント・フレームワークでは、ユーザによって作られるコマンドを表す抽象クラスは TModelCommand１１０２である。TModelCommand １１０２のサブクラスはユーザ・アクションのセマンティックスをカプセル化しており、ユーザ・アクションに基づいてモデルを変更することができる。コマンド・オブジェクトは「実行(done)」、「取消し(undone)」および「やり直し(redone)」することができ、これらを作成するときに使用されるユーザ・インタフェース手法から独立しているのが代表的である。
【００６６】
TModelCommand １１０２
TModelCommand １１０２は TCommand １１００クラスの派生クラスである。TModelCommand １１０２オブジェクトはモデルを変更するユーザ・アクションをカプセル化している。TModelCommand は、モデルに対する変更を実行し、取り消しおよびやり直し、コマンドを出したコラボレータを識別し、変更を増分的に (incrementally) 実行することを、ドラッグやタイピングのときと同じように行うためのプロトコルをもっている。
【００６７】
TModelCommand オブジェクト１１０２はコマンド・オブジェクトの一部となり得るセレクションに作用するのが一般であり、より一般的には、現ドキュメント・セレクションに作用する。基底クラスTModelCommand １１０２は、すべてのモデル・コマンド・オブジェクトが応答するプロトコルを用意している。サブクラスは"HandleXXX" メソッドをオーバライドして特定の動作を提供する。
【００６８】
いくつかのTModelCommand は増分的に実行されることを目的としている。これらのコマンドを使用すると、ユーザはモデルを増分的に変更していくことができる。これらのコマンドは反復コマンド(repeating command) と呼ばれる。反復コマンドの一例として、ドローイング・プログラムの形状ドラッギング(shape dragging) コマンドがある。トラッキング(tracking)コマンドはモデルを多くの中間状態を通過させることがあっても、このコマンドは１つのコマンドとしてカウントされる。このことは、コマンドの全体効果は１つのアトミック・アクション(atomic action) として取り消され(undo)、やり直される(redo)ことを意味する。
【００６９】
ドキュメント・フレームワークは、Undoのフレームワークではコマンド・オブジェクトの考え方を採用している。コマンド・オブジェクトはドキュメント・フレームワークのコラボレーション機能の中心にもなっている。
【００７０】
モデル・ベース・トラッキングの詳細
図１２は、ドキュメント・フレームワークでトラッキング・オペレーションのある部分を実行するときの、起こり得る処理の流れを示す概略図である。１２００に示すように、トラッカ(tracker) がDoBegin() をコールすると、コマンド引数はフラット化され（１２０２）、１２０４でコラボレーション・サーバへ送られる。そこから、この引数は再びフラット化され、コラボレータの各々へ送られる。各コラボレータでは、コマンドのHandleDoBegin() メソッドが１２０６に示すように実行される。
【００７１】
図１３は、ドキュメント・フレームワークでトラッキング・オペレーションの別の部分を実行するときの、起こり得る処理の流れを示す概略図である。トラッカが１３００に示すようにDoRepeat()をコールすると、コマンド引数はデルタ情報１３０２をストリーム・アウトするように要求される。コマンド・デルタは１３０４でコラボレーション・サーバへ送られる。そこから、デルタはコラボレータの各々へ送られる。各コラボレータでは、デルタは、１３０６に示すように、コマンドのローカル・コピーにストリーム・インされる。そのあと、コマンドのHandleDoRepeat()メソッドが実行される。
【００７２】
トラッカがDoEnd() をコールすると、図１３に示すものと同じようなオペレーションが実行される。コマンド引数はデルタ情報をストリーム・アウトするように要求される。コマンド・デルタはコラボレーション・サーバへ送られる。そこから、デルタはコラボレータの各々へ送られる。各コラボレータでは、デルタはコマンドのローカル・コピーにストリーム・インされる。そのあと、コマンドのHandleDoEnd() メソッドが実行される。増分コマンド(incremental command) がその拡張Ｄｏフェーズを終了できる方法は２つある。標準的方法はDoEnd() がコールされる場合である。もう１つの方法は、トラッキングを行っているコラボレータが予期しないでコラボレーションから出る場合である。その場合は、コラボレーション・サーバ側のコマンドはそのHandleCollaboratorDied()メソッドがコールされている。拡張Ｄｏフェーズが終了すると、コマンドはそのHandleDo()メソッドがコールされたのと同じ状態にあるものと期待される。
【００７３】
TModelCommandGroup: TModelCommandGroupは TModelCommandのサブクラスであり、複雑なコマンドを複数の単純コマンドから作ることを容易化する。TModelCommandGroupは大部分のメソッド（例えば、HandleDo）をグループ内のコマンドの各々に委任する。すべてのコマンドでHandleLocalDo がコールされ、そのあとすべてのコマンドでHandleDoがコールされるという意味で、コマンドは逐次化されていない。あるコマンドのHandleLocalDo がそれより以前のコマンドのHandleDoでセットされた状態に依存する場合は、これは働かないことになる。コマンド・グループに含まれるコマンドの管理をサポートするメンバ関数には、AdoptFirst、 AdoptLast、Orphan、OrphanAll がある。
【００７４】
標準コマンド
以下に示すコマンドはすべて、ドキュメント・フレームワークに用意されている標準コマンドである。
【００７５】
TSelectCommand: TSelectCommandが出されるのは、セレクションを変更するときである。TSelectCommandは、セレクションを直接に操作することをサポートする増分コマンドである。このコマンドはコマンドを開始するコラボレーション用にセレクションをセットし、他のコラボレータのセレクションには影響しない。
【００７６】
TCutCommand: TCutCommandには、現セレクションをドキュメントからカットするというローカル効果がある。また、なにかをクリップボードに追加するというグローバル効果がある。ローカル効果は TReplaceSelectionコマンドをサブクラス化することにより達成される。
【００７７】
TCopyCommand: TCopyCommandにはローカル効果はない。なにかをクリップボード上に置くというグローバル効果がある。
【００７８】
TPasteCommand: TPasteCommandは、現セレクションをクリップボード上のデータで置き換える。これは、TReplaceSelection コマンドをサブクラス化することにより達成される。
【００７９】
TReplaceSelectionCommand: TReplaceSelectionCommandは、セレクションまたはアンカによって指定されたデータを、コマンド・オブジェクトにカプセル化されたデータで置き換える。コマンド・オブジェクトは、セレクションのデータを置き換えるために使用される TModel を収めている。TReplaceSelectionCommandはユーザが作成しないのが通例である。ドキュメント・フレームワークはこのコマンド・オブジェクトをカット、ペースト、プッシュ、プルなどで使用する。
【００８０】
TNewAnchorCommand: TNewAnchorCommandが出されるのは、新しいアンカが作成されたときである。TStartLinkCommand は、TStartLinkのグローバル効果が行なわれたあとではTNewAnchorCommand の働きをする。
【００８１】
TNewLinkCommand: TNewLinkCommandが出されるのは、新しいリンクが作成されたときである。TCompleteLinkCommandは、そこに組み込まれている
TNewLinkCommandsを使用して TModelCommandGroup をサブクラス化する。
【００８２】
TStartLinkCommand: TStartLinkCommandには、新しいアンカを「リンクボード」上に置くというグローバル効果と、新しいアンカをドキュメントに追加するというローカル効果がある。ローカル効果はTNewAnchorCommand をサブクラス化することにより達成される。
【００８３】
TCompleteLinkCommand: TCompleteLinkCommandが行なう仕事は多数である。このコマンドには、新しいリンク・コマンドを別のドキュメント（リンク開始コマンドを出したドキュメント）に通知するという非ローカル効果（可能な場合）がある。また、アンカとリンクを現ドキュメントに追加するというローカル効果がある。これは該当のコマンド・オブジェクト(TNewAnchor とTNewLink) をその実装の中で使用して達成される。
【００８４】
TPushDataCommand: TPushDataCommandには、TPushedData コマンドをデスティネーション・アンカに通知するという非ローカル効果（可能である場合）がある。すべてのタイプ交渉はセレクション・プロトコルを通して処理される。
【００８５】
TPullDataCommand: TPullDataCommandコマンドはプル・コマンドと呼ばれることもある。これは、リンクの他端側のアンカからデータを取り出す。
【００８６】
TFollowCommand: TFollowCommandは「リンク」をたどっていく。これは、リンクの他端側のアンカを収めているドキュメントへTFollowedCommandを通知することにより行われる。
【００８７】
TFollowedCommand: TFollowedCommandは、リンク内のデスティネーション・アンカを収めているドキュメントに通知される。TFollowedCommandに組み込まれているTModelLinkの「そちら」側はデスティネーション・アンカである。デスティネーション・アンカのFollowメソッドがコールされる。このメソッドをオーバライドすると、正しいfollow動作が実装される（アンカとそのセレクションをビュウまでスクロールするのが代表例）。
【００８８】
アンカおよびリンク
図１４は、MCollectible１４００、MAbstractModeler１１０２、TModelSelection １４０４、 TModelAnchorSurrogate １１０６、およびTModelAnchor１４０８間の関係を示す図である。
【００８９】
図１５は、MCollectible１５００、 TAbstractModelLink１５０２、 TModelLinkSurrogate １５０４、およびTModelLink１５０６間の関係を示す図である。
【００９０】
アンカおよびリンク・クラス
アンカは、「スティッキ」ドキュメント・セレクションであるのが代表的である。「スティッキ(sticky)」とは、アンカによって選択されたデータがモデルで編集される変更の間で統一性があることを意味する。
【００９１】
リンクは２つのアンカを結合するコネクションである。リンクに対するオペレーションとしては、リンクの作成、リンクの除去、リンクを「たどっていく」こと、データを一方のスティッキ・セレクションから他方へプッシュすること、またはデータをプルすることがある。２つのアンカ間のリンクを作成するには、ユーザはそのアンカを指定しなければならない。これは、データをコピーしたり、ペーストするのと似ているので（ユーザはソースとデステイネーションを指定する必要がある）、これを行う１つの方法は、クリップボードに似た一種の「リンクボード」を維持することである。
【００９２】
図１６の１６００から１６０６までは、Start Linkコマンドの処理の流れを示す図である。Start Linkコマンドは、１６０２で現セレクションからアンカを作成し、そのアンカを１６０４でリンクボード上に置く。
【００９３】
図１７の１７００から１７１０までは、Complete Link コマンドの処理の流れを示す図である。Complete Link コマンドも１７０２でアンカを作成し、そのあと、新しいアンカとリンクボード上のアンカ間のリンクを１７０４で作成する。Complete Link を１７０６で何度も選択すると、処理の流れの１７０８に示すように、共通アンカを共有する複数のリンクを作ることが可能である。
【００９４】
図１８はドキュメント１８００内のリンクを示し、これはプログラムに従ってアプリケーションにより作成されたものである。リンキングの「興味のある」使い方の大部分はこのカテゴリに属するものである。例えば、リンク１８０４をもつドキュメントの影響を受ける部分に注釈１８０２を付けることができる。スクリプト１８０６はリンク１８０８をもつドキュメントの部分を参照することもできる。ここで注意すべきことは、図１８のリンクはソフトウェア構造を表したものにすぎず、リンク、スクリプト、注釈の特定のビジュアル特性、またはリンクで結合されたドキュメント部分を伝達することを目的としていないことである。ドキュメント・フレームワークには一種類のリンクしか存在しない。これは双方向リンク１８０４と１８０８で示すように双方向であり、ナビゲーション（リンクの他端を探す）とデータ転送の両方をサポートしている。
【００９５】
図１９は、リンクの特性の一部を示す図である。リンクはプロパティ１９００ももっており、これはアプリケーションが使用して、リンクを分類したり（１９０２）、リンクの使い方を制限したり（１９０４）することができる。例えば、ユーザ１９０８がリンクに対してなにを行う（１９０６）ことができるかを指定するプロパティをもつことが可能である。あるユーザだけがスプレッドシートからデータをプルすることを許し、スプレッドシートまでナビゲートしたり、データをそこにプッシュしたりするのを許さないようにすることが望ましい場合がある。注釈を実装するために使用されるリンクはある種のプロパティによって識別される。このプロパティはリンクが注釈の一部であること、該当の注釈コマンドが使用可能であることを示している。
【００９６】
最後の例は、マスタとコピーとの関係を示すリンクである。これはインポート・データで使用される。グラフの静的表現をコピーし、ペーストする代わりに、ユーザはオリジナル・グラフと、ワード・プロセッサ・ドキュメントに入っているコピーとの間のリンクを作成することができる。
【００９７】
TModelAnchorSurrogate
図１４にエレメント１４０６として示されているTModelAnchorSurrogateは、TModelAnchor１４０８のサロゲート・クラスである。これは、TModelAnchor１４０８から利用できるプロトコルのサブセットを用意している。具体的には、アンカ間のデータのやりとりをサポートするプロトコルを用意している。サロゲートのプロトコルを使用すると、クライアントはローカル・ドキュメントまたはリモート・ドキュメント内のアンカを区別しないですむ。TModelAnchor１４０８は、どのオペレーションが実行可能であるか（例えば、プッシュ、プル）といった、リンクの属性を記述した属性のリストを維持している。属性は単純属性グループ(simple attribute group)として管理される。属性を追加し、除去し、調べるためのプロトコルが用意されている。TModelAnchor１４０８はその作成者が所有し、所有権がTModelなどの別のオブジェクトに渡されていない限り、それを削除するのは作成者の責任である。重要なメンバ関数として、CreatePreferredTypelist、 ChoosePreferredTypeおよびCopyDataがある。
【００９８】
TModelAnchor
図１４にエレメント１４０８として示されているTModelAnchorは、ハイパリンクのアンカの働きをするすべての持続的セレクションの基底クラスである。TModelAnchor１４０８のデフォルト実装は、それからすべてのTModelSelection コールが委任されるTModelSelection １１０４を収めている。TModelAnchor１４０８は、どのオペレーションが実行可能であるか（例えば、プッシュ、プル）といった、リンクの属性を記述した属性のリストを維持している。属性は単純属性グループとして管理される。属性を追加し、除去し、調べるためのプロトコルが用意されている。重要なメンバ関数として、SetSelection、Follow、 Execute 、AddAttribute、スクリプティング(scripting) 、自動化テストおよびAdoptLink がある。
【００９９】
TModelLink
図１５にエレメント１５０６として示されているTModelLinkクラスは、リンクの表現を用意している。特殊化は、TModelAnchorをサブクラス化することにより行われる。TModelLink１５０６のサブクラスはない。「こちらの(here)」アンカと「そちらの(there) 」アンカは、リンク内の２つのアンカを表す名前にすぎない。TModelLink１５０６内の「こちらの」アンカは現ドキュメントの一部であるのが代表的であり、TModelのメソッドを使用すると現実のアンカに変えることができる。「そちらの」アンカは現ドキュメントの一部になることも、別のドキュメントに属することもあり得る。
【０１００】
TModelLinks １５０６も、どのオペレーションが実行できるか（例えば、プッシュ、プル）といったリンクの属性を記述したプロパティのリストを維持している。プロパティはプロパティ名と値のディクショナリとして管理される。プロパティを追加し、除去し、調べるためのプロトコルが用意されている。重要なメンバ関数として、GetHere、 GetThere、 AddAttribute およびRemoveAttribute がある。
【０１０１】
TDynamicModelAnchor
TDynamicModelAnchor は、そのデータ指定が静的でなく動的であるアンカの基底クラスである。アンカが「動的」と呼ばれるのは、アンカはアクセスされるたびに異なるドキュメント・データを指定できるためである。通常のアンカは常にドキュメント内の同じデータを参照する。例えば、動的アンカはドキュメント内の現セレクションを表すことができる。データがアンカからプッシュされたときは、そのデータはその時に現セレクションで表されていたデータになる。
【０１０２】
ドキュメントの制御と通信
このセクションでのクラスをここに含めたのは、ドキュメントがプロセス・モデルをどのように使用するかを理解しやすくするためである。クラスTDocument はチームのドキュメントを始動するために作成される。このクラスは、ドキュメント・チームのローカル制御のために必要な種々のフレームワークとサービスを作成することを担当する。この中には、コラボレーションと外部ドキュメント制御のためにサーバを開始すること、ドキュメント・ファイリング・オペレーションの制御を行うことが含まれる。クラスTRemoteDocument は他のチームのドキュメントとのリモート・インタフェースとなるものである。このクラスによると他のチームのドキュメントからデータをアクセスすることができ、これらのドキュメントをコマンドで制御することがサポートされる。
【０１０３】
モデル・ファイリング
TDocument は、ドキュメントのファイリング・オペレーションを開始することをサポートする。モデルにファイリングするとき、実際に行うべき作業はない。TModelはサロゲートから初めて要求されたとき自動的にファイルされる。モデルは、その必要があれば、コンテナによっていつでもメモリから削除することが可能である。当然のことであるが、モデルを削除するには、モデルの排他的ロックを獲得する必要があり、モデルを指すポインタをキャッシュして、モデルのロック持続期間を越えて保持していてはならない。モデル・サロゲートはモデル・ポインタをキャッシュできるが、このことはクライアントには見えないようになっている。
【０１０４】
ファイリング・アウトのときは、役割はもっと大きくなる。セーブレスのモデルをサポートし、ストレージの一貫性を維持するために、ドキュメント・フレームワークは、ストアに置かれたすべてのモデルのコマンドをそのストアにログ (log：記録）する。モデルは個別に書くことはできないが、ダーティ・モデルはすべて常に一緒に書かれる。このようにすると、モデルが書かれるときコマンド・ログ全体が各ストアから除去されるので、コマンド・ログの処理が単純化されることになる。モデルはドキュメントがクローズされると書かれるが、ドキュメントがオープンしているときは定期的にも書かれるので、システム障害が起こったときドキュメントの再始動時間が短縮されることになる。
【０１０５】
ドキュメント間通信
ドキュメント・フレームワークでは、各ドキュメントは各自のチームで実行される。ドキュメント・フレームワークの標準機能の多くをサポートするには、ドキュメントは相互間で通信できるようになっていなければならない。例えば、ハイパテキスト・リンキングによると、ドキュメント間でデータをプッシュし、プルすることができ、ドキュメント間でリンクをたどっていくことができる。この処理を行うために、図２０に示すように、ドキュメント・フレームワーク１７００は外部ドキュメント２００４のためのクライアント／サーバ・インタフェース２００２を用意している。外部ドキュメントと通信するために、ドキュメントのルート・モデルのサロゲートからTRemoteDocument が作成される。TRemoteDocument オブジェクトは、オープン、コマンドの送信、リンクの照会などを行うために使用することができる。
【０１０６】
ドキュメント始動
新しいチームは、始動される各新しいドキュメントごとに作成しなければならない。特定のルート・タイプをもつドキュメントを作成する「アプリケーション」を書くことができるが、必ずしもそのようにする必要はない。ドキュメント・フレームワークは実行時システムによってTTaskProgramの中で提供される機能を使用して、該当のオブジェクトをドキュメント・チームに作成して始動する。ドキュメントは、ドキュメントのルート・モデルのサロゲートをもつTRemoteDocument を作成し、そのあとでドキュメントの要求を行うことにより始動され、代表例としてオープンされる。これにより、ドキュメント・チームが始動され、要求されたドキュメントが用意されたサロゲートを使用してオープンされる。ドキュメントでユーザ・インタフェースをオープンすること（つまり、選択したデータをアンカからコピーすること）を必要としないような、ドキュメントの他の要求を行うことも可能である。
【０１０７】
TDocument
TDocument クラスは、ドキュメント・データのコントローラの働きをする。これは、ドキュメント・チームに必要なフレームワークとサーバを作成する。これはファイリング・プロセスの制御も行う。TDocument は、ドキュメントが始動されたときTModelApplication によって自動的にインスタンシエイトされる。重要なメンバ関数として、SetSelection、 GetSelectionがある。
【０１０８】
TRemoteDocument
このクラスは、別のチームのドキュメントをアクセスすることを可能にする。１つのドキュメントだけがチームで動作できるので、２つのドキュメントがカット／コピー、ペースト、リンキングなどの目的でやりとりするのは、この方法によってのみである。また、ドキュメントを外部から制御することを可能にする。代表的な使用例としては、リンク・ナビゲーションとデータ転送、オープニング／クロージングなどがある。リモート・ドキュメント（別のチームのドキュメント）でコマンドを実行することをサポートするメンバ関数として、Doがある。
【０１０９】
リモート・ドキュメント内のアンカとデータをやりとりすることをサポートするメンバ関数として、CreatePreferredTypeList 、ChoosePreferredType 、Copy/AnchorData およびNotifyLinkがある。リモート・ドキュメントでユーザ・インタフェースをオープンし、クローズすることをサポートするメンバ関数として、Open、Close およびIsOpenがある。ドキュメントのオープン時とクローズ時に通知を受け取ることをサポートするメンバ関数として、CreateOpenInterestとCreateCloseInterest がある。
【０１１０】
図２１は、本システムと方法の全体的システム設計を示す図である。アプリケーション層２１０２はストレージ２１０４に置かれている現ドキュメント２１０６および関連ドキュメント２１０８とフロー２１１２を通してやりとりする。アプリケーション層２１０２は、本発明のシステム・レベル・ドキュメント・フレームワーク２１１０とも、円１で示すフロー２１１４を通してやりとりする。最後に、本発明のドキュメント・フレームワーク２１１０は、ストレージ２１０４に置かれている現ドキュメント２１０６および関連ドキュメント２１０８と、円２で示すフロー２１１６を通してやりとりする。
【０１１１】
ドキュメント・フレームワーク２１１０の詳細は上述した通りである。ドキュメント・フレームワーク２１１０は、アンカとリンク・サポート２１１８、通知２１２０、コラボレーション２１２２、組込み２１２４、データ・プレゼンテーション２１２６、データ変更２１２８、マルチレベル・アンドゥ２１３０、内容ベース検索とインデクシング２１３２、複合ドキュメント・サポート２１３４、データ表現２１３６、データ指定２１３８、モデル処理２１４０、およびドキュメント通信２１４２のオブジェクトが集まったもの（コレクション）である。前述したように、オブジェクトの多くに特別な発明性があるのは、システム・レベルに置かれて、システム・レベルの他のオブジェクトと併用して関数を提供するからであるが、オブジェクトのいくつかはシステムの他のレベルで考慮の対象にすることも可能であることはもちろんである。
【０１１２】
StockTicker の例
本発明のテクノロジの実際の応用を分かりやすくするために、実生活のアプリケーションを例にして説明することにする。まず、舞台を設定するために、複合ドキュメント・テクノロジについてレビュウすることにする。モデルとは、データを収容し、データをアクセスし、変更し、ユーザに提示する機能がデータを利用できるようにするものである。プレゼンテーションとは、モデル上にビュウを提供して、ユーザが読んで編集できるようにする機能である。クリップボードとは、ユーザの環境に関連づけられていて、カット／コピー−ペースト・オペレーションでクリップボード上に置かれているモデルを収めている特殊なモデルである。
【０１１３】
このアプリケーションは、米国内の各地のMerrill Linch オフィスに設置されているストック・チッカ(stock ticker - 株相場受信機）をエミュレートしたストック・チッカを実装している。ストック・チッカは、ニューヨーク証券取引所で取り引きされる種々の株式の現在株価を提示している。これは、ニューヨーク市の証券取引所に最終的に置かれているデータベースから現在株価を入力として受信している。通信リンクはこの分野では周知であるが、例えは、ASCII 文字を伝送する非同期シリアル通信リンクにすることも可能である。ASCII 文字は、ASCII 8 ビット文字と同期するように符号化された任意の数のフォント(font)を使用して、直接にディスプレイから表示されている。ディスプレイ・メカニズムはビュウ(view)と呼ばれ、任意の数の共通ウィンドウまたは他のディスプレイ・メカニズムにすることが可能であるが、これもこの分野では周知である。クリップボード・モデルはStockTicker インスタンスであるモデルを収めている。StockTicker インスタンスとは、ストック・ディスプレイをシミュレートするように準備状態に置かれた通信およびディスプレイ情報のことである。好適実施例をどのように使用すると、異種の情報からなる複合ドキュメントを使用可能にできるかを示すために、デスティネーション・モデルがペースト・オペレーションでStockTicker インスタンスを受信する場合について説明する。
【０１１４】
デスティネーション・モデルはドキュメントの一部であり、ドキュメントの「ルート」モデルのモデルにすることも、組込みモデルにすることも可能である。ペースト・コマンドはデスティネーション・ドキュメントで出される。このコマンドは２つの指定部分を含んでいる。つまり、１）コピーしようとする、クリップボード上のソース・モデルへの参照と、２）デスティネーション・ドキュメントの中でペーストしようとするロケーションの指定である。ペースト・コマンドのオペレーションは次のようなステップで行われる。まず、デスティネーション・モデルとソース・モデルとの間でタイプ交渉のやりとりが行われる。ソースはソースから得られるタイプ・リストを用意しており、デスティネーションは望ましいタイプを選択する。この場合、デスティネーションは特定のStockTicker データ・タイプを認識しないので、それを抽象的にモデルとして受け取ってそれを組み込む。デスティネーション・サイドはStockTicker モデルの新しいコピーを得て、これはデスティネーション・モデルに受け入れられる。デスティネーション・モデルは変更されているので、変更通知メッセージをそこでオープンされたすべてのプレゼンテーションへ送る。各プレゼンテーションは通知を受け取ると、そのステート（状態）を新しいStockTicker を含んでいる新しいモデル・ステートと同期をとり直す。例えば、プレゼンテーションは、そのステートを新しいモデル・ステートから完全に生成することで行うことができる。もっと最適化されたモデル・プレゼンテーション関係では、なにが変更されたかを、もっと特殊な通知でプレゼンテーションに正確に知らせるので、プレゼンテーションは変更されたものだけを更新することができる。その結果として、プレゼンテーションはStockTicker モデルを照会して、それ自身のプレゼンテーションを生成することになる。これは複雑なオペレーションであり、以下に説明する。
【０１１５】
StockTicker モデルがその応答として、プレゼンテーション・ビュウ・インスタンスを構築するとき、このStockTicker ビュウ・サブクラスのコンストラクタ(constructor) は次のようなステップを実行する。コンストラクタはビュウ・サブクラスによって所有されるスレッドを作成し、それを始動する。スレッドは次のようなステップを実行する関数に入る。これはウィンドゥとグラフィック機能がStockTicker プレゼンテーション・ビュウにグラフィックスを表示し、絶えず更新し、アニメーション化する準備状態に置く。これの具体例として「グラフィックス・ポート(graphics port) 」機能があり、これは、このスレッドによってプレゼンテーション・ビュウ上にドローイング（描画）されるグラフィックスの通路(conduit) となるものである。そのあと、ループに入って、データのアニメーション・プレゼンテーションをドローイングし、必要に応じてストック・データについて照会する。StockTicker プレゼンテーション・ビュウが正しく構築されると、これは外側プレゼンテーションのサブビュウ(subview) として採用されるか、あるいは、もっと一般的には、組込みエンティティを全体として管理する機能をサポートする中間ビュウの内側で折り返される。
【０１１６】
以上、特定のシステム環境における好適実施例を中心にして本発明を説明してきたが、この分野に精通した当業者ならば理解されるように、本発明は、請求の範囲に明確化されている本発明の精神と範囲内で、変更を加えることにより、他の異なるハードウェアおよびソフトウェア環境で実施することも可能である。
【図面の簡単な説明】
【０１１７】
【図１】本発明の好適実施例によるパーソナル・コンピュータ・システムを示すブロック図である。
【図２】リンク、アンカ、およびモデルを示すブロック図である。
【図３】アンドゥ（取消し）に関連する関数を示すブロック図である。
【図４】本発明のシステム・レベル・インデクシングと照会処理機能を示す図である。
【図５】本発明によるクラス表現を示すブロック図である。
【図６】本発明を使用して作成できる代表的ドキュメントを示す図である。
【図７】図６に示すドキュメントの階層構造を示す図である。
【図８】TModelの一般的特性を示す図である。
【図９】ドキュメント・フレームワーク・システムと一緒に使用できる通知フレームワークを示す図である。
【図１０】指定クラスを定義している関係を示す図である。
【図１１】TModelコマンド・グループに関連する関係を示す図である。
【図１２】DoBegin() の処理の流れを示す図である。
【図１３】DoRepeat()の処理の流れを示す図である。
【図１４】TModelAnchor用に確立された関係を示す図である。
【図１５】TModelLink用に確立された関係を示す図である。
【図１６】リンクの処理を示す図である。
【図１７】完全リンク(Complete Link) の処理を示す図である。
【図１８】ドキュメントとリンクされる注釈とスクリプトの使い方を示す図である。
【図１９】システムで利用できるリンク・プロパティの一部を示す図である。
【図２０】ドキュメント・フレームワークのクライアント／サーバと外部ドキュメントとの関係を示す図である。
【図２１】本発明の方法とシステムを示すブロック図である。
【符号の説明】
【０１１８】
１０ 中央処理ユニット
１２ システム・バス
１４ ランダム・アクセス・メモリ（ＲＡＭ）
１６ リード・オンリ・メモリ（ＲＯＭ）
１８ 入出力アダプタ
２０ ディスク・ユニット
２１ 入出力周辺デバイス
２２ ユーザ・インタフェース・アダプタ
２３ データ処理ネットワーク
２４ キーボード
２６ マイクロホン
２８ スピーカ
３２ マウス
３４ 通信アダプタ
３６ ディスプレイ・アダプタ
３８ ディスプレイ・デバイス
【特許請求の範囲】
【請求項１】
プロセッサと、種々のタイプのデータを包含するストレージと、前記プロセッサの制御下に置かれたディスプレイとを有するコンピュータ・システムで使用されるドキュメント処理装置であって、
複数のモデル・オブジェクトを前記ストレージ内でインスタンシエイトする手段であって、各モデル・オブジェクトは、特定タイプのデータ、他のモデル・オブジェクトおよびメソッドを包含するコンテナであり、各々がそのデータ・タイプにしたがって前記包含されたデータを処理しかつ全ての包含されたモデル・オブジェクト内で対応するメソッドを呼び出すために呼び出すことができる、インスタンシエイトする手段と、
前記モデル・オブジェクトの一つをルート・モデル・オブジェクトとして選択し、少なくとも一つの他のモデル・オブジェクトを、前記ルート・モデル・オブジェクトのコンテナ内に追加することにより、複合ドキュメントを作成する手段と、
前記ルート・モデル・オブジェクト内でメソッドを呼び出すことにより前記複合ドキュメント上で動作を実行して前記包含されたデータを処理し、かつ包含されたモデル・オブジェクトの各々において対応する前記メソッドを呼び出し、そのうえ前記包含されたモデル・オブジェクトはそのデータ・タイプにしたがってその包含されたデータを処理し、かつ任意の包含されたモデル・オブジェクトにおいて前記対応するメソッドを呼び出す手段と
を具備することを特徴とする装置。
【請求項２】
前記ルート・モデル・オブジェクトにおいて呼び出されるメソッドはストリーミング・メソッドであり、かつ前記ルート・モデル・オブジェクトがその包含されたデータを前記ストレージにストリーミングし、包含されたオブジェクトの各々の前記ストリーミング・メソッドを呼び出すことをもたらし、それにより包含されたオブジェクトの各々がその包含されたデータを前記ストレージにストリーミングすることをもたらすストリーミング・メソッドであることを特徴とする請求項１に記載のドキュメント処理装置。
【請求項３】
前記ルート・モデル・オブジェクトにおいて呼び出されるメソッドはコピー・メソッドであり、かつ前記ルート・モデル・オブジェクトがその包含されたデータのコピーを生成し、包含されたオブジェクトの各々の前記コピー・メソッドを呼び出すことをもたらし、それにより包含されたオブジェクトの各々がその包含されたデータのコピーを生成することをもたらすコピー・メソッドであることを特徴とする請求項１に記載のドキュメント処理装置。
【請求項４】
前記ルート・モデル・オブジェクトにおいて呼び出されるメソッドはファイル・メソッドであり、かつ前記ルート・モデル・オブジェクトがその包含されたデータを前記ストレージにファイリングし、包含されたオブジェクトの各々の前記ファイル・メソッドを呼び出すことをもたらし、それにより包含されたオブジェクトの各々がその包含されたデータを前記ストレージにファイリングすることをもたらすファイル・メソッドであることを特徴とする請求項１に記載のドキュメント処理装置。
【請求項５】
前記ルート・モデル・オブジェクトに包含されたモデル・オブジェクトの少なくとも一つは、前記ルート・モデル・オブジェクトに包含されたデータの部分を指定するアンカ・モデル・オブジェクトであり、前記ルート・モデル・オブジェクトは、前記アンカ・オブジェクトにより指定されるデータの部分を他のデスティネーションに転送するメソッドを含むことを特徴とする請求項１に記載のドキュメント処理装置。
【請求項６】
前記他のデスティネーションは、前記ルート・モデル・オブジェクトに包含されたアンカ・モデル・オブジェクトであることを特徴とする請求項５に記載のドキュメント処理装置。
【請求項７】
前記他のデスティネーションは、他の複合ドキュメントに包含されたアンカ・モデル・オブジェクトであることを特徴とする請求項５に記載のドキュメント処理装置。
【請求項８】
モデル・オブジェクトを指定するアドレス空間独立なオブジェクト・モデル・サロゲートを更に具備することを特徴とする請求項１に記載のドキュメント処理装置。
【請求項９】
プロセッサと、種々のタイプのデータを包含するストレージと、前記プロセッサの制御下に置かれたディスプレイとを有するコンピュータ・システムにおいて使用されるドキュメント処理方法であって、
(a) 複数のモデル・オブジェクトであって、各モデル・オブジェクトは特定タイプのデータ、他のモデル・オブジェクトおよびメソッドを包含するコンテナであり、各々がそのデータ・タイプにしたがって前記包含されたデータを処理しかつ全ての包含されたモデル・オブジェクト内で対応するメソッドを呼び出すことができる複数のモデル・オブジェクトをインスタンシエイトするステップと、
(b) 前記モデル・オブジェクトの一つをルート・モデル・オブジェクトとして選択し、少なくとも一つの他のモデル・オブジェクトを、前記ルート・モデル・オブジェクトのコンテナ内に追加することにより、複合ドキュメントを作成するステップと、
(c) 前記ルート・モデル・オブジェクト内でメソッドを呼び出すことにより前記複合ドキュメント上で動作を実行して前記包含されたデータを処理し、かつ包含されたモデル・オブジェクトの各々において対応する前記メソッドを呼び出し、そのうえ前記包含されたモデル・オブジェクトはその包含されたデータをそのデータ・タイプにしたがって処理し、かつ任意の包含されたモデル・オブジェクトにおいて前記対応するメソッドを呼び出すステップと
を具備することを特徴とする方法。
【請求項１０】
ステップ(c)において呼び出されるメソッドはストリーミング・メソッドであり、かつ前記ルート・モデル・オブジェクトがその包含されたデータを前記ストレージにストリーミングし、包含されたオブジェクトの各々の前記ストリーミング・メソッドを呼び出すことをもたらし、それにより包含されたオブジェクトの各々がその包含されたデータを前記ストレージにストリーミングすることをもたらすストリーミング・メソッドであることを特徴とする請求項９に記載のドキュメント処理方法。
【請求項１１】
ステップ(c)において呼び出されるメソッドはコピー・メソッドであり、かつ前記ルート・モデル・オブジェクトがその包含されたデータのコピーを生成し、包含されたオブジェクトの各々の前記コピー・メソッドを呼び出すことをもたらし、それにより包含されたオブジェクトの各々がその包含されたデータのコピーを生成することをもたらすコピー・メソッドであることを特徴とする請求項９に記載のドキュメント処理方法。
【請求項１２】
ステップ(c)において呼び出されるメソッドはファイル・メソッドであり、かつ前記ルート・モデル・オブジェクトはその包含されたデータを前記ストレージにファイリングし、包含されたオブジェクトの各々の前記ファイル・メソッドを呼び出すことをもたらし、それにより包含されたオブジェクトの各々はその包含されたデータを前記ストレージにファイリングすることをもたらすファイル・メソッドであることを特徴とする請求項９に記載のドキュメント処理方法。
【請求項１３】
前記ルート・モデル・オブジェクトに包含されたモデル・オブジェクトの少なくとも一つは、前記ルート・モデル・オブジェクトに包含されたデータの部分を指定するアンカ・モデル・オブジェクトであり、前記ルート・モデル・オブジェクトは、前記アンカ・オブジェクトにより指定されるデータの部分を他のデスティネーションに転送するメソッドを更に具備することを特徴とする請求項９に記載のドキュメント処理方法。
【請求項１４】
前記他のデスティネーションは、前記ルート・モデル・オブジェクトに包含されたアンカ・モデル・オブジェクトであることを特徴とする請求項１３に記載のドキュメント処理方法。
【請求項１５】
前記他のデスティネーションは、他の複合ドキュメントに包含されたアンカ・モデル・オブジェクトであることを特徴とする請求項１３に記載のドキュメント処理方法。
【請求項１６】
モデル・オブジェクトを指定するアドレス空間独立なオブジェクト・モデル・サロゲートを更に具備することを特徴とする請求項９に記載のドキュメント処理方法。
【請求項１】
プロセッサと、種々のタイプのデータを包含するストレージと、前記プロセッサの制御下に置かれたディスプレイとを有するコンピュータ・システムで使用されるドキュメント処理装置であって、
複数のモデル・オブジェクトを前記ストレージ内でインスタンシエイトする手段であって、各モデル・オブジェクトは、特定タイプのデータ、他のモデル・オブジェクトおよびメソッドを包含するコンテナであり、各々がそのデータ・タイプにしたがって前記包含されたデータを処理しかつ全ての包含されたモデル・オブジェクト内で対応するメソッドを呼び出すために呼び出すことができる、インスタンシエイトする手段と、
前記モデル・オブジェクトの一つをルート・モデル・オブジェクトとして選択し、少なくとも一つの他のモデル・オブジェクトを、前記ルート・モデル・オブジェクトのコンテナ内に追加することにより、複合ドキュメントを作成する手段と、
前記ルート・モデル・オブジェクト内でメソッドを呼び出すことにより前記複合ドキュメント上で動作を実行して前記包含されたデータを処理し、かつ包含されたモデル・オブジェクトの各々において対応する前記メソッドを呼び出し、そのうえ前記包含されたモデル・オブジェクトはそのデータ・タイプにしたがってその包含されたデータを処理し、かつ任意の包含されたモデル・オブジェクトにおいて前記対応するメソッドを呼び出す手段と
を具備することを特徴とする装置。
【請求項２】
前記ルート・モデル・オブジェクトにおいて呼び出されるメソッドはストリーミング・メソッドであり、かつ前記ルート・モデル・オブジェクトがその包含されたデータを前記ストレージにストリーミングし、包含されたオブジェクトの各々の前記ストリーミング・メソッドを呼び出すことをもたらし、それにより包含されたオブジェクトの各々がその包含されたデータを前記ストレージにストリーミングすることをもたらすストリーミング・メソッドであることを特徴とする請求項１に記載のドキュメント処理装置。
【請求項３】
前記ルート・モデル・オブジェクトにおいて呼び出されるメソッドはコピー・メソッドであり、かつ前記ルート・モデル・オブジェクトがその包含されたデータのコピーを生成し、包含されたオブジェクトの各々の前記コピー・メソッドを呼び出すことをもたらし、それにより包含されたオブジェクトの各々がその包含されたデータのコピーを生成することをもたらすコピー・メソッドであることを特徴とする請求項１に記載のドキュメント処理装置。
【請求項４】
前記ルート・モデル・オブジェクトにおいて呼び出されるメソッドはファイル・メソッドであり、かつ前記ルート・モデル・オブジェクトがその包含されたデータを前記ストレージにファイリングし、包含されたオブジェクトの各々の前記ファイル・メソッドを呼び出すことをもたらし、それにより包含されたオブジェクトの各々がその包含されたデータを前記ストレージにファイリングすることをもたらすファイル・メソッドであることを特徴とする請求項１に記載のドキュメント処理装置。
【請求項５】
前記ルート・モデル・オブジェクトに包含されたモデル・オブジェクトの少なくとも一つは、前記ルート・モデル・オブジェクトに包含されたデータの部分を指定するアンカ・モデル・オブジェクトであり、前記ルート・モデル・オブジェクトは、前記アンカ・オブジェクトにより指定されるデータの部分を他のデスティネーションに転送するメソッドを含むことを特徴とする請求項１に記載のドキュメント処理装置。
【請求項６】
前記他のデスティネーションは、前記ルート・モデル・オブジェクトに包含されたアンカ・モデル・オブジェクトであることを特徴とする請求項５に記載のドキュメント処理装置。
【請求項７】
前記他のデスティネーションは、他の複合ドキュメントに包含されたアンカ・モデル・オブジェクトであることを特徴とする請求項５に記載のドキュメント処理装置。
【請求項８】
モデル・オブジェクトを指定するアドレス空間独立なオブジェクト・モデル・サロゲートを更に具備することを特徴とする請求項１に記載のドキュメント処理装置。
【請求項９】
プロセッサと、種々のタイプのデータを包含するストレージと、前記プロセッサの制御下に置かれたディスプレイとを有するコンピュータ・システムにおいて使用されるドキュメント処理方法であって、
(a) 複数のモデル・オブジェクトであって、各モデル・オブジェクトは特定タイプのデータ、他のモデル・オブジェクトおよびメソッドを包含するコンテナであり、各々がそのデータ・タイプにしたがって前記包含されたデータを処理しかつ全ての包含されたモデル・オブジェクト内で対応するメソッドを呼び出すことができる複数のモデル・オブジェクトをインスタンシエイトするステップと、
(b) 前記モデル・オブジェクトの一つをルート・モデル・オブジェクトとして選択し、少なくとも一つの他のモデル・オブジェクトを、前記ルート・モデル・オブジェクトのコンテナ内に追加することにより、複合ドキュメントを作成するステップと、
(c) 前記ルート・モデル・オブジェクト内でメソッドを呼び出すことにより前記複合ドキュメント上で動作を実行して前記包含されたデータを処理し、かつ包含されたモデル・オブジェクトの各々において対応する前記メソッドを呼び出し、そのうえ前記包含されたモデル・オブジェクトはその包含されたデータをそのデータ・タイプにしたがって処理し、かつ任意の包含されたモデル・オブジェクトにおいて前記対応するメソッドを呼び出すステップと
を具備することを特徴とする方法。
【請求項１０】
ステップ(c)において呼び出されるメソッドはストリーミング・メソッドであり、かつ前記ルート・モデル・オブジェクトがその包含されたデータを前記ストレージにストリーミングし、包含されたオブジェクトの各々の前記ストリーミング・メソッドを呼び出すことをもたらし、それにより包含されたオブジェクトの各々がその包含されたデータを前記ストレージにストリーミングすることをもたらすストリーミング・メソッドであることを特徴とする請求項９に記載のドキュメント処理方法。
【請求項１１】
ステップ(c)において呼び出されるメソッドはコピー・メソッドであり、かつ前記ルート・モデル・オブジェクトがその包含されたデータのコピーを生成し、包含されたオブジェクトの各々の前記コピー・メソッドを呼び出すことをもたらし、それにより包含されたオブジェクトの各々がその包含されたデータのコピーを生成することをもたらすコピー・メソッドであることを特徴とする請求項９に記載のドキュメント処理方法。
【請求項１２】
ステップ(c)において呼び出されるメソッドはファイル・メソッドであり、かつ前記ルート・モデル・オブジェクトはその包含されたデータを前記ストレージにファイリングし、包含されたオブジェクトの各々の前記ファイル・メソッドを呼び出すことをもたらし、それにより包含されたオブジェクトの各々はその包含されたデータを前記ストレージにファイリングすることをもたらすファイル・メソッドであることを特徴とする請求項９に記載のドキュメント処理方法。
【請求項１３】
前記ルート・モデル・オブジェクトに包含されたモデル・オブジェクトの少なくとも一つは、前記ルート・モデル・オブジェクトに包含されたデータの部分を指定するアンカ・モデル・オブジェクトであり、前記ルート・モデル・オブジェクトは、前記アンカ・オブジェクトにより指定されるデータの部分を他のデスティネーションに転送するメソッドを更に具備することを特徴とする請求項９に記載のドキュメント処理方法。
【請求項１４】
前記他のデスティネーションは、前記ルート・モデル・オブジェクトに包含されたアンカ・モデル・オブジェクトであることを特徴とする請求項１３に記載のドキュメント処理方法。
【請求項１５】
前記他のデスティネーションは、他の複合ドキュメントに包含されたアンカ・モデル・オブジェクトであることを特徴とする請求項１３に記載のドキュメント処理方法。
【請求項１６】
モデル・オブジェクトを指定するアドレス空間独立なオブジェクト・モデル・サロゲートを更に具備することを特徴とする請求項９に記載のドキュメント処理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【公開番号】特開２００７−１２０８０（Ｐ２００７−１２０８０Ａ）
【公開日】平成１９年１月１８日（２００７．１．１８）
【国際特許分類】
【出願番号】特願２００６−２０３５７９（Ｐ２００６−２０３５７９）
【出願日】平成１８年７月２６日（２００６．７．２６）
【分割の表示】特願平７−５１３７８１の分割
【原出願日】平成６年１月３日（１９９４．１．３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ウィンドウズ
【出願人】（５００２６９９５６）オブジェクト テクノロジー ライセンシング コーポレイション (12)
【Ｆターム（参考）】
【公開日】平成１９年１月１８日（２００７．１．１８）
【国際特許分類】
【出願日】平成１８年７月２６日（２００６．７．２６）
【分割の表示】特願平７−５１３７８１の分割
【原出願日】平成６年１月３日（１９９４．１．３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ウィンドウズ
【出願人】（５００２６９９５６）オブジェクト テクノロジー ライセンシング コーポレイション (12)
【Ｆターム（参考）】
[ Back to top ]