JP5535420B2 - Ｘｍｌドキュメントの効率的管理の方法及び装置 - Google Patents

Description

本発明は情報の格納と取り出しに関し、更に詳細には、拡張マークアップ言語（ＸＭＬ）で符号化された情報の格納と取り出しに関する。

最近のコンピュータ・システムは大量のデータの保存、取り出し、管理が可能である。しかし、コンピュータが数値データの処理で高速かつ効率的である一方、テキストデータの操作ではあまり効率的ではなく、人間に読み取り可能なテキストデータの解釈にあっては特に非効率である。一般に、今日のコンピュータは、人間に読み取り可能なテキスト・ドキュメントを含めた情報断片の理解と認識に必要とされる、微妙なコンテクスト情報を理解することができない。その結果、所定のテキスト順序又は断片、例えば画一的な（ｕｎｄｉｆｆｅｒｅｎｔｉａｔｅｄ）テキスト・ドキュメントの単語などを検出できるものの、その情報を定義する単語又は単語群が特定の意味を有する特定の情報断片を、簡単に特定することはできない。例えば、人間の読者は”Ｔｈｅ ａｔｔｏｒｎｅｙ ｗｉｌｌ ｒｅａｄ ｔｈｅ ｔｅｘｔ ｏｆ Ｍａｒｋ’ｓ ｗｉｌｌ”という文の中の”ｗｉｌｌ”という単語の違いを識別するのに困難はないが、コンピュータにはこれらの二つの使用方法の識別や、こうした第２の使用方法だけの特定には大きな困難がある。

従って、ドキュメントを適切にコーディングすることにより、コンピュータがテキスト・ドキュメントを解釈するのを支援する目的でスキーマが開発された。これらのスキーマの多くは、ドキュメントに「マークアップ・タグ」と呼ばれる情報を付与することでテキスト・ドキュメントの選択した部分を識別するもので、これによりコンピュータが確実に情報を識別できる方法で、異なったドキュメント部分を識別する。このようなスキーマは一般に「マークアップ」言語と呼ばれる。

こうした言語のうちの一つが、ＳＧＭＬ（汎用マークアップ言語規約）と呼ばれるもので、情報表現についての規格として国際的に合意が得られている。この言語規格は１９７０年代初頭に行われた、汎用コーディング及びマークアップ言語についての開発作業から発展したものである。様々な研究系統が国際標準化機構（ＩＳＯ）の分科会であるテキスト記述及び処理言語に関する分科会に統合された。この分科会はＳＧＭＬ規格を１９８６年に作成した。

ＳＧＭＬそれ自体はマークアップ・タグを定義しておらず、特定の種類のドキュメントに対してマークアップ・テンプレートを提供していない点でマークアップ言語ではない。その代わり、ＳＧＭＬは汎用記述マークアップ・スキーマを記述し開発する方法を記載している。これらのスキーマが汎用化されているのは、マークアップが特定アプリケーションを指向していないためで、記述的なのはマークアップがテキストでどう表示されるべきかではなく、何を表現するかを記述しているためである。ＳＧＭＬは規格に準拠して書かれたマークアップ・スキーマにより、ユーザがドキュメント用に自分自身のフォーマットを定義できること、また大量の複雑なドキュメントを扱えること、更に大量の情報リポジトリを管理できることから、非常に柔軟性がある。

最近、他の開発が一般的状況を変化させた。インターネットの類を見ない成長と、特にワールドワイドウェブは、簡単かつ安価に電子化文書を国際的な閲覧者に配布するための能力を、著作者又はコンテンツ・プロバイダに対して提供することにより推進された。ＳＧＭＬは、ウェブ上のアプリケーションには必要のないオプションの機能を多く含み、コスト対利益比では現在のウェブ・ブラウザ・ベンダーにとって魅力がないことが証明された。結果的に、これは一般に使用されていない。その代わりとして、ウェブ上の大半のドキュメントはハイパーテキスト・マークアップ言語、又はＨＴＭＬと呼ばれるマークアップ言語で保存また送信されている。

ＨＴＭＬは、ＳＧＭＬをもとにした単純なマークアップ言語で、ハイパーテキスト、マルチメディア、及びウェブ上で一般的に送信される、小さく十分に単純なドキュメントの表示に好適である。定められた短いマークアップ・タグのセットを使用してドキュメント部分を記述するようになっている。これらのタグはドキュメントの構成を単純化し、アプリケーションの構築を大幅に簡略化する。しかし、タグが定められている為、ＨＴＭＬは拡張性がなく非常に限られた構造と認証能力しか備えていない。電子化ウェブ・ドキュメントが肥大し更に複雑になるにつれ、ＨＴＭＬが大規模商業出版に必要とされる能力を持っていないことがますます明らかになった。

このような大規模商業出版の要求に対処するためと、新しく勃興してきた分散ドキュメント処理技術を可能にするため、ワールドワイドウェブ・コンソーシアムと呼ばれる業界グループが、ＨＴＭＬによって提供される能力を越えた能力を必要とするような用途向けに、拡張マークアップ言語（ＸＭＬ）と呼ばれる他のマークアップ言語を開発した。ＨＴＭＬと同様に、ＸＭＬはＳＧＭＬの簡略版サブセットで、ウェブ・アプリケーション用に特に設計されており、学習、使用、実装が完全版ＳＧＭＬより簡単である。ＨＴＭＬとは異なり、ＸＭＬはＳＧＭＬの利点である拡張性、構造、認証を保持しているが、ＸＭＬではドキュメントの何らかのコンポーネントへのアクセスがインターネット上で現在可能ではない場合に、デフォルトが利用できることを保証するＳＧＭＬ構成の使用を制限している。ＸＭＬはまたインターネット統一資源識別子（ＵＲＬ）を使ってどのようにＸＭＬドキュメントのコンポーネント部分を識別するかも定義している。

ＸＭＬドキュメントは、一連のエンティティ（実体）又はオブジェクトで構成される。各エンティティは１つ以上の論理要素を含み、各要素はこれを処理すべき方法を記述した何らかの属性又はプロパティを持つことができる。ＸＭＬはＸＭＬを構成するエンティティ（実体）、要素、属性の間の関係を記述する正式なシンタックス（構文）を提供する。このシンタックスはコンピュータに、各ドキュメントのコンポーネント部分をどのように認識すべきかを伝える。

ＸＭＬでは一対になったマークアップ・タグを使ってドキュメント・コンポーネントを識別する。詳しくは、各論理要素のはじまりと終わりが要素の前の開始タグと要素の後の終了タグによって明確に識別される。例えば、タグ＜ｔｏ＞と＜／ｔｏ＞は次のようにドキュメントの「受け手（レシピエント）」要素を識別するために使われる：
ドキュメントテキスト…＜ｔｏ＞レシピエント…＜／ｔｏ＞ドキュメントテキスト

マークアップ・タグの様式と構造はユーザが定義できるが、ユーザ間の相互運用性を提供する目的で、それを使用する企業やそれと同様の団体が定義することが多い。タグの所定のセットで運用するためには、ユーザはどのようにマークアップ・タグが通常のテキストから分離されるか、また各種要素間での関連性を知る必要がある。例えば、ＸＭＬシステムで、要素とその属性はカギ括弧（＜．．．＞）の対の間に入力され、エンティティ（実体）の参照はアンパサンド（＆）で始まりセミコロン（；）で終わる（＆．．．；）。ＸＭＬタグのセットはドキュメントの論理構造に基づいているので、これらは読み易く理解し易い。

他のドキュメントは他のパート又はコンポーネントを持っていることから、全てのドキュメントの全ての要素についてタグをあらかじめ定義しておくのは実用的ではない。その代わり、ドキュメントを幾つかの要素を持った「タイプ」に分類することができる。ドキュメント・タイプ定義（ＤＴＤ）は、あるドキュメント・タイプでどの要素が予想されるかを示し、ドキュメント内に見られる各要素が許容されないか、許容され要求されるか、又は許容されるが要求されないかのいずれかを表わす。各ドキュメント要素の役割をＤＴＤで定義することにより、各要素がドキュメント内の有効な場所に現われることをチェックすることが可能である。例えば、ＸＭＬのＤＴＤは第２レベルの見出しが存在しなければ第３レベルの見出しが入力されないことをチェックできるようにする。このような階層型チェックはＨＴＭＬでは行なうことができない。ある文書のＤＴＤはドキュメント・ヘッダに挿入されるのが典型的で各要素は識別子例えば＜！ＥＬＥＭＥＮＴ＞でマークされる。

発明が解決しようとする課題

しかし、ＳＧＭＬとは異なり、ＸＭＬはＤＴＤの存在を必要としない。インターネット上でＤＴＤの全部あるいは一部にアクセスできないか、又はドキュメント作者がＤＴＤの作成に失敗したためのいずれかによって、あるドキュメントにＤＴＤが利用できない場合、ＸＭＬシステムはドキュメント内で宣言されていない要素についてデフォルトの定義を割り当てることが可能である。

ＸＭＬは、ほとんどあらゆる論理テキスト構造、例えば手紙、レポート、メモ、データベース又は辞書などを記述するのに十分な柔軟性のあるコーディング・スキーマを提供する。しかし、ＸＭＬはどのようにＸＭＬ準拠のデータ構造が保存され、表示されるべきかを規定せず、ましてやどのように効率的に保存及び表示されるべきかも規定しない。そのため、ＸＭＬ準拠のドキュメントを効率的に操作し保存することができるストレージ・メカニズムの必要性が存在する。

課題を解決するための手段

本発明の一つの実施態様によれば、インメモリ・ストレージ・マネージャはメモリ内のオブジェクト集合としてＸＭＬ準拠ドキュメントを表現する。オブジェクトの集合であるため、ストレージ・マネージャは、ドキュメントあるいはドキュメントの一部を一貫したインタフェースで操作したり、従来のＸＭＬドキュメントでは利用不可能な特徴、例えばテキスト以外のタイプの要素属性や、テキスト情報の代わりにバイナリを含むドキュメントなどの特徴を提供できる。更にストレージ・マネージャでは、ＸＭＬ準拠ドキュメントにスキーマ・ドキュメント（これもＸＭＬドキュメントである）を関連させ、ドキュメント要素及び属性の構成をここで定義する。ストレージ・マネージャは、従来のストレージ・サービスを運用してＸＭＬ準拠ドキュメントを存続させることができる。ストレージ・コンテナはストレージ・マネージャによって高速で検索できるドキュメント断片を内包する。

他の実施態様によれば、ストレージ・マネージャは一貫した方法でドキュメント・コンテンツの要素及び属性にアクセスして操作できるようにする定義済みのメソッドも持っている。例えば、スキーマ・データはドキュメント・コンテンツにアクセスして操作するのに使われるのと同じメソッドでアクセスされ操作出来る。

更に他の実施態様では、ドキュメントに関連付けられたスキーマ・データはドキュメント要素と各要素に関連付けられるべきプログラム・コードの間のマッピングを含むことができる。ストレージ・マネージャは、更に要素タグからコードを取り出すためのメソッドも持っている。取り出したコードは関連する要素からの属性と内容をつかって起動でき、要素は従来のオブジェクトと同様に振る舞う。

全ての実施態様で、ストレージ・マネージャは多数のコンテクストで多数のプロセスによりダイナミックで、リアルタイムのデータアクセスをクライアントに提供する。同じドキュメントにアクセスする多数のプロセス間の同期は、イベント駆動型キュー及びロックで調整される。ドキュメントを表現するのに使用されるオブジェクトは各プロセスでローカルに見られる共通コードから構築される。更に、オブジェクト内のデータも各プロセスにローカルなメモリ内に格納される。ローカル・メモリは他のプロセスの同じ要素のデータコピーを連続的に等価化する分散メモリシステムにより同期される。

更に他の実施態様では、クライアントが指定した集合は別個の集合マネージャにより管理される。集合マネージャはタブ・フォームでＸＭＬデータ構造を表現する「ワッフル」と呼ばれるデータ構造を維持する。ユーザ・コマンドによって駆動されるレコード・セット・エンジンはあるコレクションの更新のセットを集合マネージャへ伝搬する。これらの更新に基づいて、集合マネージャはインデックス構造を更新し、通知システム経由でワッフル・ユーザに通知できる。ワッフル・ユーザもカーソルを用いて集合内を移動できる。

図１は、典型的なクライアント・コンピュータ１００、例えばＩＢＭ社製ＴＨＩＮＫＰＡＤ６００（Ｒ）などのシステム・アーキテクチャを示したもので、この上に本開示のドキュメント管理システムを実装できる。図１の典型的なコンピュータ・システムは説明の目的だけで議論され、本発明の制限と見なされるべきものではない。以下の説明では特定のコンピュータ・システムを説明する際に共通に使用される用語を参照するが、説明する概念は図１に示したアーキテクチャとは異なるアーキテクチャを持ったシステムを含め、他のコンピュータ・システム又コンピュータを内蔵した装置例えばゲーム機やケーブルテレビのセットトップ・ボックスなど、従来はコンピュータと見なされなかったものにも等しく適用される。

クライアント・コンピュータ１００は、従来のマイクロプロセッサを含む中央演算処理装置（ＣＰＵ）１０５、一時的な情報記憶用のランダム・アクセス・メモリ（ＲＡＭ）１１０、永久的な情報記憶用のリード・オンリー・メモリ（ＲＯＭ）１１５を含む。メモリ・コントローラ１２０は、システムＲＡＭ１１０を制御するために提供される。バス・コントローラ１２５は、バス１３０を制御するために提供されており、割り込みコントローラ１３５は、他のシステム・コンポーネントからの様々な割り込み信号を受信して処理するために使用される。

大容量ストレージは、ディスケット１４２、ＣＤ−ＲＯＭ１４７又はハードディスク装置１５２によって提供できる。データやソフトウェアは、リムーバブル・メディア、例えばディスケット１４２やＣＤ−ＲＯＭ１４７を経由してクライアント・コンピュータ１００と交換できる。ディスケット１４２は、ディスケットドライブ装置１４１に挿入することができ、ディスケットドライブ装置１４１は、コントローラ１４０によってバス１３０へ接続されている。同様に、ＣＤ−ＲＯＭ１４７は、ＣＤ−ＲＯＭドライブ装置１４６に挿入することができ、ＣＤ−ＲＯＭドライブ装置１４６は、コントローラ１４５によってバス１３０へ接続されている。最後に、ハードディスク１５２は、固定ディスクドライブ装置１５１の一部であり、これはコントローラ１５０によってバス１３０へ接続されている。

