(57)【特許請求の範囲】
【請求項１】
プロセッサと、種々のタイプのデータを包含するストレージと、前記プロセッサの制御下に置かれたディスプレイとを有するコンピュータ・システムで使用されるドキュメント処理装置であって、
複数のモデル・オブジェクトを前記ストレージ内でインスタンシエイトする手段であって、各モデル・オブジェクトは、特定タイプのデータ、他のモデル・オブジェクトおよびメソッドを包含するコンテナであり、各々がそのデータ・タイプにしたがって前記包含されたデータを処理しかつ全ての包含されたモデル・オブジェクト内で対応するメソッドを呼び出すために呼び出すことができる、インスタンシエイトする手段と、
前記モデル・オブジェクトの一つをルート・モデル・オブジェクトとして選択し、少なくとも一つの他のモデル・オブジェクトを、前記ルート・モデル・オブジェクトのコンテナ内に追加することにより、複合ドキュメントを作成する手段と、
前記ルート・モデル・オブジェクト内でメソッドを呼び出すことにより前記複合ドキュメント上でオペレーションを実行して前記包含されたデータを処理し、かつ包含されたモデル・オブジェクトの各々において対応する前記メソッドを呼び出し、そのうえ前記包含されたモデル・オブジェクトはそのデータ・タイプにしたがってその包含されたデータを処理し、かつ任意の包含されたモデル・オブジェクトにおいて前記対応するメソッドを呼び出す手段と
を具備することを特徴とする装置。
【請求項２】
前記ルート・モデル・オブジェクトにおいて呼び出されるメソッドはストリーミング・メソッドであり、かつ前記ルート・モデル・オブジェクトがその包含されたデータを前記ストレージにストリーミングし、包含されたオブジェクトの各々の前記ストリーミング・メソッドを呼び出すことをもたらし、それにより包含されたオブジェクトの各々がその包含されたデータを前記ストレージにストリーミングすることをもたらすストリーミング・メソッドであることを特徴とする請求項１に記載のドキュメント処理装置。
【請求項３】
前記ルート・モデル・オブジェクトにおいて呼び出されるメソッドはコピー・メソッドであり、かつ前記ルート・モデル・オブジェクトがその包含されたデータのコピーを生成し、包含されたオブジェクトの各々の前記コピー・メソッドを呼び出すことをもたらし、それにより包含されたオブジェクトの各々がその包含されたデータのコピーを生成することをもたらすコピー・メソッドであることを特徴とする請求項１に記載のドキュメント処理装置。
【請求項４】
前記ルート・モデル・オブジェクトにおいて呼び出されるメソッドはファイル・メソッドであり、かつ前記ルート・モデル・オブジェクトがその包含されたデータを前記ストレージにファイリングし、包含されたオブジェクトの各々の前記ファイル・メソッドを呼び出すことをもたらし、それにより包含されたオブジェクトの各々がその包含されたデータを前記ストレージにファイリングすることをもたらすファイル・メソッドであることを特徴とする請求項１に記載のドキュメント処理装置。
【請求項５】
前記ルート・モデル・オブジェクトに包含されたモデル・オブジェクトの少なくとも一つは、前記ルート・モデル・オブジェクトに包含されたデータの部分を指定するアンカ・モデル・オブジェクトであり、前記ルート・モデル・オブジェクトは、前記アンカ・オブジェクトにより指定されるデータの部分を他のデスティネーションに転送するメソッドを含むことを特徴とする請求項１に記載のドキュメント処理装置。
【請求項６】
前記他のデスティネーションは、前記ルート・モデル・オブジェクトに包含されたアンカ・モデル・オブジェクトであることを特徴とする請求項５に記載のドキュメント処理装置。
【請求項７】
前記他のデスティネーションは、他の複合ドキュメントに包含されたアンカ・モデル・オブジェクトであることを特徴とする請求項５に記載のドキュメント処理装置。
【請求項８】
モデル・オブジェクトを指定するアドレス空間独立なオブジェクト・モデル・サロゲートを更に具備することを特徴とする請求項１に記載のドキュメント処理装置。
【請求項９】
プロセッサと、種々のタイプのデータを包含するストレージと、前記プロセッサの制御下に置かれたディスプレイとを有するコンピュータ・システムにおいて使用されるドキュメント処理方法であって、
（a） 複数のモデル・オブジェクトであって、各モデル・オブジェクトは特定タイプのデータ、他のモデル・オブジェクトおよびメソッドを包含するコンテナであり、各々がそのデータ・タイプにしたがって前記包含されたデータを処理しかつ全ての包含されたモデル・オブジェクト内で対応するメソッドを呼び出すことができる複数のモデル・オブジェクトをインスタンシエイトするステップと、
（b） 前記モデル・オブジェクトの一つをルート・モデル・オブジェクトとして選択し、少なくとも一つの他のモデル・オブジェクトを、前記ルート・モデル・オブジェクトのコンテナ内に追加することにより、複合ドキュメントを作成するステップと、
（c） 前記ルート・モデル・オブジェクト内でメソッドを呼び出すことにより前記複合ドキュメント上でオペレーションを実行して前記包含されたデータを処理し、かつ包含されたモデル・オブジェクトの各々において対応する前記メソッドを呼び出し、そのうえ前記包含されたモデル・オブジェクトはその包含されたデータをそのデータ・タイプにしたがって処理し、かつ任意の包含されたモデル・オブジェクトにおいて前記対応するメソッドを呼び出すステップと
を具備することを特徴とする方法。
【請求項１０】
ステップ（c）において呼び出されるメソッドはストリーミング・メソッドであり、かつ前記ルート・モデル・オブジェクトがその包含されたデータを前記ストレージにストリーミングし、包含されたオブジェクトの各々の前記ストリーミング・メソッドを呼び出すことをもたらし、それにより包含されたオブジェクトの各々がその包含されたデータを前記ストレージにストリーミングすることをもたらすストリーミング・メソッドであることを特徴とする請求項９に記載のドキュメント処理方法。
【請求項１１】
ステップ（c）において呼び出されるメソッドはコピー・メソッドであり、かつ前記ルート・モデル・オブジェクトがその包含されたデータのコピーを生成し、包含されたオブジェクトの各々の前記コピー・メソッドを呼び出すことをもたらし、それにより包含されたオブジェクトの各々がその包含されたデータのコピーを生成することをもたらすコピー・メソッドであることを特徴とする請求項９に記載のドキュメント処理方法。
【請求項１２】
ステップ（c）において呼び出されるメソッドはファイル・メソッドであり、かつ前記ルート・モデル・オブジェクトはその包含されたデータを前記ストレージにファイリングし、包含されたオブジェクトの各々の前記ファイル・メソッドを呼び出すことをもたらし、それにより包含されたオブジェクトの各々はその包含されたデータを前記ストレージにファイリングすることをもたらすファイル・メソッドであることを特徴とする請求項９に記載のドキュメント処理方法。
【請求項１３】
前記ルート・モデル・オブジェクトに包含されたモデル・オブジェクトの少なくとも一つは、前記ルート・モデル・オブジェクトに包含されたデータの部分を指定するアンカ・モデル・オブジェクトであり、前記ルート・モデル・オブジェクトは、前記アンカ・オブジェクトにより指定されるデータの部分を他のデスティネーションに転送するメソッドを更に具備することを特徴とする請求項９に記載のドキュメント処理方法。
【請求項１４】
前記他のデスティネーションは、前記ルート・モデル・オブジェクトに包含されたアンカ・モデル・オブジェクトであることを特徴とする請求項１３に記載のドキュメント処理方法。
【請求項１５】
前記他のデスティネーションは、他の複合ドキュメントに包含されたアンカ・モデル・オブジェクトであることを特徴とする請求項１３に記載のドキュメント処理方法。
【請求項１６】
モデル・オブジェクトを指定するアドレス空間独立なオブジェクト・モデル・サロゲートを更に具備することを特徴とする請求項９に記載のドキュメント処理方法。
【発明の詳細な説明】
著作権表記
本特許出願の一部には、著作権保護の対象となる内容が含まれている。著作権所有者は、米国特許商標庁の特許ファイルまたはレコードに記録されている特許文書または特許開示内容を何人もが原文通りに複製することを妨げるものではないが、その他の場合には、一切の著作権を所有することを留保する。
発明の分野
本発明は一般的にはコンピュータ・システムに関し、より具体的にはオブジェクト指向複合ドキュメント処理のための方法およびシステムに関する。
発明の背景
ドキュメント処理は、社会が紙を作り出す仕方に大変革をもたらした。従来の代表的ドキュメント処理システムはＤＯＳやＯＳ／２などの、オペレーティング・システム上で稼働している。最近では、これらのドキュメント処理システムはウィンドウズ環境で稼働する設計になっている。これらのドキュメント処理システムの多くは市販されている。
「インタメディア：  シームレス情報環境の概念と構造（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）をシステム・レベルでサポートすることにより達成されている。
【図面の簡単な説明】
図１は、本発明の好適実施例によるパーソナル・コンピュータ・システムを示すブロック図である。
図２は、リンク、アンカ、およびモデルを示すブロック図である。
図３は、アンドゥ（取消し）に関連する関数を示すブロック図である。
図４は、本発明のシステム・レベル・インデクシングと照会処理機能を示す図である。
図５は、本発明によるクラス表現を示すブロック図である。
図６は、本発明を使用して作成できる代表的ドキュメントを示す図である。
図７は、図６に示すドキュメントの階層構造を示す図である。
図８は、TModelの一般的特性を示す図である。
図９は、ドキュメント・フレームワーク・システムと一緒に使用できる通知フレームワークを示す図である。
図１０は、指定クラスを定義している関係を示す図である。
図１１は、TModelコマンド・グループに関連する関係を示す図である。
図１２は、DoBegin（）の処理の流れを示す図である。
図１３は、DoRepeat（）の処理の流れを示す図である。
図１４は、TModelAnchor用に確立された関係を示す図である。
図１５は、TModelLink用に確立された関係を示す図である。
図１６は、リンクの処理を示す図である。
図１７は、完全リンク（Complete Link）の処理を示す図である。
図１８は、ドキュメントとリンクされる注釈とスクリプトの使い方を示す図である。
図１９は、システムで利用できるリンク・プロパティの一部を示す図である。
図２０は、ドキュメント・フレームワークのクライアント／サーバと外部ドキュメントとの関係を示す図である。
図２１は、本発明の方法とシステムを示すブロック図である。
発明の詳細な説明
以下、本発明の実施例について詳しく説明する。なお、以下に開示されている実施例は本発明を単に例示したものにすぎず、種々態様に実現することが可能であることは勿論である。従って、以下に詳述する開示内容は限定的なものではなく、請求の範囲を判断するときの基礎となり、本発明を製造および／または使用する方法を、当業者に教示するときの基礎となるにすぎないものと理解すべきである。
オブジェクト指向プログラミングおよびフレームワーク開発の歴史は文献に記載されている。Ｃ++と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を使用しないで、独自に継承を行なうことをサポートしている。これは、階層内のすべてのモデルが同時にメモリに置かれているとは限らず、この動作はTInheritabaleAttributeGroupによってサポートされないからである。
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）として採用されるか、あるいは、もっと一般的には、組込みエンティティを全体として管理する機能をサポートする中間ビュウの内側で折り返される。
以上、特定のシステム環境における好適実施例を中心にして本発明を説明してきたが、この分野に精通した当業者ならば理解されるように、本発明は、請求の範囲に明確化されている本発明の精神と範囲内で、変更を加えることにより、他の異なるハードウェアおよびソフトウェア環境で実施することも可能である。
【図１】
0004425348.tif 000002
【図２】
0004425348.tif 000003
【図３】
0004425348.tif 000004
【図４】
0004425348.tif 000005
【図５】
0004425348.tif 000006
【図６】
0004425348.tif 000007
【図７】
0004425348.tif 000008
【図８】
0004425348.tif 000009
【図９】
0004425348.tif 000010
【図１０】
0004425348.tif 000011
【図１１】
0004425348.tif 000012
【図１２】
0004425348.tif 000013
【図１３】
0004425348.tif 000014
【図１４】
0004425348.tif 000015
【図１５】
0004425348.tif 000016
【図１６】
0004425348.tif 000017
【図１７】
0004425348.tif 000018
【図１８】
0004425348.tif 000019
【図１９】
0004425348.tif 000020
【図２０】
0004425348.tif 000021
【図２１】
0004425348.tif 000022