オンライン文書編集を同期するために少なくとも一部はコンピューティングデバイスによって実行される方法であって、前記方法は、文書の第1のセクションと関連付けられる第1の共同オーサリングメタデータの指示を受信するステップであって、前記第1の共同オーサリングメタデータは、ブラウザベースのクライアントアプリケーションから受信される、受信するステップと、前記文書の第2のセクションと関連付けられる第2の共同オーサリングメタデータの指示を受信するステップであって、前記第2の共同オーサリングメタデータは、第2のクライアントアプリケーションから受信され、前記第2のクライアントアプリケーションは、ブラウザで動作しない、受信するステップと、前記ブラウザベースのクライアントアプリケーションに提供される変換表現に基づいて前記第1の共同オーサリングメタデータを解釈するステップと、前記文書と関連する前記第1の共同オーサリングメタデータおよび前記第2の共同オーサリングメタデータを記憶するステップとを備えたことを特徴とする方法。前記第1の共同オーサリングメタデータは、ユーザ名、ユーザの存在情報、および文書内ロックのセットのうち少なくとも1つを含むことを特徴とする請求項1に記載の方法。コンポーネントレベルの変更された文書において他の編集と衝突する1または複数の編集を認識するステップをさらに備えたことを特徴とする請求項1に記載の方法。前記衝突する編集が結びの句である場合、通知を用いずに、衝突する編集を同一コンポーネント内で統合することを試みるステップをさらに備えたことを特徴とする請求項3に記載の方法。前記文書にアクセスするクライアント間でパラグラフの番号を同期することを確認するための要求を前記クライアントアプリケーションから受信した後、前記文書の各パラグラフを再番号割り当てするステップをさらに備えたことを特徴とする請求項1に記載の方法。前記ユーザが前記文書の単一の共作成者であるかどうかを判定するための要求を、前記文書と関連付けられる共同オーサリングアプリケーションを実行するサーバに送るステップをさらに備えたことを特徴とする請求項1に記載の方法。オンライン文書編集を同期するオンライン文書アプリケーションサーバであって、前記サーバは、メモリと、前記メモリに接続されたプロセッサであって、前記プロセッサは、前記メモリに記憶された命令と共にアプリケーションを実行し、前記アプリケーションは、文書の要求をユーザから受信し、前記文書に対する文書ロックを記憶サーバから要求し、前記文書を前記記憶サーバから読み出し、前記文書を、前記文書のコンテンツを含む複数のコンポーネント、ならびにユーザ名およびユーザの存在情報を含む第1の共同オーサリングメタデータに変換し、少なくとも2人のユーザによる編集間の衝突を判定し、前記複数のコンポーネントに対する複数のコンポーネントロックを、前記衝突する編集を評価することによって判定し、前記文書ロックを解除することによって前記文書ロックを前記複数のコンポーネントロックに調整し、前記複数のコンポーネントロックを、適合するコンポーネントに適用し、前記グラフを表示用のブラウザベースのクライアントアプリケーションに送信するように構成される、プロセッサとを備えたことを特徴とするサーバ。前記衝突を判定した後、前記アプリケーションは、少なくとも1つのユーザ選択に対し、少なくとも1つの衝突するユーザ編集および少なくとも1つの対応するコンポーネントを、前記ブラウザベースのクライアントアプリケーションに送信することであって、前記少なくとも1つの選択は、前記衝突を解消する前記少なくとも1つの対応するコンポーネントに記録されるようにさらに構成されることを特徴とする請求項7に記載のアプリケーションサーバ。前記アプリケーションは、前記複数のコンポーネントロックを、第2の共同オーサリングメタデータとして文書グラフに記憶するようにさらに構成されることを特徴とする請求項7に記載のアプリケーションサーバ。オフラインブラウザベースのクライアントアプリケーションは、オンラインに戻った後、統合するための少なくとも1つのユーザ編集を、前記文書グラフに送信することを特徴とする請求項9に記載のアプリケーションサーバ。前記アプリケーションは、編集時間、ユーザの認証情報、およびユーザの役割のセットのうちの少なくとも1つを、前記ブラウザベースのクライアントアプリケーションに送信するようにさらに構成されることを特徴とする請求項7に記載のアプリケーション。オンライン文書編集を同期するための命令を記憶するコンピュータ可読記憶媒体であって、前記命令は、文書の要求をユーザから受信するステップと、前記文書に対する文書ロックを記憶サーバから要求するステップと、前記文書を前記記憶サーバから読み出すステップと、前記文書を、ユーザ名およびユーザの存在情報を含む第1の共同オーサリングメタデータを含む複数のコンポーネントに送信し、かつ前記複数のコンポーネントをグラフに記憶するステップと、前記複数のコンポーネントに対する複数のコンポーネントロックを、少なくとも1つのユーザ編集を評価することによって判定するステップと、前記文書ロックを解除することによって前記文書ロックを前記複数のコンポーネントロックに調整し、前記複数のコンポーネントロックを、前記グラフ内の適合するコンポーネントに適用し、および前記複数のコンポーネントロックを第2の共同オーサリングメタデータとして前記グラフに記憶するステップと、前記グラフを表示用のブラウザベースのクライアントアプリケーションに送るステップとを備えたことを特徴とするコンピュータ可読記憶媒体。前記命令は、現在のユーザに、前記複数のコンポーネントロックを通知することをさらに備えたことを特徴とする請求項12に記載のコンピュータ可読記憶媒体。前記命令は、コンポーネントレベル識別子を記憶するステップと、前記文書の他の部分が変化しても、前記コンポーネントレベル識別子を使用して、ユーザの編集を、適したコンポーネント領域に移動するステップとをさらに備えたことを特徴とする請求項12に記載のコンピュータ可読記憶媒体。前記命令は、ユーザに、前記文書を編集する現在の作成者の名前および存在情報を通知するステップをさらに備えたことを特徴とする請求項12に記載のコンピュータ可読記憶媒体。上記に簡潔に説明したように、ロックアクションを使用して文書コンポーネントレベルで修正を制御することによってオンライン文書編集を同期できる。文書を文書コンポーネントのグラフに変換できる。複数のユーザによって提出される変更を管理するためにロックをコンポーネント上でアサートできる。各共作成者が編集する文書をコンポーネントレベルで編集することを含めたグラフの修正を維持管理することによってグラフコンポーネントの変更を追跡できる。以下の詳細な説明において、その一部を成す添付図面についての説明が行われ、図解を目的とする実施形態または例によって示される。本開示の精神または範囲から逸脱しない範囲においてこのような態様を組み合わせてもよいし、他の態様を利用してもよいし、構造の変更を行ってもよい。従って、以下の詳細な説明は、限定された意味で解釈されるものではなく、本発明の範囲は、添付の特許請求の範囲およびその等価物によって定義される。実施形態は、コンピューティングデバイスのオペレーティングシステム上で実行するアプリケーションプログラムと共に実行するプログラムモジュールの一般的な状況において説明されるが、態様は、他のプログラムモジュールと共に実装されてもよいことが当業者には認識されよう。一般に、プログラムモジュールは、ルーチン、プログラム、コンポーネント、データ構造、および特定のタスクを実行するまたは特定の抽象データ型を実装する他のタイプの構造を含む。さらに、実施形態は、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラマブルな家電、ミニコンピュータ、メインフレームコンピュータ、および同等のコンピューティングデバイスを含む、他のコンピュータシステム構成で実施されてよいことが当業者には認識されよう。実施形態を、通信ネットワークにリンクされるリモート処理デバイスによってタスクが実行される分散コンピューティング環境で実施できる。分散コンピューティング環境において、プログラムモジュールをローカルメモリ記憶デバイスとリモートメモリ記憶デバイスとの両方に配置することができる。実施形態を、コンピュータ実装プロセス方法、コンピューティングシステムとして、あるいはコンピュータプログラム製品またはコンピュータ可読媒体などの、製造品として実装できる。コンピュータプログラム製品は、コンピュータシステムによって読み取り可能であり、且つコンピュータまたはコンピューティングシステムが例示的プロセス複数を実行するようにさせる命令を備えるコンピュータプログラムを符号化する、コンピュータ記憶媒体であってよい。コンピュータ可読記憶媒体を、例えば、揮発性コンピュータメモリ、不揮発性コンピュータメモリ、ハードドライブ、フラッシュドライブ、フロッピー登録商標ディスク、またはコンパクトディスク、および同等の記憶媒体のうちの1つまたは複数によって実装することができる。この明細書全体を通じて、用語プラットフォームは、実施形態を実装できるさまざまな文書タイプまたは同様の環境に共同オーサリングサービスを提供するソフトウェアコンポーネントとハードウェアコンポーネントとの組み合わせであってよい。プラットフォームの例は、複数のサーバ上で実行されるホストサービス、単一のサーバ上で実行されるアプリケーション、および同等のシステムを含むが、これらに限定されない。用語サーバは、一般に、典型的にはネットワーク化環境において1または複数のソフトウェアプログラムを実行するコンピューティングデバイスを指す。しかしながら、サーバは、ネットワーク上のサーバと見なされる1または複数のコンピューティングデバイス上で実行される仮想サーバソフトウェアプログラムとして実装されてもよい。このような技術および例示的動作について以下により詳細に説明する。図1は、オンライン文書編集サービスの例示的コンポーネントを示す図である。100において、サーバ110は、1または複数のオンライン文書編集アプリケーションを実行し、そしてネットワーク140経由で情報、特に文書コンテンツを送信できる。ネットワーク140は、ローカルネットワークであってよいし、またはインターネットベースのインフラストラクチャなどの、外部エンティティであってよい。そのネットワークは、有線または無線接続性を提供できる。ネットワークノードは、セキュアでないまたはセキュアな接続性を介して互いに接続できる。セキュアな接続性の例として、ネットワークノード間で暗号化された通信を使用して確立される仮想プライベートネットワークVPNがある。サーバ110は、さまざまなプロトコルを介してクライアントと通信する文書編集アプリケーションを提供できる。その一例として、ハイパーテキストトランスポートプロトコルHTTPがある。文書編集アプリケーションは、文書編集サービスをシンクライアントおよびシッククライアントのエンドユーザに提供できる。シンクライアントまたはウェブクライアント131、134は、サーバアプリケーションが提供する機能に依存できる。シッククライアントまたはリッチクライアント137は、サーバアプリケーションが提供する機能とローカル機能とを組み合わせて、エンドユーザに付加的なユーティリティを与えることができる。リッチクライアント137は、同じアプリケーションサーバ110に接続する必要がない。最終的に、すべてのクライアントは、同じ文書を文書サーバ120上で編集する。いくつかの実装に従って、アプリケーションサーバ110は、ウェブ編集能力に適するサーバにすることができ、別のサーバは、リッチクライアント137に適していて且つそれによって使用されるサービスを提供できる。アプリケーションサービスの例は、ユーザ編集とユーザ存在情報およびユーザ名とを統合してクライアントデバイス上でユーザ変更を表示できる。さらに、サーバアプリケーションは、複数のユーザが異なるクライアントデバイス130、133および136を介してサービスにアクセスできるようにする場合がある。例示的シナリオにおいて、ユーザは、文書にアクセスして変更した結果、その同じ文書132、135および138を異なるバージョンにできる。実施形態において、文書サーバ120は、文書記憶サービスであってよい。文書は、テキスト、描画、イメージ、ビデオ、およびオーディオを含む、文書のさまざまなタイプおよびフォーマットを記憶できるが、これらに限定されない。例示的システムにおいて、文書サーバは、アプリケーションサーバによって提供されるオンライン編集アプリケーションを介して複数のユーザによって編集されるテキスト文書を記憶できる。別の例示的システムにおいて、文書サーバは、アプリケーションサーバによって提供されるオンラインイメージ編集アプリケーションを介して複数のユーザによってアクセスおよび編集されるイメージ文書を記憶できる。しかし、他の例において、文書記憶サーバは、ハイブリッド文書タイプのオンラインアプリケーションサービスを介してアクセスおよび編集を同時に行う複数のファイルタイプおよびフォーマットを複数のユーザに提供できる。例示的シナリオにおいて、ユーザは、アプリケーションサーバによって提供される文書アプリケーションを介して編集するために既存の文書にアクセスできる。ユーザ要求の後、アプリケーションサーバは、記憶サーバ内の文書を読み出してロックできる。アプリケーションサーバは、文書を、その文書のコンポーネントをカプセル化するグラフに変換できる。アプリケーションサーバは、そのグラフを修正番号に割り当てることができる。アプリケーションは、ユーザ変更を評価し、そして文書ロックを、変更されたコンポーネントを包含するグラフコンポーネントを隠すコンポーネントロック複数に変えることができる。アプリケーションサーバは、グラフコンポーネントの変更を書き込んで、グラフの修正番号を変更でき、そしてファイルサーバに書き込むことによってそのグラフ変更を同期できる。さらに、オフラインクライアントは、オンラインに戻った後に統合する編集をグラフに送信できる。ユーザが文書を共同オーサリングできるようにさせるアプリケーションサーバは、クライアントからのある通信を予測することができる。その通信は、2種類の要求、即ち、記憶要求およびサーバアクセス要求の形で入ってくる。要求動作を、2つの層を使用して実装できる。第1に、サーバは、各要求に対してシンプルオブジェクトアクセスプロトコルSOAPインタフェースを示すことができる。要求は、その後、その要求にサービスするサーバのフロントエンドのコンポーネントに渡される。別の例示的実施形態において、ウェブブラウザベースのクライアントアプリケーションは、ブラウザで実行するスクリプトベースのコードと、フロントエンドで実行するCコードなどの、実装に特化したコードとの2つの部分から構成され得る。フロントエンドは、要求を受信してサービスできる。その結果、アプリケーションは、ウェブブラウザベースのクライアントが要求できる方法を実装する際のオプションを有することができる。ブラウザで実行するコードは、1サーバ上で示されたSOAPインタフェースに直接要求できるか、または2サーバ上の単一のエントリーポイントに直接すべて要求して、SOAP要求を受信すると、フロントエンドが、そのフロントエンド内から直接要求にサービスできるコンポーネントを呼び出すようにさせることができる。サーバ上の単一のエントリーポイントに直接すべて要求することは、事前処理、事後処理、管理容易性、移植性、および一貫性において有利になり得る。事前処理について、非同期JavaScript登録商標AJAXまたは同様の要求は、サーバによって要求される動作の詳細を包含できるバイナリストリームを包含できる。バイナリストリームの生成は、スクリプト言語では面倒になる恐れがある。さらに、サーバは、より単純な命令からバイナリ要求を生成できるユーティリティにすでにアクセスした可能性がある。事後処理について、生応答をバイナリストリーム以外でブラウザがより解釈しやすいフォーマットに変換するのに望ましい処理もあり得る。その応答は、文書を参照できるデータを包含できる。管理容易性についして、単一のエントリーポイントを利用するので、システムは、フロントエンド上で真の負荷を考慮するためのスロットリングなどの動作を実装できる。アプリケーションは、関連する複数の要求が同時に到達する時、より良い再使用状態にすることもできる。移植性について、ブラウザがさまざまなエンドポイントに発呼するようにさせるので、システムは、他のインプリメンタに実装から実装までのエンドポイント名を保持するように強制することによって、そのインプリメンタに負荷を加えることができる。一貫性について、ブラウザベースの文書編集は、ほとんどの通信を同じエンドポイントに集めることができる。別の実施形態において、記憶要求を使用して、データを記憶または読み出すことができる。このような記憶要求は、基本文書に結合された1または複数のパーティションされたデータセルに要求できる。ウェブブラウザなどのクライアントアプリケーションからサーバのフロントエンドに記憶要求を行うことは、異なる機構を通じて実現できる。しかしながら、文書を共同オーサリングするユーザは、新しい要求をシステムに課すことができる、共同オーサリングに関連するメタデータを記憶して読み出す付加的な要求を要求できる。例において、ウェブブラウザは、ページのコンテンツを読み出す動作を実行できる。ウェブブラウザは、文書に対してウェブブラウザベースのサービスを発呼できる。ウェブブラウザは、どの文書およびどのセルをターゲットにして要求を発行したいかについての情報をインスタンス化し、そしてその応答オブジェクトに書き込むことができる。サーバがこの要求を受信すると、サーバアプリケーションは、スロットリング、バッチングの後でタイプに基づいて変換し、そしてそのタイプに基づいて適切なハンドラにデスパッチできる。サーバアプリケーションは、実装技術に基づいてエンドポイントが受け入れ可能なフォーマットに入力を変換できる。プロトコルは、その要求の入力をバイナリストリームでのみ受け取ることもあるし、または任意の入力をそのようなデータを記憶する効率を最大にするためにバイナリデータに変換することもある。機能は、ストリームを、アプリケーションが実行できる要求の詳細どのパーティション、どのセルを入手または送出するかを包含するパラメータになり得る入力と見なすことができる。別の例示的実施形態において、アプリケーションプロバイダ110のコンポーネントは、引数からバイナリストリームを構築できるオブジェクトを包含できる。ラッパーを実装して、そのような技術の実装において相互運用することが賢明であろう。ラッパーは、ネイティブ機能をラップし、そしてその機能を実装コードに示すことができる。ラッパー実装オブジェクトは、ブラウザベースのサービス特定のセルのデータを読み出すなどに出す各タイプの要求ごとに存在し得る。ラッパー実装オブジェクトを、ブラウザベースのサービス要求に使用できる同じ引数でインスタンス化できる。ラッパー実装オブジェクトは、要求を実行するネイティブ機能の実装メソッドを呼び出す方法を認識するAddToNativeRequestメソッドを実装できる。最後に、実行メソッドは、要求を実行し、そしてその結果即ち、ストリームを戻すインタフェースで呼び出されることもある。その結果は、ラッパーコード内のオブジェクト指向構造に変換して戻される。セルデータを記憶するまたは読み出す要求は、文書コンテンツのラッパーを使用するブラウザベースのアプリケーションとしてサービスされてもよい。アプリケーションは、共同オーサリング用のメタデータを記憶して読み出す際に使用されるラッパーインタラクションを適用できる。しかしながら、メタデータは、セルオブジェクトの観点から表すことができない。アプリケーションによって記憶されるメタデータは、拡張マークアップ言語XML文書などのデータのオパークブロブになり得る。メタデータをセルオブジェクトのグラフに入れ込むことで、セルの観点から記憶できる。読み出した後、データは、ストリームに再構成され得るセルオブジェクトのグラフとして再生できる。アプリケーションサーバ上のアプリケーションコードは、データをストリームとして記憶または読み出すことによってメタデータ記憶要求に対処できる。ストリームを、適切なスキーマに従って操作用のXML文書オブジェクトに供給できる。さらに別の実施形態において、サーバアクセス要求は、共同オーサリングセッションに参加する/離脱するなどの、機能性を実行する要求のセットに限定されてもよい。機能性は、現在認証されているユーザに関する情報ユーザ名、電子メールアドレス、および他のユーザ情報などを求めることができる。そのような要求は、共同オーサリング要求と名付けられてもよい。サーバ要求は、記憶要求と同じパターンに従う。オブジェクトは、扱い易い引数を使用して共同オーサリング要求を生成する能力がある。サーバ要求のパラメータおよび出力をより単純にして、記憶要求が必要とするバイナリストリームを生成するコストの負荷よりもかなり少なくできる。例示的実施形態を、本明細書では特定のプロトコル、コマンド、メッセージ、およびシステムを用いて説明する。しかしながら、それらは、実施形態に対する制限と見なされるべきではない。本開示の異なる態様は、本明細書で説明される発明の原理を用いた他のプログラミング言語、プロトコル、システム、およびコンポーネントで実装され得る。図2は、文書へのアクセスを管理するロックアクションの例示的ステップを示す。図200は、実施形態に従って編集を管理するロックアクションのいくつかの例示的ステップを示す。ウェブブラウザなどのクライアントアプリケーション210は、アプリケーションサーバ230から文書を要求する212ことができる。要求が受信されると、アプリケーションサーバは、要求された文書上で文書ロックを生成するために文書記憶サーバ250にロック要求を送信する232ことができる。文書ロックを生成すると、アプリケーションサーバは、記憶サーバから文書を読み出す234ことができる。ある実施形態に従って、サーバは、最初に文書のロックを要求し、その後、その要求が共同オーサリングに適しているかを確認するために検査し216、そしてひとたびその判定が行われると、サーバは、そのロックを複数のクライアントが文書を開くことができる1つのロックに調整する236ことができる。ロックが適していないと判定される場合、サーバは、排他的ロックに戻ることができる。これによって、サーバが、文書が複雑なために共同オーサリングに適していない文書、ならびに文書コンテンツとの同期から外れたまたは同期が誤っている恐れのある文書のコンテンツに対する事前の情報を持たなくても、そのようなアクションに適した文書を保持できるようにさせる。例示的実施形態をXML文書ホスティングテキストにすることができる。アプリケーションサーバは、XML文書をそのスキーマおよびパラグラフコンポーネントにパースし、そしてグラフに修正番号を与える間にグラフのコンポーネントを記憶できる。記憶要求の応答は、ストリーム形式であってよい。ストリームをXML文書か、あるいはXMLの単純なAPIにパースしてメモリの負荷を回避する必要があるかもしれない。プロパティを特定するXML要素は、メンバ変数によって構成部分となり得る。サーバアクセス要求からの応答は、特化した構造になる場合もあり、ブラウザが扱い易い表現に直接変換され得る。代替的実施形態において、より複雑な事後処理のステップは、サーバに仕事をさせる代償の結果、ウェブブラウザなどのシンクライアントアプリケーション上でかなりの性能利得が得られる。二次的メタデータは、ロックの記述、および各ロックに対してロックによって隠されたパラグラフのパラグラフ識別子のリストを包含できる。ブラウザは、グラフをトラバースして、各ロックを隠されたパラグラフに適用するために、識別子がロックによって特定されるパラグラフを探す必要があるかもしれない。代替として、ロックの仕様は、対応するパラグラフ識別子の代わりに、パラグラフオブジェクトのオブジェクト識別子を包含できる。グラフ内のオブジェクトの識別子によってオブジェクトを求めるには、ランダムアクセスが効率的であり、アプリケーションは、全てトラバースすることを回避できる。二次的メタデータの要求に応答するサーバのフロントエンドは、パラグラフ識別子の代わりに、隠れたパラグラフのオブジェクト識別子を特定するロックに応答するのに十分な情報を有することができる。二次的メタデータを読み出すと、サーバのフロントエンドは、ユーザがロックするのをパースし、その後、アプリケーションサーバ上の記憶装置からグラフの最新の修正を読み出すことができる。サーバのフロントエンドは続いて、グラフ内のすべてのパラグラフオブジェクトを見つけて、パラグラフ識別子からパラグラフオブジェクトのオブジェクト識別子までの逆マップを構築できる。サーバのフロントエンドは、パラグラフ識別子に代わりに、パラグラフオブジェクト識別子を包含する応答を構築できる。ブラウザ側では、共同オーサリングメタデータを解釈してそれに基づいて動作する共通のアクタ/エディタ/マネージャのパターンと、メタデータを移動するレプリケータとを有する以下のオブジェクトを含むことができる。1、エディタ表оエディタ表を定期的にダウンロードおよびアップロードするセッション中2回プロセス。оエディタ表のスキーマの情報をカプセル化するエディタ。о文書内の現在の共作成者を表すメモリ内構造を維持管理するマネージャ。マネージャは、エディタがデータを解釈する時にそのエディタによって呼び出される追加および削除メソッドを示すことができる。マネージャは、相手のGUID識別子によってユーザを見つける検索メソッドも示すことができる。оインスタントメッセージなどの他の機能性を提供することもできる任意のUIに対処するアクタ。2、二次的メタデータо二次的メタデータを定期的にダウンロードおよびアップロードするプロセス。二次的メタデータは、いくつかの情報を包含でき、主に文書内ロックに関する情報を包含する。二次的メタデータの、文書内ロック以外の情報をレプリケータで管理できる。ロックについて、アクタ/エディタ/マネージャのパターンを再度展開できる。1、ロックを追加および削除して、グラフのコンポーネントを提供するメソッドを有するアクタ。アクタは、ロックに対してここで入力できますかという問いに答えるメソッドも有することができる。2、プレースホルダー、エフェメラル、自動削除などの、さまざまなリストに入れることができる現在周知のロックのセットを維持管理するマネージャ。すべてのエフェメラルロックを除去して、それらをプレースホルダーロックに変えるなどの、グローバルロック動作。プレースホルダー、エフェメラル、および自動削除ロックをパラグラフなどの文書コンポーネントと関連付けることができる。3、設計は、ロック編集オブジェクトを必要としないかもしれない。ロックオブジェクトは、ひとたび生成されると、効率的に不変になり得るので、実行される実編集動作が必要ないかもしれない。スキーマロックをパラグラフなどの文書コンポーネントと関連付けることもできる。代替として、ウェブブラウザベースのクライアントは、共同オーサリングを許可しない特徴の広範なセットを有することができる。ブラウザのクライアントがスキーマロックを用いてすでに開いている文書即ち、別のクライアントがロックを用いたを見つけることができたとしても、ブラウザのクライアントは、全文書をスキャンする必要があり、問題となる特徴が見つからなければ、ユーザに編集のみを許可することもある。これは、サーバアプリケーションがほとんどすべての文書コンテンツを読み取って、そのコンテンツをグラフに変換することができ、そしていつでも動作を停止できるので、ウェブブラウザベースのクライアントに対する付加的な負荷とはならない。別の実施形態において、シード同期を、文書内の各パラグラフ識別子に再度番号を割り当てる要求として使用できる。要求は、要素を二次的メタデータまたは主メタデータ内の同じ名前に一致させることによって発行され得る。再番号割り当ては、文書識別子から開始される単一の増分カウントとして実行され、および事前定義された順序で文書内のパラグラフをウォークスルーすることによって実行され得る。二次的メタデータの後続するすべての要求および情報は、元の文書に記憶されたパラグラフ識別子ではなく、再番号割り当てから生じるパラグラフ識別子を参照できる。シード同期化要求の実装は、再番号割り当てがヘッダ/フッタ、フットノートおよびエンドノート、テキストボックス内のテキストなどの、ブラウザでは現在見えない文書の部分に依存する場合があるので、ブラウザでは不可能かもしれない。シード同期化をサーバのフロントエンドに実装できる。シード同期要求を実装する単純な手法は、文書のすべてのパラグラフのプロパティパラグラフ識別子が記憶されているプロパティを変更できる新しい修正を生成することである。第2の手法は、フロントエンド内の特定の要求メソッドを実装することである。そのメソッドは、古いパラグラフ識別子を新しいパラグラフ識別子にマップするディクショナリの戻り値を有する。ブラウザは、二次的メタデータのシード同期要素を受信する時に要求を発行して、結果として生じたマップを使用してメタデータのリマインダを解釈できる。代替的実施形態において、サーバの負荷を最小に保つために、ユーザが文書の単一の共作成者であるかどうかを判定する負荷の軽い要求を実装できる。ウェブブラウザベースのクライアントもサーバの負荷を最小限にする自分1人ですかという要求を実装できる。例示的実施形態として全シーケンスを以下に示す。以下のステップにおいて、Bは、ブラウザであり、Sは、フロントエンドアプリケーションのサーバである。1、Bファイルのコンテンツを入手するウェブブラウザベースのサービス要求を行う。2、Sスキーマロックを用いてファイルをロックして、セッションに参加することを試みる。a、Sスキーマロックによってファイルが既にロックされていて、継続する場合、ユーザは、もう単独ではない。b、Sファイルがその他のロックによってロックされた場合、セッションに失敗する。c、S現在のユーザの認証情報およびサーバ時間を入手する要求を発行する。3、Sストアからファイルをストリームとして読み出す。4、Sストリームをファイル内の各xml要素をウォークスルーするグラフに変換する。a、S共同オーサリングのセッションにおいて許可されていない要素と遭遇した場合に記憶する。5、Sロックを調整する。a、Sすでにスキーマロックを用いてロックされた場合、i、ステップ4aから発行がない場合、継続する。あるいは、排他的ロックに切り替えるように試みる。b、Sアプリケーションがスキーマロックか、または排他的ロックで終了したかどうかを記録する。さらに、ユーザが文書内ですでに単独ではない場合、2aから記憶する。6、S、このグラフを記憶装置に記憶し、そしてグラフをユーザ専用ルートに提供する。この方法において、複数のユーザは、すべての異なるグラフコンテンツを記憶装置の同じパーティション内に有して、互いに衝突しないようにすることができる。2人のユーザが同じ文書から開始するが、異なる変更を行う場合を例にする。グラフを記憶するために、グラフの変更は、保存動作を呼び出して、グラフの変更が1つずつコミットされるまで、別個のままにしなければならない。同じユーザが別のコンピュータまたは別のブラウザのインスタンスからクラッシュの後でもアプリケーションを起動する場合に、システムが、グラフのどの部分がそのユーザに属しているかを特定することができるように、このルートは、ユーザに固有であるしかし、ユーザのブラウザまたはコンピュータに固有ではない。7、Sこのグラフをブラウザに送る。8、Bコンテンツを非直列化して表示する。9、Bステップ5cにおいて、アプリケーションがスキーマロックを有する場合、a、Bステップ2aから現時点で単独の場合、他の作成者が参加する時/参加するかどうかを判定するためにAmIAloneに頻繁に尋ねるプロセスを開始する。b、Bユーザが編集する時、ユーザが単独または単独でないかに関わらずロックを生成する。c、ステップ2aから単独でない場合または上記の9aから単独でない場合、i、Bこのセッションステップ9bの間に生成されるロックの表示を開始する。ii、B現在のユーザをエディタ表に付加する要求を発行する。iii、Bエディタ表および二次的メタデータに対する反復プロセスを開始する。付加的な作成者またはロックに関する新しい情報を適切な情報としてグラフに適用できる。ひとたびユーザがエディタを離脱すると、アプリケーションは、エディタ表から現在のユーザを除去する要求および共同オーサリングセッションを離脱する要求を発行できる。さらに別の実施形態において、実装は、編集不可能な領域をサポートできる。その完全な機能は、編集可能な領域と編集不可能な領域との両方、ならびにテキスト以外のオブジェクト、またはテキストと他のオブジェクトとの組み合わせを包含する範囲にわたる選択肢から成る。ユーザは、選択を行い、そして相手のコンテンツを編集不可能な領域に置いて、非ブラウザベースのクライアントに一貫した体験を提供することができる。図3は、ある実施形態に従った例示的シナリオを示す。図3に示すように、アプリケーションサーバ330は、文書編集サービスを提供できる。文書は、テキスト、描画、イメージ、オーディオ、およびビデオを含むが、これらに限定されないさまざまフォーマットから構成されてよい。例示的実装は、複数のユーザの複数のクライアントアプリケーション310によって共同オーサリングされた文書を維持管理するアプリケーションサーバである。代替として、文書は、単一のフォーマットから構成されてよいし、またはテキスト、オーディオおよびビデオのコンテンツを組み合わせた文書などの、タイプの組み合わせを包含してもよい。図300に示すように、クライアントアプリケーションは、ユーザによって編集された文書を保存する要求を行う312ことができる。アプリケーションサーバは、文書記憶サーバ350に記憶された文書を読み出す332ことができる。ステップ314において、アプリケーションサーバは、ローカルに記憶された文書の基本グラフを読み出すまたは生成できる。ステップ316において、アプリケーションサーバは、ユーザ編集を包含するグラフの修正を読み出すことができる。その後、読み出された文書をローカルに記憶された基本修正に変換する318ことができる。基本修正と記憶された文書との間の変更は、アプリケーションサーバによって同期されることができる。ステップ320において、アプリケーションサーバは、最近再記憶された基本グラフの修正と、ユーザ編集を包含する任意の修正とを比較できる。基本グラフに入れられる編集は、ステップ322において文書に入力する準備ができている。これは、322において読み出す文書が、グラフ修正316を生成するのに使用された文書と同じ文書でなくても、起こり得ることに留意されたい。従って、共同オーサリングアプリケーションは、元文書のローカルコピーを保持する必要がなく、アプリケーションは、サーバ上の最新のコピーに対して働くのでスケールアウトする能力が向上する。文書の変更は、記憶サーバに保存できる334。文書の変更を保存した後、アプリケーションサーバは、その変更を包含する修正を基本グラフに付加できる。ステップ326において、アプリケーショングラフは、変更されたグラフをローカルに記憶できる。ステップ336において、どのロックホールドもロックリフレッシュを用いて解除できる。実施形態において、どの変更も、非ブラウザベースのクライアントとブラウザベースのクライアントとの両方における現在のセッション中に文書に付加できる。しかしながら、非ブラウザベースのクライアントなどのシッククライアントは、保存アクション中にサーバから文書の最新バージョンを入手できる。ユーザは、衝突する変更または編集を解消するように求められる場合がある。ユーザ選択は、衝突を解消するためにグラフ内の対応するコンポーネントに記録され得る。ブラウザベースのアプリケーションに送られる衝突解消情報は、編集時間、ユーザに認証情報、ユーザの存在情報、およびユーザの役割を含むことができる。結果として生じたコンテンツは、新しい最新のバージョンとしてサーバに戻って保存され得る。別の実施形態において、保存中に統合するためのハイレベル実装は、以下を含むことができる。1、他のユーザまたは作成者によって行われた変更のセットを入手する。2、ユーザによって行われた変更を他の作成者によって行われた変更と比較する。サーバは、衝突として双方によって操作されるすべてのオブジェクトを収集できる。3、衝突すると見なされるすべてのオブジェクトに対して、サーバは、アプリケーションが、ユーザが介入せずに衝突を解消できるかどうかを判定できる。衝突の解消は、望ましい変更の統合セットを表す現在のユーザの修正を操作することによって実現され得る。オブジェクトが解消されないままである場合、サーバは、統合動作を停止して、ブラウザに信号を送って衝突を解消するUIをユーザに提示するようにさせる。4、変更を文書に適用して、記憶サーバに保存できる。5、アプリケーションサーバは、変更のセットを他の作成者からブラウザに送ることができる。さらに、衝突を解消するために、ユーザ自身の変更に対して変更を任意に行うことができ、その変更を送ることもできる。他のユーザによって行われる変更のセットの入手は、なおも課題が存在し得る。他のユーザの変更を管理するための入力は、不完全に見えるかもしれない。文書の現在の状態は、利用できるであろうが、元の状態は、利用できない。しかしながら、アプリケーションサーバは、元グラフを通じて文書の元の状態について把握している。ユーザによって行われる変更は、一部グラフが元に変換されなかった文書において、他の作成者によって行われた変更と恐らく衝突しないであろう。サーバアプリケーションは、文書の現在の状態を変換し、そして結果として生じたグラフを元のグラフと比較できる。比較は、文書の他の共作成者によって行われた変更のセットにおいて生じ得る。変更のセットは、グラフの2つの状態の違いとなり得るので、修正として最も自然に表すことができる。従って、サーバアプリケーションは、衝突を検出するのに必要なすべての情報を入手し、そして統合動作の最終において他の共作成者の変更をブラウザに送ることができるようになる。現在の文書の状態から生じるグラフと元グラフとの比較は、それ自体に課題が存在する。パラグラフおよび他のオブジェクトが付加または除去されたか、あるいは任意の方法で移動された恐れがあるので、グラフ内のノードを1つずつ比較することを単に用いることができない。ある種の固有の識別子がアタッチされる文書パラグラフまたは表の行を例とするの構成では、これらの識別子を使用して、すぐに対応しなければならない元グラフからノードを選び出し、そして変化があったかどうかを確かめるためにプロパティを比較することができる。例示的実施形態において、システムは、最初に元グラフ全体にわたって読み込み、そしてパラグラフの識別子によってそのオブジェクト元状態を表したグラフノードにマップすることを構築する。その後、文書の現在の状態に対応するグラフを構築する。この新しいグラフのパラグラフに対応するノードが構成されると、元ノードは、パラグラフの識別子を使用して検索される。そのようなパラグラフが、元グラフに基づいて構成されたマップ内で見つからない場合、そのパラグラフは、他の作成者によって新しく付加されたことになる。ノードがマップ内で見つかった場合、現在のノードのプロパティは、元ノードのプロパティと比較される。プロパティが任意に付加または除去された場合、またはプロパティの値が元ノードの同じプロパティの値とは異なる場合、そのプロパティは、変更されたことになる。文書内に固有の識別子が適用される構成もあり得る。現在の構成と元の構成とを比較するために、固有の識別子が関連するそのような構成の近くまたは構成内に包含する他のオブジェクトに依存することができる。例えば、セル表は、それ自体の固有の識別子を有していない。しかしながら、この実施形態において、任意のセル表に包含する最終パラグラフと関連付けられる識別子は、その表ならびに、そのパラグラフ自体セル表およびパラグラフノードのオブジェクトは、異なったタイプから成るので、両方の識別子として同じ値を使用する際の曖昧さがないの識別子として使用される。これは、それらの識別子が変更しないように、そのオブジェクトを変更する時のある法則を守るために編集システムの他の部分が必要になる。セル表の例の場合、セルに対するどの編集も、最終パラグラフのパラグラフ識別子を変更できない。代替として、衝突を自動的に解消できない場合、他の作成者によって行われた変更を包含する修正は、衝突するオブジェクトとマークされてブラウザに送られ得る。さらに、同じ変更をブラウザに送って、ユーザの文書を最新の状態にすることができる。最後に、ユーザに、衝突を解消するためにUIを提示できる。ユーザは、すべての衝突が解消されると、再度保存を試みることができる。保存動作中に統合を実行する例示的シーケンスを詳述する。以下のステップにおいて、Bは、ブラウザであり、Sは、フロントエンドアプリケーションのサーバである。1、B文書を保存するウェブブラウザベースのサービス要求を送る。2、S記憶サーバから文書の現在の状態をIStreamとして読み出す。3、S記憶装置に記憶されていた元グラフをロード中に読み出す。4、Sユーザが行った編集としてサーバに蓄積された修正を読み出す。5、Sステップ3の元グラフを使用して、他のユーザによって行われた変更の修正を蓄積するベースラインとして文書を変換する。6、Sステップ4の修正をステップ5の修正と比較する。a、S両方のステップにおいてオブジェクトが見つかった場合、ステップ3または4による修正を変更することによって解消を試みる。b、どのオブジェクトも解消することができない場合、保存を停止し、ステップ5の修正に戻る。7、S文書の保存およびステップによって変更された修正を実行する。8、S結果として生じた文書を記憶サーバに戻して記憶する。9、Sステップ5による修正を基本グラフに付加して、その結果を新しいベースとしてマークする。10、Sステップ6の恐らく変更された修正を記憶装置に付加する。11、Sファイルのロックをリフレッシュする。12、Sステップ5の修正と変更された場合ステップ6の修正との両方を戻す。図4Aから図4Cまでは、ある実施形態に従った例示的シナリオを示す。例示的実施形態において、表の構造的変更の統合は、変更が互いに直交する場合に複雑になり得る。図410において、ユーザは、2×2表の編集を開始できる。ユーザが中央の列を付加して、そして他のユーザが中央の行を付加する場合、予測される結果は、図420ようになる。予測される結果を達成するには、サーバアプリケーションは、付加される行表が2つの行を有する場合に付加されるが、統合中にその表に付加される第3のセルを有する必要があるかを検出する必要があり得る。あるいは、他のユーザによって付加された列が、セルが欠けている図430の表につながる恐れがある。このタスクは、列が第1クラスのオブジェクトとして文書でもグラフ表記でも表されないという事実によって困難になる。この複雑な状況は、1人のユーザが列その列の数が変更していないように見えるを検出して列の同じ番号を付加する時か、またはすべての共作成者のアクションの総数が全表を除去する数に達する時に生じ得る。複雑な統合解決の代替的実施形態において、ブラウザベースのアプリケーションは、同じパラグラフを編集する2人の作成者に対処しなければならない場合がある。ブラウザベースのアプリケーションは、キャラクターレベルで変更を組み合わせるのに望ましくないので、ユーザ入力無しではこの衝突の解消を試みることができない。アプリケーションは、ワードの複雑さのために無意味なワードを生成する恐れがある。分類する次の論理的単位は、ワード処理の境界に置かれるであろう。ブラウザベースのアプリケーションは、2つの付加または削除が合理的に独立したものと理解されている表のパラグラフまたは行と違って、パラグラフからワードまたは文を付加または除去するには、コンテンツをかなり変更するため、ユーザ入力も要求できる。複雑な統合解決の別の実施形態において、ブラウザベースのアプリケーションは、リストおよび再番号割り当てを用いて衝突を解消しなければならない場合がある。実装は、ワード処理アプリケーションなどのブラウザベースのアプリケーションが、リスト項目を記録し、そしてその項目に番号を割り当てることができる方法に関するコードの中で最高のレベルである。リスト項目の番号を計算し、そしてグラフ自体に永続的でないプロパティとして記憶できる。リスト項目として更新される番号を付加および削除するか、または上げるおよび下げることができる。さらに、ワード処理の場合、そのアプリケーションは、ブラウザのそのようなすべての項目メンバの値を再計算できない。しかしながら、サーバアプリケーションは、ロード動作中に値を計算して、ユーザ編集アクションの後、追加的にのみ変更できる。ユーザと他の共作成者との両方が衝突しない変更を行うことができる場合しかし、結果として変更するリスト内の項目の番号割り当てが生じる、サーバアプリケーションは、統合動作の部分として番号を更新する必要があるかもしれない。上記のオンライン文書編集を同期するシステムおよび実装は、図解を目的とし、実施形態に対して制限するものではない。文書は、テキスト、描画、イメージ、オーディオ、およびビデオを含むが、これらに限定されないさまざまなタイプから構成されてよい。文書は、タイプの組み合わせによって構成され得る。ユーザ編集を、本明細書で説明される発明の原理を使用した他のモジュール、プロセス、および構成を用いて同期できる。図5は、実施形態を実装できる例示的ネットワーク化環境である。ユーザ編集の同期化を管理するサーバアプリケーションを、ホストサーバなどの、1または複数のサーバ514または単一のサーバ例えば、ウェブサーバ516上で実行されるソフトウェア経由で実装できる。プラットフォームは、ネットワーク510を介してスマートフォン513、ラップトップコンピュータ512、またはデスクトップコンピュータ511クライアントデバイスなどの、個々のコンピューティングデバイス上のクライアントアプリケーションと通信できる。上記のように、文書アプリケーションサーバは、文書記憶サーバに記憶された文書のユーザ編集を同期するアルゴリズムを実行できる。ユーザが文書のコンポーネントを編集する場合、アプリケーションサーバは、ユーザ編集中にロックされたコンポーネントに関する情報を、クライアントデバイス511、512、513上で文書を編集する他の共作成者に送信できる。クライアントデバイス511、512、513は、以前に説明したように、リモートサーバ複数例えば、サーバ514のうちの1つ上で実行されるアプリケーションにアクセスできるようにさせる。サーバ複数は、直接またはデータベースサーバ518を介して関連データをデータストア複数519から読み出すまたはそのデータストアに記憶できる。ネットワーク複数510は、サーバ、クライアント、インターネットサービスプロバイダ、および通信媒体のうちの任意のトポロジーを備えることができる。実施形態に従ったシステムは、静的または動的トポロジーを有することができる。ネットワーク複数510は、企業ネットワークなどのセキュアなネットワーク、無線オープンネットワークなどのセキュアでないネットワーク、またはインターネットを含むことができる。ネットワーク複数510は、公衆交換電話網PSTNまたはセルラーネットワークなどの、他のネットワークを介して通信を調整することもできる。さらに、ネットワーク複数510は、Bluetooth登録商標またはこれに順ずる、短距離無線ネットワークを含むことができる。ネットワーク複数510は、本明細書で説明されるノード間の通信を提供する。ネットワーク複数510は、例として、音響、RF、赤外線および他の無線媒体などの、無線媒体を含むが、これらに限定されない。コンピューティングデバイス、アプリケーション、データソース、およびデータ分散システムによる他の多くの構成を用いて、オンライン文書編集を同期できる。さらに、図5において論じたネットワーク化環境は、単に図解を目的とするものである。実施形態は、例示的アプリケーション、モジュール、またはプロセスに限定されない。図6および関連する論述は、実施形態を実装できることに適したコンピューティング環境の簡潔で一般的な説明を与えることを意図する。図6を参照し、実施形態に従って、コンピューティングデバイス600などのアプリケーションの例示的コンピューティングオペレーティング環境を説明する。基本構成において、コンピューティングデバイス600は、オンライン文書のユーザ編集を同期するオンラインアプリケーションサーバであり、少なくとも1つの処理ユニット602およびシステムメモリ604を含むことができる。コンピューティングデバイス600は、プログラムを実行する際に協働する複数の処理ユニットも含むことができる。コンピューティングデバイスの正確な構成およびタイプに応じて、システムメモリ604は、揮発性RAMなど、不揮発性ROM、フラッシュメモリなどまたはその2つのある組み合わせであってよい。システムメモリ604は、典型的には、ワシントン州レドモンドにあるマクロソフト社製WINDOWS登録商標オペレーティングシステムなどの、プラットフォームの動作を制御するのに適したオペレーティングシステム605を含む。システムメモリ604は、プログラムモジュール606、文書サービス622、および同期化モジュール624などの、1または複数のソフトウェアアプリケーションも含むことができる。文書サービス622は、編集用のオンライン文書を提供するサービスの一部であってよい。同期化モジュール624は、ユーザ編集を記憶された文書に同期して、共同オーサリング編集によって生じる衝突を解消することができる。文書は、コンポーネントに細分化され、そしてコンポーネントは、コンポーネントレベルのロックをパラグラフなどの文書の部分的編集に実装するグラフに記憶され得る。この基本構成は、図6の破線608内のコンポーネントによって示される。コンピューティングデバイス600は、付加的な特徴または機能性を有することができる。例えば、磁気ディスク、光ディスクまたは磁気テープ、光テープなどの、付加的なデータ記憶デバイスリムーバブルおよび/またはノンリムーバブルを含むこともできる。そのような付加的記憶装置は、図6のリムーバブル記憶装置609およびノンリムーバブル記憶装置610によって示される。コンピュータ可読記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの、情報を記憶する任意の方法または技術で実装される、揮発性および不揮発性、リムーバブルおよびノンリムーバブル媒体を含むことができる。システムメモリ604、リムーバブル記憶装置609およびノンリムーバブル記憶装置610は、すべてコンピュータ可読記憶媒体の例である。コンピュータ可読記憶媒体は、RAM、ROM、EEPROM、フラッシュメモリまたは他のメモリ技術、CD-ROM、デジタル多用途ディスクDVDまたは他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、あるいは所望の情報を記憶するのに使用することができ、且つコンピューティングデバイス600によってアクセスすることができるその他の媒体を含むが、これらに限定されない。このような任意のコンピュータ可読記憶媒体は、コンピューティングデバイス600の一部であってよい。コンピューティングデバイス600は、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイス、および同様の入力デバイスなどの、入力デバイス複数612を有することもできる。ディスプレイ、スピーカ、プリンタ、および他のタイプの出力デバイスなどの、出力デバイス複数614も含むことができる。このようなデバイスは当業者には周知であり、ここで詳細に論じる必要はない。コンピューティングデバイス600は、デバイスが、分散コンピューティング環境における無線ネットワーク、衛星リンク、セルラーリンク、および同様の機構などを介して、他のデバイス618との通信を行うようにさせる通信接続616を包含することもできる。他のデバイス618は、通信アプリケーション、記憶サーバ、および同様のデバイスを実行するコンピュータデバイス複数を含むことができる。通信接続複数616は、通信媒体の一例である。通信媒体は、その中にコンピュータ可読命令、データ構造、プログラムモジュール、または搬送波または他の移送機構などの、変調データ信号の他のデータを含むことができ、そして任意の情報配信媒体を含む。用語変調データ信号は、その特性セットのうちの1または複数を有するか、または信号の情報を符号化することに関してそのような方法で変更される信号を意味する。通信媒体は、例として、有線ネットワークまたは直接有線接続などの、有線媒体と、音響、RF、赤外線および他の無線媒体などの、無線媒体とを含むが、これらに限定されない。実施形態の例も方法を含む。その方法を、本明細書で説明される構造を含む、いくつかの方法で実装することができる。そのような1つの方法は、本明細書で説明されるタイプのデバイスをマシン動作によって行うことである。別の選択的方法は、一部を実行する1または複数の人間のオペレータと共に実行される方法の個々の動作のうちの1または複数に関する。この人間のオペレータは、互いに共同配置される必要はないが、それぞれは、唯一、プログラムの一部を実行するマシンと共に配置されなければならない。図7は、実施形態に従って、修正を文書コンポーネントレベルで制御することによってオンライン文書編集を同期するプロセスである、プロセス700の論理流れ図を示す。プロセス700を、オンライン文書サービスをクライアントに提供するアプリケーションサーバによって実装できる。プロセス700は、動作710から開始し、そこでオンライン文書アプリケーションサーバ例えば、ウェブサーバのフロントエンドは、ユーザから文書の要求を受信する。文書は、さまざまなフォーマットから構成されてよい。ユーザ要求を受信すると、アプリケーションサーバは、動作720において文書が記憶サーバでロックされるようにする要求ができる。文書をロックした後、アプリケーションサーバは、動作730において記憶サーバから文書を読み出すことができる。記憶サーバは、文書をストリームとしてアプリケーションサーバに送信できる。アプリケーションサーバは、動作740において、ストリームを文書コンポーネントに変換し、そしてコンポーネントをグラフにロードできる。サーバは、読み出された文書を包含するグラフ修正を、ローカルに記憶された基本グラフと比較し、そしてコンポーネントの変更を任意に同期できる。動作750において、アプリケーションサーバは、どの文書コンポーネントがユーザによって変更されたかを判定できる。動作760において、保存動作は、ユーザが保存動作を呼び出した後で実行され得るし、アプリケーションサーバは、ユーザ変更に基づいてグラフのどのコンポーネントをロックするかを判定し、そして後続の動作770においてグラフの新しい修正を生成する間に、対応するコンポーネントの変更を記録できる。アプリケーションサーバは、動作780において、現在働いているコンポーネント上でユーザ編集が同時にならないように、文書ロックをローカルグラフ上のコンポーネントベースのロックに変更できる。クライアントアプリケーションは、文書のどのコンポーネントがユーザによってロックされかまたは動かされるかを示す通知を指示することができる。提供される情報は、ユーザ存在情報、およびコンポーネントの現在の作成者を示す作成者名も包含できる。さらに、文書レベルのロックもユーザに表示することができる。さらに、共作成者の存在情報は、共作成者が最後に編集したグラフのコンポーネントに記憶され得る。共作成者の存在情報は、編集されたコンポーネントを有するクライアントアプリケーションによって表示され得る。文書内の他の作成者の情報を示すメタデータを受信すると、現在のユーザは、ロックされたコンポーネントをさらに変更することができない。他の作成者が相手の変更をコミットするために保存する場合/時、それによって保持されたロックを任意に除去し、代わりにリフレッシュ要求されたロックに変えることができる。このロックは、異なる体裁を有するので、もはや他の作成者と関連しない。逆に、現在のユーザが編集アクションを実行しない場合、自分達の現在の作成者の存在情報は、必要に応じて文書内ロックの存在情報を記述するメタデータに付加するよことによって他の作成者に通信され得る。現在のユーザが自身の変更を保存する場合、現在のユーザによって保持されたロックを任意に除去する要求をサーバに送って、代わりに他の人に対するリフレッシュ要求されたロックに変えることができる。プロセス700に含まれる動作は、図解を目的とするものである。実施形態に従ったオンライン文書編集の同期は、本明細書で説明される発明の原理を使用して、ステップを少なくしたまたは付加した同様のプロセス、ならびに動作の異なる順序によって実装されてよい。上記の明細書において、例およびデータは、製品の完全な説明および実施形態の構成の使用を提供する。発明の主題が構造的特徴および/または方法論的動作に固有の言語で説明されているが、添付の特許請求の範囲で定義される発明の主題は、必ずしも上記の固有の特徴または動作に限定されるものではないことを理解されたい。むしろ、上記の固有の言語および動作は、特許請求の範囲および実施形態を実装する例示的形態として開示される。