クライアント・コンピュータ１００へのユーザ入力は、多数のデバイスによって提供され得る。例えば、キーボード１５６とマウス１５７は、キーボード及びマウス・コントローラ１５５によってバス１３０へ接続される。オーディオ・トランスデューサ１９６は、マイクロホン及びスピーカの両者として機能することができるもので、オーディオ・コントローラ１９７を介してバス１３０へ接続されている。他の入力デバイス、例えばペン及び／又はタブレットや、音声入力用マイクロホンなどを適当なコントローラとバス１３０経由でクライアント・コンピュータ１００へ接続することができるのは、当業者には明らかであろう。ＤＭＡコントローラ１６０はシステムＲＡＭ１１０へのダイレクト・メモリアクセスを実行するために提供される。視覚表示は、ビデオコントローラ１６５によって生成され、これがビデオ・ディスプレイ１７０を制御する。コンピュータ・システム１００はまた、クライアント・コンピュータ１００がバス１９１経由でネットワーク１９５へ相互接続できるようにするネットワーク・アダプタ１９０も含む。ネットワーク１９５は、ローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、又はインターネットでよく、多数のネットワーク・デバイスを相互接続する汎用通信回線を使用出来る。クライアントコンピュータ・システム１００は、一般にＷＩＮＤＯＷＳ ＮＴ（登録商標）オペレーティングシステム（ワシントン州レドモンドのマイクロソフト社から入手可能）などのオペレーティング・システム・ソフトウェアによって制御調節される。コンピュータ・システム制御機能のなかでも、オペレーティング・システムはシステム資源の割り当てを制御し、プロセスのスケジュール、メモリ管理、ネットワーク及びＩ／Ｏサービスなどのタスクを実行する。

図２に更に詳細に示してあるように、ストレージ・マネージャ２０６は、ＲＡＭ２００（図１のＲＡＭ１１０と同等）に常駐し、ＸＭＬドキュメント２２８及び２３０を使用するアプリケーション・プログラム２０２と、ドキュメント２２８及び２３０が格納される永続的ストレージ２０８の間のインタフェースを提供する。アプリケーション・プログラム２０２は、オブジェクトの格納に使用される永続的ストレージ２０８の種類とは無関係に、一貫したアプリケーション・プログラミング・インタフェース２０４を用いて、ストレージ・マネージャ２０６と相互作用出来る。内部的には、ストレージ・マネージャ２０６は各ドキュメント２１０、２１８をオブジェクト２１２〜２１６と２２０〜２２４の階層列として、各々表現する。ストレージ・マネージャ２０６は、ドキュメント２１０及び２１８を様々なファイルシステム、例えばディレクトリ方式ファイル・サービス、オブジェクト・ストア、リレーショナル・ファイル・システムなどを用いて矢印２２６で模式的に示してあるようにストレージ２０８に格納できる。

本発明のシステムは、従来のＸＭＬファイルで機能する。完全なＸＭＬファイルは、通常３つのコンポーネントから構成されており、これらは特定のマークアップ・タグにより定義される。最初の二つのコンポーネントはオプションで、最後のコンポーネントは必須であり、コンポーネントは以下のように定義される。

１．使用するＸＭＬバージョン、エンコードされた方法、他のファイルを参照しているかどうかを識別するＸＭＬ処理ステートメント。そのようなステートメントは次のようなフォームになる：
<?xml version ="1.0" encoding="UTF-8" standalone="yes"?>

２．ファイル内に存在する要素とその関連性を定義するドキュメント・タイプ定義（ＤＴＤ）。ＤＴＤは内部サブセットのファイル内のマークアップ・タグの形式と内容を記述する正式なマークアップ・タグ宣言（大括弧の間）、又は関連マークアップ宣言（外部サブセット）を含むファイルを参照するかのどちらかである。この宣言は次のような形になる：
<!DOCTYPE Appl SYSTEM "app. dat">

３．ルート要素で構成されるタグ付きドキュメントのインスタンス、これは要素タイプ名がドキュメントタイプ宣言のドキュメントタイプ名と一致しなければならない。他の全てのマークアップ要素はルート要素に入れ子にされる。

３つすべてのコンポーネントが存在していて、ドキュメント・インスタンスがＤＴＤに定義されたドキュメント・モデルに適合していれば、ドキュメントは「有効である」とされる。最後のコンポーネントだけが存在していて、正式なドキュメント・モデルが存在しないが、各要素が親要素内に正しく入れ子になり、かつ各属性が属性名とそれに続く値指示子（＝）と引用符つき文字列で指定されていれば、ドキュメント・インスタンスは「十分整形されている」と言われる。本発明のシステムは良く整形されたＸＭＬドキュメントで動作しこれを生成できる。

ストレージ・マネージャ２０６内で、ＸＭＬドキュメントは、名称「グループ・ドキュメント」と集合的に呼ばれるデータ・ストレージ・パーティションにより表現されて、従来のＸＭＬドキュメントとは表示が区別される。各グループ・ドキュメントはそのドキュメントを構成する各種要素の間の関連性を正しく識別するＤＴＤによって記述できる。これらのＤＴＤは標準ＸＭＬフォーマットに従う。更に、各グループ・ドキュメントは定義又はスキーマがあり、これはドキュメントの本体で要素と属性のパターンを記述する。ＸＭＬバージョン１．０はスキーマをサポートしていない。そのため、グループ・スキーマドキュメントをＸＭＬデータ・ドキュメントに関連付けるには、スキーマへのＵＲＩ参照を含む特別なＸＭＬ処理命令をデータ・ドキュメントに含める。この処理命令は次の形である：
<?schema URI="groovedocument:///GrooveXSS/$PersistRoot/sample.xml"?>

幾つかの要素はコンテンツがないか必要とせず、どこで何らかのプロセスが行なわれることを示すプレースホルダーとして機能する。タグの特別なフォームをＸＭＬで使用して何のコンテンツも持っていない、従って終了タグのない空の要素を示す。例えば、＜ＴｈｕｍｂｎａｉｌＢｏｘ＞要素はテキスト行に埋め込まれた画像のプレースホルダーとして機能する空の要素で次のような宣言をＤＴＤに行なう：
<!ELEMENT ThumbnailBox EMPTY>

要素が可変フォームを持つことができる場合、又は相互にリンクされる必要がある場合、適当な属性を与えてこれに適用されるべきプロパティを指定することができる。これらの属性はリストで指定する。例えば、＜ＴｈｕｍｂｎａｉｌＢｏｘ＞要素がＬｏｃａｔｉｏｎとＳｉｚｅ属性を含むことがあると決定されるとする。このような属性で適当と思われる属性リスト宣言は次のようになる：
<!ATTLIST ThumbnailBox
Location ENTITY #REQUIRED
Size CDATA #IMPLIED
>

これは＜ＴｈｕｍｂｎａｉｌＢｏｘ＞要素が要求されたＬｏｃａｔｉｏｎエンティティ（実体）を含みＳｉｚｅ属性を含むことがあることをコンピュータに伝える。キーワード＃ＩＭＰＬＩＥＤは＜ＴｈｕｍｂｎａｉｌＢｏｘ＞要素の幾つかのインスタンスで属性を除くことが許容されることを表わす。

ＸＭＬは、幾つかのコンパイラで使用される＃ＤＥＦＩＮＥステートメントと類似のカスタム定義ステートメントも許容している。一般に使用される定義は「エンティティ（実体）」としてＤＴＤ内部で宣言できる。典型的なエンティティ（実体）定義は次の形をとれる：
＜！ＥＮＴＩＴＹ ＢｉｎＤｏｃ３４８７ ＳＹＳＴＥＭ ”．／３４８７．ｇｉｆ” ＮＤＡＴＡ＞

これは”ＢｉｎＤｏｃ３４８７”バイナリ・ドキュメントのファイルの場所を定義する。このような宣言をＤＴＤで一度行なっておけば、ユーザは完全な値のかわりに参照を利用できる。例えば、先に説明した＜ＴｈｕｍｂｎａｉｌＢｏｘ＞要素は
<ThumbnailBox Location = BinDoc3487 Size="Autosize"/>
として指定できる。この技術を使う利点は、後で定義された値を変更しなければならない場合に、エンティティ（実体）参照は自動的に現在の宣言の内容を使用するのでＤＴＤのエンティティ（実体）宣言だけを更新すればよい点である。

ストレージ・マネージャ内部で、各ドキュメント部分は統一資源識別子（ＵＲＩ）で識別され、これはＲＦＣ２３９６に指定きれているような標準的フォーマットに準拠する。ＵＲＩは絶対でも相対でも良いが、相対ＵＲＩは基礎となる絶対ＵＲＩのコンテキスト内でのみ使用する必要がある。ドキュメントが永続的ストレージに保存された場合、これの部分は使用している特定のファイルシステムによって割り当てられ、管理される他のＳＴＯＲＡＧＥＵＲＩにより識別できる。

本発明の原理によれば、ストレージ・マネージャでは、各ドキュメント部分の内部で、内部メモリがオブジェクトの集合により表現される。例えば、ＸＭＬドキュメント内部の他の要素はストレージ・マネージャ内の要素オブジェクトとして表現される。これにより図３に示してあるような構造が得られる。図３において、例示のＸＭＬドキュメント３００はストレージ・マネージャ３０２内のオブジェクト集合として表現されている。更に詳しくは、ＸＭＬドキュメント３００は、前述したようなＸＭＬバージョン、エンコード方法、及びファイル参照を表わす、従来のＸＭＬ処理ステートメント３０４を含む。ＸＭＬドキュメント３００は、ＸＭＬドキュメント３００と関連付けられたストレージ・マネージャ３０２内のスキーマ・ドキュメント３２０を識別する、ＸＭＬ処理ステートメント３０６も含む。図示したＸＭＬドキュメントは階層化要素のセットも含み、これには何らかのテキスト３１８を含むＥｌｅｍｅｎｔＡ３０８を含み、ＥｌｅｍｅｎｔＡは関連付けられたテキストがないＥｌｅｍｅｎｔＢ３１０を含む。ＥＩｅｍｅｎｔＢは更にＥｌｅｍｅｎｔＣ３１２を含み、これには更に二つの要素が含まれている。つまりＥｌｅｍｅｎｔＣは属性（値”ｆｏｏ”の入ったＩＤ）を持っているＥｌｅｍｅｎｔＤ３１４とＥｌｅｍｅｎｔＥ３１６である。

ストレージ・マネージャ３０２では、要素群、ＥｌｅｍｅｎｔＡ〜ＥｌｅｍｅｎｔＥが階層内に構成された要素オブジェクトとして表現される。更に詳しくは、ＥｌｅｍｅｎｔＡはＥｌｅｍｅｎｔＡオブジェクト３２２により表現される。各要素オブジェクトは、対応するＸＭＬ要素に含まれるテキストと属性とを含む。そのため、要素オブジェクト３２２はテキスト３１８を含む。同様に、ＥｌｅｍｅｎｔＢ３１０は要素オブジェクト３２４で表現され、ＥｌｅｍｅｎｔＣ、ＥｌｅｍｅｎｔＤ、ＥｌｅｍｅｎｔＥはそれぞれオブジェクト３２６、３２８、３３０で表現される。要素オブジェクト３２８は、要素ＥｌｅｍｅｎｔＤを表現し、また対応する要素に含まれる属性ＩＤも含む。各要素オブジェクトは、データベース・ポインタ（オブジェクト間の矢印で示す）により子要素オブジェクトを参照し、階層内に要素オブジェクトを構成する。また属性インデックス、例えば要素オブジェクト３２８内のＩＤ属性を表わすインデックス３３２などもある。

オブジェクト集合を用いることによるＸＭＬドキュメント３００の表現により、ストレージ・マネージャ３０２は、以下で詳細に説明するような一貫したインタフェースでＸＭＬドキュメント３００の内部表現を操作できる。ストレージ・マネージャ３０２も従来のＸＭＬドキュメントでは利用できなかった特徴、例えばこれも詳細に以下で説明する集合マネージャ経由で利用できる集合サービスなどを提供する。

すでに説明したように、ＸＭＬデータを含むグループ・ドキュメントはドキュメント本体の要素と属性のパターンを記述した定義、又はスキーマ・ドキュメントを持っている。スキーマ・ドキュメントは、ＵＲＩで識別される独立したＸＭＬドキュメントに保存される。スキーマ・ドキュメントは標準ＸＭＬ ＤＴＤ定義を持ち、これはメタ・スキーマと呼ばれ、次に示すようなものである：
<!-- ドキュメント要素はスキーマのルート要素である -->
<!ELEMENT Document (Registry*, AttrGroup*, ElementDecl*)>
<!ATTLIST Document
URL CDATA #REQUIRED
>
<!ELEMENT Registry TagToProgID *>
<!ELEMENT TagToProgID EMPTY>
<!ATTLIST TagToProgID
Tag CDATA #REQUIRED
ProgID CDATA #REQUIRED
>
<!ELEMENT AttrGroup AttrDef *>
<!ELEMENT AttrDef EMPTY>
<!ATTLIST AttrDef
Name CDATA #REQUIRED
Type CDATA #REQUIRED
Index CDATA #IMPLIED
DefaultValue CDATA #IMPLIED
>
<!ELEMENT ElementDecl (ElementDecl*|AttrGroup|ElementRef*)>
<!ATTLIST ElementDecl
Name CDATA #REQUIRED
>
<!ELEMENT EIementRef EMPTY>
<!ATTLIST ElementRef
Ref CDATA #REQUIRED
>

スキーマ内の要素の各々は、ドキュメント処理中にストレージ・マネージャによって使用される情報を定義する。レジストリ”Ｒｅｇｉｓｔｒｙ”セクションはＸＭＬ要素タグをウィンドウズ（登録商標）のＰｒｏｇＩＤにマッピングする２カラムのテーブルのＸＭＬ表現を構成する（マイクロソフト社により開発されたコモン・オブジェクト・モデル（ＣＯＭ）では、ＰｒｏｇＩＤはＣＯＭシステム内でプログラム・コードのセクションに「結合（ｂｏｕｎｄ）」されたかあるいは関連づけられているオブジェクトのテキスト名である。任意のＰｒｏｇＩＤとプログラム・コードの間のマッピングは、ライブラリに格納されており、ウィンドウズ（登録商標）・レジストリなどの定義領域で指定される）。

