(57)【特許請求の範囲】
【請求項１】
文書型定義によって文書の構造が定義される文書に対する共同執筆・編集・利用を支援する文書管理装置において，
前記文書に対する部分構造の変更を伴うことがある部分編集要求に対し，編集前の実際の文書構造に対して，少なくとも編集対象部分の前後に対する文書要素の追加可能性または文書要素の削除可能性に関する制約を文書全体の文書型定義に加味した，部分構造の文書型定義を自動生成する手段と，
前記生成された部分構造の文書型定義に従って，編集対象の文書が前記文書型定義において規定された編集対象部分の前後に対する文書要素の追加可能性または文書要素の削除可能性に関する制約を少なくとも満たす範囲内で文書の部分編集を行う手段とを備える
ことを特徴とする文書管理装置。
【請求項２】
文書型定義によって文書の構造が定義される文書を格納するデータベースに対するアクセス手段を持つサーバ装置と，前記文書の編集対象部分を前記サーバ装置から取得し前記文書を編集する１または複数のクライアント装置とからなる文書管理装置において，
前記クライアント装置は，
前記文書の編集対象部分を選択する手段と，
編集対象部分に対する文書要素の追加または削除を予約する手段と，
前記編集対象部分の選択および追加予約または削除予約に基づいて，前記サーバ装置から編集対象となる文書のデータと，少なくとも編集対象部分の前後に対する文書要素の追加可能性または文書要素の削除可能性に関する制約の情報を含む部分編集用文書型定義とを獲得する手段と，
獲得した文書のデータを編集する手段と，
前記部分編集用文書型定義をもとに編集結果が前記部分編集用文書型定義において規定された編集対象部分の前後に対する文書要素の追加可能性または文書要素の削除可能性に関する制約を少なくとも満たすかどうかを検査する手段とを備え，
前記サーバ装置は，
前記クライアント装置からの編集対象部分の選択，および追加予約または削除予約の要求に対して，文書全体の文書型定義から編集対象部分に対する文書要素の追加または削除の可能性を解析し，編集前の実際の文書構造に対して，少なくとも編集対象部分の前後に対する文書要素の追加可能性または文書要素の削除可能性に関する制約を文書全体の文書型定義に加味した，部分編集用文書型定義を生成する手段と，
編集対象となる文書のデータを前記データベースから抽出し，そのデータと前記生成した部分編集用文書型定義とを前記クライアント装置へ通知する手段とを備える
ことを特徴とする文書管理装置。
【請求項３】
文書型定義によって文書の構造が定義される文書に対する共同執筆・編集・利用を支援する文書管理装置において前記文書を格納するデータベースに対するアクセス手段を提供するサーバ装置であって，
前記文書に対するアクセスを要求する装置からの編集対象部分の選択，および追加予約または削除予約の要求に対して，文書全体の文書型定義から編集対象部分に対する文書要素の追加または削除の可能性を解析し，編集前の実際の文書構造に対して，少なくとも編集対象部分の前後に対する文書要素の追加可能性または文書要素の削除可能性に関する制約を文書全体の文書型定義に加味した，部分編集用文書型定義を生成する手段と，
編集対象となる文書のデータを前記データベースから抽出し，そのデータと前記生成した部分編集用文書型定義とを前記アクセスを要求する装置へ通知する手段とを備える
ことを特徴とする文書管理装置のサーバ装置。
【請求項４】
文書型定義によって文書の構造が定義される文書に対する共同執筆・編集・利用を支援する文書管理装置において前記文書を格納するデータベースに対するアクセス手段を提供する装置から前記文書の編集対象部分を取得し，その文書を編集するクライアント装置であって，
前記文書の編集対象部分を選択する手段と，
編集対象部分に対する文書要素の追加または削除を予約する手段と，
前記編集対象部分の選択および追加予約または削除予約に基づいて，前記文書を格納するデータベースに対するアクセス手段を提供する装置から編集対象となる文書のデータと，少なくとも編集対象部分の前後に対する文書要素の追加可能性または文書要素の削除可能性に関する制約の情報を含む部分編集用文書型定義とを獲得する手段と，
獲得した文書のデータを編集する手段と，
前記部分編集用文書型定義をもとに編集結果が前記部分編集用文書型定義において規定された編集対象部分の前後に対する文書要素の追加可能性または文書要素の削除可能性に関する制約を少なくとも満たすかどうかを検査する手段とを備える
ことを特徴とする文書管理装置のクライアント装置。
【請求項５】
請求項１から請求項４までのいずれか１項に記載の文書管理装置において，
文書要素の複写，移動，交換，追加または削除の履歴情報を前記文書の形式で保持する手段と，
保持した履歴情報を装置に依存しない形式で出力する手段とを備える
ことを特徴とする文書管理装置。
【請求項６】
請求項５記載の文書管理装置において，
前記文書の形式は，元の文書型定義に履歴情報部分の宣言を加えて生成した履歴付きの前記文書の文書型定義を用いる形式である
ことを特徴とする文書管理装置。
【請求項７】
請求項５記載の文書管理装置において，
前記文書の形式は，履歴情報の文書の骨組みに元の前記文書を埋め込んだ形式であり，改定履歴を差分情報として列挙して前記文書本体の要素との対応を記述する形式である
ことを特徴とする文書管理装置。
【請求項８】
請求項５記載の文書管理装置において，
前記文書の形式は，履歴情報の文書の骨組みに元の前記文書を埋め込んだ形式であり，改定前と改定後の要素間の遷移関係を記述する形式である
ことを特徴とする文書管理装置。
【請求項９】
文書型定義によって文書の構造が定義される文書に対する共同執筆・編集・利用を支援する文書管理装置を構成する計算機が実行するプログラムを格納した計算機読み取り可能なプログラム記憶媒体であって，
前記計算機を，
前記文書に対する部分構造の変更を伴うことがある部分編集要求に対し，編集前の実際の文書構造に対して，少なくとも編集対象部分の前後に対する文書要素の追加可能性または文書要素の削除可能性に関する制約を文書全体の文書型定義に加味した，部分構造の文書型定義を自動生成する手段と，
前記生成された部分構造の文書型定義に従って，編集対象の文書が前記文書型定義において規定された編集対象部分の前後に対する文書要素の追加可能性または文書要素の削除可能性に関する制約を少なくとも満たす範囲内で文書の部分編集を行う手段として，
機能させるためのプログラムを格納したことを特徴とする文書管理装置のプログラム記憶媒体。
【請求項１０】
文書型定義によって文書の構造が定義される文書に対する共同執筆・編集・利用を支援する文書管理装置において前記文書を格納するデータベースに対するアクセス手段を提供するサーバ装置を構成する計算機が実行するプログラムを格納した計算機読み取り可能なプログラム記憶媒体であって，
前記計算機を，
前記文書に対するアクセスを要求する装置からの編集対象部分の選択，および追加予約または削除予約の要求に対して，文書全体の文書型定義から編集対象部分に対する文書要素の追加または削除の可能性を解析し，編集前の実際の文書構造に対して，少なくとも編集対象部分の前後に対する文書要素の追加可能性または文書要素の削除可能性に関する制約を文書全体の文書型定義に加味した，部分編集用文書型定義を生成する手段と，
編集対象となる文書のデータを前記データベースから抽出し，そのデータと前記生成した部分編集用文書型定義とを前記アクセスを要求する装置へ通知する手段として，
機能させるためのプログラムを格納したことを特徴とする文書管理装置におけるサーバ装置のプログラム記憶媒体。
【請求項１１】
文書型定義によって文書の構造が定義される文書に対する共同執筆・編集・利用を支援する文書管理装置において前記文書を格納するデータベースに対するアクセス手段を提供する装置から前記文書の編集対象部分を取得し，その文書を編集するクライアント装置を構成する計算機が実行するプログラムを格納した計算機読み取り可能なプログラム記憶媒体であって，
前記計算機を，
前記文書の編集対象部分を選択する手段と，
編集対象部分に対する文書要素の追加または削除を予約する手段と，
前記編集対象部分の選択および追加予約または削除予約に基づいて，前記文書を格納するデータベースに対するアクセス手段を提供する装置から編集対象となる文書のデータと，少なくとも編集対象部分の前後に対する文書要素の追加可能性または文書要素の削除可能性に関する制約の情報を含む部分編集用文書型定義とを獲得する手段と，
獲得した文書のデータを編集する手段と，
前記部分編集用文書型定義をもとに編集結果が前記部分編集用文書型定義において規定された編集対象部分の前後に対する文書要素の追加可能性または文書要素の削除可能性に関する制約を少なくとも満たすかどうかを検査する手段として，
機能させるためのプログラムを格納したことを特徴とする文書管理装置におけるクライアント装置のプログラム記憶媒体。
【請求項１２】
請求項９記載の文書管理装置のプログラム記憶媒体であって，
さらに，前記計算機を，
文書要素の複写，移動，交換，追加または削除の履歴情報を前記文書の形式で保持する手段と，
保持した履歴情報を装置に依存しない形式で出力する手段として，
機能させるためのプログラムを格納したことを特徴とする文書管理装置のプログラム記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は，マニュアル等の大規模なＳＧＭＬ（Ｓｔａｎｄａｒｄ  Ｇｅｎｅｒａｌｉｚｅｄ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）文書群の共同執筆・編集，改訂管理などのために用いられる文書管理装置に関するものである。
【０００２】
近年，文書の電子化が進み，大量の文書を蓄積して再利用することで文書作成のコストを大幅に引き下げることが可能になってきた。また，一方で，技術の高度化に伴うマニュアル類のボリュームの増加と多様化，インターネットに代表される新たな文書流通メディアの出現もあいまって，流通・作成・管理すべき文書の量が爆発的に増加している。必然的に，一度作成した電子化文書を再利用して，新たな文書として発信していきたいという要請が強まっている。ＳＧＭＬは，このような要請に応じて登場し，広く使われ始めた文書形式である。
【０００３】
ＳＧＭＬ形式は装置依存性が低く，電子データとしての交換が容易で，また，文書の体裁の切替えや文書内容の部分的な再利用などが容易であり，同じ内容の文書を様々な形式で用いることができるという特徴を持つ。
【０００４】
このため，現在は，マニュアルなどの技術文書の作成管理や計算機支援印刷や電子出版における利用が最も進んでいるが，その他ネットワークによるコミュニケーションや，商取引，電子図書館などのデータベースなど，大規模で寿命の長い文書を扱う分野で広く使われ出している。例えば，近年爆発的な勢いで拡大しているインターネットにおいて使われているＨＴＭＬ文書も，ＳＧＭＬ形式の一種であり，電子図書館における図書や目録などの蓄積・管理もＳＧＭＬ形式によって試みられている。
【０００５】
このようにＳＧＭＬ形式の文書が広く，そして大規模に使われるようになってきたため，ＳＧＭＬ文書を管理する装置の必要性が高まっている。ＳＧＭＬ文書は，大規模で長い寿命を持つことでその特徴が生かされるという性質をもつことから，これを管理する装置は，ＳＧＭＬ文書の作成・蓄積・再利用のライフサイクルを支援する装置でなければならない。また，ＳＧＭＬ文書はその構造が文書型定義（ＤＴＤ：Ｄｏｃｕｍｅｎｔ  Ｔｙｐｅ  Ｄｅｆｉｎｉｔｉｏｎ）中の定義に適合していなくてはならないので，ＳＧＭＬ文書管理装置には文書構造の整合性の管理機構も必要である。
【０００６】
本発明は，このようなＳＧＭＬ文書管理装置において，文書構造の整合性の管理および文書構造の改訂履歴管理のための機構に特徴をもつものである。
【０００７】
【従来の技術】
（１）文書の共同編集における文書全体の整合を維持する技術
大量の文書の作成には，既存文書の再利用と多人数で共同執筆・編集を行なえる環境が必要である。ＳＧＭＬ文書の管理装置としては，文書全体としての整合性を保ちつつ，文書の部分部分を独立して編集可能とする機構が必要となる。
【０００８】
個別の作業が正しく行なわれても，並行して進んでいた別の作業の影響で整合がとれなくなることがある。こうなると，作業結果を破棄して改めて更新しなおすか，整合のとれなかった部分を修正しない限り，元の文書には反映できないため（不整合のまま作業結果を反映すると他のＳＧＭＬアプリケーションで使用できなくなる），作業効率が阻害される。
【０００９】
このような事態を避けるために，従来の構造化文書管理装置では，文書の共同編集作業の場合，文書のある部分について，別の作業者に更新させないように読み出しのみ可（ｒｅａｄ−ｏｎｌｙ）にする等によりチェックアウトし，作業終了後にチェックインしてｒｅａｄ−ｏｎｌｙを解除するというようなチェックアウト／チェックイン機構を用意して対処してきた。この場合，一般に，作業者が更新可能なのはチェックアウトした部分に含まれる内容だけである。
【００１０】
従来のＳＧＭＬ文書管理装置においても基本的機構は同様であり，文書要素の単位でチェックアウト／チェックイン機構を用い，チェックアウトした文書要素の下位構造部分だけを更新可能とし，チェックインの際に文書全体のＤＴＤとの適合性を検査（これをＳＧＭＬパージングという）することで文書の整合性を維持していた。
【００１１】
（２）ＳＧＭＬ文書のパージングを効率的に行う技術
部分的に更新したＳＧＭＬ文書がＤＴＤに適合しているかを検査（ＳＧＭＬパージング）するためには，基本的には，更新部分以外の文書要素も含めて文書全体にどのような文書要素が配置されているかを調べなくてはならない。すなわち，ルート文書要素から各文書要素を順次ＤＴＤと対応付けていく必要がある。このとき，ＳＧＭＬ文書を文書要素単位で格納して前述のチェックアウト／チェックイン機構で部分編集を行う文書管理装置では，編集要素以外の部分の文書要素のタグ（ＧＩ：Ｇｅｎｅｒｉｃ  Ｉｄｅｎｔｉｆｉｅｒ；総称識別子）情報を，文書を格納しているデータベースから取り出す必要がある。なお，総称識別子（ＧＩ）とは，文書要素のタイプを示す名前であり，ＤＴＤは，この配置の仕方を階層ごとに内容モデル（ｃｏｎｔｅｎｔ  ｍｏｄｅｌ）で定義する。
【００１２】
これを単純に行うと，少なくとも編集しようとしている文書要素から文書のルートにいたるパスに含まれる文書要素およびそれらより前に出現している文書要素（文書中で先行する文書要素）のタグを取り出して照合を行う必要があり，文書を格納しているデータベースへのアクセスコストが大きくなる。そこで，従来の技術では，文書構造を文書内容とは別に格納したり，各々の文書要素にその先行文書要素のタグ列を対応付けて格納するなどの工夫により，ＳＧＭＬパージングのコスト軽減を図っているものもある。
【００１３】
（３）ＳＧＭＬ文書の改訂履歴管理技術
ＳＧＭＬ文書の改訂履歴の管理についてみると，ＳＧＭＬのような構造化文書を管理する技術は未成熟であり，構造の変化を改訂履歴として保持する技術は確立されていない。一般的には，文書要素レベルで細かく改訂履歴を管理する方法においても，改訂前の文書要素や改訂による差分を個別に保持するだけで，文書要素の配置の変化などの構造の履歴は保持していない。また，文書要素個別の履歴としては保持できない構造変化の履歴も管理するものとして，例えば特開平６−２５０８９５号公報に示されているような「構造化データベースシステム」があるが，装置に依存した内部表現形式によるものしか存在せず，履歴情報付きでＳＧＭＬ文書を自由に流通できるものとはなっていない。
【００１４】
【発明が解決しようとする課題】
本発明が解決しようとする問題点は，以下の２点である。
１）文書更新上の制約が不要に大きいという問題
共同編集において個々の作業の独立性を高めつつ文書全体の整合性を保つことが必要であるが，従来の技術では文書全体の整合性を保つことを優先していて，個々の作業の独立性が低くなっている。
【００１５】
従来の技術では，チェックアウトした文書要素の内容，すなわちその文書要素の下部構造と記述されている情報内容のみを編集可能としている。このため，チェックアウトした文書要素のタイプを表すタグの変更やそれ自体の分割や削除などは禁止されている。本質的に同時編集が不可能なのはＤＴＤ上で依存関係にある部分であり，ＤＴＤによってはタグの変更や要素の分割・削除などは他の編集とは独立して行える場合があるので，このような制約は必要以上に大きいものといえる。
【００１６】
このような事情により，例えば，章のレベルで分担して執筆中にその章の分割が必要になった場合，いったん編集を打ち切って１つ上位の文書要素レベルから編集をやり直す必要が生じる。作業途中でこのような中断がおきると，執筆者の思考の流れを阻害するだけでなく，上位文書要素レベルがその時点で更新不能であったり，分散環境で実行している場合には，その時点では文書本体へ物理的にアクセス不能であった，などの理由で作業を進められなくなる事態があり得，作業の進行の妨げとなる。
【００１７】
章の分割のような編集にうまく対応できないのは，チェックアウトする要素と周辺の要素との依存関係に応じて，部分編集に適切な制約を施す機構がないためである。
【００１８】
つまり，章の分割のような編集を可能にするためには，編集前の文書構造におけるチェックアウトする要素に関する依存関係を把握し，この依存関係に沿って編集に制約をかける必要がある。
【００１９】
ＳＧＭＬ文書は木構造であり，深さの異なる文書要素は親子関係にない限り依存しないが，同じ文書要素インスタンスを親とする姉妹文書要素インスタンスは文書型定義によっては依存しあう場合がある。このため，編集の整合性を保証するには，姉妹関係の依存性を予め把握しておかなければならない。例えば，ＤＴＤでいくつ出現してもよいように定義されている文書要素を編集する場合，その要素を同じタイプの要素に分割することや，削除することは可能であるが，必ず１つだけ出現しなくてはならないように定義されている要素についてはこのような編集を行うことはできない。
【００２０】
また，連続して１つ以上出現しなくてはならない文書要素を削除できるかどうかは，そのタグをもつ要素が実際の文書にいくつあって，そのうちで別の作業により削除されるかもしれない要素（他で編集中の要素）がいくつあるのかを把握しないと判定できない。例えば，
0003831085.tif 000002
という文書構造の例では，ｉｄ＝ｓｌ，ｉｄ＝ｓ２の文書要素のいずれか１つのみ削除可能である。
【００２１】
このような制約はＤＴＤだけでなく，並行して実行されている別の編集の結果にも依存するので，従来の技術のように，ＳＧＭＬ文書全体の文書型定義をそのまま編集の制約として用いて，更新結果をとりこんだ文書の形式を検査（ＳＧＭＬパージング）するだけでは取り扱うことができない。すなわち，ＳＧＭＬパージングでは，別の編集制約機構を用意するか，部分編集用に別のＤＴＤを用意することが必要となる。
【００２２】
本発明は，この点に関して，文書全体の文書型定義に編集前の実際の文書構造とその編集状況による制約を加味した，文書の部分に対する部分構造の文書型定義を自動生成して，解決を図るものである。
【００２３】
２）文書の構造変化の履歴が不十分であるという問題
もう一つの問題点は，ＳＧＭＬ文書の構造の変化の履歴が十分に保持されないことである。従来の一般的な履歴管理は，個々の文書要素の遷移として個別に保持しているため，単独の文書要素には記述することのできない移動・交換などの構造変化の履歴を正確に格納できない。
【００２４】
例えば，文書要素の分割は，文書要素内の一部削除と新文書要素の追加として，また，文書要素の交換は，２組の削除と追加との操作として解釈するか，あるいは，更新前と更新後の変化から推定して処理しているのが現状である。このため，結果の文書としては正しく処理したものと等価であるが，分割・交換などの更新履歴の信頼性が低くなっている。
【００２５】
このような構造変化の履歴も管理する装置（例えば特開平６−２５０８９５号公報）もあるが，管理されている情報は装置に依存するものであるため，ＳＧＭＬ文書を履歴情報付きで自由に流通できるものとはなっていない。
【００２６】
本発明は，上記の２つの問題を解決し，共同執筆・編集の効率化と改訂履歴の機能向上を実現すると同時に，その実現のために付加する文書管理情報を共通にして，管理情報の格納効率をあげつつ，また，管理すべき情報の種類を減らすことで管理効率をも向上させることを目的とする。
【００２７】
【課題を解決するための手段】
本発明は，上記課題を解決するため，ＳＧＭＬ（Ｓｔａｎｄａｒｄ  Ｇｅｎｅｒａｌｉｚｅｄ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）文書を格納し，共同執筆・編集・利用を支援し，改訂などの履歴を管理する文書管理装置において，例えば以下の機構を持つことを主要な特徴とする。
【００２８】
▲１▼  ＳＧＭＬ文書を文書要素単位で格納し，文書要素それぞれに，文書型定義中の文書要素宣言の内容モデル（ｃｏｎｔｅｎｔ  ｍｏｄｅｌ）に対してそれに適合している子文書要素のインスタンス識別子を付与した拡張内容モデルを対応付けて管理する機構
▲２▼  ＳＧＭＬ文書の編集中の部分に対応する部分編集用文書型定義を一時的に生成することにより，該当部分のみ独立にＳＧＭＬパージング可能とする機構
▲３▼  上位文書要素および前後の文書要素を編集可能にしたままで，部分編集用文書型定義に違反しない範囲において，編集中の最上位の文書要素の削除とタグ（総称識別子）の変更およびその前後に新たな文書要素を追加することを可能にする機構
▲４▼  文書要素の複写・移動（交換）・追加・削除の履歴を保持する機構
▲５▼  保持した履歴情報を装置に依存しない形式で出力する機構
図１は，以上の機構を実現する本発明のブロック構成図である。
【００２９】
図１において，ＳＧＭＬ文書管理装置１は，ＳＧＭＬ文書編集装置１０，ＳＧＭＬ文書交換装置２０，ＳＧＭＬ文書アクセス装置３０，ＳＧＭＬ文書のデータベース４０，ＳＧＭＬパーサ５０，５０’からなる。
【００３０】
本発明がサーバ・クライアント・システム上で実現される場合には，ＳＧＭＬ文書編集装置１０およびＳＧＭＬ文書交換装置２０はクライアント側に備えられ，ＳＧＭＬ文書アクセス装置３０，データベース４０，ＳＧＭＬパーサ５０はサーバ側に備えられる。さらにクライアント側にＳＧＭＬパーサ５０’が備えられていてもよい。
【００３１】
ＳＧＭＬ文書編集装置１０は，ＳＧＭＬ文書の編集対象部分をＳＧＭＬ文書アクセス装置３０を通じて取得し，編集を行う手段である。ＳＧＭＬ文書編集装置１０は，ＳＧＭＬ文書アクセス装置３０で生成された部分編集用ＤＴＤを元に，ＳＧＭＬパーサ５０’を呼び出すことにより編集結果の整合性を検査する部分編集用ＤＴＤ整合性検査手段１１と，文書要素の内容および拡張内容モデルの変更を記憶し，編集対象部分の内容・構造の変更履歴を生成する履歴作成手段１２を持つ。
【００３２】
ＳＧＭＬ文書交換装置２０は，外部のＳＧＭＬ文書または履歴付きＳＧＭＬ文書の入力・出力を行う手段である。これには，本装置内で用いる標準的な拡張モデル付きＳＧＭＬ文書形式と履歴情報のないＳＧＭＬ文書形式あるいは履歴情報を分離した履歴つきＳＧＭＬ文書形式との相互変換を行う機能がある。
【００３３】
ＳＧＭＬ文書アクセス装置３０は，クライアントの要求に従い，データベース４０に格納されたＳＧＭＬ文書の部分または全体の入出力や，部分編集用ＤＴＤの作成，ＳＧＭＬ文書の版数管理や文書の退避・復元などを行うものである。
【００３４】
ＳＧＭＬ文書アクセス装置３０は，標準的な拡張モデル付きＳＧＭＬ文書形式とデータベース４０の内部形式との相互変換を行う文書形式変換手段３１，部分編集用ＤＴＤを生成する部分編集用ＤＴＤ作成手段３２，ＳＧＭＬパーサ５０を呼び出すことにより，入力されたＳＧＭＬ文書の整合性を検査する文書形式整合性検査手段３３，文書内容や拡張内容モデルの履歴情報を整理する履歴管理手段３４を持つ。
【００３５】
ＳＧＭＬパーサ５０，５０’は，その他の装置の補助としてＤＴＤとＳＧＭＬ文書本体との対応付けを行うものである。クライアントのＳＧＭＬパーサ５０’はサーバのＳＧＭＬパーサ５０と機能的には同じもので，サーバ・クライアントが別の計算機である場合，特にオフライン状態のクライアントで編集中に整合検査などを行う時にはサーバと物理的に別の装置が利用される。
【００３６】
以上の各処理手段を計算機によって実現するためのプログラムは，計算機が読み取り可能な可搬媒体メモリ，半導体メモリ，ハードディスクなどの適当な記憶媒体に格納することができる。
【００３７】
【発明の実施の形態】
以下，本発明の実施の形態を説明する。
図２は，本発明におけるデータの基本構造を示す図である。図中の実線の矢印は識別子による対応関係を示している。本発明のデータ構成は，文書全体の情報と文書要素単位の情報に大別される。
【００３８】
図２（Ａ）に示す文書全体の情報には，文書を操作・管理するためのシステム情報や，文書の論理的な性質を記述するためのプロフィール情報，文書履歴情報などがある。
【００３９】
図２（Ｂ）に示す文書要素単位の情報には，文書単位で格納されたそれぞれの情報を関係づけて文書構造を表現する識別子情報，各々の文書要素がＳＧＭＬとしての情報（属性・タグ・下位情報），要素別の履歴情報，要素単位にアクセス制御などを行うためのシステム管理情報などがある。
【００４０】
文書は，文書要素毎にデータベース４０に格納され，インスタンス識別子を付与されて管理される。インスタンス識別子は，論理的には，（ある版数の）文書を識別する文書識別子，文書内の文書要素を特定するための要素識別子の２つから構成される。
【００４１】
文書識別子は，ある文書のある（独立した）版に対して一意に割り当てられたものである。
要素識別子は，ある文書における実際の文書要素（インスタンス）に対して一意に割り当てられたもので，ＳＧＭＬ文書における文書内のＩＤ参照の機能に対応が可能なものである。
【００４２】
また，改訂された各要素には改訂前の要素（列）がインスタンス識別子と改訂番号によって対応付けられている。改訂番号は，ある文書のある版としての改訂作業に対して一意に与えられた改訂の順序も表現した識別値で，具体的にはチェックインの際にシステムが付与するものである。
【００４３】
格納された要素は，インスタンス識別子を介してリンクされ，ＳＧＭＬ文書構造を形成する。ＳＧＭＬ文書構造を示すリンクは，ＤＴＤ中の内容モデルと対応付けて拡張内容モデルとして格納され，構造の改訂履歴管理や部分編集の独立性の判定にも利用されている。拡張内容モデルは，内容モデルに，実際のＳＧＭＬ文書の要素との対応関係（インスタンス識別子）とその要素の削除可能性指示子（削除可能数）を付与したものである。
【００４４】
まず，図３および図４を用いて，本装置によるＳＧＭＬ文書の格納の例を説明する。図３および図４では，図２に示した格納情報のうち構造に関わる部分などの主要部分のみを示している。図３に示すＳＧＭＬ文書の原文書は，ＳＧＭＬ文書交換装置２０によって内部表現へ変換され，ＳＧＭＬ文書アクセス装置３０を通じて，図４のような構成のデータとしてデータベース４０に格納される。
【００４５】
図３に示すＳＧＭＬ文書において，「＜  ＞」は，タグを表す。このＳＧＭＬ文書の原文書は，２つの章（ＳＥＣＴ）からなり，第１の章には２つの節（Ｐ），次の章（ＳＥＣＴ）には１つの節（Ｐ）を持つ構造になっている。
【００４６】
図５は，前記の拡張内容モデルの構成を本明細書で表現する形式に従ってバッカス記法（ＢＮＦ）で示した図である。ただし，このＢＮＦでは，表現が煩雑になることを避けるため，各構成単位の間の空白要素の有無は示していない。
【００４７】
なお，内容モデルにＡＮＹや＃ＰＣＤＡＴＡを含んでいて実際の文書にさらなる下部構造が表れる場合には，その下部構造単位での格納・管理，下部構造を無視した格納・管理など，下部構造の管理レベルを選択することができる。つまり，強調語句などは管理単位とせず，文や段落などの上位要素のレベルまでを単位として格納・管理することも可能である。
【００４８】
また，他文書中のある改訂状態の要素（部分木）を取り込むことも可能である。取り込みのモードとして，元の要素も変更する共有モードと元の要素には変更を加えない独立モード，変更自体を許さないリンクモードがある。
【００４９】
共有モード・リンクモードの時には，リンク用の特別な文書要素を介して，取り込み先から取り込んだ要素の実体へ対応付けられる。リンク用の文書要素には，取り込む部分木の最上位要素のインスタンス議別子と改訂番号および下位要素の要素識別子の対応表などが共有情報として格納され，下位情報は記述されない。要素識別子の対応表は，取り込んだ文書内の別の部分からのＩＤ参照を実現するために使用されるものである。独立モードの時には，取り込む部分内の各要素はコピーされ，履歴情報で元の要素と対応付けられる。
【００５０】
〔１〕部分編集用ＤＴＤ
本発明では，文書の要素あるいは親要素が共通の連続する文書列を対象に編集することができる。この際，編集中の部分の整合性を独立して検査（ＳＧＭＬパージング）できるようにするために，ＳＧＭＬ文書アクセス装置３０は，拡張内容モデルを利用して生成した部分編集用のＤＴＤを，ＳＧＭＬ文書編集装置１０へ渡すようにしている。
【００５１】
部分編集用ＤＴＤは，部分編集用に生成した一次的な文書型名のＤＴＤであり，全文書用のＤＴＤ中の宣言に，生成した文書型名の宣言をルート文書要素の宜言として追加したものである。ルート文書要素の宣言は，編集対象部分の最上位の文書要素の並びに対応する内容モデルの部分を取り出したものを基本にして，追加予約（後述）に対応した前後の要素の追加可能性と削除予約（後述）に対応した要素の削除可能性の情報を出現標識などの形で反映したものである。
【００５２】
なお，出現標識としては，「＊，？，＋」などがあり，「＊」は要素が任意数出現することを示し，「？」は要素が１つのみ出現するか省略され得ること，すなわち要素が０個か１個であることを示し，「＋」は要素が１以上出現することを示す。
【００５３】
図５は，拡張内容モデルの構成例を示す図である。
拡張内容モデルは，拡張モデル群またはそれと添加要素，除外要素を含み，拡張モデル群は，拡張モデル列または削除可能モデル群を含む。削除可能モデル群は，削除可能数，タグもしくはモデル列，出現標識，拡張モデル列を含む。拡張モデル列は，拡張モデル要素を含む。拡張モデル要素は，拡張モデル群または拡張要素である。拡張要素は，タグまたはタグと出現標識に，インスタンス識別子を付与したものである。
【００５４】
この拡張内容モデルは，部分編集用ＤＴＤを生成する上で必須ではないが，編集部分の最上位要素に関する制約を求める処理を高速に行うために利用される。すなわち，拡張内容モデルを保持することで，編集部分の制約を求める処理の編集前の文書要素と内容モデルとを対応付ける部分が，拡張内容モデルを参照するだけで行えるようになる。
【００５５】
（１）部分編集の独立性を確保する手段
本発明では，ＳＧＭＬ文書の共同執筆などにおいて，並行して進む部分編集作業の競合を避けるために，編集対象要素のチェックアウト／チェックインをべースにした排他制御を行う。これは，編集対象要素のチェックアウト機構と，出現数に制約のある可変個要素（内容モデル中で出現標識が付与された要素）に関して削除予約・追加予約機構を用意して実現する。可変個要素と添付要素は，ＳＧＭＬ文書の同一レベルに（すなわち，ある文書要素の下位に並んで）出現している他の文書要素とは独立に追加・削除が可能な場合がある。
【００５６】
本発明は，追加・削除の可能性を予め解析し，追加・削除が可能な場合について，編集要素の前後に可変個要素または添付要素を挿入することと，編集要素自体が可変個要素か添付要素である場合の分割と削除の操作を可能にする。削除予約・追加予約は，これに関する処理の競合を防ぐものである。
【００５７】
また，編集の対象部分の最上位の文書要素（列）がＯＲ（｜）で連結されたモデル群の要素となっている場合には，それらのタグを変更することも可能である。本発明では，これについても後述の部分編集用ＤＴＤに該当するモデル群の制約を反映することで，可能な限り編集対象部分の最上位要素のタグの変更を可能にしている。
【００５８】
（２）部分編集用ＤＴＤ生成
図６は，部分編集用ＤＴＤの生成の例を説明する図である。
ＳＧＭＬ文書全体は，ＤＯＣという型の文書で，ＤＯＣはいくつかのＳＥＣＴ（章）からなり，またそれぞれのＳＥＣＴはいくつかのＰ（パラグラフ）からなっている。ここで，ＳＧＭＬ文書アクセス装置３０は，ユーザからの指示に応じて編集対象（１番目のＳＥＣＴ中の２番目のＰ）を取り出して，元のＤＴＤおよび文書本体による編集の制約を織り込んだ部分編集用ＤＴＤを生成して，文書本体と部分編集用ＤＴＤをＳＧＭＬ文書編集装置１０へと渡す。
【００５９】
ＳＧＭＬ文書（全体）のＤＴＤが，
<!ELEMENT DOC(SECT+)>
<!ELEMENT SECT(P+)>
であるとき，ＳＧＭＬ文書アクセス装置３０によって生成される部分編集用ＤＴＤは，
<!ELEMENT EDITDOC(P*)>
である。部分編集用ＤＴＤは，一時的なＥＤＩＴＤＯＣという文書型名をもち，編集対象の要素を削除したり，別のＰ（パラグラフ）というタグの要素を追加してもよいという制約を表現している。「＊」は，Ｐの数は任意であることを示す出現標識である。Ｐの数が任意でよいのは，元のＤＴＤにおいて，編集対象として抜き出す部分が「Ｐ＋」（＋は要素が１以上出現することを表す）となっており，既にＰが１つ存在して整合性が保証されているからである。
【００６０】
（３）文書要素の追加・削除・タグの変更
次に，編集の対象部分の最上位レべルの文書要素の追加・削除・タグ変更の例を図７〜図１０を用いて説明する。図中のＤＴＤは構造に関わる部分のみを示す。
【００６１】
図７は，編集対象としてチェックアウトする要素の前後に別の要素を追加可能かどうかを判定する例を説明する図である。
編集対象部分の最上位レべルで追加可能な要素は，可変個要素あるいは添付要素である。このような要素は，それが出現可能な位置の隣の要素を編集する場合にＤＴＤに違反することなく追加することができる。
【００６２】
図７において，ＳＧＭＬ文書（全体）のＤＴＤが，
<!ELEMENT DOC(SECT+)>
<!ELEMENT SECT(TITLE?,P+)>
であるとする。図７（Ａ）は，文書に未だＴＩＴＬＥ（題名）がなく，追加が可能なＴＩＴＬＥに隣接しないＰを編集部分とする場合，図７（Ｂ）は，ＴＩＴＬＥがなく，追加が可能なＴＩＴＬＥに隣接するＰを編集部分とする場合，図７（Ｃ）は文書に既にＴＩＴＬＥがある場合の例である。
【００６３】
ここで，ＴＩＴＬＥが追加可能となるのは，ＴＩＴＬＥが編集対象の文書にまだない状況で，かつＴＩＴＬＥが追加可能な位置に隣接する（この場合は先頭の）Ｐを編集対象とする場合である。図７（Ｂ）の「ＴＩＴＬＥがない場合（その２）」がこれに当たる。図７（Ａ）の「ＴＩＴＬＥがない場合（その１）」では，編集対象のＰがＴＩＴＬＥが追加可能な位置の隣にないのでＴＩＴＬＥは追加不能であり，図７（Ｃ）「ＴＩＴＬＥがある場合」は，既にＴＩＴＬＥが存在するために追加不能である。
【００６４】
図７（Ａ）では，編集部分であるＰがＴＩＴＬＥと隣接しないので，生成される部分編集用ＤＴＤは，
<!ELEMENT EDITDOC (P*)>
となる。したがって，部分編集ではＴＩＴＬＥを追加することができないが，Ｐを任意の数とすることができる。
【００６５】
図７（Ｂ）では，編集部分であるＰがＴＩＴＬＥと隣接するので，生成される部分編集用ＤＴＤは，
<!ELEMENT EDITDOC (TITLE?,P*)>
となり，部分編集ではＴＩＴＬＥを追加することもでき，Ｐを任意の数とすることもできる。
【００６６】
図７（Ｃ）では，ＴＩＴＬＥが既に生成されているので，生成される部分編集用ＤＴＤは，
<!ELEMENT EDITDOC (P*)>
となり，部分編集ではＴＩＴＬＥを追加することができない。
【００６７】
図８は，異なる編集作業による要素の追加の競合を抑止するための追加予約の例を説明する図である。
ＳＧＭＬ文書（全体）のＤＴＤが，
<!ELEMENT DOC(SECT+)>
<!ELEMENT SECT(TITLE?, AUTHOR?, P+)>
であるとする。出現数に上限のある要素（ＳＧＭＬ文書では，ＯＰＴ出現標識’？’のついた１つのみ出現するか省略され得る要素）では，その要素が編集前に存在しない場合に限り追加処理が可能である。このような要素を追加可能な状態で編集するには，前後にある要素をチェックアウトすると共に追加予約を発行する。追加予約された要素は，別の作業によっては追加不能となる。
【００６８】
図８（Ａ）に示す初期状態では，ＳＧＭＬ文書のＳＥＣＴ（章）の中にまだＡＵＴＨＯＲ（著者名）がないので，ＴＩＴＬＥ（題名）およびそれに後続するＰ（パラグラフ）のいずれの編集でもＡＵＴＨＯＲが追加可能である。ここで，ＴＩＴＬＥを編集（チェックアウト）するときＡＵＴＨＯＲの追加予約を行うと，図８（Ｂ）に示すＴＩＴＬＥ編集中にはＡＵＴＨＯＲが追加予約され，後続のＰの編集においてはＰの編集のみ可能となる。
【００６９】
すなわち，図８（Ａ）に示す初期状態において，ＴＩＴＬＥを編集するときに，ＡＵＴＨＯＲの追加予約も行う場合に，生成される部分編集用ＤＴＤは，
<!ELEMENT EDITDOC (TITLE, AUTHOR?, P*)>
となり，部分編集ではＴＩＴＬＥの編集に加えてＡＵＴＨＯＲとＰを追加することができる。
【００７０】
さらに，図８（Ｂ）に示すＴＩＴＬＥ編集中の別のＰの編集においては，ＡＵＴＨＯＲは追加予約済みであるので，生成される部分編集用ＤＴＤは，
<!ELEMENT EDITDOC (P+)>
となり，部分編集ではＰの数を１以上の任意の数とすることができるだけである。
【００７１】
図９は，異なる編集作業による要素の削除の競合を抑止するための削除予約の例を説明する図である。
ＳＧＭＬ文書（全体）のＤＴＤが，
<!ELEMENT DOC(SECT+>
<!ELEMENT SECT(P+)>
であるとする。出現数に下限のある可変個要素（ＳＧＭＬ文書では，ＰＬＵＳ出現標識’＋’のついた１つ以上出現する要素）では，その要素が編集前に２つ以上存在している場合に限り削除処理が可能である。このような要素を削除可能な状態で編集する場合，編集対象の要素をチェックアウトすると共に削除予約を発行する。削除予約は，既に削除予約された要素を除いた同種の要素の出現数が２以上である場合にだけ受理される。
【００７２】
図９（Ａ）に示す初期状態では，１番目のＳＥＣＴ（章）には２つのＰ（パラグラフ）があるので，いずれか１つは削除可能である。２番目のＰを削除予約してチェックアウトすると，生成される部分編集用ＤＴＤは，
<!ELEMENT EDITDOC (P*)>
となり，部分編集ではパラグラフを削除可能要素として取り出すことが可能となる。
【００７３】
このように，１番目のＳＥＣＴの中の２番目のＰを削除可能な状態でチェックアウトすると，図９（Ｂ）に示すその編集中には，２番目のＰが削除予約されているため１番目のＰの編集では削除不可となる。したがって，１番目のＳＥＣＴ中の１番目のＰの部分編集で生成される部分編集用ＤＴＤは，
<!ELEMENT EDITDOC (P+)>
となり，Ｐを削除することはできない。
【００７４】
以上の追加・削除予約は，通常チェックアウト時にＳＧＭＬ文書編集装置１０からＳＧＭＬ文書アクセス装置３０に対して発行されるが，編集途中で追加発行も可能である。
【００７５】
図１０は，編集対象の最上位レべルの要素のタグを変更する例を説明する図である。
ＳＧＭＬ文書（全体）のＤＴＤが，
<!ELEMENT DOC(SECT+)>
<!ELEMENT SECT(P｜LIST)+>
<!ELEMENT LIST(ITEM+)>
であり，編集対象部分の最上位の文書要素がＯＲ（｜）で連結された内容モデル群と対応しているため，タグを変更してＬＩＳＴ構造の内容へ置き換えることが可能である。
【００７６】
この場合に生成される部分編集用ＤＴＤは，
<!ELEMENT EDITDOC(P ｜LIST)*>
<!ELEMENT LIST(ITEM+)>
となり，ＰをＬＩＳＴに変更することが可能となる。
【００７７】
図１１および図１２は，クライアントが文書の編集部分を獲得するための処理のフローチャートである。
図１１のステップＳ１では，クライアントのＳＧＭＬ文書編集装置１０は，ユーザに対し編集対象要素の選択を促す。
【００７８】
ステップＳ２では，選択された編集対象の選択予約を発行する。
ステップＳ３では，選択予約が成功かどうかを判定し，選択予約が成功した場合にはステップＳ４の処理へ進み，選択予約が成功しなかった場合にはステップＳ１３の処理へ進む。
【００７９】
ステップＳ４では，追加・削除予約候補要素のリストを獲得する。追加・削除予約候補要素リストとは，編集対象部分およびその周辺にある追加・削除可能な要素のリストであり，後述（図１５，図１６）の処理に従ってサーバ側で作成されるものである。
【００８０】
ステップＳ５では，予約候補要素リストが空であるかどうかを判定する。リストが空でない場合にはステップＳ６の処理へ進み，リストが空の場合にはステップＳ１４の処理（図１２）へ進む。
【００８１】
ステップＳ６では，追加・削除予約要素リストを空にする。
ステップＳ７では，追加・削除候補要素を表示してユーザに選択を促す。
ステップＳ８では，選択要素が何であるかを判定する。選択要素が追加要素である場合にはステップＳ９の処理へ進み，選択要素が削除要素である場合にはステップＳ１０の処理へ進み，選択要素が選択終了であればステップＳ１４の処理（図１２）へ進む。
【００８２】
ステップＳ９では，選択要素を追加予約リストに追加し，ステップＳ１１の処理へ進む。
ステップＳ１０では，選択要素を削除予約リストに追加する。
【００８３】
ステップＳ１１では，選択要素を追加・削除候補リストから削除する。
ステップＳ１２では，予約候補要素リストが空であるかどうかを判定する。予約候補要素リストが空であればステップＳ１４の処理（図１２）へ進み，予約候補要素リストが空でなければステップＳ７以降の処理を繰り返す。
【００８４】
ステップＳ１３では，ステップＳ３の処理の判定結果（選択予約不成功）により，選択不能理由をユーザに通知して，処理を終了する。
図１２のステップＳ１４では，削除要素リストが空であるかどうかを判定する。削除要素リストが空でない場合にはステップＳ１５の処理へ進み，削除要素リストが空である場合にはステップＳ１９の処理へ進む。
【００８５】
ステップＳ１５では，削除要素リストの先頭要素をポップする。
ステップＳ１６では，ポップした要素の削除予約を発行する。
ステップＳ１７では，削除予約が成功したかどうかを判定し，予約が成功であればステップＳ１４の処理へ戻り，予約が成功でなければステップＳ１８の処理へ進む。
【００８６】
ステップＳ１８では，削除予約失敗をユーザに通知する。
ステップＳ１９では，追加要素リストが空であるかどうかを判定する。追加要素リストが空でない場合にはステップＳ２０の処理へ進み，追加要素リストが空である場合にはステップＳ２４の処理へ進む。
【００８７】
ステップＳ２０では，追加要素リストの先頭要素をポップする。
ステップＳ２１では，ポップした要素の追加予約を発行する。
ステップＳ２２では，追加予約が成功したかどうかを判定し，予約が成功であればステップＳ１９の処理へ戻り，予約が成功でなければステップＳ２３の処理へ進む。
【００８８】
ステップＳ２３では，追加予約失敗をユーザに通知する。
ステップＳ２４では，編集データのチェックアウトと部分編集用ＤＴＤの獲得を行う。
【００８９】
ステップＳ２５では，選択予約の解除を行い，処理を終了する。
図１３および図１４は，サーバが要求に応じて部分編集用ＤＴＤと編集データを提供する処理のフローチャートである。
【００９０】
図１３のステップＳ３１では，ＳＧＭＬ文書アクセス装置３０は，編集対象要素の選択予約を受け付ける。
ステップＳ３２では，指定要素（列）は予約されているかどうかを判定する。予約されている場合にはステップＳ４０の処理へ進み，予約されていない場合にはステップＳ３３の処理へ進む。
【００９１】
ステップＳ３３では，指定要素（列）を一時ロック（選択予約）する。
ステップＳ３４では，指定要素（列）の親要素（列）が予約されているかどうかを判定する。予約されている場合にはステップＳ３９の処理へ進み，予約されていない場合にはステップＳ３５の処理へ進む。
【００９２】
ステップＳ３５では，指定要素（列）の親要素（列）を一時ロック（選択予約）する。
ステップＳ３６では，部分編集用内容モデルおよび追加・削除候補要素リスト作成処理を行う。
【００９３】
ステップＳ３７では，クライアントに選択予約成功を通知する。
ステップＳ３８では，クライアントに追加・削除予約候補リストを提供する。その後，図１４のステップＳ４１の処理へ進む。
【００９４】
ステップＳ３９では，指定要素（列）の一時ロックを解除する。
ステップＳ４０では，クライアントに処理失敗とその理由を通知し，処理を終了する。
【００９５】
図１４のステップＳ４１では，次の要求が何であるかを判定する。次の要求が追加削除予約であればステップＳ４２の処理へ進み，次の要求がチェックアウトであれば，ステップＳ４３の処理へ進み，次の要求が選択予約解除（要求終了）であればステップＳ５５の処理へ進む。
【００９６】
ステップＳ４２では，追加・削除予約リストに追加し，ステップＳ４１の処理へ戻る。
ステップＳ４３では，削除予約リストが空であるかどうかを判定し，削除予約リストが空でなければステップＳ４４の処理へ進み，削除予約リストが空であればステップＳ４７の処理へ進む。
【００９７】
ステップＳ４４では，削除予約リストの先頭要素をポップする。
ステップＳ４５では，ポップした要素に対応する部分編集用内容モデルの要素の出現標識を，'+' を'*' に変更する。
【００９８】
ステップＳ４６では，ポップした要素に対応する親要素の拡張内容モデル中の削除可能モデルの削除可能数から編集対象の要素の数を引き，その後，ステップＳ４３の処理へ戻る。
【００９９】
ステップＳ４７では，追加予約リストを追加要素番号でソートする。
ステップＳ４８では，要素番号が負の要素を部分編集用内容モデルの先頭に追加する。
【０１００】
ステップＳ４９では，要素番号が正の要素を部分編集用内容モデルの末尾に追加する。
ステップＳ５０では，追加予約リスト中の要素を追加予約する。
【０１０１】
ステップＳ５１では，編集対象をチェックアウトし，選択予約のための一時ロックを解除する。
ステップＳ５２では，部分編集用の文書型名を生成し，部分編集用内容モデルとあわせて編集部分の最上位要素の要素宣言を作成する。
【０１０２】
ステップＳ５３では，作成した要素宣言に全体のＤＴＤ中の宣言を加え部分編集用ＤＴＤを生成する。
ステップＳ５４では，クライアントに部分編集用ＤＴＤと編集データを提供し，処理を終了する。
【０１０３】
ステップＳ５５では，一時ロックを解除し，処理を終了する。
図１５および図１６は，図１３のステップＳ３６に示す，拡張内容モデルを利用した部分編集用内容モデルおよび追加・削除候補要素リスト作成処理のフローチャートである。
【０１０４】
図１５のステップＳ６１では，照合要素列からなる拡張内容モデルの部分を取り出す。
ステップＳ６２では，閉じていない（閉じ括弧‘）’の足りない）要素群があるかどうかを判定する。閉じていない要素群がある場合にはステップＳ６３の処理へ進み，閉じていない要素群がない場合にはステップＳ６７の処理へ進む。
【０１０５】
ステップＳ６３では，最後の要素（群）は削除可能モデル群の要素かどうかを判定する。最後の要素（群）が削除可能モデル群の要素である場合にはステップＳ６４の処理へ進み，最後の要素（群）が削除可能モデル群の要素でない場合にはステップＳ６６の処理へ進む。
【０１０６】
なお，拡張内容モデルの削除可能モデル群は，元のＳＧＭＬの内容モデルで「'*'(REP)（０個以上出現可能を示す）」, 「'+'(PLUS) （１つ以上出現可能を示す）」の出現標識が付与された部分に対応する。削除可能モデル群の先頭要素は，元の内容モデルに削除可能数を付与したもので，２番目以降の要素は，それに対応する実際の文書要素の拡張モデル（インスタンス識別子付きのモデル）である。
【０１０７】
ステップＳ６４では，最後の削除可能モデル中の要素数と削除可能数とを比較する。削除可能数が要素数以上の場合にはステップＳ６５の処理へ進み，その他の場合にはステップＳ６６の処理へ進む。なお，任意個繰り返し可能な場合（出現標識（'*'(REP)の場合）は，常に判定結果が「その他」となるように削除可能数（例えば−１）を設定しておく。
【０１０８】
ステップＳ６５では，削除可能モデル群を削除予約候補要素群として削除予約候補リストに加える。
ステップＳ６６では，末尾に')' を補う。
【０１０９】
ステップＳ６７では，先頭の要素（群）が削除可能モデル群の要素かどうかを判定する。先頭の要素（群）が削除可能モデル群の要素である場合にはステップＳ６８の処理へ進み，先頭の要素（群）が削除可能モデル群の要素でない場合にはステップＳ７１の処理へ進む。
【０１１０】
ステップＳ６８では，最初の削除可能モデル中の要素数と削除可能数とを比較する。削除可能数が要素数以上の場合にはステップＳ６９の処理へ進み，その他の場合にはステップＳ７０の処理へ進む。なお，任意個繰り返し可能な場合（出現標識（'*'(REP)の場合）は，常に判定結果が「その他」となるように削除可能数（例えば−１）を設定しておく。
【０１１１】
ステップＳ６９では，削除可能モデル群を削除予約候補要素群として削除予約候補リストに加える。
ステップＳ７０では，取り出した拡張内容モデルの先頭に削除可能モデルの先頭要素と'(' を加える。
【０１１２】
ステップＳ７１では，部分拡張内容モデル内の削除可能モデル群について先頭要素だけを残し，さらに，先頭の+<削除可能数> を取り除く。
ステップＳ７２では，部分拡張内容モデルからインスタンス識別子を取り除く。これにより，部分編集用内容モデルが完成する。
【０１１３】
図１６のステップＳ７３では，指定要素列の１つ前の要素を取り出す。先頭要素が要素列の区切りの場合には，その１つ上のレベルで要素（モデル群）を取り出す。
【０１１４】
ステップＳ７４では，要素番号に０を代入する。
ステップＳ７５では，取り出した要素（モデル群）が何かを判定する。取り出した要素（モデル群）がインスタンス識別子を含まない省略可能モデルまたは削除可能モデルであればステップＳ７６の処理へ進み，その他（そのレベルでそれ以上の要素がない場合を含む）であればステップＳ７９の処理へ進む。
【０１１５】
ステップＳ７６では，要素番号から１を引く。
ステップＳ７７では，取り出した要素と要素番号の組を追加候補要素（群）として追加候補要素リストに追加する。
【０１１６】
ステップＳ７８では，１つ前の要素を取り出す。その後，ステップＳ７５へ戻り，同様に処理を繰り返す。
ステップＳ７９では，要素番号に０を代入する。
【０１１７】
ステップＳ８０では，指定要素列の１つ後ろの要素を取り出す。最終要素が要素列の区切りの場合には，その１つ上のレベルで要素（モデル群）を取り出す。
ステップＳ８１では，取り出した要素（モデル群）が何かを判定する。取り出した要素（モデル群）がインスタンス識別子を含まない省略可能モデルまたは削除可能モデルであればステップＳ８２の処理へ進み，その他（そのレベルでそれ以上の要素がない場合を含む）であれば処理を終了する。
【０１１８】
ステップＳ８２では，要素番号から１を引く。
ステップＳ８３では，取り出した要素と要素番号の組を追加候補要素（群）として追加候補要素リストに追加する。
【０１１９】
ステップＳ８４では，１つ後ろの要素を取り出す。その後，ステップＳ６１の判定を繰り返す。
〔２〕改訂履歴情報
（１）改訂履歴の格納方法
前出の図５に示す拡張内容モデルは，ある文書要素の下位の要素の並びを完全に表現しているので，その遷移の情報を文書要素に対応付けて管理することで，ある時点におけるある文書構造上の位置にいずれの内容があったのかという履歴情報とすることができる。この情報に文書要素の直接の上位文書要素が何であったのかという履歴を加えれば，文書の構造がどのように変化したかを完全に追跡できる。
【０１２０】
すなわち，上位要素から見て下位要素の構成がどのように変化してきたかは拡張内容モデルの改訂履歴のみを参照すれば掌握でき，下位要素がどこから移動してきたかを追跡するためには，改訂前の上位要素の拡張内容モデルの（該当する改訂レベルの）改訂履歴を取り出して，その下位要素がいずれの位置にあったかを調べればよい。
【０１２１】
このことを利用して，本発明では，次のように履歴情報を格納し管理する。
履歴情報には，前出の図２に示すように文書単位に管理されるものと文書要素単位に管理されるものとがある。文書単位に管理される履歴情報には，改訂日時，改訂者，改訂部分のシステムが自動的に設定する情報と，改訂名やコメントなどユーザが自由に入力できる情報があり，文書のライフサイクルにおける全改訂を順序列として識別する改訂番号を付与して管理されている。改訂文書単位に管理される履歴情報は，その改訂に関するマスターデータであり，要素単位の履歴を高めるために，各文書要素に対応付けてコピーを格納することもできる。
【０１２２】
文書要素単位で管理される履歴情報には，親要素の改訂履歴，拡張内容モデルの改訂履歴，文書内容の改訂履歴，タグ・属性の改訂履歴，およびコメントからなる。これらの情報は，基本的には改訂前の該当する文書要素へのリンクに改訂番号とコメントと削除・移入・移出された子文書要素の情報を付与した形で保持される。
【０１２３】
再利用される可能性のない改訂前の要素に関する履歴情報は，差分の形に直してスペース効率や履歴の検索効率を高めることもできる。差分で格納する場合には，改訂番号，コメント，改訂前の親要素の識別子，改訂前の拡張内容モデルとの差分，改訂前の文書内容との差分，タグ・属性の改訂前との差分を１単位とする列として格納する。
【０１２４】
（２）文書構造の改訂履歴の作成手法
文書構造の改訂履歴は，基本的には，ＳＧＭＬ文書アクセス装置３０において，チェックインの時点で拡張内容モデルの差分を求めることにより作成される。この差分を正確に求めるために，ＳＧＭＬ文書アクセス装置３０は，ＳＧＭＬ文書編集装置１０へ差分を求める手がかりとなる情報を文書要素のＳＧＭＬ属性の形式で渡す。この情報は，その要素および親要素の文書識別子・要素識別子および改訂番号である。このうち，文書識別子・改訂番号は別の文書や改訂レベルとの間で文書要素を共有・交換する際に用いられるもので，通常の編集時には要素識別子だけが利用される。
【０１２５】
専用のＳＧＭＬ文書編集装置１０の操作は，文書要素の移動・交換・追加・削除などの構造の変更と，文書要素内のデータの変更，文書要素の属性の変更に大別されている。このうち構造の変更操作が行われた場合には，ＳＧＭＬ文書編集装置１０は，削除された子の識別子，移出・移入された子文書要素の識別子とその移動先・元の親要素の識別子を，文書要素の属性に加える。また，要素の追加や複写が発生した場合には，追加・複写された要素に対して仮の要素識別子を設定する。
【０１２６】
専用のＳＧＭＬ文書編集装置１０では，ある文書の部分として別の文書の要素（部分木）を取り込むこともできる。この場合，取り込まれた他の文書の親要素の拡張内容モデルのインスタンス識別子は，文書識別子と要素識別子の組になる。また，取り込まれた要素の編集に関する変更モードの省略値が別に付与される。変更モードは，取り込まれた要素に対する変更を元の要素へも及ぼすかどうかを区別するものである。これには，元の要素も変更する共有モードと元の要素には変更を加えない独立モード，変更自体を許さないリンクモードがある。共有モードの時には，チェックアウト時に取り込まれた要素に対応する別の文書の部分も同時にチェックアウトされる。
【０１２７】
なお，同一の文書の部分かどうかに関わらず，別々にチェックアウトした編集部分の間で文書要素を交換した場合には，ＳＧＭＬ文書編集装置１０は，強制的に同期チェックインモードとなる。この場合，ＳＧＭＬ文書アクセス装置３０は，両方の編集結果が正しい場合に限りチェックインを受理する。ＳＧＭＬ文書アクセス装置３０で付与された特別の属性を変更しなければ，一般のＳＧＭＬエディタなどを用いて編集しても，構造の改訂履歴を作成することが可能である。ただし，上に述べた別の文書の文書要素の取り込みや，リンクなどの機能は利用できない。また，複写などが意図通りに解釈されない場合もあり得る。
【０１２８】
（３）改訂履歴の作成例
図１７は改訂履歴の作成例を説明する図である。まず，図１７（Ａ）に示す編集前のＳＧＭＬ文書本体より点線で囲まれた部分をＳＧＭＬ文書アクセス装置３０を通じて取り出し，文書識別子（ｄｏｃ），要素識別子（ｉｄ），改訂番号（ｖｅｒ），親要素の識別子（ｐｉｄ）を属性として付与してＳＧＭＬ文書編集装置１０に渡す。
【０１２９】
この例では，ＳＧＭＬ文書編集装置１０による編集操作によって，要素識別子ｐ２の要素をコピーし，要素識別子ｐｌの要素を要素識別子ｓ２へ移動する編集を行っている。ここで，要素識別子ｐ２をコピーした要素については，仮の要素識別子ｎｅｗ１が付与され，コピー元の要素を表すｃｏｐｙｏｆ属性と変更モードを示すｃｏｐｙｓｔａｔ（ここでは独立モード）の属性がＳＧＭＬ文書編集装置１０によって設定される。
【０１３０】
編集結果は，ＳＧＭＬ文書アクセス装置３０を通じて取り込まれ，図１７（Ｂ）に示す編集後の文書本体がデータベースに格納される。ここで，更新された部分には，更新後の要素が作成され，更新前の要素へのリンクが改訂番号などによって設定されている。
【０１３１】
（４）改訂履歴の出力方法
本発明では，改訂履歴をＳＧＭＬ文書とともに出力する手段を持つ。改訂履歴もＳＧＭＬ文書形式で出力される。改訂履歴は，基本的には改訂の差分を列挙したものである。改訂前の文書も独立に出力してその間の遷移（対応）関係を加えることもできる。
【０１３２】
出力形式には，元のＤＴＤに履歴情報部分の宣言を加えて生成した履歴付きＳＧＭＬ文書のＤＴＤを用いる形式と，履歴文書をハブとして元のＳＧＭＬ文書を埋め込んだ形式の２種類がある。後者はさらに，改訂履歴を差分情報として列挙してＳＧＭＬ文書本体の要素との対応を記述する形式と，改訂前のＳＧＭＬ文書群も出力してそれらの要素の間の遷移関係を記述する形式とがある。いずれの形式でも，履歴情報として出力される内容は，図２に示した履歴情報と同一である。
【０１３３】
履歴情報付きＳＧＭＬ文書において，履歴情報とＳＧＭＬ文書本体との対応付けは，ＳＧＭＬのＩＤ参照機能を使って行われる。このために，通常はＳＧＭＬ文書本体の各文書要素にインスタンス識別子に相当する属性を埋め込む。なお，例えばＩＳＯ規格として知られているＨｙＴｉｍｅ（ＩＳＯ１０７４４）のロケーションラダーの機能を利用して，元のＳＧＭＬ文書のＤＴＤに手を加えることなく実現することも可能である。このような出力が可能なのは，本発明におけるインスタンス識別子などの構成がＳＧＭＬのＩＤ参照やＨｙＴｉｍｅのリンク機能との親和性が高いからである。
【０１３４】
要素識別子は，ＳＧＭＬ文書本体の要素の識別子の属性として，文書識別子は，ＳＧＭＬ文書本体を履歴文書と別の文書とした場合のＳＧＭＬ文書エンティティの識別子として，改訂番号は履歴情報部分の要素の識別子属性として利用される。
【０１３５】
（５）履歴付きＳＧＭＬ文書の出力
図１８および図１９は，ＳＧＭＬ文書本体に要素識別子などの情報を埋め込む場合の履歴付きＳＧＭＬ文書のＤＴＤの例を示す図である。ここで，他の文書の要素を取り込んでいる部分などについては，履歴付きＳＧＭＬ文書における要素識別子・改訂番号として本装置で管理しているものに文書識別子を加えたものが用いられる。
【０１３６】
ＳＧＭＬ文書本体に要素識別子などを埋め込めない場合には，ＳＧＭＬ文書本体を外部エンティティとして定義し，ＥＳＤｄｏｃの部分にＨｙＴｉｍｅのｐａｔｈｌｏｃを使ったロケーションラダーによってＳＧＭＬ文書本体の要素に要素識別子などの属性を対応付けるなどの手段によって，同様の情報をＳＧＭＬ文書として表現できる。
【０１３７】
図２０ないし図２７は，ＳＧＭＬ文書編集装置１０の文書編集処理のフローチャートである。特に図２０および図２１は，全体の処理の流れを示している。
図２０のステップＳ９１では，サーバから，あるいはローカルファイルから編集対象の文書部分木を獲得する。ここで，依存関係にある文書編集装置も同時に起動される。
【０１３８】
ステップＳ９２では，ユーザの要求または別の文書編集装置からのメッセージ（同期要求）を待つ。
ステップＳ９３では，同期要求かどうかを判定し，同期要求であればステップＳ１０７の処理へ進み，同期要求でなければステップＳ９４の処理へ進む。
【０１３９】
ステップＳ９４では，ユーザの要求を判定し，ユーザの要求が構造編集要求であればステップＳ９５の処理へ進み，ユーザの要求が内容編集要求であればステップＳ９６の処理へ進み，ユーザの要求が終了またはチェックイン要求であればステップＳ９８の処理へ進む。
【０１４０】
ステップＳ９５では，後述する構造編集処理を行う。
ステップＳ９６では，編集可能要素かどうかを判定し，編集可能要素であればステップＳ９７の処理へ進み，編集可能要素でなければステップＳ９２の処理へ戻る。
【０１４１】
ステップＳ９７では，内容編集を行う。
ステップＳ９８では，別の文書編集装置と依存関係があるかどうかを判定し，依存関係がある場合にはステップＳ９９の処理へ進み，依存関係がない場合にはステップＳ１０４の処理へ進む。
【０１４２】
ステップＳ９９では，直接の依存関係にある文書編集装置に通知して依存関係にある全ての文書編集装置の識別子リストを獲得する。なお，重複するものは取り除く。
【０１４３】
ステップＳ１００では，依存関係にあるものを表示して全てに対して処理を行うことを確認する。
ステップＳ１０１では，処理するかどうかを判定する。処理する場合にはステップＳ１０２の処理へ進み，処理しない場合にはステップＳ１０３の処理へ進む。
【０１４４】
ステップＳ１０２では，依存関係にある装置に処理実行を要求し，ステップＳ１０４の処理へ進む。
ステップＳ１０３では，予約解除を行い，ステップＳ９２の処理へ戻る。
【０１４５】
ステップＳ１０４では，要求が何であるかを判定し，要求がチェックイン要求の場合にはステップＳ１０５の処理へ進み，要求が終了要求の場合には，ステップＳ１０６の処理へ進む。
【０１４６】
ステップＳ１０５では，後述するチェックイン処理を行い，ステップＳ９２の処理へ戻る。
ステップＳ１０６では，後述する終了処理を行う。
【０１４７】
ステップＳ１０７では，同期要求が何であるかを判定し，同期要求が終了またはチェックイン要求の場合にはステップＳ１０８の処理へ進み，同期要求が依存関係獲得要求（兼同期処理予約）の場合にはステップＳ１０９（図２１）の処理へ進む。
【０１４８】
ステップＳ１０８では，予約解除またはエラー処理を行い，ステップＳ１０４の処理へ進む。
図２１のステップＳ１０９では，処理予約がされているかどうかを判定し，処理予約がされている場合にはステップＳ１１３の処理へ進み，処理予約がされていない場合にはステップＳ１１０の処理へ進む。
【０１４９】
ステップＳ１１０では，同期処理予約として，要求元の識別子を記憶し，他からの処理の受け付けを停止する。
ステップＳ１１１では，依存関係にある他の文書編集装置に要求元の識別子と同期要求とを転送し依存関係にある文書編集装置の識別子リストを得る。
【０１５０】
ステップＳ１１２では，文書編集装置の識別子リストに自身の識別子を加え，要求送信元に返す。
ステップＳ１１３では，要求送信元に空の文書編集装置識別子リストを返す。なお，要求送信元では，識別子が予約と異なる場合にはエラー処理を行うことになる。
【０１５１】
ステップＳ１１４では，別の文書編集装置（同期予約主）からのメッセージ（同期要求）を待つ。その後，ステップＳ１０７の処理へ戻る。
図２２は，図２０におけるステップＳ９５の構造編集処理のフローチャートである。
【０１５２】
ステップＳ１２１では，ユーザの要求が何であるかを判定し，新規作成要求の場合にはステップＳ１２２の処理へ進み，張り付け（ペースト）要求の場合にはステップＳ１２７の処理へ進み，複写（コピー）／切り取り（カット）要求の場合にはステップＳ１３１の処理へ進み，削除要求の場合にはステップＳ１３５の処理へ進む。
【０１５３】
ステップＳ１２２では，新規要素を作成する位置は編集可能領域かどうかを判定し，編集可能領域であればステップＳ１２３の処理へ進み，編集可能領域でなければ処理を終了する。
【０１５４】
ステップＳ１２３では，ユーザに要素種別の指定を促す。
ステップＳ１２４では，仮の要素識別子を生成し，新規要素を作成する。
ステップＳ１２５では，親要素の文書識別子と要素識別子を新規要素の属性（ｄｏｃ，ｐｉｄ）に設定する。
【０１５５】
ステップＳ１２６では，新規作成した要素を処理中の文書木に追加し，処理を終了する。
ステップＳ１２７では，張り付ける位置は編集可能領域かどうかを判定し，編集可能領域であればステップＳ１２８の処理へ進み，編集可能領域でなければ処理を終了する。
【０１５６】
ステップＳ１２８では，張り付ける要素が登録されたレジスタがあるかどうかを判定し，登録されたレジスタがある場合にはステップＳ１２９の処理へ進み，登録れたレジスタがない場合には処理を終了する。
【０１５７】
ステップＳ１２９では，張り付け元のレジスタの選択を促す。
ステップＳ１３０では，後述する張り付け処理を行い，処理を終了する。
ステップＳ１３１では，切り取り要求か複写要求かを判定し，切り取り要求であればステップＳ１３２の処理へ進み，複写要求であればステップＳ１３４の処理へ進む。
【０１５８】
ステップＳ１３２では，切り取る位置は編集可能領域かどうかを判定し，編集可能領域であればステップＳ１３３の処理へ進み，編集可能領域でなければ処理を終了する。
【０１５９】
ステップＳ１３３では，後述する要素削除処理を行う。すなわち，指定された要素を削除リストにつなぎ，指定された要素の親要素の要素削除情報を更新する。
【０１６０】
ステップＳ１３４では，指定要素と親要素の識別子，複写／切り取りの種別をレジスタに登録する。その後，処理を終了する。
ステップＳ１３５では，削除する位置は編集可能領域かどうかを判定し，編集可能領域であればステップＳ１３６の処理へ進み，編集可能領域でなければ処理を終了する。
【０１６１】
ステップＳ１３６では，後述する要素削除処理を行う。
図２３および図２４は，図２２におけるステップＳ１３０の張り付け処理のフローチャートである。
【０１６２】
図２３のステップＳ１４１では，レジスタの要素種別を判定し，要素種別が複写の場合にはステップＳ１４２の処理へ進み，要素種別が切り取りの場合にはステップＳ１５４の処理へ進む。
【０１６３】
ステップＳ１４２では，複写する要素の変更モードの選択をユーザに促す。
ステップＳ１４３では，変更モードを判定し，変更モードが共有モードまたはリンクモードの場合にはステップＳ１４４の処理へ進み，変更モードが独立モードの場合にはステップＳ１５２の処理へ進む。
【０１６４】
ステップＳ１４４では，仮の要素識別子を生成する。
ステップＳ１４５では，レジスタの要素のコピーを作り，生成した要素識別子を設定する。
【０１６５】
ステップＳ１４６では，コピー要素のコピー元属性（ｃｏｐｙｏｆ）と変更モード属性（ｃｏｐｙｓｔａｔ）に，レジスタ要素のインスタンス識別子と変更モードとをそれぞれ設定する。
【０１６６】
ステップＳ１４７では，コピーした要素のコピー要素リスト属性（ｃｏｐｉｅｄ．ｔｏ）と，リンク要素リスト属性（ｌｉｎｋｅｄ．ｗｉｔｈ），派生要素リスト属性（ｄｅｒｉｖａｔｉｏｎｓ）をクリアする。
【０１６７】
ステップＳ１４８では，レジスタ要素以下の文書部分木に含まれるレジスタ要素以外の要素に対して仮の要素識別子を生成し，元の要素識別子との対応を要素対応表属性（ｌｉｎｋｔｂｌ）に格納する。
【０１６８】
ステップＳ１４９では，変更モードを判定し，変更モードがリンクモードの場合にはステップＳ１５０の処理へ進み，変更モードが共有モードの場合にはステップＳ１５１の処理へ進む。
【０１６９】
ステップＳ１５０では，レジスタ要素のリンク要素リスト属性（ｌｉｎｋｅｄ．ｗｉｔｈ）の末尾にコピーした要素の（仮）インスタンス識別子を追加し，ステップＳ１５３の処理へ進む。
【０１７０】
ステップＳ１５１では，レジスタ要素のコピー要素リスト属性（ｃｏｐｉｅｄ．ｔｏ）の末尾にコピーした要素の（仮）インスタンス識別子を追加し，ステップＳ１５３の処理へ進む。
【０１７１】
ステップＳ１５２では，レジスタの要素以下の文書部分木を深さ優先に訪れ，行きがけ順にコピーする。すなわち，全ての要素識別子は，仮の識別子を生成して置き換え，コピー元属性には元要素のインスタンス識別子を設定し，変更モード属性は独立モードとする。それぞれのコピー元の要素の派生要素リスト属性（ｄｅｒｉｖａｔｉｏｎｓ）に生成したコピー要素のインスタンス識別子を加える。ただし，部分木内で閉じている共有・リンク関係については，部分木内のリンクに付け替える。
【０１７２】
ステップＳ１５３では，張り付ける要素を処理中の部分木に追加し，処理を終了する。
ステップＳ１５４では，レジスタの要素は処理中の文書とは別の文書であるかどうかを判定する。レジスタの要素が別の文書である場合にはステップＳ１４２の処理へ進み，レジスタの要素が別の文書でない場合にはステップＳ１５５（図２４）の処理へ進む。
【０１７３】
図２４のステップＳ１５５では，レジスタの要素以下の部分木を削除リストから取り除き，張り付ける要素とする。
ステップＳ１５６では，張り付ける要素は新規要素であるかどうかを判定する。張り付ける要素が新規要素である場合にはステップＳ１６３の処理へ進み，張り付ける要素が新規要素でない場合にはステップＳ１５７の処理へ進む。
【０１７４】
ステップＳ１５７では，レジスタ要素の元の親要素の削除要素属性（ｄｅｌｅｔｉｏｎｓ）からレジスタ要素の識別子（文書識別子と要素識別子）を取り除く。
【０１７５】
ステップＳ１５８では，取り除けたかどうかを判定し，レジスタ要素の識別子が取り除けた場合にはステップＳ１５９の処理を行い，レジスタ要素の識別子が取り除けない場合にはステップＳ１６０の処理へ進む。
【０１７６】
ステップＳ１５９では，レジスタ要素の元の親要素の移出要素属性（ｅｘｐｏｒｔｓ）の末尾にレジスタ要素の識別子（文書識別子と要素識別子）を追加する。
【０１７７】
ステップＳ１６０では，張り付け先の親要素の削除要素属性（ｄｅｌｅｔｉｏｎｓ）からレジスタ要素の識別子（文書識別子と要素識別子）を取り除く。
ステップＳ１６１では，取り除けたかどう判定し，レジスタ要素の識別子が取り除けた場合にはステップＳ１６３の処理へ進み，レジスタ要素の識別子が取り除けない場合にはステップＳ１６２の処理へ進む。
【０１７８】
ステップＳ１６２では，張り付け先の親要素の移入要素属性（ｉｍｐｏｒｔｓ）の末尾にレジスタ要素の識別子（文書識別子と要素識別子）を追加する。
ステップＳ１６３では，レジスタの要素種別を複写要素に変更する。その後，ステップＳ１５３の処理へ進む。
【０１７９】
図２５は，図２２におけるステップＳ１３３とステップＳ１３６の要素削除処理のフローチャートである。
ステップＳ１７１では，削除する要素は新規要素かどうかを判定する。削除する要素が新規要素である場合にはステップＳ１７５の処理へ進み，削除する要素が新規要素でない場合にはステップＳ１７２の処理へ進む。
【０１８０】
ステップＳ１７２では，削除要素の元の親要素の移入要素属性（ｉｍｐｏｒｔｓ）から削除要素の識別子（文書識別子と要素識別子）を取り除く。
ステップＳ１７３では，削除要素の識別子が取り除けたかどうかを判定し，取り除けた場合にはステップＳ１７４の処理へ進み，取り除けなかった場合にはステップＳ１７５の処理へ進む。
【０１８１】
ステップＳ１７４では，削除要素の元の親要素の削除要素属性（ｄｅｌｅｔｉｏｎｓ）の末尾に削除要素の識別子（文書識別子と要素識別子）を追加する。
ステップＳ１７５では，削除要素以下の文書の部分木を削除リストにつなぎ，処理を終了する。
【０１８２】
図２６は，図２０におけるステップＳ１０５のチェックイン処理のフローチャートである。
ステップＳ１８１では，ＳＧＭＬパーサで編集結果が部分編集用ＤＴＤに適合しているかどうかを検証する。
【０１８３】
ステップＳ１８２では，同期要求による処理かどうかを判定する。同期要求による処理の場合にはステップＳ１８３の処理へ進み，同期要求によらない処理の場合にはステップＳ１８７の処理へ進む。
【０１８４】
ステップＳ１８３では，処理中の文書はＤＴＤに適合しているかどうかを判定し，適合していない場合にはステップＳ１８４の処理へ進み，適合している場合にはステップＳ１８５の処理へ進む。
【０１８５】
ステップＳ１８４では，文書が不完全であることを要求元に通知し，処理を終了する。
ステップＳ１８５では，要求元の識別子と編集結果をサーバに送信し，（同期）チェックインする。
【０１８６】
ステップＳ１８６では，チェックイン結果を要求元に通知し，処理を終了する。
ステップＳ１８７では，処理中の文書または同期チェックインする文書はＤＴＤに適合しているかどうかを判定する。ＤＴＤに適合している場合にはステップＳ１８８の処理へ進み，ＤＴＤに適合していない場合にはステップＳ１９２の処理へ進む。
【０１８７】
ステップＳ１８８では，削除リストの先頭の文書要素を削除要素として取り出す。
ステップＳ１８９では，処理中の文書の識別子と編集結果をサーバに送信し，チェックインする。
【０１８８】
ステップＳ１９０では，チェックインが成功したかどうかを判定し，チェックインが成功である場合にはステップＳ１９４の処理へ進み，チェックインが不成功の場合にはステップＳ１９１の処理へ進む。
【０１８９】
ステップＳ１９１では，チェックイン失敗とその理由をユーザに示し，ステップＳ１９４の処理へ進む。
ステップＳ１９２では，処理中の文書識別子と同期チェックインの解除を通知する。
【０１９０】
ステップＳ１９３では，不完全な文書の部分をユーザに示す。
ステップＳ１９４では，依存関係にある文書装置に同期予約解除を通知し，処理を終了する。
【０１９１】
図２７は，図２０におけるステップＳ１０６の終了処理のフローチャートである。
ステップＳ２０１では，処理中の文書のＤＴＤと文書本体を（文書）ファイルに出力する。
【０１９２】
ステップＳ２０２では，文書ファイル名，レジスタの削除リストの内容を（管理）ファイルに出力する。
ステップＳ２０３では，同期要求による処理かどうかを判定する。同期要求による処理の場合にはステップＳ２０４の処理へ進み，同期要求によらない処理の場合にはステップＳ２０５の処理へ進む。
【０１９３】
ステップＳ２０４では，文書ファイル名を要求元へ通知し処理を終了する。
ステップＳ２０５では，依存関係にある文書ファイルのリストを（管理）ファイルに出力し，処理を終了する。
【０１９４】
以上の実施の形態による作用を，以下に説明する。
１）効率よく文書の取リ出しと格納ができる。
ＳＧＭＬ文書を要素単位でデータベース（ＤＢ）に格納している場合，要素毎に取り出しのコストがかかるので，編集の際に取り出す要素数はなるべく少ないほうが望ましい。可変個要素に関する挿入・分割を判定するためには，内容モデルと実際のエレメントをルート文書要素からデプスファーストに対応付ける必要がある。
【０１９５】
正しいＤＴＤには，モデル要素と実際の文書要素の対応に暖昧性がないので，すでに適合を確かめられたＳＧＭＬ文書なら，下位要素および後続要素に関するＤＴＤとの適合検査は省略できる。この場合でも，少なくとも編集しようとしている文書要素から文書のルートにいたるパスに含まれる文書要素およびそれより前に出現している文書要素についての照合を行う必要がある。
【０１９６】
本発明によれば，内容モデルに下位要素のインスタンス識別子および可変要素のある時点における削除・挿入の可否の指標を加えた拡張内容モデルを作成し，各々の要素と対応付けて格納してあるので，直接の上位要素編集対象となる要素群（ただし，下位要素が既に編集中の場合は例外であり，その要素以下のレベルの要素も取り出されるが，編集対象とはならない）を取り出すだけでよく（正確には，これ以外に後述のアクセス制御と履歴管理のために直接の上位の要索に対応する情報も取り出す必要がある），アクセス効率が向上する。
【０１９７】
また，本発明ではＳＧＭＬ文書自体の情報の他に管理用として拡張内容モデルなどを格納するが，スペース効率の悪化は小さく抑えられている。文書要素単位に格納する場合に上位・下位の要素へのリンク情報は必須であり，実際の文書には出現していない可変個要素や例外要素部分を加えても，タグ情報が３倍に増える程度である。また，格納された文書要素のリンク付けに用いられるインスタンス識別子は，ＳＧＭＬの文書内の参照のための属性値としても利用可能であり，このように利用するならスペース効率は向上できる。
【０１９８】
２）部分編集の自由度が向上する。
本発明のチェックアウト時の削除・追加予約の手段により，ＳＧＭＬ文書を部分的に編集する際に，編集対象の最上位レベルでタグの変更や要素の分割・追加・削除など従来は不可能だった編集が可能になる。
【０１９９】
３）編集の独立性が高まる。
本発明では，部分編集用ＤＴＤによりＳＧＭＬ文書編集装置１０だけで編集中の部分の整合チェックが可能である。このため，部分編集中にＳＧＭＬ文書を管理するサーバに全くアクセスする必要がなくなり，部分編集を例えばオフライン形態のパーソナル・コンピュータなどでも行えるようになるなど，編集の独立性が高まる。
【０２００】
４）文書構造変化の履歴が保持できる。
拡張内容モデルと親要素の遷移を保持することで，文書要素レベルでの追加・削除・移動の履歴を追跡することが可能となる。
【０２０１】
５）ＳＧＭＬ文書の更新履歴付きで流通が可能となる。
ＳＧＭＬに準拠した形式で履歴情報についても出力する機構によって，履歴付きでＳＧＭＬ文書を異なる装置間で交換することが可能になる。
【０２０２】
６）ＤＴＤ変更時などの安全性が向上する。
拡張内容モデルにより，ＤＴＤを復元することができるので，ＤＴＤの改訂や不慮の事故によりＤＴＤが使用不能になっても，格納されたＳＧＭＬ文書を利用可能である。
【０２０３】
【発明の効果】
以上説明したように，本発明は以下の効果を奏する。
１）編集作業の独立性が高まり，作業効率が向上する。
【０２０４】
本発明では，上位文書要素および前後の文書要素を編集可能にしたままで，ＤＴＤに違反しない範囲において，編集中の最上位の文書要素の削除とタグの変更およびその前後に新たな文書要素を追加することが可能であるので，担当する章を分割する場合などにＳＧＭＬ文書全体を管理している装置にアクセスし直す必要が減少する。
【０２０５】
また，部分編集文書は，生成された部分編集用ＤＴＤで独立に整合検査が可能であるため，一旦編集対象部分を取り出した後はチェックインまで，ＳＧＭＬ文書全体を管理している装置にアクセスすることなく編集を進めることが可能である。
【０２０６】
このような部分編集の独立性が確保されるので，ＳＧＭＬ文書本体を管理するサーバのアクセスに伴う編集作業の停滞が少なくなり，また，オフラインの形態のコンピュータで編集も可能になるなど作業環境の選択範囲も広がり，共同編集における作業効率を向上させることができる。
【０２０７】
２）文書の再利用が容易になり文書作成・改訂の効率が向上する。
本発明では，文書の内容・構造の変化の履歴をとりつつ，また，他の文書や版の部分を別の文書に取り込んで作成管理することができる。これにより，異なる版が同時に流通している製品や，一部の機能のみ違う製品群のマニュアルの作成管理などにおいて，文書作成・改訂の効率を向上させることができる。
【図面の簡単な説明】
【図１】  本発明のブロック構成図である。
【図２】  データの基本構造および履歴情報との対応関係を示す図である。
【図３】  ＳＧＭＬ文書の原文書の例を示す図である。
【図４】  ＳＧＭＬ文書の格納例を示す図である。
【図５】  拡張内容モデルの構成例を示す図である。
【図６】  部分編集用ＤＴＤの生成の例を示す図である。
【図７】  追加可能な要素の判定の例を説明する図である。
【図８】  追加予約の例を説明する図である。
【図９】  削除予約の例を説明する図である。
【図１０】  最上位要素のタグ変更の例を説明する図である。
【図１１】  クライアントが文書の編集部分を獲得するための処理のフローチャート（１）である。
【図１２】クライアントが文書の編集部分を獲得するための処理のフローチャート（２）である。
【図１３】部分編集用ＤＴＤと編集データを提供する処理のフローチャート（１）である。
【図１４】部分編集用ＤＴＤと編集データを提供する処理のフローチャート（２）である。
【図１５】拡張内容モデルを利用した部分編集用内容モデルおよび追加・削除候補要素リストの作成処理のフローチャート（１）である。
【図１６】拡張内容モデルを利用した部分編集用内容モデルおよび追加・削除候補要素リストの作成処理のフローチャート（２）である。
【図１７】改訂履歴の作成の例を説明する図である。
【図１８】履歴付きＳＧＭＬ文書のＤＴＤの例（１）を示す図である。
【図１９】履歴付きＳＧＭＬ文書のＤＴＤの例（２）を示す図である。
【図２０】  文書編集処理のフローチャート（１）である。
【図２１】  文書編集処理のフローチャート（２）である。
【図２２】構造編集処理のフローチャートである。
【図２３】張り付け処理のフローチャート（１）である。
【図２４】張り付け処理のフローチャート（２）である。
【図２５】要素削除処理のフローチャートである。
【図２６】チェックイン処理のフローチャートである。
【図２７】終了処理のフローチャートである。
【符号の説明】
１  ＳＧＭＬ文書管理装置
１０  ＳＧＭＬ文書編集装置
１１  部分編集用ＤＴＤ整合性検査手段
１２  履歴作成手段
２０  ＳＧＭＬ文書交換装置
３０  ＳＧＭＬ文書アクセス装置
３１  文書形式変換手段
３２  部分編集用ＤＴＤ作成手段
３３  文書形式整合性検査手段
３４  履歴管理手段
４０  データベース
５０，５０’  ＳＧＭＬパーサ
【図１】
0003831085.tif 000003
【図２】
0003831085.tif 000004
【図３】
0003831085.tif 000005
【図４】
0003831085.tif 000006
【図５】
0003831085.tif 000007
【図６】
0003831085.tif 000008
【図７】
0003831085.tif 000009
【図８】
0003831085.tif 000010
【図９】
0003831085.tif 000011
【図１０】
0003831085.tif 000012
【図１１】
0003831085.tif 000013
【図１２】
0003831085.tif 000014
【図１３】
0003831085.tif 000015
【図１４】
0003831085.tif 000016
【図１５】
0003831085.tif 000017
【図１６】
0003831085.tif 000018
【図１７】
0003831085.tif 000019
【図１８】
0003831085.tif 000020
【図１９】
0003831085.tif 000021
【図２０】
0003831085.tif 000022
【図２１】
0003831085.tif 000023
【図２２】
0003831085.tif 000024
【図２３】
0003831085.tif 000025
【図２４】
0003831085.tif 000026
【図２５】
0003831085.tif 000027
【図２６】
0003831085.tif 000028
【図２７】
0003831085.tif 000029