JPH09510034A - コンピューターヒューマンインタフェースにおいて文書パーツとエディタとを結合するシステム - Google Patents

Abstract

(57)【要約】 コンピューターヒューマンインタフェースに、文書の基本的構造の要素としてパーツを採用する。１つのパーツがオープンしたとき、コンピュータで最も効率的に使用できるプログラムを利用可能とするように、エディタをそのパーツに結合する。その結合システムは最初にそのパーツに好適なエディタがコンピュータで利用可能であるかどうかを決定する。もし、利用可能であれば、そのエディタがパーツと結合され、これがまだ実行されていないなら起動される。一方、その好適なエディタが利用可能でないなら、システムはカテゴリや種類のようなパーツの内容の種々の特徴に基づいて、そのパーツに関する最適なハンドラを関係づけるように試みる。もし、コンピュータ上で適切なエディタや他のハンドラが利用可能であれば、それがパーツと結合されて起動される。もし、必要であれば、そのパーツはある種類のものから、エディタが利用可能な別の種類のものに変換される。さて、コンピュータで利用可能なプログラム中に、そのパーツについて適切なエディタがないなら、最後の手段としてのハンドラがエディタとしてそのパーツに結合される。この種のハンドラは、通常、パーツの特定の種類の内容を操作するエディタに関係した機能を全く使用することはできないが、パーツをユーザに呈示できるようにするジェネリックなツールである。

Description