この構造を図４Ａに示し、ＸＭＬドキュメント４００とこれに関連したスキーマ・ドキュメント４０２が示してある。これらのドキュメントはどちらもストレージ・マネージャ４０６に常駐し、実際には図３に示したようなオブジェクトによって表現される。しかし、図４では、ドキュメントは簡略化のため従来のＸＭＬフォーマットで表現してある。図４はウィンドウズ（登録商標）環境で動作するストレージ・マネージャを示してあり、これはワシントン州レドモンドのマイクロソフト社が開発したコモン・オブジェクト・モデル（ＣＯＭ）に従って構築されたオブジェクトを使用するが、同じ原理が他のオペレーティングシステム環境にも適用される。

ＸＭＬドキュメント４００は、ＸＭＬバージョン、エンコード方法とファイル参照を識別する通常のＸＭＬ処理ステートメント４１４を含む。スキーマＸＭＬ処理ステートメント４１６はスキーマ・ドキュメント４０２を参照し、このスキーマ・ドキュメントはドキュメント４００に関連付けられており、名称ステートメント４２６で定義された名前”ｕｒｎ：ｇｒｏｏｖｅ．ｎｅｔ：ｓａｍｐｌｅ．ｘｍｌ”を持っている。また名称”ｄｏｃ．ｘｍｌ”と”ｕｒｎ：ｇｒｏｏｖｅ．ｎｅｔ”として定義された”ｇ”ＸＭＬネームスペースを定義しているルート要素４１８も含む。

ドキュメント４００は、他に３つの要素があり、タグ”ｕｒｎ：ｇｒｏｏｖｅ．ｎｅｔ：ＡＡＡ”で定義された要素４２０と、タグ”ｕｒｎ：ｇｒｏｏｖｅ．ｎｅｔ：ＢＢＢ”で定義された要素４２２と、タグ”ｕｒｎ：ｇｒｏｏｖｅ．ｎｅｔ：ＮｏＣｏｄｅ”で定義された要素４２４とを含む。要素４２４はスキーマ・ドキュメント４０２に対応する接合コードがなく、また対応するタグからＰｒｏｇＩＤへのマッピングもない単純要素である。

タグ４２８で定義された「レジストリ”ｒｅｇｉｓｔｒｙ”」セクション内でスキーマ・ドキュメント４０２には２つの要素からＣＯＭ ＰｒｏｇＩＤへのマッピングが定義してある。一方のマッピングはタグ”ｕｒｎ：ｇｒｏｏｖｅ．ｎｅｔ：ＡＡＡ”の要素について定義され、もう一方は”ｕｒｎ：ｇｒｏｏｖｅ．ｎｅｔ：ＢＢＢ”の要素について定義されている。結合コードは、クライアント・アプリケーション４０４がメソッド”ＯｐｅｎＢｏｕｎｄＣｏｄｅ（）”を呼び出した時にアクセスされる。この呼び出しの書式は表１５の下に示したようなもので関係するステップが図４Ｂに図示してある。ＯｐｅｎＢｏｕｎｄＣｏｄｅ（）メソッドを単純な要素、例えば要素４２４で呼び出すことで例外を生成する。結合コードを取り出すプロセスは、ステップ４３４で始まりステップ４３６に進んでＯｐｅｎＢｏｕｎｄＣｏｄｅ（）を呼び出す。要素タグ”ｕｒｎ：ｇｒｏｏｖｅ．ｎｅｔ：ＡＡＡ” のついた要素でＯｐｅｎＢｏｕｎｄＣｏｄｅ（）メソッドを呼び出すとストレージ・マネージャ４０６にステップ４３８で説明するように要素タグのついたスキーマ・ドキュメント６０２のレジストリ要素４２８を参照させる。セクション４３０から、ストレージ・マネージャはステップ４４０に示したようにＰｒｏｇＩＤ ”Ｇｒｏｏｖｅ．Ｃｏｍｍａｎｄ” を取り出す。ステップ４４２で、ストレージ・マネージャはＣＯＭマネージャ４０８を呼び出し、このＰｒｏｇＩＤを持ったオブジェクトを作成するように指示する。従来の周知の方法では、ステップ４４４で、ＣＯＭマネージャがウィンドウズ（登録商標）・レジストリ４１０のキーを使ってＰｒｏｇＩＤからＣＳＬＩＤに変換している。ステップ４４６では、ＣＯＭマネージャがＣＳＬＩＤを使ってそのオブジェクトのコードを持っているコード・データベース４１２でダイナミック・ローダブル・ライブラリ（ＤＬＬ）ファイルを検索する。最後に、ステップ４４８で、ＣＯＭマネージャはオブジェクトを作成してそのオブジェクトへのインタフェース・ポインタをストレージ・マネージャ４０６に返し、ストレージ・マネージャは更に、ポインタをクライアント・アプリケーション４０４に返す。ルーチンはこうしてステップ４５０で終了する。クライアント・アプリケーション４０４は、ポインタを使って属性と関連要素内のコンテンツを使用するコードでメソッドを起動する。要素は、そして他のＣＯＭオブジェクトと同様に振る舞う。同様のプロセスが、タグ”ｕｒｎ：ｇｒｏｏｖｅ．ｎｅｔ：ＢＢＢ”のついた要素でＯｐｅｎＢｏｕｎｄＣｏｄｅ（）メソッドを起動した場合にも発生する。

”ＡｔｔｒＧｒｏｕｐ”セクションは、属性についての非ＸＭＬ特性を定義する。属性のデータ形式はテキスト以外の何らかの形式として定義でき、属性はこれを含む要素の高速取り出しを容易にするべくインデックスが付けられる。

”ＥｌｅｍｅｎｔＤｅｃｌ”セクションはＤＴＤ＜！ＥＬＥＭＥＮＴ＞宣言と同様の要素定義フォームを提供するが、拡張属性の特徴と非包含要素参照の定義を許容する。

以下の例では、すでに説明した「テレスペース」を定義するＸＭＬドキュメントについてのスキーマ・ドキュメントのサンプル部分を示す。
<groove:Document URL="TelespaceSchema.xml"
xmlns:groove="urn:groove.net:schema.l">
<groove:Registry>
<groove:TagToProgID groove:Tag="g:Command"
groove:ProgID="Groove.Command"/>
<groove:TagToProgID groove:Tag="groove:PropertySetChanged"
groove:ProgID="Groove.PropSetChangeAdvise"/>
</groove:Registry>
<groove:AttrGroup>
<groove:AttrDef Name="ID" Index="true"/>
<!-- KEY EXCHANGE ATTRIBUTES -->
<groove:AttrDef Name="NKey" Type="Binary"/>
<groove:AttrDef Name="ReKeyld" Type="String"/>
<groove:AttrDef Name"T" Type="String"/>
<!-- AUTHENTICATION ATTRIBUTES -->
<groove:AttrDef Name="MAC" Type="Binary"/>
<groove:AttrDef Name="Sig" Type="Binary"/>
<!-- ENCRYPTION ATTRIBUTES -->
<groove:AttrDef Name="IV" Type="Binary"/>
<groove:AttrDef Name="EC" Type="Binary"/>
<!-- XML Wrapper Attributes -->
<groove:AttrDef Name="Rows" Type="Long"/>
<groove:AttrDef Name="Cols" Type="Long"/>
<groove:AttrDef Name="Items" Type="Long"/>
<groove:AttrDef Name="ItemID" Type="Bool" Index="true"/>
</groove:AttrGroup>
<groove:ElementDecl Name="groove:Telespace">
<AttrGroup>
<AttrDef Name="Persist" DefaultValue="True" Type="Bool"/>
<AttrDef Name="Access" DefaultValue="Identity" Type="String"/>
</AttrGroup>
<ElementRef Element="Dynamics"/>
<ElementRef Element="Members"/>
</groove:ElementDecl>
</groove: Document>

この例では、ＴａｇからＰｒｏｇＩＤへのマッピングテーブルに二つのエントリがある。最初のエントリはタグ”ｇ：Ｃｏｍｍａｎｄ”（これはＸＭＬ名前空間の拡張を使用し”ｕｒｎ：ｇｒｏｏｖｅ．ｎｅｔ．ｓｃｈｅｍａ．１：Ｃｏｍｍａｎｄ”である）からＰｒｏｇＩＤ ”Ｇｒｏｏｖｅ．Ｃｏｍｍａｎｄ” にマッピングする。属性を定義するセクションで、”ＩＤ”属性はインデックス化されていて、ＮＫｅｙ属性のデータ形式がバイナリである、と言うように続く。

このスキーマ・データは要素オブジェクトによって表現され、以下で詳細に説明するようにドキュメントを操作するために使用するのと同じストレージ・マネージャ要素及び属性インタフェース・メソッドによってアクセス／操作できる。更に詳しくは、ドキュメントを記述する情報がドキュメント内容を操作するのに使用されるのと同じインタフェースを使用して操作できる。

本発明の他の態様によれば、サブドキュメントはプライマリ・ドキュメントに関連付けられる。あらゆるドキュメントが任意のドキュメントのサブドキュメントにできる。あるドキュメントが他のドキュメントへのサブドキュメント参照を含む場合、参照されたドキュメントはサブドキュメントである。二つのドキュメントが互いにサブドキュメント参照を含む場合には、各々のドキュメントが他方のドキュメントのサブドキュメントである。各サブドキュメントは、従来からのＸＭＬＸＬｉｎｋ言語でプライマリ・ドキュメントから参照されるが、この言語はｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｘｌｉｎｋ／に詳細な説明がある。リンクは、又、完全テキストＸＭＬドキュメントとバイナリ・サブドキュメントとの関連を策定する。バイナリ・ドキュメントはどのような種類のサブドキュメントへのリンクも持たない。リンクがドキュメントの一部への場合、サブドキュメントの関連性はその部分を含むドキュメントに対して設定される。ドキュメントとサブドキュメントとの関連性が図５に示してある。

例えば、主ドキュメント５００はリンク５０２を内包し、リンク５０２は矢印５１０で示してあるドキュメント５０４へのリンクと、矢印５０８で示してあるバイナリ・ドキュメント５０６へのリンクを含む。従って、ドキュメント５０４と５０６は、ドキュメント５００のサブドキュメントである。ドキュメント５０４は更にリンク５１２を含み、このリンクは矢印５１４で示されるようにコンテンツ５１８のあるドキュメント５１６へのリンクを含む。ドキュメント５１６はドキュメント５００のサブドキュメントである。ドキュメント５０６はバイナリ・コンテンツ５２０を含み、そのためサブドキュメントへのリンクを持てない。

サブドキュメントのリンクは、単純なリンクについての標準定義に従属する。リンクについての代表的な要素定義は次のようなものである：
<!ELEMENT GrooveLink ANY>
<!ATTLIST GrooveLink
xml:link CDATA #FIXED "simple"
href CDATA #REQUIRED
role CDATA #IMPLIED "sub-document"
title CDATA #IMPLIED
show (parsed|replace|new) #IMPLIED
actuate (autoluser) #IMPLIED
serialize (byvalue|byreference|ignored) #IMPLIED
behavior CDATA #IMPLIED
content-role CDATA #IMPLIED
content-title CDATA #IMPLIED
inline (true|false) #IMPLIED "true">

上記の定義を使用せず、値”ｓｉｍｐｌｅ”のｘｍｌ：ｌｉｎｋ属性とｈｒｅｆ属性とを持ったＸＭＬリンクをドキュメントに追加することでサブドキュメントの関連性を構築することも可能である。このようなリンクはｈｒｅｆ属性のＵＲＩ値によって識別されるドキュメントへのサブドキュメントの関連性を構築する。

ドキュメントからこれのサブドキュメントへの関連性ができると、ドキュメントとサブドキュメントの任意のセットのコピーを作ることが可能になる。一つのストレージ・サービス内で、このようなコピーを直接実行することが可能である。ストレージサービスを横断する、あるいは複数ドキュメントを他のマシンへ送信するには、このようなドキュメントの階層全体をシリアル化した方法で「記述可能」にする必要がある。本発明のストレージ・マネージャは、集合ドキュメントのＭＩＭＥ封入（Ｅｎｃａｐｓｕｌａｔｉｏｎ）の仕様に適合するテキスト表現へと、例えばｆｔｐ：／／ｆｔｐ．ｉｓｉ．ｅｄｕ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ２５５７．ｔＸｔ／で詳細に説明が見られるＨＴＭＬ（ＭＨＴＭＬ）などに、多数のドキュメントをシリアル化する。

以下のデータ・ストリーム断片はＭＨＴＭＬ文字列に見られるようなドキュメントと参照されるサブドキュメントの一例である。本例では、”ＳＰ”は一つの空白文字が存在することを意味し、”ＣＲＬＦ”は復帰・改行のアスキー文字対を表わす。他の全ての文字はそのまま送信される。ＭＩＭＥバージョン・ヘッダは通常のＭＩＭＥバージョンであり、グループ・プロトコルバージョンはＲＦＣ８２２のコメントにある。コメントは単に単語Ｇｒｏｏｖｅとそれに続く整数である。境界セパレータ文字列はユニークなものとし、ＭＩＭＥとついで各本体部分をパースするシステムが正しく動作するようにする。シリアル化ＸＭＬテキストはＵＴＦ−８フォーマットで示してあるが、ＷＢＸＭＬフォーマットで送信することもできる。ＸＭＬドキュメントはＸＭＬプレフィックスを持ち、これはバージョンならびに文字エンコード方法を含む。バイナリ・ドキュメントはｂａｓｅ６４で符号化される。

