JPH01140238A - データ処理システム - Google Patents

データ処理システム

Info

Publication number
JPH01140238A
JPH01140238A JP63208001A JP20800188A JPH01140238A JP H01140238 A JPH01140238 A JP H01140238A JP 63208001 A JP63208001 A JP 63208001A JP 20800188 A JP20800188 A JP 20800188A JP H01140238 A JPH01140238 A JP H01140238A
Authority
JP
Japan
Prior art keywords
data
resource
link
resources
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP63208001A
Other languages
English (en)
Other versions
JP3113658B2 (ja
Inventor
Marc S Soucie
マーク・サン・ソウシー
Carolyn E Surprenant
キャロライン・イー・サプリナント
Thomas Fitzgerald
トーマス・フィッツジェラルド
Susan Walker
スーザン・ウォーカー
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wang Laboratories Inc
Original Assignee
Wang Laboratories Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Wang Laboratories Inc filed Critical Wang Laboratories Inc
Publication of JPH01140238A publication Critical patent/JPH01140238A/ja
Application granted granted Critical
Publication of JP3113658B2 publication Critical patent/JP3113658B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/543—User-generated data transfer, e.g. clipboards, dynamic data exchange [DDE], object linking and embedding [OLE]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/451—Execution arrangements for user interfaces

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Stored Programmes (AREA)

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 １、−の１ 本発明はカストマイズ可能のコンピュータシステムに関
し、特に種々のプログラム間でデータ資源を抜用するメ
カニズムを備えたシステムに関する。
゛　　　、−び　ロが　゛　べき喋題 データ処理システムにおいて繰返して起る多数の主要で
一般的な問題領域があり、これら問題ｆｆＩ域はデータ
および情報処理アプリケーションのタイプの範囲やユー
ザの数やタイプの増加に伴い現代のシステムにおいて益
々注目されてきている。
これらの領域は特に均一なシステムや環境におけるアプ
リケーション、データの統合、新しいアプリケーション
とデータタイプとを既存のアプリケーションやデータタ
イプと統合させるために、新しいアプリケーションやデ
ータタイプを既存システムに追加できる能力、アプリケ
ーションを更新しうる能力、特にビジネス上の利害やデ
ータの応用規模が国際的になるにつれてプログラムやデ
ータを一方の言語から他方の言語に変換できる能力、種
々のユーザがデータを共用できること、特にタイムリに
特定のデータを共用することにより各ユーザがデータの
特定ボディの最新バージョンを有することができること
、および一方のフオーム（ｆｏｒｍ）あるいはデータ構
造から他方のフオームまたは構造にデータを転換即ち交
換しうる能力を含む。
ユーザはグラフをドキュメントに含めたいと思うことが
ある。ユーザがグラフをドキュメントの文脈内から編集
できるようにする既存の一方法はドキュメントのエディ
タのグラフ編集機能を強化することである。この方法は
、（例えば音声の注釈のように）さらに新しいタイプの
データをドキュメントに続きするために、ドキュメント
エディタを再度修正する必要があるという欠点を有する
。
事実、各エディタは各々の新しいタイプのデータを扱う
よう個々に拡張されねばならない。
従来技術のあるシステムは、全てのデータタイプが「オ
ブジェクト」と称される標準化したデータ構造に常駐す
るオブジェクトベースのシステムを構成することにより
これらの問題を解決しようと試みて来たが、この従来技
術のシステｌ＼は全体的に、これらの問題を十分に解決
することに失敗した。特に、従来技術のシステムは一般
的に２種類の一方に該当する。第１の、古い方の種類の
ジステ１１においては、データタイプや応用プログラム
に対する制約が殆んど無く、その結果、新しいアプリケ
ーションやデータタイプを追加することは容易であるも
のの統合したシステムとユーザ環境を提供することは困
難で、かつユーザとデータタイプの間でデータ通信する
ことが極めて難しい。
第２の、より最近の種類のシステムにおいては、例えば
オブジェクトベースのシステムであって、定義したシス
テム環境を提供しょと試みてきた。
この方法では、ユーザおよびデータタイプ間での通信で
きる能力を向上させる統合されたシステムとユーザ環境
を提供する。しかしながら、前記種型のシステムに対し
て繰返し起る問題はシステムの定義自体および定義され
たオブジェクトベースのシステムを管理する上で必要と
されるオペレーティングシステムのタイププログラムと
が、もしそれらが初期に検討され、かつ定義されたアプ
リケーションとデータタイプとに１　ｉＴｈしないＰ４
合新しいアプリケーションやデータタイプを追加する能
力を阻害することである。
課０皿乏邂１Ｊン１月ｉ 本発明によるシステムは、プログラムに対する分裂性が
最小で、かつ労力を低減させて、プログラムをカストマ
イズし、更新し、かつ修正し、例えば他の言語に変換で
きるようにする。プロゲラ１１を保存し、かつ実行する
構造とメカニズムとを含む。この点に関して、いずれか
のタイプのプログラムは実行可能のコードと、実行可能
のコードにより用いられるが、それ自体は実行されない
データより構成されているものと見做しうる。そのよう
なデータの例としては、アイコン、言語依存文脈、メツ
セージ、テキストフォント、日付および時間並びにプレ
ゼンテーションフォーマット（表示形式）を含む。現在
のシステムにおいては、プログラムの実行可能コードや
プログラムデータはプログラムオブジェクトあるいはフ
ァイルに常駐のプログラムの実行可能コードおよび資源
に常駐するプログラムのデータにより分離される。資源
とは、プログラムの実行可能コードにより使用されるが
、プログラムの実行可能コードの一部として保存されな
いデータのブロックである。したがって、資源オブジェ
クトはそのようなプログラムデータを、それが付属する
プログラムとは別に独立して記憶する手段である。資源
の概念がオブジェクトベースのシステムに限定されてい
ないが、現在のシステム忙おいては、全ての形態のデー
タや対応するオブジェクトマネージャが資源オブジェク
トに対してオペレートするよう提供されるように全ての
資源はオブジェクトに記憶され、そのため資源は簡単に
作成され、かつ資源のデータは簡単に定義できる。
本発明は、適当なカストマイズした資源が存在すると資
源のカストマイズしたバージョンを自動的に標準資源に
代替（置換）された機構を含む。全てのタイプのプログ
ラムはプログラムの挙動の多種局面を制御するために資
源の中味に依存するよう構成されている。カストマイズ
した資源が標準的な資源に自動的に代替されると、資源
を用いているプログラムはカストマイズされて挙動する
。
このように単一の資源検索機能を用いてカストマイゼー
ションが可能とされる。
本発明のその他の特徴、目的および利点は本発明の実施
例に関する以下の説明を読み、かつ添付図面を検討した
後は当該技術分野の専門家には理解されよう。
及１匠 以下の説明は、本発明の現在の好適な実施例を組み入れ
たコンピュータシステムの構成とオペレーションとに関
するものである。
詳細な説明の概要 １　概念 １．１．オブジェクトおよびオブジェクトマネージャ １、］、１オブジェクトタイプ：フォルダ１．２．リン
ク １．３．プロファイル １．４．資源 １．５．オペレーティングシステムとルーチンバック ２　アーキテクチュア上の概観 ３　オブジェクトとファイル ４　データ統合 ４１、宛て先オブジェクトのユーザへの見掛け４．２．
あるデータの統合概念を示す例５　リンク ５．１．リンクの更新 ５．１．１．いつ更新が起るか？ ｓ、ｉ、ｚ、リンク更新オペレーションは再帰を要す ５．２．はめ込みリンクを有するデータをコピイ５．３
．リンクマーカ ５．４．リンク仕様 ５．５．オブジェクトおよびリンクの凍結（フリーリン
ク） ６　物理編成（第１Ａ図、第１Ｂ図および第１Ｃ図）７
　表示システムのあるエレメントについて８　システム
データ構造 ８．１．システムデータベース ８．１．１．オブジェクトタイプテーブル８．１．２．
オブジェクトマネージャテーブル８．１．３．オブジェ
クトプロトタイプテーブル８．１．４．カストマイゼー
ションテーブル８．１．５．ライブラリテーブル ８．１．６．ボリュームテーブル ８．１．７．システム構成テーブル ８．２．オブジェクトカタログ ８、Ｚ、１．オブジェクトテーブル ８．２．２．リンクテーブル ８．２．３．ファイルリストテーブル ８．２．４．フオルダテーブル ８．２．５．フィールド旧Ｔファイル ８．２．６．オブジェクト−ＩＴファイル８．２．７　
　削除オブジェクトテーブル８．３．リンクパラレルフ
ァイル ９　オブジェクトマネージャ呼び出し ９．１．カーネルを直接用いることによる呼び出し ９．２．スタートアップリクエスト ９．３．＾ＰＰＡＣにによる呼び出し １０　　オブジェクトマネージャテーブル（第３図）１
１　　オブジェクトプロトタイプテーブル（第４図）１
２　　オブジェクトカタログ（第５図、第６図および第
７図） １２．１．カタログサーバプロセス １３　　リンクおよびリンクパラレルファイル（第８図
） １４　　コピイ、移動および共用 １５　　マツチメーカ（組み合わせ決定プログラム）１
５．１　、マツチメーカの目的と全体作動１５．２．マ
ツチメーカプロトコル １５．２゜１．原始プロトコル １５．２．２．場所プロトコル １５．２．３．オブジェクト間のＨＯＶＥオペレーショ
ンの後のＵＮＤＯの処理 １６　　データ交換（第９図） １７　　資源 １７．１．資源ファイル １７．２．資源（第１０Ａ図） １７．３．資源エディタ １８　　資源力ストマイゼーシコン １８．１．カストマイズした資源による一般的なカスト
マイゼーション １８．２．カストマイゼーシヲンＩＤ５１９　　へＰＰ
ＡＣＫ機能呼び出し １９．１．呼び出しサービス １９．１．１．　ＡＰｒｑｓｔａｒｔ（）−スタートリ
クエストを発する １９．１．２．　Ａ　Ｐ　ｒｑｅｄｉｔ（）−エデイツ
トリクエストを発する １９．１．３．　Ａ　Ｐ　ｒｑｒｅａｄ（）−−・読取
りリクエストを発する １９．１．４．　ＡＰｒｑｒｕｎ（）−実行リクエスト
を発する １９．１．５．　Ａ　Ｐ　ｒｑｃｒｅａＬｅ（）−作成
リクエストを発する １９．１．６、Ａ　Ｐ　ｒｑｃｌ＋ａｎｇｅｆｉｎｋ□
−リンク変更リクエストを発する １９．１．７、Ａ　Ｐ　ｒｑｐｒｉｎｔ□−プリントリ
クエストを発する ｔ９．１．８．　ＡＰｒｑｕｐｄａｔｅ（）−リンク更
新リクエストを発する １９．１．９．　Ａ　Ｐ　ｒｑｃｏｐｙ（）−オブジェ
クトをコピイする １９．１．１０．　Ａ　Ｐ　ｒｑｄｅｌｅｔｅｌｉｎｋ
Ｏ−リンクを削除する １９．１．１１．　ＡＰｒｑｒｅｌｏｃｑｔｅ（＞−オ
ブジェクトを再配置する １９．１．１２．　ＡＰｒｑｉｕ＋ｐｏｒｔ（）−外部
のオブジェクｌへをインボートする １９．１．１３．　Ａ　Ｐ　１ｎｖｏｋｅ（）・＝アプ
リケーションを呼び出す １９−．２．オペレーションサポート １９．２．１．　Ａ　Ｐ　１ｎｉｔ（）−アプリケーシ
ョンリクエスト処理の初期設定をする １９．２．２．　Ａ　Ｐ　ｒｅｐｌｙ（）−リクエスト
に対して応答する １９．２．３．　ＡＰｅｖｉｎｉｔＯ−＾ＰＰＡＣＫイ
ベント（事象）の仕様を初期設定する １９．２．４．　ＡＰｅｖａｃｔｉｏｎ（）−＾ＰＰＡ
ＣＫイベントに対するアクションコードをセットする １９．２．５．　Ａ　Ｐｅｖｒｅｍｏｖｅ（）−＾Ｐ！
’ＡＣＫイベント仕様を除去する １９．２．６．　Ａ　Ｐ　ｍｓｇｔｅｓｔ□−＾ＰＰＡ
ＣＫメツセージイベントをテストする １９．２．７．　Ａ　Ｐ　ｒｉｏｉｎｉｔＯ−アクティ
ブオペレーションに対するＲＩＯＩＤを取得する１９．
２．８．　ＡＰｍｓｇｗａｉｔ（）−へＰＰＭＣＫメツ
セージを待機する １９．２．９．　ＡＰｏｐｒｅｑｕｅｓｔ（）−オベレ
、ジョンリクエストを送る １９．２．１０．　Ａ　Ｐｍｓｇｒｅｑｕｅｓｔ□−リ
クエストメツセージを解釈する １９．２．１１．　ＡＰｏｐｔｉｎｉＳｈＯ−オペレー
ションを停止する １９．３．マツチメーカオペレーション１９．３．１　
、　Ａ　Ｐ　輪＋５ｒｅｓｅｒｖｅ□−オペレーション
に対するマツチメーカを予約する ！９．３．２．　Ａ　Ｐ　ｎ輪ｐｏｓｔ□−マツチメー
カに対するオペレーションを通知する １９．３．３．　Ａ　Ｐ　ｎ＋ｍｃｏｎｎｅｅｔ（）−
一致したアプリケーションに接続する １９．４．リンク交換 １９．４．１　、　ＬＮＸｐｉｎｉｔ（）−リンクスト
リームの構成を開始する １９．４．２．　ＬＮＸｐｒｅｓｔａｒｔ（）−ストリ
ームをリンクにリセットする １９．４．３．　ＬＮＸｐｅｉｎｋＯ−リンクをストリ
ームに入れる １９．４．４．　ＬＮＸｐｎｅｗｌｉｎｋ（）−新しい
リンクをストリームに入れる １９．４．５．　ＬＮＸｐｔｉｎｉｓｈ（）−リンクス
トリームの構成を終了する １９．４．６．　ＬＮＸｇｉｎｉｔ（）−リンクストリ
ームの読取りを開始する １９．４．７．　ＬＮＸｇｒｅｓｔａｒｔ（）−ストリ
ームをリンクにリセットする １９．４．８．　ＬＮＸｇｌｉｎｋ□−次のリンクをス
トリームで取得（ＧＥＴ）する １９．４．９．　ＬＮＸｇｐｅｅｋ（）−ストリームで
次のリンクをルックアップする １９．４．１０．　ＬＮＸｇｓｋｉｐ（）−ストリーム
での次のリンクをスキップする １９．４．１１．　ＬＮＸｇｆｉｎｉｓ［）−リンクス
トリームの読取りを終了する １９．５．テキストの交換 １９．５．１．　ＴＸＸｐｉｎｉｔ（）−テキストスト
リームの構成を開始する １９．５．２．　ＴＸＸｐｒｅｓｔａｒｔ（）−テキス
トにストリームをリセットする １９．５．３．　ＴＸＸｐｓｔｒｉｎｇ□−テキストス
トリングをストリームに入れる １９．５．４．　ＴＸＸｐｅｈａｒ（）−単一キャラク
タをストリームに入れる １９．５．５．　ＴＸＸｐｔｏｎｔ（）−現在ノフォン
トを変更する １９．５．６．　ＴＸＸｐａｔｔｒｓ（）−テキストの
属性をセットする １９．５．７．　ＴＸＸｐｄｉａｅｒｉｔｉｃ（）−区
別的発音符を挿入する １９．５．８．　ＴＸＸｐ、５ｔｒｉｋｅｔｈｒｕ（）
−ストライクスルー（Ｓｔｒｉｋｅ−Ｔｂｒｕ）キャラ
クタをセットする１９．５．９．　ＴＸＸｐｓｃｒｉｐ
ｔ（）−スクリプトオフセットをセットする １９．５．１０．　ＴＸＸｐｒｅｒｔｉｅａｌ□−垂直
降下移動指令を出す １９．５．１１．　ＴＸＸｐｈｏｒｉｚｏｎｔａｌ□−
水平移動指令を出す １９．５．１２．　ＴＸＸｐｓｐａｃｉｎｇ（）−行間
間隔指令を出す １９．５．１３．　ＴＸＸｐｌａｎｇｕａｌＨｅ□−言
語変更指令を出す １９．５．１４．　ＴＸＸｐｌｉｎｋＯ！Ｊ　’／　り
をストリームに入れる １９．５．１５．　ＴＸＸｐｆｉｎｉｓｈ（）−テキス
トストリームの構成を終了する １９．５．１６．　ＴＸＸｇｉｎｉｔ（）−テキストス
トリームの読取りを開始する １９．５．１７．　ＴＸＸｇｒｅｓｔａｒｔＯ−ストリ
ームをバニラ（Ｖａｎｉｌｌａ）テキストにリセットす
る１９．５．１８．　ＴＸＸｇｎｅｘｔ（）−データの
次のタイプを入力ストリームで取得する １９．５．１９．　ＴＸＸｇｓｔｒｉｎｇｓｉｚｅ（）
−次のストリングの長さを取得する １９．５．２０．　ＴＸＸｇｓｔｒｉｎｇ（）−ストリ
ームから次のテキストストリングを取得する １９．５．２１．　ＴＸＸｇｃｈａｒＯ−ストリームか
ら次のキャラクタを取得する １９．５．２２．　ＴＸＸｇｆｏｎｔ（）−現在のフォ
ントを取得する １９．５．２３．　ＴＸＸｇａｔｔｒｓＯ−テキストの
属性を取得する １９．５．２４．　ＴＸＸｇｄｉａｃｒｉｔｉｔｉｃｍ
−区別的発音符を取得する １９．５．２５．　ＴＸＸｇｓｔｒｉｋｅｔｌ＋ｒｕ（
）−ストライクスルーキャラクタを取得する １９．５．２６．　ＴＸＸｇｓｅｒｉｐＬ（）−スクリ
プトオフセットを取得する １９．５．２７．　ＴＸＸｇｖｅｒｔｉｃａｆ□−垂直
降下移動を取得する １９．５．２８．　ＴＸＸｇｈｏｒｉｚｏｎｔａ／（）
−水平移動を取得する １９．５．２９．　ＴＸＸｇｓｐａｅｉｎｇ□−行間間
隔を取得する １９．５．３０．　ＴＸＸｇｌａｎｇｕａｇｅ＜＞−ス
トリームから言語変更指令を取得する １９．５．３１、ＴＸＸｇｆｉｎｉｓｈ□−テキストス
トリームの読取りを終了する １９．６．レコードの交換 １９．８．１．　ＲＥＸｐｉｎｉｔ（）−バニラレコー
ドストリームの構成を開始する １９．６．２．　ＲＥＸｐｒｅｓｔａｒｔ（）−バニラ
レコードへストリームをリセットする １９．６．３．　ＲＥＸｐｈｅａｄｅｒ（）−ヘッダレ
コードを構成する １９．６．４．　ＲＥＸｐｒｉｎｉＬＯ−レコード記述
子を開始する １９．６．５．　ＲＥＸｐｆｄｅｓｃ（）−フィールド
記述子を構成する １９．６．６．　ＲＥＸｐｒ４ｉｎｉ（）−レコード記
述子を終了する １９．８．７．　ＲＥＸｐｄｉｎｉｔ（）−データレコ
ードを開始する １９．６．８．　ＲＥＸｐｄａｔａ（）−データフィー
ルドを構成する ！９．６．９．　ＲＥＸｐｄｆｉｎｉ（）−データレコ
ードを終了する １９．６．１０．　ＲＥＸｐｆｉｎｉｓｈＯ−バニラレ
コードストリームの構成を終了する １９．６．１１．　ＲＥＸｇｉｎｉｔ（）−バニラレコ
ードストリームの読取りを開始する １９．６．１２．　ＲＥＸｇｒｅｓｔａｒｔ（）−スト
リームをバニラレコードにリセットする １９．６．１３．　ＲＥＸｇｔｙｐｅ□−次のレコード
タイプを取得する ｒ９．６．１４．　ＲＥＸｇｂｅａｄｅｒ（）−ヘッダ
レコード情報を取得する １９．６．１５．　ＲＥＸｇｆｄｅｓｃｏ−次のフィー
ルド記述子を取得する １９．６．１６．　ＲＥＸｇｄａｔａｏ−次のデータフ
ィールドを取得する １９．６．１７．　ＲＥＸｇｎｅｘｔ□−次のレコード
タイプまでスキップする １９．６．１８．　ＲＥＸｇｆｉｎｉｓｈ（）−バニラ
レコードストリームの読取りを終了する ２０　　ＲＥＳＰＡＣに　機能呼び出し２０．１．資源
ファイルアクセス機能 ２０．１．１．　ＲＥＳｆｏｐｅｎｏ−資源ファイルを
開ける２０．１．２．　ＲＥＳｆｉｎｉｔ（）−資源フ
ァイルのリストを開ける ２０．１．３．　ＲＥＳｆｃ１ｏｓｅ□−資源ファイル
を閉じ２０．２．資源アクセス機能 ２Ｇ、２．１．　ＲＥＳｇｅｔｏ−資源を取得する２０
．２．２．　ＲＥＳｍｇｅＬ（）−多数資源を取得する
２０．２．３．　ＲＥＳｐｏｉｎｔ（）−資源に対する
ポインタを取得する ２０．２．４．　ＲＥＳｒｅｌｅａｓｅ（）−資源を解
放する２０．２．５．　ＲＥＳｒｅａｄ（）−資源を読
取る２０．２．６．　ＲＥＳｌｏｏｋｕｐ（）−資源を
所定の名称で見つける ２０．２．７．　ＲＥＳｇｔｉｎｆｏｏ−資源に関する
情報を取得する ２０．３．資源ファイルの管理 ２０．３．１．　ＲＥＳｆｃｒｅａｔｅ（）−資源ファ
イルを作成する ２０．３．Ｚ、　ＲＥＳｆｅｄｉｔ（）−資源ファイル
を修正する ２０．３．３．　ＲＥＳｆｕｒｅｗ（）−資源ファイル
を精査する ２０．３．４．　ＲＥＳｆｃｏ＋ｕｉｉｔ（）−ファイ
ルの修正を行２０．３．５．　ＲＥＳｇｔｆｉｎｆｏ（
）−ファイルに関する情報を取得する ２０．３．６．　ＲＥＳｐｔ４ｉｎｆｏ（）−ファイル
に関する情報を入れる ２０．３．７．　ＲＥＳａｖａｉｌ（）−未使用の資源
ＩＤを取得する ２０．３．８．　ＲＥＳｇｔｎｅｘｔ（）−次の資源情
報を取得する ２０．３．９．　ＲＥＳＨｔｐｒｅｖ（）−以前の資源
情報を取得する ２０．３．１０．　ＲＥＳｅｈｅｅｋｐｔ（）−資源フ
ァイル更新のチエツクポイント ２０．３．１１．　ＲＥＳｒｅｖｅｒｔ（）−最後のチ
ｘ　ツクポイントへ復帰する ２０．３．１２．　ＲＥＳｆｒｅｅｚｅ（）−資源ファ
イルバージョンを凍結する ２０．３．１３．　ＲＥＳｇｔｆｖｅｒｏ−資源ファイ
ルバージョン番号を取得する ２０．３．１４．　ＲＥＳｐｔｆｖｅｒ（）−資源ファ
イルバージラン番号を入れる ２０．４．資源編集機能 ２０．４．１．　ＲＥＳｒｄｅｕｒｏ−資源の現在のバ
ージョンを読取る ２０．４．２、ＲＥＳｇｔｃｕｒ□−現在の資源情報を
取得する ２０．４．３．　ＲＥＳｃｒｅａｔｅ（）−資源を作成
する２０．４．４．　ＲＥＳｗｒｉｔｅ（）−資源を書
込む２０．４．５．　ＲＥＳｒｅｗｒｉｔｅ（）−資源
を重ね書きする２０．４．６．　ＲＥＳｐｔｉｎｆｏ（
）−資源についての情報を入れる ２０．４．７．　ＲＥＳｍｏｖｅ（）−資源を新しい位
置へ移す ２０．４．８．　ＲＥＳｐｔｎｕｍ（）−資源の番号を
付は直す２０．４．９．　ＲＥＳ輪ｅｒｇｅ□−資源リ
ストをファイルに併重する ２０．４．１０．　ＲＥＳｄｅｌｅｔｅｏ−資源を削除
する２０．５．資源インデックス機能 ２０．５．１、ＲＥＳｉｘｉｎｉｔ□−資源インデック
スの構成を開始する ２０．５．２．　ＲＥＳｉｘｐｒｅｐ（）−既存インデ
ックスの修正を始める ２０．５．３．ＲＥＳｉｘａｄｄ□−資源インデックス
エントリを追加する ２０．５．４．　ＲＥＳｉｘｄｅ！ｅｔｅ（）−資源イ
ンデックスエントリを削除する ２０．５．５．　ＲＥＳｉｘｒｉｎｉ（）−資源インデ
ックスの構成を終了する ２０．５．６．　ＲＥＳｉｘｌｏｏｋｕｐ（）−資源イ
ンデックスエントリをルックアップする ２０．５．７．　ＲＥＳｉｘｕｌｏｏｋｕｐ（）−ＵＳ
ＩＩＯＲＴエントリをルックアップする ２Ｇ、５．８．　ＲＥＳｉｘｌｌｏｏｋｕｐ（）−ＵＬ
ＯＮＧエントリをルックアップする ２０．５．９．　ＲＥＳｉｘｓｌｏｏｋｕｐ（）−スト
リングエントリをルックアップする ２０．５．１０．　ＲＥＳｉｘｕｆｉｎｄ（）−ＵＳＩ
ＩＯＲＴエントリを見つける ２０．５．１１．　ＲＥＳｉｘＺｆｉｎｄ（）−１ｌＬ
ＯＮＧエントリを見つける ２Ｇ、５．１２．　ＲＥＳｉｘｓｆｉｎｄ（）−ストリ
ングエントリを見つける Ｚｏ、５．１３．　ＲＥＳｉｘｇｅｔ（）−資源インデ
ックスでエントリを取得する ２０．５．１４．　ＲＥＳｉｘｉｎｄｅｘ（）−資源イ
ンデックスでエントリを取得する ２０．５．１５．　ＲＥＳｉｘｉｎｆｏｏ−資源インデ
ックスに関する情報を取得する ２０．６．バッチスタイルでの資源の作成２０．６．１
．　ＲＥＳｃｃｒｅａｔｅＯ−バッチスタイルの資源フ
ァイルを作成する ２０．６．２．　ＲＥＳｃａｄｄｏ−資源ファイルへ資
源を追加する ２０．６．３．　ＲＥＳｃｃｌｏｓｅｏ−資源ファイル
構成を終了する ２０．７．ユーザプロファイルサポート機能２０．７．
１．　ＲＥＳｐｔｃｕｓｆｎｄＯ−−・セストマイゼー
ションＩＤをセットする ２０、乞２．　ＲＥＳｓｕｐｅｄｉｆＯ−プロファイル
で資源をｍ集する。
■、概念 １．１．　　ブジェクトと　ブジエクトマネージャ本発
明のシステムは［オブジェクトベースの」様に記述され
る一最的な種類のシステムの１つである。即ち、情報は
「オブジェクト」と称される構造に記憶される。現在好
適な実施例の実現において、はとんどのオブジェクトは
それぞれ従来のコンピュータファイルシステムの１個以
上のファイルに対応する。
さらにオブジェクトに関して、本発明によるシステムは
フォルダとして前述したタイプを含む基本的には無限の
オブジェクト「タイプ」の使用を可能とし、本システム
により実行すべきデータ、情報あるいは演算の各形態に
対しであるタイプのオ、ブジェクトがある。即ち、本発
明によるシステムはオブジェクトとシステムとの間で最
小のインタフェースのみ定義し、いずれかのオブジェク
トの内部ｆｌＩ造あるいは形態は定義しない、そのため
、本発明によるシステム内のオブジェクトはデータ、プ
ログラムあるいはその他の情報用の汎用コンテナとして
見做してよく、内部構造即ち特定のオブジェクトの形態
は実行すべきオペレーションの要件あるいは記憶すべき
データあるいは情報のタイプにより定義される。
オブジェクトに作用（オペレート）するプログラムは［
オブジェクトマネージャ」として知られ、あるいは場合
によって「エディタ」、「アブリゲーションプログラム
」あるいは「アプリケーション」と称される。「アプリ
ケーションＪという用語はまた、単一のオブジェクトタ
イプをオペレートするオブジェクトマネージャのコレク
ション（集まり）を参照するために使用される。各タイ
プのオブジェクトは、そのタイプのオブジェクトに記憶
されているデータあるいは情報をオペレートする一次手
段として構成あるいは意図した少な（とも１個のオブジ
ェクトマネージャを関連させている０例えば、システム
は、ワードプロセッシングに対して「ドキュメントタイ
プ」のオブジェクトをサポートでき、そのオブジェクト
タイプに関連したワードプロセッシングオブジェクトマ
ネージャがある。同様に、［データベースタイプ」のオ
ブジェクトは、データベースタイプのオブジェクトに記
憶したデータに（又はデータで）オペレートする一次手
段であるデータベースオブジェクトマネージャを関連さ
せている。
しかしながら、特定タイプのオブジェクトに対してオペ
レートするオブジェクトマネージャはそのオブジェクト
タイプ用の一次オブジェクトマネージャに限定されない
ことに注目すべきである。
さらに特定のオブジェクトに対してオペレートするよう
呼び出された特定のオブジェクトマネージャは実行すべ
きオペレーションのタイプによって変わる９本発明によ
るシステムはいずれか所定のオブジェクトタイプに対し
てオペレートする１数のオブジェクトマネージャを提供
し、あるオブジェクトマネージャ、例えばあるユーティ
リティは１個以上のタイプのオブジェクトに対してオペ
レートしうる一次オブジェクトマネージャは、もしユー
ザが異なったプログラムを選定していないとすれば、特
定のオブジェクトタイプに対してオペレーションすべく
省略値により呼び出される単なるオブジェクトマネージ
ャである。
典型的には、オブジェクトマネージャは単一タイプのオ
ブジェクトのデータに対してオペレートするが、ある場
合にはプログラムが１つのオブジェクトタイプ以上のオ
ブジェクトマネージャとなるよう配置することが望まし
い。さらに、オブジェクトデータ（例えばファイルコピ
イ）を解釈しないオペレーションを実行せず、したがっ
て各種タイプのオブジェクトに対して用いうる各種のユ
ーティリティプログラムがある。
１．１．１．　　ブジェクトタイプ：フォルダフォルダ
は編成ツールとして用いられる。フォルダタイプのオブ
ジェクトはそれが含んでいるリンクに対して主として用
いられる。例えば、グループのオブジェクトは、全てを
単一のフォルダオブジェクトに連結することにより論理
的に相互に関連づけることができる。いずれのオブジェ
クトと同様に、フォルダ自体をフォルダに連結すること
ができる。各フォルシダには、フォｌレダの目的につい
てのユーザのコメント、フォルダのオブジェクトに対し
て何をすべきかの指令等の情報を含みうるファイルが関
連している。そのようなデータが無い場合も多いので、
典型的なフォルダの有意性は単にそれに連結したオブジ
ェクトのリストのみであり、この場き、基本的にはフォ
ルダにあるのはオブジェクトカタログでのエントリ１．
主としてリンクテーブルのエントリのみである。
フォルダは、リンクがいずれのデータにもはめ込まれて
いないのでリンクマーカを何ら必要としない。フォルダ
のリンク間の順序はリンクマーカがはめ込まれている順
序によって決められるのでなく、リンクテーブルに記憶
されているリンク■Ｄの値により決定される。
フォルダは、それがリンクを有しているオブジェクトか
らはデータを何ら連結しない（即ち、フォ　。
ルダはリンク・パラレル・ファイルを何ら必要としない
）、フォルダは全てのオブジェクトの間の関係を示すリ
ンクを正に用いるということである。
本システムの各ユーザは一次フォルダを有する。
ユーザがシステムの資源へのアクセスを得るのはこの一
次手段によるものである。典型的に各ユーザの一次フォ
ルダに連結され、各ユーザにある種の共通のシステム資
源へのアクセスを提供する一次システムフォルダがある
。さらに、ユーザの一次フォルダの全てはシステムフォ
ルダに連結されている。
１．２．リンク システムの情報は主としてオブジェクトの内部に含まれ
ているが、オブジェクトの方は「リンク」と称される機
構を介して相互に関連している。リンクは概念的には、
「子供Ｊオブジェクトと称せられる一方のオブジェクト
が、「親」オブジェクトと称される別のオブジェクトに
「接続」されるようにする手段と見做すことができる。
各オブジェクトはある意味では、各オブジェクトが常に
少なくとも１個のリンクを連結し、そのリンクを介して
少なくとも１個の親のオブジェクトに連結するという点
で子供のオブジェクトである。この点については、以下
に説明するように、各ユーザは少なくとも１個の親オブ
ジェクトを有し、該オブジェクトに対して、前記ユーザ
に関連したその使命てのオブジェクトが直接的あるいは
間接的にリンクされている。「親」とか「子供」という
用語はリンクの方向を指すのであって、リンクされたオ
ブジェクト間での階層を意味するものではない。
以下の説明で述べるように、リンクはまた子供オブジェ
クトの一部を親オブジェクトに、かつ子供オブジェクト
全体をリンクするために使用し得る。さらに、いずれの
数のオブジェクトや、オブジェクトの部分をリンクを介
して相互に連結することができ、かつリンクの方向は階
層的に限定されはしない。
１．３．プロファイル プロファイルは、例えばシステム、オブジェクトあるい
はリンクのような何かについてユーザが見ることのでき
る情報である。オブジェクトプロファイルに含まれる情
報はオブジェクトタイプによって左右される。ドキュメ
ントタイプのオブジェクトに対して、オブジェクトプロ
ファイルは、例えばフォントリスト、グローバルフォー
マット情報およびプリンティングパラメータのようなオ
ブジェクト自体に記憶された情報と共にオブジェクトテ
ーブルに記憶された何らかの情報を含む。
Ｌ４−責、、源− 「資源１とは、プログラムが使用するが、プログラムで
実行可能のコードの一部としては記憶されないデータで
ある。そのようなデータの例はアイコン、言語依存のテ
キスト、メツセージ、テキストフォント、フオーム、日
付および時間並びにプレゼンテーションフォーマットを
含む。したがって、資源はそのようなプログラムデータ
を、それが関連したプログラムから分離し、かつ独立し
て記憶する手段である。
プログラムデータを資源に入れることにより、その中の
情報をプログラムが実行可能のコードに影習を与えるこ
となくカストマイズ即ち変更することができるようにす
る０例えば、ワードプロセッシングデータベースおよび
スプレッドシートプログラムの英語、仏語および独語バ
ージョンは単に、対応する資源の英語、仏語および独語
バージョンを提供することにより生成することができる
。プログラムの各バージョンにおいては、関連した資源
に常駐するプログラムデータのみを変えればよく、プロ
グラムの実行可能のコードは不変のままである。さらに
、資源を使用することによりオブジェクトマネージャと
その他のプログラムが共通のプログラムデータを共用で
きるようにし、そのため個々のオブジェクトマネージャ
とその他のプログラムのサイズと記憶要件を減少させる
。
また資源にデータを記憶することにより個々のユーザに
対してプログラムの外観とオペレーションを容易にカス
トマイゼーションできるようにする。資源のユーザ特定
のカストマイズしたバージョンをユーザのユーザプロフ
ァイルに記憶することができる。ユーザプロファイルに
介在するいずれかのカストマイズした資源を自動的にそ
れらの標準的なカウンタバート（相当物）と必要に応じ
て自動的に（かつ資源を用いてプログラムに見えないよ
うにして）代替させる機構が提供される。
ｌ、５．ペレーーイングシスームとルー　ンバツコンピ
ュータシステムは典型的には、オペレーティングシステ
ムと称されるプログラムのグループを含む、オペレーテ
ィングシステムは、システムの全体オペレーションを制
御し、かつ促進し、該システムのユーザに対して選定し
た基本的で一般的なサービスオペレーションを提供する
プログラムのコレクションと見做すことができる。オペ
レーティングシステムのそのようなサービスやオペレー
ションの例としてはプロセス管理、イベント管理、記憶
管理、入出力操作、物理的アドレス変換論理、図形／テ
キストおよびデイスプレィ（表示）操作、ファイルアク
セスおよび管理オペレーションおよび数学的演算を含む
。
オペレーティングシステムの従来からの見解では特定の
アプリケーションプログラムに対して特定的あるいは一
意的でない全ての機能やオペレーションはオペレーティ
ングシステムにより実行されるべきである。さらに、伝
統的な見方ではオペレーティングシステムを緊密に集積
化し、かつプログラムの相互依存グループと見做してお
り、オペレーティングシステムは一般的に、アプリケー
ションプログラマが現在および将来にわたって希望する
全ての機能を設計者が想定するプログラムの一体構造と
して設計されている。オペレーティングシステムが相対
的にモノリシック的で、かつＰ５１雑であり、その結果
オペレーティングシステムを構成するプログラムと相互
関係があるため、オペレーティングシステムを修正した
り、変更したり、更新したり別の特徴を追加することは
相対的に困難である。
本発明によるオペレーティングシステムは、まずオペレ
ーティングシステムにより実行される実際の機能とサー
ビスとが最小に低減されるという点で従来のオペレーテ
ィングシステムと相違する。
後述のように、本発明によるオペレーティングシステム
は基本的にはプロセス、イベントおよび記憶管理機能と
、物理的アドレス変換論理のみを実行する。
第２に、通常オペレーティングシステムにより実行され
るその他の機能やサービスはアプリケーションプログラ
ム自体で通常実行される多くの機能やオペレーションと
共にルーチンのライブラリによって実行される。Ｅパッ
ク」と本明細書で称するルーチンのライブラリはオペレ
ーティングシステムとアプリケーションプログラムの双
方から独立して存在している。以下の説明で述べるよう
に、バック内に含まれたルーチンは全体的な広範の適用
性を有し、かつオペレーティングシステムとアプリケー
ションプログラムのサポート機能の双方に対して有用な
るよう構成した、短くて、−ａ的で、単一目的のルーチ
ンから構成されている。
バックルーチンにより実行されるサービスと機能とは限
定的ではないが、入出力操作、図形／テキストおよびデ
イスプレィ操作、ファイルアクセスおよび管理オペレー
ションおよび数学的演算を含む。
また後述のように、各パックは、それらが実行するタイ
プあるいはそれらがオペレートするオブジェクトのタイ
プとにより関係づけられる一組のルーチン即ち機能を含
んでいる。さらに、所定のパックの全てのルーチンには
均一なインタフェースあるいは呼び出しおよび復帰シー
ケンスを備えており、かつパックは特にバックヘッダフ
ァイルと制御ブロック即ちパックが制御するオブジェク
トに関する情報のブロックに関して一定のフォーマット
に合致する必要がある。
オペレーティングシステムの多様なサービスや機能およ
びアプリケーションプログラム内で通常提供される多く
のオペレーションに対してルーチンのパックを用いるこ
とによりシステムのアーキテクチャと構成のフレキシビ
リティを大きく向上させる。機能およびサービスは容易
かつ迅速に、さらにシステムのその他の機能を阻害する
か、さもなければ圧迫することなく追加あるいは変更が
できる。さらに、パックを使用することにより、通常側
々の各アプリケーションプログラムに組み入れられる多
くのオペレーションや機能が多くのアプリケーションプ
ログラムにより共用されうるという点でアプリケーショ
ンプログラムのサイズや複雑さを低減させる。また標準
化したインタフェースを備えたルーチンバックを使用す
ることにより、多くのオペレーション、およびシステム
、ユーザおよび他のアプリケーションプログラムに対す
るインタフェースが定義され、標準化されたルーチンバ
ックインタフェースにより定義され、かつ該インタフェ
ースに合致するようにされる点で種々のアプリケーショ
ンの統合を促進させる。
好適な実施例においては、これらのルーチンは共用され
たサブルーチンライブラリに記憶され、実行時間に必要
に応じ動的（ダイナミック）にリンクされる。ある場合
には、バックライブラリからのルーチンのコピイをプロ
グラムの実行可能コードに含めることが望ましいが、こ
の方法はアプリケーションプログラムの物理的サイズを
増大させる。
以下の説明においである種の機能を実行するルーチンを
鵞照する場合、該ルーチンはその機能を直接独自で、あ
るいはシステム呼び出しを行うか、あるいは別のプロセ
スと一連のプロセス間通信を行うことにより達成するこ
とを理解すべきである。
例えば、＾ＰＰＡＣＫルーチン＾ＰｉｎｖｏｋｅＯは、
最終的にシステム呼び出しを行いその結果オブジェクト
マネージャを呼び出すことになるがアプリケーションマ
ネージャプロセスと通信することによりオブジェクトマ
ネージャを呼び出す。
２、アー　テクチャＬの 本発明はタイプしたオブジェクトの処理（マニプユレー
ション）な含む。種々のオブジェクトが、例えば以下に
述べるような情報の種々形態を示ず　　　　　′ように
構成されている。ドキュメントオブジェクトはテキスト
とそれに関連するフォーマット化情報を表示する。スプ
レッドシートオブジェクトは数学的モデル化情報を表示
する。イメージオブジェクトは写真タイプのピクチャを
表示する。
各タイプのオブジェクトに対して、そのタイプのオブジ
ェクトに対してオペレートしうる１個以上の［オブジェ
クトマネージャ」がある。オブジェクトマネージャは大
略アプリケーションプログラムに対応する。例えば、ス
ブレッドシ一トプログラムがある。これはオペレーティ
ングシステムのプログラムと区別されて［アプリケーシ
ョン」と理解されうる。また、「スプレッドシート」タ
イプのオブジェクトの「マネージャ」あるいは「エディ
タ」とも理解しうる。
オブジェクトの構造と解釈とを定義するのはオブジェク
トのオブジェクトマネージャであるので、オブジェクト
タイプのコレクションは拡張可能である。既存タイプの
情報は、それぞれ既存のタイプが相互に続きされている
のと同じで、各々が従来タイプの情報と統合しうる。新
しいタイプのオブジェクトを操作しうるプログラム（即
ち、オブジェクトマネージャ）を追加することにより新
しいオブジェクトタイプを本システムに追加することが
できる。新しいタイプのオブジェクトを操作しうる能力
は一回実現されればよい、新しいオブジェクトマネージ
ャを追加すると、新しいタイプのオブジェクトは、以前
に存在のオブジェクトマネージャを修正することなく前
に存在のオブジェクトへリンクしたり、データを交換し
たりでき、あるいは統合されたようになる。
拡張可能の統合を促進するということは、各オブジェク
トタイプに対して、標準的なセットのリクエストを全て
サポートするオブジェクトマオ・−ジャがあるというこ
とである。さらに、これらのリクエストはアプリケーシ
ョンとは独立した単一の標準的プロトコルによりオブジ
ェクトマネージャの間で通信される。この態様に絶対的
に固執する必要はない。しかしながら例外の数が増加す
るにつれて、データ統合に対するこの方法から得られる
利点が減少していく。
標準的なリクエストやプロトコルが十分な程度の統合を
提供しない場合が発生すれば、専用リクエストやプロト
コルを定義して標準的なセットと共存するようにできる
。このように、この拡張可能の方法は、適当に応じ緊密
な連結を阻止することなく最低レベルの統合のみを定義
する。専用プロトコルが適当である場合の一例はスプレ
ッドシートアプリケーションとグラフィング（図示）ア
プリケーションとの間の通信である。
全てのオブジェクトマネージャに対して利用可能の１組
のアプリケーション統合サービスがある。
これらのサービスはいずれか特定のタイプのオブジェク
トの「知識」を何ら具体化しているものではない。むし
ろ前記サービスは各種タイプのオブジェクトの操作を調
整するなめにオブジェクトマネージャが使用するもので
ある。特に、これらのサービスは適当なオブジェクトタ
イプに特定的な「知識」を具体化するオブジェクトマネ
ージャをサポートしやすくする。
アプリケーション統合サービスの名称の由来は、それら
が個々のアプリケーション（即ち、オブジェクトマネー
ジャ）がユーザに対して他のアプリケ−シランのそれと
データのオペレーションおよび操作とを統合しうるよう
に見せかける機構であるためである。ユーザ（二対して
は、テキストとピクチャの双方を有する時事通信の１頁
をデイスプレィすることは、ユーザにはドキュメントと
して知られる単一のエンティティでピクチャとテキスト
とが統合されたことを示す０本発明によれば、この効果
は、アプリケーション統合サービスを用いることにより
調整された、２つの異なるオブジェクトマネージャのオ
ペレーションにより達成される。時事通信は、テキスト
と関連のフォーマット化情報とを記憶するよう構成され
たオブジェクトの１タイプであるタイプドキュメントの
オブジェクトに記憶される。この例の特定のドキュメン
トオブジェクトは、写真タイプのピクチャを記憶するよ
う構成されたオブジェクトである「イメージ」タイプの
個別のオブジェクトに対するリンクを含む。当該ページ
の表示は、テキストを検索し表示しているドキュメント
オブジェクトマネージャと、ピクチャを検索し表示して
いるイメージオブジェクトマネージャとにより達成され
る。ピクチャに対するリンクと必要なオペレーション（
表示）とを記載する情報は、アプリケーション続きサー
ビスの助けをかりてドキュメントオブジェクトマネージ
ャからイメージオブジェクトマネージャまで通信される
。
本発明の実施例によるコンピュータシステムは、複数の
プログラムを同時に有効に実行するＩａ能を含んでいる
。これはマルチタスキングあるいはマルチプロセッシン
グとして知られていて、同時に実行するプログラムの各
々はタスクあるいはプロセスとして知られている。
本発明のシステムにおいては、アプリケーションマネー
ジャがある。アプリケーションマネージャはオブジェク
トマネージャの処理の基となる。
即ち一般的には、オブジェクトマネージャは相互に対し
て同僚であって、アプリケーションマネージャの子供で
ある。
アプリケーション統合サービスは部分的にはアプリケー
ションマネージャによって、また部分的には一組の共通
のサブルーチン即ち機能によって提供される。オブジェ
クトマネージャの原始コードの本体の組み込みうる１組
の機能呼び出しが利用しうる。この組の機能は八ＰＰＭ
ＣＫとして知られている。へＰＰへＣＫＩＩ能呼び出し
は、それによりオブジェクトマネージャがアプリケーシ
ョンマネージャのサービスを利用するメカニズムである
。−船釣に、ＡＩ’ｌｌ＾ＣＫ機能はアプリケーション
マネージャプロセスへプロセス間メツセージを送り、か
つそこからプロセス間、メツセージを受取る。＾ＰＰＡ
ＣＫ機能自体は共用のサブルーチンライブラリから呼び
出し可能であって、あるいはプログラムリンク時にオブ
ジェクトマオ・−ジャの実行可能本体へ直接組み入れる
ことができる。
＾ＰＰＡＣＫにより提供されるサービスは以下のカテゴ
リーに分類できる。即ち、呼び出し、データ交換、突き
合わせ（マツチメーキング）、オブジェクト管理および
リンク管理である。
アプリケーション統合サービスの中で最も強力なサービ
スは「呼び出し」サービスである。これらサービスご取
得するために介する最も一般的なメカニズムは＾Ｐｉｎ
ｖｏｋｅＯとして知られるＡＩ’ｌ’ＡＣＫｆｉ能であ
って、これは以下詳述する。特定の目的（例えばオブジ
ェクトからデータをプリントするＡＰｒｑｐｒｉｎｔ（
）や、リンクにわたってデータを更新する＾Ｐｒｑｕｐ
ｄａｔａ□で呼び出すためにその他の＾ＰＰＡＣＫ機能
も利用できる。
呼び出しサービスはいずれのオブジェクトマネージャも
（例えばリンク仕様により）あるデータを規定し、その
データに関してオペレーションを実行できるようにし、
適当なオブジェクトマネージャを識別し、かつ呼び出し
、その結果呼び出されたオブジェクトマネージャが特定
のタイプのデータを何ら扱うことなく希望するオペレー
ションが実行されるようにする。例えば、ドキュメント
オブジェクトマネージャは、それぞれ同等の容易さで、
かつイメージあるいはオーディオ（音声）データのいず
れかを操作するよう構成することなくピクチャを表示し
たり、音声メツセージを再生できるようにする。
標準的なプロトコルを実行する役割を果す以外に、呼び
出しサービスはまた、２個のオブジェクトマネージャの
間で通信を行い、続いて各オブジェクトマネージャが専
用プロトコルに基いて通信するようにするためにも利用
できる。
データ交換サービスは、データに対して類似の内部表示
を共用しえない２個のオブジェクトマネージャの間でデ
ータを転送するために共通のデータタイプに対して標準
的な表示を提供する。これらのサービスはデータの形態
と転送の手段の双方をマスクすることによって、それら
を使用するプログラムはデータの意味のある中味にのみ
関係すればよい。
マツチメーキング（組合わせ決定）サービスはユーザ主
導のデータ転送を設定するために使用される（これはデ
ータ交換サービスを用いて完了するオペレーションであ
る）。これらのサービスはデータ転送元（ソース）と受
信者との間の交渉を促進する。
オブジェクト管理サービスとリンク管理サービスとを使
用することは、本システムのオブジェクトおよびリンク
機能を利用するオブジェクトマネージャにとって必要で
ある。オブジェクト管理サービスはオブジェクトのアク
セス、ネーミングおよび操作に関する基準を定義する。
リンク管理サービスはオブジェクトマネージャが、それ
についてオブジェクトマネージャが何ら直接の「知識」
を有さないタイプのオブジェクトへのリンクを保てるよ
うにする。
３、オブジェクトとファイル 本発明のシステムにおいては、はとんどのオブジェクト
タイプに対して、各オブジェクトは（出来れば１個以上
のファイルの）個別のファイルに記憶される。しかしな
がらこれは必要な要件でない。
ファイルとしてのオブジェクトを実行することの利点は
、あるオブジェクトのオペレーションはアプリケーショ
ン統合サービス（例えばオブジェクトの作成、オブジェ
クトのコピイ）により直接容易に実行できるということ
である。
本発明のシステムにおいては、インへりタンス（ｉｎｌ
＋ｅｒｉｔａｎｃｅ）の形態は限定されている。ファイ
ルベースのオブジェクトに対して実行しうるある種のオ
ブジェクト管理オペレーションは八ＰＰＭＣＫにより直
接サポートされる。即ち、オブジェクトの作成、オブジ
ェクトのコピイ、オブジェクトの名前の付は直し、オブ
ジェクトの削除およびオブジェクトの凍結である。前記
オペレーション中の１つがファイルベースのオブジェク
トに対して要求されると、オブジェクトマネージャテー
ブルがそのオブジェクトに対するオブジェクトマネージ
ャがオペレーションを実行している旨指示し、その場合
オブジェクトマネージャが呼び出され、オペレーション
リクエストが該オブジェクトマネージャへ通される。＾
ＰＰＡＣＫはファイルベースのオブジェクトに対してこ
れらのオペレーションを実行しうるのみであるので、こ
れらのオペレーションは非ファイルベースのオブジェク
トにより引き継がれえない。
各オブジェクトタイプが別のタイプをその親として識別
しうるさらに一般的なインへりタンスを実行しうる。そ
のような状況においては、子供のタイプに対して特に定
義されていないオペレーションは親のタイプのオブジェ
クトマネージャにより子供タイプのオブジェクトに対し
て実行しうる。これは新しいオブジェクトタイプを作成
しやすくするという利点を有する。他方、インへりタン
スが生成されていないシステムはそれ自体より単純で高
性能のシステムとなる。
生−ｊシ：外腹金− データ統合を改良する本発明によるシステムの利点を理
解する上で広範囲の緊密に開運し合った概念の間の区別
を理解することが有用である。例えば、ユーザは（「原
始（ソース）」オブジェクトの全て、あるいは一部であ
る）既存のデータが新しい場所（以前に存在していたか
あるいはデータを受取るためにのみ作成しうる「行き先
（宛て先）」のオブジェクトにおける場所）へ「コピイ
」「移動」あるいは［共用Ｊオペレーションにより現わ
れるようにでき、これらのオペレーション各々は他の２
つのオペレーションとは相違している。さらに、コピイ
あるいは移動オペレーションは、コピイあるいは移動さ
れたデータがその行き先（行き先オブジェクト相当のオ
ブジェクトマネージャによりユーザからかくされている
行き先）で「内部化（ｉｎｔｅｒｎａｌ　１ｚｅｄ）　
」あるいは［密閉化（ｅｎｃａｐｓｕｌａｔｅｄ）　」
されるように実行することができる。
行き先オブジェクトへのデータの「共用」とは、データ
は行き先オブジェクトにあるように見えることを意味し
、これは共用されたデータに対してリンクにより達成さ
れ、共用されたデータは実際には行き先内には記憶され
ない、さらに、リンクは他のリンクがすでに参照してい
るものと同じデータを参照する。即ち、同じ記憶された
データが「共用」されるのである。共用の効果は共用さ
れたデータＩ＼の各リンクが更新されると（更新のタイ
ミングは他の個所で論じられているリンク更新フラッグ
によって左右される）、その変更を明示することである
。
「コピイする」ことはコピイされたデータの記憶と、原
始データの記憶とが区別され、そのため−方が他方に影
響を与えることなく変更可能であるという点で共用とは
相違する。換言すれば、実際のデータの新しいコピイが
作られる。さらに、コピイされたデータは２柱頭の要領
で処理できる。
即ち、行き先オブジェクトにおいて「内部化」するか、
行き先オブジェクトにより「密閉化」できる。
もしコピイされたデータが行き先オブジェクトで記憶し
うるタイプのものであるとすれば、コピイされたデータ
は行き先オブジェクトにおいて内部化され、これはデー
タが行き先オブジェクトのデータ構造において直接記憶
されることを意味し、内部化されたデータはオブジェク
トに記憶されたいずれかの他のデータとは区別できなく
なる。コピイされたデータが行き先オブジェクトで記憶
できないタイプのものである場合、データを記憶しうる
タイプの新しいオブジェクトが作成され、この新しいオ
ブジェクトへのリンクが行き先オブジェクトに追加され
る。この場合（密閉化）、行き先オブジェクトは間接的
に、コピイされたデータを収容する。
各アプリケーションはデータを密閉化するリクエストに
応答する必要がある。応答の最も単純な方法は、データ
を含むオブジェクト全体のコピイを作り、その新しく作
成されたオブジェクトを９照するリンク仕様を提供する
ものである。この単純な方法は、密閉化すべきデータが
オブジェクト全体の中の極めて小さい部分である場合は
非能率的である。このように、各アプリケーションは出
来るだけ少ないデータをコピイすることによりデータ密
閉化のリクエストに応答するように構成すべきである。
換言すれば、出来ればアプリケーションは全体オブジェ
クトより小さいもの、好ましくは希望するデータのみを
コピイすべきである。
チャート（図表）アプリケーションは完全なチャートを
作りうるのみであるため、チャートを密閉化するには、
たとえチャートの一部のみ所望であってもチャートオブ
ジェクト全体のコピイを必要とする。別の極端な場合、
ドキュメントオブジェクトマネージャは必要とされるも
のの近辺までを抽出しうる。イラストレーションオブジ
ェクトマネージャはさらに別の場合である。それは希望
する領域の外に来るイラストレーションエレメントはコ
ピイしない。それは、たとえ部分的であっても希望する
領域に入るエレメントを、該エレメントを希望領域のサ
イズまで切り取ることなくコピイする。このように、希
望する領域より外側のイラストレーションの部分は密閉
化されたデータ内で表示される。
「移動」は原始データが削除されている以外コピイする
ことと似たようなものである。移動の宛て先が著しいデ
ータ損失を伴ってデータを受取りうるとすれば（例えば
、宛て先がリンクをサポートしないとすれば）、ユーザ
はそのような警告を受け、移動オペレーションを止める
機会が与えられる。
４．１．ニー　に・　る　て　　ブジエクトの１吏 前述の説明は宛て先オブジェクトが内部的に、共用され
たデータ、コピイされたデータあるいは移動したデータ
を表示する態様に焦点を当ててきた。若干離れた論議は
そのデータがユーザに提供される態様である。−旦デー
タが内部化されると、宛て先オブジェクトに記憶された
他のデータとは相違しない。ユーザに対するその見掛け
も必然的に相違せず、該オブジェクトの他のデータと共
に＃Ｒ集可能である。宛て先オブジェクトにより扱いう
るタイプであるが（共用されているため）リンクされて
いるタイプのデータは宛て先オブジェクトに実際に記憶
されたデータとは区別のつかない態様でユーザに提供さ
れうる。しかしながら、前記データはオブジェクトに直
接記憶されるのと正確に同じ要領で＃ＩＡ集できないの
で、何らかの方法で事実上区別がつかないようにするこ
とが好ましい。
（それがリンクされているオブジェクトに対して外部の
タイプであるか否かには関係なく）リンクされているデ
ータは個別にリンクされたデータ上で編集オペレーショ
ンを呼び出すことにより編集される。リンクされている
データのあるものは、固有のデータと相互作用しえない
ほど異なったタイプであっても依然として固有のデータ
と共に可視的に現われる可能性がある（外部データを表
示するため、宛て先のオブジェクトマネージャは八Ｐｒ
’ＡＣにを介して、そのようなデータを表示できるオブ
ジェクトマネージャを呼び出す）。これは［隔離された
」データとして知られている。たとえ隔離されたデータ
がオブジェクトにおける他のデータと同じタイプのもの
であったとしてもデータ閉離が用いられるような状況が
ある。例えば、ドキュメントのピクチャと関連した見出
しが単に固定位置に修正されず、かつドキュメントの他
のテキストとフォーマット化されずに現われることがあ
る。
このように、見出しはテキストとしてでなくむしろイメ
ージとして効果的に扱いうる。
隔離が可能でない場合、統合されたプレゼンテーション
（表示）の最小の形態は「アイコンによる表示」であっ
て、リンクされたデータの介在を示すアイコンが宛て先
オブジェクトのデイスプレィの適当な位置に表示される
。他のオブジェクトへのリンクをサポートする全てのア
プリケーションは少なくともアイコンによりデイスプレ
ィをサポートすべきである。リンクがデータ交換を指示
しない場合（即ち、リンクがリンク仕様を含まない場か
）アイコンによるデイスプレィはリンキングアプリケー
ションが成しうる最良のものである。
このように、フォルダオブジェクトはアイコン以外でユ
ーザに現われることは全くない。
４．２．　　る−一タ　ム　、を云 以下の例は前述したデータ統合概念のあるものを示す。
第１のドキュメントがチャートを含む。これはチャート
を記憶するに適したオブジェクトへのリンクを含むドキ
ュメントオブジェクトにより達成される。ユーザは第２
のドキュメントを作成する。
ユーザはく例えばマウスを動かし、関連の釦を入れるこ
とにより）第１のドキュメントでチャートを選択し、次
いで「共用」キーを押す（あるいは他の手段では共用命
令を呼び出す）。次いでユーザはチャートが現われるべ
き第２のドキュメントの位置を指し、次いで「プレース
〈位置指示）」キーを押す（あるいは他の手段ではプレ
ース命令を呼び出す）。次いで、チャートは第２のドキ
ュメントに現われる。次いでユーザは、第２のドキュメ
ントの内部からチャートを選択し、ｍ集キーを押し、チ
ャートオブジェクトマネージャを呼び出す。ユーザはチ
ャート内で変更する。次いで、ユーザは第１のドキュメ
ントを再び開き、第２のドキュメントの内部からユーザ
が行ったばかりの変更を含むチャートを観察する。この
例においては、チャート自体のコピイが一枚ある。共用
オペレーションによりチャートへのリンクのコピイの第
２のドキュメントを作成したので単一のチャートに２個
のリンクがあることになる。
引続きこの例を検討する。ユーザが第２のドキュメント
において第１のドキュメントのそれと似たテキストのあ
るパラグラフを利用したいと思う。
ユーザはこのテキストが現われるべき第２のドキュメン
トにおける個所を指しプレースキーを押す。（宛て先オ
ペレーション（プレース）と原始オペレーション（コピ
イ、移動あるいは共用すること）はいずれの順番でも呼
び出し可能である０次いで、ユーザは第１のドキュメン
トまで進み、テキストのパラグラフを選択し、コピイの
キーを押す。次いでユーザは第２のドキュメントに戻り
、パラグラフが希望位置に現われるか観察する。ユーザ
はそのパラグラフを編集する。後でユーザは第１のドキ
ュメントに戻り、原始テキストが変ってないか、即ち第
２のドキュメントでコピイしたテキストをｍｓすること
により第１のドキュメントの原始テキストに何らかの変
化をもたらしていないか観察する。
前記の例を更に継続して検討する。ユーザが第１のドキ
ュメントにあるピクチャを第２のドキュメントに組み入
れたいと思う。ユーザがこれを実行したいのは、前述の
テキストのように、しかし前述のチャートのようではな
く、ピクチャの見掛けの各々は他のドキュメントのピク
チャを変えることなく変えうるからである。ユーザは、
第１のドキュメントのピクチャを選択し、コピイのキー
を押し、第２のドキュメントにおける希望位置を指し、
プレースキーを押すことによりこの作業を達成する。こ
のためピクチャを含むピクチャオブジェクトのコピイを
作り、かつこの新しく作成されたピクチャオブジェクト
へのリンクを第２のドキュメントにおいて作成する。
この例を１ステツプ先まで引続き検討する。ユーザが第
１のドキュメントのテキストの文が同一形態で常に第２
のドキュメントに現われ、その文で行った何らかの変更
が双方のドキュメントに現われるようにしたいと思う。
ユーザはこのことを、希望する文を選択し、共用キーを
押し、第２のドキュメントにおける位置を指し、プレー
スキーを押すことにより達成する。、第１のドキュメン
トを記憶するオブジェクトを識別し、かつ（ドキュメン
トオブジェクトマネージャが理解しうる要領で）選択さ
れたテキストの文を識別するリンク仕様を含むリンクか
第２のドキュメントで作成される。
データの「内部化」と「密閉化」との区別は前述の例を
９照して表示しうる。ドキュメントオブジェクトはテキ
ストを記憶するよう構成されたものであるため、第２の
ドキュメントにコピイされたテキストのパラグラフは、
第２のドキュメントを記憶したドキュメントオブジェク
トにおいて内部化される。このことはコピイされたテキ
ストが前記第２のドキュメントに記憶された他のテキス
トと共に直接記憶されたことを意味する。対照的に、第
２のドキュメントにコピイされたピクチャは密閉化され
る。この理由は宛て先オブジェクト（ドキュメントマネ
ージャ）が直接ピクチャデータを記憶できないからであ
る。チャートと文とが（コピイされるのでなくむしろ）
それぞれ共用されるので、それらはそれぞれ（内部化さ
れるのではなくむしろ）第２のドキュメントにおいて密
閉化される。
オブジェクトがデータを内部化するにつれて、このデー
タはオブジェクトにすでに存在しているデータと区別が
つかなくなる。内部化したデータは編集でき、あるいは
前に存在していたデータと共に直接操作できる。密閉化
したデータをＲｉａ集するために、ユーザは密閉化した
データ分選択し、編集命令を出すことにより、密閉化し
たデータが記憶されているタイプのオブジェクトを扱う
ことの出来るオブジェクトマネージャを呼び出す必要が
ある。何故ならこの差により密閉化されたデータは典型
的にはユーザに対して可視マーキングを（例えばボック
スで囲んだり、文字上の属性で表示したりして）付され
るからである。
前述の例においては、ユーザは必ずしもピクチャデータ
がテキストデータとは別に記憶されていることに気をつ
けておく必要がないが、ユーザは、ピクチャを編集する
には新しいウィンドウを開くことになるエキストラオペ
レーションが必要なことを知る必要がある。
前述の例で示される別の点は、オブジェクトの全て、あ
るいは一部に対して前記の統合オペレーションを実行し
うろことである。前述のように、オブジェクトが「コピ
イ」され、データが「密閉化」されると、新しいオブジ
ェクトが作成されてそのデータを記憶し、かつ新しいオ
ブジェクトに対するリンクが宛て先オブジェクトで作成
される。コピイすべくユーザが選択したデータがオブジ
ェクトの極一部である場合、新しく作成されたオブジェ
クトは（１）原始オブジェクト全体のコピイ、（２）希
望する部分のみ、あるいは選択されたものより大きいが
全体よりは小さい部分のコピイを含むことができ、特定
の場合のデータの量はオブジェクトのタイプ、および可
能性としては選択された部分とｉＪ択されない部分との
間の関係によって変わる。新しいオブジェク１−が選択
したデータ以上のものを含む場合、リンク仕様が選択し
た部分を識別する。
リンクにより子供のオブジェクトからのデータが親のオ
ブジェクトに現われるようにする。概念的には、子供の
オブジェクトにおけるリンクされたデータが修正される
と、その修正は親のオブジェクトにおいて明示すべきで
ある。直線的にリンク結合を達成する実行によりシステ
ムに対して強度の性能要求を課しうる。
本発明によるシステムはリンクパラレルファイルと、広
範囲の代替的なリンク更新状態とを用いてシステムに対
するリンク結合による負荷を低減し、一方ユーザに対し
てリンク結合の利点を提供している。リンクパラレルフ
ァイルは親のオブジェクトが容易にアクセスしうるリン
ク結合のデータのコピイな記憶するための便利な倉庫で
ある。
もしこのコピイを連続的に使う場合、親オブジェクトは
常に子供オブジェクトにおいてデータを正確に反映する
ことになる。しかしながら、実際的な問題として、もし
リンクパラレルファイルがある重要な時点、例えば子供
のオブジェクトにおけるデータが変るときとか、あるい
は親のオブジェクトに対してオペレーションが実行され
るときに更新されるとすれば同じ結果を達成することが
できる。各リンクは、該リンクの状態に適きするよう選
択しうる関連の更新状態を有する。更新状態とは、本明
４ａ書の詳細な説明において述べるようにリンクパラレ
ルファイルにおけるエントリでのフィールドである。更
新状態に対して現在定義されている値は、マニュアル（
Ｍａｎｕａｌ）、ファーストタイム（Ｆ　１ｒｓｔ　Ｔ
　ｉｍｅ＞およびダイナミック（Ｄｙｎａ鴎ｉｃ）であ
る。−船釣に、ユーザが親オブジェクトを観察している
間に子供オブジェクトにおいては何ら変化は発生しない
。このように、はとんどのリンクはユーザが親のオブジ
ェクトに作用する毎に、即ち「ファーストタイム」の更
新状態のときにのみ更新されればよい。もしユーザがス
プレッドシートで作スすると同時にスプレ・ンドシート
からリンクされた数でドキュメントを観察したい場き、
およびユーザがドキュメントが常に現在のスプレッドシ
ートの値を反映しているか調べたい場合、そのリンクの
更新状態を「ダイナミック」にセットずべきで、このた
めスプレッドシートが修正される毎に更新オペレーショ
ン牽発生させる。
５．１．２．リンク１　　ベレーシ、ンは　戸をリンク
更新オペレーションは再帰を要する可能性がある。「リ
ンク更新」に含まれたデータには「別のリンク」がはめ
込まれている。この「別のリンク」における更新状態の
フラッグの状態に応じて、元の更新オペレーションを完
了させるためにこのｒ別のリンク」に対して更新オペレ
ーションを実行する必要がある。「別のリンク」により
基準化されるデータ自体は、はめ込まれたり、ンクを含
む。このように、リンク更新オペレーションが完了する
ことはリンクにより指示される深さまでの入れ子関係の
更新オペレーションの完了を含む。
リンクとオブジェクトとがＩＩｌ？層関係に編成される
とは限らないので、一連のシリーズが依存ループを形成
することができる。単純な例としては、第１のオブジェ
クトが、第２のオブジェクトの一部を基準とした第１の
リンクを含み、第２のオブジェクトが第１のリンクを含
む第１のオブジェクトの部分を基準とする場合である。
本発明のシステ１１は更新オペレーションが循環的であ
って、エラーを発することを検出する。代替的システム
では惟に１回の循環、データが安定するまで（このよう
なことは発生することがない）の循環、あるいは間欠的
な循環を合む。
５．２．はめムみリンクを　　る−一部をコピイー他の
オブジェクトへのリンクを含むオブジェクトをコピイす
る場合、この参照されたデータをいかに処理するかの問
題が発生する。リンクあるいはデータ自体がコピイしう
る。ユーザは、例えば以下の例が示すように種々の状態
において種々の結果を所望することがある。
本発明のシステムにおいては、各リンクと関連した「コ
ピイフラッグ」がある。コピイフラッグの値が、リンク
を含むオブジェクトがコピイされる場合にリンクを処理
するり様を決める。リンクが作成される場合、そのコピ
イフラッグの初期値は、ユーザあるいはアプリケーショ
ンが規定したリンクを作成しないならば省略値のルール
によりセットされる。その結果はコピイオペレーション
がユーザの期待する結果を度々達成する。コピイフラッ
グをセットする省略値ルールは以下の通りである９リン
クされたオブジェクトがリンクを含むオブジェクト内か
ら作成されると、コピイフラッグはリンクされたデータ
がコピイされるようにセラｌ−される。さもなければ、
コピイフラッグは、リンク（リンクされたデータでなく
）がコピイされるようにセットされる。
５．３．リンクマー　゛ リンクマーカはオブジェクトのデータの本ｆ本に含まれ
リンクされたデータの介在を指示する。オブジェクトの
データはそのオブジェクトタイプに典型的に独特のフォ
ーマツＩ・（オブジェクトのオブジェクトマネージャの
みに「知られる」必要のあるフォーマット）に記憶され
るので、リンクマスクのフォーマットもアプリケーショ
ンに依存している。リンクマスクは少なくともオブジェ
クトを読取るアプリケーションがリンクＩＤの値を決定
できるようにする必要がある。リンクＩＤはリンクに関
する別の情報がリンクテーブルから検索できるようにす
る。
アプリケーション設計者は子供のオブジェクトのオブジ
ェクトタイプをリンクマーカに含めるよう選択すればよ
い。このため、子供のオブジェクトのオブジェクトマネ
ージャを呼び出す前に（子供のオブジェクトのオブジェ
クトマネージャを識別するに必要であるが、（タイプに
関する情報を検索するアプリケーション統合サービスに
より）オブジェクトテーブルの探索を排除することによ
り性能を向上させうる。
リンクマスクフォーマットは、リンクマスクを含むオブ
ジェクトにおけるデータが修正されると、残りのデータ
に関するリンクマスクの位置は出来るだけ緊密にユーザ
の期待に対応するよう設計すべきである。以下の２種類
の実行を検討する。即ち（１）データファイルのどこに
リンクが論理的に位置していたかを示すバイトカウント
を備えたリンクＩＤのテーブル（２）前記データの関連
位置にはめ込まれたリンクＩＤが続くエスケープシーゲ
ンスである。第１の例によりマーカで識別したリンクは
、リンクマスクに先行するデータが追加されたり、ある
いは削除されると移動しているように見える。少なくと
もドキュメントに関しては、第２の代案がより緊密にユ
ーザの期待に対応する。
前節に述べる第１の実行により示すように、リンクマー
カはリンクされたデータが現われるべき親のオブジェク
トのデータの位置に物理的に記憶される必要はない。
Ｌユ２辺ユ２乙仇鵞− そこを横切ってデータが通りうる各リンクに対して、リ
ンク仕様がある。フォルダオブジェクトへのリンクは訣
してリンク仕様を含むことはない。
フォルダはオブジェクトの編成を作成するために使用す
るオブジェクトであり、かつオブジェクト自体は何ら実
質的なデータを含まないため、リンク仕様は必要でない
。
リンク仕様は、リンクされたデータがリンクされたオブ
ジェクトの全体であることを示し、あるいは特定の部分
を識別することができる。リンク仕様の解釈はリンクさ
れたオブジェクトのオブジェクトマオ・−ジャにより実
行される。即ち、リンク仕様は特定のアプリケーション
に係るものである。
リンクされたオブジェクトが修正された後リンク仕様の
解釈が出来るだけユーザの期待に対応するようリンク仕
様の実現を考えることが望ましい。
リンク仕様を実現する以下の方法がこの点を示す。
データベースオブジェクト用のリンク仕様は質問仕様で
ある。このタイプのリンク仕様はユーザの期待に対応す
るという希望する結果を特に十分達成する。
図示のためのリンク仕様は以下の形態である。
３頁１インチ下２インチ横から始まって、２インチ長さ
で３インチ幅の長方形の部分を用いる。これにより図示
のある頁が入るウィンドウを規定する。その頁のピクチ
ャがシフトされる結果、リンクで別のデータが規定され
る。
スプレッドシート用のリンク仕様は、絶対的な座標ある
いは名前付き範囲のいずれかで規定されるある範囲のセ
ルである。スプレッドシートの変更により、スプレッド
シートのユーザより容易に理解される要領によりリンク
仕様によりいずれのセルが規定されるか作用する（例え
ば、絶対的な座標が使用されると、規定された組のセル
は、その範囲の左側のコラムが削除されると変化する）
。
ドキュメントオブジェクト用のリンク仕様は顕著に異な
る方法をとる。ドキュメントの一部がリンクすべく選定
されると、ドキュメントの選定された部分は現在の位置
から除去され、ドキュメント内のシェルフ（「柵」）に
位置される。その部分が以下常駐していた位置には新し
く作成されたシェルフへの索引が位置される。リンク仕
様がこのシェルフを識別する。ドキュメントエディタが
リンクされたマテリアルのようにシェルフ上のマテリア
ルを取り扱う。シェルフ上のマテリアルは適当な位置で
ドキュメントで表示されるが、シェルフ上のマテリアル
はそのシェルフでの編集オペレーションを特別に呼び出
さずには編集することはできない、このように、ユーザ
はドキュメントのテキストのあるものを共用している別
のオブジェクトにおいてドキュメントに対する変更が明
示される態様を容易に理解する。シェルフの外側での変
更は何ら効果なく、シェルフ上の変更はリンクを横切っ
て見られる直接変更したデータである。
５．５．オブジェクトとリンクの　七 オブジェクトは凍結できる。凍結されたオブジェクトは
決して修正することができない。本発明によるシステム
に対する規則はオブジェクトが一旦凍結されたものとし
てマーキングされると、再び凍結したとマーキングされ
ることは無いことである。コピイは凍結したオブジェク
トからつくることができ、コピイは修正することができ
る。オブジェクトは、オブジェクトカタログのそのオブ
ジェクトのレコードにおいて「凍結」フラッグを設計す
ることにより凍結したものと識別される。
リンクは凍結することができる。これはリンクの更新状
態をマニュアルにセットすることにより実行される。マ
ニュアルの更新状態のリンクにより提供されたデータは
、次のときにリンクを新しいデータで更新すべきとのリ
クエストがなされるまで一定のままである。リンクの更
新状態がマニュアルであると、リンクに関連したデータ
が宛て先オブジェクトのリンクパラレルファイルに記憶
されるコピイとなる。このデータはユーザが更新オペレ
ーションを要求するまでは不変のままであるが、前記の
要求時データの新しいコピイが作られる。リンクの更新
状態がマニュアルにセットされると、更新オペレーショ
ンが実行され、リンクパラレルファイルにデータがある
ことを保証する。
オブジェクトに対する凍結したリンクはそのオブジェク
トの修正可能性には影響しない。該リンクはその特定の
リンクを通して視たオブジェクトの外観のみを凍結する
。前記外観を含むデータはく宛て先オブジェクト即ちリ
ンクを含むオブジェクトである）リンクパラレルファイ
ルに記憶され、リンクが作られているオブジェクト（原
始オブジェクト）は依然として修正可能である。
第１Ａ図、第１Ｂ図および第１Ｃ図は本発明を組み込み
うる情報処理システムのブロック線図である。
第１Ａ図を参照すれば、顕著なディスク記憶容量１７２
、ブリンク１７４およびその他の共用の周辺装置１７６
を備えたホストコンピュータ１７０は複数のインテリジ
ェントワークステーション１７８に接−続されている。
各ワークステーション１７８は仮想メモリをサポートす
るメモリ管理を備えたコンピュータを禽む。ワークステ
ーションは局部的に接続された周辺装置を含んでよいが
、典型的にはホストコンピュータ１７０に接続された周
辺装置１７４および１フロを使用する。ワークステーシ
ョン１フ８はローカルディスク記憶装置１８０を含んで
よく、その場合仮想メモリシステムはホストコンピュー
タのディスク１７２へでなく、むしろ局部的にページン
グ出来る。
特定の構成においては、高速（４メガビット／秒）の直
列データリンク１８２を介して各ワークステーション１
７８に接続されたつオングＶＳミニコンピユータで、ワ
ークステーションは各Ｑモトローラ（ＭｏＬｏｒｏｌａ
）６８０２０プロセツサである。この構成において、ホ
ストコンピュータはｖｓオペレーティングシステムを実
行し、オブジェクトカタログとシステムのデータベース
テーブルのあるものを管理するために汎用の関連データ
ベースシステムを使用し、かつシステムのデータベース
の残りに対してより単純なツールを用いる。（以下説明
する）カタログサーバプロセッサ１９０がＶｓで実行す
る。
各ディスク１７２は１個以上のボリュームとして編成さ
れ、その各々はオブジェクトおよびその他のファイルを
記憶するなめに使用され、かつ対応するオブジェクトカ
タログを含む。一方のボリュームがシステムデータベー
スを含む。各ワークステーション１７８は必要に応じて
マルチタスキングカ−ネル１９２、アプリケーションマ
ネージャプロセス１９４、および１個以上のオブジェク
トマネージャ１９６を実行する。へＰＰＭＣＫルーチン
２１８とＲＥＳＰＡＣにルーチン２２２とかワークステ
ーションに介在し、そこで実行している各種のオブジェ
クトマネージャ１９６により呼び出される。
代替形態（第１Ｃ図）においては、ワークステーション
はローカルエリヤネットワーク１５４上の対等なものと
して接続され、前記ネットワークには共用資源用サーバ
（例えばファイルサーバ１５６、プリントサーバ）およ
び例えばミニコンピユータあるいはメインフレー１１コ
ンピユータのような共用計算資源も接続されている。
さらに別の代替構成（第１Ｂ図）においては、（キーボ
ード１１８とデイスプレィ１２０とを含む）ダム（ｄｕ
ｍｂ）ワークステーションが（メモリスペース１１０と
中央処理装置１１６とを含む）ホストコンピュータに取
り付けられている。この構成において、オブジェクトマ
ネージャとアプリケーションマネージャとは、ワークス
テーションでなくむしろホストコンピュータで実行され
る。
第１Ｂ図を参照すれば、全体的な情報処理システム、即
ち、ブログラノ、により制御され、かつシステム１００
のユーザにより指示されてデータあるいはｔｒｒａに対
してオペレーションを実行するコンピュータシステムの
ブロック線図が示されている。
図示のように、システム１００はメモリスペース１１０
、即ちオペレーションを実行する上でシステム１００ま
でアクセス可能で且つ該システムにより使用可能のメモ
リスペース、を含み、該スペースにおいてユーザによる
指示と制御とによって対応するデータ構造に対して各種
のオペレーションを実行するためのプログラムやオペレ
ートすべきデータ構造が常駐する。図示のように、メモ
リスペース１１０は、現在使用中のデータ構造やプロゲ
ラｌ、を記憶するためのメインメモリと、現在使用中で
ないデータ構造やプログラムを記憶するための、１個以
上のディスクドライブのような大記憶メモ’月１４から
構成されている。前記システ：ｂＩｏｏにはまた、シス
テムのオペレーションを実行するためにプログラムに対
して応答する中央処理装置（ＣＰＵ）１１６が含まれて
いる。ユーザの入力に対してキーボード１１８が設けら
れ、かつユーザにオペレーションを可視表示するために
デイスプレィが設けられている。また、システム１００
はシステム１００へ、かつそこからの情報入出力を供給
するためにテレコミュニケーション、ネットワークイン
タフェースおよびプリンタのような１個以上の周辺装置
１２２を含んでもよい。これら周辺装置１２２のあるも
のはシステム１００のメモリスペース１１０内に含めて
よいことに注目すべきである。
システム１００のメモリスペース１１０に常駐するプロ
グラムとデータ構造とを参照すれば、これらのエレメン
ト・はユーザの指示でデータ構造に対してオペレーショ
ンを実行するプログラム１２４と、オペレートされるデ
ータ構造１２６とを含む。また、本システムのオペレー
ションを導き、監視し且つ調整する機能を提供するオペ
レーティングシステムのプログラム１２８と、本システ
ムとキーボード１１８、デイスプレィ１２０および周辺
装置１２２どの間での情報の転送を制御する入力／出力
プログラム１３０とが含まれている。
第１Ｃ図を参照すれば、本発明を組み込みうる第２の情
報処理システム（システム１５０）が示されている。該
システム１５０は、単一のｃ　ｐ　ｕ　１１６と、多数
のユーザが共用しうるメインメモリ１１２との代りに、
システム１５０が、それぞれが皐−のユーザに供しうる
複数のＣＰＵ１１６とメインメモリ１１２とを備える点
においてシステム１００と相違する。
しかしながらシステム１５０はシステム１００と同様に
、現在使用されていないプログラム１２４を記憶する単
一の大容量メモリ１１４とデータ構造１２６とを備え、
単一の大容量メモリ１１４も本システムの全てのユーザ
により共用される。
図示のように、システム１５０は一般的に第１Ｂ図に示
すシステム１００と同じ基本的エレメントを含む。しか
しながら、システム１５０は複数の処理装置１５２から
構成され、該処理装置の方はファイルサーバ１５６にバ
ス１５４を介して接続され、該サーバの方はシステム１
５０の中央に配置の大容量メモリ１１４に接続されてい
る。各処理装置１５２、即ちワークステーションの方は
ＣＰ　Ｕ　１１６と、メインメモリ１１２と入力／出力
装置　１５８とからなり、該入力／出力装置１５８は例
えばキーボード１１８、デイスプレィ１２０および周辺
装置１２２とを含む。
システム１００におけるように、現在使用中のプロゲラ
１．１２６とデータ構造１２６、オペレーティングシス
テムのプログラム１２８と入力／出力プログラム１３０
とは各処理装置１５２のメインメモリ１１２に常駐し、
入力／出力装置を介して処理装置１５２と対話している
ユーザの指示によってオペレーションを実行する。イナ
クティブ（ｉｎａｃｔｉｖｅ）、プログラム１２４とデ
ータ構造１２６とは単一の中央に配置の大容量メモリ１
１４に常駐し、大容量メモリ１１４と、処理装置１５２
の個々のメインメモリ１１２どの間をファイルサーバ１
５６とバス１５４とにより転送される。この点に関して
、ファイルサーバ１５６は処理装置１５２からのリクエ
ストを読取ったり書込むよう応答し、データ構造１２６
とプログラム１２４とを、ユーザのオペレーションによ
り要求されるに応じて大容量メモ１月１４と処理装置１
５２との間で読取ったり書込んだりする。さらに、オペ
レーティングシステムプログラム１２８と入力／出力プ
ログラム１３０とは大容量メモリ１１４において記憶さ
れかつ必要に応じて例えば処理装置１５２の開始時に大
容量メモリ１１４から処理装置１５２のメインメモリ１
１２ヘロードしうる。
これらの目的に対して、ファイルサーバ１，５６は例え
ばインテリジェントドライブシステムのような専用ファ
イルサーバより構成するか、あるいはシステムユーザの
指示とリクエストとにより更に別のオペレーションを実
行しうる汎用コンピュータから構成すればよい。
７、−六シスームの　るエレメントについて本発明のシ
ステムのエレメントのあるものには、システムデータ構
造、アプリケーションパック（＾ｒ’ＰＡｃＫ）２１８
、関連した資源パック（ＩＩＥＳＰＡＣＫ）２２２を備
えた資源がある。
システムデータ構造は本システムの管理に関係した複数
のデータ構造体、その中のオブジェクトおよびオブジェ
クトマネージャと資源とである。
システムデータ構造はシステムの一次フォルダ、システ
ムのデータベース２５０および１個以上のオブジェクト
カタログ２５２とを含む。第２図に示すように、システ
ムベース２５０はオブジェクトタイプテーブル２５４、
オブジェクトマネージャテーブル２５６、およびオブジ
ェクトプロトタイプテーブル２５８とを含む。第５図に
示すように、オブジェクトカタログ２５２はオブジェク
トテーブル２６０、リンクテーブル２６２およびファイ
ルリストテーブル２６４とを含む。リンク平行ファイル
２６６も、それらが公に入手しうる情報（例えば、更新
状態、表示状態および表示モードフィールド）を含む範
囲まではシステムデータ構造である。
八ＰＰＡＣＫ２１８の方は、オブジェクトマネージャの
統合、オブジェクト管理、オブジェクトマネージャの呼
び出しおよびオブジェクトマネージャの「突き合わせ」
およびオブジェクト間でのデータの交換に対するサービ
スと機能とのパックからなる。
烏ろ場合には、特定のシステムにおけるオブジェクトと
ファイルとは「ボリューム」に編成され、特定のオブジ
ェクトカタログは所定のボリュー！、内でのオブジェク
トへのエントリを含み、１個以上のボリュームがある場
合、該システムにおけるオブジェクトカタログは１個以
上である。その他のシステムにおいては、オブジェクト
とファイルとは単一のオブジェクトカタログに収録しう
る。オブジェクトカタログはボリュームにある全てのオ
ブジェクトの中オブジェクト識別子により割り出された
オブジェクトテーブルを含む。さらに、オブジェクトカ
タログはオブジェクトテーブルにエントリを有する各オ
ブジェクトへ、あるいはそこからの各リンクに関する基
本的情報を含む、データリンクを有するオブジェクトカ
タログにおいて各校のオブジェクトに関してリンクパラ
レルファイル２６６がある。特定のオブジェクトに関係
するリンクパラレルファイル２６６はそのオブジェクト
の二次データファイルに常駐する。
ユーザが所定のオブジェクトに対してオペレーションと
行うよう選択すると、ＡＩ’ＰＡＣＫ２１８のルーチン
がそのオブジェクトのオブジェクトタイプ、オペレーシ
ョンおよび可能なオブジェクトマネージャテーブルから
の言語を読み取り呼び出すべき対応のオブジェクトマネ
ージャを検出する。特定のオブジェクトに対してオペレ
ートするよう呼び出された特定のオブジェクトマネージ
ャは実行すべきオペレーションのタイプにより変わり、
かつあるオブジェクトマネージャは１タイプ以上のオブ
ジェクトにオペレートすることができる。
オブジェクトプロトタイプテーブルはプロトタイプのオ
ブジェクトを識別する。オブジェクトプロトタイプは対
応するタイプのオブジェクトの基本的な省略値特性を含
む。オブジェクトプロトタイプテーブルは、そのために
プロトタイプが存在するシステムに取り付けたオブジェ
クトの各タイプのブロトタイプコピイを識別する手段を
提供する。そのためにプロトタイプの存在するいずれか
のタイプの新しいオブジェクトが、オブジェクトプロト
タイプのコピイを作ることにより作成され、プロトタイ
プオブジェクトのコピイはユーザにより修正されたり、
オペレートされる新しいオブジェクＩ・どなる。プロフ
ァイルエディタは新しいオブジェクトに対して対応する
新しいプロファイルを作成し、かつ必要に応じてオブジ
ェクトの修正された特性を反映するために基本的プロフ
ァイルのコピイを修正するために使用しうる。
ユーザは、例えば書式文字であるデータをすでに含む新
しいタイプのオブジェクトを作成できる。
ユーザは前述のようにプロトタイプオブジェクトの適当
なコピイをつくることにより新しいブランクオブジェク
トを作成する。次いでユーザはプロトタイプオブジェク
トに現われるべきデータを入力し、必要に応じてオブジ
ェクトプロファイルを修正し、オブジェクトプロトタイ
プテーブルにこの新しいプロトタイプオブジェクトのエ
ントリを位置する。次いで、この新しいプロトタイプオ
ブジェクトは、プロトタイプオブジェクトのコピイを作
ることによりブランクのプロトタイプオブジェクトと同
様にオブジェクトを作成するために使用され、プロトタ
イプにユーザにより入力されたデータがプロトタイプの
各コピイに現われる。
資源は、プロゲラｌえにより使用されるが、いずれのプ
ログラムの実行可能コードの一部として記憶されないデ
ータのブロックである。これらの資源は、−ａ的に、例
えば各種のオペレーティングシステムやユーザのインタ
フェース機能により本システムにより使用されるが、個
々のプロゲラ１１により使用される。１個以上のシステ
ム資源を含む、さらに、資源は、特に本システムのユー
ザと特に関連しくユーザファイルに記憶された）１個以
上の資源を含みうる。
ＲＥＳＰＡＣには資源にアクセスしかつそれを修正する
ために使用するサービスや機能のパックである。
いずれかのプログラムあるいはユーザを用いてＲＥＳＰ
ＡＣＫの装置を用いて資源を作成するが、あるいは既存
資源をコピイし、かつコピイした資源をプログラム、機
能またはユーザの特定の要件に合うようコピイした資源
を修正しうる。これらの揚重には、カストマイズされた
資源がそのため作成あるいは修正されたプログラム、機
能あるいはユーザに対して特定的となり、後述のように
、プロダラムあるいはユーザの関連ファイルの対応する
修正によりそのプログラム機能あるいはユーザと関連す
るようになる。その後カストマイズされた資源は元の未
修正資源の代りに用いられる。
８、シスームーータ　貴 以下オブジェクトとリンクとに関する情報を記憶する各
種のシステムデータ構造について説明する。この情報は
、それぞれ−組のフィールドに編成されるレコードのテ
ーブルとして編成される。
８．１．シスームーータベース 各システムに対して以下のものがそれぞれある。
８．１．１．−ブジェクトタイプーープルオブジェクト
タイプテーブルは各オブジェクトタイプに対してレコー
ドを含む。
１．１（ａ）　　　ブジェクト　イブ−４バイト１．１
（ｂ）　　；　ブジェクトクラスー４バイトこれはオブ
ジェクトタイプをユーザが熟知のカテゴリに関係させる
。オブジェクトタイプの区別は一般的にユーザからは隠
されている。オブジェクトの［クラスＪはユーザの考え
る区別に対応するようにしたものである。例えば、オブ
ジェクトをオブジェクトのクラスに関連づけることによ
り、（それぞれ異なるオブジェクトタイプに対応する）
２個以上の非互換性のドキュメントエディタを用いて作
成できるものではあるが、全てのユーザの「ドキュメン
ト」のリストをユーザに示しやすくする。
１．１（ｃ）　　−イスプレイ　　。
ユーザに示すためのオブジェクトタイプの名前を含む資
源の資源ＩＤ １．１（ｄ）　　−イスプレイアイコンオブジェクトタ
イプに関連したアイコンを含む資源の資源ＴＤ １　、１　（ｅ）　　プロトタイプＩＤ−６４バイト関
連したタイプのオブジェクトに対する一次プロトタイプ
のオブジェクトパーマネントＴＤ１．１（ｆ）　　ＬＡ
−５０バイト オブジエクトタイプのテキストの説明 １．１（ｇ）　　傷艮入５　Ｌｆ　−１バイトユーザが
このタイプのオブジェクトを作成しうるか調べるための
もの ８．１．２　　オブジェクトマネージャー−プルオブジ
ェクトマネージャテーブルは規定したタイプのオブジェ
クトに対する規定した開始リクエストを実行できるプロ
グラムを識別するために使用するものである。
１．２（ａ）　　　ブジェクトタイプー４バイト１．２
（ｂ）　　リノ≦Ｌ乙±−４バイトこのフィールドは、
特定のオブジェクトタイプに対するリクエスト全部を扱
うために単一のプログラムが使用される単純なケースを
簡単に処理するためにｒａｌｌという特殊な値を有する
ことができる。このフィールドに対する他の値の例とし
ては、 ｆｉ（ｓｔａｒｔ）　：規定したオブジェクトタイプ用
の省略時開始オペレーションを実行する ！Ｌ！Ｌ（ｅ’！ｔ）’ユーザがオブジェクトを編集で
きるようにする 読」！カー（ｒ　ｅ　ａ　ｄ　）　：ユーザが修正出来
ないがオブジェクトを観察できるようにする １、２（ｃ）　　’）じ４王ｊ（五ｊ１称−関連のオブ
ジェクトタイプに対するユティリテイメニューで表示す
べき、開始リクエストを記述するテキストを含む資源の
資源ＩＤ、このフィールドは開始リクエストが標準的リ
クエストではないが、特定アプリケーションである場合
にのみ使用される。
１．２（ｄ）　　　ブジェクトマネージャＩＤ−６４バ
イト 関連のタイプのオブジェクトに対して関連のリクエスト
を実行しうるプログラムのファイル名。
もしこのフィールドの値が零であれば、開始リクエスト
がなされたとき、規定されたオブジェクトの一次データ
ファイルが実行される（即ち、オブジェクトは直接実行
可能である）。
８．１．３．　　ブジエクトプロトタイプーープルオブ
ジェクトプロトタイプテーブルは各オブジェクトプロト
タイプに対するレコードを含む。各オブジェクトタイプ
に対して複数のプロトタイプがありうる。このテーブル
は、ファイルベースのオブジェクトに対してオブジェク
ト作成オペレーションを実行する場合アプリケーション
統合サービスにより使用される。
１．３（ａ）　　−ブジェクトタイプー４バイトオブジ
ェクトのタイプを示すコード １．３（ｂ）　　位ｆｌ二Ｊ−−２バイトオブジェクト
と関連した言語（例えば英語）１．３（ｃ）　　プロト
　イブＩＤ−６４バイト関連したタイプのオブジェクト
のプロトタイプのオブジェクトパーマネントＩＤ ８．１．４．　　ストマイゼーシ　ンーープルカストマ
イゼーションテーブルは可能な各資源力ストマイゼーシ
ョン（即ち、資源ＩＤ、資源ファイルおよびカストマイ
ゼーションＩＤの各有効組きぜ）に対するレコードを含
む １．４（ａ）　　　ストマ　ゼーシ９ンＩＤ−カストマ
イゼーションＩＤは特定のカストマイゼーションにより
資源のどの用途が変ったかを検出するために使用される １、４（ｂ）　　１１−関係のカストマイゼーションＩ
Ｄをユーザに対して識別するために使用するテキストス
トリングを含む資源の資源ＩＤ１．４（ｃ）　　えｌム
Ｌ血と一関連したカストマイゼーションＩＤに対して、
カストマイズしたバージョンがある資源を含む資源ファ
イルの名称１．４（ｄ）　　責１カーー関連したカスト
マイゼーションＩＤに対してカストマイズしたバージョ
ンがある関連資源ファイル内の資源を識別する８、１．
５．ライブラリー−プル ライブラリテーブルはオブジェクトカタログにドキュメ
ントを含む各ドキュメントライブラリに対するレコード
を含む １．５（ａ）　　−イブラ１タイプー１バイト（例えば
ＷＰまたはｗｐプラス） １．５（ｂ）　　ライブラリー８バイト−ｗｐルブラス
ライブラリよびＶＳ物理的ライブラリの名称１．５（ｃ
）　　昼曵遭ＪリコビーＡ−１バイトーＷＰボリューム
が省略時ＷＰボリュームか否か指示する １、５（ｄ）　　本Ｍノ二−Ａ−８バイト−ライブラリ
が常駐しているボリュームの名称 １．５（ｅ）　　ド　ユメントライブラリー１バイトー
ライブラリのＷＰ名称 １．５（ｆ）　　乳化１吏１バイトーライブラリの現在
の状態を、索引付けせず、要約のみ索引付けし、要約お
よびＷＩＴを割り出しと指示する。
１．５（ｇ＞　　次！ど数用〕ｔサー　１バイト−次の
索引けけの状態を示す９３種類の値を有する。即ち索引
１寸けせず、要約のみ索引付けし、要約およびＷＩＴを
索引付けし、ユーザは次の索引付けがなされるときどの
ようにライブラリを索引付けすべきか決定するようこの
フィールドをセットする。
１．５（１＋）　　アー　イバブルフーッグー１バイト これはこのレコードに対応するライブラリで作成された
オブジェクトに対するアーカイバブルフラッグ用の省略
時値である。
１．５（ｉ）　　ファイル　−クラスー１バイトこれは
このレコードに対応するライブラリで作成されたオブジ
ェクトに対するファイル保護クラスの省略時値である。
１．５（ｊ）　　オ：ゴ１１中−８バイトこのレコード
に対応するライブラリのオーナのログオンＩＤである。
１．５（ｋ）　　フォルシダＩＤ−３８バイトこのレコ
ードに対応するライブラリで作成されたドキュメントを
同期化すべきフォルダオブジェクトのパーマネントＩＤ
と現在の位置である。
８．１．６．ボリュームテーブル ボリュームテーブルは本システムに対する各々の構成し
たボリューム（例えば使用中の全てのボリュームやある
アーカイブボリューム）のレコードを含む。
１．６（ａ）　　ボリューム−８バイト−ボリュームの
名称 １．６（ｂ）　　仇囲沖１−辷Ｌ４−１バイトーボリュ
ームの状態、即ち使用中か保存中か、 １．６（ｅ）　　ボリュームバス　　、−６４バイト８
バイトより長いボリューム名を備えたシステムに対する
ボリュームのフルパス名称 ８．１．７．シスーム　　−一プル システム構成テーブルは例えば以下のような情報を備え
た単一レコードを含む。
１．７（ａ）　　レコードアクセス−１バイトオブジエ
クトへのアクセスの日付と時間とを記録できるようセッ
トされている １、７（ｂ）　　±に一色ＡＣＬ−１バイトオブジェク
トカタログに対する照会の間のアクセスコントロールリ
ストのチエツクを制御する。
即ち、決してチエツクしない、常にチエツクする、ある
いは関連のオブジェクトのレコードにおけるＡＣＬフラ
ッグがセットされたときのみチエツクする。
１．７（ｃ）　　シス−ムラオルダボ１ニームー８フバ
イト ジステムフオルダが常駐しているボリュームの名称 ８．２．　　ブジェクト　タログ 各ボリュームに対して以下の各々がある。
８．２．１．　　ブジェクトーープル オブジェクトテーブルはカタログにおける各オブジェク
トの記録を含む。論理的にはこのテーブルには、レコー
ドに関連するオブジェクトへのリンクの数を有する、各
レコードのリンクカウントフィールドがある。しかしな
がら、この数は、適当な子供のオブジェクトのパーマネ
ントＴＤを有するリンクテーブルのレコードを計数する
ことにより決定しうるので、その数はオブジェクトテー
ブルに記憶する必要はない。性能を向上させるために（
即ち、リンクテーブルにおけるレコードの計数を避ける
ために）オブジェクトテーブルの数を物理的に記憶する
ことが望ましい。
２．１（ａ）　　　ブジェクトＩＤ−４バイトレコード
の一連番号　カタログ内のオブジェクトを独特の方法で
識別する。別のカタログで割出しすべくオブジェクトが
動かされたとすれば新しいオブジェクトＩＤを割り当て
しうる。
２．１（ｂ）　　　ブジェクトパーマネントＩＤ−１２
バイト オブジェクトが移されるとしてもそのオブジェクトに対
して一定のままである。最初の６バイトはオブジェクト
が作成された１９８６年以来１０分の１秒の数を記憶す
る。次の６バイトはオブジェクトが作成されたシステム
が索引付けのため初期化された１９８６年からの１０分
の１秒の数を記憶する。
２．１（ｃ）　　タイトル−６４バイト＝ＷＩＴ（索引
付けされた「テキストのワード」）−ユーザが定義しう
る自由テキスト ２．１（ｄ）　　ＬｆＬ−３２バイト−ＷＩＴ−ユーザ
が定義しうる自由テキスト ２、Ｈｅ）　　１１にコム−３２バイト＝ＷＩＴ−ユー
ザが定義しうる自由テキスト ２．１（ｆ）　　：２　メ７　）−２５２パイ）−ＷＩ
Ｔ−ユーザが定義しうる自由テキスト ２．１（ｇ）　　；　ブジェクト　イブ−４バイト−オ
ブジェクトタイプを示すコード ２．１（ｂ）　　　ブジェクトクラスー４バイトーオブ
ジェクトクラスを示すコード、。これはオブジェクトク
ラステーブルへのキーとしてオブジェクトタイプを用い
て決定しうる。しがしながら、クラスは性能を向上させ
るためここで記憶される。
２．１（ｉ）　　タイプ−２０バイト−ＷＩＴ−ユーザ
が定義しうる自由テキスト ２、ＩＵ）　　デガニ」二Ａｚ±−−２０バイトーＷＩ
Ｔ−ユーザが定義しうる自由テキスト ２．１（ｋ）　　物」［的」【置−６４バイト−その本
来の名前スペースにおける、例えばファイル名あるいは
データベースの名前とレコード番号との組合せにおける
オブジェクト（あるいはもし一部分以上の場合主要部分
）の名称。一部分以上（例えば複数のファイルまたはレ
コード）から構成されているオブジェクトに対してはこ
れは主要部分の位置である。
２．１（Ｖ）　　　寸とｒｆＦ日ノー８ハイド２．１（
＋ｓ）　　ｆＬｆＬ！Ｌ　　８バイト−オブジェクトを
作成したユーザのログオンＩＤ ２．１（＋＋）　　修１ｍ吸同−８バイト２．１（ｏ）
　　１！ＬＬｆＬ−８バイト−オブジェクトを最後に修
正したユーザのログオンＴＤ２．１（ｐ）　　アクセス
した　・と時ｍ８バイト ２、Ｈｑ）７９−＋≦（した考−８バイト−オブジェク
トに８７１にアクセスしたユーザのログオンＤ ２．１（ｒ）　　プリントした　・と　＋＋−８バイト ２．１（ｓ）　　１里し」とした渚−８バイト−オブジ
ェクトを最後にプリントしたユーザのログオンＤ ２．１（Ｌ）　　アー　イブした　寸と時間−８バイト ２．１（ｕ）　　アー　イブした　−８バイト−オブジ
ェクトをＲ後にアーカイブしたユーザのログオンＩＤ ２．１（ｖ）　　アー　イブしたツー・・　−１バイ゛
トーオブジエクトがアーカイブされたか、コピイされた
かを示す、３種類の値（ｖａｌｖｅ）、即ち、保存した
、コピイした、いずれでもない、がありうる ２、１（ｗ）　　７　　ｈ’鉱乙可稲−１ビット−オブ
ジェクトに対応するファイルがもはや存在しないことが
検出された際何をなすべきか指示する。もしそのような
状暦が検出され、このフラッグがセットされていないと
すれば、オブジェクトのレコードが削除される。もしそ
のような状暦が検出され、このフラ・ソゲがセットされ
たとすれば、オブジェクトのレコードが保存され、アー
カイブされたフィールドが「アーカイブされたＪという
値にセットされる。
２．１（ｘ）　　アー　イブされたパーマネントＩＤ−
１２バイト−本オブジェクトに対してアーカイブされた
オブジェクトのオブジェクトパーマオン）ＩＤ ２．１（ｙ）　　アーカイブされた　　のＩ胃−２８バ
イト 本オブジェクトに対してアーカイブされたオブジェクト
の現在の記憶位ｅ（ロケーション）又は本オブジェクト
がアーカイブされたときの現在位置。
オブジェクトの現在位置はそのオブジェクトのＩＤ（４
バイト）、それがカタログ化されたボリュームの識別子
（８バイト）、およびそのボリュームが位置されている
システム用の識別子（１６バイト）である。
２．１（ｚ）　　テ　ストのワード−１バイトＷＩＴ照
会オペレーシヨン中に使用される２、１（ａａ）　　　
ブジェクトＷＩＴフラッグー１バイト オブジェクトがかってＷＩＴされたが、あるいはオブジ
ェクトがＶ％ＭＴされるかセットされる。
２．１（ａｂ）　　を１九ＩＤ−８バイトオブジェクト
のオーナのログオンＩＤ ２．１（ａｃ）　　ファイル　１クラス−１バイト２．
１（ａｄ）　　ΔＳ」ニＬｉヱグー　１バイトオブジエ
クトがアクセス制御リストを有するかセットする。
２．１（ａｅ）　　１ｌｉ（Ａ−４バイトオブジエクト
により使用されるにバイト２．１（ａｒ）　　、　Ｆ！
　　　４　Ｘ　−２バイトオブジエクトがｍ集されてき
た回数 ２．１（ａｌ＋）　　　、　７−　Ｌｆ　−１バイトオ
ブジエクトを削除すべきかセットする。
２．１（ａｉ）　　ＩＩＪＬ　　１バイトオブジエクト
が編集できないかセットする。
２．１（ａｊ）　　　　さ　たツーラグ−１バイトオブ
ジエクトが損傷され、開放できないかセットする。
２．１（ａｋ）　　改１ｍ歴−３ビツト改訂履歴情報を
記録すべきか指示する。
以下は可能な値である。
凡Ω−二改訂履歴情報を記録すべきでない旺：オブジェ
クトの修正に関する情報を記録すべきである ■〃：オブジェクトを修正しないであろうオブジェクト
の外観に関する情報並びに修正に関する情報を記録すべ
きである。
２．１（ａＮ）　　位ｍ−２バイト オブジェクトと関連した言語（例英語）２．１（ａｍ）
　　曲１礼１−１ビットオブジェクトのリンクカウント
が零になると何が起るかを検出する。オブジェクトおよ
びそのレコードが削除されるか、正にレコードが削除さ
れたかのいずれかである。
２．１（ａｎ）　　Ｗ　Ｐ　ｎ　　７５　ニゲ−１ビツ
トオブジエクトがドキュメントライブラリと同期化して
いるか、即ちこのオブジェクトに関する何らかのデータ
がドキュメントライブラリで複写されていないか指すた
めにドキュメントオブジェクトに対して使用する。
２．１（ａｏ）　　プ１ント′＝ 例えば以下のようにオブジェクトのプリントに使用され
る省略時パラメータ ーテキストを開始すべき場所の座標 一方向（ランドスクープまたはポートレート）−フオー
ムの番号 一プリントビン番号 一ペーパサイズ ーオブジェクトの重ね書きが相互のオブジェクトをカバ
ーするか透き通しであるべきか−オブジェクトはクリッ
プ（ｃｌｉｐ）されるべきか、用紙に適合させるために
縮められるべきか−どのプリントがどのシステムに並ぶ
か８．２．２．　ｌンクー−プル リンクテーブルはカタログのオブジェクトを参照したか
、あるいは該オブジェクトによるレコードを含む。１個
のカタログにおけるオブジェクト間のリンクに対して、
２ｆｌ！！ｌのカタログの各々におけるリンクテーブル
にはエントリがある。
２．２（ａ）　　　のパーマネントＩＤ−１２バイト親
のオブジェクトパーマネントＩＤ ２．２（ｂ）　　星偽１１！■６１−２８バイトオブジ
ェクトの現在の位置はそのオブジェクトＩＤ（４バイト
）、それがカタログ化されたボリュームの識別子（８バ
イト）、およびそのボリュームが位置しているシステム
の識別子（１６バイト）である。該システムの識別子は
、それがこのレコードと同じシステムにあるときは零で
ある。ボリュームの識別子はもしそれがこのレコードと
同じボリュームにあれば零である。
２．２（ｃ）Ｗしｚ乙１」−４バイト 親のオブジェクト内で独特のもの、リンクＩＤは親のオ
ブジェクトのリンクマーカに記憶される。
このリンクＴＤが特定のオブジェクトにおけるいずれか
特定のリンクマーカに対応したリンクテーブルからのレ
コードの検索を可能とする。
２．２（ｄ）　　リンクタイプ−１バイト可能の値とし
ては下記を含む。
：ＬＬ：通常の値 バージョンフリンクされたオブジェクトは親のオブジェ
クトのバージョンである 【艮：リンクされたオブジェクトは親のオブジェクトの
コピイである ２、２（ｅ）　　デ：罷−史２ノーー１ビットこのリン
クに対応するリンクパラレルアイルエントリにエントリ
があるか否かセットされる。
２．２（ｆ）　　　　のパーマネントＩＤ−１２バイト 子供のオブジェクトパーマネントＩＤ ２．２（［１）　　　　の　　の１−２８バイト２．２
（１＋）　　子店（７３Ｆニブ−４バイトオブジエクト
のタイプ ２．２（ｉ）　　立式９ノコロｈｔＩ、＝−６４バイト
性能を向上させるためにリンクレコードに保持された子
供のオブジェクトのタイトルフィールドのコピイ ２．２（ｊ）　　１譜ｍ−３２バイト 性能を向上させるためにリンクレコードに保持された子
供のオブジェクトの著者のコピイ２．２（ｋ）　　コピ
イフラッグー１ビットもしセットされると、子供のオブ
ジェクトは親のオブジェクトがコピイされるとコピイさ
れる。
もしセットされていないとすれば、子供のオブジェクト
へのリンクがコピイされる。
２．２（１）　　良！Ｌ−２５２バイトリンクを記述す
るためにユーザが定義しうる自由テキスト ２．２（＋ｓ）　　旧ｊ匹萱とヱグ−１バイトこのリン
クレコードが削除すべきかセットされる。この使用はデ
ータベースシステムの内部へのものである。このため都
合のよいときまでリンクレコードの物理的削除が延期さ
れる。
２．２（ｎ）　　Ｐｉ　　　リンクフラッグ−１ピント
別のボリュームあるいはシステムに対してこのリンクレ
コードをそのコピイと同期すべきかセットされる。
８．２．３．ファイル１ストーーブル フアイルリストテーブルはその主要な部分以外のオブジ
ェクトの各部分に対するレコードを含む。
これらの部分は典型的にはファイルであるが、例えばレ
コードのような何か別のある。リンクパラレルファイル
はこのテーブルにリストされる。
２．３（ａ）　　レコードの−゛事゛　−４バイトこの
ファイルリストのレコードに対する独特の識別子 ２．３（ｂ）　　；ブジエ　）ＩＤ−４バイトこのレコ
ードにおいてそのオブジェクト部分（例えばファイル）
が一部であるオブジェクトのオブジェクトレコードの識
別子。
２．３（ｃ）　　−ブジェクト　　の１互−６４バイト その元の名前空間（例えばファイル名あるいはデータベ
ースの名前とレコード番号との組合せ）におけるオブジ
ェクト部分の名前。
２．３（ｄ）　　遣ｊ≦房と１グー　１バイトその部分
がこのテーブルとは異なるシステムに位置するかセット
される。
８．２．４．フォルダーープル フオｌレダテーブルはオブジェクトテーブルにおける各
フォルダ用のレコードを含む。
２．４（ａ）　　フォル　　ブジエクトＩＤ−４バイト フォルダオブジェクトのオブジェクトＩＤ２．４（ｂ）
　　　　ロケーション−６４バイトこのフォルダにおい
て作成されたオブジェクトを置くべき記憶位置 ２．４（ｃ）　　−ファイルツース−１バイトこのフォ
ルダにおいて作成された全てのオブジェクトのクラス ２．４（ｄ）　　　　ド　ユメン　−　ブーＩ−１バイ
ト このフォルダにおいて作成されたドキュメントオブジェ
クトを置くべきオブジェクトライブラリ８．２．５．フ
ィールドＷＩＴファイルフィールドＷＩＴファイルはオ
ブジェクトテーブルのＷＩＴ（ｒテキストのワード」）
の索引付けされたフィールドにおける各ワードに対する
レコードを含む。
８．２．６．　　ブジエ　トＷＩＴフ　イルオブジェク
トＷＩＴファイルはＷＩＴの索引付けされたドキュメン
トの各ワードに対するレコードを含む。
８．２．７．　　　、シｆ’　　プジェクトーープル削
除したオブジェクトテーブルはオブジェクトＷＩＴテー
ブルにおいて索引付けられそれ以来削除された各オブジ
ェクト用のレコードを含む。
２．７（ａ）　　レコードの−゛！！　　−４バイトレ
コードの一意な識別子 ２．７（ｂ）　　土ブｊう＝ｌΣユ」−４バイト削除し
たドキュメントのオブジェクトテーブルのレコードを識
別する。
８．３　　リンクパーレルファイル ボリュームは多くのリンクパラレルファイルを含むこと
ができる。各プロジェクトに対して、少なくとも１個の
データリンク（リンク仕様を含むリンク）がはめ込まれ
たリンクパラレルファイルがある。リンク平行ファイル
はデータ転送に使用可能のリンクに関する情報を含む。
リンクパラレルファイルは前記リンクを含む各オブジェ
クトに対して存在する。
３（ａ）兜１目＆エニー１バイト リンクが更新されるときを制御する。以下の値を有しう
る。
マニュアル：特にリクエストされると更新が行われる ファーストタイム＝Ｈのオブジェクトの開放毎にせいぜ
い１回更新が行われ、かつ子供のオブジェクトが最初に
アクセスされたとき更新が行われる ダイナミック：子供のオブジェクトが変化する毎に更新
が行われる ３（１））　　−イスプレイモード−１バイトリンクを
示すためにユーザが調べるものを制御する。
デ：二り−ニリンクされたデータが表示される。
アイコン　タイトル：子供のオブジェクトのタイトルと
、および／または子供のタイプのオブジェクトを示すア
イコンが表示される。アイコンまたはタイトルの選択は
アブリゲーションに依存する。
３（ｃ）　　−イスプレイ　゛、−１バイトデイスプレ
ィモードフィールドが、リンクされたデータがユーザに
対して表示されるべきことを指示すると、デイスプレィ
状暦フィールドはリンクされたデータがユーザに対して
表示されるときを制御する。表示しているリンクされた
データに関して多大のオーバヘッドがある可能性があり
、例えばユーザは常、にピクチャがドキュメントに現わ
れるようにすることよりもドキュメントを通して迅速に
スクロールできることを好む、このフィールドによりユ
ーザがこの性能の選好を表現することができる。
土：」二乙ｈノ一二リンクされたデータがユーザ内に入
れば常にリンクされたデータを表示する。
オフ９り９ダ已上−：特にリクエストされたときのみリ
ンクされたデータを表示する。さもなければ、リンクさ
れたデータと親のデータとの関係に応じて、アイコンあ
るいはタイトルのみが表示されるか、あるいはオブジェ
クトが現われると＜ｒｌ’４えばドキュメントにイメー
ジが現われると）空のスペースが表示されうる ３（ｄ）す］ヨー１１！とムグー 各リンク仕様に先行する標準情報は以下のフィールドを
含む： バージョン：８バイト リンク仕様を作成した子供オブジェクトのオブジェクト
マネージャのバージョンを識別する。このため、アプリ
ケーションの改訂を促進し、一方リンク仕様をサポート
する。
ＵＬＬＬＬ＝４バイト 親オブジェクトに通す際それを通して子供のデータが変
換されるフォーマット。
良し：４バイト 後続のリンク仕様情報のバイトの数 ３（ｅ）　　リ受−色壮Ｕ■、−可変長子供オブジェク
トのタイプに細部依存する。このフィールドはリンクに
より参照される子供オブジェクト内のデータを識別する
ために（リンクがその中にはめ込まれているオブジェク
トのオブジェクトマネージャあるいはアプリケーション
統合サービスによるのでなく）子供のタイプのオブジェ
クトのオブジェクトマネージャにより解釈される。
３（ｒ）　　：ン　　れｔ・−一　のコピイー可ｇ：長
リンクされたデータのコピイを含む。
レ オブジェクトマネージャは呼び出しプログラムの子供の
オブジェクトのプロセスとして別のプログラムがオブジ
ェクトマネージャを直接呼び出すことにより呼び出すこ
とができる。しがしながら、オブジェクトマネージャの
呼び出しは典型的には八ＰＰＡＣにの呼び出し機能（例
えば＾Ｐｒｑｅｄｉｔ□、ＡＰｉｎｖｏｋｅＯ）の１つ
を別のプログラムが呼び出すことにより開始される。
２種類のアプリケーションが非標準的なプロトコルを介
してやりとりする必要のないときでさえ、カーネル呼び
出しによる直接呼び出しに対して（専用リクエストを用
いて）＾ＰＩ’ＡＣＫ呼び出しＩＲｆｌｌの使用の選択
の方が利点がある。例えば八ＰＰＡＣＫはアプリケーシ
ョン間のやりとりの設定により高レベルの援助を提供す
る。さらに、２種類の通信アプリケーションは相互から
、双方の連続したオペレーションを独立して分離させる
ことができる。これはへＰＰＡＣＫ呼び出しが用いられ
ると、双方のプロセスがアプリケーションマネージャプ
ロセスの子供であり、２つの通信プロセスの一方が他方
の子供とならないためである。
９．２．スタートアップリクエスト 本発明のシステムはオブジェクトに対して実行しうる多
数の一般的オペレーションをサポートする。、これらの
オペレーションは［スタートアップリクエスト」と称さ
れる。その理由はまず、それらが実行すべきオペレーシ
ョンに対するリクエストとして開始され、第２に各リク
エストがオペレーションあるいはプロセスを開始させる
からである。
本発明のシステムの重要な特徴は、概ねいずれのオペレ
ーションも概ね全てのタイプのオブジェクトに対して実
行しうるよう一組のオペレーションが定義されることで
ある０本発明のシステムのオブジェクトマネージャは、
実用上あるいは有意的に出来るだけ多くの標準的リクエ
ストがオブジェクトの各タイプに対してサポートされる
よう構成されている。ファイルベースのオブジェクトに
対して、標準的リクエストのあるものは＾Ｉ’ＰＡＣＫ
により直接実行しうる。これは、八ＰＰＡＣににより実
行されるファイルベースのオペレーションが不十分であ
る場合、オブジェクトのタイプに対するオブジェクトマ
ネージャによりサポートされるのみでよいのでオプショ
ンのリクエストと称されている。
標準リクエストに加え専用リクエストをサポートするよ
ういずれのアプリケーションも構成しうる。このため、
必要とするどのような特殊のリクエストもどのアプリケ
ーションも定義し、一方へＰＰへＣにによりサポートさ
れた基本的呼び出し機構を用いれるようにする。大量の
オブジェクトタイプに対しても特定の専用リクエストは
一般的にサポートされないので、典型的にはその他のア
プリケーションがそのようなリクエストを出すことはな
い。それにもかかわらず、アプリケーションのある組合
せは特別仕様のリクエストから著しい利点を得て、その
ためそれら自身の特異なリクエストを共に定義し、サポ
ートする。
基本的には、専用リクエストと標準リクエストとの間の
差異はリクエストをサポートするアプリケーションの数
である。特定のアプリケーションの構成者は専用リクエ
ストの定義を広く公表するよう選択しうる。その他多く
の者がリクエストに対応するにはオブジェクトマネージ
ャを修正するに十分有用なリクエストを見出すことがで
きる。
その結果、そのリクエストは事実上の標準リクエストと
なる。
（ＡＰＰＡＣににより典型的には直接実行される「オプ
ションの」リクエストを含む）標準リクエストは以下の
通りである： 鉦薊江：省略オペレーションを実行する。多くのタイプ
のオブジェクトに対して、省略時オペレーションはユー
ザにより編集するようオブジェクトを開くことである。
何らオブジェクトが規定されなければ、典型的な省略時
オペレーションがユーザが新しいオブジェクトを作成で
きるようにする。
凹：ユーザがオブジェクトをｔｉ集できるようにする。
吠机：ユーザがオブジェクトを観察できるが、修正はで
きないようにする。
Ｒｕ＝規定したオブジェクトを実行する。オブジェクト
マネージャは通訳あるいはプログラムローダとして機能
する。
ＰＲＩＮＴニブリントするようオブジェクトを整列させ
る。このリクエストにより規定されたオプションはユー
ザがプリントパラメータと提供するか、あるいは省略時
パラメータを使用すべきかを指示する。
ＵＰＤＡＴＥ　ＬＩＮＫ：特定のリンク仕様により指定
されたデータの最終バージョンを親のオブジェクトに通
信する。もしリンク仕様が有効でなければ、子供のオブ
ジェクトマネージャがウィンドウを開き、ユーザがリン
クを再規定できるようにすべきである。
ＲＥＳＰＥＣＩＦＹ　ＬＩＮＫ：ウィントウを開放シ、
ユーザがリンク仕様を変えれるようにする３子供のオブ
ジェクトマネージャは（現在規定されているデータを示
して）子供のオブジェクトの関連部分を表示し、かつユ
ーザが種々データを規定できるようにする４ ＥＤＩＴ　０ＢＪＥＣＴ　ＰＲＯＦＩＬＥ：ウィンドウ
を開き、ユーザが子供のオブジェクトのブロファ・イル
を編集できるようにする。オブジェクトプロファイルに
含まれている情報の性質はオブジェクトタイプによって
変わる。
ＣＵＳＴＯＭＩＺＥ：ユーザが、リクエストを受取るオ
ブジェクトマネージャの挙動をカストマイズできるよう
にする。修正可能の特性が関連のデータを資源に記憶さ
せている。カストマイズされた資源はこのオペレーショ
ンの結果である。はとんどのプログラムはカストマイズ
可能の挙動オプションを有しておらず、そのためこのリ
クエストをサポートしない。
Ｃ０ＮＶＥＲＴ　０ＩＩＴ：規定されたオブジェクトの
中味全体を提供する。そのようなリクエストを受け取る
と、オブジェクトマネージャは、（情報損失の増える順
序で）提供しうる交換フォーマットのリストを含む、マ
ツチメーカを備えた ＡＰＩ４ＭＯＰＣＯＮＶＥＲＴＯｔｌＴオヘＬ／　−シ
９７を通知する。
ＣＱＨｖＥＲＴ　ＩＮ：新しいオブジェクト受取りデー
タを作成する。そのようなリクエストを受け取ると、オ
ブジェクトマネージャはく情報損失の増える順序で）受
け入れ可能交換フォーマットのリストラ含ム、マツチメ
ー力ヲ備；ｔ　タＡＰＮＮＯｆ’ＣＯＮＶＥＲＴｒＮオ
ペレーションを通知すべきである。次いで、マツチメー
カによりマツチメ・ンセージが発行され、２個のオブジ
ェクトマネージャ間の接続が作られデータを転送する。
Ｃ０ＮＰＡＣＴ　：規定されたオブジェクトにおけるデ
ータ記憶をコンパクトにする。少なくともメ・ｙセージ
の完了、あるいはエラーメツセージの確認を含むブレテ
ィン（ｂｕｌｌｅｔｉｎ）をリクエスト元へ送る。
ＲＥＣＯＶＥＲ：規定されたオブジェクト内のデータ記
憶を回復する。メツセージの完了あるいはエラーメツセ
ージの確認を含むブレティンをリクエスト元へ送る。
ＷＯＲＤ　ＬＩＳＴ：オブジェクトにおける全てのワー
ドのリストをコンパイルし、ブレティンをリクエスト元
へ送る。ワードはバニラテキスト交換フォーマットを用
いて戻される。それらの順番はフレーズオリエンティラ
ドな索引付けのサポートに重要である。
ＣＲＥＡＴＥ　：　（オプション） 新しいオブジェクトを作成する。
刈上：（オプション） 既存オブジェクトのコピイを作成する。
ＲＥＮＡＨＥ　：　（、オプション） オブジェクトのユーザの可視の名前を変更する。
ＤＥＬＥＴＥ　：　（オプション） オブジェクトを削除する。
ＦＲＥＥＺＥ　：　（オフ　ショ：／　）オブジェクト
を凍結する（例えば、オブジェクトテーブルのオブジェ
クトのレコードのフィールドを修正する） ＩＭＰＯＲＴ：（オプション） 既存ファイルを取り上げオブジェクトとする。
９．３．＾ＰＰＡＣＫによる　び　し ＡＰＰＡＣにによるオブジェクトマネージャの呼び出し
を用いることに係るステップの順序は一般的に次の通り
である。
（ａ）　　リクエスト元が、リンクを識別してへＰＰＭ
ＣＫ開始リクエストルーチンの１つを呼び出す（特に汎
用＾Ｐｉｎｖｏｋｅ□機能が用いられた場合より多くの
パラメータが規定しうる）。
（ｂ）　　八ＰＰＭＣにルーチンがリクエストをリクエ
スト元のメイルボックス名と共にアプリケーションマネ
ージャプロセスへ送る。
（ｅ）　　アプリケーションマネージャは（オペレート
すべきオブジェクトのタイプに基き）リクエストをハン
ドルする必要のあるオブジェクトマネージャはどれか規
定し、かつどのリクエストを規定すべきかを決め、必要
とされたオブジェクトマネージャの例を実行する新しい
プロセスをつくる（これがこのオペレーションにおける
「サーバ」である）。
（ｄ）　　新しく呼び出されたオブジェクトマネージャ
の初期設定の一部として、アプリケーションマネージャ
にそのリクエストと関連の情報とを散層する。
（ｅ）　　そのリクエストが受け入れ可能であれば、サ
ーバは、オペレーションを進行すべきことを示して、（
データは常にコンシューマに対するサーバの方向に流れ
る必要はないが、コンシューマとしても知られる）リク
エスト元へ答えを送る。もしリクエスト元により規定さ
れたり、あるいはリクエストの性質が絶対的なものであ
れば、リクエスト元とサーバとの間が接続される。
（ｆ）　　もしデータに対してリクエストがなされたと
すれば、データ交換が前記接続を通して実行される。ア
プリケーションマネージャはもはやインタラクシジンの
一部ではなくなる。
（ｇ）　　リクエスト元とサーバとがオペレーションを
終了すると、それらは接続を停止する。
八ＰＰＭＣにルーチンはリクエストの発信の細部を損う
、前記ルーチンは通信に使用されるメイルボックスを定
義し、それ自身のメツセージを作り、特にリクエスト用
ルーチン（例えば＾ＰｒｑｐｒｉｎｔＯ２であって、Ａ
ＰｉｎｖｏｋｅＯではない）への呼び出しの場合呼び出
しを完了させるために（かつある場合には通信、が何ら
必要とされない場合はオペレーションを完了させるため
に）必要な事象の処理の全てを実行する。呼び出された
へＰＰＭＣＫスタートアップ（ｓｔａｒｔｕｐ）機能が
復帰すると、オペレーションは中断するか、あるいは新
しいオブジェクトマネ−ジャが開始され満足のいく答え
を出している０通信が要求されるとすれば、リクエスト
元とサーバとは各々、さらに別の通信で用いる共通のオ
ペレーションＩＤが提供される。オペレーションが終了
すれば、双方が＾ＰｏｐｆｉｎｉｓｂＯを呼び出す。
標準的機能のいずれかをサポートするオブジェクトマネ
ージャが開始され、（リクエストが何らユーザインタラ
クションを含まないこともあるので）ウィンドウを開く
前に、＾ＰｉｎｔＯを呼び出しスタートアップリクエス
トとパラメータとを取得すべきである０次いで、オブジ
ェクトマネージャはリクエストを受けうるか決定すべき
かであって、このことは典型的には、規定されたオブジ
ェクトを開き、リンク仕様を有効にする（これはリクエ
スト元が依然として答えを待っているので、迅速にすべ
きである）ことを含む、もしリクエストを受けえないと
すれば、オブジェクトマネージャは（リクエストを拒否
する理由をつけて）＾ＰｒｅｐｌｙＯを呼び出し、かつ
クリヤにして出ていくべきである。もしリクエストを受
けつけできるならば、このことが＾ＰｒｅｐｌｙＯを用
いて報告されるべきである。リクエスト元との通信が必
要とされれば、リクエスト元からのメツセージを待機し
、その後オペレーション特有の通信が進行する。もしオ
ペレーションがリクエスト元との通信を必要しないとす
れば、オブジェクトマネージャはオペレーションを完了
させるよう進行し、完了すると＾Ｐｏｐｆｉｎｉｓｈ□
を用いて状態を報告すべきである。
１０、　　ブジェ　　マネージャ　　３゛特定オブジエ
クトにオペレートすべく呼び出された特定のオブジェク
トマネージャはオブジェクトタイプによって変わり、か
つさらに実行すべきオペレーションのタイプによって変
わり、例えばワード処理のような言語依存型オペレーシ
ョンにおいてはオペレートすべきオブジェクトで用いら
れる特定の言語によって変わりうる。
第３図を参照すれば、テーブルのデータフィールドのあ
るものを示すオブジェクトマネージャテーブル２５６の
線図が示されている。オブジェクトマネージャテーブル
２５６は複数のオブジェクトマネージャテーブルのエン
トリ５００から構成されている。各オブジェクトマネー
ジャテーブルのエントリ５００の方はオブジェクトタイ
プ、オペレーションのタイプ、即ち前記オブジェクトタ
イプに対して実行すべきリクエスト、適用可能なら言語
および特定のリクエストを実行すべき対応するオブジェ
クトマネージャの識別との組合せに対応する。
各オブジェクトマネージャテーブルのエントリ５００は
オブジェクトタイプフィールド５０２、リクエストフィ
ールド５０４およびオブジェクトマネージャ識別子フィ
ールド５０６とを含む。
前記フィールドの各々を検討すれば、オブジェクトタイ
プフィールド５０２はオブジェクトタイプコードを含む
。リクエストフィールド５０４の方はオブジェクトマネ
ージャテーブルエントリ５００で識別されたタイプのオ
ブジェクトに対して、あるいは関連して実行しうるオペ
レーションに対応するコードを含む。最後に、オブジェ
クトマネージャＩＤフィールド５０６は、特定のオブジ
ェクトに対してリクエストされたオペレーションを実行
するよう呼び出された特定のオブジェクトマネージャの
ファイル名を含む。
オブジェクトマネージャテーブルは以下のように使用し
うる。ユーザに対してオブジェクトを表示するためにオ
ブジェクト１つにおいてデータを読取る過程においてオ
ブジェクトマネージャはリンクマーカを見い出しうる。
リンクマーカはリンクＩＤを含む、このリンクＩＤはリ
ンクマーカがはめ込まれたオブジェクト（このリンクに
関する「親の」オブジェクト）のパーマネントＩＤと共
にリンクテーブルにおいてそのリンクと対応するレコー
ドを探索するために使用しうる。このリンクレコードは
リンクされたオブジェクトのタイプを識別するフィール
ドを含む（オブジェクトテーブルへのキーとしてリンク
レコードにおいて子供のパーマネントＩＤを用いること
により子供のオブジェクトのオブジェクトタイプを取得
しうるので、このフィールドは必要とされない）、子供
のオブジェクトに対するこのタイプコードは［デイスプ
レィ」のリクエストのコードと共にオブジェクトマネー
ジャテーブルにおけるレコードを識別するために使用さ
れる。そのレコードのオブジェクトマネージャＩＤはリ
ンクされたオブジェクトに対して必要とされるデイスプ
レィオペレーションを実行しうるプログラム用のファイ
ル名である。
１１、　　ブジェクトプロトタイプーーブル　４第４図
を参照すれば、オブジェクトプロトタイプテーブル２５
８は本システムに取り付けられたオブジェクトの各タイ
プの記憶した１０トタイプコピイをアクセスする手段を
提供する。第４図に示すように、各プロトタイプテーブ
ル２５８は複数のオブジェクトプロトタイプエントリ６
００より構成され、各オブジェクトプロトタイプエント
リ６００は単一のユニークなオブジェクトプロトタイプ
に対応する。
各オブジェクトプロトタイプエントリ６００はオブジェ
クトタイプフィールド６０２、言語フィールド６０４お
よびプロトタイプ識別子フィールド６０６から構成され
ている。オブジェクトタイプフィールド６０２と言語フ
ィールド６０４とがオブジェクトプロトタイプエントリ
６００をアクセスする「キー」を構成し、一方プロトタ
イプＩＤフィールド６０６は、各キーに対して、対応す
るプロトタイプオブジェクトを識別するためにオブジェ
クトプロトタイプエントリ６００から読出した情報を含
む、前記フィールドの各々を検討すれば、オブジェクト
タイプフィールド６０２は、そのプロトタイプがオブジ
ェクトプロトタイプエントリ６００により識別されるオ
ブジェクトのタイプの識別子を含む、言語フィールド６
０４の方は、そのプロトタイプがオブジェクトプロトタ
イプエントリ６００により識別されるオブジェクトのタ
イプの特定バージョンが言語依存型である場合の特定の
言語を識別するコードを含む０例えばドキュメントオブ
ジェクト、およびしたがってそれらのプロトタイプが、
第１のタイプが英語のドキュメント、第２のタイプが独
語のドキュメントおよび第３のタイプが仏語のドキュメ
ントというように区別される数種のドキュメントタイプ
オブジェクトのプロトタイプがありうる。
最後に、プロトタイプＴＤフィールド６０６は、そのタ
イプのオブジェクトのプロトタイプコピイを含むファイ
ルのファイル名を含む。
ユーザは例えばメニューピック（＋ｍｅｎｕ　ｐｉｃｋ
）を介してオブジェクトタイプと、および可能ならオブ
ジェクトの言語バージョンを識別することにより所定タ
イプの新しいオブジェクトを作成しうる。
次いでオブジェクトタイプ識別子と言語コードとがオブ
ジェクトプロトタイプテーブル２５８で対応するオブジ
ェクトプロトタイプエントリ６００を探すキーとして用
いられ、対応するプロトタイプオブジェクトを含むファ
イルの名前がオブジェクトプロトタイプエントリ６００
から読みとられる０次いでファイルコードユーティリテ
ィを呼び出すために１０トタイプファイル名が使用され
、前記ユーティリティの方はプロトタイプの新しいコピ
イを作る。新しいオブジェクトに対するエントリが次い
でオブジェクトテーブルにおいて作成される。
ユーザは次いで、そのオブジェクトタイプのオブジェク
トマネージャを呼び出し、そのオブジェクトに対してオ
ペレートするかあるいはそのオブジェクトタイプのプロ
ファイルエディタを呼び出し、必要に応じ、あるいは希
望に応じ新しく作成されたオブジェクトをカストマイズ
できる。もしユーザが新しいオブジェクトタイプの作成
を希望していたとすれば、ユーザは適当なプロファイル
エディタを用いて必要に応じ、あるいは希望に応じ新し
く作成されたオブジェクトのプロファイルをカストマイ
ズし、あるいはプロトタイプで所望されているデータを
入力しうる。次いで、ユーザはユーティリティを呼び出
して新しいオブジェクトタイプに対応する新しいオブジ
ェクトプロトタイプエントリ６００を作成し、かつこの
新しいオブジェクトプロトタイプエントリ６００をオブ
ジェクト１０トタイブテーブル２５８に位置させる。次
いで、ユーザは新しいタイプの新しいオブジェクトを前
述のオペレーションを介して意のままに作成しうる。
第５図を９照すれば、オブジェクトカタログ２５２の構
造と編成とが示されている。オブジェクトカタログ２５
２はオブジェクトテーブル２６０、リンクテーブル２６
２およびファイルリストテーブル２６４とを含むものと
して示されている。これらはオブジェクトと、オブジェ
クトへのリンクについての情報を含む。
第６図を参照すれば、オブジェクトテーブル２６０は１
個以上のオブジェクトレコード３６０から構成されてい
る。オブジェクトカタログ２５２に含まれた各オブジェ
クトに対して１個のオブジェクトレコード３６０がある
。各オブジェクトレコード３６０は、オブジェクト識別
子３６２、オブジェクトタイプコード３６４およびオブ
ジェクト位置の指示３６６とを含む複数のフィールドに
編成された情報を含む。
第７図を参照すれば、リンクテーブル２６２は１個以上
のリンクレコード３フＯから構成されている。
オブジェクトテーブル２６０でカタログ化されたオブジ
ェクトへ、あるいはそこからの各リンクに対して１個の
リンクレコード３７０がある。各リンクレコード３７０
は、親のオブジェクト識別子３７２、リンク識別子３７
４、子供のオブジェクト識別子３７Ｂ、リンクタイプコ
ード３７８、データリンクフラッグ３８０およびコピイ
フラッグ３８２とを含む複数のフィールドに編成された
情報を含む、また、子供のオブジェクトの現在の位置も
リンクテーブル２６２に記憶しうる。
コピイフラッグフィールド３８２は親のオブジェクトの
識別子３７２によって識別されたオブジェクトをコピイ
するために使用される。親のオブジェクト４００のコピ
イが作られると、リンクを親のオブジェクトと共にコピ
イするか、あるいは子供のオブジェクト識別子３７６に
より識別されたオブジェクトのリンクされたデータをコ
ピイする必要がある。リンクまたは、リンクにより参照
されるデータがコピイされるか否かはコピイフラッグフ
ィールド３８２の状態によって決まる。
本発明のシステムにおいて、採用された規則は、もしリ
ンクされたオブジェクトが親のオブジェクトの内部から
作成されたとすれば、子供のオブジェクト即ちそこから
リンクされたデータはコピイされるか、あるいはリンク
がコピイされるということである０例えばもしユーザが
チャート（図表）を用い、そのためドキュメントタイプ
の親のオブジェクト内からの、あるいはその部分として
のチャートタイプの子供のオブジェクトは親のオブジェ
クトと重複するとすれば、親のオブジェクトのコピイは
チャートの新しいコピイを含む。
チャートのこのコピイは親のオブジェクトのコピイと同
様、原始バージョンと独立して修正しうる。
しかしながらもしリンクが以前に存在していた親のオブ
ジェクトと以前存在していた子供のオブジェクトとの間
で作成されたとすれば、子供のオブジェクトのリンクさ
れたデータよりもむしろリンクの方がコピイされる。
１２．１．　　　ロ　　−パブロセス 本発明の好適実施例においては、オブジェクトカタログ
はホストコンピュータあるいはファイルサーバ（例えば
第１Ａ図、第１Ｂ図および第１Ｃ図のそれぞれ１７０，
１１６または１５６）に対して実行するカタログサーバ
１９０を用いて実施される。前記ホストコンピュータは
中央の大容量メモリ（例えば、１７２，１１０，１１４
）を支配する０代案は記憶されたカタログデータへの直
接アクセスをカタログからの情報を必要とする（あるい
はカタログに情報を追加する）各プロセスが出来るよう
にさせることである。
カタログサーバを用いることの利点のあるものは以下の
通りである。カタログサーバはカタログファイルを常に
開放しうるよう連続的に使用されるプロセスであって、
カタログサーバの使用によりカタログにアクセスする各
々の個別プロセスに対してカタログを開けておく必要性
を排除する。
同様に、カタログサーバは、さもなければさらに実行が
困難となるバッファリングを提供しうる。
カタログへのアクセスを必要として個々のプロセス全部
が記憶されたカタログデータへの直接アクセスを提供さ
れたとすれば、カタログの効果的な機密性を実行するこ
とが困難で、カタログサーバを使用することにより機密
性を向上させることができる。
１３．１ン　お　び１ンクバーレルフアイル　８前述の
ように、本システムにおける全ての情報、データおよび
プログラムはオブジェクト内に含まれ、オブジェクトの
方はリンクを介して相互眸関連する。リンクは、「子供
」のオブジェクトと称される一方のオブジェクトが「親
」のオブジェクトと称される他方のオブジェクトに接続
される手段と見做すことができる。各オブジェクトは典
型的には少なくとも１個のリンクに対して子供である。
例えば、各ユーザは少なくとも１個の一次フォルダオブ
ジェクト即ちフォルダを有し、該フオルダにはユーザが
直接あるいは間接的にリンクされる。
いずれの数のオブジェクト、あるいはオブジェクトの部
分もリンクを介して相互に継ぐことができ、リンクの順
序および方向は階層的に限定されない。
子供のオブジェクトを親のオブジェクトに結合すること
の他に、リンクはまた、子供のオブジェクトのデータの
全て、あるいは一部を親のオブジェクトに結合するなめ
にも使用しうる。子供のオブジェクトから親のオブジェ
クトへのデータの結合は、結合されるデータが親のオブ
ジェクトの一体部分となるのではなく、子供のオブジェ
クトの一部のままであるという点において一方のオブジ
ェクトから他方のオブジェクトへデータをコピイするこ
とは区別される。後述のように、リンクされたデータは
子供のオブジェクト内のみで、子供のオブジェクトタイ
プに指定したオブジェクトマネージャによってのみ編集
しうる。
さて第８図を参照すれば、リンクパラレルファイル２６
６と、子供のオブジェクト４０４からの（子供のデータ
４０６の）リンクされたデータ４０７が親のオブジェク
ト４００に統合されている親のオブジェクト４００と子
供のオブジェクト４０４との間のリンクとが示されてい
る。第８図に示され、かつ以下説明するリンク構造とリ
ンクパラレルファイル２６６とはまた、リンクパラレル
ファイルが含まれていないことおよび子供のオブジェク
トに何らリンクされたデータの無いことを除いて（例え
ばオブジェクトをフォルダタイプオブジェクトに結合す
る場合）非データリンクのリンクにも適用されることに
注目すべきである。
第８図に示すように、リンクの主要エレメントとしては
、親のデータ４０２を含む親のオブジェクト、子供のデ
ータ４０６を含む子供のオブジェクト４０４および少な
くとも１個のリンクパラレルファイルのエントリ４０８
を含むリンクパラレルファイル２６６とを含む。
親のオブジェクト４００にリンクすべき子供のデータ４
０６の部分はリンクされたデータ４０フとして子供のデ
ータ４０６において示され、このリンクされたデータ４
０７が親のデータ４０２にリンクすべき位置は親のオブ
ジェクト４００におけるリンクマーカ４２０の１つであ
るリンクマーカ４２０ａによって示されている。
まず親のオブジェクト４００、特に前述のリンクマーカ
４２０＆を参照すれば、各リンクマスクは対応する他の
オブジェクト、あるいは別のオブジェクトのデータがそ
こを通して例えば親のオブジェクト４００のような親の
オブジェクトにリンクされる関連リンクへの基準である
。各リンクマーカは、親オブジェクト内の対応するリン
クを独特の方法で識別するリンクＩＤを含む。さらに、
各リンクマーカは、リンクされた子供のオブジェクトあ
るいは子供のオブジェクトからのリンクされたデータが
「現われる」族オブジェクトでの個所をマークする。
族オブジェクト４００のリンクパラレルファイル２６６
は族オブジェクト４００にはめ込まれた各データリンク
用のリンクパラレルファイルエントリ４０８を含む、こ
れらリンクパラレルファイルエントリ４０８の各々は、
族オブジェクト４００に現われるべき子供オブジェクト
のデータを識別する情報を含む。
リンクプロフィルフィールド４２２はリンクとリンクさ
れたデータの状態に関するある基本的情報を提供する。
特に、リンクプロフィルフィールド４２２は、フィール
ドの更新状態、デイスプレィモードおよびデイスプレィ
状態とを含む、族オブジェクト４００におけるリンクと
リンクされたデータとの外観と作用とに関する情報を含
む。
更新状態フィールドの値は、いつ対応するリンり２３６
が更新されるか、即ち子供オブジェクト４０４の新しい
現在のコピイ並びに子供オブジェクト４０４からのリン
クされたデータが取得され、親オブジェクト４００に提
供されるかを決める。リンクのこの更新は自動的に、即
ちユーザが何ら干渉することなく行われ、ある事象が発
生すると、即ちユーザがリクエストしたときのみマニュ
アルとなるか、あるいはそれらの組合せとなる。
自動更新に対して更新状態フィールドが設定されると、
親オブジェクト４００のオブジェクトマネージャは、親
オブジェクトのオブジェクトマネージャが決めるときに
、子供オブジェクト４０４のコピイである子供オブジェ
クトのデータを自動的に取得し、−時的に記憶させるこ
とができる。このことは例えば、リンクされたデータ４
０７を表示あるいはプリントする毎、あるいは親オブジ
ェクト４００が開始する毎、即ち親オブジェクト４０Ｇ
に対するオペレーションの開始時に発生する。また、本
システムはダイナミック更新即ち、子供オブジェクト４
０４に対するオペレーションにより更新が開始され、そ
のため子供オブジェクト４０４における変化が、子供オ
ブジェクト４０４が変ると親オブジェクト４００に自動
的に現われる。しかしながら、マニュアル更新にマニュ
アル状態フィールドが設定されると、リンクはユーザに
より特別のリクエストあるいは指令のときのみ更新され
る。
デイスプレィモードフィールドはセット可能のフィール
ドを含み、該フィールドは対応するリンクを親のオブジ
ェクト４００で表示する態様を選択できるようにする。
オブジェクトのタイトル、オブジェクトのタイプを示す
アイコン、子供オブジェクトのデータを示すことにより
、あるいはこれらをいずれか組合せることによりリンク
を示すことができる。
デイスプレィ状態フィールドをセツティングすることに
より、親オブジェクト４００でデータ用にとっておいた
領域が例えばＣＲＴデイスプレィのような可視表示でユ
ーザ（二見えると、下記するリンク仕様に含まれている
データが自動的に表示されるか否か検出する。デイスプ
レィ状態フィールドが「自動デイスプレィ」にセットさ
れると、リンクされた子供オブジェクト４０４のデータ
が、親オブジェクト４０Ｇの領域がユーザに見えてくる
と常に表示される。デイスプレィ状態フィールドがｒオ
ン・コマンド（指令）デイスプレィ」にセットされると
、リンクされた子供オブジェクト４０４のデータが、ユ
ーザによるデイスプレィに対する特別の指令が出るとき
のみデイスプレィされる。もしユーザが「オン・コマン
ド・デイスプレィＪモードにある間にリンクされたデー
タをデイスプレィせよとの指令を出さないとすれば、リ
ンクは例えばリンクされた子供オブジェクト４０４のデ
ータにとっておいた領域の外形と、例えばアイコンある
いはリンクのタイトルのようなリンクされた領域の短い
指示とにより表示される。デイスプレィ状態フィールド
のセツティングと作用とは、もしデイスプレィモードフ
ィールドがリンクされたデータを表示しないよう、即ち
リンクをタイトルあるいはアイコン、あるいはタイトル
とアイコンの組合せによってのみ表示するようセットさ
れると適用できないことに注目すべきである。
リンク仕様フィールド４３８は、リンクプロファイルフ
ィールド４２２で述べたように親オブジェクトのリンク
の表示と作用よりもむしろ子供オブジェクト４０４から
のリンクされたデータを記述する情報を含む。
リンク仕様フィールド４２２に含まれた情報は、子供オ
ブジェクト４０４からのリンクされたデータ（リンクさ
れたデータ４０７）が親オブジェクトで表示され、かつ
使用される態様を決めるために、親オブジェクト４００
のオブジェクトマネージャでなく、むしろ親オブジェク
トにより使用される。対照的に、以下説明するように、
リンク仕様フィールド４３８の情報がリンクパラレルフ
ァイルのエントリ４０８で提供され、そのため親オブジ
ェクト４０Ｇと関連するが、その中の情報は親オブジェ
クトのオブジェクトマネージャにより使用されない、そ
の代りに、リンク仕様フィールド４３８の情報は、いず
れの子供オブジェクトのデータが親オブジェクト４００
にどのような形態で提供されるか検出するために子供オ
ブジェクトのオブジェクトマネージャにより用いられる
。この目的に対して、リンク仕様フィールド４３８に常
駐する情報が、前述のようにリンクが更新される毎に＾
ＰＰＡＣＫ２１８更新ルーチンにより子供オブジェクト
のオブジェクトマネージャに戻される。子供オブジェク
トのオブジェクトマネージャが次いでこの情報を解釈し
て、リンク仕様によりどの子供オブジェクト４０４のデ
ータが示されるか、どのような形態でリンクされたデー
タが親オブジェクト４００に提供されるか検出し、かつ
期待した形態でリンクされたデータを親オブジェクト４
００へ提供する。
リンク仕様フィールド４３８を参照すれば、これはそれ
ぞれヘッダフィールドとリンク仕様情報フィールドと称
される２ブロツクのフィールドから構成されている。ヘ
ッダフィールドは主として子供オブジェクト４０４の記
述する情報を含み、一方リンク仕様情報フィールドは子
供オブジェクトのリンクされたデータを記述する情報を
含む。
第６図に示すように、まずヘッダフィールドを参照すれ
ば、該ヘッダフィールドはバージョンのフィールドと、
長さのフィールドと、および交換タイプのフィールドと
を含む。バージョンフィールドは元々リンク仕様を作成
した子供のオブジェクトマネージャの特定バージョンを
識別する。長さのフィールドはリンク仕様データの長さ
を指示する。交換タイプフィールドは子供オブジェクト
から親オブジェクトまで、リンクされたデータをやりと
りする上で使用すべきデータ交換フォーマットを示す。
交換タイプフィールドに関して、オブジェクトの各タイ
プは異なるタイプあるいは異なるデータのフォーマット
を有することがある。したがって、リンクの子供オブジ
ェクト４０４と親オブジェクト４００とは異なった形態
のデータを有することが可能である０例えば、ピクチャ
、チャートあるいは図面のようなピクチャあるいはグラ
フィック（図形）データはグラフィックタイプの子供の
オブジェクトからドキュメントタイプの親のオブジェク
トへリンクできる。多くの場合、リンクされたデータは
親オブジェクトにおけるものと同じタイプのものでよく
、あるいはデータが子供データタイプから、情報を包か
、あるいは全く損失することなく親のデータタイプまで
部分的あるいは完全に変換しうるに十分類似でよい。し
かしながら、その他の場合、リンクされたデータは、親
オブジェクトで直接使用可能のタイプに容易には変換し
えない。
オブジェクトの間でのデータの変換は、原始オブジェク
ト即ち子供オブジェクトのデータのタイプと宛て先の、
即ち親のオブジェクトのデータのタイプとによって左右
される。もしデータタイプが同一あるいは十分近似であ
るならば、データは直接変換され、データをほとんど、
あるいは全く変換せず、即ち情報をほとんど、あるいは
全く損失することなく宛て先オブジェクトにおいて直接
使用することができる。しかしながら、もしデータタイ
プが十分具なっているとすれば変換は困難であり、ある
いはデータは宛て先オブジェクトにおいて直接即ち宛て
先オブジェクトのデータの一体部分として使用すること
ができない。この場合、ある程情報損失があり、かつ後
述するように原始オブジェクトのデータは出来るだけ良
く、宛て先オブジェクトのデータに「はめ込む」必要が
ある。
オブジェクト間のデータ交換は「マツチメーカ」と称す
る八ＰＰＭＣにファシリティの援助を得て達成すること
ができる。マツチメーカはデータ交換オペレーションの
２個所の終りに関連した２個のオブジェクトマネージャ
が相互に識別し合い、かつ共通のデータ交換フォーマッ
トを識別しやすくさせるために使用される。
さて、リンク仕様情報フィールドを参照すれば、これら
のフィールドは前述のように子供オブジェクト４０４か
らリンクすべきデータを記載している。
リンク情報フィールドの特定の構造はオブジェクトのタ
イプによって左右される。一方のフォーマットにおいて
、リンク情報フィールドは、例えば子供データ４０６に
おけるリンクされたデータ４０７の始めを指示し、かつ
リンクされたデータ４０７内に含まれた子供データ４０
６の部分と識別するデータ識別フィールドとを指示する
ことにより子供デ−夕４０６でのリンクされたデータ４
０７の位置を指示する位置フィールドを含む。
子供データ４０６は、リンクされたデータ４０７が親オ
ブジェクト４００にリンクされた後で編集、あるいは変
更または修正が可能であり、かつ子供オブジェクト４０
４の変更はリンクされたデータ４０７の位置や識別に影
響を与えうろことを注目すべきである。したがって、リ
ンクされたデータ４０７の位置や識別が指示される態様
、即ち位置フィールドやデータ識別フィールドに位置す
べく選択した情報のタイプは出来るだけ子供データ４０
６に対する変更に敏感でないことが必要である。リンク
されたデータ４０７が位置され、かつ識別される態様は
リンクされたデータ４０７あるいはリンクされたデータ
４０７を囲む子供のデータ４０６がリンク仕様を無効に
することなく変化できるようにするか、あるいは子供オ
ブジェクト４０６のオブジェクトマネージャが変更のな
された後リンクされたデータ４０７の位置や識別の再設
定できるようにさせる０例えば、位置フィールドとデー
タ識別フィールドとに記憶されている情報は、子供デー
タ４０６の領域に対するリンクされたデータ４０７の識
別された領域を位置づけることができる。さらに、デー
タ識別はリンクされたデータ４０フでのカーソルの初期
位置を含むことを注目すべきである。
最後に、リンクパラレルファイルのエントリ４０８の最
後のフィールドを参照すれば、リンクパラレルファイル
エントリ４０８はリンクされたデータのコピイフィール
ド４５８を含むことが示されている。
前述のように、子供オブジェクト４０４からのリンクさ
れたデータは、アイコン、タイトルあるいはリンクされ
たデータ自体、あるいはこれらのいずれかの組合せによ
り親オブジェクト４００においてユーザに表示されうる
。リンクされたデータコピイのフィールド４５８は、リ
ンクされたデータがアイコンあるいはタイトルとの組合
せ如何を問わずデータ自体により可視表示される場合に
、子供オブジェクト１０４からのリンクされたデータの
コピイを記憶する手段である。リンクされたデータがユ
ーザに可視表示される際表示されるのはリンクされたデ
ータコピイのフィールド４５８に記憶されたリンクされ
たデータのコピイである。リンクされたコピイがアイコ
ンあるいはタイトルのみにより表示されると、リンクさ
れたデータコピイのフィールド４５８は何らデータを含
む必要はない。
リンクが形成され、リンクが更新される毎にリンクされ
たデータの新しい現在のコピイが子供のオブジェクト４
０４から受取られ、リンクされたデータコピイのフィー
ルド４５８に記憶される。
第８図にはまた、リンクテーブル２６２とオブジェクト
テーブル２６０とのリンクに対する役割も示されている
。リンクマーカ４２０ａと親オブジェクト４００のＩＤ
とがリンクテーブル２６２のエントリを探すために使用
される。このエントリは、子供オブジェクト４０４に対
応するオブジェクトテーブルにおけるエントリを探すた
めに使用する子供識別情報を含む、オブジェクトテーブ
ル２６０におけるこのエントリは子供オブジェクト４０
４を探すために使用する情報を含む。
１４、コピイ　　　および北 本発明によるシステムにおいて実施可能のコピイ、移動
および共用オペレーションについての以下の説明は、先
に説明してきたこれらオペレーションの局面を要約し、
さらにこれらオペレーションの別の局面を説明するもの
である。前記オペレーションについての以下の説明は、
種々オブジェクトの間でのコピイ、移動および共用オペ
レーションに特に関するものであることを注目すべきで
ある。これらのオペレーションは単一のオブジェクト内
で実施可能であるが、共用オペレーションを除いて、あ
るオブジェクト内でオペレーションが実施される正確な
方法と手段とは、関連のオブジェクトマネージャにより
決定される。しかしながら。
オブジェクト内のデータの共用は、全てのオブジェクト
マネージャがオブジェクト間の共用をサポートする訳で
はないが、オブジェクト間の共用と同じ要領で、かつ同
じ手段により実行される。
本発明によるシステムにおけるコピイ、移動および共用
オペレーションは本システムのユーザにとっては、原始
オブジェクトからのデータのコピイが各オペレーション
において宛て先オブジェクトに現われる点で基本的に類
似に見えるであろう。
コピイと移動オペレーションは、原始データのコピイが
宛て先オブジェクト「内に位置され」かつ下記するある
例外内で、宛て先オブジェクトの一部となる点で類似で
ある。コピイと移動オペレーションとの主たる相違は、
移動オペレーションにおいて、原始データは原始オブジ
ェクトから削除され、一方コピイオペレーションにおい
て原始データが原始オブジェクトにおいて不変のまま残
る。コピイと移動オペレーションとは以下説明するよう
に、コピイされたデータあるいは移動されたデータが宛
て先オブジェクトにおいて、該宛て先オブジェクトのオ
ブジェクトマネージャがコピイされ、あるいは移動され
たデータのタイプに対してオペレート出来る程度まで宛
て先オブジェクトにおいてオペレートできるという点で
さらに類似である。
一方のオブジェクトから別のオブジェクトへのデータの
共用は、共用されたデータが親のオブジェクトの一体部
分となるのでなく子供オブジェクトの一部として留まる
という点で一方のオブジェクトから別のオブジェクトへ
のデータのコピイや移動とは区別される。共用されたデ
ータはリンクにより親のオブジェクトで利用可能とされ
る。共用されたデータは子供オブジェクト内でのみ、か
つ子供オブジェクトタイプに指定されたオブジェクトマ
ネージャのみによって編集可能である。
共用は、リンクが「更新」されうるためデータのコピイ
あるいは移動とさらに区別される。コピイあるいは移動
オペレーションに対してそのような進行中のキャラクタ
はない。共用オペレーションから生じるデータは後のリ
ンク更新オペレーションにより変化しうる。宛て先オブ
ジェクトをオペ、レートする毎、例えば開放したり１表
示したり、編集したり、あるいはプリントする毎に更新
するようリンクをセットしうる。あるいは原始オブジェ
クトが修正されれば常に更新するようリンクをセットし
てもよい。あるいは、リンクはマニュアルで更新するよ
うセットしてもよく、この場合共用されたデータは更新
が特にリクエストされるまで効果的に「凍結」される。
コピイと移動とは、コピイあるいは移動されたデータを
含む宛て先オブジェクトの部分に対してコピイあるいは
移動オペレーションが実行されると、宛て先オブジェク
トに常駐しているコピイあるいは移動されたデータが処
置されるという点において共用とさらに相違する。即ち
、コピイあるいは移動されたデータはデータタイプに関
し以下さらに説明する限度内で宛て先オブジェクトの一
部として処理され、宛て先オブジェクトにおける他の原
始部分と同じ要領でコピイあるいは移動しうる。この点
に関して、データ交換に関し前述したように、データ交
換フォーマットはデータ交換のデータ流れの間データタ
イプを変えるための配備はしであることに注目すべきで
ある。即ち、宛て先オブジェクトのそれとは異なるタイ
プの先にコピイあるいは移動したデータは、コピイある
いは移動されつつある宛て先オブジェクトの部分にはめ
込まれているのが判る。そのような場きに、前述のよう
に本発明のシステムにおけるデータストリームの転送に
採用した規則では、マツチメーカ８１０のオペレーショ
ンにより定義されるデータストリーム用の初期交換タイ
プあるいはデータフォーマットがあることである。別の
データタイプが例えばリンクマーカあるいはリンクされ
たデータのようなストリームへ挿入されるとすれば、デ
ータタイプの変更と新しいフォーマットとを示ず指示コ
ードが前記ストリームの中へ挿入され、適当なデータフ
ォーマットの変換により呼び出しを促進し、データ転送
／変換ルーチン８０８を新しいデータタイプに切り換え
る。例えば、データストリームの挿入された部分の終り
においてデータタイプが再び変わると同じオペレーショ
ンが用いられ、交換フォーマットは原始データタイプに
戻る。
対照的に、リンクは効果的にデータのコピイを原始オブ
ジェクトから宛て先オブジェクトまで転送するが、リン
クされたデータは実際には宛て先オブジェクトの一体部
分ではない。例えば、リンクされたデータは宛て先オブ
ジェクトのオブジェクトマネージャによりオペレートは
されえぬが、原始オブジェクトマネージャにより原始オ
ブジェクトにおいてオペレートされねばならない。
別のオブジェクトからリンクされたデータを含むオブジ
ェクトの一部をコピイあるいは移動させるべき場合、リ
ンクされたデータあるいは実際のリンクされたデータへ
のリンクがコピイあるいは移動されるか否かは、リンク
をはめ込んだオブジェクトがどのようにしてｆｔ成され
たかにより決定される。本発明によるシステムにおいて
は、採用された規則は、もし原始オブジェクトが別のオ
ブジェクト内から作成された場合、リンクされたデータ
はコピイされるということである。例えば、もしユーザ
がドキュメントタイプのオブジェクトのドキュメント内
から、かつその一部としてチャートを、したがってチャ
ートタイプの原始オブジェクトを作成し、次いでドキュ
メントオブジェクトあるいはリンクされたチャートタイ
プデータを含むドキュメントオブジェクトの部分を複製
してドキュメントオブジェクトのこの部分をコピイした
とすれば、ドキュメントオブジェクトのそのコピイはチ
ャートの新しいコピイへのリンクを含む。このチャート
のコピイは、ドキュメントのオブジェクトのコピイと同
様原始バージョンとは独立して修正できる。しかしなが
ら、もしリンクが先に存在していたドキュメントオブジ
ェクトと先に存在していたチャートオブジェクトの間で
作成されたとすれば、リンクされたデータよりもむしろ
リンクがコピイされ、その結果第１のドキュメントと同
じチャートオブジェクトのリンクを備えたドキュメント
のコピイを作ることになる（即ち前記チャートに対する
変更が双方のドキュメントに現われることになる）。
原始データが宛て先データと類似かあるいは同一の場合
、直接あるいは変換後、コピイされ、移動され、あるい
は共用された原始データは宛て先データに「混入される
か」あるいは「はめ込まれる」ようになる、コピイある
いは移動されたデータの場合、コピイあるいは移動され
たデータは宛て先オブジェクトマネージャにより編集可
能である。
しかしながら、共用されたデータの場合、かつ共用され
たデータがコピイ、移動あるいは削除される場合、該デ
ータは原始オブジェクトにおいてのみ、かつ原始オブジ
ェクトのオブジェクトマネージャによってのみ編集可能
である。宛て先オブジェクトのオブジェクトマネージャ
は共用されたデータを独自の内部データフォーマットに
変換可能であるが、共用されたデータを独自のデータに
組み入れることはなく、いずれにしても原始データを編
集できず、共用データを「マークし保持する」必要があ
る。ユーザがデータが編集されつつあるオブジェクトの
直接その一部でなく、共用されているのであることに気
が付くようデータをユーザに対して可視マークを付ける
べきである。「マークされ、保持されている」データの
場合、宛て先オブジェクトのリンク平行ファイルのエン
トリはリンクされたデータのコピイを含む（即ち「保持
して」いる）。リンクパラレルファイルにおけるこのコ
ピイは直接ＩＩ集でき、むしろこのデータはそこからリ
ンクされている原始オブジェクトをＭ４集することによ
り編集される。
宛て先オブジェクトマネージャは、コピイあるいは移動
オペレーションを首尾よく実行するためにコピイされ、
あるいは移動されたデータを編集できる必要はなく、単
に原始データを何らかの方法で宛て先オブジェクトへは
め込めればよい。コピイあるいは移動したデータを「密
閉化」でき、その場合データは適当なタイプの個別のオ
ブジェクトに記憶され、該オブジェクトへのリンクは、
コピイあるいは移動オペレーションの終りにあるオブジ
ェクトにはめ込まれる。
共用オペレーションにおいては、宛て先オブジェクトマ
ネージャは共用オペレーションを定義することにより何
らかの方法で原始データを編集し、共用されたデータを
「マークし保持する」必要がある。共用されたデータは
コピイ、移動あるいは削除しうるが、一方ｍ集できるの
は原始オブジェクトにおいてのみ、かつ原始オブジェク
トのオブジェクトマネージャによってのみである。
１５、マツ　メー １５．１．マツ　メー　の　　　　　・２個のオブジェ
クトの間でデータ転送あるいはリンクを発生させるには
、ユーザは原始オブジェクトと宛て先オブジェクト並び
に実行すべきオペレーションとを識別する０例えば、ユ
ーザは原始データを選択し、Ｃ０ＰＹキーを押し、次い
で宛て先を指し、ＰＬＡＣＥキーを押す、原始とデータ
とが異なるオブジェクトにある場合、（異なるプロセス
でそれぞれ実行している）２個のオブジェクトマネージ
ャが介入させられる。しかしながら、あるプロセスが所
有するウィンドウの外側でのカーソルの移動はそのプロ
セスには知られていないので、プロセスはオペレーショ
ンの他の半分（例えばｃｏｐｙあるいはＰＬＡＣＥ）が
ユーザにより実行されたことも知らない、この問題はマ
ツチメーカにより解決される。
アプリケーションマネージャは、各々の潜在的なオペレ
ーションに対して２個面を有するマツチメーカを保持す
る。即ち、サーバ側（即ち何かを有する側）とコンシュ
ーマ側（即ち何かを欲している側）である。データ交換
オペレーションに対しテＧｉ？−ｔ＜＠＜ＰＡＬＧｆ、
Ｃ０ＰＹ、　ＨＯＶＥ、　’ＪＡＲＥ）を通知する。オ
ブジェクトマネージャはデータ交換フォーマットが提供
するものを列挙する。コンシューマ側（ＩＮえばＰＬＡ
ＣＥ）を通知するオブジェクトマネージャはそれが受け
入れるデータ交換フォーマットを列挙する。
一旦Ｃ０ＰＹ、　ＭＯＶＥ、または５ＨＡＲＥが通知さ
れると、ＰＬＡＣＥが通知されるまで、それ以外１７）
ＣＯＰＹ、ＭＯＶＥまりＧ、ｔ　５ＨＡＲＩＪ、を受ケ
入れられなイ、　Ｃ０ＰＹ、ＭＯＶＥまたはＳｌｌ八Ｒ
へが何ら通知されおらず、ＰＬＡＣＥが通知されタトす
れば、Ｃ０ＰＹ、　ＭＯＶＥまたは５ＨＡＲＥが受ケ入
れられるまで、（あるいは通知したオペレーションを担
当するオブジェクトマネージャがオベレーンヨンを停止
するまで、）それ以上のＰＬＡＣＥは通知されない。
その他の明白に区別のつくオペレーションの対が定義さ
れるとすれば、これらオペレーションのマツチメーカの
半分が同時に通知され、満足のいく半分が呼び出される
と突き合わせ（マツチ（ｍａｔｅｈ））が行われる。
マツチングが行われ、（オペレーションのマツチングし
た側が通知されると）へＰｒ’ＡＣＫマツチメツセージ
がサーバとコンシューマの双方へ送られる。
次いで各々が＾ＰｍｍｃｏｎｎｅｃｔＯを呼び出し相互
に通信し、直接データを交換するに必要な情報を取得す
る０次いで、アプリケーションマネージャがマツチメー
カをクリヤし、最初のマ・ソチから発生したデータ交換
が進んでいる量刑のマツチを受け入れる。
オブジェクトマネージャがＣ０ＰＹ、　ＭＯＶＥあるい
はＳｌｌ＾ＲＥイベントを受けとると、オブジェクトマ
ネージャは次のステップをとる。
（ａ）　　オペレーションを通知する。
−＾Ｐｍｍｒｅｓｅｒｖｅ□を呼び出し、同じタイプの
オペレーションがすでに進行しているか検出する。もし
その通りであれば、エラーメツセージ分表示し、通常の
処理に戻る。
−　データを選択するに必要なユーザとのどんな対話で
も行う。しかしながら、もしオペレーションがＳｌｌ＾
ＲＥであり、＾Ｐｍｍｒｅｓｅｒｖｅ□を呼び出して他
の側が通知されリンクデータを必要としないことを示せ
ば（即ち、Ｓｌｌ＾ＲＥは全体としてオブジェクトへの
リンクを作ることであって、オブジェクトのいずれかの
データへのリンクを作成するのではない）、ユーザはデ
ータ選定を急がされるべきでない。
−情報損失の増える順序で、供給しうる交換フォーマッ
トのリストで＾Ｐ１ｐｏｓｔ□を呼び出す。
−もし＾ＰｍｍｐｏｓｔＯがマツチは不可能であること
を示すとすれば（例えば、共通のフォーマットが無く、
宛て先はリンクをサポートせず密閉化をさらに不可能と
する）、適当なエラーメツセージを表示し、八Ｐ＋ａｍ
ｃｌｅａｒＯを呼び出し、通常の処理に戻る。
−もし＾Ｐ＋ｏｎ＋ｐｏｓｔＯがマツチの行われること
を示すとすれば（即ち、ＰＬＡＣＥがすでに通知されて
いる）、（「何処へ？　」”Ｔｏｗｈｅｒｅ？”の処理
をスキップして）オペレーションを開始する。
−もし＾Ｐｆｉｍｐｏｓｔ□がまだマツチのなされてい
ないことを示せば、「何処へ？」の処理を行う。
（ｂ）　　宛て先を決める（「何処へ？」）−「何処へ
？」を表示する。
−もしＰＬＡＣＥ事象が（このオブジェクトマネージャ
により）受け取られるとすれば、オペレーションは内部
的（即ち単一のオブジェクト内の一方の場所から他の場
所）である。＾ＰｍｍｃｌｅａｒＯを呼び出しマツチメ
ーカをクリヤにしオペレーションを進行させる。
−もしＭＡＴＣＨ事象がマツチメーカから受け取られる
とすれば（以下のように）オペレーションの処理を開始
する。
（ｅ）　　オペレーションの処理を開始−＾Ｐｎ＋ｍｃ
ｏｎｎｅｃｔ□を呼び出し他のオブジェクトマネージャ
へ接続する。−旦双方のオブジェクトマネージャが＾Ｐ
ｍｍｃｏｎｎｅｃｔ□を呼び出せば、オペレーションへ
のマツチメーカの介入が終る。
−他のオブジェクトマネージャからのりクエストを待機
するそのリクエストはリンク、特別の交換フォーマット
でのデータあるいは密閉化用かもしれない。
−　リンクに対してはリンク仕様を構成し、次いでへＰ
ＰＡＣＫリンク交換ルートを用いてリンク仕様を送る９ −データに対しては、適当な八ＰＰＡＣＫあるいは他の
データ交換ルーチンを呼び出しくリクエストされた交換
フォーマットに応じて）データを送る ー　密閉化に対しては、 ＊　＾ＰｒｑｅｏｐｙＯを呼び出してオブジェクト全体
をコピイするか＾ＰｒｑｃｒｅａｔｅＯを呼び出して（
プロトタイプのコピイを作成し）、かっ（オペレーショ
ンにより指示されて）選択したデータを新しく作成され
たオブジェクトへ移動あるいはコピイさせる。（オブジ
ェクトのタイプによって、たとえ一部のみをリンクすべ
きとしても、コピイに全体オブジェクトを含めることが
必要かもしれないことに注目のこと）。
＊　リンク仕様を新しいオブジェクトの選択したデータ
に構成しく新しいオブジェクトにおける全てのデータを
リンクするとしても必要）、次いでへＰＰＭＣＫリンク
交換ルーチンを用いてリンク仕様を送る。
（ｄ）　　オペレーションを停止する −　もしオペレーションがｃｏｐｙまたはＳｌｌ八Ｒへ
であれば、＾Ｐｏｐｆｉｎｉｓｈ□を呼び出しオペレー
ションを停止する。（Ｓ１１＾ＲＥまたはｅｏｐｙに対
するＵＮＤＯ（取り消し）オペレーションはコンシュー
マの介入を・ｇ・要とせず、したがって通信はもはや必
要でなくなる）。
−もしオペレーションがＭＯＶＥの場合、オブジェクト
マネージャは下記の発生までオペレーションを継続させ
ておくこと。
＊　ユーザがＮ０ＶＨの可能なｔｌＮＤＯを上層るオペ
レーションを実行する。この場合、オブジェクトマネー
ジャは＾Ｐｏｐｆｉｎｉｓｈ□を呼び出しオペレーショ
ンを停止し、コンシューマに対して取り消しはもはや不
可能となることを通知する。
＊　ユーザがオペレーションのＵＮＤＯを要求する。こ
の場合、オブジェクトマネージャはコンシューマと通信
して運動したデータを検索し、ＭＯＶεオペレーション
を反転する。
マツチの起る前にＣＡＮＣＥＬ事象が受けとられた場合
、へＰ＋ｕ内ｃｌｅａｒ□を呼び出しマツチメーカをク
リヤし、通常の処理に戻る。
１５．２．２．戸〃プロトコル オブジェクトマネージャがＰＬＡＣＥ事象を受け取ると
、オブジェクトマネージャは次のステップを踏む。
（、）　　オペレーションを通知する。
−＾Ｐｍ＋＊ｒｅｓｅｒｖｅ□を呼び出して同じタイプ
のオペレーションがすでに進行中であるが検出する。そ
うであれば、エラーメツセージを表示し、通常の処理に
戻る。
−八Ｐｍｍｐｏｓｔ□を、情報損失の大きい順の受け入
れられる交換フォーマットのリストで呼び出す。
−もし八Ｐ＋＋＋ｍｐｏｓｔ□がマツチが不可能なこと
（例えば共通のフォーマットが無い）を示せば、適当な
エラーメツセージを表示し、ＡＰ＋ａｍｃｌｅａｒＯを
呼び出し、通常の処理へ戻る。
−もし＾Ｐ＋＊ｍｐｏｓｔ□が、マツチのあること（即
ち、Ｃ０ＰＹ、ＭＯＶＥまｆ、：　！、ｔ　５ｌｌＡＲ
Ｅオヘレ−Ｅ／　ヨ’／がすでに通知されている）を示
せば、（“ＰＬＡＣＥ　　１１＋１八Ｔ？”処理を飛ば
して）オペレーションの処理を開始する。
−もし＾Ｐ＋＊ｍｐｏｓｔＯがマツチが未だ無いことを
示せば、“ＰＬＡＣＥ　　ｌｌ１ｌｌ＾Ｔ？゛°の処理
を行う。
（ｂ）　　データ選定を待ａ（’″ＰＬＡＣＥ　　ＨＦ
Ｉ＾Ｔ？”）−“ＰＬＡＣＥ　　Ｗｌｌ＾Ｔ？”を直ち
に表示する。
−もしＣ０ＰＹ、　１４０ＶＥ、または５ＨＡＲＥオペ
レーシヨンが（このオブジェクトマネージャにより）受
け取られたならば、その場゛合オペレーションは内部的
（即ち単一のオブジェクト内での一方の場所から他の場
所まで）である。＾Ｉ’ｍｍｃｌｅａｒＯを呼び出しマ
ツチメーカをクリヤし、オペレーションを進める。
−もし１４ＡＴｃＨ事象がマツチメーカから受け取られ
ると、（以下のように）オペレーションの処理を開始す
る９ （Ｃ）　　オペレーション処理の開始 −＾Ｐｗｍｃｏｎｎｅｃｔ□を呼び出し他のオブジェク
トマネージャへの接続を行う。−旦双方のオブジェクト
マネージャが＾ＰｍｍｃｏｎｎｅｃｔＯを呼び出すと、
そのオペレーションへのマツチメーカの介入は終了する
。
−原始オブジェクトマネージャに、リンク、特別の交換
フォーマットでのデータあるいは密閉化のリクエストを
出す。
−　リクエストが確認された後、八ＰＰＡＣにの１つあ
るいは他のタイプのデータ交換専用サービスを用いて交
換を遂行する。
−もしリクエストがマルチ（多重）オブジェクト転送（
＾ＰＤＡＴＡＭＵＬＴＩＰＬＥ）のためのものであると
すれば、以下の余分のステップが必要とされる。
＊　＾Ｐｍｍｒｅｓｅｒｖｅ□を呼び出しマルチオブジ
ェクト転送用にマツチメーカを予約する。
＊　　ＡＰＰＡＣにのマルチ交換サービスを用いて、オ
ブジェクトの供給されたリストを通してループ化し、各
々とインタラクトしてその中味を探索する。
（ｄ）　　オペレーションを終了する −　オペレーションがＣ０ＰＹまたは５ＨＡＲＥであれ
ば、＾ＰｏｐｆｉｎｉｓｈＯを呼び出してオペレーショ
ンを終了させる。
−もしオペレーションがＨＯＶＥであれば、オブジェク
トマネージャは下記の発生するまでオペレーションを継
続させるべきである。
＊　ユーザが、ＭＯＶＥの可能性のある［ＩＮＤＯを上
廻るオペレーションを実行する。この場き、オブジェク
トマネージャは＾Ｐｏｐｆ　１ｎｉｓｈ□を呼び出して
オペレーションを終了させ、コンシューマに取り消しが
もはや可能でない旨通知する。
＊　ユーザがオペレーションのりＮＤＯをリクエストす
る。この場合、オブジェクトマネージャはコンシューマ
と通信して移動したデータを検索してＭＯＶＥオペレー
ションを反転させる。
１５．２．３．　　ブジェクト。のＭＯＶＥ　　ペレー
ションの　の［１ＮＤＯの　理 オブジェクト間のＭＯＶＥオペレーションを取り消すた
めに、原始および宛て先の双方のオブジェクトマネージ
ャはＵＮＤＯがリクエストされるか、オペレーションが
（例えば別のオペレーションにより抑えられて）もはや
反転できなくなるまでオペレーションを継続させておく
必要がある。オブジェクト間の（外部の）ＭＯＶＥが依
然として作用している間オブジェクトマネージャは以下
のことを行う。
−もしＵＮＤＯ事象がユーザから受け取られると、他の
オブジェクトマネージャにＭＯＶＥＵＮＤＯリクエスト
を送りＮ０ＶＨの反転に進行する。
−もしＭＯＶＥｔｌＮＤＯメツセージが他のオブジェク
トマネージャから受け取られると、ＭＯＶＥを反転する
よう進行する。
−もしユーザが外部のＭＯＶＥを、現在反転可能のオペ
レーションとして上廻るオペレーションを実行するとす
れば、＾Ｐｏｐｆ　１ｎｉｓｈＯを呼び出してオペレー
ションを終了する。
−もしオペレーション終了メツセージが受け取られると
すれば、次に＾ＰｏｐｆｉｎｉｓｈＯを呼び出す、　Ｍ
ＯＶＥの一方の側のみが取り消ししうる。もしＭＯＶＥ
が抑えられる前にｔｌＮＤｏ事象が後で受け取られると
すれば、ユーザは、Ｎ０ＶＨの半分のみが取り消されう
ろことを警告され、確認を促がされる。
１６、−一部　　　　９ データ交換に関する以下の説明において説明するように
、オブジェクト間のデータの交換は原始オブジェクトお
よび宛て先オブジェクトにおけるデータのタイプによっ
て左右される。もしデータタイプが同一か、十分近似し
ているとすれば、データをほとんどあるいは全く交換す
ることなく、かつ情報をほとんどあるいは全く損失する
ことなく直接交換され、かつ宛て先において直接用いる
ことができる。しかしながら、もしデータタイプが十分
相違しているとすれば、変換は困難であり、また、デー
タを宛て先オブジェクトで直接使用できない、即ち宛て
先オブジェクトのデータの一体部分として使用できなく
なる。この場合、情報に若干の損失があり、後述するよ
うに原始オブジェクトのデータは出来るだけ上手く宛て
先オブジェクトのデータに「はめ込むＪ必要がある。
オブジェクト間のデータ交換は「マツチメーカＪと称さ
れる＾Ｐｒ’ＡＣＫ装置により促進することができる。
マツチメーカは２個のオブジェクトマネージャが、それ
らがデータ交換オペレーションの終りをマツチングさせ
ていることを検出できるようにする。原始および宛て先
オブジェクトマネージャとマツチメーカとのインタラク
ション（対話）の一部として、これらのオブジェクトマ
ネージャはマツチメーカに対して、オブジェクトがデー
タを提供し−、かつ受け入れうるフォーマット即ち形式
を示す、これらのフォーマットと形式とはオブジェクト
の元のデータタイプを含みうる。各オブジェクトに対す
るオブジェクトマネージャはまた、ある種のデータ変換
を行う能力を有し、したがって、それらの元のフォーマ
ット以外のフォーマットや形式でデータの提供あるいは
受け取りができる。
交換用データフォーマットは原始および宛て先オブジェ
クトマネージャとマツチメーカとの間の対話により合意
され、交換は、どのようなデータ変換がいずれかのオブ
ジェクトで必要とされようとも合意したフォーマットに
より実行される。
リンクを介するデータ交換において、子供のオブジェク
トのデータを提供すべきデータタイプは、特定のリンク
に対する後でのデータ交換において子供オブジェクト４
０４が後で使用するようリンクのリンクパラレルファイ
ルエントリ４０４の交換タイプフィールドにおいて記録
される。マツチメーカは最初にリンクを作成する共用オ
ペレーションには介入しうるものの、リンク更新オペレ
ーションでは介入しない。
第９図を参照すれば、データが原始オブジェクトから宛
て先オブジェクトまで移動され、コピイされ、あるいは
共用される、＾ＰＰＡＣＫ２１８のデータ交換が線図表
示されている。原始ユーザオブジェクト２３２−ｓと関
連のオブジェクトマネージャプログラム２４０−ｓ、宛
て先ユーザオブジェクト２３２−ｄとその関連のオブジ
ェクト／マネージャプログラム２４０−ｄ、およびアプ
リケーションバック（八ＰＰＡＣに）２１８とが示され
ている。ユーザオブジェクト２３２−ｓは原始データ８
００を含むものとして示され、該データはコピイされ、
移動され、あるいはユーザオブジェクト２３２−ｄと共
用されるデータであり、−方ユーザオブジェクト２３２
−ｄは宛て先データ８０２を含むものとして示され、該
データは交換されたデータがユーザオブジェクト２３２
−ｄで占める場所と交換されたデータ自体の双方を示す
。
オブジェクト／マネージャプログラム２４０−ｓおよび
２４０−ｄを参照すれば、これらオブジェクト／マネー
ジャプログラム２４０の各々はそれらの各々のユーザオ
ブジェクト２３２にオペレートしているものとして示さ
れている。各オブジェクト／マネージャプログラム２４
０−ｓの実行可能コードはデータ交換ルーチン８０４−
ｓを含むモジュール、関連のフォーマットテーブル８０
６−ｓおよびデータ転送／変換ルーチン８０８−ｓを含
むモジュールを含むものとして示されている。同様に、
オブジェクト／マネージャプログラム２４０−ｄはデー
タ交換ルーチン８０４−ｄ、フォーマットテーブル８０
６−ｄおヨヒデータ転送／変換ルーチン８０８−ｄを含
む。
さて、データ交換オペレーションを検討すると、前述の
説明ではデータ交換はデータのコピイおよび移動オペレ
ーション並びにデータ共用に使用できるということであ
った。前記オペレーションの全ては多くの点において酷
似していることにまず注目すべきである。コピイ、移動
および共用オペレーションに関する以下の説明でさらに
詳しく説明するが、これらオペレーション間の主たる差
は、それらオペレーションが開始される態様と、データ
がオペレーション後筬われる態様とにある。
後者に関しては、３種のオペレーション、即ちコピイ、
移動および共用オペレーションの全ては基本的にはコピ
イオペレーションと見做すことができる。即ち、各オペ
レーションにおいて、あるデータが識別され、原始オブ
ジェクトからコピイされ、宛て先オブジェクトの識別し
た位置に置かれる。移動オペレーションとコピイオペレ
ーションの相違点は、原始オブジェクトにおけるデータ
がオペレーションの終りにおいて削除される、即ちデー
タが原始オブジェクトから宛て先オブジェクトヘコピイ
され、原始オブジェクトにおけるデータの原コピイが削
除されることである。共用オペレーションも、原始オブ
ジェクトからのデータの新しいコピイが作られ、前述の
ようにリンクが更新される毎に宛て先オブジェクトに位
置される点を除いてコピイオペレーションと類似である
。
データ交換オペレーションの開始に関して、最初のステ
ップはオペレーションの開始と、データが宛て先オブジ
ェクトにおいて現われる位置の識別と、および原始オブ
ジェクトにおいて交換されるべきデータの識別とである
。後述のように、コピイ、移動および共用オペレーショ
ンは、通常メニューピックアップあるいはキーボードを
介して入力される指令によりシステムのユーザが典型的
にはマニュアルで開始させる。次に、原始オブジェクト
データおよびデータの宛て先オブジェクトにおける位置
との識別の順序は、ユーザの見方で原始オブジェクトと
宛て先オブジェクトとの間を移動しているオペレーショ
ンがオペレーション「から」来るのかオペレーション「
へ」向うのかによって変わり、オペレーションの順序（
即ち、ユーザがまず原始データを識別できるのか、ある
いはユーザがまず宛て先データでの位置を識別できるの
か）によって変わる。
さらに、リンクを介するデータ交換もリンク更新の発生
時に、即ちマニュアルの更新が選択されていた場きはユ
ーザの指令により、あるいは自動的更新が（共用オペレ
ーションが最初にリンクを作成すると発生する更新に加
えて）選択されていたとすればリンクされたデータを含
む宛て先オブジェクトの部分のデイスプレィあるいはプ
リントによって開始される。
原始オブジェクトのデータのユーザによる選択と、デー
タが行くべき宛て先オブジェクトでの位置の識別とに関
して、原始および宛て先オブジェクトマネージャが呼び
出される。
次いで、本明細書の説明の主観であるが、原始および宛
て先オブジェクトは原始オブジェクトから宛て先オブジ
ェクトへデータを交換する必要がある。第９図に示す本
説明では、ユーザの行動（即ち宛て先の位置の識別）が
すでに実行されているものと想定する。
データ交換オペレーションの開始時、原始および宛て先
オブジェクトのオブジェクトマネージャは、データ交換
オペレーションを導き、かつ制ｉｎするルーチンのグル
ープからなる各データ交換ルーチン８０４を呼び出す。
データ転送／変換ルーチンモジュール８０８とそれに関
連したフォーマットテーブルとがある。データ転送／変
換ルーチン８０８はオブジェクトと＾ＰＰＡＣに２１８
のデータ交換装置８１２どの間でデータを転送する、即
ちオブジェクトがら、かつオブジェクトへデータを読取
ったり、書込んだりするための、−群のルーチンがら構
成されている。また、データ交換装置８１２は、オブジ
ェクトの元のデータフォーマットとある外部のデータフ
ォーマットとの間でデータを変換するデータ変換ルーチ
ンも含む。フォーマットテーブル８０６の方は、対応す
るオブジェクトにより、即ちオブジェクトのオブジェク
ト／マネージャプログラム２４０のデータ転送／変換ル
ーチン８０８により発生され、かつ受け入れられうる全
てのデータフォーマ・ントのリスト即ちテーブルを含む
。これらのフォーマットは少なくともオブジェクトの元
のデータフォーマットを含み、かつある外部のデータフ
ォーマットを含みうる。
各オブジェクトマオ・−ジャのデータ交換ルーチン８０
４はマツチメーカ８１０に対して、データ交換ルーチン
８０４の関連のデータ転送／変換ルーチン８０８が受け
入れ、あるいは提供しうる各種のデータフォーマットを
記述した、関連のフォーマットテーブル８０６からの情
報を提供する。これらのフォーマットは好ましい順に提
供され、マツチメーカ８１０が交換のための共通のデー
タフォーマットを選択する。マツチメーカ８１０は交換
のために選定したデータフォーマットをデータ交換ルー
チン８０４へ戻し、次いでデータの転送が行われる。
データ交換における次のステップは原始オブジェクトか
ら宛て先オブジェクトへデータを実際に転送することで
ある。転送はストリームモードで実行される。即ちバイ
トが転写オペレーションにより相互に区別されず、デー
タのバイトの基本的に制限のないストリームの形で転写
される。即ち、ストリームのバイトに対する重要性が、
交換オペレーション自体でなく、交換フォーマットによ
り規定される。
データストリームの転送を実施するために、各々のデー
タ転送／変換ルーチン８０８は、それぞれのユーザオブ
ジェクト２３２と＾ＰＰＡＣＫ２１８のデータ交換装置
８１２どの間で一連のｒＧＥＴＪおよびｒＰＵＴ、オペ
レーションを実行する。即ちデータ転送／変換ルーチン
８０８ｓは原始データから一連のバイトのデータをｒ（
：ＥＴ（取得）」シ即ち読取り、原始データが原始デー
タ８００から「取得」されるにつれて必要なデータ変換
オペレーションを実行しながら、集められた原始データ
のバイトをデータ交換装置８１２にｒＰＵＴ（置く）」
即ち書込む。データ転送／変換ルーチン８０８−ｄは同
時に、データ交換装置８１２から原始データのバイトを
「取得」即ち読取り、再びデータが宛て先データ８０２
へ「置かれる」につれて必要なデータ変換オペレーショ
ンを実施して原始データのバイトを宛て先データ８０２
へ「置＜」即ち書込む。
この点に関して、データ交換装置８１２は一組のレジス
タと、例えばデータ転送／変換ルーチン８０８−ｓのよ
うな原始データを受け取り、データ転送／変換ルーチン
８０８−ｄのようにデータを宛て先へ転送するデータチ
ャンネルを含むルーチンとから構成されていることに注
目すべきである９ さらに、データ転送／変換ルーチン８０８のオペレーシ
ョンが例えばリンクマーカのような各種タイプのはめ込
みデータを含めることをサポートすることに注目すべき
である。ストリーム転送に採用されている規則は、スト
リームに対して初期の交換タイプ即ちデータフォーマッ
トがあることである。例えばリンクマーカあるいはリン
クされたデータのような別のデータタイプをストリーム
に挿入すべき場合、データタイプの変更と新しいフォー
マットとを示すインジケータコードがストリームに挿入
され、適当なデータ転送／変換ルーチン８０８のデータ
フォーマット変換装置が呼び出されてデータ転送／変換
ルーチン８０８のオペレーションを新しいデータタイプ
に切り換える。データタイプが例えばデータストリーム
の挿入された部分の終りにおいて再び変更されると同じ
オペレーションが用いられ、データ転送／変換ルーチン
８０８は元のデータタイプに戻る。
最？表に、前述の説明から、データ変換フォーマットは
、リンク用であろうと移動あるいはコピイオペレーショ
ン用であろうと、あるいは考えうるいずれからの他のタ
イプのデータ交換に対してであっても、データ交換のあ
らゆるタイプに対しても中心的であることが明らかであ
る。前述のように、−旦２つのオブジェクトマネージャ
が共通のデータ交換フォーマットについて合意すると、
原始オブジェクトマネージャは原始オブジェクトの内部
データフォーマットからの原始データを必要に応じ交換
フォーマットに変換し、データを交換フォーマットにお
ける宛て先オブジェクトマネージャへ伝送する。宛て先
オブジェクトマネージャはデータを受け取り、必要に応
じて変換フォーマットからのデータを宛て先オブジェク
トの内部データフォーマットに変換し、即ちデータを宛
て先オブジェクトに内部化し、データを宛て先オブジェ
クトに置く。さらに、交換に含まれるフォーマットの複
雑さ、「リッチさ」および互換性が交換の複雑さあるい
は容易さ、およびあるとした場合の情報損失あるいは歪
の可能性を規定する。
各オブジェクトマネージャはそれが内部的にオペレート
するデータのフォーマットや構造を決めることができる
。このため各オブジェクトマネージャの最も強力で効率
的な実行性を許容する。オブジェクトマネージャは典型
的に内部使用のためのシステム定義のデータフォーマッ
トを使用しない。
いずれか所定の対の内部データフォーマットは異なる属
性を有しており、所定の原始データフォーマットと所定
の宛て先データフォーマットとの交換フォーマットを選
択することにより、情報損失あるいは歪みの可能性も含
みデータ交換の速度、効率および正確さに直接影響を与
えることが上記の説明から明らかである。データの中味
の保持、即ち所定のデータフォーマットの属性−を表現
あるいは変換する能力はデータ交換を達成する上でシス
テムのユーザに対して最も重要な要素の１つであり、し
たがって、データ中味を可能な限り最も高度に保持する
交換フォーマット、即ち原始および宛て先の内部データ
フォーマットの属性を最大限収容しうる交換フォーマッ
トを用いて各データ交換を実行することが重要である。
そのため、各オブジェクトマネージャは出来るだけ高レ
ベルの交換フォーマットをサポートし、かつ出来るだけ
多くの交換をサポートすべきである。このため、所定の
各データ交換に対して最も効率的な交換フォーマットを
利用できる確率を増し、かつ所定のオブジェクトマネー
ジャが高レベルでデータ交換しうるオブジェクトマネー
ジャの数と範囲とを増大する。このことによりまた、オ
ブジェクトマネージャ問およびオブジェクトマネージャ
とシステムとの間の結合の程度を向上させる。
交換フォーマットは３レベルに構成される。交換フォー
マットレベルの区別は交換において達成されるデータ中
味の保持程度、即ち交換が原始および宛て先の内部デー
タフォーマットの異なる属性のサポートしうる度合いに
基いている。３種類のフォーマットレベルはそれぞれデ
ータおよび属性の保持レベルの大きい順に「バニラ」フ
ォーマット、「カテゴリ特定」フォーマット、および「
専用」フォーマットと指示されている。
まず「バニラＪデータ交換フォーマットを検討する。こ
れらフォーマットは、システムに現われうるデータタイ
プの全スペクトルの間で、但しデータ交換が過度にＴ’
ＭＴｔＬにならぬレベルでデータ交換を提供する意図の
ものである。基本的に、「バニラ」フォーマットは、例
えば＾ＳＣ■あるいは２進フアイルのように、システム
に現われうる全てのデータタイプの中の最低の共通の特
徴を示す一般的なデータ交換フォーマットである。即ち
、一般的なフォーマットは種々の内部データフォーマッ
トの実用的な最大数の内部データ属性の最大の共通セッ
トをサポートする。これらの一般的な交換フォーマット
は、２個のオブジェクトマネージャに関連のデータが基
本的に異なるタイプである場合、即ち内部データフォー
マットがそれらの属性において著しい程度の共通性を有
さない場合使用する態度のものである。その例としては
、グラフィックタイプのオブジェクトとドキュメントタ
イプオブジェクトとの間の交換あるいはスプレッドシー
トあるいはデータベースタイプオブジェク１〜とドキュ
メントタイプオブジェクトの間、あるいはスプレッドシ
ートあるいはデータベースタイプオブジェクトとグラフ
ィックタイプオブジェク１へとの間の交換である。
これらの場合において、データの内部表示およびデータ
のユーザモデルの内部表示は、宛て先のオブジェクトが
原始オブジェクトデータ表示の、即ち原始オブジェクト
データの相対的に小さい細部分以上のものは解釈あるい
は表示しえないため高レベルの交換をしようとも単純に
は実用に供さない。しかしながら、−ｍフォーマットは
データタイプの固有の制限内での最大限のデータの中味
や属性の範囲をサポートするように構成されていること
に注目すべきである。この点に関して、−最フオーマッ
トが宛て先オブジェクトが受け入れ可能な以上の情報を
含みうろこともある。しかしながら、−ｍフォーマット
は、宛て先のオブジェクトマネージャがそれが使用しえ
ない、あるいは解釈してないデータ中味の部分は無視し
て外苑て先オブジェクトが提供されたデータを最大限利
用できるように構成されている。
現在定義されているバニラ交換フォーマットの例として
は、定義されたレコードフォーマット、未定義のレコー
ドフォーマット、テキストフォーマット、ピクチャフォ
ーマット、リンクフォーマットおよびサウンドフォーマ
ットを含む。これら−最フオーマットの各々を検討すれ
ば、定義されたレコードフォーマットは主として数字あ
るいはテキストである各種タイプの情報を含みうるフィ
ールドを含む、レコード構造の定義を可能とする。
このフォーマットは例えば詳細なデータベース変換ある
いはスブレッドシートフオーミュラ交換を志目したもの
でなく、レコード向きのオブジェクトマネージャの間で
有意な情報の転送ができるように１７たちのである。
未定義のレコードフォーマットは前述の定義したレコー
ドフォーマットの変形であるが、レコード記述子は含ま
ず、そのため各レコードの中味はレコードによって変り
うる。この未定義のレコードフォーマットは、あるオブ
ジェクトマネージャが未定義のフォーマットのデータを
拒否したいと思うこともあるため定義されたレコードフ
ォーマットとは明確に区別されている。
テキストフォーマットは例えば＾５ＣＴＩストリングフ
ォーマットにおけるようにテキストデータを単純に表示
するが、あるテキストの属性情報と単純なフォーマット
化情報は含むことができるものである。さらに、テキス
トフォーマットは例えば定義されたレコードフォーマッ
トあるいは未定義のレコードフォーマットにフィールド
の中味として含入できる。
ピクチャフォーマットはオブジェクトマネージャが、グ
ラフィック能力がほとんど無い、あるいは皆無の宛て先
オブジェクトにより表示しうる表示可能の「エンティテ
ィ」を提供できるようにする意図のものである。テキス
トオブジェクトにリンクされたグラフィックデータの場
合、例えば、グラフィック「エンティティ」はリンクパ
ラレルファイルエントリ４０８のリンクされたデータコ
ピイ４５８に記憶され、宛て先テキストオブジェクトに
おいてアイコン、あるいはタイトルで表示されることに
よりテキストオブジェクト自体ではグラフィックデータ
として実際には介在しない。次いでグラフィックデータ
は、グラフィックデータを「含む」テキストオブジェク
トの部分を表示すべき場合、表示のために、リンクされ
たデータコピイ４５８から読みとられる。このタイプの
フォーマットの意図は合理的に完全な可視性中味を有す
るが、意味あるいはグラフィックデータを編集する能力
の無いグラフィック表示性を提供することである。
リンクフォーマットは、リンクのコピイと移動オペレー
ションについて前述のように、オブジェクトマネージャ
がリンクを交換できるようにさせるものである。リンク
フォーマットは基本的には、前述のリンク構造を表示す
る。
サウンド（音響）フォーマットはピクチャフォーマット
と類似であるが、グラフィックデータではなく、例えば
音声メツセージのようにサウンドデータを交換するため
のものである。このフォーマットも、合理的に完全なオ
ーディオの中味を以ってサウンドデータを交換したり、
「再生」できるが、意味的な中味あるいはサウンドデー
タを編集する能力は無いものである。
カテゴリ特定フォーマットを検討する。「カテゴリ特定
」交換フォーマットは類似のデータモデルを有するが内
部データ記憶フォーマットの異なるオブジェクトの間で
データの属性の著しく大きい中味と著しく大きい保持力
としてデータ交換する意図のものである。例えば、種々
のスプレッドシートオブジェクトは類似のデータモデル
を有するが、内部データ表示は極めて相違する。そのた
め、２個の異なったスプレッドシートは一般フｉ−マッ
トより著しく大きい中味でデータ交換できるが、それら
の内部データフォーマットでは直接データ交換できない
。
各カテゴリ特定交換フォーマットは、そのカテゴリ特定
交換フォーマットを用いるカテゴリの全てのオブジェク
トマネージャに有意なデータと記述情報とを含む。この
点に関して、カテゴリの定義とは、カテゴリは所定のカ
テゴリ特定フォーマットにおいてデータを提供、受け取
り、あるいは提供と受け取りの双方を行うことを合意し
た１つ以上のオブジェクトマネージャからなるグループ
である。
カテゴリ特定交換フォーマットの可能な数は、基本的に
は無制限であって、新しいカテゴリ特定交換フォーマッ
トを備えた新しいカテゴリは意のままに作成できる。例
えば、もし一般フオーマットより大きい中味のデータを
交換することを２個の異なるオブジェクトマネージャが
必要あるいは冷望することが判明した場合、それらのオ
ブジェクトマネージャに対してカテゴリ特定フォーマッ
トを１ヤ成し、新しいカテゴリを定義することができる
。次いでいずれの数の、他の異なるオブジェクトマネー
ジャも新しいカテゴリ交換フォーマットを使用するよう
選択し、そのカテゴリのメンバとなればよい。この点に
関して、いずれの所定のオブジェクトマネージャもいず
れかの数のカテゴリのメンバとなりうることに注目すべ
きである。
定義されたカテゴリ特定フォーマットの例としては、つ
オング情報転送アーキテクチャ（ＷａｎｇＩｎｆｏｒ＋
＊ａｔｉｏｎ　　ＴｒａｎＳｆｅｒ　　Ａｒｃｋｉｔｅ
ｃｔｕｒｅ−ＷＩＴＡ＞、データベースフォーマット、
スプレッドシートフォーマットおよびグラフィックフォ
ーマットを含む。再びこれらフォーマットの各々を検討
する。ＷＩＴＡフォーマットはマサチューセッツ州ロウ
エルのウォング・ラボラトリーズ社（ＷａＢ　　Ｌａｂ
ｏｒａｔｏｒｉｅｓ、Ｉｎｃ、ｏｆ　　Ｌｏｗｅｌｌ。
Ｍ　ａｓｓａｃｌ＋ｕｓｃｔｔｓ）により開発されたＷ
ＩＴＡデータ交換アーキテクチャをさらに開発したもの
である。本発明のシステムにおいては、ＷＩＴＡフォー
マットは、広範なフォーマット化情報および可能性とし
て各種タイプのその他のオブジェクトへのリンクを含む
テキストデータを主として交換する上でドキュメントや
テキストエディタが使用する意図のものである。ＷＩＴ
Ａはまた、一方のドキュメントタイプから他方のドキュ
メントタイプへテキストおよびフォーマット化情報を交
換するのに特に適しており、一般的なデータ通信に使用
される。
データベース交換フォーマットはデータベースタイプオ
ブジェクトマネージャが使用する意図のものである。こ
のフォーマットは、例えばデータベース定義、レコード
構造、レコード間の接続についての情報を有するデータ
レコード、計算されたフィールドとフォーミュラフィー
ルドおよびリンクを含む考えうる全てのデータベースタ
イプのデータを交換する上で使用する意図である。デー
タベースフォーマットはまた、例えばドキュメントとス
プレッドシートオブジェクトのあるタイプのものを変換
したり、通信するのにも使用しうる。
スプレッドシート交換フォーマットはスプレッドシート
タイプのオブジェクトマネージャが使用する意図のもの
である。スプレ・ソドシート交換フォーマットにおいて
交換されたり変換されるスプレッドシートデータは、例
えば行、列、およびセルの定義、公式およびテキストお
よびデータフィールドを含む全てのタイプのスプレッド
シートタイプデータを含む。
ｉｆ＆に、グラフィック交換フォーマットはグラフィッ
クタイプのオブジェクトマネージャが使用する意図のも
のである。このフォーマットは、例えばビットマツプ化
したグラフィックデータ、ベクトルおよび［オブジェク
トベースの」グラフィックおよびピクチャ情報の全ての
形聾を含む考えられる全てのグラフィックタイプのデー
タを交換する上で使用する意図のものである。（「オブ
ジェクト」という用語はここでは本明細書の残りの部分
で使用する意味でなく、グラフィックに関係した視点か
ら使用していることに注目すべきである。）最後に「専
用」交換フォーマットは正に同じデータ構造とフォーマ
ットと分有するデータオブジェクト間でのデータ交換に
用いられる。これらの場き、交換に参加するオブジェク
トマネージャの各々は、正確に何が他のオブジェクトマ
ネージャの内部データ表示や属性であるか知っており、
したがって最大のデータ中味を保持するためにデータを
どのようにパッケージにし、かつ通信すべきか知ってい
る。データ構造は基本的に同じであるべきとの要件のた
めに、専用交換フォーマットは同じオブジェクトマネー
ジャにより作成されたデータオブジェクト間のデータ交
換に最も一般的に使用される。
専用交換フォーマットにおいては、オブジェクトマネー
ジャは、いずれかの他のオブジェクトマオ・−ジャの内
部データ構造との互換性の必要が全くないため自由にそ
れ自体の専用の交換フォーマットを定義すればよい。し
かしながら、専用の交換フォーマットを有しているオブ
ジェクトマネージャはその専用フォーマットを発表して
、他のオブジェクトマネージャかその専用フォーマット
を使用するよう選択することによって、新しいカテゴリ
特定の交換フォーマットを作成できる。専用フォーマッ
トはオブジェクトマネージャの内部データ構造により細
部に定義されるので、専用フォーマットをカテゴリ特定
フォーマットに変えても、オブジェクトマネージャが後
でその内部データ構造を変えうる範囲には制限がある。
所定のオブジェクトマネージャはデータオブジェクト間
で通信するために専用の交換フォーマットを使用する必
要はないが、カテゴリ特定のフォーマットを使用するよ
う選択でき、あるいは一般フオーマットでの交換に十分
なこともありうることに注目すべきである。さらに、所
定のいずれかのオブジェクトマネージャは同時に、専用
変更フォーマットと有し、いずれかの数のカテゴリに属
し、かつ対応するカテゴリ特定フォーマットを用いたり
、かつ一般フオーマットを用いてもよい。
最後に、−ｍ、カテゴリ特定あるいは専用フォーマット
であろうとも、各交換フォーマットに対して、どのよう
にデータを並べるか、かつどのようにデータ交換を行う
かオプションによって決めるいずれかの数の交換オプシ
ョンのあることに注目すべきである。宛て先オブジェク
トマネージャの決めるオプションや原始オブジェクトマ
ネージャが決めるオプションがある。所定のデータ交換
に対して、いずれのオプションを選択するがは交換の行
われるときに原始および宛て先オブジェクトマネージャ
によって決められ、特定の交換フォーマットを使用する
全てのオブジェクトマネージャは出来るだけそのオプシ
ョンを使用するものと思われる。
−ＬＬ 前述のように、オブジェクトマネージャは、実行可能の
コードと、プログラムにより使用されるデータとから構
成されているものと見做しうる。
そのようなデータの例としてはアイコン、言語依存テキ
スト、メツセージ、テキストフォント、フオーム、日付
および時間の表示フォーマットを含みうる９本発明によ
るシステムは、プログラムのコードとは別に変更あるい
は共用したいと希望するデータを記憶するために使用し
うる「資源」を提供する。したがって、資源はそのよう
なプログラムを、それが関連しているプログラムとは別
に、かつ独立して記憶する手段である。
資源にデータを位置させることによりその中の情報をプ
ログラムの実行可能コードに影響を与えることなくカス
トマイズあるいは変更できるようにする。この手段によ
り、所定のプログラムに対して多くのバージョンができ
、実行可能コードは各バージョンに対して同じであるが
関連の資源の常駐する該プログラムのデータのみがバー
ジョンによって変わる。さらに、資源を用いることによ
りオブジェクトマネージャと他のプログラムとが共通の
プログラムデータを共用することにより個々の１０グラ
１１のサイズとメモリ要件とを減少させることができる
。
１７．１．″゛原ファイル 資源は典型的には多く資源ファイルに記憶される。資源
は所期の関連に基き資源ファイルにグループ化される。
資源を用いたプログラムは、−時に開放されている複数
の資源ファイルを有する３資源がリクエストされるとそ
のプログラムの現在開放している資源ファイルが、リク
エストされた資源ＩＤを有する資源に対して検索される
。このようにどの資源ファイルをプログラムが開放する
か否かにより種々の資源を使用できる。
以下の例はファイルに資源をグループ化することに係る
事象のあるものを示す。１個の資源ファイルは、英語で
スプレッドシートオペレーションに特に向けられるユー
ザのプロンプトの全てを含みうる。第２の資源ファイル
は仏語におけるプロンプトを含む、第３と第４の資源フ
ァイルはそれぞれ英語と仏語の一般的なプロンプトを含
む。スプレッドシートオブジェクトマネージャは典型的
にこれら資源ファイルの２個を開放している。第１と第
３のファイルは英語を話すユーザ用であり、第２と第４
のファイルは仏語を話すユーザ用である。また、ドキュ
メントオブジェクトマネージャはドキュメントオペレー
ションに特有の資源を含む資源ファイルと共に第３また
は第４の資源ファイルのいずれかを開放する。
資源ＩＤは資源ファイル内で一意的であるが、種々の資
源ファイルを介して一意的である必要はない。資源ＩＤ
のある範囲が一定の定義を有するように割り当てられる
。換言すれば、同じＩＤを有する１ｒｖＪ以上の資源が
あるかもしれないが（例えば一方が英語資源で他方が仏
語資源のファイルにあるが）、これらの定義が一定の資
源ＩＤｓの中の１個を共用する全ての資源は同じ目的で
ある（例えば同じプロンプト）。完全に異なる目的に対
して池の資源ＩＤｓを異なるプロゲラ１１により使用し
うる。スズレッドシートに関連の資源のファイルはデー
タベースに関連の資源のファイルに使用されるように同
じ資源ＩＤを使用しうる。
各資源ファイルは３種類のセクション、索引付情報、資
源データ、記述情報から編成される。
索引付情報は資源ファイルの前方に記憶される。
これは、希望する資源がファイルにおいて探されたか否
かを検出するに必要な情報を含む。この索引は、一連の
アレイとして編成され、各アレイは順次の資源ＩＤのク
ラスタに対応するエントリを含む。資源ファイルの索引
部分の各エントリは−資源のサイ、ズ、 一資源フアイル内の資源の位置、 一資源タイブコード、および 一対応する資源がカストマイズできるか否かを指示する
フラッグを含むフラッグを含む。
資源ファイルの資源データ部分はいずれかの順序で資源
を記憶しうる（資源の各々の位置はファイルの割出し部
分に指示される。共に使用されそうな資源は相互に対し
て物理的に近接させて記憶することが好ましい。このた
め、リクエストされる資源がすでに主メモリにあり、デ
ィスクでのアクセスを低減させる可能性を増大できる。
記述情報はオプションのものである。これは資源のテキ
スト名、資源のテキスト記述およびリテラルとを含みう
る。
（任意的に介在させうる）リテラルは資源ＩＤｓを備え
た資源を探すプログラムの原始コードでシンボルを突き
会わせるために使用される。このためプログラム原始コ
ードが、その簡略値について選択し、かつ資源ＩＤの簡
略値と独立したシンボルを備えた資源を９照するように
できる。ユーティリティプログラムが資源ファイルを読
み取り、かつプログラムヘッダファイルを作成する。資
源ファイルにおいてリテラルが定義される各資源に対し
て、エントリが、その値が対応する資源ＩＤであるシン
ボルにリテラルがなるよう定義するヘッダファイルに現
われる。このように、これらの機械的に発生したヘッダ
ファイルの１個を含むプログラムが、資源を識別するた
めに資源ＩＤでなくむしろリテラルを使用することがで
きる。
１７．２．　ゞ、　１０Ａ二 第１ＣＩＡ　１３を参照すれば、本システムの全ての資
源を代表する資源７００の線図が示されている。全ての
資源７００は、ＲＥＳＰＡＣＫ２２２のルーチンを介し
て資源７００をシステムが位置づけ、かつアクセスする
情報を含むヘッダ７０２と、実際の資源データを含む資
源の中味７０４とからなる共通の構造を共用する。以下
説明するように、その中に８−よれる情報は資源を作成
したエディタにより検出されるものの、資源の中味７０
４の内部構造が資源のタイプにより検出される、資源の
ある定義されたタイプがある。また、資源の中味７０４
の中味と内部構造とは資源を作成したエディタにより全
体的に検出される自由形君の資源のタイプもある。
各種タイプの資源の資源の中味７０４の構造と、中味と
は資源７００のタイプによって変わるが、全ての資源７
００のヘッダ７０２は構造ならびに中味が均一である。
指示しているように、ヘッダ７０２はタイプフィールド
７０６、名前フィールド７０８、識別子フィールド７１
０、リテラルフィールド７１２、記述フィールド７１４
、一致したフラッグフィールド７１６としてそれぞれ指
示される３個のフラッグフィールド、ユーザがカストマ
イズしうるフラッグフィールド７１８およびシステムが
修正可能のフラッグフィールド７２０とを含む。
タイプフィールド７０６は、例えば資源がフオーム、メ
ツセージ、プルダウンメニュー、アイコン、ウィンドウ
構造、あるいは例えばテキストあるいはデータのバイト
ストリングであろうと、特定の資源７００に含まれた資
源のタイプの識別子を含む。
この点に関し、フオームとは典型的にはスクリーンの表
示、即ち、有益で明確なテキストフィールドおよび多く
の場合ユーザにより埋めることの可能なフィールドを含
むＣＲＴデイスプレィである。
、メツセージの方は、例えばイベントあるいはユーザが
実施すべき行動の通知のような情報をユーザに提供する
手段であって、グラフィック、テキストあるいはオーデ
ィオでよい。周知のようにメニューとは、有限の複数の
可能な行動あるいは事象の間でユーザが選択できるよう
にする手段である。プルダウンメニューは、そのメニュ
ーが必要なときのみ、即ちユーザの選択あるいはメニュ
ー表示が適当であるとオブジェクトマネージャが検出す
ると実行されるものである。「プルダウン」とは単に、
二ニーが明らかにスクリーンの上部から引き下げること
を意味する。アイコンはテキストストリングの代りにグ
ラフ表示するものであって、テキストがメツセージを提
供したり、行動あるいは選択を表示し、あるいは何かを
識別するために使用されるほとんどの何処の場所におい
ても使用しうる。ウィンドウ資源は、ウィンドウ、即ち
ユーザへの可視表示を含むスクリーンの有限の部分を説
明するパラメータブロックであり、ユーザに表示すべき
対応の窓を発生させるｒパック」により使用される。
その他の定義された資源タイプはタイプフォントを定義
するフォント資源、特定の言語の統語および文法上のル
ールを定義する言語ルール資源と、キーボードの各種の
キーの機能と用途とを定義するキーボード変換テーブル
とを含みうる。Ｉｆｔｔ＆に、バイトストリング資源は
前述の定義したタイプの中の１個の範囲内にない何らか
の資源を記憶するための自由にフォーマット化されるバ
イトストリングである。このタイプの資源において、情
報の内部構造は資源を作成するエディタにより完全に検
出される。
名前フィールド７０８は資源７００に対する任意に識別
する名前を割り当てするために使用される。名前フィー
ルド７０８に常駐する名前は例えば指令言語を介して資
源７００をアクセスするために使用しうる。
識別子フィールドフ１０は、識別子がプログラムの実行
可能コードにより参照されると資源にアクセスするため
にＲＥＳＰＡＣＫにより使用される識別子を含む。プロ
グラムが資源を必要とすると、プログラムは資源ＩＤを
ＲＥＳＰＡＣにルーチン〈例えばＲＥＳｇｅｔ（））に
通す。資源識別子を用いて、ＲＥＳＰＡＣＫの方は現在
開放している資源ファイルの１個で資源を位置づけ、資
源をプログラムに提供する。
識別子フィールド７１０に常駐する識別子は、資源がグ
ループ化されているファイル内においてのみ一意的であ
ればよい。典型的には識別子は資源が使用されるべきと
きのみ資源ファイルのセット内で一意となる。
リテラルフィールド７１２は、資源を用いるプログラム
の原始コード内で識別子フィールド７１０の資源ＴＤを
言及するラベルとして使用されるテキストストリングを
含む、資源エディタの方は所定の資源ファイルに対応す
るｒ　［ＮＣＬｔｌＤＥ（ｉｉ人）Ｊファイルを生成す
る機能を提供する。
記述子フィールド７１４は資源の表示可能の記述からな
るテキストストリングを含む。記述子テキストストリン
グは、資源エディタの資源のインデックス（索引）に、
かつ資源を用いているユーザあるいはオブジェクトマネ
ージャに対してはユーザあるいはプログラムプロフィル
に表示できる。
最後に、へ・ソダ７０２のフラッグフィールドを検討す
ると、一致したフラッグフィールド７１６は、セ・ソト
されると資源が資源ファイル内のブロック境界に整合さ
せるフラッグを含む。本発明のシステムにおいては、ブ
ロック境界に整合しないのは新しく資源を作成した省略
値である。しかしながら、整合は例えばフロントのよう
なある資源に対して有利であって、あるいはもし資源フ
ァイルが大きくて、多くの資源を含んでおれば、あるい
は資源自体が大きい場合、効率のためにも望ましい。
ユーザがカストマイズしうるフラッグのフィールド７１
８とシステムが修正可能のフラッグのフィールド７２０
とは、双方共、資源のカストマイズしたコピイが作成し
うるか否か、および誰によって作成されうるかを示すフ
ラッグを含んでいるという点において類似である。ユー
ザがカストマイズしうるフラッグのフィールド７１８は
、ユーザが資源のカストマイズしたコピイを作成しうる
か否かを指示す。システムが修正可能のフラッグのフィ
ールド７２０は同様であるが、システムの管理者がシス
テムプロファイルにおいて資源をカストマイズしうるか
否かを示す。
前述のように、資源の中味７０４は、資源データの構造
が資源のタイプにより決められる実際の資源データを含
む。さらに、この点に関して、所定の資源は１個以上の
他の資源から構成しうろことを注目すべきである。即ち
、資源フ００の資源の中味７０４は基準、即ち複数の他
の資源７００の識別子７１０を含むことによってそれら
の他の資源７００６組み入れればよい０例えば、フオー
ムタイプの資源は、各グループのフィールドが資源７０
０であるフィールドのグループから構成すればよい、各
グループのフィールド、即ち、グループのフィールドと
定義する資源７００の°各々は別のフィールドあるいは
フィールドのグループから構成してよく、これらのフィ
ールドの方は基準、即ちメツセージタイプの資源を識別
する識別子７１０を含めばよい。
資源には複数のタイプがあり、所定の資源７００の一部
の資源の中味７０４のｆｌｌｌ造と中味とは資源のタイ
プにより変わる。しかしながら全ての資源７００のへ・
ソダ７０２の部分は構造並びに中味が均一であって、タ
イプのフィールド７０６を介して資源７００のタイプを
検出する。−旦資源７００のへ・・ｌタフ０２が定義さ
れると、資源の中味７０４の中味は定義しうる。
げユＬ−資ゴ、ニーイタ　・　１０Ｂ゛第１０Ｔ３図を
参照すれば、資源７００を作成し、かつ編集するために
使用する本発明によるシステムの資源エディタの構造と
オペレーションとが示されている。第１０Ｂ図には、資
源タイプによりグループ化され、かつタイプａ資源７０
０ａ、タイプｂ資源７００ｂ・・・タイプｎ資源７００
ｎとそれぞれ指示した複数の資源７００が示されている
。
資源エディタ７２２は主資源エディタ７２４と複数のタ
イプを特定したサブエディタ７２６とから構成されてい
る。各資源タイプにはタイプＸのサブエディタ７２６が
あり、第１０Ｂ図に示すタイプＸサブエディタ７２６は
、例えばタイプＸサブエディタ７２６ａ、タイプＸサブ
エディタ７２６ｂ、・・・タイプＸサブエディタ７２６
ｎに対応するよう指示されている。
図示のように、主資源エディタ７２４はユーザ７２８に
対する一部インタフェースを提供し、資源７００を作成
し、資源７００のヘッダ部分７０２を定義し、編集する
装置を含む。主資源エディタ７２４は、資源７００の中
味７０４を編集し、管理するために直接使用されないが
、−旦資源７００が作成され、ヘッダ７０２が定義され
、編集されると、タイプにサブエディタ７２６の中の対
応するサブエディタを呼び出し、呼び出されたタイプＸ
のサブエディタ７２６へのインタフェースを提供する。
呼び出されたタイプにサブエディタ７２６は次いで、資
源７００の中味部分７０４に常駐する資源データを定義
し編集するために使用される。
資源エディタ７２２は、実際の資源操ｆＴの多くを達成
する責任のあるＲＥＳＰＡＣＫＩＩ能への呼び出しをよ
く利用する。その他のプログラムはＲＥＳＰＡＣＫｆｉ
能への呼び出しにより資源を作成したり修正したりでき
る。しかしながら、資源エディタ７２２は資源を作成し
たり修正する一次手段である。
本発明のシステムにおいて、本システムの挙動の多様な
局面を、適当な原始資源に対して自動的にカストマイズ
した資源で代替させる単一の機構を用いて個々のユーザ
に対してカストマイズできる。
カストマイズ可能特性を有するプログラムを構成する場
合、プログラムは各カストマイズ可能特性についてのデ
ータを記憶するために１個以上の資源を使用するように
される。ユーザが特性を変えると、対応する資源のカス
トマイズされたバージョンが作成され、そのユーザのユ
ーザプロフィルに記憶される。その後そのユーザに対し
てカストマイズした形で特性が現われ、一方他のユーザ
には元の形で現われる。、：の作用は、カストマイゼー
ションを示すプログラムとは独立したメカニズムにより
達成される。換言すれば、カストマイゼーションを示す
プログラムが、カストマイズした特性を含むオペレーシ
ョンを実行している堝き、そのプログラムがカストマイ
ゼーションがあったか否かについて心配する必要はない
。これは、−数的な特性のカストマイゼーションはカス
トマイズした資源を利用して達成されるからである。
ＲＥＳＰＡＣＫは自動的に、・必要とされた変更のみ実
行する、即ちＲＥＳＰＡＣＫは自動的に、適当なときに
（即ち、現在のユーザのユーザプロファイルに適当なも
のが介在するときに）資源のカストマイズしたバージョ
ンと代替する。
ＲＥＳＰＡＣＫは特定の資源を（例えばＲＥＳｇｅＬＯ
呼び出しに応答して）検索するとき、特定の資源の資源
ＩＤに対応するエントリに対して、現在開放されている
資源ファイルで割り出し情報を探索する。
もし現在のカストマイゼーションＩＤ（即ちＲＥＳｐｔ
ｃｕｓｔｉｄ（）を呼び出すことによりセットした）が
あり、かつ前記エントリにおいて力ストマイゼーション
フラッグが、資源のカストマイズしたバージョンが介在
しうろことを示すとすれば、ＩＩＥＳｒ’ＡＣＫはユー
ザのユーザプロフィルが、特定の資源ＩＤと現在のカス
トマイゼージョンＩＤを備えたカストマイズした資源を
含むか否か検出する。
ＲＥＳＰＡＣＫはもしカストマイズした資源が介在する
とすればそれを検索するか、あるいは適当なエントリが
見つかった資源ファイルにおいて資源を検索する。
１８．２．　　ストマイゼーションＩＤｓユーザが資源
をカストマイズすると、資源の新しいバージョンが作成
される。この資源のカストマイズしなコピイはユーザの
ユーザプロフィルの一部として記憶される。資源のそれ
ぞれのカストマイズしたコピイはそれにカストマイゼー
ションＩＤと資源ＩＤとを関連づけている。資源ＴＤは
カストマイズされた資源のそれと同じである。カストマ
イゼーションＩＤは、ユーザがカストマイゼーシゴンを
行ったプログラムにより割り当てられる。
カストマイゼーションＩＤはいずれのカストマイズした
資源に対しては一意でない。同じ力ストマイゼーション
ＩＤは同じ範囲のカストマイゼーションが好ましいグル
ープの資源に対して用いられる。典型的には、各オブジ
ェクトタイプに単一のカストマイゼーションＩＤが関連
している。このように、オブジェクトのあるタイプに対
するオブジェクトマネージャの全ては同じユーザのカス
トマイゼーションを明示する。しかしながら、もし特定
のプログラムがその単一のプログラムに対してのみ現わ
れるカストマイゼーションを提供することが好ましい場
合、そのプログラムに関連した１個以上の個別のカスト
マイゼージョンＩＤがありうるはずである。
以下の例はカストマイゼージョン丁りの用途を例示する
。最初に、資源は多くの種々のオブジェクトマネージャ
（例えば全てのスプレッドシートのオブジェクトマネー
ジャおよび全てのドキュメントオブジェクトマネージャ
）により使用されうる。ユーザはドキュメントオブジェ
クトマネージャのカストマイゼーションの能力を利用し
て資源分カストマイズし、資源の修正したコピイを作成
する。このカストマイズしたコピイはドキュメントオブ
ジェクトマネージャのカストマイゼーションＩＤ特性と
関連する。ドキュメントにオペレートしているときはい
つでも、資源のカストマイズしたバージョンが使用され
る。スプレッドシートに対してオペレートするときはい
つでも、スプレッドシートオブジェクトマネージャが別
の力ストマイゼーションＩＤを使用するであろうがら資
源の元のバージョンが用いられる。
１９、＾ＰＰＡＣＫ、呼び　し 以下はアプリケーションパック（＾ＰＰＡＣＫ）により
提供される機能のあるものについての詳細説明を提供す
る。これは当該技術分野の専門家にｒＰＡＣＫ。
の概念と用途の双方と示し、かつ本発明のシステムの前
述した特徴やオペレーションを更に詳細に説明する。
１９．１．１１びｌＰシ　　−ビス 光コＬ この機能は所定のリンクにより特定されたアプリケーシ
ョンを呼び出し、それに５ＴＡＲＴリクエストを送る。
このリクエストに対してはリクエストのオプションは何
らない。呼び出されたアプリケーションが＾Ｐｉｎｉｔ
Ｏを呼び出すと、リンクと、任意のリンク仕様とを受け
取る。この機能は呼び出されたアプリケーションからの
応答を期待し、その応答が受け取られると復帰する。そ
れは呼び出されたアプリケーションとは通信をしない。
入力バラメータ ーこのリンクに対する族オブジェクトのオブジェクトＩ
Ｄへのポインタ ー呼び出すべきオブジェクトへのリンクのＩＤ、もしこ
の値が零の場合、オブジェクトＩＤへのポインタにより
識別されたオブジェクトが直接呼び出される 一リンク仕様の長さ、もし何ら提供されないなら零 一希望に応じリンクを備え、呼び出されたアプリケーシ
ョンへ送られるべきリンク仕様へのポインタ。これはも
しリンクが関連のデータを有するとすればＬＫＦｇｔｓ
ｐｅｃＯを呼び出すことにより得ることができる。もし
このポインタがＮＵＬＬの場合、仕様は何ら送られない
。
出力バラメータ ー無 １９．１．２．＾Ｐｒｅｄｉｔ　　ニーイト　リクエス
トを免ｔ この機能は所定のリンクにより規定されたアプリケーシ
ョンを呼び出し、それにＥＤＩＴリクエストを送る。こ
のリクエストに対しては何らリクエストのオプションは
ない。呼び出されたアプリケーションが＾ＰｉｎｉｔＯ
を呼び出すと、リンクを任意のリンク仕様とを受け取る
。この機能は呼び出しされたアプリケーションからの応
答を期待し、応答が受け収られると復帰する。それは呼
び出されたアプリケーションとの通信は設定しない。
１９．１．３．＾ｌ’ｒ　ｒｅａｄ（”シリクエストを
　。
す− この機能は所定のリンクにより規定されたアプリケーシ
ョンを呼び出し、それにＲＥＡＤリクエストを送る。こ
のリクエストに対しては何らリクエストのオプションは
無い、呼び出されたアプリケーションが＾ＰｉｎｉｔＯ
を呼び出すと、それはリンクとオプションのリンク仕様
とを受け取る。この機能は呼び出されたアプリケーショ
ンからの応答を期待し、応答が受け取られると復帰する
。それは呼び出されたアプリケーションとの通信は設定
しない。
１９．１．４．＾Ｐｒｒｕｎ　　−’−１エストをこの
機能は所定のリンクにより規定されたアプリケーション
を呼び出し、それにＲＵＮリクエストを送る。呼び出さ
れたアプリケーションが＾Ｐｉｎｉｔ（）を呼び出すと
、リンクおよび任意のリンク仕様とを受け取る。この機
能は呼び出されたアプリケーションから返答を期待し、
応答を受け取ると復帰する。それは呼び出されたアプリ
ケーションとは通信を設定しない。
１９．１．５．＾Ｐｒｃｒｅａｔｅ（−リクエストをこ
の機能は所定のリンクにより規定されたアプリケーショ
ンを呼び出し、それにＣＲＥＡＴＥリクエストを送る。
リンクは新しく作成されたオブジェクトへのものである
と規定する。リンクの他に呼び出し元は、サーバアプリ
ケーションから受け取り可能のリンクに対するデータタ
イプ仕様のリストを提供する必要がある。認定されたリ
ンクデータタイプのみを提供すべきである。呼び出され
たアプリケーションが＾ＰｉｎｉｔＯを呼び出すと、リ
ンクとデータタイプ仕様とを受け取る。この機能は呼び
出されたアプリケーションからの応答を期待し、該アプ
リケーションとの通信を設定する。この機能は、否定的
な答が得られるか、満足に通信が設定されると復帰する
。この呼び出しを行った後、アプリケーションはオブジ
ェクト作成プロトコルの残りの部分と共に進行すべきで
ある。
１９．１．Ｔ３．＾Ｐｒ　ｃｈａｎ　ｅｌｉｎｋ　　−
’　ンク　　リフツムＫＬｌｔ この機能は所定のリンクにより規定されたアプリケーシ
ョンを呼び出し、それにＣＩｌ八ＮへＥＬＩＮＫリクエ
ストを送る。リンクは既存オブジェクトに対するものと
想定する。リンクの他に、呼び出し元は、サーバアプリ
ケーションから受け取り可能のリンクに対してデータタ
イプの仕様のリストを提供する必要がある。認定したリ
ンクデータタイプのみ提供すべきである。呼び出された
アプリケーションは八ＰｉｎｉｔＯを呼び出すと、リン
クと、任意のリンク仕様とおよびデータ仕様リストとを
受け取る。
この機能は呼び出しされたアプリケーションからの応答
を期待し、かつ該アプリケーションとの通信を選定する
。この機能は、否定的な応答が受けとられるか、通信が
首尾よく設定されると復帰する。この呼び出しを行った
後、アプリソージョンはリンク変更プロトコルの残りの
部分と共に進められるべきである。
この機能は所定のリンクにより規定されたアプリケーシ
ョンを呼び出し、かつそれにＰＲＴＮＴリクエストを送
る。リンクの他に、呼び出し元はそのリクエストが実行
される要領を示す多数のリクエストのオプションを提供
する必要がある。呼び出されたアプリケーションが＾Ｐ
ｉｎｉｔ□を呼び出すと、リンクと、任意のリンク仕様
と、リクエストのオプションと３受け取る。この機能は
呼び出しされたアプリケーションからの応答を期待する
。もしプリントリクエストモードがＰＲＩＮＴ　ｒＮＴ
ＥＲＡｃＴ以外のものであれば通信がなされる。この機
能は、プリントリクエストモードに応じて、応答が得ら
れるか、あるいは通信が首尾よく設定されると復帰する
。
この機能は所定のリンクにより規定されたアプリケーシ
ョンを呼び出し、それにＬＩＮＫＵＰＤＡＴＥリクエス
トを送る。このリクエストに対しては何らリクエストの
オプションは無い、呼び出しされたアプリケーションが
＾ＰｉｎｉｔＯを呼び出すと、リンクとリンク仕様とを
受け収る。この機能は呼び出されたアプリケーションか
らの答を期待し、それとの通信を設定する。この機能は
、否定的応答が受け取られるか、あるいは通信が首尾よ
く設定されると復帰する。この呼び出しを行った後、ア
プリケーションはリンク更新プロトコルの残りの部分と
共に進められるべきである。
１９．１．９．＾Ｐｒｃｏ　　　−：　ブジェクトをコ
ピイするこの機能は所定のリンクにより規定されたオブ
ジェクトあるいはオブジェクトＴＤをコピイする。
リクエストされるとすれば、新しく作成されたコピイへ
のリンクが特定された親から設定される。
新しいオブジェクトは以下の３（ｌ！ｉＩ所の中の１個
所、即ち呼び出し元により規定された個所、環オブジェ
クトの近く、あるいは原始オブジェクトの近く、で作成
できる。もしオブジェクトが他のオブジェクトに対して
リンクを有しておれば、セラトコピイ状態フラッグを担
持するり゛ンクを有する子供オブジェクトのいずれかも
コピイできる。オブジェクトタイプの定義にそのような
指示がなされていないとすれば、オブジェクトマネージ
ャが呼び出され実際のコピイオペレーションを実行する
。
もっとも＾ｆ’ｒｑｃｏｐｙＯの呼び出し元はこの事実
に気が付かない。
１９．１．１０．＾Ｐｒ　ｄｅｌｅｔｅｌｉｎｋ　　−
リンクを１　、を支 この機能は特定した親オブジェクトからのリンクを削除
する削除後子供のオブジェクトがもはや親のリンクを有
していないならば、子供のオブジェクト自体も削除され
る。オブジェクトタイプの定義にそのように指示されて
おれば、オブジェクトマネージャが呼び出され実際のオ
ブジェクト削除オペレーションを実行する。呼び出し元
はこの事実に気付いていないが。
この機能は所定のリンクにより規定されたオブジェクト
あるいはオブジェクトＩＤを特定された物理的位置まで
動かす、再配置されたオブジェクトまで、あるいはそこ
からの全てのリンクは、このオブジェクトの池の親や子
供が見出せるように調整される。オブジェクトタイプ定
義にそのように指示されるとオブジェクトマネージャは
呼び出され、呼び出し元は気付がないものの実際の再配
置オペレーションを実施する。
この機能はへＰＰＭＣＫオブジェクト環境の外部で作成
されたファイル用のオブジェクトカタログにエントリを
作成する。この機能は情報をオブジェクトレコードに追
加するために０ＢＪＰＡＣＫと共に使用しうる有効な０
ＢＪｒＤを戻す、オブジェクトタイプの定義にそのよう
に指示されるとすれば、オブジェクトマネージャが呼び
出されて、呼び出し先が気が付かないものの実際のオブ
ジェクトレコード作成オペレーションを実行する。この
機能は新しいオブジェクトへのリンクは作成しない。
この機能は特定のオブジェクトのマネージャを呼び出し
所定のリクエストを送る。アプリケーションにはリンク
、いずれかの関連リンク仕様および呼び出し者供給のリ
クエストのオプションが提供される。呼び出し者はまた
、再に通信するため呼び出したアプリケーションとの接
続が設定されるまで待機を依頼できる。この機能はアプ
リケーションがスタートされ、リクエストを確認すれば
復帰する。
この機能はプログラム間で特殊なインタラクションが要
求されるときのみ呼び出されることに注目のこと。その
他アプリケーションの呼び出しのほとんどは標準的なリ
クエスト機能を用いることにより実行すべきである。
入力パラメータ ｍ：のリンクに対する親オブジェクトのオブジェクトＩ
Ｄへのポインタ ー呼び出すべきオブジェクトへのリンクのＴＤ、もしこ
の値が零であるとすれば、オブジェク）ＴＤへのポイン
タにより識別されるオブジェクトが直接呼び出される −呼び出されたアプリケーションへ送られるべきリクエ
ストコード。このコードは標準リクエストコードのいず
れかとコンフリクトしてはならない。
一応答フラッグ：呼び出しされたアプリケーションから
応答が期待されるとＴＲＵＥ。そうでなければＦＡＬＳ
Ｅ。もしＴＲＵＥであれば、成功か否かは問わず新しく
スタートしたアプリケーションから応答が受け取られる
まで機能は待機する。
−接続フラッグ：呼び出しされたアプリケーションとの
通信が希望されるとすればＴＲＵＥ。そうでなければＦ
ＡＬＳＥ。もしＴｒｌｌＪＥであれば、接続が設定され
るまで、あるいはリクエストに対する否定的応答が受け
取られるまで機能は待機する。
−リンク仕様の長さ。何も提供されなければ零 一希望に応じ、リンクと共に呼び出されたアプリケーシ
ョンへ送るべきリンク仕様へのポインタ。これは、もし
リンクが関連のデータを有する場合ＬＫＦｇｔｓｐｅｃ
ｍを呼び出すことにより得られる。
もしこのポインタがＮｔｌＬＬであれば、何ら仕様は送
られない。
一リクエストと共に送るべきリクエストオプションの長
さ、何も提供されなければ零。
−リクエストと共に送るべきリクエストオプションへの
ポインタ、もしこのポインタがＨＵＬＬであれば、何ら
オプションは送られない。
−その「環境」のパラメータとして新しいアプリケーシ
ョンへ通すべきテキストストリングへのポインタのリス
トへのポインタ。このリストはＮＵＬＬのポインタで終
るべきである。
出力バラメータ ーこのオペレーションの間に更に通信すべく使用するた
めに、八ＰＯＰＩＤ（ＡＩ’ＰＡＣにオペレーションＩ
Ｄ）を受け取る変数に対するポインタ。何ら通信が期待
も希望もされないとすれば、このポインタはＮＵＬＬで
あるべきである。
スト処理を　　　　る この機能は＾ＰＰＡＣに通信を初期化し、そのため呼び
出し者はスタートアップリクエストを処理し、マツチメ
ーカオペレーションを実行し、あるいはその他のアプリ
ケーションを開始できる。この＾Ｐｒ’ＡＣＫは他のへ
ＰＰＡＣＫサービスが使用される前に呼び出す必要があ
る。これは、アプリケーションマネージャにより呼び出
されたアプリケーションに送られたスタートアップリク
エストを解釈し、中味を呼び出し者へ戻す。この機能は
このリクエストのそれ以上の処理に使用すべきオペレー
ションＩＤを戻す、もし呼び出し者がアプリケーション
マネージャにより呼び出しされてなかったとすれば、戻
されるリクエストコードはＮ０ＮＥであり、何ら八ＰＯ
ｒ’ｌＤは戻されない。
リクエスト自体の他に、この機能はリクエストに関連し
たいずれのリンクをも戻し、かつリクエストと共に供給
されたリクエスト特定のオプションも戻してしまう。ア
プリケーションは初期化の面この機能を呼び出すものと
想定され、リクエストが非インタラクチブ処理に対する
ものの場合いずれかのユーザには可視のオペレーション
を実行する前に機能の呼び出しを行うべきである。
入力バラメータ ー無 出力バラメータ ー呼び出しアプリケーションにより発行されるリクエス
トコード。もし呼び出しプログラムがアプリケーション
マネージャにより呼び出されていたとすれば、この値は
Ｎ０ＮＥである。
−このリクエストに対する応答フラッグ−もし応答が期
待されればＴＲＵＥ、もしそうでなければＦＡＬＳＥ。
ｍ：のリクエストに対する接続希望フラッグ−もし通信
が希望されるならばＴＩＩＵＥ、もしそうでなければＦ
ＡＬＳＥ　。
−このオペレーションの間それ以上のアクティビティに
使用する＾Ｉ’０ＰＩＤ、このＩＤは、もし応答を発す
るならば＾Ｐｒｅｐｌｙ□に提供すべきである。
−提供された０ＢＪＩＤにより規定されるオブジェクト
タイプ。もしオブジェクトの名前がリクエストと関連し
ていないならば零。
一リクエストを実行すべきオブジェクトのオブジェクト
ＩＤ。このフィールドはもしオブジェクトタイプフィー
ルドが零であれば埋められない。
−省略値し−プから割り当てられ、特定されたオブジェ
クトを記述するオブジェクトカタログレコードからの属
性に関する情報を含むデータのブロックに対するポイン
タ。このポインタはオブジェクトに関する詳細情報を抽
出するため０ＢＪＰＡＣにまで通される。もはや必要が
なくなれば、このブロックに割り当てたスペースはＩＩ
ＰｔｒｅｅＯを呼び出すことによりヒープに戻すべきで
ある。ＮＵＬＬのポインタは何らオブジェクトが提供さ
れなかったことを示す。
一アプリケー、ジョンを呼び出すことにより送られるリ
ンク仕様の長さ。もしこの値が零であれば、リクエスト
に伴い何らリンク仕様が送られなかったことを示す。
一省略値ヒープから割り当てられたリンク仕様に対する
ポインタ。もはや必要とされなければ、リンク仕様に割
り当てられたスペースは１ＩＰｆｒｅｅＯを呼び出すこ
とによりヒープに戻すべきである。
ＨＵＬＬのポインタはリンク仕様が何ら送られなかった
ことを示す。
一アプリケーションを呼び出すことにより送られたリク
エストオプションの長さ、もしこの値が零であれば、リ
クエストを共に何らオプションが送られていなかった。
一へＰＰＡＣＫオプション栴造の１つあるいは非識別の
バイトのストリングとして、発せられたリクエストに応
じてフォーマット化され、省略時ヒープから別り当てら
れたリクエストオプションに対するポインタ。ＨＵＬＬ
ポインタは、リクエストオプションが何ら特定されなか
ったことを示す。
この機能は＾Ｐｉｎｉｔ□から受け取られたリクエスト
に対して、あるいは実行中のオペレーションに対して応
答を送る。この機能は、呼び出しアプリケーションは応
答を待機しているので、八ＰＩＮＩＴの「返答」フィー
ルドがＴｒｌＵＥにセットされると常に呼び出される。
＾ＰｉｎｉＬＯの後呼び出され、応答が５ＵＣＣＥＳＳ
でないとすれば、オペレーションは停止され、通信は設
定されない、もし返答が５ＩＪＣＣＥＳＳであり、呼び
出しアプリケーションと呼び出し者の双方が通信を設定
したいと所望すれば、使用可能接続が設定される。もし
呼び出しアプリケーションあるいは呼び出し者のいずれ
かが通信を所望しなければ、何ら通信は設定されない、
ＡＰｉｎｉｔＯ後以外で呼び出しされるとすれば、ｒｃ
ＯＮＮＥｃＴ。
パラメータが否定される。
注：もし応答状磐が５ＵＣＣＥＳＳ以外であれば、ある
いはもし接続が希望されなければ、オペレーションＩＤ
はこの呼び出しにより無効とされる。そのような場合に
、＾ＰｏｐｆｉｎｉｓｈＯを呼び出す必要はない。
入力バラメータ ー＾ＰｉｎｉｔＯまたは＾Ｐ＋＊ｍｒｅｓｅｒｖｅによ
り戻される、応答を送るべきオペレーションのＩＤ。
−リクエストしているアプリケーションに戻すべきエラ
ーコード、あるいはリクエストが受け入れられたとすれ
ば５ＵＣＣＥＳＳ。
−接続フラッグ：もし呼び出しアプリケーションとの通
信が所望されればＴＲＵＥ、あるいは何ら接続が必要と
されなければＦＡＬＳＥ、 出力バラメータ ー無 この機能は、呼び出し者がへＰＰＡＣＫメツセージを待
機できるようυＩＰＡＣＫイベント仕様構造を初期化す
る。この機能は「マツチ」メツセージ、オペレーション
リクエストおよび返答、およびバッフアマネジメントイ
ベントとを含む、この機能は構造のアレイの１エレメン
トを充てんする。呼び出し者はｔｌｌＶｓＰＥｃ構造の
アレイに対してスペースを割り当てるか、とっておき、
かつこれら構造の１個に対するポインタをこの機能に通
す。リストターミネータを含む、アレイの他のエレメン
トを充てんするのは呼び出し者の責任である。この使用
を用いて受け取られたイベントは、それらの目的や中味
を検出するため＾Ｐｍｓｇｔｅｓｔ□へ通すべきである
。
＾ＰｉｎｉｔＯはこのｉ能を呼び出す前に首尾よく呼び
出されたものと想定する。
入力バラメータ ー無 出力パラメータ　　　□ 一＾ＰＩ”ＡＣＫメツセージイベントを待機できるよう
にするに必要な情報で充てんすべきＵＴＶＳＰＥＣｆｉ
Ｎ造に対するポインタ この機能は所定のＵＩＰＡＣＫアクションコードとデー
タとを前に準備されていた＾ＰＩ’ＡＣＫイベント仕様
リストエレメントに関連づける。このエレメントは１個
以上のりストエントリを含みうるので、呼び出し者がこ
れらコードをセットするのは実用的でない。にの機能は
、へＰｒ’ＡＣＫイベントリストエレメントと共にイベ
ント仕様リストが、イベントアクションを支援する高レ
ベルのイベント処理パッケージに提供すべき場合に呼び
出すべきである。
入力バラメータ ー＾ＰｅｖｉｎｉｔＯにより準備されていたＵＩＶＳＰ
ＥＣ構造に対するポインタ ーへＰＰＡＣＫイベントに関連すべきアクションコード 一＾ＰＰＡＣＫイベントに関連すべきアクションデータ 出力バラメータ ー無 この機能は、へＰＰＡＣＫメツセージを待機するために
イベント仕様エレメントに割り当てられたスペースを空
ける。この機能は、もし前に準備されたイベント仕様が
それ以上使用されないと呼び出すべきである。
入力バラメータ ー＾Ｐｅｖｉｎｉｔ□により準備されたυＩＶＳＰＥＣ
機構に対するポインタ 出力バラメータ ー無 この機能は提供された旧ＰＡＣにイベントレコードをテ
ストして、それが進行しているオペレーションと関連し
ているへＰＰＡＣＫメツセージイベントであるか否か検
出する。もしそうであれば、この機能は関連の、メツセ
ージの性質を示すフラッグと、それが属するオペレーシ
ョンのオペレーションＩＤとを戻す。その結果によって
、呼び出し者は多数の他の＾ｒ’ｌ’ＡｃＫｆｉ能の中
の１つを呼び出し、メツセージをさらに解釈するものと
思われる。
入力バラメータ ーテストすべきイベントレコードに対するポインタ 出力バラメータ ーメツセージイベントが属するオペレーションのＩＤを
受け取る変数へのポインタ、この変数は、もしイベント
レコードが八ＰＰＭＣにオペレーションに属していなけ
ればＨｔｌＬＬにセットされる。
−提供されたメツセージイベントのタイプを示すフラッ
グを受け取る変数に対するポインタ。
以下は可能なタイプのリストである。
＊＾ＰＰＡＣＫマツチメーカのマツチメツセージ−通知
されたオペレーションは別のアプリケーションによりマ
・フラッグされた。
＊＾Ｉ’ＰＡＣＫリクエストメツセージ−メツセージを
解釈するため＾Ｐｍｓｇｒｅｑｕｅｓｔ□を呼び出す。
＊＾ＰＰＭＣＫオペレーション終了メツセージ＾Ｐｏｐ
ｆ　１ｎｉｓｂＯを呼び出しオペレーションを終了させ
る。
＊最近完了した運動オペレーションを取り消すリクエス
ト−ＭＯＶＥ　　ＵＮＤＯプロトコルに従う。
＊新しいオペレーションに対するリクエストを含むへＰ
ＰＡＣＫメツセージ−＾Ｐ＋Ｉｌｓｇｎｅｗｒｅｑ□を
呼び出してメツセージを解釈する。
＊データ交換ストリームメツセージ−現在の交換取得機
能を呼び出す。
＊オペレーションの他方の終りにおけるアプリケーショ
ンにより送られた専用プロトコルメツセージ−＾ＰＰＡ
ＣＫにより解釈されず。
＊＾ＰＰＡＣＫにより扱われる内部コントロールメツセ
ージ−それを否定し、継続する。
＊＾ＰＩ’ＡＣＫでないメツセージ。
この機能は、ＲＩＯＰＡＣＫサービス（その上に各種の
データ交換機能が構成される再方向変換可能■／Ｄ）を
用いる標準的なデータ交換サービスのいずれかとのデー
タ交換を実施するために使用しうるＲＩＯｒＤを戻す、
提供されなＲＩＯＩＤは特定のオペレーションＩＤと関
連した、前に設定された接続に基いている。データ交換
が完了すると、呼び出し者は他のへＰＰＡＣＫアクティ
ビティ用のオペレーションＴＤを使用し続けるか、ある
いはオペレーションを終了するために＾Ｐｏｐｆｉｎｉ
ｓｈＯを呼び出すことができる。
入力バラメータ ーそのために旧０１０を戻すべきオペレージョンのＩＤ
。
出力バラメータ ーこのオペレーションと関連したＲＩＧＩＤを受け取る
ための変数に対するポインタ この機能は、特定のオペレーションと関連したイベント
を特に待機したいアプリケーションの利益のために提供
される。このａ能は、このオペレーションと関連した使
用可能の接続があるものと想定する。この機能はオペレ
ーションの他方の終りにおいてアプリケーションから到
来するメツセージを待機する。呼び出し者は、希望する
メツセージが到来する前に＾Ｐｍｓｇｗａｉｔ□が戻る
ようにさせるイベントのリストを供給しうる。さらに、
呼び出し者は待機のためのタイムリミツトを規定しうる
。次いで、イベントレコードポインタが、さらに処理す
るための（＾Ｐｍｓｇｒｅｑｕｅｓｔ□）のような＾Ｐ
ｓｅｓｇ（＞解釈機能の１つに通すことができる。
入力バラメータ ーメツセージが期待されているオペレーションのＩＤ。
一希望するメツセージが到来する前にこの機能を戻すよ
うにさせるべきイベントを記述した、イベント仕様のア
レイに対するポインタ。詳細についてはＩＪＩＩ’ＡＣ
に仕様を参照のこと。もしこのポインタがＨＵＬＬであ
るとすれば、この機能はメ・ソセージが到来するか、タ
イムリミツトが消滅するまで待機する。
一受け取りの待機を停止する前に待機すべきミリ秒の数
、零の値は、この接続のへＰＰＡＣＫ省略値が用いられ
るべきことを示す。−＾ＩＴ　ＦＯＲＥＶＥＲの値はそ
の意味するところを意味する。
出力バラメータ ー提供されたメツセージイベントのタイプを示すフラッ
グを受け取る変数に対するポインタ・メツセージタイプ
は＾Ｐｎｓｇｔｅｓｔ□により戻されるものと同じであ
る。
一本機能を早期に戻してしまったイベントレコードで充
てんすべき構造へのポインタ。このレコードは、希望す
るメツセージが到来するかあるいは機能がタイムアウト
すれば充てんされない。
このポインタは、もしイベントレコードが希望でなけれ
ばＨＵＬＬでよい。
この機能は、呼び出し者が供給したいずれかのリクエス
トオプションと共に、オペレーション接続の他端におい
てアプリケーションに特定されたリクエストを送る。他
端におけるアプリケーションは＾ＰｍｓｇｔｅｓｔＯが
タイプ＾ＰＭＳＧＲＥＱＩＪＥＳＴと解釈するメツセー
ジイベントを受け取る。もし応答が希望されると、この
機能は、他方のアプリケーションがリクエストを受け取
り確認すると復帰する。
入力バラメータ ーリクエストを送るべきオペレーションのＩＤ。
一他のアプリケーションに送るべきリクエストコード。
一応答フラッグ：もし応答が呼び出したアプリケーショ
ンから期待されるとＴＲＵＥ、もしそうでなければＦＡ
ＬＳＥ。もしＴＲＵＥであれば、本機能は成功の如何を
問わず新しく開始したアプリケーションから応答が受け
取られるまで待機する。
−リクエストと共に送るべきリクエストオプションの長
さ。
一リクエストと共に送るべきリクエストオプションを含
む構造に対するポインタ。もしこのポインタがＮＩＪＬ
Ｌであるとすれば、オプションは何ら送られない。
出力バラメータ ー無　　　　　′ この機能はタイプ＾ＰＭＳＧＲＥＱＵＥＳＴの＾Ｐｒ’
ＡＣＫ、メツセージを解釈し、リクエストについての詳
細を戻す。
リクエスト自体の池に、この機能はリクエストと共に供
給されたいずれかのリクエスト特定のオプションを戻す
。応答フラッグは、リクエスト自体が処理される前に、
送り出されているアブリゲージョンがこのリクエストに
対する応答を期待しているか否か指示する。
入力バラメータ ー＾ＰｍｓｇｔｅｓｔＯにより戻された際、リクエスト
を適用すべきオペレーションのＩＤ。
−メツセージ用のイベントレコードに対するポインタ。
、　出力バラメータ ー池方のオペレーションにより送られるリクエストを受
け取る変数に対するポインタ。
−他方のオペレーションにより送られる応答フラッグを
受け取る変数に対するポインタ。もし応答が期待される
ならＴＲＵＥ、そうでなければＦＡＬＳＥである。
一他方のオペレーションにより送られるリクエストオプ
ションの長さを受け取る変数に対するポインタ。もし戻
された長さが零であれば、リクエストと共に何らオプシ
ョンが送られなかったのである。
−発せられたリクエストに応じて、＾ＰＰＡＣＫオプシ
ョンｔＭ　Ｆの１つとして、あるいは非識別のバイトの
ストリングとしてフォーマット化された、リクエストオ
プションに対するポインタを受け取る変数のポインタ、
ＮυＬＬのポインタは何らリクエストが特定されなかっ
たことを示す。
この機能は進行中のオペレーションを停止させる。この
機能は理由を問わず、オペレーションの現在の状態にか
かわらずオペレーションを停止すべきときはいつでもこ
の機能が呼び出される。もしオペレーションが現在２つ
の接続されたアプリケーションから構成されているとす
れば、タイプ八ＰＭＳｆｌ：Ｆ　Ｉ旧Ｓ）Ｉのメツセー
ジが他方のアプリケーションに送られる。この呼び出し
者は停止の理由を指示するエラーコードを供給し、５Ｕ
ＣＣＥＳＳが文字通りの意味であればオペレーションの
終りにおいてオペレーションの停止を同意する。もしタ
イプＡＰＭＳＧＦ　Ｉ旧ＳＨの＾ＰＰＡＣにメツセージ
が受け取られるとすれば、他方のアプリケーションの停
止信号と、該オペレーションに割り当てられたフリーメ
モリを取得するためにこの機能も呼び出すべきである。
この場合、　５ＵＣＣＥＳＳは状態を示すものとして送
るべきである。
入力バラメータ ー停止すべきオペレーションのＩＤ −他方のオペレーションに送るべき状邪のコード 出力バラメータ ー他方のアプリケーションにより送られた停止状暦コー
ドを受け取るための変数へのポインタ、この値はもし呼
び出し者が最初にオペレーション停止するのであれば、
戻されない。
この機能は特定のオペレーションに対するマツチメーカ
の一方の側を予約する。マツチメーカは、オペレーショ
ンの半分の細部についてのユーザ仕様が進行している間
マツチメーカを予約しておくべきである。−旦ユーザ仕
様が完了すると、へＰｍ餉ｐｏｓｔＯを呼び出すことに
よりオペレーションに通知すべきである。このオペレー
ションの他の＾Ｐｔａｔａｒｅｓｅｒｖｅ（＞またはＡ
Ｐ＋ｍｐｏｓｔ□リクエストは、マツチメーカの予約さ
れている間は許容されない。
このリクエストを受け入れないようにするオペレーショ
ンが現在通知されると、進行中のオペレーションを記述
したエラーコードが戻され、そのためユーザに適当に通
知できる。もしマツチメーカの状磐が＾ＰＮＭＹＯＩＪ
Ｒ５ＥＬＦであれば、同じプロセスが通知されたマツチ
メーカの対応する他方の側を有していることを示す。呼
び出し者はこの点でオペレーションを停止するか、八Ｐ
ｍｍｐｏｓｔ□を継続しマツチをチエツクするか遷択で
きる。
入力バラメータ ーマツチメーカを予約しておくべきオペレーションのコ
ード： ＊コピイオペレーション ＊移動オペレーション ＊共川オペレーション ＊マルチコピイオペレーション ＊オブジェクトコンバートアウトオペレーション ＊プレースオペレーション ＊リンクのみ許容したプレースオペレーション ＊リンクを許容していないプレースオペレーション ＊オブジェクトコンバートインオペレーション 出力バラメータ ー所定のオペレーションに対応するマツチメーカの他方
の側の現在の状態を示すフラ・フグを受け入れる変数の
ポインタ。この変数はマツチメーカを予約できない場合
変更されない。
＊他方の側はまだ通知せず ＊他方の側はすでに通知し、待機中 ＊他方の側は通知し、リンクのみ期待中＊他方の側は通
知したが、リンクを受け入れること不可能 ＊他方の側は自身により通知ずみ 一進行中のオペレーションＩＤを受け入れる変数のポイ
ンタ、このＩＤはいずれか他の使用がなされる前に八Ｐ
１１１ＭＩ）Ｏ！ＩＩＬＯまたは＾ＰｍｍｃｌｅａｒＯ
まで送る必要がある。
この機能は、マツチメーカに対する進行中の交換オペレ
ーションの半分を通知する。＾Ｐｍｍｒｅｓｅｒｖｅ（
）はそのオペレーションに対してマツチメーカを予約す
るために先に呼び出しずみとなっている。
呼び出し者は、本オペレーションを完成させることに合
意する別のアプリケーションに対して提供しうる、ある
いはそこから受け取られうるデータ交換のタイプを記載
した情報を提供する必要がある。もしこの機能が５ＵＣ
ＣＥＳＳを戻し、かつ戻されたマツチメーカの状態が＾
ＰＮＮＭ＾ＴＣＨまたは＾ＰＭＭＹＯＵＲＳＥＬＦであ
るとすれば、マツチが発生したこと、およびマツチイベ
ントが何ら到来していないものと恵定しうる。状態が＾
ＰＭＭＮＯＭ＾ＴＣＨであるとすれば、呼び出し者は＾
Ｐｏｐｆｉｎｉｓｈ□を呼び出し、ユーザに通知すべき
である。
入力バラメータ ー通知すべきオペレーションのＩＤ。
−通知アプリケーションにより提供あるいは受け入れ可
能のデータタイプを記述し、＾ＰＤＡＴＡＬＩＳＴＥＮ
Ｄにセットされた「データタイプ」を備えたエントリに
より停止された＾ＰＤＡＴＡＳＰＥＣ１７１造のアレイ
に対するポインタ。
出力バラメータ ー所定のオペレーションに対応するマツチメーカの他方
の現在の状態を示すフラッグを受け入れるポインタへの
ポインタ。マツチメーカに通知できなければこの変数は
変わらない。
ネ他方の側はまだ通知されず一待機 ＊他方の側は通知されたがマツチメーカは可能でない ネ他方の側は通知され、一致が判明した＊他方の側は通
知され、自身でマツチングされた −もしマツチメーカの状態が八ＰＭＨＭ＾ＴＣ１１また
は＾ＰＭＭＹＯＵＲ５ＥＩ、Ｆであれば、他方のアプリ
ケーションが通知したオペレーションコードを受け取る
変数へのポインタ。
この機能は、呼び出し者の通知したオペレーションとマ
ツチしたアプリケーションとの通信を設定する。この機
能の呼び出しは、アプリケーションマネージャから八Ｐ
ＮＳにＭ＾ＴＣＩ＋メツセージを受け取り、あるいは＾
ＰｍｍｐｏｓＬ□からＡＰＭＭＭ＾ＴＣＨ状態を受け取
った後であるべきである。この機能は他方のアプリケー
ションにより通知されたオペレーションコード、および
マツチしたデータ仕様のカウントとリストとを戻す。（
通信ＰＬＡＣＥ側にある）コンシューマアブ・リケーシ
ョンはこの機能を呼び出した後データに対する特別のリ
クエストを出すものと思われる。この機能により戻され
た＾ＰＯＰｒＤは＾ＰＰＡＣＫリクエスト機能のいずれ
か、およびデータ交換サービスを用いて、データを送っ
たり、受け取ったりするために使用できる。＾Ｐｏｐｆ
ｉｎｉｓｈＯはこのｆｉｆｉｔが不首尾のときに呼び出
すべきである。さもなければ、接続が設定されるとマツ
チメーカがクリヤーされる。
入力バラメータ ー接続が希望されるオペレーションのＩＤ出カバラメ−
タ ー他方のアプリケーションが通知したオペレーションコ
ードを受け取る変数に対するポインター２種類のアプリ
ケーションの間でマツチしたデータタイプの数のカウン
トを受け取る変数に対するポインタ −２種類のアプリケーションの間でマ・ソチしたデータ
タイプを記述し、「データタイプ」を＾ＰＤＡＴＡＬＩ
ＳＴＥＮＤにセットしたエントリにより停止された＾Ｐ
ＤＡＴＡＳＰＥＣ構造のアレイへのポインタを受け取る
変数に対するポインタ、もしポインタがＮＩＪＬＬであ
るとすれば、仕様は何ら戻されない。これ以上必要とさ
れないのであれば、アレイにより使用されたスペースを
ヒープへ戻すようＨＰｒｒｅｅｏを呼び出すべきである
。
この機能はリンク交換ストリームの構成を開始する。新
しいストリームが現在の交換ストリームとなる。−時に
使用中のリンクストリームは１個のみしかありえないこ
とに注目のこと、この機能を呼び出した後、地方のＬＮ
ＸｐＯｆｉ能を用いてリンクおよびリンクデータとをス
トリームに入れる。二とができる。
この機能はリンク交換データを受け入れるために、特定
の接続に対して現在使用中のストリームをリセットする
。この機能ははめ込まれたリンクを交換データの別のタ
イプへ挿入するか、あるいは前のリンクのデータに対し
て別のデータタイプに切り換えた後リンクを送り始める
ために呼び出しできる。この機能は新しいストリームを
作成することができない、ストリームは現在のリンク交
換ストリームとなる。この機能を呼び出した後、他のＬ
ＮＸｐ０１能を用いてリンクとリンクデータとをストリ
ームに投入することができる。
この機能は既存のリンクを現在のリンクのストリームに
入れる。親のオブジェクトは前に定義したリンクを有し
ており、いずれかの関連したリンク仕様とデータとが前
に識別したリンクファイルに記憶されているものと想定
される。リンクの他に、該リンクに関連した仕様とデー
タとがストリームに入れられる。リンクの挿入を完了さ
せるために、他の交換サービスへの呼び出しは必要でな
い。このＩ！能は多数のリンクを現在のストリームに投
入するため１１３１Ｍし呼び出せばよい。
この機能は現在のリンクのストリームで新しいリンクを
構成する。呼び出し者は、リンクを設定すべきオブジェ
クトのＩＤを供給する。受け取る方のアプリケーション
は、それがリンク交換情報を受け取るとオブジェクトへ
リンクを正式に設定する。リンクに関連したリンクデー
タがあるとすれば、データフラッグはセットし、かつ有
効なデータタイプとリンク仕様を提供すべきである。次
いで呼び出し者は適当な交換サービスを用いてリンクデ
ータをストリームにセットすべきである（ＸＸＸｐｒｅ
ｓｔａｒｔ　（）機能への呼び出しから開始する）。
ＬＮＸｐｒｅｓｔａｒｔ（）は終了するとリンクストリ
ームへ戻るよう呼び出される。この機能は多数のリンク
を現在のストリームに入れるために繰り返し呼び出せば
よい。
このＩＩ能は現在のリンク交換ストリームの構成を終了
する。もしリンク交換が別のデータタイプ内にはめ込ま
れていたとすれば、再びそのデータタイプは現在のデー
タタイプとなり、ＸＸＸｐｒｅｓｔａｒｔＯｆｉ能を使
用してデータを送り続けるべきである。
もしストリームが最初にリンク交換ストリームであった
場合、この機能がストリームを完成させ、バッファされ
たいずれかのデータを接続の他端でコンシューマへ送る
。この機能は接続を終了させはしない。
この機能は新しいリンク交換ストリームの読取りを開始
する。新しいストリームが現在交換ストリームとなる。
−時に使用中のストリームは１個しかありえないことに
注目のこと。リンク交換データは所定の接続上を到来し
ているものと想定される。この機能を呼び出した後、他
方のＬＮＸｇ□機能を使用してストリームからリンクお
よびリンクデータを取得できる。
この機能は特定の接続にストリームをリセットしてリセ
ット交換データを読取る。この機能は、別のタイプの交
換データにはめ込まれたリンクを読取り、あるいは前の
リンクのデータに対して別のデータタイプに切り換えた
後リンクの読取りを再Ｅするよう呼び出すことができる
。この機能を呼び出した後、他のＬＮＸｇ　０機能を用
いてストリームからリンクおよびリンクデータを読取る
ことができる。
この機能は現在のリンク交換ストリームで次のリンクを
取得する。この機能は指示された親オブジェクトに対す
るリンクを作成し、いずれかのリンク仕様と関連のデー
タとを指示されたリンクファイルに記憶し、新しいリン
クを識別すべくリンクＴＤを戻す。リンクに関連したコ
ピイフラ・ソゲが指示すれば、オブジェクトはコピイさ
れ、リンクは新しいオブジェクトに対して設定される。
新しいリンクはオブジェクトカタログとｎ　自し、その
ため親オブジェクトが新しいリンクを担持するものとし
て整合する。またこの機能はリンクされたオブジェクト
のオブジェクトタイプと、データがリンクに関連してい
るか否か指示するフラッグと、介在した場合のデータの
データタイプとを戻す。
ＬＮＫｇｉｎｉｔ（）またはＬＮＸｇｒｅｓｔａｒｔ　
□を呼び出しているときに何らリンクファイルが特定さ
れていなかったとすれば、リンク仕様とデータとは棄却
される。データを記憶するためのリンクファイルが全く
利用できないとしてもフラッグとデータタイプとは戻さ
れる。現在のストリームから多数のリンクを収得するた
めにこの機能を縁り返し呼び出せばよい。
この機能は現在のリンク交換ストリームにおける次のリ
ンクについての情報を戻す。この機能は実際にはリンク
を作成しない。この機能は、リンクのオブジェクトタイ
プあるいはデータタイプをリンクを受け取る前に検査す
る必要のあるＪ′％会に使用すべきである。この機能を
呼び出した後は、ＬＮＸｇｌｉｎｋＯまたはＬＮＸｇｓ
ｋｉｐＯを呼び出してリンクを処理すべきである。
１９．４．１０．　ＬＮＸ　ｓｋｉ　　　−ストリーム
で２８のりこの機能は現在のリンク交換ストリームで次
のリンクをスキップする。ＬＮＸｇｐｅｅｋ　Ｏが丁度
リンクを検査するために呼び出され、かつエラーを戻し
ていないものと想定する。この機能を呼び出した後、Ｌ
ＮＸｇｌｉｎｋＯまたはＬＮＸＨｐｅｅｋＯのいずれか
を呼び出して次のリンクを処理すべきである。
この機能は現在のストリームがらのリンク交換データの
読取りを終了する。もし別のデータのタイプにリンク交
換がはめ込まれていたとすれば、そのデータタイプは再
び現在のデータタイプとなり、そのＸＸＸｇｒｅｓｔａ
ｒｔ□機能を用いてデータの読取りを継続すべきである
。もしストリームが初めはリンク交換ストリームであっ
たとすれば、この機能はストリームの処理を終了し、そ
れ以上は使用できない。通常この機能は、ＬＮＸｇ　ｌ
　ｉ　ｎｋ　ＯまたはＬＮＫｇｐｅｅｋ（）がＬＮＸＥ
ＥＮＤを戻した後のみ呼び出されるべきであるが、リン
ク交換ストリームを処理している間はいつでも呼び出す
ことができる。
この機能はテキストストリームの構成を開始する。新し
いストリームが現在の流れとなる。所定の接続に対して
作用するのは１個のストリームのみであることに注目の
こと。この機能を呼び出した後、他のＴＸＸｐＯｆｉ能
を用いてテキストとテキストデータをストリームに入れ
ることができる。省略値がストリームでのヘッダ情報の
一部として転送され、かつ後で転送できるように記憶さ
れる。
この機能は特定の接続において現在使用中のストリーム
をリセットしてテキストを受け入れる。
この機能はテキストを別のタイプの交換データへ挿入す
るか、あるいは前にはめ込んでいたデータ用の別のデー
タタイプに切り換えた後テキストの転送を再開するため
に呼び出すことができる。この機能は新しいストリーム
の作成はできない。ストリームは現在の交換ストリーム
となる。この機能を呼び出した後、その他のＴＸＸｐＯ
機能を用いてテキストをストリームに入れることができ
る。
この機能はテキストのストリングを現在のテキストスト
リームへ入れる。このストリングはテキストのレイアウ
トを制御するためにラインフィードとフオームフィード
とを含みうる。これらのキャラクタを備えないストリー
ムは、受け取る方のアプリケーションと文脈とに応じて
異なる要領で扱われる。この機能はまた、行間の間隔に
明らかに垂直降下移動指令が与えられると有用なキャリ
ッジリターンを含むこともできる。
この機能は単一のキャラクタを現在のテキストのストリ
ームへ入れる。
１９．５．５．　ＴＸＸ３ｆｏｎＬ□　　　ｔのフォン
トを齋えるこのｌ！能はセットされたフォント指令を現
在のテキストストリームへ挿入し、後続のキャラクタの
フォントを変える。もしフォントのｉｄとして０の値が
通されると、フォントは伝送の開始時に特定された省略
時フォントにセットされる。
この機能は使用可能／使用不能属性指令を現在のテキス
トのストリームに挿入する。この指令は、保持、アンダ
ライニング、ダブルアンダライニングおよびストライク
スルーというテキストの属性をセット／リセットするた
めに使用される。これらの値は再びこの指令により変え
られるまで有効のままである。
この機能は区別的発音符を備えたキャラクタを現在のテ
キストの流れに挿入するために使用される。
１９．５．８．　ＴＸＸ　５ｔｒｉｋｅＬｈｒｕ（−ス
トライクスルこの機能はストライクスルーキャラクタ命
令を現在のテキストストリームへ挿入する。
この機能はセットされたスクリプトオフセット指令を現
在のテキストストリームへ挿入する。
セットされたスクリプトオフセット指令はテキストのベ
ースラインに対する次のスクリプト（スーパ、あるいは
サブ）の距離と方向とをセットするために使用される９
（スクリプトオフセットをフォントサイズの省略値にセ
ットし戻すために）プリントする際有効である零の値は
、テキストめ伝送時に通されるとエラーを戻す。
この機能は垂直降下移動指令を現在のテキストの流れへ
挿入する。垂直降下移動指令は行間間隔に対して、ある
いは大きな白紙の部分をスキップするために使用される
。この移動は水平位置には影響を与えないため、前のテ
キストにキャリッジを戻して後続させるべきである。
この機能は水平移動指令を現在のテキストストリームへ
挿入する。水平移動指令により左右への運動を許容する
。ストライクスルーとアングライン属性とを白紙部分に
適用したり（ペンダウンで移動）あるいは適用しない（
ペンアップ移動）ようにできる。
１９．５．１２．　ＴＸＸ　ｓ　ａｃｉｎ　（−’−ｕ
　ｎ　　　Ａこの機能はセットされた行間間隔指令を現
在のテキストストリームへ挿入する。セットされた行間
間隔指令が所定のフォントに対して省略時間隔をオーバ
ライドするよう使用される。もし得られた値が正であれ
ばその値は自動スペーシングに使用され、もしその値が
０であれば、自動スペーシングは何らなされない、もし
その値が負であれば、省略時価が再び使用される。
１９．５．１３．　　ＴＸＸｌｌａｎ　　ｕａ　　ｅ　
　　　−’＝’五ｇ　　　　　　　　を出」１ この機能は言語変更指令を入力ストリームへ挿入する。
この指令はその後のテキストが異なる言語であることを
指示するために使用される。
この機能は別のオブジェクトへのリンクを現在のテキス
トのストリームへ挿し始める。この機能を呼び出した後
、ＬＮＸｐｒｅｓｔａｒｔ□を呼び出して他のＬＮＸｐ
ＯＮＸへの呼び出しを準備すべきである。
リンクを挿入することは、リンクの実際のデータを舎人
するために他のデータ交換タイプも含むことができる。
全体のリンクが送られた後、ＴＸＸｐｒｅｓｔａｒｔ（
）が呼び出されテキストストリームを再び送り始めるべ
きである。
この機能は現在のストリームへのテキスト交換データの
構成を終了する。もし別のデータタイプにテキスト交換
がはめ込まれると、そのデータタイプが再び現在のデー
タタイプとなり、そのＸＸＸｐｒｅｓｔａｒｔ（）ｆｉ
能を用いてデータを送り続けるべきである。もしストリ
ームが初めテキスト交換ストリームであったとすれば、
この機能はストリームを完成させ、いずれかのバッファ
したデータを接続の他端においてコンシューマへ送る。
この機能はテキスト交換ストリームの読取りを開始する
ゆこの機能はストリームの第１の部分が接続の他端から
到来し、次いでテキストについての省略時の情報をスト
リームに戻すのを待機する。
新しいストリームは現在の交換ストリームとなる。
所定の接続において使用可能の流れは１つのみでありえ
ない、この機能を呼び出した後、他のＴＸＸｇ（）機能
が使用され流れからテキストデータを取得するために使
用できる。
１９．５．１７．　ＴＸＸ　ｒｅｓｔａｒｔ　　−スト
リームをバニラ−ストに１セツト　る この機能は特定の接続で現在使用中のストリームをリセ
ットしてテキスト交換データを読取る。
この機能は別のタイプの交換データにはめ込まれたテキ
ストを読取り、あるいは前にはめ込んでいたデータに対
する別のタイプに切り換えた後テキストの読取りを再開
するよう呼び出しできる。ストリームは現在の交換スト
リームとなる。この機能を呼び出した後、−他のＴＸＸ
ｇ□機能を用いてストリームからテキストデータを読取
ることができる。
このルーチンは入力ストリームにおけるデータの次のタ
イプを検出する０次いで、そのデータを処理するのは呼
び出し者の責任である。データを検索することのないこ
のルーチンへの第２の一連の呼び出しはデータをスキッ
プし、入力ストリームにおける次のデータのタイプを戻
す。この機能はデータ指示の終りを戻す。
注：もしタイプがＴＸＸＬＩＮＸであるとすればＬＮＸ
ｇ□機能をＴＸＸｇｒｅｓｔａｒｔ□への呼び出しに続
いてリンりを取得するよう用いてテキストの取得を続行
すべきである。
この機能は、ストリームにおいて次にあるテキストのス
トリングの長さを戻す、この長さを用いてＴＸＸｇｔｅ
ｘｔＯへの呼び出し用バッファを準備すべきである。
この機能は現在のテキストストリームからテキストのス
トリングを取得する。
この機能は入力ストリームから単一のキャラクタを取得
する。
この機能は、入力ストリームにおいて次である、セット
されたフォント指令に規定されたフォントを戻す、もし
セットされたフォント指令が入力ストリームにおける次
のデータタイプでないとすれば、Ｍｆ＆にセットされた
フォント指令に規定された現在のフォントが戻される。
もし省略時のフォントがセットされでいないとすれば、
零フォントが戻される。
この機能は、入力ストリームにおいて次である使用可能
／使用不能属性指令からの属性値を戻す。
そのような指令が次でないとすれば、この機能はこれま
で出会った最後のそのような指令からの値あるいは省略
値（即ち全ての属性が無い）を戻す。
この機能は、キャラクタと入力ストリームで次にある区
別的発音符を取得するために使用される。
この機能は現在のテキストストリームから新しいストラ
イクスルーキャラクタを取得する。
この機能は、入力ストリームで次にある、セットされた
スクリプトオフセット命令からのスクリプトオフセット
の値を戻す、もしそのような指令が次にないとすれば、
この機能は最後のそのような指令からの値を戻す。
この機能は、入力ストリームにおいて次にある垂直降下
移動指令取得する。
この機能は、入力ストリームにおいて次にある水平移動
指令を取得する。水平移動指令により左右の移動を許容
する。ストライクスルーおよびアンダライン属性を白紙
に適用するか（ペンダウンで移動）あるいは適用しない
（ペンアップ移動）ようにできる。
１９．５．２９．　ＴＸＸ　ｓ　ａｃｉｎ　（−ｎスペ
ーシングこの機能は、入力ストリームにおいて次にある
セットされた行間スペーシング指令における行間距離の
値を戻す。もしそのような指令が前記ストリームにおい
て次になければ、最後に出会ったそのような指令の値が
戻される。
この機能は入力ストリームにおいて次にある言語変更指
令を取得する。もし言語変更指令が次にないとすれば、
この値は最後のそのような指令あるいはヘッダからの値
を戻す。
この機能は現在のストリームからのテキスト交換データ
の読取りを終了する。もしテキスト交換が別のデータタ
イプ内にはめ込まれていたとすれば、そのデータタイプ
は現在のデータタイプとなり、そのＸＸＸｇｒｅｓｔａ
ｒｔ□機能を用いてデータの読収りを継続すべきである
。もしそのストリームが頭初からテキスト交換ストリー
ムであったとすれば、この機能はストリームの処理を停
止させ、それ以上は使用できない。
この機能はバニラレコード交換ストリームの構成を開始
する。新しいストリームが現在の交換ストリームとなる
。所定のオペレーションには１個のストリームしか使用
できないことに注目のこと。
この機能を呼び出した後、その他のＲＥＸｐＯ機能を用
いてレコードをストリームに投入することができる。
この機能は特定のオペレーションにおいて現在使用中の
ストリームをリセットするバニラレコード交換データを
受け入れる。この機能は、はめ込まれたレコードを別の
タイプの交換データへ挿入するか、あるいは前にはめ込
まれたデータに対して別のデータタイプに切り換えた後
レコードを再び送るために呼び出すことができる。この
機能を呼び出した後、他のＲＥＸｐＯ機能を用いてレコ
ードをストリームに投入することができる。
この機能はヘッダレコードを現在の交換ストリームへ構
成する。レコードは入力パラメータ値に基き構成される
。不明の値はＮＵＬＬとして通過させるべきである。
サブタイプフィールドはアプリケーションに柔軟性をも
たせるためのものである。もしアプリケーションがサブ
タイプ修飾子材のレコードを生成させる意図の場合、サ
ブタイプｉｄｓを＾ＰＰＡＣＫに整合させるべきである
。このためサブタイプフィールドは全てのアプリケーシ
ョンを通して一意のままとしうる。
１９．６．４．　ＲＥＸ　ｒｉｎｉｔ（）−レコード記
述子を開この機能は現在の交換システムにおいてレコー
ド記述子を開始させる。この機能はレコード記述子当り
１回呼び出される。
サブタイプのフィールドはアプリケーションに柔軟性を
提供するためのものである。アプリケーションがサブタ
イプ修飾子を備えたレコードを生成させる意図の場合サ
ブタイプｉｄｓを＾ＰＰＡＣＫに整合させるべきである
。このためサブタイプフィールドは全てのアプリケーシ
ョンを通して一意のままとしうる。
この機能は現在の交換ストリームにおいてフィールド記
述子を構成する。この機能はレコード記述子の各フィー
ルドに対して１回呼び出すべきである。
この機能は完全なレコード記述子の終りをマークする０
本機能はレコード記述子当り１回呼び出される。
この機能はデータレコードを初期化する。この機能はデ
ータレコード当り１回呼び出される。
サブタイプフィールドはアプリケーションに柔軟性を提
供するためのものである。もしアプリケーションがサブ
タイプ修飾子材のレコードを生成させる意図であれば、
サブタイプｉｄｓを八ＰＩ”ＡＣＫに整合させるべきで
ある。このため全てのアプリケーションを通してサブタ
イプフィールドが一意のままとしうる。
この機能は現在の交換システムにおいてデータフィール
ドを構成する。入力データタイプは対応する標準的な交
換フォーマットに変換される。この機能はデータレコー
ドの各フィールド当り１回呼び出される。
１９．６．９．　ＲＥＸ）ｆｉｎｉ□−データレコード
を終了すｊ［ この機能は完全なデータレコードの終りをマークする。
この機能はデータレコード当り１回呼び出される。
この機能は現在のストリームにおけるバニラレコード交
換データの構成を終了する。もしバニラレコード交換が
別のデータタイプ内にはめ込まれたとすれば、そのデー
タタイプは再び現在のデータタイプとなり、その＾ＰＸ
ＸｐｔｒｅｓｅＬ□機能を用いてデータを送り続けるべ
きである。もしストリームが頭初からバニラレコード交
換ストリームであったとすれば、この機能はストリーム
を完成させ、バッファされたいずれかのデータをオペレ
ーションの他方の終りにおいてコンシューマに送る０次
いでストリームが終了し、それ以上使用されない。
このＲｌｍはバニラレコード交換ストリームの読取りを
開始する。この機能はストリームの最初の部分がオペレ
ーションの他端においてサーバから到来するのを待機す
る。新しいストリームが現在の交換ストリームとなる。
所定のオペレーションで使用できる流れは１つのみであ
ることを注目のこと。バニラレコード交換データのリク
エストがすでにサーバへ送られており、満足な応答が受
け取られたものと想定する。この機能を呼び出した後、
他のＲＥＸｇＯＷｔｒｆＡを用いてストリームからレコ
ードを取得するよう使用できる。
この機能は特定のオペレーションにおいて現在使用中の
ストリップをリセットしてバニラレコード交換データを
読取る。この機能は、はめ込まれたレコードを別のタイ
プの交換データから読取るか、あるいは前にはめ込んだ
データに対して別のデータタイプに切り換えた後レコー
ドの読取りを再開するために呼び出すことができる。こ
のストリームは現在の交換ストリームとなる。この機能
を呼び出した後、他のＲＥＸｇ□ｎ能を用いてストリー
ムからレコードを読取ることができる。
この機能はレコードタイプの値とサブタイプとを戻す。
どのタイプのレコードが後続するかを検出し、それを正
確に処理するのはコンシューマの責任である。データ転
送の終りはエラーとしてこの機能により戻されることに
注目することが重要である。
この機能は現在の交換ストリームにおいてヘッダレコー
ド情報を戻す。
この機能は次の順のフィールド記述子を戻す。
レコード記述子の終りはこの機能からエラーとして戻さ
れることを注目することが重要である。
フィールド記述子をデータタイプに基いて正確に処理す
ることはコンシューマの責任である。
この機能はフィールドデータとタイプとを戻す。
データレコードの終りはこの機能から戻されることを注
目することが重要である。どのタイプのデータを処理す
べきか検出することはコンシューマの責任である。タイ
プ依存型情報については＾ＰＲＸＦＤＡＴＡｔＲ造の定
義を参照のこと、またバニラレコードデータ構造を参照
。
この機能は所定タイプの次のレコード、レコード記述子
あるいはデータレコードを見付ける。タイプはユーザが
指定する。
この機能は現在のストリームからバニラレコード交換デ
ータの読取りを終了する。もしバニラレコード変換が別
のデータタイプにはめ込まれてぃたとすれば、そのデー
タタイプが再び現在のデータタイプとなり、その＾ＰＸ
Ｘｇｒｅｓｅｔ□機能を用いてデータの読取りを継続す
べきである。もしストリームが頭初バニラレコード変換
ストリームであったとすれば、この機能はストリームの
処理を停止し、それ以上は使用されない。
この機能は読出し専用アクセスのために既存の資源ファ
イルを開ける。アプリケーションは資源ファイルを何枚
開けてもよい。
この機能は呼び出し者が特定する資源ファイルのリスト
を開ける。各ファイルの名称は呼び出し者が通したスト
リング、プログラムの省略時言語コード、およびプログ
ラム自体がそこから来たカタログあるいはライブラリか
らの情報の径路から構成される。ファイルは読出し専用
アクセスに対して開かれる。
この機能に通されたパラメータリストは不変であって、
実行すべきアクションによって決まる。
第１のパラメータは常にインターナショナルな位置コー
ドである。これに続き、多数のフラッグ／ストリングの
ペアがあり、ここでフラッグが開くべきファイルのタイ
プ（システム資源ファイル、言語依存型アプリケーショ
ン資源ファイルあるいは言語とは独立したアプリケーシ
ョン資源ファイル）を特定し、ストリングが開けるべき
ファイルの名前または接頭語を特定する。あるフラッグ
の値は後続のストリングポインタを必要としない。
パラメータリストは常にＲＥＳＦＨＥＮＤのフラッグと
共に終了する。
、パラメータストリングのフォーマットとファイル名称
を構成する方法とはシステムによって決まる。この機能
は開かれたファイルのファイルＩＤは戻さない、プログ
ラムは常に各資源に対して入手可能の全ての資源ファイ
ルを通して探索するものと想定される。もしファイルの
１個を開ける際エラーを経験すると、その地金てのファ
イルも開かれ、エラーは戻される。
２Ｇ、１．３．　ＲＥＳｆｃｌｏｓｅ　　−ファイルを
　しるこの機能はＲＥＳｆｏｐｅｎＯにより開かれた資
源ファイルを閉じる。
この機能はユーザのファイルあるいは資源ファイルにお
いて資源を見つける。タイプがマツチすれば、この機能
は資源用の省略時ヒープからのスペースを割り当て、メ
モリへ読取り、ポインタをその資源のメモリコピイまで
戻す、タイプがマツチしなければエラーが戻される。
タイプパラメータがＲＥＳＴＡＨＹであるとすれば、い
ずれの資源タイプともマツチし、ミスマツチエラーは何
ら戻されない。
成功すれば、資源はユーザのプロフィルあるいは１．も
しユーザプロフィルで見つからなければ開かれた資源フ
ァイルの１個から読取られる。呼び出し者が資源を見つ
けると、本機能は旺５ｒｅｌｅａＳｅ０を呼び出すこと
により解放され、そのためし−プの前記スペースは再生
利用しうる。
入力バラメータ ー検索すべき資源のＩＤ −実際の資源タイプを妥当化すべき資源の期待されるタ
イプあるいはＲＥＳＴＡＮＹ出カバラメ−タ ー資源に対するポインタが記憶されている領域へのポイ
ンタ ー資源のサイズが記憶されている変数へのポインタ。も
し８０１゜してあれば、サイズは戻されない。
２０．２．２．　ＲＥＳｍ　ｅｔ　−−”を′　るこの
機能は多数の資源を省略時のヒープへ読取り、それらの
ポインタを戻す。ある環境下では、この機能はアクセス
すべき各資源に対して、ＲＥＳｇｅｔ□を呼び出すこと
よりも顕著な性能上の利点を提供しうる。タイプの妥当
性が得られないと資源のサイズは戻されない。もし資源
が見つからなければ、資源へのポインタはＨＵＬＬにセ
ットされ、エラーが戻されるが、その地金ての資源はい
ずれにしでも読出しされる。もしＲＥＳＥｔｌＮＩＩＥ
ＦＩＮＥＤ以外の何らかのエラーが読取りの間に発生す
れば、全てのポインタはＮＵＬＬにセットされ、全ての
割り当てられたスペースが自由とされ、エラーが戻され
る。
資源がもはや必要とされないと＋　ＲＥＳｒｅｌｅａｓ
ｅ□を読取られた各資源に対して呼び出しそれにより占
有されていたスペースを割り当て直すようにすべきであ
る。
入力バラメータ ー検索すべき資源ＩＤのアレイの始まり一検索すべき資
源の数 出力バラメータ ー資源へのポインタが記憶されるアレイの始まり この機能は資源の一部へのポインタは戻す。この機能は
、資源が潜在的に極めて大きく、かつアプリケーション
がそれをバッファにコピイするというオーバヘッドを排
除したいと希望するときに叶び出すべきである。資源の
断片はアプリケーションに提供しうるが、修正はできな
い。資源を修正しようと試みても予想の出来ない結果を
もたらす。
資源がもはや必要とされなくなれば、ＲＥＳｒｅｌｅａ
ｓｅ（）を呼び出すべきである。
一時にマツピング可能な資源の断片の数は極限定されて
いる。最大数の断片数に達す条と、既存の断片に対して
ＲＥＳｒｅｌｅａｓｅ□を呼び出すことなく別の断片の
ポインタを得ようとしてもエラーを発生させる。
特定されたオフセットが資源サイズより大きい場合、エ
ラーは戻される。長さをプラスした特定オフセットが資
源のサイズより大きいならば、異なるエラーが戻され、
資源はいずれかにマツピングされる。
入力バラメータ ー検索すべき資源のＴＤ −検索すべき資源内のオフセット 一必要な資源データの量（バイト） 出力バラメータ ー資源へのポインタが記憶される領域へのポインタ ２０．２．４．ＲＥＳｒｅｌｅａｓｅ−′るこの機能は
メモリでの資源のコピイを解放することによって、必要
ならスペースを再生利用できる。この機能はＨＰｆｒｅ
ｅＯ直接呼び出しでなくむしろ常に利用すべきである。
入力バラメータ ーＲＥＳｇｅｔ□、ＲＥＳｍｇｅｔ□あるいはＲＥＳｐ
ｏ　ｉ　ｎ　ｔ　□により戻される資源データポインタ 出力バラメータ 一部 ２０．２．５．ＲＥＳｒｅａｄ　　−、”υＬ＝この機
能は資源の全部または一部をユーザが特定の領域へ読取
る。もし提供されたバッファが要求された資源のサイズ
より大きいか、あるいは資源がバッファより大きければ
エラーが戻されるが、資源は依然としてバッファに置か
れる。
入力バラメータ ー検索すべき資源のＩＤ −読取りされている資源内のオフセット−読取るべき資
源のバイト数 出力バラメータ ー資源データが記憶される領域へのポインタこの機能は
、特定の名称を有する資源のＩＤと、その中で資源が発
見されたファイルのＩＤとを戻す、その名前の資源がな
い場合、エラーが戻される。特定の名前で資源が見つか
るが、より最近に開かれたファイルには同じ資源ＩＤを
有する別の資源がある場合、資源とファイルのＩＤがセ
ットされるが、エラーは依然として戻される。この理由
は、資源ＩＤを資源のアクセスに使えないがらである。
この機能は資源に関する情報を戻す。
ユーザが特定した情報構造は要求された情報と共に充て
んされるユーザの変数に対するポインタを含むべきであ
る。もし前記構造におけるフィールドがＨＵＬＬの場合
、その情報は戻されない。さもなければ情報はフィール
ドにより指摘された変数にセットされる。もし名称、ｈ
己述あるいはリテラルフィールドがセットされるとすれ
ば、適当なテキストストリングが省略時のし−プに読取
られ、零で終り、呼び出し者のポインタはそこを指すよ
うセットされる。この場合、呼び出し者は、ストリング
がもはや必要とされないならばＨＰｔｒｅｅ□で割り当
てられたスペースを解放する必要がある。
そのようなストリングの無い場合、呼び出し者のポイン
タはＨＵＬＬにセットされる。
を支 この機能は新しい資源ファイルを作成し、そのファイル
に対して編集オペレーションが実行できるようにする。
　ｍ１ｎｉｄおよび−ａｘｉｄがファイルで作成しうる
最小と最大の資源ＩＤｓを定義する。この範囲より外の
ＩＤでファイルに資源を作成しようとしてもエラーを戻
すことになる。−旦フアイルが作成されると、これらの
値は決して変更できない。
２０．３．２．ＲＥＳｆｅｄｉＬ　　−゛源ファイルを
　正　るこの機能は資源エディタが既存の資源ファイル
の中味を修正できるようにする。この機能は該ファイル
に対する最低および最高の合法的な資源Ｉ　Ｄを戻す。
２０．３．３．　ＲＥＳｆｖｉｅｗ　　−”）ファイル
を　査　ろこの機能は資源エディタがユーザファイルか
ら干渉されることな（、ＲＥＳＨｔｎｅｘｔ□、および
ＲＥＳｇｔｐｒｅｖ□による走査を含み、資源ファイル
の中味を観察できるようにする。ファイルは読出し専用
に開かれているので、資源は何ら修正されないが、編集
されたファイルに適用されるその他の機能のいずれも使
用可能である。
この機能は、ＲＥＳＥＦＩＤを戻す機能のいずれかによ
り開けられた資源ファイルへの修正を完了する。
もしファイルがユーザプロファイルである場合、それも
閉じられる。
資源ファイルになされた変更はファイルのパーマネント
コピイに組み込むことができ、あるいは変更を捨てファ
イルを変えないままとしうる。もしファイルがＲＥＳｆ
ｅｄｉｔ□により開けられ、非変更パラメータがＴＲＵ
Ｅであれば、ファイルに対してなされた全ての変更は棄
却される。もしファイルがＲＥＳｆｅｒｅａｔｅ（）を
用いて開けられたとすれば、それも削除される。もしパ
ラメータがＦＡＬＳＥであれば、変更はファイルのパー
マネントコピイヘ組み込まれる。
このルーチンに通されて来た資源ファイルＩＤがＲＥＳ
ｓｕｐｅｄｉｔ□を介して作成されたとすれば、ファイ
ルＩＤは削除されるが、関連のプロファイルは影響され
ない、呼び出し者は依然としてプロファイルを閉じる責
任がある。
この機能は、編集のために開けである資源ファイルにつ
いての数個の情報、即ちファイルにおける資源の全数、
現在の最小および最高の資源ＩＤ、および外部および内
部のファイルバージョン番号とを戻す。これらの番号は
、現在の編集セツションの間作成されたり、かつ／また
は削除された資源の数を考慮する。もしピクチャのいず
れかがＮｔｌｌ、Ｌであるとすれば、相応の数の情報は
戻されない。
最低および最高の既存の資源ＩＤは、ＲＥＳｆｃｒｅａ
ｔｅ（）により受け入れられ、ＲＥＳｆｅｄｉｔ□によ
り戻された、それぞれファイルにおける最低および最高
の資源ＩＤであるＩＤとは同じでない。
この機能は、資源ファイルに記憶可能の最小と最大の資
源ＩＤを修正する。もしその範囲が違法値を含んでいる
か、あるいはすでにファイルに存在している資源とを除
外しているとすればエラーが戻される。
２０．３．７．　ＲＥＳａｖａｉｌ（−の゛　ｔ−ｒｏ
を取得ｊコ卜 この機能は、すでにある資源により使用されていない、
ある特定範囲内の、ファイル内のれ小または最高資源を
戻す。この機能は、システムが生成の資源ＩＤを選択す
る上で資源エディタにより使用される。
この機能は、特定のファイルの特定の資源の後で物理的
に位置した資源に関する情報を戻す。その引き数はＲＥ
ＳｒＤＢＯＦとなり、その場合そのファイルの最初の資
源は戻される。もし特定の資源がファイルにおける最後
の資源である場合、エラーは戻される。
この機能は、特定ファイルの特定資源の直前の資源に関
する情報を戻す。引き数はＲＥＳＩＤＥＯＦでよく、そ
の場合ファイルの最後の資源が戻される。
特定の資源がファイルでの最初の資源である場合、エラ
ーが戻される。
この機能は、何らかのそれ以上の修正がなされる前に、
特定の資源ファイルの現在の状態を記録する。もしＲＥ
ＳｒｅｖｅｒＬ□が呼び出されるとすれば、ＲＥＳｃｈ
ｅｃｋｐｔ（）およびＩｔＥＳｒｅｖｅｒｔ□との間で
実施された全ての修正が棄却される。このオペレーショ
ンは、このオペレーションの作用を要するシステムに対
する「取り消し」オペレーションをサポートする。
チエツクポイントはルベルのみ可能である９−旦この機
能が呼び出されると、この機能に対する２回目の呼び出
しにより最初の呼び出しにより記憶されたデータを忘れ
させる。これらの機能の呼び出し者はどの程度の細分性
の「取り消し」支援を提供すべきか、即ち何が全体的に
取り消す必要のある単一のユーザオペレーションを構成
するかを自分自身で決定する必要がある。
２０．３．１１．　ＲＥＳｒｅｖｅｒｔ（−最　の　ニ
ックポイン」二 この機能により、特定の資源ファイルを、それが最後の
ＲＥＳｃｈｅｃＲｐｔＯとしておかれていたのと同じ状
態に戻されるようにする。その時点以来なされた全ての
編集上の修正は棄却する。
この機能は資源ファイルを修正して解放および分配の準
備をさせる。もしｎｅｗｖｅｒフラッグがセットされる
と、外部のバージョン番号が増分される。
もしｃｌｒａｌｔｅｒフラッグがセットされるとすれば
、（現在の編集セツションの間修正された資源を含む）
全ての資源のＲＥＳＦＡＬＴＥＲＥＤフラッグがクリヤ
される。もし５ｔｒｉｐｌｉｔフラツグがセットされる
とすれば、全てのリテラルはサイズを小さくするために
資源ファイルから除去される。
この機能は資源ファイルに記憶されたバージョン番号の
ストリングを検索する。このバージョン番号は８キヤラ
クタのフラッグでなければならない。資源ファイルがＲ
ＥＳＰＡＣＫにより作成されると、バージョン番号はｒ
ｏｏ、００．ｏＯＪにセットされるが、いつでもＲＥＳ
ｐｔｆｖｅｒ□を用いて変更しうる。
この機能は８キヤラクタのバージョン番号ストリングを
資源ファイルにセットする。このストリングはＲＥＳｇ
ｔｆｖｅｒ□により検索できる。
この機能は特定の資源ファイルから、資源の現在の値を
読取る。この機能は、バッファの未編集バージョンのみ
を戻すＲＥＳｒｅａｄＯと対照的である。
資源はユーザが提供したバッファへ読取られる。
もし提供されたバッファが要求された資源より矢きいか
、あるいは資源がバッファより大きければ。
エラーは戻されるが、資源は依然としてバッファに位置
される。
２０．４．２．ＲＥＳ　ｔｅｕｒ（）−上のゝ゛、　　
　　を　　“す」Ｙ この機能は、資源の情報になされたバージョンについて
の情報を戻すＲＥＳｇｔｉｎｆｏ□とは対照的に、資源
の現在の状態についての情報を戻す。
呼び出し者は、資源に対しどのファイルを探索すべきか
規定するか、編集のため（こ用いている全てのファイル
内での探索を規定しうる。この機能は、ファイルの間で
資源の探索を行いうる唯一の編集機能である。その他の
全ての編集機能に対して探索すべきファイルは明確に特
定する必要がある。
情報構造は、要求された情報で充てんされるユーザ変数
に対するポインタを含むべきである。前記情報ｉｌｌ造
におけるいずれかのフィールドがＨＵＬＬであるとすれ
ば、その情報は戻されない。さもなければ、情報はフィ
ールドにより指摘された変数ヘセットされる。もし名称
、記述あるいはリテラルフィーｌレドがセットされると
すれば、適当なテキストストリングが省略時ヒープへ読
取られ、かつＮｕｔ、１．で終るようにされ、呼び出し
者のポインタは該ストリングにセットされる。この場合
、呼び出し者は、ストリングがもはや必要とされなけれ
ばｌｌｒ’ｆｒｅｅＯで割り当てたスペースを解放する
必要がある。そのようなストリングがないとすれば、呼
び出し者のポインタはＨＵＬＬにセットされる。
２０．４．３．　ＲＥＳｃｒｅａｔｅ　）　−’　、を
９　るこの機能は特定ファイルにおいて新しい資源を作
成する。資源は特定のパラメータで作成され、データは
何ら含まない、もし資源が非零サイズで作成されるとす
れば、そのデータ領域は零で充てんされる。資源はファ
イルにおけるいずれかの希望する相対位置で作成できる
。
これは新しい資源を作成しうる唯一の機能である。
情報構造は新しい資源の属性に対するある値を含む。タ
イプおよびフラッグフィールドは情報構造内で特定せね
ばならず、あるいはエラーが戻される。全ての他のフィ
ールドは任意である。もしバージョンが特定されないと
すれば、資源バージョンが内部資源ファイルバージョン
にセットされる。
２０．４．４．　ＲＥＳｗｒｉｔｅ　　−’　”、を　
Δむこの機能はユーザにより提供されたデータを特定フ
ァイルの設定資源に書込む。資源にすでに介在している
必要がある。資源にすでにデータが介在しているとすれ
ば、古いデータを捨て、資源サイズが特定のカウントに
セットされる。
２０．４．５．　ＲＥＳｒｅｗｒｉｔｅ　　−”４を東
ね−き−るこの機能はユーザにより提供されたデータを
特定ファイルの既存資源に書込む、これは、すでに資源
にあるデータに追加するか部分的に重ね書きできる。
宙込みが始まるオフセットは資源の現在のサイズより小
さいか、あるいは等しくあらねばならない。いずれのよ
り大きい値もエラーを戻すようにさせる。特定のオフセ
ットプラス長さが現在の資源サイズより大きいとすれば
、このサイズは新しいデータを収容するために増大する
。
２０．４．６．　ＲＥＳ　ｔｉｎｆｏ　　−資２２、に
　　る　　を入れる この機能は資源に関する情報をセットする。もし資源の
サイズが増えると、新しい資源スペースは零で充てんさ
れる。
この情報構造はセットすべき値へのポインタを含むべき
である。情報構造におけるいずれのフィールドもＨＵＬ
Ｌであるとすれば、資源の対応する属性は不変のままと
される。フラグの中のＲＥＳＦＮＡＨＥＤフラッグが使
用されず、情報構造に記憶された名前ポインタから再び
取り出される。
２０．４．７．　ＲＥＳ＋＊ｏｖｅ　　−”、　　　　
い立管へこの機能は既存の資源を資源ファイルの新しい
位置まで移す。
２０．４．８．　ＲＥＳ　ｔｎｕｍ　　−”　’、、の
、　を・（官この機能は特定の資源の資源ＩＤを変える
。
この機能は一方のファイルから他方のファイルへ資源の
リストを併重する。資源は通常原始ファイルと同じ情報
およびデータで宛て先ファイルにおいて作成される。コ
ンフリクトがあれば、宛て先ファイルにすでにある資源
が最初に取り消される。もしインデックスがコピイされ
つつあるとすれば、呼び出し側は古いインデックスを保
持すべきか、壊すべきかあるいは古いインデックスと新
しいインデックスの中味を併合すべきか規定するオプシ
ョンを有する。
この機能はそれ以上の構成を必要としない。
２０．４．１０．　ＲＥＳｄｅｌｅｔｅ（）　　”、、
を　　、　るこの機能はファイルから資源を削除する。
２０．５．：、１、？　　。
資源インデックスは、任意的に分類され、全て単一の資
源ＩＤにより識別された単一の資源に記憶された均一サ
イズのエントリの単純なリストである。インデックスエ
ントリは３種類の情報、即ちキー、データの任意チャン
クおよび資源ＩＤとを含む。キーが与えられると、呼び
出し者は資源インデックスにおけるそのキーでエントリ
を探し、その結果そのキーと関連したデータと資源ＩＤ
とを受け取ることができる。もしインデックスが分類さ
れるとすれば、全てのエントリはそれらのキーの値の順
に配列される。もしエントリの資源■Ｄが別の資源イン
デックスのＩＤと定義されるとすれば、インデックス構
成者は多くのレベルの階層の関連資源インデックスを作
成することができる。
この機能は資源インデックスの構成過程を初期化させる
。呼び出し者はキータイプを特定し、インデックスの挙
動を分類して、資源インデックスが構成されるにつれて
資源を識別するために使用すべきＩＤを受け取る。この
機能は資源を資源ファイルに入れない。呼び出し側は資
源のファイルへの投入を別のオペレーションにおいて行
う必要があり、そうする前にＲＥＳｉｘｆｉｎｉＯを呼
び出ず必要がある。
ｎ１ｎｉｄ、ｍａｘｉｄおよびｒｅｓｔｙｐｅパラメー
タが割り出すべき資源に関する情報を提供する。これら
のフィールドはＲＥＳＰＡＣＫによっては全く使用され
ず、呼び出し側の便宜上インデックスに関する情報を記
憶するためのものである。
この機能は、ファイルから読出されるに−）れて資源イ
ンデックスへのポインタを取り、その修正可能コピイへ
のポインタを戻す。この機能は他のＲＥＳｉｘＯ機能の
いずれがか呼び出される前に行うべきである。いずれに
しても入力ポインタは修正されない。もしく例えばＲＥ
Ｓｇｅｔ□により）ヒープから割り当てられたとすれば
、呼び出し側はそれを解放すべきである。
この機能は特定のキー、データおよび資源ＩＤで新しい
資源インテ・ソクスエントリを構成し、所定の資源イン
デックスへ挿入する。分類したリストに対して、エント
リは照合順序内の適正位置で挿入される。未分類のリス
トに対しては、エントリはリストの終りに付属される９
提供されたＲＥＳｒＸｆ口はＲＥＳｉｘｉｎｉｔ□また
はＲＥＳｉｘｐｒｅｐ’０への呼び出しにより戻された
ものと想定する９この機能は資源インデックスから特定
のエントリを削除する。提供された資源ＩＤはＲＥＳｉ
にｎｉｔ□またはＲＥＳｉｘｐｒｅｐ□の呼び出しによ
り戻されたものと想定する。
この機能は資源インデックスの構成過程を完了させ、か
つ資源ファイルに追加可能の資源を戻す。
この機能は実際にはＲＥＳｉｘｐｒｅｐＯにより実行さ
れたオペレーションの逆である。戻された資源はヒープ
から割り当てられ、そのため資源ファイルに挿入された
陵、１ＩＰｆｒｅｅＯを呼び出すことにより解放すべき
である。
この機能は特定の資源インデックスを取得し、所定のキ
ーで該インデックスを通してエントリを探索し、そのキ
ーに関連したデータと、資源ＩＤとを戻す。この機能は
探索を終った後資源インデックスを解放する。もし憤−
の資源インデックスを通してのマルチパスが必要であれ
ば、ＲＥＳｇｅｔ（）、ＲＥＳｉｘｐｒｅｐＯおよびＲ
ＥＳｉｘＨｅｔ□を用いる方が速くなる。
この機能は特定の資源インデックスを取得し、所定のキ
ーで、該インデックスを通してエントリを探索し、その
キーに関連した資源ＩＤを戻す。
この機能はＵＳＩＩＯＲＴのキータイプを備えた資源イ
ンデックスに対してのみ使用可能である。インデックス
データはこの機能によって戻されないので、エントリデ
ータを取得するにはＲＥＳｉｘＨｅｔ□を使用のこと。
この機能により探索を終った後資源インデックスを解放
させる。単一の資源インデックスを通してのマルチパス
が必要であるとすれば、ＲＥＳｇｅｔ（）およびＲＥＳ
ｉｘｕｆ　ｉｎｄ□を用いる方が速い。
２０．５．８．ＲＥＸｉｘｌｌｏｏｋｕ　　−ＩＪＬＯ
ＮＧエントリをルックアップ　る この機能は特定の資源インデックスを取得し、所定のキ
ーで該インデックスの中でエントリを探索し、そのキー
に関連した資源ＩＤを戻す。この機能はＵＬＯＮＧのキ
ータイプを備えた資源インデックスに対してのみ使用可
能である。インデックスエントリはこの機能によって戻
されず、壬ントリデータを取得するにはＲＥＳｉｘｇｅ
ｔＯを用いること。
この機能は探索終了後資源インデックスを解放する。も
し単一の資源インデックスを通してのマルチパスが必要
であるとすれば、ＲＥＳｇｅｔ□およびＲＥＳｉｘｆｉ
ｎｄＯを用いる方が速い。
この機能は特定の資源インデックスを取得し、特定のキ
ーで該インデックスの中でエントリを探索し、該キーに
関連した資源ＩＤを戻す。この機能はストリングのキー
タイプを備えた資源インデックスに対してのみ使用可能
である。インデックスエントリデータはこの機能によっ
て戻されず、エントリデータを取得するにはＲＥＳｉｘ
ｇｅＬ□を用いること。この機能は探索終了後、資源イ
ンデックスを解放する。もし単一の資源インデックスを
通してのマルチパスが必要であるとすれば、ＲＥＳｇｅ
ｔ（）およびＲＥＳｉｘｓｆｉｎｄＯを用いる方が速い
。
この機能は所定のキーで所定の資源インデックスのエン
トリを探索し、そのキーに関連した資源ＩＤを戻す。こ
の機能はＵＳＩＩＯＲＴのキータイプを備えた資源イン
デックスに対してのみ使用可能である。゛インデックス
エントリデータはこの機能によって戻されないので、エ
ントリデータを取得するにはＲＥＳｉｘｇｅＬ□を用い
ること。
２０．５．１１．ＲＥＳｉｘｌｆｉｎｄ　　−ＵＬＯＮ
Ｇエンド−を註 この機能は所定のキーで所定の資源インデックスのエン
トリを探索し、そのキーに関連した資源ＩＤを戻す。こ
の機能はＵＬＯＮ（：のキータイプを備えた資源インデ
ックスに対してのみ使用可能である。インデックスエン
トリデータはこの機能によって戻されず、エントリデー
タを取得するにはＲＥＳｉｘｇｅＬ（）を用いること。
この機能は所定のキーで所定の資源インデックスのエン
トリを探索し、そのキーに関連した資源ＩＤを戻す。こ
の機能はストリングのキータイプを備えた資源インデッ
クスのみに対して使用可能である。インデックスエント
リデータはこの機能によって戻されず、エントリデータ
を取得するにはＲＥＳｉｘｇｅｔＯを用いること。
この機能は所定のキーで所定の資源インデックスのエン
トリを探索し、そのキーに関連したデータと資源ＩＤを
戻す。
この機能はインデックス内のその位置により特定された
、資源インデックスのエントリを戻す。
もし特定のエントリが存在していないとすれば、何ら情
報は戻されない。
この機能は資源インデックスを記述した情報を戻す。資
源インテ・ソクスは資源アクセス機能の１つを叶び出す
ことによりすでに集められているものとする。
２０．６．バ・ソチスタイルの・′源　９　　。
こノセクジョンはバッチスタイルの資源ファイル構成に
使用する一組の資源ファイル作成機能を記述する。これ
らの機能は資源ファイルをｆ？成するより’Ｆ［な手段
を提供する。但しファイル構成プロセスは非インタラク
チブスクリプトから推進されるものとする。既午のファ
イルを編集したり、あるいはすでに資源ファイルに入れ
られた資源を修正する機能は何ら提供されていない。
２０．６．１．　ＲＥＳｃｃｒｅａＬｅ　　−バラ　ス
タイルのコ、ファイルを−　　る この機能は新しい資源ファイルを作成し、資源を挿入す
べく準備する。このファイルは既存のものではない。資
源の範囲は定義した限度内に入る必要がある。
この機能は所定の資源を現在間いている資源ファイルに
追加する。資源のデータ部分は前に挿入された資源のす
ぐ後に挿入し、所定の資源ＩＤを関連させる。この機能
により挿入された全ての資源は「可視」「修正可」およ
び「カストマイズ可」とフラッグされる。
この機能は現在の資源ファイルの構成を終了し、該ファ
イルを閉じる。
２０．７．ニー　プロファイル　ボート機借このセクシ
ョンはユーザプロファイルとＲＥＳＰＡＣＫを介して対
話するよう機能する。ＲＥＳＰＡＣＫは資源を読取って
いる間、もしユーザのプロファイルにカストマイズされ
たバージランがあるとすればオリジナルの代りにａ源の
カスｌ−ライズしたバージョンを代替させるよう選択し
うる。また、ユーザプロファイル内の資源は、それらが
資源ファイルにあたかも記憶されているように編集しう
る。
この機能は、ユーザファイルからカストマイズされた資
源を検索する上でＲＥＳＰＡＣＫにより使用されるカス
トマイゼーションＩＤをセットする。このカストマイゼ
ーションＩＤを介してカストマイズされた資源のみが別
のＲＥＳＰＡＣＫ呼び出しにより戻される。ＴＤは現在
のプログラムの実行の残りの部分を通して使用される。
もしこの呼び出しが行われないとすれば、カストマイズ
された資源は戻されることはない。
１１ＥＳＰＡＣＫはユーザプロファイルに記憶された資
源が、あたかも資源ファイルに記憶されていなごとくに
編集できるようにする。このｎ能は、実際に使用されて
いるファイルのタイプとは関係なくＲＥＳＰＡＣＫルー
チンを全体的に通して資源編集が実施できるようにする
。
この機能はユーザプロファイルに関する情報を取得し、
ＲＥＳＥＦＩＤを必要とする他のＲＥＳｒ’ＡＣＫ機能
に対する引き数として使用可能の１１ＥＳＥＦＩＤを戻
す。
全ての修正はプロフィルファイルに適用される。
プロファイルを編集するためにＲＥＳＰＡＣＫ機能のサ
ブセットのみが使用できる。これらのｖ１能とは、ＲＥ
Ｓｒｃｏ＋＋ｕａｉｔ（）　、ＲＥＳｒｄｃｕｒ□　、
ＲＥＳｇｔｃｕｒ□　、ＲＥＳｅｒｅａｔｅ（）、　Ｒ
ＥＳｗｒｉｔｅ（）＋ＲＥＳｒｅｗｒｉｔｅ□、ＲＥＳ
ｐｔｉｎｆｏ□、およびＲＥＳｄｅｌｅｔｅ□である。
その他の全ての機能は、プロファイルを修正するよう呼
び出されるとエラーコードＲＥＳＢＡＤＦＩＯを戻す。
前述の説明は本発明の特定実施例に限定してきた。さら
に別の利点や修正が当該技術分野の専門家には明らかで
ある。したがって、本発明は本明細書に示し、かつ記述
した特定の詳細、代表的装置並びに例示には限定されな
い。むしろ特許請求の範囲は本発明の真正な精神や範囲
に入る前述のような変更や修正を網羅することである。
【図面の簡単な説明】
第１Ａ図、第１Ｂ図および第１Ｃ図は本発明を組み入れ
うる情報処理システムの線図、第２図は本発明のシステ
ムデータベースの線図、第３図は本発明のオブジェクト
マネージャの線図、 第４図は本発明のオブジェクトプロトタイプテーブルの
線図、 第５図は本発明のオブジェクトカタログの線図、第６図
は本発明のオブジェクトテーブルの線図、第７図は本発
明のリンクテーブルの線図、第８図は本発明のリンクに
含まれる各種のデータ構造の線図、 第９図は本発明のマツチメーカを含む、本発明のデータ
交換の線図、および 第１０Ａ図と第１０Ｂ図とは本発明の資源および資源エ
ディタの線図である。 図面の浄書（内容：二変更なし） ＦＩＧ、　２ ＦＩＧ、　　３ ＦＩＧ、　５ ＦＩＧ、　６ ＦＩＧ、　７ １週、７００　Ｓ

Claims (1)

  1. 【特許請求の範囲】 １）データ処理システムにおいて、カストマイズした挙
    動を提供する方法であって、 （Ａ）資源の中味によって変わる挙動をプログラムに提
    供し、かつ資源のオリジナルバージョンを提供し、 （Ｂ）資源をコピイし、 （Ｃ）コピイされた資源を修正し、 （Ｄ）資源をプログラムが要求すると、修正された資源
    をユーザプロファイルに記憶させ、（Ｅ）資源がカスト
    マイズ可能か検出し、 （Ｆ）もし資源がカストマイズ可能であれば、必要とさ
    れる資源のコピイについて現在のユーザのユーザプロフ
    ァイルを検査し、 （Ｇ）もし前記の資源がユーザプロファイルに介在して
    いるとすれば、ユーザプロファイルから資源を提供し、
    さもなければ資源のオリジナルバージョンを提供する 過程を含むことを特徴とする上記方法。 ２）（Ａ）複数のタイプの複数の資源と、 （Ｂ）その挙動の各々が少なくとも１個の資源の中味に
    よって変わる複数のプログラムと、（Ｃ）資源の修正可
    能のバージョンを作成するための、資源をカストマイズ
    する手段と、（Ｄ）カストマイズした資源が関連してい
    るユーザを指示した、資源のカストマイズしたバージョ
    ンを記憶する手段と、 （Ｅ）全ゆるタイプの資源に対するプログラムからのリ
    クエストを受け取り、かつそれに応答して資源をプログ
    ラムに提供する検索手段であつて、特定の資源のバージ
    ョンがカストマイズされたバージョンが対応するプログ
    ラムの現在のユーザに対して存在しているか否かの検索
    手段の検出に応じて提供される検索手段とを含み、 ユーザ間の区別をしない単一のプログラムが、適当なカ
    ストマイズした資源が存在するユーザに対してはカスト
    マイズした要領で自動的に挙動し、かつ適当なカストマ
    イズした資源が存在しないユーザに対しては標準的な要
    領で挙動することを特徴とするカストマイズ可能なデー
    タの処理システム。 ３）請求項２に記載のシステムにおいて、特定のユーザ
    に対してカストマイズした資源がそのユーザのユーザプ
    ロファイルに記憶されていることを特徴とするデータ処
    理システム。 ４）（Ａ）それによって資源の中味および資源に関する
    情報が資源ファイルに記憶され、かつそこから検索され
    うる資源記憶および検索手段であって、各資源が関連し
    た資源識別子を有し、各資源に関する情報が任意的に資
    源リテラルを含んでいる資源記憶および検索手段と、 （Ｂ）前記資源記憶および検索手段を用いて資源に関す
    る情報にアクセスし、かつ各資源リテラルを定義するプ
    ログラム原始コードを作成し対応する資源識別子の値を
    得るヘッダ生成手段とを含むことを特徴とするデータ処
    理システム。 ５）請求項４に記載のデータ処理システムにおいて、い
    ずれかの資源リテラルを除去することにより修正された
    資源ファイルを作成する除去手段を、さらに含むことを
    特徴とするデータ処理システム。
JP63208001A 1987-08-21 1988-08-22 データ処理システム Expired - Lifetime JP3113658B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US8817687A 1987-08-21 1987-08-21
US88176 1987-08-21

Publications (2)

Publication Number Publication Date
JPH01140238A true JPH01140238A (ja) 1989-06-01
JP3113658B2 JP3113658B2 (ja) 2000-12-04

Family

ID=22209806

Family Applications (1)

Application Number Title Priority Date Filing Date
JP63208001A Expired - Lifetime JP3113658B2 (ja) 1987-08-21 1988-08-22 データ処理システム

Country Status (5)

Country Link
EP (1) EP0304072B1 (ja)
JP (1) JP3113658B2 (ja)
AU (1) AU612681B2 (ja)
CA (1) CA1287173C (ja)
DE (1) DE3853751T2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04141733A (ja) * 1990-10-02 1992-05-15 Fujitsu Ltd パッケージソフトのレベルアップ管理システム

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995031772A1 (en) * 1994-05-16 1995-11-23 Apple Computer, Inc. Dialog item interface definition object
US5922054A (en) * 1994-08-19 1999-07-13 Canon Kabushiki Kaisha System for managing external applications and files
US5652884A (en) * 1994-11-14 1997-07-29 Object Technology Licensing Corp. Method and apparatus for dynamic update of an existing object in an object editor
US6121964A (en) * 1996-12-09 2000-09-19 Microsoft Corporation Method and system for automatic persistence of controls in a windowing environment
CA2248419A1 (en) * 1997-09-30 1999-03-30 Pitney Bowes Inc. Carrier manager interface utilizing an ocx control
US6873978B1 (en) 1997-10-01 2005-03-29 Pitney Bowes Inc. Event interface for a carrier manager system
US6910047B1 (en) 1997-10-01 2005-06-21 Pitney Bowes Inc. Method and system for changing rating data via internet or modem in a carrier management system
US7869068B2 (en) * 2003-06-27 2011-01-11 Zoran Corporation Printer driver extension and related method
CN116185454B (zh) * 2023-02-14 2026-02-27 恒生电子股份有限公司 应用资源确定方法、装置、服务器和计算机可读存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS60128530A (ja) * 1983-12-16 1985-07-09 Fujitsu Ltd ユ−ザメニユ−表示処理方式
JPS6184955U (ja) * 1984-11-08 1986-06-04

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS60128530A (ja) * 1983-12-16 1985-07-09 Fujitsu Ltd ユ−ザメニユ−表示処理方式
JPS6184955U (ja) * 1984-11-08 1986-06-04

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04141733A (ja) * 1990-10-02 1992-05-15 Fujitsu Ltd パッケージソフトのレベルアップ管理システム

Also Published As

Publication number Publication date
EP0304072A2 (en) 1989-02-22
AU2098188A (en) 1989-02-23
DE3853751D1 (de) 1995-06-14
EP0304072A3 (en) 1991-01-30
JP3113658B2 (ja) 2000-12-04
CA1287173C (en) 1991-07-30
EP0304072B1 (en) 1995-05-10
DE3853751T2 (de) 1995-12-14
AU612681B2 (en) 1991-07-18

Similar Documents

Publication Publication Date Title
US5421012A (en) Multitasking computer system for integrating the operation of different application programs which manipulate data objects of different types
US5303379A (en) Link mechanism for linking data between objects and for performing operations on the linked data in an object based system
US5261080A (en) Matchmaker for assisting and executing the providing and conversion of data between objects in a data processing system storing data in typed objects having different data formats
US5369778A (en) Data processor that customizes program behavior by using a resource retrieval capability
CA1289255C (en) Data integration by object management
RU2365972C2 (ru) Интерфейс программирования для компьютерной платформы
Anderson et al. Chimera: Hypertext for heterogeneous software environments
US5787416A (en) Methods for hypertext reporting in a relational database management system
US5499359A (en) Methods for improved referential integrity in a relational database management system
US5625809A (en) Method for constructing a data structure which allows data to be shared between programs
US5818447A (en) System and method for in-place editing of an electronic mail message using a separate program
US6308179B1 (en) User level controlled mechanism inter-positioned in a read/write path of a property-based document management system
US6269380B1 (en) Property based mechanism for flexibility supporting front-end and back-end components having different communication protocols
US7086000B2 (en) Tagging related files in a document management system
US7111016B2 (en) Method and apparatus for data item movement between disparate sources and hierarchical, object-oriented representation
US6330573B1 (en) Maintaining document identity across hierarchy and non-hierarchy file systems
US6606649B1 (en) Application programming interface functions for supporting an improved message store for hand-held computers
US5710928A (en) Method and system for connecting objects in a computer system
CN101124572A (zh) 文件系统外壳
JP2000099508A (ja) 複合文書管理システム及び複合文書の構造管理方法ならびに複合文書構造管理プログラムを格納した記録媒体
US8359606B2 (en) Generic user interface command architecture
JP3113658B2 (ja) データ処理システム
US20080005752A1 (en) Methods, systems, and computer program products for generating application processes by linking applications
US7231598B1 (en) User interface for editing documents containing markup language
CN100543737C (zh) 将原始数据从一个数据结构转移到另一结构的机制

Legal Events

Date Code Title Description
R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20080922

Year of fee payment: 8

EXPY Cancellation because of completion of term