【発明の詳細な説明】 コンピューターヒューマンインタフェースにおいて 文書パーツとエディタとを結合するシステム発明の属する分野 本発明はパーツが文書についての基本的な構築ブロックを形成するようにした コンピューターヒューマンインタフェースのアークテクチュアに関するものであ り、特に、パーツがオープンされたときエディタをそのパーツに結合するシステ ムに関するものである。発明の背景 パーツが文書についての基本的な構築ブロックを形成するようにしたコンピュ ーターヒューマンインタフェースのアークテクチュアは、１９９３年５月１０日 出願の米国特許出願第08/058260 号に説明されている。パーツは、２つの基本的 な構成要素、即ち、内容と、その内容の操作子或はハンドラで構成される自己完 結的なエンティティである。一般的に、そのハンドラはそのパーツのいくらか或 いは全ての内容に追加をしたり、そこから削除したり、さもなくば修正したりす るために必要な機能を提供しているエディタである。例えば、もし、そのパーツが テキスト文書を有していれば、その内容はテキストであり、そのパーツの構成要 素となるエディタは、ユーザがそのテキストを編集できるようにするワードプロ セッシングソフトウェアである。或は、そのパーツの構成要素を形成するハンド ラはビューワでも良い、これによって、ユーザはパーツの内容を見ることができ る。しかし、そのビューワに編集可能な機能は備えられていない。 この種のアーキテクチュアでは、パーツの内容はそれ自身によっては存在しな い。むしろ、その内容は常にパーツがアクティブであればいつでもハンドラと関 係づけられる。言い換えると、パーツがオープンしたとき、パーツの構成要素を 形成するハンドラもまたオープンされ、バックグランンドで実行され、これによっ てその機能がユーザに利用可能となる。 どのパーツであっても、それに関連したある特性をもっている。これらの特性 の１つは、そのパーツに関する好適なエディタの認識である。パーツが最初に創 成されたとき、そのパーツを創成するために用いられたプログラムは、普通は、 好適なエディタとして認識される。例えば、テキストパーツについて考えると、 好適なエディタは、その文書を創成するために用いられた特定のワードプロセッ シングプログラムを認識するかもしれない。この特性は、パーツとともに保存さ れる。そのパーツが次にオープンされるときはいつも、そのワードプロセッシン グプログラムが起動され、その結果、その機能はユーザがそのパーツの内容にア クセスするとき、利用可能となる。 そのパーツに関する好適なエディタをもっていない別のコンピュータシステム へあるコンピュータシステムからパーツが移される場合がある。或は、好適なエ ディタがそのシステムから除去されることがあるかもしれない。例えば、そのエ ディタが単に試行的に用いられていたり、或は、その試用期間が過ぎてしまった 場合があるかもしれない。これらの場合、システムで利用可能な異なるハンドラ がそのパーツに割当てられねばならない。従って、最適で利用可能なハンドラを パーツに割当て、これによってそのパーツがアクセスされるときにはいつもその 機能を利用可能にするシステムを提供することが望まれている。パーツにハンド ラを割当てるこのプロセスは、バインディング（結合）として知られている。本発明の簡単な説明 本発明は、コンピュータで最も効率的に使用できるプログラムを利用可能にす るように、パーツにハンドラを結合するシステムを提供する。その結合動作は、 パーツのオープン時、或は、ハンドラの機能にアクセスする必要があると判断さ れる適切な時に、発生する。その結合動作において、本発明のシステムは、まず 、コンピュータ上でパーツに関して好適なエディタが利用可能であるかどうかを 決定する。もし、利用可能であれば、そのエディタがパーツと結合され、これが まだ実行されていないなら起動される。一方、その好適なエディタが利用可能で ないなら、本発明のシステムはカテゴリや種類のようなパーツの内容の種々の特 徴に基づいて、そのパーツに関する最適なハンドラを関係づける。もし、コンピュ ータ上で適切なエディタや他のハンドラが利用可能であれば、それがパーツと結 合 されて起動される。もし、コンピュータで利用可能なプログラム中にそのパーツ に適切なハンドラがないなら、そのパーツをエディタが利用可能な別の種類のも のに変換するかどうかを決定する。もし、変換するように決定されたなら、その パーツは変換され、ハンドラが結合される。さもなければ、最後の手段としての ハンドラがエディタとしてそのパーツに結合される。この種のハンドラは、通常 、パーツの特定の種類の内容を操作するエディタに関係した機能を全く使用する ことはできないが、パーツをユーザに呈示できるようにするジェネリックなツー ルである。 以下、本発明の特徴について、付属した図面によって説明されている好適な実 施例を参照して説明する。図面の簡単な説明 図１Ａ及び図１Ｂは、パーツを採用した図形インタフェースによって生成され る画面を示す図である。 図２は、本発明の結合システムの基本的なプロセスを示すフローチャートであ る。 図３は、Ｄirect Ｂinding（直接接合）ルーチンのステップを示すフローチャ ートである。 図４は、パーツの種類によって直接結合する手順のステップを示すフローチャ ートである。 図５は、カテゴリエディタを関係ずけるプロセスを示すフローチャートである 。 図６は、パーツの種類に基づいてハンドラを選択するサブルーチンのフローチ ャートである。 図７は、Ｔranslated Ｂinding（変換結合）のルーチンのフローチャートであ る。 図８は、選択されたカテゴリに従ったＴranslated Ｂinding(変換結合)サブル ーチンのフローチャートである。 図９は、ハンドラリスト内でカテゴリエディタを関係づけるサブルーチンのフ ローチャートである。 図１０は、選択されないカテゴリにおける変換結合のサブルーチンのフロー チャートである。詳細な説明 本発明の理解を容易にするために、文書の基本的な構成要素としてパーツを採 用したコンピューターヒューマンインタフェースについてまず説明する。ここで 説明する特定の例では、アップルコンピュータ株式会社によって供給されている マッキントッシュ（登録商標）ブランドのコンピュータに適したインタフェース を説明する。しかしながら、本発明の原理はこの特定な例に限定されるものでは ないことを理解すべきである。 図１Ａ及び図１Ｂは、パーツを採用したコンピューターヒューマンインタフェ ースを介してユーザに提示される画面を示す図である。これらの画面はワークス ペース３６を定義するデスクトップ３４を示している。また、デスクトップには メニューバー３８が含まれている。ワークスペース３６内には２つのウィンドウ ４０、４２がある。左側のウィンドウ４０はフォルダウィンドウであり、種々のパ ーツを示すアイコンを含んでいる。図１Ａに示されているように、３つのアイコ ン４４はテキストパーツに関係しており、４番目のアイコン４５は図形パーツで あり、もう１つのアイコン４６は帳票パーツである。６番目のアイコン４８はプ レゼンテーション・スライドの創成のために用いられるパーツを表現するステー ショナリ・アイコンである。図１Ａにおいて、右側のウィンドウ４２はテキスト 文書を含んでいる。具体的には、その文書はテキストパーツ５０を含んでいる。 このテキストパーツは、ウィンドウ４２内にテキストをタイプするか或は１つの アイコンによって表現される以前に創成されたテキストパーツをウィンドウ内で オープンすることによって創成される。 図１Ｂは図形アイコン４５が左側のウィンドウ４０のフォルダから右側のウィ ンドウ４２のテキスト文書にドラッグする動作を行なったときの結果を示してい る。図１Ａ及び図１Ｂに示されるようなデスクトップメタフォーを採用するユー ザインタフェースでは知られているように、ドラッギングとはマウスのような適 当なカーソル制御デバイスを起動することでデスクトップ上やウィンドウ内でオ ブジェクトを移動させたり、コピーしたりする動作のことである。いったん、図 形アイコンが文書内に置かれると、その内容がフレーム５２に表示される。今や 、文書はテキストも図形要素も含んでいるのであるから、それは複合文書として 言及される。 複合文書において、例えば、エディタのような異なるプログラム実行モジュー ルは協働して１つに統合された情報の体裁をなすようにする。そのような実行モ ジュール各々は、文書の全ての情報の内容の１つのセグメント、即ち、パーツを 制御する。ここで、文書のパーツは互いに関係するように制約が設けられる。そ の制約によって、ユーザは含まれる或は埋め込まれた従属パーツが主たるコンテ ナパーツとともに移動したり、その主たるコンテナパーツによって影響を受けた りすることを予想できる論理的な関係を表現することができる。テキスト５０と フレーム５２内の図形要素とは夫々別々のパーツに属しており、これらが一緒に なって複合文書を構成する。図形パーツはこの具体例の場合、テキストパーツに 含まれている。 パーツは内容とその内容の操作子成はハンドラとから構成される自己完結型の エンティティである。これら２つの構成要素は、そのパーツがアクセスされたと きは、それが、デスクトップのどこに位置していようと、常に利用可能である。 従って、図１Ａに示すように、図形アイコン４５がウィンドウ４０のフォルダに 位置しているとき、それは、図形要素とその要素についてのエディタとを含むパー ツを表現している。そのパートがウィンドウ４２の文書に移動したとき、その内 容もパーツとともに移動し、それらの内容のエディタの機能もユーザにはすぐに 利用可能である。 この特徴で重要なことは、パーツの内容は、それがどこに位置していようとも 常に編集可能、さもなければ、操作可能であるという事実である。従って、図１ Ｂの複合文書において、テキストの内容５０は、その文書内で、例えば、そのテ キストを初めて創成したときに用いられたと同じワードプロセッサを用いて編集 可能である。図形エディタが、フレーム５２によって表現されるパーツの構成要 素として存在しているので、パーツの図形要素も適宜に直接編集可能となる。従っ て、ユーザが別の図形アプリケーションを、例えば、デスクトップ３４の別のウィ ンドウでオープンし、その図形情報を所望の形に編集し、その後、編集された図 形をウィンドウ４２の文書に移動させる必要はない。むしろ、ユーザは、直接、 ウィンドウ４２の文書の内容の中で、中間的な過程を組み込むことなく、フレー ム５２の内容を編集することができる。ユーザは、アプリケーションプログラム ではなく、むしろ、文書の内容に注意を集中することができ、周辺の文書によっ て備えられた文脈を利用することができる。 それ故に、パーツとは、基幹システム技術における自律性のある自己完結的な オブジェクトである。それは、どんな種類のソフトウェアエンジンでも環境でも 使用することができ、ユーザはパーツについて特別なエディタの操作を学ぶ必要 はない。そのパーツに適したエディタが基幹システムで表現されている限り、ユー ザは、そのパーツの能力を十分に利用することができる。さらに、もし、テキス ト部分が特別なテキストエディタ（ワードプロセッサ）で生成されたとしても、 ユーザはただそのテキストエディタをそのパーツとともに用いるように限定され ている訳ではない。もし、そのユーザが異なるワードプロセッサのコマンドによ り親しんでいるなら、例えば、そのワードプロセッサを、その文書或はコンピュー タシステムでの全てのテキストパーツに関する好適なエディタとして指定できる 。 パーツに関するエディタ或はハンドラは、従来のコンピュータシステムでのア プリケーションプログラムに類似している。それは、パーツの内容を表示したり 、適当であればこれらの内容を修正するためのユーザインタフェースを呈示する ための必要な機能を提供するソフトウェア要素である。これには、メニューや、 コントローラや、ツールパレットや、他のユーザインタラクティブな機能が含ま れる。他のパーツを含むことができるパーツに関して言えば、そのエディタは、 その内容を表示するとき、これら含まれた従属のパーツを考慮にいれる。例えば 、テキストエディタはそのパーツの内容を包み込み、その内容が埋め込まれた図 形パーツ内で現れないようにする。 パーツは数多くのそれに関連した特性をもっている。これらの１つは、その好 適なエディタである。例えば、パーツが最初に創成されたとき、そのパーツを創 成するために用いられたプログラムはその好適なエディタとして識別される。そ の後、その好適なエディタは変更可能である。通常、そのような変更はユーザの 好みに合わせて、ユーザによってなされる。これとは別に、或は、これに加えて 、 好適なエディタの変更は、例えばシステムのデフォルトに合わせて、システムに よって自動的になされることもある。 パーツの別の特性は、そのタイプ或は種類と呼ばれるものである。種々の種類 のパーツが異なるカテゴリに分類される。一般的に言って、カテゴリは、テキス ト、図形、帳票などのパーツの内容についての情報のいくつかのジェネリックな クラスの１つを識別する。この種類という特性は、その内容の１つ以上の特徴を 示唆する。例えば、その種類は、内容の属性（イタリック体）、データ形式（Ｐ ＩＣＴ或はＴＩＦＦファイル）、或は、テキストを創成するために用いた特定の ワードプロセッサが備えるようなテキストに関連したフォーマッティングや他の 制御コードを本質的に識別する他の顕著な特徴を示す。 パーツに関するより詳細な情報、パーツに基づいた図形インタフェースについ ては上述の米国特許出願第08/058260 号に見いだすことができ、そこで開示され た情報は参照として本願に組み込まれている。 従来のアプリケーションプログラムによって提供される機能を利用するために 、プログラムが起動され実行されねばばらない。言い換えると、それはコンピュ ータシステムの主記憶メモリに格納しておかねばならない。これと同じような方 法で、文書パーツに基づくインタフェースにおいて、パーツがユーザによってア クセスされたとき、そのパーツについてのエディタもシステムメモリさもなけれ ばコンピュータのＣＰＵにアクセス可能なメモリで実行しなければならない。そ のようにするために、エディタはシステムにインストールされなければならない 。例えば、それは、フォルダ或はハードディスクのような永久記憶メモリのサブデ ィレクトリに格納され、関連するパーツがアクセスされたとき呼び出し可能とな っている。システム資源を無駄にしないため、全てのインストールされたエディ タは全時間システムメモリにロードしておく必要はない。むしろ、これらは必要 に応じて起動される。例えば、パーツについてのエディタは、パーツが文書にドラ ッグされたとき、このときがエディット能力が最も必要とされるときであるので 、起動される。 従って、パーツの内容へのアクセスが必要であるときはいつでも、エディタと そのパーツとを関係づけることが望ましい。特定のエディタをパーツに関連づけ るプロセスは、バインディング（結合）として知られている。通常、結合はパー ツが最初にオープンしたとき実行され、そのパーツがオープンしている限り、エ ディタとそのパーツとの結合は続く。或は、エディタをパーツとを別のときに結 合されることが望ましいかもしれない。例えば、そのパーツを含むウィンドウが アクティブとなっているとき、たとえそのパーツ自身がそのウィンドウ内でまだ オープンされていなくとも、結合を実行しても良い。 もちろん、全てのエディタが、パーツがアクセスされるどのコンピュータシス テムでも利用可能であるという訳ではないだろう。例えば、あるコンピュータシ ステムで特定のワードプロセッシングプログラムを用いて、テキスト文書が創成 される。従って、そのパーツに関する好適なエディタとは、それを創成したとき も用いたワードプロセッサである。さて、そのパーツが最初にそれを創成したと きに用いたものとは異なるワードプロセッシングプログラムを採用した他のコン ピュータに移動することは有り得る。従って、この別のコンピュータシステムで そのパーツがアクセスされたとき、そのパーツに関する好適なエディタは、利用 可能ではない。そのような場合、そのシステムで利用可能なものからそのパーツ と結合するのに適した別のエディタを認識することが必要である。 本発明は、そのコンピュータシステムで利用可能なものからパーツについて最 適なハンドラを識別し、そのハンドラとそのパーツとを結合する手順に関するも のである。本発明に従って、エディタとパーツとを結合する全般的な手順につい ての概要は、図２のフローチャートに図示されている。この全般的な手順の個々 のステップの詳細はこれに続く図のフローチャートに図示されている。 ハンドラとパーツとを関係づける必要があるときにはいつでも、この結合手順 が実行される。通常、これは、パーツがクローズされた状態や隠された状態から 最初にオープンしたとき、実行される。例えば、マウスボタンが押下されたとき やスクリプト内のステップにおいて生成されるイベントフラグに応答して、この 結合は発生するかもしれない。ハンドラとパーツとを結合する他の適切な時には 、パーツがシステムに最初にロードされた時や、パーツを含むウィンドウのオー プン時や、パーツがアクティブな文書にドラッグされた時がある。 図２において、いったん結合を開始する適切なイベントが検出されたなら、本 発明のシステムはまず、Ｄirect Ｂinding（直接結合）（ステップ２０１）とし て知られるルーチンを実行する。Ｄirect Ｂindingにおいて、パーツに関して好 適なエディタ、或は、もし好適なエディタが利用可能でないなら、そのパーツの 内容の種類の１つをサポートする別のハンドラを確認する試みがなされる。適し たハンドラが確認されたとき、それがパーツに結合される。適切な基準を満たす パーツのハンドラが利用可能でないなら、Ｄirect Ｂindingはうまくいかなかっ たことになる。ステップ２０２において、Ｄirect Ｂindingルーチンがうまく実 行できたかどうかを判別する。もし、うまく実行されたなら、システムは結合プ ロセス（ステップ２０３）と呼ばれるプログラムに進む。 Ｄirect Ｂindingルーチンがうまく実行できなかったなら（ステップ２０２に おける応答がネガティブ（ＮＯ））、手順はＴranslated Ｂinding（変換結合） を実行する（ステップ２０４）。このプロセスでは、パーツの内容をハンドラが 利用可能な種類に変換する試みがなされる。そのような手順によってうまくいく 可能性があれば、そのパーツは変換され、利用可能なハンドラが変換されたパー ツに結合される。もし、ステップ２０５で判断されるように、その手順の結果が よいものであれば、システムはステップ２０３に進む。しかしながら、ステップ ２０５においてその応答がネガティブ（ＮＯ）であれば、即ち、Ｔranslated Ｂ inding（変換結合）ルーチンの実行がうまくいかなったなら、システムはステッ プ２０６においてパーツを最後の手段となるハンドラと結合する。最後の手段と なるハンドラは、そのパーツをユーザに呈示できるようにするプログラム実行モ ジュールである。そのハンドラの機能に依存して、パーツの内容が表示できるよ うになる。さもなければ、そのパーツは空のボックスとして表示され、ユーザに は文書全体のどこにそれが位置するのかを可視化して示すようにする。例えば、 最後の手段としてのハンドラが図１Ｂの例において、図形パーツに関して用いら れていた場合、フレーム５２の輪郭は表示されるかもしれないが、内部の内容に ついては表示されない。最後の手段としてのハンドラはまた、パーツについての 、そのパーツが明らかに変換された特定の種類であるといったある限定された情 報を提供する。 図３には、ステップ２０１のＤirect Ｂindingルーチンの詳細が示されている 。 ステップ３０１では、システムは好適なハンドラがそのパーツに指定されている かどうかを判別する。もし、好適なハンドラが指定されていれば、ステップ３０ ２ではその好適なハンドラがコンピュータシステム上で利用可能であるかどうか を判別する。もし、それが利用可能であれば、ステップ３０３ではそのハンドラ がそのパーツに結合されたハンドラであると認識される。例えば、ハンドラを識 別する唯一の文字列が、結合プロセスを呼び出したプログラムに返される。この 文字列は、そのパーツがアクセスされたときにはいつでも参照されるローカル変 数として記憶される。適当なフラグがステップ３０４でセットされ、Ｄirect Ｂ indingルーチンの実行がうまくいったことを示す。そして、システムは図２のフ ローチャートのステップ２０２に戻る。 もし、ステップ３０１において好適なハンドラが指定されていないか、或は、 ステップ３０２において確認できないなら、システムはどんな種類のデータがパ ーツに含まれているかを決定する。もし、そのパーツが多数の種類のデータから 構成されているなら、その１種類が選択される（ステップ３０５、３０６）。好 適には、その種類はデータの忠実度の順番に従って選択される。この点に関して 、どのハンドラにもそのエディタについての好適な種類とカテゴリのリストが伴 っている。異なる種類やカテゴリのデータは同じ情報を表現すると言えるが、定 性的に言えば、そのエディタの機能性を考慮するとあるものの表現能力は別のも のよりもその質が良いこともあれば、悪いこともある。定性的に比較的良質の種 類のデータが、高い忠実度をもっていると認識される。忠実度についてのデータ 種類に関する所定の順番というものはない。むしろ、忠実度は常に特定の状況に よって決定される。エディタは多くの異なる種類のデータをサポートすることが できるかもしれず、それ故に適切なデータ構造は、忠実度の順序に従って、特定 のエディタに関連するデータ種のリストを保存している。例えば、ワードプロセ ッシングプログラムは通常は異なる種類のテキストを扱うことができる。これら の異なる種類の忠実度の順序は、（１）リッチテキスト、（２）スタイルテキス ト、（３）プレインテキスト等である。 それゆえ、どのパーツも忠実度の順序に従ってリストされた異なる種類のデー タを有している。この順番は、そのパーツに最後に結合したエディタによって決 定される。ステップ３０６では、この種のデータが、忠実度の順序に従って、選 択される。パーツに関して１種類のデータが選択された後、システムはステップ ３０７でＤirect Ｂind Ｂy Ｋindとラベルされたルーチンを実行する。このル ーチンにおいて、システムは、ハンドラが選択された種類をサポートするために 存在するかどうかを判別する。もし、それが存在すれば、そのハンドラがパーツ に結合されたハンドラであるとして認識される（ステップ３０８、３０９）。そ して、それがうまくいったことを示すフラグ（成功フラグ）がステップ３０４で セットされる。もし、ステップ３０７において、そのルーチンがその種のパーツ についてのハンドラを確認できなければ、システムはステップ３０５に戻り、そ のパーツがまだ検証されていない別の種類の内容を含んでいるかどうかを判別す る。もし、別の種類の内容を含んでいるなら、ステップ３０７のＤirect Ｂind Ｂy Ｋindルーチンがその種の内容に関して繰り返し実行される。このプロセス は、パーツの内容の１種類についてハンドラが認識されるまで続く。もし、パー ツの種類の何れに対してもハンドラが見つからなければ、プロセスはステップ３ １０に進み、成功フラグをリセットし、失敗の状態にする。そして、システムは ステップ２０２に戻る。 ステップ３０７のＤirect Ｂind Ｂy Ｋindサブルーチンの詳細は、図４のフ ローチャートに図示されている。この図において、文書各々（１以上のパーツを 含む）は、ハンドラの限定されたリストと関係づけられている。このリストは、 ユーザがその文書に関して好適である１セットのハンドラを選択するときに、形 成される。ステップ４０１では、システムはＣhoose Ｂy Ｋindとラベルされた サブルーチンを実行する。このサブルーチンにおいて、システムはその文書に限 定されたリスト上のハンドラのいずれか１つがステップ３０６で選択された種類 のパーツをサポートしているかどうかを判別する。もし、サポートされていれば 、何らかの適切な手順を用いて、その選択された種類をサポートするハンドラの １つが選択される。例えば、その適切なハンドラは、アルファベット順にハンド ラをソートし、リスト上の最初のハンドラを選択することによって、選んでも良 い。 もし、Ｃhoose Ｂy Ｋindサブルーチンの実行が、ハンドラの選択でうまくい ったなら、そのハンドラがステップ４０３でパーツに結合される。そして、成功 フラ グがステップ４０４でセットされる。その後、プロセスはステップ３０８に戻る 。 さて、ステップ４０１のサブルーチンの実行が、ハンドラの選択でうまくいか なかったなら、ステップ４０６において選択された種類のパーツについての好適 なハンドラが基幹コンピュータシステムで識別されるかどうかを判別する。例え ば、最初にユーザがコンピュータシステムを構成するとき、パーツ各種に対して 好適なエディタをユーザは認識しているかもしれない。また、好適なハンドラは 自動的にそのコンピュータシステムで選択されることもある。或は、他のいくつ かの適当な手順によって、好適なハンドラを認識するようにしても良い。好適な ハンドラが指定されたなら、システムはステップ４０７でそのハンドラがシステ ムに現在存在しているかどうかを判別する。もし、存在していれば、そのハンド ラはパーツにステップ４０８で結合され、ステップ４０４で成功フラグをセット した後、そのプロセスは続行する。 もし、指定された好適なハンドラがなかったり、或は、それが現在システム上 に存在していないなら、サブルーチンがステップ４０９で実行され、そのパーツ のカテゴリに従って、ハンドラが利用可能であるかどうかを判別する。このサブ ルーチンの詳細は、図５のフローチャートに図示されている。その図において、 このサブルーチンでは、選択された種類のパーツに関連する種々のカテゴリに基 づいて、ハンドラが選択される。具体的にいうと、どの種類のパーツも少なくと も１つのカテゴリと関係している。ある種のパーツについていえば、１つ以上の カテゴリと関連があるかもしれない。ステップ５０１、５０２では、選択された 種類のパーツに関連するカテゴリの１つが選択され、ステップ５０３では、その コンピュータシステムがそのカテゴリのパーツについて好適なハンドラをもって いるかどうかを判別する。もし、そのようなハンドラをもっていれば、ステップ ５０４では、その好適なハンドラが選択された種類のパーツに適しているかどう か、即ち、その機能がその種のパーツをサポートしているかどうかを判別する。 もし、そのハンドラが適していれば、ステップ５０５においてそのハンドラが現 在システムに存在しているかどうかを判別する。もし、存在していれば、そのハ ンドラがステップ５０６で選択され、成功フラグがセットされる。もし、このプ ロセスの結果として、何のハンドラも選択されなければ、システムはステップ５ ０１に戻り、選択された種類のパーツが別のカテゴリと関連しているかどうかを 判別する。もし、他の何かのカテゴリと関連していれば、そのプロセスは、ハン ドラが選択されるか或は全てのカテゴリを調べてしまうまで、繰り返される。も し、どのカテゴリについてのハンドラを選択することができなければ、成功フラ グはステップ５０７でリセットされ、そのプロセスは図４のフローチャートのス テップ４１０に戻る。 再び、図４において、ステップ４０９のサブルーチンの実行がうまくいけば、 選択されたハンドラはステップ４１１においてパーツに結合され、成功フラグが ステップ４０４でセットされる。さもなければ、そのプロセスはステップ４１２ のサブルーチンに進む。このサブルーチンでは、選択された種類をサポートする ハンドラの確認がなされる。そのサブルーチンの詳細は、図６に図示されている 。この図において、ステップ６０１、６０２では、システムはコンピュータシス テムで現在利用可能な全てのハンドラから１つを選択する。ステップ６０３では 、このハンドラが選択された種類のパーツに適しているかどうかを判別する。も し、それが適したものであれば、このハンドラは検証済ハンドラの一時的なリス トに加えられる（ステップ６０４）。ステップ６０１〜６０４は、選択された種 類のパーツに相対するコンピュータシステム上で現在利用可能である全てのハン ドラが検証されるまで繰り返され、検証済ハンドラの一時的なリストを創成して いく。その後、ステップ６０５では、検証済ハンドラのリストがソートされ、エ ディタがビューワの前に置かれ、これら２つのカテゴリ各々の内でハンドラはア ルファベット順或は何か他の適切な順番に調整される。その後、ステップ６０６ では、それらハンドラの１つ、例えば、リストの最上位にあるハンドラ、がリス トから選択される。それから、このプロセスは図４のフローチャートのステップ ４１３に戻る。もし、そのサブルーチンの実行がハンドラの選択においてうまく ゆけば、そのハンドラはステップ４１４でパーツに結合され、成功フラグがステ ップ４０４でセットされる。一方、図４のＤirect Ｂind Ｂy Ｋindルーチン実 行の結果として、何のハンドラも選択されなかったなら、成功フラグはステップ４ １５でリセットされ、システムは図３のフローチャートのステップ３０８に戻る 。 パーツに関する全ての種類を検証後、Ｄirect Ｂindingルーチンがハンドラを 選 択することができないなら、ステップ２０３のＴranslated Ｂindingルーチンが 実行される。このルーチンのプロセスは、図７のフローチャートに図示されてい る。Ｔranslated Ｂindingルーチンの最初のステップとして（ステップ７０１） 、システムは、指定されたカテゴリに関して変換が実行されるサブルーチンを実 行する。そのサブルーチンの各ステップは、図８に図示されている。この図にお いて、ステップ８０１では、パーツの種類が“all kinds（全種）”とラベルさ れているリストに格納される。ステップ８０２と８０３では、このリストにある １種類が選択され、リスト上の残りのエントリは“other kinds（他種）”とラ ベルされている第２のリストに格納される。システムは、選択された種類が変換 可能な種類のパーツを認識する。このことは、例えば、コンピュータシステムで 利用可能な変換機能によって決定される。これら認識されたパーツ種は、目的種 のリストに格納される。他種のリストに格納されているパーツ種は、目的種のリ ストから除去される。他種のリストにあるパーツ種を目的種のリストから除去す る理由は、これら他種のパーツはＤirect Ｂindingルーチンの実行中に適したハ ンドラの存在に関して既に検証されているという事実のためである。Ｔranslate d Ｂindingルーチンが今実行されているという事実によって、適切なハンドラは 他種のリストにあるパーツ種に関しては存在しないことが前に判別されている。 従って、Ｔranslated Ｂindingルーチンにおいて、これらの種類のパーツをこれ 以上検証する必要はない。 ステップ８０４では、選択種に関連した種々のカテゴリが識別される。目的種 のリストにあるエントリが検証され、このリスト上のどんな種類も、選択種につ いてのカテゴリの１つと同じ関連するカテゴリをもたないなら、これらもまた除 去される。それ故に、目的種のリストは、選択種が変換可能であり、選択種と共 通の少なくとも１つのカテゴリを有し、他種のリストに現れない全ての種類を含 んでいる。 ステップ８０５と８０６では、目的種のリストにおける種類のパーツの１つが 選択され、ステップ８０７では、以前に図４のフローチャートに関して説明した ように、Ｄirect Ｂind Ｂy Ｋindサブルーチンが実行される。もし、そのサブ ルーチンの実行が利用可能なハンドラを確認するのにうまくいけば、そのハンド ラは ステップ８０８において目的ハンドラのリストに付加される。また、ハンドラが 見つけられなければ、選択された目的種はステップ８０９において、目的種のリ ストから除去される。それから、プロセスはステップ８０５に戻り、他の目的種 が検証のために残存しているかどうかを判別する。このプロセスの結果により、 注目しているパーツが変換可能な目的種に適したシステム上の全てのハンドラの リストが創成される。 全目的種の検証後、システムはステップ８１０で目的ハンドラのリストが空と なったかどうかを判別する。もし、空になっていないなら、即ち、少なくとも１ つのハンドラがＤirect Ｂind Ｂy Ｋindサブルーチンの実行結果として、確認 されたなら、システムはステップ８１１に進む。このステップでは、サブルーチ ンが実行され、カテゴリに基づいて、目的ハンドラの１つを選択する。このサブ ルーチンの各ステップは、図９のフローチャートに図示されている。この図にお いて、ステップ９０１、９０２では、選択種のパーツ（ステップ８０３で認識さ れるように）についてのカテゴリの１つが選択される。ステップ９０３では、シ ステムの好適なエディタがそのカテゴリについて認識されたかどうかを判別する。 もし、認識されたならば、ステップ９０４では、システムはそのハンドラがス テップ８０８で設けられた目的ハンドラのリストに見出されるかどうかを判別す る。もし、見出されれば、ステップ９０５において、選択されたハンドラが現在 コンピュータシステムにあるかどうかを判別するチェックを行う。もし、そのハ ンドラが見出されたならば、このハンドラが選択され、成功フラグがステップ９ ０６でセットされる。その時、システムは図８のサブルーチンに戻り、その図の ステップ８１２では、成功フラグの状態が認識され、選択されたハンドラはステ ップ８１３で選択されたカテゴリについての好適なハンドラであると定められる 。 もし、最初に選択されたカテゴリに関して、何のハンドラも見つからなければ 、システムはステップ９０１に戻り、別のカテゴリを選択し、システムの好適な ハンドラがそのカテゴリで見出されるかどうかを判別する。このプロセスは、ハ ンドラが見出されるまで、各カテゴリについてステップ９０２〜９０５でループ する。全てのカテゴリについての検証がなされた後も、ハンドラが見出されなけ れば、ステップ９０７において成功フラグには失敗（false）状態がセットされ る。 このサブルーチン実行の結果として、何のハンドラも選択されないなら、シス テムはステップ８１４に進み、そこで、何らかの好適な手順に従って、目的ハン ドラのリストにあるハンドラの１つが選択される。例えば、前述のように、ハン ドラのリストがアルファベット順にソートされ、さらなる処理のために、そのリ スト上の最上位にあるハンドラが選択される。 ステップ８１４でいったんハンドラが選択されれば、目的種のリストが検証さ れ、どの種類が選択エディタによって最も高い忠実度をもつと考えられるかを決 定する。最大の忠実度をもつ種と関連したカテゴリが識別され、各々のカテゴリ についてシステムの好適なエディタがあるかどうかが判別される。どのカテゴリ もシステムの好適なエディタを未だ有していないなら、選択されたエディタは、 ステップ８１６で、そのカテゴリについてのシステムの好適なエディタであると 設定がなされる。その後、成功フラグがセットされ、ステップ７０２での肯定的 な応答（ＹＥＳ）によりシステムはステップ７０３へと進み、そこで選択された ハンドラがパーツに結合される。その後、ステップ７０４では、そのパーツは、 目的種のリストにあるもので、選択されたハンドラが最も高い忠実度をもつと考 える種類に変換される。 再び図８において、ステップ８１０で目的種のリストが空であることが分かっ たなら、或は、ハンドラがステップ８１４で選択されていないなら、システムは ステップ８０２に戻り、そのパーツが未だ検証されていない他の関連種を有して いるかどうかを判別する。もし、これを有しているなら、処理は他の種類に関し ても繰り返される。また、全ての種について検証後にも、ハンドラが選択できな いなら、成功フラグはステップ８１８でリセットされ、そして、そのフラグがス テップ７０２でチェックされる。ハンドラが選択されていないので、システムは ステップ７０５のサブルーチンに進む。そのサブルーチンは図１０で詳細に図示 されている。 ステップ７０１のサブルーチンにおいて、注目パーツに関連するカテゴリの１ つをサポートする利用可能なハンドラを確認することがなされる。もし、その手 順の実行がうまくいかないなら、ステップ７０５のサブルーチンは他のカテゴリ のパーツに基づいて利用可能なハンドラを確認することを試みる。図１０におい て、ステップ１００１〜１００３では、注目するパーツの１種が選択され、その 選択種についての目的種のリストが形成され、他の種類についてはそのリストか ら除去される。この処理はステップ８０１〜８０３と同様である。ステップ１０ ０４では、目的種のリストではそのリストから、選択種と関連したカテゴリのい づれかと同じ関連したカテゴリをもった種類を除去する。言い換えると、ステッ プ１００４で実行されるプロセスは、ステップ８０４で実行される手順の補完と なっている。ステップ８０５〜８０９に対応したステップ１００５〜１００９で は、目的種とハンドラのリストを創成するために実行される。その後、ステップ １０１０では、これらのリストが空であるかどうかを判別する。もし、空でない なら、即ち、少なくとも１つの目的とするハンドラが確認されれば、そのハンド ラの１つが無作為に或は何かの望ましい技術を用いてステップ１０１１で選択さ れ、成功フラグがステップ１０１２でセットされる。その後、プロセスは図７の フローチャートに戻り、ステップ７０６で選択されたハンドラがパーツに結合さ れる。その後、ステップ７０４では選択ハンドラが最も高い忠実度をもっている と考える目的種が選択され、パーツはその種に変換される。成功フラグが再びセッ トされ、そのプロセスは終了する。 これに対して、目的とするハンドラが選択されなかったなら、成功フラグがス テップ１０１３でリセットされる。その後、プロセスはステップ２０４に戻り、 ハンドラ選択において、Ｄirect Ｂindingルーチンの実行もＴranslated Ｂindi ngルーチンの実行もうまくいかなかったとの決定がなされる。従って、最後の手 段としてのハンドラがステップ２０５においてパーツに結合される。 従って、要約すると、本発明ではパーツに関する最適なエディタ、或は、他の ハンドラを識別し、そのハンドラをパーツに結合する手順が提供される。動作の 好適なモードでは、まず、パーツを変換する必要なく、そのパーツを構成する種 類の１つに適したハンドラを結合することが試みられる。もし、そのパーツの好 適なエディタがその基幹コンピュータシステムに存在するなら、そのエディタが 選択される。さもなければ、一連の優先度に基づいて、１つのエディタが選択さ れる。これらの優先度にはその種のパーツを取り扱うその文書に限定されたエデ ィタのセット、その種のパーツについてのシステムの好適なエディタ群、その 種のパーツを取り扱うことができるカテゴリのパーツについてのシステムの好適 なエディタ群、その種のパーツを取り扱う何か他のエディタからのエディタを含 んでいる。エディタの選択において、これらのどの方法もうまくいかないなら、 変換がなされる。この方法では、注目するパーツについて変換可能であり、その パーツのカテゴリと互換性のある種類の１つについてのエディタが認識される。 そのようなエディタが見つからないなら、他のカテゴリのパーツと互換性のある エディタが選択される。これら種々の基準値に基づいて、適したエディタが利用 可能ではないことが分かれば、最後の手段としてのハンドラがパーツに結合され 、そのパーツをシステムのユーザに呈示できるようにする。 本発明の理解を容易にするために、その原理を具体的な実施例を参照して説明 した。しかしながら、本発明を実際に適用することはこの特定の実施例に限定さ れるものではないことは言うまでもない。例えば、適切なハンドラを確認するた めの種々のサブルーチンや、これらサブルーチンに含まれるステップは、ここで 説明した特定の順序で実行される必要はない。異なる順序のステップで種々の基 準で検証することにより、好ましい結果が得られる。従って、本発明の範囲は、 以下のクレームによって記述され、前述の説明によって定義されるものではない 。そして、クレームの意味に矛盾のない全ての等価物が、その範囲に含められる ものである。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＭＷ，ＳＤ，ＳＺ，ＵＧ)， ＡＭ，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，Ｃ Ｈ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ ，ＧＥ，ＨＵ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ， ＬＫ，ＬＲ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＮ，Ｍ Ｗ，ＭＸ，ＮＬ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＴ，ＵＡ， ＵＳ，ＵＺ，ＶＮ 【要約の続き】 る。この種のハンドラは、通常、パーツの特定の種類の 内容を操作するエディタに関係した機能を全く使用する ことはできないが、パーツをユーザに呈示できるように するジェネリックなツールである。