MIME-Version : SP 1.0 SP (Groove SP 2) CRLF
Content-Type: SP multipart/related ; SP boundary="<<[[&&&]]>>" CRLF
CRLF
--<<[[&&&]]>> Content-Type : SP text/XML ; SP charset="UTF-8"
<?xml version="1.0" encoding='utf-8'?>
<rootelement>
.
.
.
</rootelement> CRLF
CRLF
--<<[[&&&]]>>
Content-ID : SP <URI> CRLF
Content-Type: SP application/octet-stream CRLF
Content-Transfer-Encoding: base64 CRLF
CRLF
ROIGODlhdQAgAPcAAP//////zP//mf//Zv//M///AP/M///MzP/Mmf/MZv/MM//MAP+Z//+ZzP+Zmf+ZZv+ZM/+ZAP9m//9mzP9mmf9mZv9mM/9mAP8z//8zzP8zmf8zZv8zM/8zAP8V//8AzP8Amf8AZv8AM/8AAMz//8z/zMz/mcz/Zsz/M8z/AMzM/8zMzMzMmczMZszMM8zMAMyZ/8yZzMyZmcyZZsyZM8yZAMxm/8xmzMxmmcxmZsxmM8xmAMwz/8wzzMwzmcwzZswzM8wzAMwA/8wAzMwAmcwAZswAM8wAAJn//5n/zJn/mZn/Zpn/M5n/AJnM/5mMzJnMmZnMZpnMM5nMAJmZ/5mZOG/qTMnzJUWQHoMKHUq0KEagRpMqXaoUaU6dG2IKIOqRKt0kTq9q3VrV5sd/XMOKZZp1rNmzGsuiXct2hNq2cMVmXdkzZ12LLe/ehYrXpsy/MPUGHvw04lzCdhFbzasYMd+aUxsnnrzTq1uwcTN3tVrxrebPWDGDHr3UM+nTHE2jXn1RNevXEl3Dfi179urDJrte5BzVcknNhyNHZiyzJnGvuWMuppu7uHLkyV1Kxe1ccOGZOCn/xshcu8/K2g2LQ8bJGPJj4eh3+/WNHb118PAtBn8aXTrn6s7tl2QP9b399fhNN55tbe31FYEITIRbgqAtvCBwAz5120MUVmjhhRgyFBAAOw==
--<<[[&&&]]>>--

文書エディタやインターネット・ブラウザなどの大半のＸＭＬ処理装置とは異なり、ストレージ・マネージャは、同時的なドキュメント操作を提供する。ドキュメントは同時的に検索され、要素は同時的に作成、削除、更新又は移動される。要素の階層のコピーは、一つのドキュメントから他のドキュメントへ移動できる。大半のＸＭＬ処理装置では、ドキュメントへの更新の全部が一人のユーザによって行なわれ、このユーザは一台のコンピュータ上の一つのプロセス内の一つのスレッドを制御するのが普通である。

ストレージ・マネージャは、多数のユーザが同一のドキュメントを更新する間もＸＭＬドキュメントの完全性を保持するのに、多数のプロセスでの多数のスレッドを使用する。好適な実施態様では、更新の全部が一台のコンピュータ上で発生するが、他にも従来の異なるプロセッサ間通信メカニズムを用いる他の動作実施態様が可能である。図６はストレージ・マネージャの基本構造を示しプロセス間通信の問題からアプリケーション・プログラムをいかに隔離するかを示している。例えば、二つの独立したプロセス６００と６０２が同時に、同じコンピュータ上で又は他のコンピュータ上で動作している。プロセス６００は後述するように「ホーム」プロセスで、一方プロセス６０２はプロセスＮとして指定される他のプロセスである。プロセス６００内部で、マルチスレッド・クライアント・アプリケーション・プログラム６０６が動作しており、プロセス６０２の内部ではマルチスレッド・クライアント・アプリケーション・プログラム６１６が動作している。

各アプリケーション・プログラム６０６、６１６は各々参照番号６０５、６１５で指定されたストレージ・マネージャとインタフェースする。プロセス６００では、ストレージ・マネージャはアプリケーション・プログラム６０８が使用してストレージ・マネージャを制御し、これとインタフェースするストレージ・マネージャ・インタフェース層６０８を含む。これは実際にアプリケーションによって操作されるデータベース、ドキュメント、要素、スキーマ・オブジェクトを含む。この層からエクスポートされるＡＰＩについては、以下で詳細に説明する。ストレージ・マネージャ６０５は分散仮想オブジェクト（ＤＶＯ）データベース・メソッド６１０、基本データ形式のためのＤＶＯメソッド６１２、ＤＶＯコモン・システム・メソッド６０９、分散共有メモリ６１４も含む。同様に、プロセス６０２で動作しているストレージ・マネージャはトランザクション層６１８、ＤＶＯデータベースメソッド６２０、基本データ形式のためのＤＶＯメソッド６２２，ＤＶＯコモン・システム・メソッド６１７、分散共有メモリ６２４を含む。

二つのプロセス６００と６０２は、従来のメッセージ受け渡しプロトコル又はプロセス間通信（ＩＰＣ）システム６０４を介して通信する。一台のコンピュータ上で動作するプロセスでは、このようなシステムは共有メモリバッファを用いてウィンドウズ（登録商標）（Ｒ）オペレーティングシステムに実装できる。プロセスが他のコンピュータ上で動作している場合、他のメッセージ受け渡しプロトコル、例えばＴＣＰ／ＩＰなどを使用できる。他の従来のメッセージング又は通信システムも本発明の動作を改変することなく使用できる。しかし、図６に示してあるように、アプリケーション・プログラム６０６と６１６はメッセージ受け渡しシステム６０４と直接相互作用しない。その代わり、アプリケーション・プログラム６０６と６１６は、各々ストレージ・マネージャ６０５、６１５と相互作用し、ストレージ・マネージャ６０５、６１５は、分散共有メモリ（ＤＳＭ）システム６１４と６２４が一部を構成するＤＳＭシステムを介してメッセージ受け渡しシステム６０４と相互作用する。

多数の周知のＤＳＭシステムが存在し、本発明での使用に適当である。好適な実施態様において、ストレージ・マネージャで使用されるＤＳＭシステムは、Ｃリージョン・ライブラリ（ＣＲＬ）システムと呼ばれる。ＣＲＬシステムは全ソフトウェア分散共有メモリシステムで、メッセージ受け渡しマルチコンピュータ分散とシステム上での使用を想定している。ＣＲＬシステムとこのようなシステムを実装するためのコードは、”ＣＲＬ： Ｈｉｇｈ−Ｐｅｒｆｏｒｍａｎｃｅ Ａｌｌ Ｓｏｆｔｗａｒｅ Ｄｉｓｔｒｉｂｕｔｅｄ Ｍｅｍｏｒｙ Ｓｙｓｔｅｍ”， Ｋ． Ｌ． Ｊｏｈｎｓｏｎ， Ｍ． Ｆ． Ｋａａｓｈｏｅｋ ａｎｄ Ｄ． Ａ． Ｗａｌｌａｃｈ， Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ Ｆｉｆｔｅｅｎｔｈ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ Ｐｒｉｎｃｉｐｌｅｓ， ＡＣＭ， Ｄｅｃｅｍｂｅｒ １９９５； 及び”ＣＲＬ ｖｅｒｓｉｏｎ １．０ Ｕｓｅｒ Ｄｏｃｕｍｅｎｔａｔｉｏｎ”， Ｋ． Ｌ． Ｊｏｈｎｓｏｎ， Ｊ． Ａｄｌｅｒ ａｎｄ Ｓ． Ｋ． Ｇｕｐｔａ， ＭＩＴ Ｌａｂｏｒａｔｏｒｙ ｆｏｒ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ， Ｃａｍｂｒｉｄｇｅ， ＭＡ ０２１３９， Ａｕｇｕｓｔ １９９５に詳細に説明されている。どちらの論文も以下のウェブアドレスから入手可能である： ｈｔｔｐ：／／ｗｗｗ．ｐｄｏｓ．ｌｃｓ．ｍｉｔ．ｅｄｕ／ｃｒｌ／。

ＣＲＬの上に構築される並列アプリケーション、例えばストレージ・マネージャなどはメモリの「リージョン（ｒｅｇｉｏｎｓ）」からデータを共有する。各リージョンは任意の大きさで、連続したメモリ領域（ａｒｅａ）である。共有メモリのリージョンは、ＤＳＭシステムの各種関数により作成され、他のプロセスにマッピングされ、マッピング解除され、削除される。本発明で使用するＤＳＭシステムは、ＣＲＬＤＳＭシステムで使用されている関数のスーパーセットを提供する。メモリリージョンのユーザは、あるリージョンに対して読み取り又は書き込みが必要な時に、ＤＳＭに対して宣言し、リージョンの使用後は、読み込み又は書き込みの完了を宣言することによりアクセスを同期する。書き込み動作の影響は、リージョンを共有している他のプロセスがそれの必要性を宣言するまで伝播されない。基本的共有メモリと同期動作に加えて、ＤＳＭはエラー処理とトランザクションの信頼性も提供する。本発明のＤＳＭの全部のインタフェースが表１に示してある：

各ストレージ・マネージャ６０５、６１５は、対応するプロセス６００、６０２のアドレス空間内にある１つ以上のＤＳＭリージョン（図６には図示していない）を使用するＤＳＭノードを含む。これらのリージョンはＤＶＯオブジェクトとクラスを含み、ストレージ・マネージャにより管理されるドキュメント、要素、ＸＭＬデータのスキーマを表現するために使用できる。ドキュメントの一部、通常は、要素とインデックスセクションがリージョン内部に全体として含まれる。ＤＳＭシステムはリージョン共有のための概念的に均一なノード空間を提供するが、特別なタスクを実行する特定ノード又はプロセスを選抜する必要が出て来るという問題がある。

結果として、ＤＳＭ同期プロトコル内で、一つのノードが各リージョンについての「ホーム・ノード」として識別される。１台のコンピュータ上でストレージ・マネージャを動作させている多数のプロセスのうち、「ホーム・プロセス」と呼ばれる一つのプロセスが全てのディスクＩ／Ｏ動作を実行するプロセスである。プロセス間でのデータ移動量を減少するため、ホーム・プロセスは全リージョンについてのホーム・ノードである。全てのノードが全てのリージョンのホームになることができ、全てのプロセスがディスクＩ／Ｏを実行するような他の実装も可能である。しかし、１台のディスク・ドライブを持ったパーソナル・コンピュータでは、多数のプロセスにディスクＩ／Ｏを実行できるようにすることでＩ／Ｏ同期の必要が発生し、同時にディスク１台であるという主なパフォーマンス上のボトルネックを緩和しなければならない。

ＤＳＭ動作によると、プロセスがあるリージョンの最新コピーを持っている場合、そのリージョンを読み書きできる。それ以外、プロセスはリージョンの読み書きをする前にホーム・プロセスから最新コピーを取り寄せる必要がある。各ＤＳＭシステム６１４、６２４はノード間通信層（６１５、６２５）と呼ばれるインタフェース層を介してメッセージ受け渡しシステム６０４とインタフェースしており、ノード間通信層が基盤となる伝送メカニズムからＤＶＭシステムを隔離する。これはブロードキャスト・グループへメッセージを送信し、対応するプロセスとホーム・プロセスのアドレスを操作するメソッドを含む。

本発明のストレージ・マネージャは、ＸＭＬオブジェクトの基礎として共有オブジェクトを使用する。プロセス間やコンピュータ間でオブジェクトを共有する多くのシステムが存在する。このようなオブジェクト共有モデルの一つはオペレーティング・システムにより提供される、共有メモリ機能の使用に基づくものである。このような共有メモリ・モデルで最大の欠点の一つは、メモリへの書き込み失敗による信頼性の欠如で、これは他のプロセスの完全性に影響を与える。例えば、一つのプロセスがオブジェクトの状態を更新するプロセスで、そのプロセスが分かっている良好な状態にオブジェクトをセットする前に失敗すると、他のプロセスからはオブジェクトが無効な状態に見えるか、ブロックされてしまい失敗したプロセスが同期ロックを解除するまで無限に待機することになる。共有メモリ・モデルも緊密に結合したマルチ・コンピュータでの共有メモリのローカリティ制約に苦しめられ、ネットワーク上でオブジェクトを共有する方法が何も提供できない。

分散オブジェクト共有及びリモート・メソッドの呼び出しを提供する他のモデルは、Ｊａｖａ（登録商標）あるいはＯｂｊｅｃｔ Ｍａｎａｇｅｍｅｎｔ ＧｒｏｕｐのＣＯＲＢＡシステムで分散オブジェクト管理機能を基盤にしている。コンピュータ・ネットワーク上でオブジェクトを共有する能力が提供されるものの、このようなシステムのクライアントはオブジェクトがローカルなのか、リモートなのかに注意を払う必要がある――オブジェクトはロケーションに依存しない。このアプローチでは、パフォーマンスが他の欠点である。オブジェクトに対する全ての動作はオブジェクト・サーバへ送信する必要があるが、これは、サーバがオブジェクト状態の唯一のコピーを含んでいてそのデータについての同期ポイントとして機能するためである。

これらの欠点を克服するため、本発明のストレージ・マネージャは分散仮想オブジェクト（ＤＶＯ）システムを使用してＸＭＬオブジェクト形式を構築すべきプリミティブ・データ形式を提供する。ＤＶＯシステムはまた、データが多数のコンピュータ上の多数のプロセスにある場合でも、又は本当は一つのコンピュータ・ノード上の一つのプロセスに存在していても、全てのデータが一つのコンピュータ・ノード上の一つのプロセスに確実に含まれていると言う錯覚を呼び出し側に提供する。

ＤＶＯオブジェクト共有モデルを図７に示す。オブジェクトを共有している全てのコンピュータ上の全てのプロセスは、同じメソッド・コードを持っている。例えば、図７のプロセス７００とプロセス７０２は同じオブジェクトのコピーを持っている。つまり、プロセス７００、７０２の各々が同じメソッド・コードのコピー７０４、７０６を各々のプロセス・アドレス空間に持っている。あるオブジェクトについて揮発性のデータ状態がＤＳＭリージョンに格納される。つまりプロセス７００のオブジェクト・コピーについてオブジェクト・データ７０８はプロセス７００のアドレス空間のリージョン７１０に格納されている。同様に、プロセス７０２のオブジェクトコピーについて、オブジェクトデータ７１２は、プロセス７０２のアドレス空間のリージョン７１４に格納される。オブジェクト・メソッドはＤＳＭ同期機能を使ってオブジェクトのデータへのアクセスを同期させ、同期機能が矢印７１６で示したようにリージョンを同期させる。この方法だと、ＤＶＯオブジェクトはロケーションに依存せず、失敗は一つのプロセス内部に含まれ、ローカル・オブジェクトに対する多数の変更がノード間伝送によるデータ移動を必要としなくなる。

ＤＶＯシステムは構築ブロックとして使用され、ストレージ・マネージャ用にＸＭＬドキュメントを管理し、３つの機能部分に分割される基本的オブジェクトを提供する。ＤＶＯデータベース６１０は、各プロセスにローカルなＤＶＯコンテクストを取り扱うオブジェクトと、開いているデータベースに関する情報と、これらのデータベース内に含まれるドキュメントに関する情報を含む共有テーブルとを含む。ＤＶＯでは、「データベース」は概念的なストレージ・コンテナであり、何らかのストレージ・サービス６０９に最終的に保存されるオブジェクトを伝送する。ＤＶＯドキュメントにはＸＭＬ又はバイナリ・ドキュメントが関連し、これらはストレージ・マネージャのクライアントから見ることができる。ＤＶＯドキュメントはまた集合に関連付けられたインデックス及びメタデータを内包するためにも使用される。

ＤＶＯタイプ６１２は、ＤＶＯドキュメント内で使用できるオブジェクト・クラスのセットで、もっと高レベルなデータ・モデル構造を実装する。ＤＶＯタイプは単純なデータ包含オブジェクトから複雑なスケーラブルインデックス構造まで範囲が広がる。各ＤＶＯタイプは二つのクラスで実装される――そのひとつは「非共有クラス」で、これはオブジェクト参照にメモリ・ポインタを使用するもの、またもう一つは「共有クラス」で、これはオブジェクト参照にデータベース・ポインタと呼ばれる論理アドレスを使用する。「共有クラス」は二つのサブフォームがある―――つは共有ＤＳＭリージョンにあるオブジェクトの表現で、他方はオブジェクト格納データベースにディスク上で保存される、あるオブジェクトの表現である。ＤＶＯシステム６０７はこれらの共有と非共有実装の間でオブジェクトを転送するメソッドを提供する。

様々なＤＶＯタイプを表２に示す。

ＤＶＯシステム６０７は、物理ストレージとプロセスの局在問題からＤＶＯの上位レベルを隔離する。ＤＶＯシステム・オブジェクトはＤＳＭを使用してホーム・プロセスへ／からの要求を起動し処理する。要求にはデータベースを開く、閉じる、消去する、データベース内でドキュメントを検索する、データベース・ドキュメントを開く、閉じる、消去する、書き込むなどの動作を含む。マスター・プロセス６００のＤＶＯシステム６０７はストレージ・サービス６０９からＤＶＯオブジェクトを取り出すこともできる。ストレージ・サービス、例えばサービス６０９などは永久媒体から情報を保存したり取り出すユーティリティ・プログラムで、コンテナ、データベース、又はファイルの物理的完全性について責任を担っている。全ての更新が永続的であり全ての内部データ構造（例えばリダイレクト・テーブル、空間割り当てマップ）が常にディスク上で一貫していることを保証する。他のプロセス、例えばプロセス６０２は直接ストレージ・サービス６０９にアクセスできないが、ＤＳＭリージョン６２４経由で間接的にシステムへアクセスできる。

ストレージ・マネージャ６０５は他の種類の物理ストレージ・システムで動作でき、これには、コンテナやオブジェクト・ストア、ストリーム・ファイルシステムとＺＩＰファイルを含む。アトム的なコミットを実現するため、オブジェクト・ストア・ストレージ・サービスはページ指向の入出力動作とピンポン・シャドー頁・テーブルを用いて実装できる。

個別のストレージ・マネージャ・メソッドはアトム的である。複数のストレージ・マネージャ動作は、異なるドキュメントに対する動作であっても、「トランザクション」にグループ化される。トランザクションはＸＭＬデータの完全性を保護する以外にも、ストレージ・マネージャがリージョンロック動作の個数を減少できるようにしたり、メッセージ受け渡しシステム上でのデータ移動量を減少できるようにするため性能を改善する。

ストレージ・マネージャは、上記で参照したＤＳＭ文書に記載されているＤＳＭ同期プリミティブの上に構築された、読み書き可能及び読み取り専用トランザクションの両方をサポートし、このプリミティブは、多数のプロセス又はコンピュータでの一貫性を保証する。読み書き可能なトランザクションは、データベース読み取りと書き込み動作のセットのアトム性と一貫性を提供する。トランザクションの一部として変更される各リージョンは、トランザクションがコミットされるか中断されるまで「ロック」状態に保持される。これによりトランザクションの一部を構成しない動作で変更されないようにする。更に、各トランザクションは、変更するリージョンの「以前のイメージ」を格納しておき、トランザクションが中断された場合（明示的なＡＰＩコール又は例外の結果として）、トランザクションの影響を取消しできるようにする。性能要求によっては、他の実装で完全な「以前のイメージ」を保存するのではなく、取り消し情報を書き込むことができる。読み取り専用トランザクションは、読み取り書き込みトランザクションと同じインタフェースを使用する。読み取り専用トランザクションは多数の読み取り動作が一貫することを保証する。他のトランザクションと同様に、ＤＳＭ関数を使って全ての読み取りリージョンを終了まで「読み取り中状態」に保持する。

更に、チェックポイントを使って変更が永続的であることを確認し、ストレージ・マネージャ動作の耐久性を提供できる。チェックポイントは何時でも実行できる。チェックポイントはデータ復旧ロギングと組み合わせて使用する。全ての動作がコミット時にシーケンシャルな復旧ログファイルへ「やり直し」情報を書き込む。チェックポイントがコミットされると、復旧ログファイルが永続的ストレージへフラッシュされて動作が復旧できることを保証する。トランザクションはコミットされるまで「やり直し」情報を書き込まないので、チェックポイント動作がトランザクションの半ばで開始されると、トランザクション動作はフラッシュされない。

トランザクションは、スレッドとデータベースに範囲が限定される。トランザクションが特定データベースのスレッドで開始されると、そのトランザクションはそのデータベースとスレッドで後続の全てのストレージ・マネージャ動作に自動的に使用される。従来のオペレーティング・システム・スレッドの拡張を使用し、トランザクションが他のスレッド、例えばユーザ・インタフェース・スレッドに整理される必要があるコールを、Ｇｒｏｏｖｅシステムの、簡単なｍａｒｓｈａｌｅｒを使って、正しく処理できるようにする。トランザクションを開始しないスレッドとデータベースに対して行なわれたストレージ・マネージャのコールは、ストレージ・マネージャにコール終了の直前にコミットされる「デフォルト・トランザクション」を作成させる。これ以外に、すでに既存のトランザクションが進行中のスレッドとデータベースに対する新しいトランザクションを開始することで、この新規トランザクションが自動的に既存のトランザクションに「入れ子」にされる。入れ子トランザクションは、外側のトランザクション内にシステムをロールバックする能力を提供する。更に詳しくは、内側の入れ子になったトランザクションは一番外側のトランザクションがコミットされるまで最終的にコミットされない。例えば、入れ子トランザクションがコミットされる場合でこれを内包するトランザクションが後に中止されると、入れ子になったトランザクションも中断される。

本発明の好適な実施態様において、ストレージ・マネージャはオブジェクト指向環境で実装される。従って、ストレージ・マネージャそれ自体と、ドキュメントコンポーネント全部、例えばドキュメント、要素、エンティティ（実体）などがオブジェクトとして実装される。これらのオブジェクト、そのインタフェース、基盤となる構造とストレージ・マネージャとのインタフェースに使用されるＡＰＩが図８に示してある。ＡＰＩは図９から図１１との関連で更に詳細に説明する。図８を参照すると、ストレージ・マネージャはドキュメント操作ＡＰＩ８０２経由でドキュメントへの共有アクセスを開始するが、クライアント・アプリケーションの完全なプログラミング・モデルを有効にするため、ドキュメントのコンテキスト内で追加の通信及び同期動作が提供される。例えば、ストレージ・マネージャは待ち行列要素の動作を提供し、これにより一つのプロセスがＱｕｅｕｅＡＰＩ８０４経由で他のプロセスへ要素を送信できるようにする。要素は値（要素全体のコピー）又は要素への参照により送信できる。同期動作も１つ以上のスレッドに任意の待ち行列へ入れる要素を待機させるために提供される。ストレージ・マネージャは、またＲＰＣＡＰＩ８０４経由でＲＰＣスタイルの要素通信及び同期を提供する。

他のクライアント・コンポーネントは、いつドキュメントがストレージ・マネージャに作成されたか、又は削除されたかを注意する必要がある。そのため、ストレージ・マネージャは通知ＡＰＩ８００経由でこれらのクライアント・コンポーネントに対して重要性に基づく通知システムへのインタフェースを提供する。通知システム８０６はドキュメントが作成又は削除された時の重要性を登録したクライアント・コンポーネントへ通知を提供する。

ドキュメント・データは、データベースオブジェクト、ドキュメントオブジェクト、要素オブジェクト、スキーマオブジェクト８０８を含むオブジェクト集合により表現される。オブジェクトはドキュメント操作ＡＰＩ８０２経由で直接操作される。

ドキュメント関連オブジェクト８０８は、上記で詳細に説明した分散仮想オブジェクト・システム８１０により実際に実装される。分散仮想オブジェクト・システム８１０はまた要素キューとＲＰＣオブジェクト８１２により、キュー及びＲＰＣＡＰＩ８０４の制御下に操作することもできる。

分散仮想オブジェクト・システム８１０は、インタフェース８１４経由で分散共有メモリと通信し、インタフェース８１６経由でロギング動作と通信する。同様に、分散仮想オブジェクト・システムは、インタフェース８１８経由でストレージ・サービスと相互作用できる。

以下は、本発明のストレージ・マネージャの好適な実施態様を実装するために使用されるオブジェクトの各々についてのインタフェースの説明である。これらのオブジェクトはワシントン州レドモンドのマイクロソフト社から配布されているコモン・オブジェクト・モデル（ＣＯＭ）に準拠して設計されており、ＣＯＭオブジェクトとしてメモリ内で操作できる。しかし、ＣＯＭは一つのオブジェクト・モデルと一組のインタフェース方法論に過ぎない。本発明は他のスタイルのインタフェースやオブジェクト・モデルを使って実装することもでき、これにはＪａｖａ（登録商標）やＣＯＲＢＡ オブジェクト・モデルも含みこれに限定されない。

図９はストレージ・マネージャ・オブジェクトへのオブジェクトインタフェースを示す。インタフェース９００（ＩＧｒｏｏｖｅＳｔｏｒａｇｅＭａｎａｇｅｒ）はストレージ・マネージャ用の基本的枠組を内包する。このインタフェースはＣＯＭモデルによって定義された共通クラスであるＩＤｉｓｐａｔｃｈインタフェースのサブクラスである。表３はストレージ・マネージャ・インタフェースに含まれるメソッドの定義である。

他のインタフェース９０２（ＩＧｒｏｏｖｅＳｔｏｒａｇｅＵＲＩＳｙｎｔａｘ）は、統一資源識別子（ＵＲＩ）の形になっている標準名の一部について演算を実行する必要があるストレージ・マネージャのクライアントが使用する。表４はＩＧｒｏｏｖｅＳｔｏｒａｇｅＵＲＩＳｙｎｔａｘインタフェース用のメソッドを含む。

図１０は通知システムインタフェースを示す。インタフェース１０００（ＩＧｒｏｏｖｅＬｉｎｋＣａｌｌｂａｃｋ）はＸＭＬドキュメント又は要素の入力処理中にリンクへの定義が見付かった場合通知される必要のあるストレージ・マネージャのクライアントで使用するインタフェースである。インタフェースは表５に定義されているメソッドを含む。

他のインタフェース１００２（ＩＧｒｏｏｖｅＲＰＣＳｅｒＶｅｒＣａｌｌｂａｃｋ）は、ＸＭＬドキュメント内の要素についてリモート・プロシージャ・コール（ＲＰＣ）を扱う必要があるストレージ・マネージャのクライアントで使用される。ＲＰＣサーバのコールバックは「ｕｔｉｌ」ベースクラスのサブクラスである（後述する）。つまり、ＩＧｒｏｏｖｅＥｌｅｍｅｎｔＵｔｉｌＢａｓｅのメソッド全部もＩＧｒｏｏｖｅＲＰＣＳｅｒｖｅｒＣａｌｌｂａｃｋに適用される。表６はストレージ・マネージャＲＰＣサーバ・コールバック・インタフェースで使用されるメソッドを定義したものである。

図１１、図１２、図１３はドキュメント操作インタフェース、待ち行列、ＲＰＣインタフェースを示す。更に詳しくは、図１１にはデータベースを操作するために使用するインタフェースを示す。インタフェース１１００（ＩＧｒｏｏｖｅＤａｔａｂａｓｅ）はドキュメントを格納するデータベースを管理する必要があるストレージ・マネージャのクライアントによって使用される。これは表７のメソッドを含む。

表８はプロセス間のアクセスを同期する必要があるストレージ・マネージャのクライアント用インタフェース１１０２（ＩＧｒｏｏｖｅＣｒｏｓｓＰｒｏｃｅｓｓＳｅｍａｐｈｏｒｅ）のメソッドを示す。

表９は、データベース内での動作をグループ化する必要があるストレージ・マネージャクライアント用のインタフェース１１０４（ＩＧｒｏｏｖｅＴｒａｎｓａｃｔｉｏｎ）を示す。トランザクションはプロセス間セマフォのサブクラス、つまりＩＧｒｏｏｖｅＣｒｏｓｓＰｒｏｃｅｓｓＳｅｍａｐｈｏｒｅのメソッドの全てにもＩＧｒｏｏｖｅＴｒａｎｓａｃｔｉｏｎが適用される。ストレージ・マネージャトランザクションインタフェースは次のようなメソッドを含む。

図１２は、ストレージ・マネージャのクライアントが、ドキュメントとこれらのドキュメント内の要素を操作できるようにするインタフェースを示す。表１０には、データベース内のドキュメントを管理する必要があるストレージ・マネージャのクライアント用インタフェース１２００（ＩＧｒｏｏｖｅＤｏｃｕｍｅｎｔ）を示す。ストレージ・マネージャ・ドキュメント・インタフェースは次のようなメソッドを含む。

表１１は、データベース内のＸＭＬドキュメントを管理する必要があるストレージ・マネージャのクライアント用インタフェース１２０２（ＩＧｒｏｏｖｅＸＭＬＤｏｃｕｍｅｎｐ）を示す。ＸＭＬドキュメントは、ドキュメントのサブクラス、つまりＩＧｒｏｏｖｅＤｏｃｕｍｅｎｔのメソッドの全部がＩＧｒｏｏｖｅＸＭＬＤｏｃｕｍｅｎｔにも適用される。ストレージ・マネージャＸＭＬドキュメント・インタフェースは次のようなメソッドを含む。