Claims (1)

1. 【特許請求の範囲】 １． 文書が内容と前記内容のハンドラとを有する複数のパーツに基づいており 、前記内容が複数の異なる種類のデータの内、少なくとも１つのデータに属して いるとして認識されるようなコンピューターヒューマンインタフェースを備えた コンピュータシステムにおいて、パーツにハンドラを結合する結合方法であって 、 前記パーツに含まれる少なくとも１種類のデータを取り扱うに適したコ ンピュータシステムにおいて利用可能なハンドラがあるかどうかを判別し、前記 ハンドラが利用可能であると判別された時には、前記ハンドラを前記パーツに結 合する判別・結合工程と、 前記ハンドラが利用可能でない場合、前記パーツが変換可能なデータの 別の種類を決定する決定工程と、 前記決定された別の種類の内、いづれか１種類のデータに適した利用可 能なハンドラを前記システムで識別する第１識別工程と、 前記パーツの内容を、前記識別されたハンドラに適した前記決定された 別の種類のデータの１種類に変換する第１変換工程と、 前記変換されたパーツを前記識別されたハンドラに結合する第１結合工 程とを有することを特徴とする結合方法。 ２． パーツを前記コンピュータシステムのユーザに呈示可能にする最後の手段 としてのハンドラを提供する第１提供工程と、 前記決定された別の種類のデータのいずれにも適したハンドラが利用可能 でない場合、前記最後の手段としてのハンドラを前記パーツに結合する第２結合 工程とをさらに有することを特徴とする請求項１に記載の結合方法。 ３． 前記判別・結合工程は、 前記パーツが好適なハンドラを識別する情報を含んでいるかどうかを判 別する第１判別工程と、 前記好適なハンドラが識別されたとき、前記コンピュータシステムで前 記識別された好適なハンドラが利用可能であるかどうかを判別する第２判別工程 と、 前記識別された好適なハンドラが利用可能であるとき、前記パーツへの 結合のため、前記好適なハンドラを選択する第１選択工程とを含むことを特徴と する請求項１に記載の結合方法。 ４． 前記判別・結合工程は、さらに 前記パーツを含む文書に限定されたハンドラのセットを提供する第２提 供工程と、 前記限定されたセットにおけるハンドラのいずれかが、前記パーツに含 まれたデータの種類に適しているかどうかを判別する第３判別工程と、 前記データの種類に適した１つのハンドラを前記限定されたセットから 選択する第２選択工程とを含むことを特徴とする請求項３に記載の結合方法。 ５． 前記パーツの内容は、夫々対応する忠実度をもった複数種類のデータに関 連づけられ、前記種類の１つが、それ以外の他の種類に相対的な忠実度に基づい て選択されることを特徴とする請求項４に記載の結合方法。 ６． 前記データの種類各々の忠実度は、最後に前記パーツに結合されたハンド ラによって決定されることを特徴とする請求項５に記載の結合方法。 ７． 前記コンピュータシステムが前記選択されたデータ種類に好適なハンドラ の識別情報を含んでいるかどうかを判別する第４判別工程と、 前記コンピュータシステムにおいて前記好適なハンドラが識別され、前記 好適なハンドラが利用可能であれば、前記好適なハンドラを選択する第３選択工 程とをさらに有することを特徴とする請求項５に記載の結合方法。 ８． データ種類各々は少なくともデータの１つのジェネリックなカテゴリと関 連づけられ、 前記選択されたデータ種類に関連したカテゴリを識別する第２識別工程と 、 前記カテゴリのデータに好適なハンドラの識別情報を前記コンピュータシ ステムが含んでいるかどうかを判別する第５判別工程と、 前記カテゴリに関して好適なハンドラが識別されたなら、前記好適なハン ドラが前記選択されたデータ類について適しているかどうかを判別する第６判別 工程と、 前記好適なハンドラが前記選択されたデータ種類について適しているなら 、前記識別されたカテゴリについて前記好適なハンドラを選択する第４選択工程 とをさらに有することを特徴とする請求項７に記載の結合方法。 ９． 好適なハンドラがシステムで識別されないなら、前記選択されたデータ種 類について適している、前記コンピュータシステムで利用可能な何らかのハンド ラから１つのハンドラを選択する第５選択工程をさらに有することを特徴とする 請求項８に記載の結合方法。 １０．前記決定工程は、 前記パーツの内容に関連するデータの１種類を選択する第６選択工程と 、 前記選択された種類が変換される目的となるデータ種類のセットを決定 する第１決定工程と、 前記セットから、前記パーツの内容に関連する前記１種類を除く他の全 てのデータ種類を除去する第１除去工程と、 前記選択された種類に関連する１つ以上のジェネリックなカテゴリを決 定する第２決定工程と、 前記セットから、前記データのカテゴリの少なくとも１つにも関連しな い全ての前記目的となるデータ種類を除去する第２除去工程とを含むことを特徴 とする請求項１に記載の結合方法。 １１．前記第１識別工程は、 前記セットにおける前記目的となるデータ種類に適した、前記コン ピュータシステムで利用可能なハンドラを確認する確認工程と、 前記確認されたハンドラのいずれかが少なくとも前記カテゴリの１つに 適しているかどうかを判別する第７判別工程と、 適していると判別されたハンドラを選択する第７選択工程とを含むこと を特徴とする請求項１０に記載の結合方法。 １２．前記ハンドラのいずれもが、前記カテゴリのいづれにも適していないこと が判別されたなら、前記確認されたハンドラのいずれかからハンドラを選択する 第８選択工程をさらに含むことことを特徴とする請求項１１に記載の結合方法。 １３．前記第１変換工程は、 前記識別されたハンドラに関連する異なる種類のデータについての忠実 度の好適な順番を決定する第３決定工程と、 前記パーツの内容を、前記識別されたハンドラについて最も忠実度の高 い他の種類の内の１種のデータに変換する第１変換工程とを含むことを特徴とす る請求項１に記載の結合方法。 １４．文書が内容と前記内容のハンドラとを有する複数のパーツに基づいており 、前記内容が複数の異なる種類のデータの内、少なくとも１つのデータに属して おり、前記複数種類のデータ各々は対応する忠実度を有しているとして認識され るようなコンピューターヒューマンインタフェースを備えたコンピュータシステ ムにおいて、パーツにハンドラを結合する結合方法であって、 前記パーツに関し前記複数種類の内の１つの種類のデータを、前記パー ツについての他の種類のデータ種類に相対的な忠実度に基づいて、選択する第１ 選択工程と、 前記コンピュータシステムが前記選択された種類のデータに関して好適 なハンドラの識別情報を含むかどうかを判別する第１判別工程と、 前記好適なハンドラが識別され、前記好適なハンドラが前記コンピュー タシステムで利用可能である場合には、前記好適なハンドラを選択する第２選択 工程と、 前記選択されたハンドラを前記パーツに結合する第１結合工程とを有す ることを特徴とする結合方法。 １５． 前記パーツを含む前記文書に限定されたハンドラのセットを提供する第 １提供工程と、 前記限定されたセットにおいて、前記ハンドラのいずれかが前記選択さ れた種類のデータに適しているかどうかを判別する第２判別工程と、 前記限定されたセットから、前記種類のデータに適したハンドラの１つ を選択する第３選択工程とをさらに有することを特徴とする請求項１４に記載の 結合方法。 １６． データ種類各々の忠実度は、前記パーツに最後に結合されたハンドラに よって決定されることを特徴とする請求項１４に記載の結合方法。 １７． データ種類各々は少なくとも１つのジェネリックなカテゴリのデータに 関連しており、 前記選択された種類のデータに関連するカテゴリを識別する第１識別工 程と、 前記コンピュータシステムが前記カテゴリのデータに関して好適なハン ドラの識別情報を含むかどうかを判別する第３判別工程と、 前記カテゴリに関する好適なハンドラが識別されたなら、前記好適なハ ンドラが前記選択された種類のデータに適しているかどうかを判別する第４判別 工程と、 前記好適なハンドラが前記選択された種類のデータに適しているなら、 前記識別されたカテゴリに関して、前記好適なハンドラを選択する第４選択工程 とをさらに有することを特徴とする請求項１４に記載の結合方法。 １８． もし、好適なハンドラがシステム内で識別されなければ、前記選択され たデータ種類について適している１つのハンドラを、前記コンピュータシステム で利用可能な何らかのハンドラから選択する第５選択工程をさらに有することを 特徴とする請求項１７に記載の結合方法。 １９． 文書が内容と前記内容のハンドラとを有する複数のパーツに基づいてお り、前記内容が複数の異なる種類のデータの内、少なくとも１つのデータに属し ているとして認識されるようなコンピューターヒューマンインタフェースを備え たコンピュータシステムにおいて、パーツをある種類から別の種類に変換し、前 記変換されたパーツにハンドラを結合する変換結合方法であって、 前記パーツの内容が関連する１つの種類のデータを選択する第１選択工 程と、 前記選択された種類のデータが変換される目的となる種類のデータのセ ットを決定する第１決定工程と、 前記セットから、前記パーツの内容が関連する他の全ての種類のデータ を除去する第１除去工程と、 前記選択された種類のデータが関連する１つ以上のジェネリックなカテ ゴリのデータを決定する第２決定工程と、 前記セットから、前記カテゴリのデータの少なくとも１つとも関連のな い全ての目的となる種類のデータ除去する第２除去工程と、 前記セットにおける前記目的となる種類のデータに適する、前記コンピ ュータシステムで利用可能なハンドラを確認する確認工程と、 前記確認されたハンドラのいずれかが前記カテゴリの少なくとも１つに 適しているかどうかを判別する判別工程と、 適していると判別されたハンドラを選択する第２選択工程と、 前記パーツの内容を、前記選択されたハンドラが適している前記目的と なる種類の内の１つの種類のデータに変換する変換工程と、 前記変換されたパーツを前記選択されたハンドラに結合する結合工程と を有することを特徴とする変換結合方法。 ２０． 前記ハンドラのいずれもが、前記カテゴリのいずれにも適していないと 判別された場合には、前記確認されたハンドラのいずれかからハンドラを選択す る第３選択工程をさらに有することを特徴とする請求項１９に記載の変換結合方 法。 ２１． コンピュータにおいて、ハンドラを情報パーツに結合する結合システム であって、 前記コンピュータ内にあって利用可能なハンドラと、各ハンドラに関連 するデータ種類を識別する情報を格納する第１のデータ構造と、 パーツに含まれるデータ種類を識別する第２のデータ構造と、 利用可能なハンドラが前記パーツに含まれるデータ種類に関連している かどうかを判別する第１判別手段と、 もし、ハンドラが前記パーツに含まれるデータ種類に関連しているなら 、前記パーツに前記ハンドラを結合する第１結合手段と、 前記パーツの内容を変換可能なデータ種類を決定する決定手段と、 利用可能なハンドラが前記パーツの内容を変換可能なデータ種類のいず れかに関連しているかどうかを判別する第２判別手段と、 前記パーツの内容を、利用可能なハンドラに関連する種類のデータに変 換する変換手段とを有することを特徴とする結合システム。 ２２． 前記コンピュータのユーザにいかなるパーツも呈示可能にする最後の手 段としてのハンドラを格納する格納手段と、 前記利用可能なハンドラが前記パーツに含まれるデータ種類とも、前記 パーツの内容を変換可能なデータ種類とも関連がない場合には、前記パーツに前 記最後の手段としてのハンドラを結合する第２結合手段とをさらに有することを 特徴とする請求項２１に記載の結合システム。 ２３． 前記第２のデータ構造は、前記パーツに含まれるデータ種類各々につい ての忠実度の順番を認識し、 前記決定手段は、利用可能なハンドラが前記ータと関連しているどうか を判別するために、前記忠実度の順番で前記パーツに含まれるデータ種類を順次 選択することを特徴とする請求項２１に記載の結合システム。 ２４． データ種類各々は少なくとも１つのジェネリックなカテゴリのデータと 関連があり、 前記決定手段は、前記コンピュータが前記選択された種類のデータと関 連するカテゴリについての好適なハンドラを識別する情報を含んでいるかどうか を判別し、さらに、もし前記情報を含んでいるなら、前記好適なエディタが前記 選択された種類と関連しているかどうかを判別することを特徴とする請求項２３ に記載の結合システム。 ２５． 前記変換手段は、前記利用可能なハンドラと関連する異なる種類のデー タについての忠実度の好適な順番を決定し、変換に適した最も忠実度の高い種類 に前記パーツの内容を変換することを特徴とする請求項２１に記載の結合システ ム。 ２６．内容と前記内容のハンドラとを有する複数のパーツに基づいた文書を扱う コンピューターヒューマンインタフェースを備えたコンピュータにおいて、パー ツにハンドラを結合する結合システムであって、 各々が対応する忠実度をもつ複数の異なる種類のデータの内の少なくと も１つの種類に属するデータとして、パーツの内容を認識するデータ構造と、 前記パーツについての他の種類のデータに関する相対的な忠実度に基づ いて、前記パーツについて前記種類のデータの１つを選択する第１選択手段と、 前記コンピュータシステムが前記選択された種類のデータについて適し たハンドラを含んでいるかどうかを判別する第１判別手段と、 利用可能であると判別された適切なハンドラに前記パーツを結合する結 合手段とを有することを特徴とする結合システム。 ２７． 前記データ種類各々についての忠実度は、最後に前記パーツに結合され た前記ハンドラによって決定されることを特徴とする請求項２６に記載の結合シ ステム。 ２８． データ種類各々を少なくとも１つのジェネリックなカテゴリのデータに 関連づける情報を格納する格納手段と、 前記選択された種類のデータに関連するカテゴリを識別する識別手段と 、 前記コンピュータが前記カテゴリのデータに適したハンドラを含んでい るかどうかを判別し、もし前記カテゴリに適したハンドラが利用可能であれば、 前記ハンドラが前記選択された種類のデータに適しているかどうかを判別する第 ２判別手段と、 前記ハンドラが前記選択された種類のデータに適しているなら、前記識 別されたカテゴリが前記パーツに結合されるよう前記ハンドラを選択する第２選 択手段とをさらに有することを特徴とする請求項２６に記載の結合システム。