表１２はデータベース内でバイナリ・ドキュメントを管理する必要があるストレージ・マネージャのクライアント用インタフェース１２０４（ＩＧｒｏｏｖｅＢｉｎａｒｙＤｏｃｕｍｅｎｔ）のメソッドを示す。バイナリ・ドキュメントはドキュメントのサブクラス、つまりＩＧｒｏｏｖｅＤｏｃｕｍｅｎｔのメソッドの全部もまたＩＧｒｏｏｖｅＢｉｎａｒｙＤｏｃｕｍｅｎｔに適用される。

表１３はＸＳＬＴと呼ばれる仕様に定義されている、ロケータ・クエリを使用して要素を検索する必要があるストレージ・マネージャのクライアント用インタフェース１２０６（ＩＧｒｏｏｖｅＬｏｃａｔｏｒ）を示す。ＸＳＬＴ仕様の詳細はｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｘｓｌｔにある。ストレージ・マネージャのロケータ・インタフェースは次のようなメソッドを含む。

表１４は、ＸＳＬＴに定義されているＸＭＬドキュメント変換を実行する必要があるストレージ・マネージャのクライアント用インタフェース１２０８（ＩＧｒｏｏｖｅＴｒａｎｓｆｏｒｍ）を示す。ストレージ・マネージャ変換インタフェースは次のようなメソッドを含む。

表１５は、ストレージ・マネージャクライアントがＸＭＬドキュメント内の要素を操作できるようにするインタフェース１２１０（ＩＧｒｏｏｖｅＥｌｅｍｅｎｔ）を示す。ストレージ・マネージャの要素インタフェースは次のようなメソッドを含む。

表１６は、ＸＭＬドキュメント内の読み取り専用要素を操作する必要があるストレージ・マネージャのクライアント用インタフェース１２１２（ＩＧｒｏｏｖｅＲｅａｄＯｎｌｙＥｌｅｍｅｎｔ）のメソッドを示してある。読み取り専用要素は要素のサブクラス、すなわちＩＧｒｏｏｖｅＥｌｅｍｅｎｔのメソッドの全部がＩＧｒｏｏｖｅＲｅａｄＯｎｌｙＥｌｅｍｅｎｔにも適用される。

表１７は、ＸＭＬドキュメント内の要素参照を操作する必要があるストレージ・マネージャのクライアント用インタフェース１２１４（ＩＧｒｏｏｖｅＥｌｅｍｅｎｔＲｅｆｅｒｅｎｃｅ）を示したものである。ストレージ・マネージャの要素参照インタフェースは次のようなメソッドを含む。

ストレージ・マネージャの他のインタフェース内で使用するインタフェース１２１６（ＩＧｒｏｏｖｅＥｌｅｍｅｎｔＵｔｉｌＢａｓｅ）を、表１８に示す。ＩＧｒｏｏｖｅＥｌｅｍｅｎｔＵｔｉｌＢａｓｅは、一般に使用されるオブジェクトのためのインタフェースではないが、共通に使用されるオブジェクトを持っている他のサブクラスについてのベースクラスとして用いることを想定している。”ｕｔｉｌ”インタフェースの全てが要素に関連する。ストレージ・マネージャ要素ｕｔｉｌベースインタフェースは次のようなメソッドを含む。

表１９は、ＸＭＬドキュメント内の要素に関連付けられた実行可能コードを処理する必要があるストレージ・マネージャクライアント用インタフェース１２１８（ＩＧｒｏｏｖｅＢｏｕｎｄＣｏｄｅ）を示す。ストレージ・マネージャ・バインドコード・インタフェースは次のようなメソッドを含む。

図１３は、前述のＩＧｒｏｏｖｅＥｌｅｍｅｎｔＵｔｉｌＢａｓｅベースクラス１３００のサブクラスであるインタフェースを示している。表２０には、ＸＭＬドキュメント内の要素に対するキューを操作する必要があるストレージ・マネージャのクライアント用インタフェース１３０２（ＩＧｒｏｏｖｅＥｌｅｍｅｎｔＱｕｅｕｅ）を示す。要素キューは”ｕｔｉｌ”ベースクラスのサブクラス、すなわちＩＧｒｏｏｖｅＥｌｅｍｅｎｔＵｔｉｌＢａｓｅのメソッド全部がＩＧｒｏｏｖｅＥｌｅｍｅｎｔＱｕｅｕｅにも適用される。ストレージ・マネージャ要素キューインタフェースは次のようなメソッドを含む。

表２１は、ＸＭＬドキュメント内部の要素参照に対するキューを操作する必要があるストレージ・マネージャのクライアント用インタフェース１３０６（ＩＧｒｏｏｖｅＥｌｅｍｅｎｔＲｅｆｅｒｅｎｃｅＱｕｅｕｅ）を示す。要素参照キューは”ｕｔｉｌ”ベースクラスのサブクラス、すなわちＩＧｒｏｏｖｅＥｌｅｍｅｎｔＵｔｉｌＢａｓｅのメソッド全部がＩＧｒｏｏｖｅＥｌｅｍｅｎｔＲｅｆｅｒｅｎｃｅＱｕｅｕｅにも適用される。ストレージ・マネージャ要素キュー参照インタフェースは次のようなメソッドを含む。

表２２は、ＸＭＬドキュメント内の要素に対するマルチリーダー／キューから要素を除去する必要があるストレージ・マネージャのクライアント用インタフェース１３１０（ＩＧｒｏｏｖｅＭｕｌｔｉＲｅａｄｅｒＥｌｅｍｅｎｔＱｕｅｕｅＲｅａｄｅｒ）を示す。マルチリーダー要素キューは”ｕｔｉｌ”ベースクラスのサブクラス、すなわちＩＧｒｏｏｖｅＥｌｅｍｅｎｔＵｔｉｌＢａｓｅのメソッド全部がＩＧｒｏｏｖｅＭｕｌｔｉＲｅａｄｅｒＥｌｅｍｅｎｔＱｕｅｕｅＲｅａｄｅｒにも適用される。ストレージ・マネージャ・マルチリーダー要素キュー・リーダーインタフェースは次のようなメソッドを含む。

表２３は、ＸＭＬドキュメント内の要素についてマルチリーダー・キューへ要素を追加する必要があるストレージ・マネージャのクライアント用インタフェース１３１４（ＩＧｒｏｏｖｅＭｕｌｔｉＲｅａｄｅｒＥｌｅｍｅｎｔＱｕｅｕｅＷｒｉｔｅｒ）を示す。マルチリーダー要素キューは”ｕｔｉｌ”ベースクラスのサブクラス、すなわちＩＧｒｏｏｖｅＥｌｅｍｅｎｔＵｔｉｌＢａｓｅのメソッド全部がＩＧｒｏｏｖｅＭｕｌｔｉＲｅａｄｅｒＥｌｅｍｅｎｔＱｕｅｕｅＷｒｉｔｅｒにも適用される。ストレージ・マネージャ・マルチリーダー要素キュー・ライター・インタフェースは次のようなメソッドを含む。

表２４は、ＸＭＬドキュメント内の要素についてマルチリーダー・キューへの要素参照を追加する必要があるストレージ・マネージャのクライアント用インタフェース１３１８（ＩＧｒｏｏｖｅＭｕｌｔｉＲｅａｄｅｒＥｌｅｍｅｎｔＲｅｆｅｒｅｎｃｅＱｕｅｕｅＷｒｉｔｅｒ）を示す。マルチリーダー要素参照キューは”ｕｔｉｌ”ベースクラスのサブクラス、すなわちＩＧｒｏｏｖｅＥｌｅｍｅｎｔＵｔｉｌＢａｓｅのメソッド全部がＩＧｒｏｏｖｅＭｕｌｔｉＲｅａｄｅｒＥｌｅｍｅｎｔＲｅｆｅｒｅｎｃｅＱｕｅｕｅＷｒｉｔｅｒにも適用される。ストレージ・マネージャ・マルチリーダー要素参照キューライター・インタフェースは次のようなメソッドを含む。

表２５は、ＸＭＬドキュメント内の要素についてマルチリーダー・キューから要素参照を除去する必要があるストレージ・マネージャのクライアント用インタフェース１３１６（ＩｇｒｏｏｖｅＭｕｌｔｉＲｅａｄｅｒＥｌｅｍｅｎｔＲｅｆｅｒｅｎｃｅＱｕｅｕｅＲｅａｄｅｒ）を示す。マルチリーダー要素参照キューは”ｕｔｉｌ”ベースクラスのサブクラス、すなわちＩＧｒｏｏｖｅＥｌｅｍｅｎｔＵｔｉｌＢａｓｅのメソッド全部がＩＧｒｏｏｖｅＭｕｌｔｉＲｅａｄｅｒＥｌｅｍｅｎｔＲｅｆｅｒｅｎｃｅＱｕｅｕｅＲｅａｄｅｒにも適用される。ストレージ・マネージャ・マルチリーダー要素参照キューリーダー・インタフェースは次のようなメソッドを含む。

表２６は、ＸＭＬドキュメント内の要素についてリモート・プロシージャ・コール（ＲＰＣ）を実行する必要があるストレージ・マネージャのクライアント用インタフェース１３０４（ＩＧｒｏｏｖｅＲＰＣＣｌｉｅｎｔ）を示す。ＲＰＣクライアントは”ｕｔｉｌ”ベースクラスのサブクラス、すなわちＩＧｒｏｏｖｅＥｌｅｍｅｎｔＵｔｉｌＢａｓｅのメソッド全部がＩＧｒｏｏｖｅＲＰＣＣｌｉｅｎｔにも適用される。ストレージ・マネージャＲＰＣクライアント・インタフェースは次のようなメソッドを含む。

ＸＭＬドキュメント内の要素についてリモート・プロシージャ・コール（ＲＰＣ）を処理する必要があるストレージ・マネージャのクライアント用インタフェース１３０８（ＩＧｒｏｏｖｅＲＰＣＳｅｒｖｅｒＴｈｒｅａｄ）を、表２７に示す。ＲＰＣサーバ・スレッドは”ｕｔｉｌ”ベースクラスのサブクラス、すなわちＩＧｒｏｏｖｅＥｌｅｍｅｎｔＵｔｉｌＢａｓｅのメソッド全部がＩＧｒｏｏｖｅＲＰＣＳｅｒｖｅｒＴｈｒｅａｄにも適用される。ストレージ・マネージャＲＰＣ サーバ・コールバック・インタフェースは、それ自体のメソッドを持っておらず、ＩＧｒｏｏｖｅＥｌｅｍｅｎｔＵｔｉｌＢａｓｅから継承したメソッドのみである。タイプをチェックするための独立したインタフェースとして提供される。

表２８は、ＸＭＬドキュメント内の要素についてリモート・プロシージャ・コール（ＲＰＣ）を処理する必要があるストレージ・マネージャのクライアント用インタフェース１３１２（ＩＧｒｏｏｖｅＲＰＣＳｅｒｖｅｒ）を示す。ＲＰＣサーバは”ｕｔｉｌ”ベースクラスのサブクラス、すなわちＩＧｒｏｏｖｅＥｌｅｍｅｎｔＵｔｉｌＢａｓｅのメソッド全部がＩＧｒｏｏｖｅＲＰＣＳｅｒｖｅｒにも適用される。ストレージ・マネージャＲＰＣサーバ・インタフェースは次のようなメソッドを含む。

以下の表は、上記インタフェースにリストアップした列挙データタイプについて許容される値を示したものである。とくに、表２９はＧｒｏｏｖｅＳｅｒｉａｌｉｚｅＴｙｐｅに列挙したデータタイプで許容される値を示す。

表３０は、ＧｒｏｏｖｅＳｅｒｉａｌｉｚｅＯｐｔｉｏｎｓで列挙したデータタイプで許容される値を示す。

表３１は、ＧｒｏｏｖｅＰａｒｓｅＯｐｔｉｏｎｓに列挙したデータタイプで許容される値を示す。

表３２は、ＧｒｏｏｖｅＣｏｎｔｅｎｔＴｙｐｅで列挙したデータタイプで許容される値を示す。

表３３は、ＧｒｏｏｖｅＸＬｉｎｋＳｈｏｗで列挙したデータタイプに許容される値である。

表３４は、ＧｒｏｏｖｅＸＬｉｎｋＡｃｔｕａｔｅで列挙したデータタイプに許容される値である。

表３５は、ＧｒｏｏｖｅＸＬｉｎｋＳｅｒｉａｌｉｚｅで列挙したデータタイプに許容される値である。

表３６は、ＧｒｏｏｖｅＭｕｌｔｉＲｅａｄｅｒＱｕｅｕｅＯｐｔｉｏｎｓで列挙したデータタイプに許容される値である。

ストレージ・マネージャの基本的データ・モデルはＸＭＬである。ＸＭＬは半構造型、階層型、ハイパーリンク型データ・モデルである。多くの実世界の問題はこのような複雑な構造で良く表現されず、タブ型フォームでよりよく表現される。例えば、スプレッドシートやリレーショナル・データベースは単純なタブ型インタフェースを提供する。本発明の１つの態様では、表現を簡単にするため、ＸＭＬ構造は一般に「ワッフル」と呼ばれるタブ型ディスプレイにマッピングされる。ワッフルはデータの集合を表現する。このマッピングはストレージ・マネージャのコンポーネントである集合マネージャにより実行される。

集合は集合記述子により定義され、記述子はＸＭＬドキュメントタイプの記述である。ドキュメント・スキーマと同様に、集合記述子は特殊なドキュメントで、集合データそれ自体とは別に保存される。集合データのソースは多く存在するが、集合データの主なソースはレコード・セット・エンジンと呼ばれるソフトウェア・ルーチンである。ユーザのコマンドにより駆動されて、レコード・セット・エンジンは集合の更新の組を集合マネージャへ伝播する。これらの更新に基づいて、集合マネージャはインデックス構造を更新し、通知システムを介してワッフル・ユーザに通知する。ワッフル・ユーザが更新された、あるいは新規の集合データを必要とする場合、ワッフル・ユーザは、集合マネージャを呼び出して更新データを含む新しい結果配列を返してもらう。ワッフル・ユーザはカーソルを使って集合内を移動することもできる。

以下のリストは集合記述子ドキュメントのＸＭＬＤＴＤコンテンツを示す。

<!ELEMENT Collection ANY>
<!ATTLIST Collection
Name CDATA #REQUIRED
Start (record｜index) "record" #REQUIRED
Version CDATA #REQUIRED
Location CDATA #IMPLIED
>
<!ELEMENT Level (Column|Sorting|Level)*>
<!ATTLIST Level
Mapping (Flatten|Direct)
Links (Embed|Traverse) "Traverse"
>
<!ELEMENT Column EMPTY>
<!ATTLIST Column
Source CDATA #REQUIRED
Output CDATA #REQUIRED
MultiValue (OnlyFirst|MultiLine|Concatenate)" OnlyFirst"
MultiValueSeparator CDATA #IMPLIED","
>
<!ELEMENT Sorting SortDescription+>
<!ELEMENT SortDescription Group?|SortColumn+|lnterval?>
<!ATTLIST SortDescription
Naｍe CDATA #REQUIRED
>
<!ELEMENT SortColumn EMPTY>
<!ATTLIST SortColumn
Source CDATA #REQUIRED
Order (Ascending|Descending) #REQUIRED
DataType CDATA #REQUIRED
Strength (Primary|Secondary|Tertiary|Identical) "Identical"
Decomposition (None|Canonical|Full) "None"
>
<!ELEMENT Group Group?|GroupColumn+>
<!ATTILIST Group
Grouping (Unique|Units) #REQUIRED
GroupUnits (Years|Months|Days|Hours)
AtGroupBreak (None|Count|Total) "None"
Order (Ascending|Descending) #REQUIRED
Strength (Primary|Secondary|Tertiary|Identical) "Identical"
Decomposition (None|Canonical|Full) "None"
>
<!ELEMENT GroupColumn EMPTY>
<!ATTLIST GroupColumn
Source CDATA #REQUIRED
>
<!ELEMENT Interval EMPTY>
<!ATTLIST Interval
Start CDATA #REQUIRED
End CDATA #REQUIRED
>

全ての集合Ｃｏｌｌｅｃｔｉｏｎは、集合を参照するのに使用する名前を持っている。Ｓｔａｒｔ属性は集合の「ルート（ｒｏｏｔ）」をどのように発見するかを指定する。レコード・ルートのある集合は、丁度一組のレコードで、一方インデックスで始まる集合はインデックス、更にレコードの組を経由して移動される。インデックスは一致（ｃｏｎｃｏｎｒｄａｎｃｅ）又は完全にテキストである。オプションのＬｏｃａｔｉｏｎ属性はルートのどこで実際に開始するかを識別する相対ＵＲＬである。

レベル（Ｌｅｖｅｌ）は出力階層の一部のコンテンツを定義する。あるレベルはそのレベルのカラム、そのレベルにあるレコードの順序又はグループ化、サブレベルの定義で構成される。レベルはマッピング（Ｍａｐｐｉｎｇ）属性を介してソース・レコード・ストリームのレコードに関連付けられる。マッピングがダイレクト（Ｄｉｒｅｃｔ）の場合には、レベルは一つのソースレコード・タイプを表わす。マッピングが水平（Ｆｌａｔｔｅｎ）の場合には、レベルはソースレコード・タイプとそのレコードの全ての子孫を含む。水平（Ｆｌａｔｔｅｎ）マッピングは集合内のそのレベルだけ、又は最低レベルにのみ指定される。リンク（Ｌｉｎｋ）属性は、リンク属性のあるレコードをどのように処理するかを指定する。リンクがＴｒａｖｅｒｓｅｄの場合、レコードは独立したレベルとして出力される。リンクがＥｍｂｅｄｄｅｄの場合、ソースレコードの子供レコードはちょうどこれがソースレコードの一部であるかのように見える。

カラム（Ｃｏｌｕｍｎ）は、ソースフィールドと出力配列カラムの間のマッピングを定義する。ソース（Ｓｏｕｒｃｅ）属性は、ソースレコードでのＸＳＬＴパス表現である。結果（Ｒｅｓｕｌｔ）属性は、結果配列のフィールドの名前である。多値（ＭｕｌｔｉＶａｌｕｅ）及び多値セパレータ（ＭｕｌｔｉＶａｌｕｅＳｅｐａｒａｔｏｒ）属性は、多値ソース値が結果にどのように返されるかを定義する。

全ての集合は、少なくとも一つの定義済み順序を持つ必要がある。順序はソート済みｃｏｌｌａｔｉｏｎか、集合関数による多レベルグループ化ができる。

ＳｏｒｔＣｏｌｕｍｎ要素は、ＳｏｒｔＤｅｓｃｒｉｐｔｉｏｎ内の集合特性を定義する。ソース（Ｓｏｕｒｃｅ）属性は、ソートしようとする出力カラムの名前を定義する。順序（Ｏｒｄｅｒ）は、昇順又は降順のどちらかでなければならない。強度（Ｓｔｒｅｎｇｔｈ）と分解（Ｄｅｃｏｍｐｏｓｉｔｉｏｎ）の値は、ユニコード（Ｕｎｉｃｏｄｅ）に定義されているのと同じ意味を持つ入力パラメータである。

２種類のグループ化は、ユニーク値によるものと単位によるものである。集合がユニーク値によりグループ化された場合、同じＧｒｏｕｐＣｏｌｕｍｎ値の全部のレコードが同じグループに統合される──グループ間の境界はＧｒｏｕｐＣｏｌｕｍｎ値の変化で起こる。集合が単位でグループ化される場合、同じＧｒｏｕｐＣｏｌｕｍｎ値を持つ全てのレコードは、ＧｒｏｕｐＵｎｉｔｓの値で解決され、同じグループに一緒にされる。例えば、ＧｒｏｕｐＵｎｉｔｓが”Ｄａｙｓ”の場合、任意の日（ｄａｙ）についての全レコードが同じグループになる。ＡｔＧｒｏｕｐＢｒｅａｋが指定された場合、各々の値又は単位区切り（ｕｎｉｔ ｂｒａｋｅ）の値で集合関数の結果を含む合成された行が返される。

ＧｒｏｕｐＣｏｌｕｍｎは、グループ化しようとする結果カラムを識別する。

インターバル（Ｉｎｔｅｒｖａｌ）は、範囲を定義する各レコードの二つのフィールドを識別する。開始（Ｓｔａｒｔ）と終了（Ｅｎｄ）のデータタイプは数値か日時のどちらかでなければならない。

以下の例は６つのソート順序で簡単な文書説明レコード・ビューについての集合記述子文書を示したものである。

<Collection Name="Main" Start="Record" Version="0,1,0,0">
<Level Mapping="Flatten">
<Column Source="Title" Output="Title"/>
<Column Source="_Modified" Output="_Modified"/>
<Column Source="_Created By" Output="_CreatedBy"/>
<Sorting>
<SortDescription Name="ByAscModified">
<SortColumn Source="_Modified" Order="Ascending"
DataType="DateTime"/>
</SortDescription>
<SortDescription Name="ByDescModified">
<SortColumn Source="_Modified"
Order="Descending' DataType="DateTime"/>
</SortDescription>
<SortDescription Name="ByAscAuthor">
<SortColumn Source="_CreatedBy"
Order="Ascending" DataType="String"/>
</SortDescription>
<SortDescription Name='ByDescAuthor">
<SortColumn Source="_CreatedBy"
Order="Descending" DataType="String"/>
</SortDescription>
<SortDescription Name="ByAscTitle">
<SortColumn Source="Title" Order="Ascending"
DataType="String"/>
</SortDescription>
<SortDescription Name="ByOrdinal">
<SortColumn Source="" Order="Ordinal"
DataType="Long"/>
</SortDescription>
</Sorting>
</Level>
</Collection>

以下の例は、カレンダー・ビューの集合記述子を示す。上の例と同様だが、ソート記述に多少の変化があり、集合は日付間隔の範囲で順序付けられることに注意する。

<Collection Name="Main" Start="Record" Version="0,1,0,0">
<Level Mapping="Flatten">
<Column Source="from-attributes(Subject)"
Output="Subject"/>
<Column Source="from-attributes(Start)"
output="Start"/>
<Column Source="from-attributes(End)"
Output="End"/>
<Column Source="from-attributes(RecurrenceEnd)"
Output="RecurrenceEnd"/>
<Column Source="from-attributes(IsAllDay)"
Output="IsAllDay"/>
<Column Source="from-attributes(IsRecurrent)"
Output="IsRecurrent"/>
<Sorting>
<SortDescription Name="DateRanges">
<Interval Start="Start" End="End"/>
</SortDescription>
</Sorting>
</Level>
</Collection>

基本的ストレージ・マネージャと同様、集合マネージャは、オブジェクト指向環境で実装される。従って、集合マネージャそれ自体と、集合、ワッフル、カーソル、結果配列、レコードセット・エンジンを含む、集合コンポーネントの全部がオブジェクトとして実装される。これらのオブジェクト、そのインタフェース、基盤となる構造や集合マネージャとのインタフェースに使用されるＡＰＩは図１４に示してある。ＡＰＩは図１５との関連で更に詳細に説明する。図１４を参照すると、集合マネージャは集合操作ＡＰＩ１４０２経由で集合への共有アクセスを提供するが、クライアント・アプリケーションの完全なプログラミング・モデルを有効にするため、集合のコンテクスト内部に追加の通信及び同期動作が提供される。例えば、ユーザはエンジンＡＰＩ１４０４を用いてレコードセット・エンジン１４１２を制御できる。エンジンＡＰＩ１４０４のコマンド制御下で、レコードセット・エンジン１４１２は、すでに説明した分散仮想オブジェクト・システム１４１０へ集合の更新セットを伝播する。これらの更新に基づいて、分散仮想オブジェクト・システム１４１０はインデックスとやその他の構造を更新する。

他のクライアント・コンポーネントは、例えば集合マネージャによって管理されているワッフルなど、コンポーネント内部の変更に注意する必要がある。そのため、集合マネージャはこれらのクライアント・コンポーネントのために重要性に基づく通知システム１４０６へのインタフェース１４００を提供する。通知システム１４０６は集合を表わすオブジェクト内の値１４０８が変化したときの重要度を登録してあるクライアント・コンポーネント・リスナーのために通知を提供する。

集合データは、集合オブジェクト、レコード・オブジェクト、ワッフル・オブジェクト、カーソル・オブジェクト、結果配列オブジェクトを含む、一組のオブジェクト１４０８によって表現される。オブジェクトは、集合操作ＡＰＩ１４０２によって直接操作することが可能である。集合関連オブジェクト１４０８は、実際には、上記で詳細に説明した分散仮想オブジェクト・システム１４１０によって実装される。

図１５と以下の表は、本発明の集合マネージャの好適な実施態様を実装するのに使用されるオブジェクトの各々についてのインタフェースの記述を含む。ストレージ・マネージャの実装と同様に、これらのオブジェクトは、コモン・オブジェクト・モデル（ＣＯＭ）に準拠して設計されているが、他のインタフェースのスタイルやオブジェクト・モデルを使用して実装することも可能である。

表３７は、集合で実行される主要な動作についての基本的枠組み（ｆｒａｍｅｗｏｒｋ）を内包する集合マネージャについてのインタフェース１５００（ＩＧｒｏｏｖｅＣｏｌｌｅｃｔｉｏｎＭａｎａｇｅｒ）を示している。集合マネージャのインタフェースは次のようなメソッドを含む。

表３８は、集合について実行される主な動作についての基本的枠組み（ｆｒａｍｅｗｏｒｋ）を内包する集合のためのインタフェース１５０２（ＩＧｒｏｏｖｅＣｏｌｌｅｃｔｉｏｎ）を示したものである。集合インタフェースは次のようなメソッドを含む。

表３９は、「有意な」イベントが集合内で発生した場合に通知するように希望している集合マネージャのクライアント用インタフェース１５０４（ＩＧｒｏｏｖｅＣｏｌｌｅｃｔｉｏｎＬｉｓｔｅｎｅｒ）を示す。有意なイベントはどの時点でも発生することがあり、更新、追加、削除、親再設定、又は集合要素の順列位置での変更を含む。集合マネージャ・リスナー・インタフェースは次のようなメソッドを含む。

表４０は、集合内のカーソルを移動したい集合マネージャのクライアント用インタフェース１５０６（ＩＧｒｏｏｖｅＣｏｌｌｅｃｔｉｏｎＣｕｒｓｏｒ）を示す。集合はあらゆる時点で１つ以上のカーソルをアクティブにして持つことができる。集合マネージャ・カーソル・インタフェースは次のようなメソッドを含む。

以下の表は、上記のインタフェースにリストした列挙データ・タイプについて許容される値を示したものである。更に詳しくは、表４１ではＧｒｏｏｖｅＣｏｌｌａｔｉｏｎＯｒｄｅｒで列挙されたデータ・タイプで許容される値を示す。

表４２は、ＧｒｏｏｖｅＣｏｌｌｅｃｔｉｏｎＮａｖｉｇａｔｉｏｎＯｐで列挙したデータ・タイプについて許容される値を示す。

表４３は、ＧｒｏｏｖｅＣｏｌｌｅｃｔｉｏｎＣｕｒｓｏｒＰｏｓｉｔｉｏｎ に列挙したデータタイプで許容される値を示す。

表４４は、ＧｒｏｏｖｅＣｏｌｌｅｃｔｉｏｎＲｏｗＴｙｐｅ に列挙したデータタイプで許容される値を示す。

表４５は、ＧｒｏｏｖｅＣｏｌｌｅｃｔｉｏｎＳｙｎｔｈＴｙｐｅで列挙したデータタイプで許容される値を示す。

表４６は、ＧｒｏｏｖｅＣｏｌｌｅｃｔｉｏｎＵｐｄａｔｅＯｐ で列挙したデータタイプに許容きれる値を示す。

表４７は、ＧｒｏｏｖｅＣｏｌｌｅｃｔｉｏｎＷａｆｆｌｅＳｙｓｔｅｍに列挙したデータタイプで許容される値を示す。

表４８は、ＧｒｏｏｖｅＣｏｌｌｅｃｔｉｏｎＲｅｃｏｒｄＩＤに列挙したデータタイプで許容される値を示す。

表４９は、ＧｒｏｏｖｅＳｏｒｔＯｒｄｅｒに列挙したデータタイプで許容される値を示す。

上記の実施態様のソフトウェアによる実装は、例えばコンピュータで読み取り可能な媒体、例えばディスケットや、ＣＤ−ＲＯＭ、ＲＯＭメモリ又は固定ディスクなどの有形媒体上に固定されているか、媒体上でモデムを介してあるいは他のインタフェース装置を介して、コンピュータ・システムへ伝送可能な一連のコンピュータ命令を含む。媒体は、光又はアナログ通信線を含み、これに制限されない有形媒体としたり、赤外線又はその他の伝送技術を含み、これに制限されない無線技術で実装することができる。これはインターネットとすることもできる。一連のコンピュータ命令は、本発明に関して本明細書ですでに説明した機能の全部又は一部を実現する。このようなコンピュータ命令が、多くのコンピュータ・アーキテクチャ、あるいはオペレーティング・システムで使用する多数のプログラミング言語で書けることは、当業者には理解されよう。更に、このような命令は、半導体、磁気、光、又はその他のメモリ装置を含み、これに制限されない現在又は将来の何らかのメモリ技術、を用いて保存したり、又は光、赤外線、マイクロ波、あるいはその他の通信技術を含み、これに制限されない現在又は将来の他の通信技術を用いて伝送することができる。このようなコンピュータ・プログラム製品が、印刷した又は電子化された説明を伴ったリムーバブル媒体、例えばシュリンクラップ・ソフトウェアとして配布される、コンピュータ・システムの、例えばシステムのＲＯＭ又は固定ディスク上にプリロードされる、又は例えばインターネット又はＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）などのネットワーク上のサーバ又は電子掲示板システムから配布されることを想定している。本発明の代表的実施態様を開示したが、本発明の利点の幾つかを実現する様々な変化や変更を本発明の精神と範囲から逸脱することなく成し得ることは、当業者には明らかであろう。例えば、説明は特定のハードウェア・システムとオペレーティング・システムを指向したものだったが、他のハードウェアやオペレーティング・システム・ソフトウェアを説明したのと同じ方法で使用できることは、当業者には自明であろう。特定の関数を実現するために使用される特定の命令などの他の態様や、本発明の概念に対するその他の変更は添付の請求の範囲に含まれることを意図している。

図１は、本発明のストレージ・マネージャ・システムを実行できるコンピュータ・システムの略図である。 図２は、インメモリ・ストレージ・マネージャと永続的ストレージの関連性を示す略ブロック図である。 図３は、オブジェクト集合としてストレージ・マネージャ・メモリ上のＸＭＬドキュメント表現を示す略ブロック図である。 図４Ａは、ＸＭＬ要素にコードを結合する際に関係するコンポーネントを示す略ブロック図である。 図４Ｂは、要素に結合されたプログラム・コードを取り出す際に関係するステップを示すフローチャートである。 図５は、ＸＭＬテキスト・ドキュメントとバイナリ・サブドキュメントとの関連を示す。 図６は、他のプロセスでのストレージ・マネージャの主要な内部パーツを示す略ブロック図である。 図７は、プロセス間のオブジェクトを同期するためのメカニズムを示す。 図８は、ストレージ・マネージャの主要内部パーツを介してストレージ・マネージャＡＰＩからの主制御パスを示す略図である。 図９は、本発明のオブジェクト指向実装により構築されたストレージ・マネージャインタフェースの略図である。 図１０は、ストレージ・マネージャにより定義され、リンクの処理中又は要素ＲＰＣ処理中に呼び出される、本発明のオブジェクト指向実装により構築されたインタフェースの略図である。 図１１は、本発明のオブジェクト指向実装により構築されたデータベース及びトランザクション・インタフェースの略図である。 図１２は、本発明のオブジェクト指向実装により構築されたドキュメント及び要素のインタフェースの略図である。 図１３は、本発明のオブジェクト指向実装により構築された要素通信及び同期インタフェースの略図である。 図１４は、集合の主要な内部パーツとストレージ・マネージャを介した集合マネージャＡＰＩからの主制御パスを示す略図である。 図１５は、本発明のオブジェクト指向実装により構築された集合マネージャ・インタフェースの略図である。

Claims (12)

1. 永続性メモリ内のＸＭＬ準拠ドキュメントを表現管理するための装置であって、前記装置は、処理装置と、ホーム・プロセスである第１のプロセスで実行する第１のアプリケーション・プログラムと、第２のプロセスで実行する第２のアプリケーション・プログラムと、複数のプロセスからオブジェクトに対するアクセスを同期するように適合された分配共有メモリ・システムとを備え、前記ＸＭＬ準拠ドキュメントのコピーが第１の複数の仮想オブジェクトおよび第２の複数の仮想オブジェクトとしてそれぞれ、前記分配共有メモリ・システムの一部を構成する前記第１のプロセスに関連付けられた第１の分散共有メモリ・システムおよび前記第２のプロセスに関連付けられた第２の分散共有メモリ・システムに格納され、
   前記装置は、さらに、
   前記第１のアプリケーションから呼び出されることが可能なメソッドを含む第１のストレージ・マネージャ・インタフェース・プログラムであって、前記第１のプロセスに関連づけられた処理装置が、該メソッドの実行を介して、前記第１の分散共有メモリ・システムに前記第１の複数の仮想オブジェクトとして格納された前記ＸＭＬ準拠ドキュメントのコピー上で読み取り及び／又は書き込み動作を実行し、前記第１の複数の仮想オブジェクトにアクセスする、第１のストレージ・マネージャ・インタフェース・プログラムと、
   前記第２のアプリケーションから呼び出されることが可能なメソッドを含む第２のストレージ・マネージャ・インタフェース・プログラムであって、前記第２のプロセスに関連付けられた処理装置が、該メソッドの実行を介して、前記第２の分散共有メモリ・システムに前記第２の複数の仮想オブジェクトとして格納された前記ＸＭＬ準拠ドキュメントのコピー上で読み取り及び／又は書き込み動作を実行し、前記第２の複数の仮想オブジェクトにアクセスする、第２のストレージ・マネージャ・インタフェース・プログラムと
   を備え、
   前記第１のアプリケーションおよび第２のアプリケーションはそれぞれ、ＸＭＬ準拠ドキュメントのコピー上の読み取り及び／又は書き込み動作を実行することができ、
   前記第１のプロセスに関連づけられた処理装置が前記第１のストレージ・マネージャ・インタフェース・プログラム中のメソッドを実行して、前記第１の分散共有メモリ・システムに前記第１の複数の仮想オブジェクトとして格納された前記ＸＭＬ準拠ドキュメントのコピー上で読み取り及び／又は書き込み動作を実行し、
   前記第２のプロセスは前記装置で提供されるメッセージ通信プロトコルに対するノード間通信インタフェースを有し、前記ノード間通信インタフェースは前記第１のプロセスと第２のプロセスのアドレスを操作するメソッドを含み、前記第２のプロセスに関連付けられた第２の分散共有メモリ・システムが第２の複数の仮想オブジェクトの最新のコピーを保有していない場合、前記第２のプロセスに関連づけられた処理装置が前記ノード間通信インタフェースを介して前記第１のプロセスに関連付けられた第１の分散共有メモリ・システムから第１の複数の仮想オブジェクトのコピーを要求することを特徴とする装置。
   
2. 前記分散共有メモリ・システムは、前記第１の複数の仮想オブジェクトと前記第２の複数の仮想オブジェクトとの間の一貫性を維持することを特徴とする請求項１に記載の装置。
   
3. 前記第１のプロセスは、前記第１のプロセスに関連づけられた処理装置が第１の複数の仮想オブジェクトを変更している場合に、前記第１の分散共有メモリ・システムが第１の複数の仮想オブジェクトをロックすることを要求するメソッドを含むこと、を特徴とする請求項２に記載の装置。
   
4. 前記第２のプロセスは、前記第２のプロセスに関連づけられた処理装置が第２の複数の仮想オブジェクトを変更している場合に、前記第２の分散共有メモリ・システムが第２の複数の仮想オブジェクトをロックすることを要求するメソッドを含むこと、を特徴とする請求項２に記載の装置。
   
5. 前記永続性メモリは、不揮発性記憶を備えることを特徴とする請求項１に記載の装置。
   
6. 前記第１および第２のストレージ・マネージャ・インタフェース・プログラムの双方は、前記第１および第２の複数の仮想オブジェクトを操作するための同等なプログラム・コードを含むこと、を特徴とする請求項１に記載の装置。
   
7. 永続性メモリ内のＸＭＬ準拠ドキュメントを表現管理するための方法であって、前記ＸＭＬ準拠ドキュメントは、第１のアプリケーション・プログラムを実行するためのホーム・プロセスである第１のプロセスに関連づけられた処理装置によって、および第２のアプリケーション・プログラムを実行するための第２のプロセスに関連づけられた処理装置によって更新される、前記方法は、
   （ａ）前記第１のプロセスに関連づけられた処理装置および前記第２のプロセスに関連づけられた処理装置が、前記ＸＭＬ準拠ドキュメントのコピーである第１の複数の仮想オブジェクトおよび第２の複数の仮想オブジェクトをそれぞれ、前記第１のプロセスに関連付けられた第１の分散共有メモリ・システムおよび前記第２のプロセスに関連付けられた第２の分散共有メモリ・システムに格納するステップと、
   （ｂ）前記第１のプロセスに関連づけられた処理装置が、前記第１のアプリケーションから呼び出されることが可能なメソッドを含む第１のストレージ・マネージャ・インタフェース・プログラムを使用するステップであって、前記第１のプロセスに関連づけられた処理装置が、該メソッドの実行を介して、前記第１の分散共有メモリ・システムに格納された前記ＸＭＬ準拠ドキュメントのコピー上で読み取り及び／又は書き込み動作を実行し、前記第１の複数の仮想オブジェクトにアクセスする、ステップと、
   （ｃ）前記第２のプロセスに関連づけられた処理装置が、前記第２のアプリケーションから呼び出されることが可能なメソッドを含む第２のストレージ・マネージャ・インタフェース・プログラムを使用するステップであって、前記第２のプロセスに関連づけられた処理装置が、該メソッドの実行を介して、前記第２のプロセスに関連付けられた第２の分散共有メモリ・システムに格納された前記ＸＭＬ準拠ドキュメントのコピー上で読み取り及び／書き込み動作を実行し、前記第２の複数の仮想オブジェクトにアクセスし、前記第２のプロセスに関連づけられた第２の分散共有メモリ・システムが第２の複数の仮想オブジェクトの最新のコピーを保有していない場合、前記第２にプロセスが有するメッセージ通信プロトコルに対するノード間通信インタフェースを使用して前記第２のプロセスに関連づけられた処理装置が前記第１のプロセスに関連づけられた前記第１の分散共有メモリ・システムから第１の複数の仮想オブジェクトのコピーを要求する、ステップであって、前記ノード間通信インタフェースは前記第１のプロセスと前記第２のプロセスのアドレスを操作するメソッドを有する、ステップと
   を備え、
   前記第１のアプリケーションおよび第２のアプリケーションのそれぞれは、ＸＭＬ準拠ドキュメントのコピー上の読み取り及び／又は書き込み動作を実行することができることを特徴とする方法。
   
8. 前記第１および第２の分散共有メモリ・システムは、前記第１の複数の仮想オブジェクトと前記第２の複数の仮想オブジェクトとの間の一貫性を維持することを特徴とする請求項７に記載の方法。
   
9. 前記ステップ（ｂ）は、前記第１のプロセスに関連づけられた処理装置が第１の複数の仮想オブジェクトを変更している場合に、第１の複数の仮想オブジェクトをロックするステップを含むこと、を特徴とする請求項７に記載の方法。
   
10. 前記ステップ（ｃ）は、前記第２のプロセスに関連づけられた処理装置が第２の複数の仮想オブジェクトを変更している場合に、第２の複数の仮想オブジェクトをロックすることを含むこと、を特徴とする請求項７に記載の方法。
    
11. （ｅ）第１のプロセスの制御下で、不揮発性記憶に前記第１の複数の仮想オブジェクトのコピーを格納するステップを更に備えること、を特徴とする請求項７に記載の方法。
    
12. 永続性メモリ内のＸＭＬ準拠ドキュメントを表現管理するためのコンピュータ・プログラムであって、前記ＸＭＬ準拠ドキュメントは、第１のアプリケーション・プログラムを実行するためのホーム・プロセスである第１のプロセスに関連づけられた処理装置によって、および第２のアプリケーション・プログラムを実行する第２のプロセスに関連付けられた処理装置によって、更新され、前記コンピュータ・プログラムは、
    前記第１のプロセスに関連づけられた処理装置および前記第２のプロセスに関連づけられた処理装置に、前記ＸＭＬ準拠ドキュメントのコピーである第１の複数の仮想オブジェクトおよび第２の複数の仮想オブジェクトをそれぞれ、前記第１のプロセスに関連付けられた第１の分散共有メモリ・システムおよび前記第２のプロセスに関連付けられた第２の分散共有メモリ・システムに格納させ、
    前記第１のプロセスに関連づけられた処理装置に、前記第１のアプリケーションから呼び出されることが可能なメソッドを含む第１のストレージ・マネージャ・インタフェース・プログラム内の該メソッドの実行を介して、前記第１の分散共有メモリ・システムに前記第１の複数の仮想オブジェクトとして格納された前記ＸＭＬ準拠ドキュメントのコピー上で読み取り及び／又は書き込み動作を実行させ、前記第１の複数の仮想オブジェクトにアクセスさせ、
    前記第２のプロセスに関連づけられた処理装置に、前記第２のアプリケーションから呼び出されることが可能なメソッドを含む第２のストレージ・マネージャ・インタフェース内の該メソッドの実行を介して、前記第２の分散共有メモリ・システムに前記第２の複数の仮想オブジェクトとして格納された前記ＸＭＬ準拠ドキュメントのコピー上で読み取り及び／書き込み動作を実行させ、前記第２の複数のオブジェクトにアクセスさせ、前記第２のプロセスに関連づけられた第２の分散共有メモリ・システムが第２の複数の仮想オブジェクトの最新のコピーを保有していない場合、前記第２のプロセスに関連づけられた処理装置に、前記第２にプロセスが有するメッセージ通信プロトコルに対するノード間通信インタフェースであり前記第１のプロセスと前記第２のプロセスのアドレスを操作するメソッドを有するノード間通信インタフェースを使用して、前記第１のプロセスに関連づけられた前記第１の分散共有メモリ・システムから第１の複数の仮想オブジェクトのコピーを要求させ、
    前記第１のアプリケーションおよび第２のアプリケーションのそれぞれは、ＸＭＬ準拠ドキュメントのコピー上の読み取り及び／又は書き込み動作を実行することができることを特徴とするコンピュータ・プログラム。

Images