JPH10143507A - Ｓｇｍｌ文書管理装置，サーバ装置，クライアント装置およびそれらのプログラム記憶媒体 - Google Patents

Abstract

(57)【要約】 【課題】ＳＧＭＬ文書を格納・管理するＳＧＭＬ文書管
理装置に関し，共同執筆等の際に部分編集の独立性を高
め，さらに，構造変化を含む改訂履歴を装置依存性の少
ない形式により管理する。 【解決手段】ＳＧＭＬ文書の部分編集の要求により，Ｓ
ＧＭＬ文書アクセス装置30は，文書本体のＤＴＤの拡張
内容モデルをもとに，ＤＴＤの整合性を保持するための
制約（追加・削除予約）を付加した部分編集用ＤＴＤを
生成する。ＳＧＭＬ文書編集装置10は, 部分編集用ＤＴ
Ｄと文書の対象部分を得て，部分編集用ＤＴＤの制約に
従って編集を行う。編集後，ＳＧＭＬ文書編集装置10
は, 部分編集用ＤＴＤを用いて編集対象部分のみのＳＧ
ＭＬパージングを行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は，マニュアル等の大
規模なＳＧＭＬ（Ｓｔａｎｄａｒｄ Ｇｅｎｅｒａｌｉ
ｚｅｄ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）文書群の共
同執筆・編集，改訂管理などのために用いられるＳＧＭ
Ｌ文書管理装置に関するものである。

【０００２】近年，文書の電子化が進み，大量の文書を
蓄積して再利用することで文書作成のコストを大幅に引
き下げることが可能になってきた。また，一方で，技術
の高度化に伴うマニュアル類のボリュームの増加と多様
化，インターネットに代表される新たな文書流通メディ
アの出現もあいまって，流通・作成・管理すべき文書の
量が爆発的に増加している。必然的に，一度作成した電
子化文書を再利用して，新たな文書として発信していき
たいという要請が強まっている。ＳＧＭＬは，このよう
な要請に応じて登場し，広く使われ始めた文書形式であ
る。

【０００３】ＳＧＭＬ形式は装置依存性が低く，電子デ
ータとしての交換が容易で，また，文書の体裁の切替え
や文書内容の部分的な再利用などが容易であり，同じ内
容の文書を様々な形式で用いることができるという特徴
を持つ。

【０００４】このため，現在は，マニュアルなどの技術
文書の作成管理や計算機支援印刷や電子出版における利
用が最も進んでいるが，その他ネットワークによるコミ
ュニケーションや，商取引，電子図書館などのデータベ
ースなど，大規模で寿命の長い文書を扱う分野で広く使
われ出している。例えば，近年爆発的な勢いで拡大して
いるインターネットにおいて使われているＨＴＭＬ文書
も，ＳＧＭＬ形式の一種であり，電子図書館における図
書や目録などの蓄積・管理もＳＧＭＬ形式によって試み
られている。

【０００５】このようにＳＧＭＬ形式の文書が広く，そ
して大規模に使われるようになってきたため，ＳＧＭＬ
文書を管理する装置の必要性が高まっている。ＳＧＭＬ
文書は，大規模で長い寿命を持つことでその特徴が生か
されるという性質をもつことから，これを管理する装置
は，ＳＧＭＬ文書の作成・蓄積・再利用のライフサイク
ルを支援する装置でなければならない。また，ＳＧＭＬ
文書はその構造が文書型定義（ＤＴＤ：Ｄｏｃｕｍｅｎ
ｔ Ｔｙｐｅ Ｄｅｆｉｎｉｔｉｏｎ）中の定義に適合
していなくてはならないので，ＳＧＭＬ文書管理装置に
は文書構造の整合性の管理機構も必要である。

【０００６】本発明は，このようなＳＧＭＬ文書管理装
置において，文書構造の整合性の管理および文書構造の
改訂履歴管理のための機構に特徴をもつものである。

【０００７】

【従来の技術】

（１）文書の共同編集における文書全体の整合を維持す
る技術 大量の文書の作成には，既存文書の再利用と多人数で共
同執筆・編集を行なえる環境が必要である。ＳＧＭＬ文
書の管理装置としては，文書全体としての整合性を保ち
つつ，文書の部分部分を独立して編集可能とする機構が
必要となる。

【０００８】個別の作業が正しく行なわれても，並行し
て進んでいた別の作業の影響で整合がとれなくなること
がある。こうなると，作業結果を破棄して改めて更新し
なおすか，整合のとれなかった部分を修正しない限り，
元の文書には反映できないため（不整合のまま作業結果
を反映すると他のＳＧＭＬアプリケーションで使用でき
なくなる），作業効率が阻害される。

【０００９】このような事態を避けるために，従来の構
造化文書管理装置では，文書の共同編集作業の場合，文
書のある部分について，別の作業者に更新させないよう
に読み出しのみ可（ｒｅａｄ−ｏｎｌｙ）にする等によ
りチェックアウトし，作業終了後にチェックインしてｒ
ｅａｄ−ｏｎｌｙを解除するというようなチェックアウ
ト／チェックイン機構を用意して対処してきた。この場
合，一般に，作業者が更新可能なのはチェックアウトし
た部分に含まれる内容だけである。

【００１０】従来のＳＧＭＬ文書管理装置においても基
本的機構は同様であり，文書要素の単位でチェックアウ
ト／チェックイン機構を用い，チェックアウトした文書
要素の下位構造部分だけを更新可能とし，チェックイン
の際に文書全体のＤＴＤとの適合性を検査（これをＳＧ
ＭＬパージングという）することで文書の整合性を維持
していた。

【００１１】（２）ＳＧＭＬ文書のパージングを効率的
に行う技術 部分的に更新したＳＧＭＬ文書がＤＴＤに適合している
かを検査（ＳＧＭＬパージング）するためには，基本的
には，更新部分以外の文書要素も含めて文書全体にどの
ような文書要素が配置されているかを調べなくてはなら
ない。すなわち，ルート文書要素から各文書要素を順次
ＤＴＤと対応付けていく必要がある。このとき，ＳＧＭ
Ｌ文書を文書要素単位で格納して前述のチェックアウト
／チェックイン機構で部分編集を行う文書管理装置で
は，編集要素以外の部分の文書要素のタグ（ＧＩ：Ｇｅ
ｎｅｒｉｃ Ｉｄｅｎｔｉｆｉｅｒ；総称識別子）情報
を，文書を格納しているデータベースから取り出す必要
がある。なお，総称識別子（ＧＩ）とは，文書要素のタ
イプを示す名前であり，ＤＴＤは，この配置の仕方を階
層ごとに内容モデル（ｃｏｎｔｅｎｔ ｍｏｄｅｌ）で
定義する。

【００１２】これを単純に行うと，少なくとも編集しよ
うとしている文書要素から文書のルートにいたるパスに
含まれる文書要素およびそれらより前に出現している文
書要素（文書中で先行する文書要素）のタグを取り出し
て照合を行う必要があり，文書を格納しているデータベ
ースへのアクセスコストが大きくなる。そこで，従来の
技術では，文書構造を文書内容とは別に格納したり，各
々の文書要素にその先行文書要素のタグ列を対応付けて
格納するなどの工夫により，ＳＧＭＬパージングのコス
ト軽減を図っているものもある。

【００１３】（３）ＳＧＭＬ文書の改訂履歴管理技術 ＳＧＭＬ文書の改訂履歴の管理についてみると，ＳＧＭ
Ｌのような構造化文書を管理する技術は未成熟であり，
構造の変化を改訂履歴として保持する技術は確立されて
いない。一般的には，文書要素レベルで細かく改訂履歴
を管理する方法においても，改訂前の文書要素や改訂に
よる差分を個別に保持するだけで，文書要素の配置の変
化などの構造の履歴は保持していない。また，文書要素
個別の履歴としては保持できない構造変化の履歴も管理
するものとして，例えば特開平６−２５０８９５号公報
に示されているような「構造化データベースシステム」
があるが，装置に依存した内部表現形式によるものしか
存在せず，履歴情報付きでＳＧＭＬ文書を自由に流通で
きるものとはなっていない。

【００１４】

【発明が解決しようとする課題】本発明が解決しようと
する問題点は，以下の２点である。 １）文書更新上の制約が不要に大きいという問題 共同編集において個々の作業の独立性を高めつつ文書全
体の整合性を保つことが必要であるが，従来の技術では
文書全体の整合性を保つことを優先していて，個々の作
業の独立性が低くなっている。

【００１５】従来の技術では，チェックアウトした文書
要素の内容，すなわちその文書要素の下部構造と記述さ
れている情報内容のみを編集可能としている。このた
め，チェックアウトした文書要素のタイプを表すタグの
変更やそれ自体の分割や削除などは禁止されている。本
質的に同時編集が不可能なのはＤＴＤ上で依存関係にあ
る部分であり，ＤＴＤによってはタグの変更や要素の分
割・削除などは他の編集とは独立して行える場合がある
ので，このような制約は必要以上に大きいものといえ
る。

【００１６】このような事情により，例えば，章のレベ
ルで分担して執筆中にその章の分割が必要になった場
合，いったん編集を打ち切って１つ上位の文書要素レベ
ルから編集をやり直す必要が生じる。作業途中でこのよ
うな中断がおきると，執筆者の思考の流れを阻害するだ
けでなく，上位文書要素レベルがその時点で更新不能で
あったり，分散環境で実行している場合には，その時点
では文書本体へ物理的にアクセス不能であった，などの
理由で作業を進められなくなる事態があり得，作業の進
行の妨げとなる。

【００１７】章の分割のような編集にうまく対応できな
いのは，チェックアウトする要素と周辺の要素との依存
関係に応じて，部分編集に適切な制約を施す機構がない
ためである。

【００１８】つまり，章の分割のような編集を可能にす
るためには，編集前の文書構造におけるチェックアウト
する要素に関する依存関係を把握し，この依存関係に沿
って編集に制約をかける必要がある。

【００１９】ＳＧＭＬ文書は木構造であり，深さの異な
る文書要素は親子関係にない限り依存しないが，同じ文
書要素インスタンスを親とする姉妹文書要素インスタン
スは文書型定義によっては依存しあう場合がある。この
ため，編集の整合性を保証するには，姉妹関係の依存性
を予め把握しておかなければならない。例えば，ＤＴＤ
でいくつ出現してもよいように定義されている文書要素
を編集する場合，その要素を同じタイプの要素に分割す
ることや，削除することは可能であるが，必ず１つだけ
出現しなくてはならないように定義されている要素につ
いてはこのような編集を行うことはできない。

【００２０】また，連続して１つ以上出現しなくてはな
らない文書要素を削除できるかどうかは，そのタグをも
つ要素が実際の文書にいくつあって，そのうちで別の作
業により削除されるかもしれない要素（他で編集中の要
素）がいくつあるのかを把握しないと判定できない。例
えば， <!ELEMENT PART (SECT)+ > <!--PART は１つ以上のSECT
からなる--> <PART id=p1> <SECT id=s1>最初の章</SECT> <SECT id=s2>次の章</SECT> </PART> という文書構造の例では，ｉｄ＝ｓｌ，ｉｄ＝ｓ２の文
書要素のいずれか１つのみ削除可能である。

【００２１】このような制約はＤＴＤだけでなく，並行
して実行されている別の編集の結果にも依存するので，
従来の技術のように，ＳＧＭＬ文書全体の文書型定義を
そのまま編集の制約として用いて，更新結果をとりこん
だ文書の形式を検査（ＳＧＭＬパージング）するだけで
は取り扱うことができない。すなわち，ＳＧＭＬパージ
ングでは，別の編集制約機構を用意するか，部分編集用
に別のＤＴＤを用意することが必要となる。

【００２２】本発明は，この点に関して，文書全体の文
書型定義に編集前の実際の文書構造とその編集状況によ
る制約を加味した，文書の部分に対する部分構造の文書
型定義を自動生成して，解決を図るものである。

【００２３】２）文書の構造変化の履歴が不十分である
という問題 もう一つの問題点は，ＳＧＭＬ文書の構造の変化の履歴
が十分に保持されないことである。従来の一般的な履歴
管理は，個々の文書要素の遷移として個別に保持してい
るため，単独の文書要素には記述することのできない移
動・交換などの構造変化の履歴を正確に格納できない。

【００２４】例えば，文書要素の分割は，文書要素内の
一部削除と新文書要素の追加として，また，文書要素の
交換は，２組の削除と追加との操作として解釈するか，
あるいは，更新前と更新後の変化から推定して処理して
いるのが現状である。このため，結果の文書としては正
しく処理したものと等価であるが，分割・交換などの更
新履歴の信頼性が低くなっている。

【００２５】このような構造変化の履歴も管理する装置
（例えば特開平６−２５０８９５号公報）もあるが，管
理されている情報は装置に依存するものであるため，Ｓ
ＧＭＬ文書を履歴情報付きで自由に流通できるものとは
なっていない。

【００２６】本発明は，上記の２つの問題を解決し，共
同執筆・編集の効率化と改訂履歴の機能向上を実現する
と同時に，その実現のために付加する文書管理情報を共
通にして，管理情報の格納効率をあげつつ，また，管理
すべき情報の種類を減らすことで管理効率をも向上させ
ることを目的とする。

【００２７】

【課題を解決するための手段】本発明は，上記課題を解
決するため，ＳＧＭＬ（Ｓｔａｎｄａｒｄ Ｇｅｎｅｒ
ａｌｉｚｅｄ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）文書
を格納し，共同執筆・編集・利用を支援し，改訂などの
履歴を管理するＳＧＭＬ文書管理装置において，例えば
以下の機構を持つことを主要な特徴とする。

【００２８】 ＳＧＭＬ文書を文書要素単位で格納
し，文書要素それぞれに，文書型定義中の文書要素宣言
の内容モデル（ｃｏｎｔｅｎｔ ｍｏｄｅｌ）に対して
それに適合している子文書要素のインスタンス識別子を
付与した拡張内容モデルを対応付けて管理する機構 ＳＧＭＬ文書の編集中の部分に対応する部分編集用
文書型定義を一時的に生成することにより，該当部分の
み独立にＳＧＭＬパージング可能とする機構 上位文書要素および前後の文書要素を編集可能にし
たままで，部分編集用文書型定義に違反しない範囲にお
いて，編集中の最上位の文書要素の削除とタグ（総称識
別子）の変更およびその前後に新たな文書要素を追加す
ることを可能にする機構 文書要素の複写・移動（交換）・追加・削除の履歴
を保持する機構 保持した履歴情報を装置に依存しない形式で出力す
る機構 図１は，以上の機構を実現する本発明のブロック構成図
である。

【００２９】図１において，ＳＧＭＬ文書管理装置１
は，ＳＧＭＬ文書編集装置１０，ＳＧＭＬ文書交換装置
２０，ＳＧＭＬ文書アクセス装置３０，ＳＧＭＬ文書の
データベース４０，ＳＧＭＬパーサ５０，５０’からな
る。

【００３０】本発明がサーバ・クライアント・システム
上で実現される場合には，ＳＧＭＬ文書編集装置１０お
よびＳＧＭＬ文書交換装置２０はクライアント側に備え
られ，ＳＧＭＬ文書アクセス装置３０，データベース４
０，ＳＧＭＬパーサ５０はサーバ側に備えられる。さら
にクライアント側にＳＧＭＬパーサ５０’が備えられて
いてもよい。

【００３１】ＳＧＭＬ文書編集装置１０は，ＳＧＭＬ文
書の編集対象部分をＳＧＭＬ文書アクセス装置３０を通
じて取得し，編集を行う手段である。ＳＧＭＬ文書編集
装置１０は，ＳＧＭＬ文書アクセス装置３０で生成され
た部分編集用ＤＴＤを元に，ＳＧＭＬパーサ５０’を呼
び出すことにより編集結果の整合性を検査する部分編集
用ＤＴＤ整合性検査手段１１と，文書要素の内容および
拡張内容モデルの変更を記憶し，編集対象部分の内容・
構造の変更履歴を生成する履歴作成手段１２を持つ。

【００３２】ＳＧＭＬ文書交換装置２０は，外部のＳＧ
ＭＬ文書または履歴付きＳＧＭＬ文書の入力・出力を行
う手段である。これには，本装置内で用いる標準的な拡
張モデル付きＳＧＭＬ文書形式と履歴情報のないＳＧＭ
Ｌ文書形式あるいは履歴情報を分離した履歴つきＳＧＭ
Ｌ文書形式との相互変換を行う機能がある。

【００３３】ＳＧＭＬ文書アクセス装置３０は，クライ
アントの要求に従い，データベース４０に格納されたＳ
ＧＭＬ文書の部分または全体の入出力や，部分編集用Ｄ
ＴＤの作成，ＳＧＭＬ文書の版数管理や文書の退避・復
元などを行うものである。

【００３４】ＳＧＭＬ文書アクセス装置３０は，標準的
な拡張モデル付きＳＧＭＬ文書形式とデータベース４０
の内部形式との相互変換を行う文書形式変換手段３１，
部分編集用ＤＴＤを生成する部分編集用ＤＴＤ作成手段
３２，ＳＧＭＬパーサ５０を呼び出すことにより，入力
されたＳＧＭＬ文書の整合性を検査する文書形式整合性
検査手段３３，文書内容や拡張内容モデルの履歴情報を
整理する履歴管理手段３４を持つ。

【００３５】ＳＧＭＬパーサ５０，５０’は，その他の
装置の補助としてＤＴＤとＳＧＭＬ文書本体との対応付
けを行うものである。クライアントのＳＧＭＬパーサ５
０’はサーバのＳＧＭＬパーサ５０と機能的には同じも
ので，サーバ・クライアントが別の計算機である場合，
特にオフライン状態のクライアントで編集中に整合検査
などを行う時にはサーバと物理的に別の装置が利用され
る。

【００３６】以上の各処理手段を計算機によって実現す
るためのプログラムは，計算機が読み取り可能な可搬媒
体メモリ，半導体メモリ，ハードディスクなどの適当な
記憶媒体に格納することができる。

【００３７】

【発明の実施の形態】以下，本発明の実施の形態を説明
する。図２は，本発明におけるデータの基本構造を示す
図である。図中の実線の矢印は識別子による対応関係を
示している。本発明のデータ構成は，文書全体の情報と
文書要素単位の情報に大別される。

【００３８】図２（Ａ）に示す文書全体の情報には，文
書を操作・管理するためのシステム情報や，文書の論理
的な性質を記述するためのプロフィール情報，文書履歴
情報などがある。

【００３９】図２（Ｂ）に示す文書要素単位の情報に
は，文書単位で格納されたそれぞれの情報を関係づけて
文書構造を表現する識別子情報，各々の文書要素がＳＧ
ＭＬとしての情報（属性・タグ・下位情報），要素別の
履歴情報，要素単位にアクセス制御などを行うためのシ
ステム管理情報などがある。

【００４０】文書は，文書要素毎にデータベース４０に
格納され，インスタンス識別子を付与されて管理され
る。インスタンス識別子は，論理的には，（ある版数
の）文書を識別する文書識別子，文書内の文書要素を特
定するための要素識別子の２つから構成される。

【００４１】文書識別子は，ある文書のある（独立し
た）版に対して一意に割り当てられたものである。要素
識別子は，ある文書における実際の文書要素（インスタ
ンス）に対して一意に割り当てられたもので，ＳＧＭＬ
文書における文書内のＩＤ参照の機能に対応が可能なも
のである。

【００４２】また，改訂された各要素には改訂前の要素
（列）がインスタンス識別子と改訂番号によって対応付
けられている。改訂番号は，ある文書のある版としての
改訂作業に対して一意に与えられた改訂の順序も表現し
た識別値で，具体的にはチェックインの際にシステムが
付与するものである。

【００４３】格納された要素は，インスタンス識別子を
介してリンクされ，ＳＧＭＬ文書構造を形成する。ＳＧ
ＭＬ文書構造を示すリンクは，ＤＴＤ中の内容モデルと
対応付けて拡張内容モデルとして格納され，構造の改訂
履歴管理や部分編集の独立性の判定にも利用されてい
る。拡張内容モデルは，内容モデルに，実際のＳＧＭＬ
文書の要素との対応関係（インスタンス識別子）とその
要素の削除可能性指示子（削除可能数）を付与したもの
である。

【００４４】まず，図３および図４を用いて，本装置に
よるＳＧＭＬ文書の格納の例を説明する。図３および図
４では，図２に示した格納情報のうち構造に関わる部分
などの主要部分のみを示している。図３に示すＳＧＭＬ
文書の原文書は，ＳＧＭＬ文書交換装置２０によって内
部表現へ変換され，ＳＧＭＬ文書アクセス装置３０を通
じて，図４のような構成のデータとしてデータベース４
０に格納される。

【００４５】図３に示すＳＧＭＬ文書において，「＜
＞」は，タグを表す。このＳＧＭＬ文書の原文書は，２
つの章（ＳＥＣＴ）からなり，第１の章には２つの節
（Ｐ），次の章（ＳＥＣＴ）には１つの節（Ｐ）を持つ
構造になっている。

【００４６】図５は，前記の拡張内容モデルの構成を本
明細書で表現する形式に従ってバッカス記法（ＢＮＦ）
で示した図である。ただし，このＢＮＦでは，表現が煩
雑になることを避けるため，各構成単位の間の空白要素
の有無は示していない。

【００４７】なお，内容モデルにＡＮＹや＃ＰＣＤＡＴ
Ａを含んでいて実際の文書にさらなる下部構造が表れる
場合には，その下部構造単位での格納・管理，下部構造
を無視した格納・管理など，下部構造の管理レベルを選
択することができる。つまり，強調語句などは管理単位
とせず，文や段落などの上位要素のレベルまでを単位と
して格納・管理することも可能である。

【００４８】また，他文書中のある改訂状態の要素（部
分木）を取り込むことも可能である。取り込みのモード
として，元の要素も変更する共有モードと元の要素には
変更を加えない独立モード，変更自体を許さないリンク
モードがある。

【００４９】共有モード・リンクモードの時には，リン
ク用の特別な文書要素を介して，取り込み先から取り込
んだ要素の実体へ対応付けられる。リンク用の文書要素
には，取り込む部分木の最上位要素のインスタンス議別
子と改訂番号および下位要素の要素識別子の対応表など
が共有情報として格納され，下位情報は記述されない。
要素識別子の対応表は，取り込んだ文書内の別の部分か
らのＩＤ参照を実現するために使用されるものである。
独立モードの時には，取り込む部分内の各要素はコピー
され，履歴情報で元の要素と対応付けられる。

【００５０】〔１〕部分編集用ＤＴＤ 本発明では，文書の要素あるいは親要素が共通の連続す
る文書列を対象に編集することができる。この際，編集
中の部分の整合性を独立して検査（ＳＧＭＬパージン
グ）できるようにするために，ＳＧＭＬ文書アクセス装
置３０は，拡張内容モデルを利用して生成した部分編集
用のＤＴＤを，ＳＧＭＬ文書編集装置１０へ渡すように
している。

【００５１】部分編集用ＤＴＤは，部分編集用に生成し
た一次的な文書型名のＤＴＤであり，全文書用のＤＴＤ
中の宣言に，生成した文書型名の宣言をルート文書要素
の宜言として追加したものである。ルート文書要素の宣
言は，編集対象部分の最上位の文書要素の並びに対応す
る内容モデルの部分を取り出したものを基本にして，追
加予約（後述）に対応した前後の要素の追加可能性と削
除予約（後述）に対応した要素の削除可能性の情報を出
現標識などの形で反映したものである。

【００５２】なお，出現標識としては，「＊，？，＋」
などがあり，「＊」は要素が任意数出現することを示
し，「？」は要素が１つのみ出現するか省略され得るこ
と，すなわち要素が０個か１個であることを示し，
「＋」は要素が１以上出現することを示す。

【００５３】図５は，拡張内容モデルの構成例を示す図
である。拡張内容モデルは，拡張モデル群またはそれと
添加要素，除外要素を含み，拡張モデル群は，拡張モデ
ル列または削除可能モデル群を含む。削除可能モデル群
は，削除可能数，タグもしくはモデル列，出現標識，拡
張モデル列を含む。拡張モデル列は，拡張モデル要素を
含む。拡張モデル要素は，拡張モデル群または拡張要素
である。拡張要素は，タグまたはタグと出現標識に，イ
ンスタンス識別子を付与したものである。

【００５４】この拡張内容モデルは，部分編集用ＤＴＤ
を生成する上で必須ではないが，編集部分の最上位要素
に関する制約を求める処理を高速に行うために利用され
る。すなわち，拡張内容モデルを保持することで，編集
部分の制約を求める処理の編集前の文書要素と内容モデ
ルとを対応付ける部分が，拡張内容モデルを参照するだ
けで行えるようになる。

【００５５】（１）部分編集の独立性を確保する手段 本発明では，ＳＧＭＬ文書の共同執筆などにおいて，並
行して進む部分編集作業の競合を避けるために，編集対
象要素のチェックアウト／チェックインをべースにした
排他制御を行う。これは，編集対象要素のチェックアウ
ト機構と，出現数に制約のある可変個要素（内容モデル
中で出現標識が付与された要素）に関して削除予約・追
加予約機構を用意して実現する。可変個要素と添付要素
は，ＳＧＭＬ文書の同一レベルに（すなわち，ある文書
要素の下位に並んで）出現している他の文書要素とは独
立に追加・削除が可能な場合がある。

【００５６】本発明は，追加・削除の可能性を予め解析
し，追加・削除が可能な場合について，編集要素の前後
に可変個要素または添付要素を挿入することと，編集要
素自体が可変個要素か添付要素である場合の分割と削除
の操作を可能にする。削除予約・追加予約は，これに関
する処理の競合を防ぐものである。

【００５７】また，編集の対象部分の最上位の文書要素
（列）がＯＲ（｜）で連結されたモデル群の要素となっ
ている場合には，それらのタグを変更することも可能で
ある。本発明では，これについても後述の部分編集用Ｄ
ＴＤに該当するモデル群の制約を反映することで，可能
な限り編集対象部分の最上位要素のタグの変更を可能に
している。

【００５８】（２）部分編集用ＤＴＤ生成 図６は，部分編集用ＤＴＤの生成の例を説明する図であ
る。ＳＧＭＬ文書全体は，ＤＯＣという型の文書で，Ｄ
ＯＣはいくつかのＳＥＣＴ（章）からなり，またそれぞ
れのＳＥＣＴはいくつかのＰ（パラグラフ）からなって
いる。ここで，ＳＧＭＬ文書アクセス装置３０は，ユー
ザからの指示に応じて編集対象（１番目のＳＥＣＴ中の
２番目のＰ）を取り出して，元のＤＴＤおよび文書本体
による編集の制約を織り込んだ部分編集用ＤＴＤを生成
して，文書本体と部分編集用ＤＴＤをＳＧＭＬ文書編集
装置１０へと渡す。

【００５９】ＳＧＭＬ文書（全体）のＤＴＤが， <!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)の場合）
は，常に判定結果が「その他」となるように削除可能数
（例えば−１）を設定しておく。

【０１１１】ステップＳ６９では，削除可能モデル群を
削除予約候補要素群として削除予約候補リストに加え
る。ステップＳ７０では，取り出した拡張内容モデルの
先頭に削除可能モデルの先頭要素と'(' を加える。

【０１１２】ステップＳ７１では，部分拡張内容モデル
内の削除可能モデル群について先頭要素だけを残し，さ
らに，先頭の+<削除可能数> を取り除く。ステップＳ７
２では，部分拡張内容モデルからインスタンス識別子を
取り除く。これにより，部分編集用内容モデルが完成す
る。

【０１１３】図１６のステップＳ７３では，指定要素列
の１つ前の要素を取り出す。先頭要素が要素列の区切り
の場合には，その１つ上のレベルで要素（モデル群）を
取り出す。

【０１１４】ステップＳ７４では，要素番号に０を代入
する。ステップＳ７５では，取り出した要素（モデル
群）が何かを判定する。取り出した要素（モデル群）が
インスタンス識別子を含まない省略可能モデルまたは削
除可能モデルであればステップＳ７６の処理へ進み，そ
の他（そのレベルでそれ以上の要素がない場合を含む）
であればステップＳ７９の処理へ進む。

【０１１５】ステップＳ７６では，要素番号から１を引
く。ステップＳ７７では，取り出した要素と要素番号の
組を追加候補要素（群）として追加候補要素リストに追
加する。

【０１１６】ステップＳ７８では，１つ前の要素を取り
出す。その後，ステップＳ７５へ戻り，同様に処理を繰
り返す。ステップＳ７９では，要素番号に０を代入す
る。

【０１１７】ステップＳ８０では，指定要素列の１つ後
ろの要素を取り出す。最終要素が要素列の区切りの場合
には，その１つ上のレベルで要素（モデル群）を取り出
す。ステップＳ８１では，取り出した要素（モデル群）
が何かを判定する。取り出した要素（モデル群）がイン
スタンス識別子を含まない省略可能モデルまたは削除可
能モデルであればステップＳ８２の処理へ進み，その他
（そのレベルでそれ以上の要素がない場合を含む）であ
れば処理を終了する。

【０１１８】ステップＳ８２では，要素番号から１を引
く。ステップＳ８３では，取り出した要素と要素番号の
組を追加候補要素（群）として追加候補要素リストに追
加する。

【０１１９】ステップＳ８４では，１つ後ろの要素を取
り出す。その後，ステップＳ６１の判定を繰り返す。 〔２〕改訂履歴情報 （１）改訂履歴の格納方法 前出の図５に示す拡張内容モデルは，ある文書要素の下
位の要素の並びを完全に表現しているので，その遷移の
情報を文書要素に対応付けて管理することで，ある時点
におけるある文書構造上の位置にいずれの内容があった
のかという履歴情報とすることができる。この情報に文
書要素の直接の上位文書要素が何であったのかという履
歴を加えれば，文書の構造がどのように変化したかを完
全に追跡できる。

【０１２０】すなわち，上位要素から見て下位要素の構
成がどのように変化してきたかは拡張内容モデルの改訂
履歴のみを参照すれば掌握でき，下位要素がどこから移
動してきたかを追跡するためには，改訂前の上位要素の
拡張内容モデルの（該当する改訂レベルの）改訂履歴を
取り出して，その下位要素がいずれの位置にあったかを
調べればよい。

【０１２１】このことを利用して，本発明では，次のよ
うに履歴情報を格納し管理する。履歴情報には，前出の
図２に示すように文書単位に管理されるものと文書要素
単位に管理されるものとがある。文書単位に管理される
履歴情報には，改訂日時，改訂者，改訂部分のシステム
が自動的に設定する情報と，改訂名やコメントなどユー
ザが自由に入力できる情報があり，文書のライフサイク
ルにおける全改訂を順序列として識別する改訂番号を付
与して管理されている。改訂文書単位に管理される履歴
情報は，その改訂に関するマスターデータであり，要素
単位の履歴を高めるために，各文書要素に対応付けてコ
ピーを格納することもできる。

【０１２２】文書要素単位で管理される履歴情報には，
親要素の改訂履歴，拡張内容モデルの改訂履歴，文書内
容の改訂履歴，タグ・属性の改訂履歴，およびコメント
からなる。これらの情報は，基本的には改訂前の該当す
る文書要素へのリンクに改訂番号とコメントと削除・移
入・移出された子文書要素の情報を付与した形で保持さ
れる。

【０１２３】再利用される可能性のない改訂前の要素に
関する履歴情報は，差分の形に直してスペース効率や履
歴の検索効率を高めることもできる。差分で格納する場
合には，改訂番号，コメント，改訂前の親要素の識別
子，改訂前の拡張内容モデルとの差分，改訂前の文書内
容との差分，タグ・属性の改訂前との差分を１単位とす
る列として格納する。

【０１２４】（２）文書構造の改訂履歴の作成手法 文書構造の改訂履歴は，基本的には，ＳＧＭＬ文書アク
セス装置３０において，チェックインの時点で拡張内容
モデルの差分を求めることにより作成される。この差分
を正確に求めるために，ＳＧＭＬ文書アクセス装置３０
は，ＳＧＭＬ文書編集装置１０へ差分を求める手がかり
となる情報を文書要素のＳＧＭＬ属性の形式で渡す。こ
の情報は，その要素および親要素の文書識別子・要素識
別子および改訂番号である。このうち，文書識別子・改
訂番号は別の文書や改訂レベルとの間で文書要素を共有
・交換する際に用いられるもので，通常の編集時には要
素識別子だけが利用される。

【０１２５】専用のＳＧＭＬ文書編集装置１０の操作
は，文書要素の移動・交換・追加・削除などの構造の変
更と，文書要素内のデータの変更，文書要素の属性の変
更に大別されている。このうち構造の変更操作が行われ
た場合には，ＳＧＭＬ文書編集装置１０は，削除された
子の識別子，移出・移入された子文書要素の識別子とそ
の移動先・元の親要素の識別子を，文書要素の属性に加
える。また，要素の追加や複写が発生した場合には，追
加・複写された要素に対して仮の要素識別子を設定す
る。

【０１２６】専用のＳＧＭＬ文書編集装置１０では，あ
る文書の部分として別の文書の要素（部分木）を取り込
むこともできる。この場合，取り込まれた他の文書の親
要素の拡張内容モデルのインスタンス識別子は，文書識
別子と要素識別子の組になる。また，取り込まれた要素
の編集に関する変更モードの省略値が別に付与される。
変更モードは，取り込まれた要素に対する変更を元の要
素へも及ぼすかどうかを区別するものである。これに
は，元の要素も変更する共有モードと元の要素には変更
を加えない独立モード，変更自体を許さないリンクモー
ドがある。共有モードの時には，チェックアウト時に取
り込まれた要素に対応する別の文書の部分も同時にチェ
ックアウトされる。

【０１２７】なお，同一の文書の部分かどうかに関わら
ず，別々にチェックアウトした編集部分の間で文書要素
を交換した場合には，ＳＧＭＬ文書編集装置１０は，強
制的に同期チェックインモードとなる。この場合，ＳＧ
ＭＬ文書アクセス装置３０は，両方の編集結果が正しい
場合に限りチェックインを受理する。ＳＧＭＬ文書アク
セス装置３０で付与された特別の属性を変更しなけれ
ば，一般のＳＧＭＬエディタなどを用いて編集しても，
構造の改訂履歴を作成することが可能である。ただし，
上に述べた別の文書の文書要素の取り込みや，リンクな
どの機能は利用できない。また，複写などが意図通りに
解釈されない場合もあり得る。

【０１２８】（３）改訂履歴の作成例 図１７は改訂履歴の作成例を説明する図である。まず，
図１７（Ａ）に示す編集前のＳＧＭＬ文書本体より点線
で囲まれた部分をＳＧＭＬ文書アクセス装置３０を通じ
て取り出し，文書識別子（ｄｏｃ），要素識別子（ｉ
ｄ），改訂番号（ｖｅｒ），親要素の識別子（ｐｉｄ）
を属性として付与してＳＧＭＬ文書編集装置１０に渡
す。

【０１２９】この例では，ＳＧＭＬ文書編集装置１０に
よる編集操作によって，要素識別子ｐ２の要素をコピー
し，要素識別子ｐｌの要素を要素識別子ｓ２へ移動する
編集を行っている。ここで，要素識別子ｐ２をコピーし
た要素については，仮の要素識別子ｎｅｗ１が付与さ
れ，コピー元の要素を表すｃｏｐｙｏｆ属性と変更モー
ドを示すｃｏｐｙｓｔａｔ（ここでは独立モード）の属
性がＳＧＭＬ文書編集装置１０によって設定される。

【０１３０】編集結果は，ＳＧＭＬ文書アクセス装置３
０を通じて取り込まれ，図１７（Ｂ）に示す編集後の文
書本体がデータベースに格納される。ここで，更新され
た部分には，更新後の要素が作成され，更新前の要素へ
のリンクが改訂番号などによって設定されている。

【０１３１】（４）改訂履歴の出力方法 本発明では，改訂履歴をＳＧＭＬ文書とともに出力する
手段を持つ。改訂履歴もＳＧＭＬ文書形式で出力され
る。改訂履歴は，基本的には改訂の差分を列挙したもの
である。改訂前の文書も独立に出力してその間の遷移
（対応）関係を加えることもできる。

【０１３２】出力形式には，元のＤＴＤに履歴情報部分
の宣言を加えて生成した履歴付きＳＧＭＬ文書のＤＴＤ
を用いる形式と，履歴文書をハブとして元のＳＧＭＬ文
書を埋め込んだ形式の２種類がある。後者はさらに，改
訂履歴を差分情報として列挙してＳＧＭＬ文書本体の要
素との対応を記述する形式と，改訂前のＳＧＭＬ文書群
も出力してそれらの要素の間の遷移関係を記述する形式
とがある。いずれの形式でも，履歴情報として出力され
る内容は，図２に示した履歴情報と同一である。

【０１３３】履歴情報付きＳＧＭＬ文書において，履歴
情報とＳＧＭＬ文書本体との対応付けは，ＳＧＭＬのＩ
Ｄ参照機能を使って行われる。このために，通常はＳＧ
ＭＬ文書本体の各文書要素にインスタンス識別子に相当
する属性を埋め込む。なお，例えばＩＳＯ規格として知
られているＨｙＴｉｍｅ（ＩＳＯ１０７４４）のロケー
ションラダーの機能を利用して，元のＳＧＭＬ文書のＤ
ＴＤに手を加えることなく実現することも可能である。
このような出力が可能なのは，本発明におけるインスタ
ンス識別子などの構成がＳＧＭＬのＩＤ参照やＨｙＴｉ
ｍｅのリンク機能との親和性が高いからである。

【０１３４】要素識別子は，ＳＧＭＬ文書本体の要素の
識別子の属性として，文書識別子は，ＳＧＭＬ文書本体
を履歴文書と別の文書とした場合のＳＧＭＬ文書エンテ
ィティの識別子として，改訂番号は履歴情報部分の要素
の識別子属性として利用される。

【０１３５】（５）履歴付きＳＧＭＬ文書の出力 図１８および図１９は，ＳＧＭＬ文書本体に要素識別子
などの情報を埋め込む場合の履歴付きＳＧＭＬ文書のＤ
ＴＤの例を示す図である。ここで，他の文書の要素を取
り込んでいる部分などについては，履歴付きＳＧＭＬ文
書における要素識別子・改訂番号として本装置で管理し
ているものに文書識別子を加えたものが用いられる。

【０１３６】ＳＧＭＬ文書本体に要素識別子などを埋め
込めない場合には，ＳＧＭＬ文書本体を外部エンティテ
ィとして定義し，ＥＳＤｄｏｃの部分にＨｙＴｉｍｅの
ｐａｔｈｌｏｃを使ったロケーションラダーによってＳ
ＧＭＬ文書本体の要素に要素識別子などの属性を対応付
けるなどの手段によって，同様の情報をＳＧＭＬ文書と
して表現できる。

【０１３７】図２０ないし図２７は，ＳＧＭＬ文書編集
装置１０の文書編集処理のフローチャートである。特に
図２０および図２１は，全体の処理の流れを示してい
る。図２０のステップＳ９１では，サーバから，あるい
はローカルファイルから編集対象の文書部分木を獲得す
る。ここで，依存関係にある文書編集装置も同時に起動
される。

【０１３８】ステップＳ９２では，ユーザの要求または
別の文書編集装置からのメッセージ（同期要求）を待
つ。ステップＳ９３では，同期要求かどうかを判定し，
同期要求であればステップＳ１０７の処理へ進み，同期
要求でなければステップＳ９４の処理へ進む。

【０１３９】ステップＳ９４では，ユーザの要求を判定
し，ユーザの要求が構造編集要求であればステップＳ９
５の処理へ進み，ユーザの要求が内容編集要求であれば
ステップＳ９６の処理へ進み，ユーザの要求が終了また
はチェックイン要求であればステップＳ９８の処理へ進
む。

【０１４０】ステップＳ９５では，後述する構造編集処
理を行う。ステップＳ９６では，編集可能要素かどうか
を判定し，編集可能要素であればステップＳ９７の処理
へ進み，編集可能要素でなければステップＳ９２の処理
へ戻る。

【０１４１】ステップＳ９７では，内容編集を行う。ス
テップＳ９８では，別の文書編集装置と依存関係がある
かどうかを判定し，依存関係がある場合にはステップＳ
９９の処理へ進み，依存関係がない場合にはステップＳ
１０４の処理へ進む。

【０１４２】ステップＳ９９では，直接の依存関係にあ
る文書編集装置に通知して依存関係にある全ての文書編
集装置の識別子リストを獲得する。なお，重複するもの
は取り除く。

【０１４３】ステップＳ１００では，依存関係にあるも
のを表示して全てに対して処理を行うことを確認する。
ステップＳ１０１では，処理するかどうかを判定する。
処理する場合にはステップＳ１０２の処理へ進み，処理
しない場合にはステップＳ１０３の処理へ進む。

【０１４４】ステップＳ１０２では，依存関係にある装
置に処理実行を要求し，ステップＳ１０４の処理へ進
む。ステップＳ１０３では，予約解除を行い，ステップ
Ｓ９２の処理へ戻る。

【０１４５】ステップＳ１０４では，要求が何であるか
を判定し，要求がチェックイン要求の場合にはステップ
Ｓ１０５の処理へ進み，要求が終了要求の場合には，ス
テップＳ１０６の処理へ進む。

【０１４６】ステップＳ１０５では，後述するチェック
イン処理を行い，ステップＳ９２の処理へ戻る。ステッ
プＳ１０６では，後述する終了処理を行う。

【０１４７】ステップＳ１０７では，同期要求が何であ
るかを判定し，同期要求が終了またはチェックイン要求
の場合にはステップＳ１０８の処理へ進み，同期要求が
依存関係獲得要求（兼同期処理予約）の場合にはステッ
プＳ１０９（図２１）の処理へ進む。

【０１４８】ステップＳ１０８では，予約解除またはエ
ラー処理を行い，ステップＳ１０４の処理へ進む。図２
１のステップＳ１０９では，処理予約がされているかど
うかを判定し，処理予約がされている場合にはステップ
Ｓ１１３の処理へ進み，処理予約がされていない場合に
はステップＳ１１０の処理へ進む。

【０１４９】ステップＳ１１０では，同期処理予約とし
て，要求元の識別子を記憶し，他からの処理の受け付け
を停止する。ステップＳ１１１では，依存関係にある他
の文書編集装置に要求元の識別子と同期要求とを転送し
依存関係にある文書編集装置の識別子リストを得る。

【０１５０】ステップＳ１１２では，文書編集装置の識
別子リストに自身の識別子を加え，要求送信元に返す。
ステップＳ１１３では，要求送信元に空の文書編集装置
識別子リストを返す。なお，要求送信元では，識別子が
予約と異なる場合にはエラー処理を行うことになる。

【０１５１】ステップＳ１１４では，別の文書編集装置
（同期予約主）からのメッセージ（同期要求）を待つ。
その後，ステップＳ１０７の処理へ戻る。図２２は，図
２０におけるステップＳ９５の構造編集処理のフローチ
ャートである。

【０１５２】ステップＳ１２１では，ユーザの要求が何
であるかを判定し，新規作成要求の場合にはステップＳ
１２２の処理へ進み，張り付け（ペースト）要求の場合
にはステップＳ１２７の処理へ進み，複写（コピー）／
切り取り（カット）要求の場合にはステップＳ１３１の
処理へ進み，削除要求の場合にはステップＳ１３５の処
理へ進む。

【０１５３】ステップＳ１２２では，新規要素を作成す
る位置は編集可能領域かどうかを判定し，編集可能領域
であればステップＳ１２３の処理へ進み，編集可能領域
でなければ処理を終了する。

【０１５４】ステップＳ１２３では，ユーザに要素種別
の指定を促す。ステップＳ１２４では，仮の要素識別子
を生成し，新規要素を作成する。ステップＳ１２５で
は，親要素の文書識別子と要素識別子を新規要素の属性
（ｄｏｃ，ｐｉｄ）に設定する。

【０１５５】ステップＳ１２６では，新規作成した要素
を処理中の文書木に追加し，処理を終了する。ステップ
Ｓ１２７では，張り付ける位置は編集可能領域かどうか
を判定し，編集可能領域であればステップＳ１２８の処
理へ進み，編集可能領域でなければ処理を終了する。

【０１５６】ステップＳ１２８では，張り付ける要素が
登録されたレジスタがあるかどうかを判定し，登録され
たレジスタがある場合にはステップＳ１２９の処理へ進
み，登録れたレジスタがない場合には処理を終了する。

【０１５７】ステップＳ１２９では，張り付け元のレジ
スタの選択を促す。ステップＳ１３０では，後述する張
り付け処理を行い，処理を終了する。ステップＳ１３１
では，切り取り要求か複写要求かを判定し，切り取り要
求であればステップＳ１３２の処理へ進み，複写要求で
あればステップＳ１３４の処理へ進む。

【０１５８】ステップＳ１３２では，切り取る位置は編
集可能領域かどうかを判定し，編集可能領域であればス
テップＳ１３３の処理へ進み，編集可能領域でなければ
処理を終了する。

【０１５９】ステップＳ１３３では，後述する要素削除
処理を行う。すなわち，指定された要素を削除リストに
つなぎ，指定された要素の親要素の要素削除情報を更新
する。

【０１６０】ステップＳ１３４では，指定要素と親要素
の識別子，複写／切り取りの種別をレジスタに登録す
る。その後，処理を終了する。ステップＳ１３５では，
削除する位置は編集可能領域かどうかを判定し，編集可
能領域であればステップＳ１３６の処理へ進み，編集可
能領域でなければ処理を終了する。

【０１６１】ステップＳ１３６では，後述する要素削除
処理を行う。図２３および図２４は，図２２におけるス
テップＳ１３０の張り付け処理のフローチャートであ
る。

【０１６２】図２３のステップＳ１４１では，レジスタ
の要素種別を判定し，要素種別が複写の場合にはステッ
プＳ１４２の処理へ進み，要素種別が切り取りの場合に
はステップＳ１５４の処理へ進む。

【０１６３】ステップＳ１４２では，複写する要素の変
更モードの選択をユーザに促す。ステップＳ１４３で
は，変更モードを判定し，変更モードが共有モードまた
はリンクモードの場合にはステップＳ１４４の処理へ進
み，変更モードが独立モードの場合にはステップＳ１５
２の処理へ進む。

【０１６４】ステップＳ１４４では，仮の要素識別子を
生成する。ステップＳ１４５では，レジスタの要素のコ
ピーを作り，生成した要素識別子を設定する。

【０１６５】ステップＳ１４６では，コピー要素のコピ
ー元属性（ｃｏｐｙｏｆ）と変更モード属性（ｃｏｐｙ
ｓｔａｔ）に，レジスタ要素のインスタンス識別子と変
更モードとをそれぞれ設定する。

【０１６６】ステップＳ１４７では，コピーした要素の
コピー要素リスト属性（ｃｏｐｉｅｄ．ｔｏ）と，リン
ク要素リスト属性（ｌｉｎｋｅｄ．ｗｉｔｈ），派生要
素リスト属性（ｄｅｒｉｖａｔｉｏｎｓ）をクリアす
る。

【０１６７】ステップＳ１４８では，レジスタ要素以下
の文書部分木に含まれるレジスタ要素以外の要素に対し
て仮の要素識別子を生成し，元の要素識別子との対応を
要素対応表属性（ｌｉｎｋｔｂｌ）に格納する。

【０１６８】ステップＳ１４９では，変更モードを判定
し，変更モードがリンクモードの場合にはステップＳ１
５０の処理へ進み，変更モードが共有モードの場合には
ステップＳ１５１の処理へ進む。

【０１６９】ステップＳ１５０では，レジスタ要素のリ
ンク要素リスト属性（ｌｉｎｋｅｄ．ｗｉｔｈ）の末尾
にコピーした要素の（仮）インスタンス識別子を追加
し，ステップＳ１５３の処理へ進む。

【０１７０】ステップＳ１５１では，レジスタ要素のコ
ピー要素リスト属性（ｃｏｐｉｅｄ．ｔｏ）の末尾にコ
ピーした要素の（仮）インスタンス識別子を追加し，ス
テップＳ１５３の処理へ進む。

【０１７１】ステップＳ１５２では，レジスタの要素以
下の文書部分木を深さ優先に訪れ，行きがけ順にコピー
する。すなわち，全ての要素識別子は，仮の識別子を生
成して置き換え，コピー元属性には元要素のインスタン
ス識別子を設定し，変更モード属性は独立モードとす
る。それぞれのコピー元の要素の派生要素リスト属性
（ｄｅｒｉｖａｔｉｏｎｓ）に生成したコピー要素のイ
ンスタンス識別子を加える。ただし，部分木内で閉じて
いる共有・リンク関係については，部分木内のリンクに
付け替える。

【０１７２】ステップＳ１５３では，張り付ける要素を
処理中の部分木に追加し，処理を終了する。ステップＳ
１５４では，レジスタの要素は処理中の文書とは別の文
書であるかどうかを判定する。レジスタの要素が別の文
書である場合にはステップＳ１４２の処理へ進み，レジ
スタの要素が別の文書でない場合にはステップＳ１５５
（図２４）の処理へ進む。

【０１７３】図２４のステップＳ１５５では，レジスタ
の要素以下の部分木を削除リストから取り除き，張り付
ける要素とする。ステップＳ１５６では，張り付ける要
素は新規要素であるかどうかを判定する。張り付ける要
素が新規要素である場合にはステップＳ１６３の処理へ
進み，張り付ける要素が新規要素でない場合にはステッ
プＳ１５７の処理へ進む。

【０１７４】ステップＳ１５７では，レジスタ要素の元
の親要素の削除要素属性（ｄｅｌｅｔｉｏｎｓ）からレ
ジスタ要素の識別子（文書識別子と要素識別子）を取り
除く。

【０１７５】ステップＳ１５８では，取り除けたかどう
かを判定し，レジスタ要素の識別子が取り除けた場合に
はステップＳ１５９の処理を行い，レジスタ要素の識別
子が取り除けない場合にはステップＳ１６０の処理へ進
む。

【０１７６】ステップＳ１５９では，レジスタ要素の元
の親要素の移出要素属性（ｅｘｐｏｒｔｓ）の末尾にレ
ジスタ要素の識別子（文書識別子と要素識別子）を追加
する。

【０１７７】ステップＳ１６０では，張り付け先の親要
素の削除要素属性（ｄｅｌｅｔｉｏｎｓ）からレジスタ
要素の識別子（文書識別子と要素識別子）を取り除く。
ステップＳ１６１では，取り除けたかどう判定し，レジ
スタ要素の識別子が取り除けた場合にはステップＳ１６
３の処理へ進み，レジスタ要素の識別子が取り除けない
場合にはステップＳ１６２の処理へ進む。

【０１７８】ステップＳ１６２では，張り付け先の親要
素の移入要素属性（ｉｍｐｏｒｔｓ）の末尾にレジスタ
要素の識別子（文書識別子と要素識別子）を追加する。
ステップＳ１６３では，レジスタの要素種別を複写要素
に変更する。その後，ステップＳ１５３の処理へ進む。

【０１７９】図２５は，図２２におけるステップＳ１３
３とステップＳ１３６の要素削除処理のフローチャート
である。ステップＳ１７１では，削除する要素は新規要
素かどうかを判定する。削除する要素が新規要素である
場合にはステップＳ１７５の処理へ進み，削除する要素
が新規要素でない場合にはステップＳ１７２の処理へ進
む。

【０１８０】ステップＳ１７２では，削除要素の元の親
要素の移入要素属性（ｉｍｐｏｒｔｓ）から削除要素の
識別子（文書識別子と要素識別子）を取り除く。ステッ
プＳ１７３では，削除要素の識別子が取り除けたかどう
かを判定し，取り除けた場合にはステップＳ１７４の処
理へ進み，取り除けなかった場合にはステップＳ１７５
の処理へ進む。

【０１８１】ステップＳ１７４では，削除要素の元の親
要素の削除要素属性（ｄｅｌｅｔｉｏｎｓ）の末尾に削
除要素の識別子（文書識別子と要素識別子）を追加す
る。ステップＳ１７５では，削除要素以下の文書の部分
木を削除リストにつなぎ，処理を終了する。

【０１８２】図２６は，図２０におけるステップＳ１０
５のチェックイン処理のフローチャートである。ステッ
プＳ１８１では，ＳＧＭＬパーサで編集結果が部分編集
用ＤＴＤに適合しているかどうかを検証する。

【０１８３】ステップＳ１８２では，同期要求による処
理かどうかを判定する。同期要求による処理の場合には
ステップＳ１８３の処理へ進み，同期要求によらない処
理の場合にはステップＳ１８７の処理へ進む。

【０１８４】ステップＳ１８３では，処理中の文書はＤ
ＴＤに適合しているかどうかを判定し，適合していない
場合にはステップＳ１８４の処理へ進み，適合している
場合にはステップＳ１８５の処理へ進む。

【０１８５】ステップＳ１８４では，文書が不完全であ
ることを要求元に通知し，処理を終了する。ステップＳ
１８５では，要求元の識別子と編集結果をサーバに送信
し，（同期）チェックインする。

【０１８６】ステップＳ１８６では，チェックイン結果
を要求元に通知し，処理を終了する。ステップＳ１８７
では，処理中の文書または同期チェックインする文書は
ＤＴＤに適合しているかどうかを判定する。ＤＴＤに適
合している場合にはステップＳ１８８の処理へ進み，Ｄ
ＴＤに適合していない場合にはステップＳ１９２の処理
へ進む。

【０１８７】ステップＳ１８８では，削除リストの先頭
の文書要素を削除要素として取り出す。ステップＳ１８
９では，処理中の文書の識別子と編集結果をサーバに送
信し，チェックインする。

【０１８８】ステップＳ１９０では，チェックインが成
功したかどうかを判定し，チェックインが成功である場
合にはステップＳ１９４の処理へ進み，チェックインが
不成功の場合にはステップＳ１９１の処理へ進む。

【０１８９】ステップＳ１９１では，チェックイン失敗
とその理由をユーザに示し，ステップＳ１９４の処理へ
進む。ステップＳ１９２では，処理中の文書識別子と同
期チェックインの解除を通知する。

【０１９０】ステップＳ１９３では，不完全な文書の部
分をユーザに示す。ステップＳ１９４では，依存関係に
ある文書装置に同期予約解除を通知し，処理を終了す
る。

【０１９１】図２７は，図２０におけるステップＳ１０
６の終了処理のフローチャートである。ステップＳ２０
１では，処理中の文書のＤＴＤと文書本体を（文書）フ
ァイルに出力する。

【０１９２】ステップＳ２０２では，文書ファイル名，
レジスタの削除リストの内容を（管理）ファイルに出力
する。ステップＳ２０３では，同期要求による処理かど
うかを判定する。同期要求による処理の場合にはステッ
プＳ２０４の処理へ進み，同期要求によらない処理の場
合にはステップＳ２０５の処理へ進む。

【０１９３】ステップＳ２０４では，文書ファイル名を
要求元へ通知し処理を終了する。ステップＳ２０５で
は，依存関係にある文書ファイルのリストを（管理）フ
ァイルに出力し，処理を終了する。

【０１９４】以上の実施の形態による作用を，以下に説
明する。 １）効率よく文書の取リ出しと格納ができる。 ＳＧＭＬ文書を要素単位でデータベース（ＤＢ）に格納
している場合，要素毎に取り出しのコストがかかるの
で，編集の際に取り出す要素数はなるべく少ないほうが
望ましい。可変個要素に関する挿入・分割を判定するた
めには，内容モデルと実際のエレメントをルート文書要
素からデプスファーストに対応付ける必要がある。

【０１９５】正しいＤＴＤには，モデル要素と実際の文
書要素の対応に暖昧性がないので，すでに適合を確かめ
られたＳＧＭＬ文書なら，下位要素および後続要素に関
するＤＴＤとの適合検査は省略できる。この場合でも，
少なくとも編集しようとしている文書要素から文書のル
ートにいたるパスに含まれる文書要素およびそれより前
に出現している文書要素についての照合を行う必要があ
る。

【０１９６】本発明によれば，内容モデルに下位要素の
インスタンス識別子および可変要素のある時点における
削除・挿入の可否の指標を加えた拡張内容モデルを作成
し，各々の要素と対応付けて格納してあるので，直接の
上位要素編集対象となる要素群（ただし，下位要素が既
に編集中の場合は例外であり，その要素以下のレベルの
要素も取り出されるが，編集対象とはならない）を取り
出すだけでよく（正確には，これ以外に後述のアクセス
制御と履歴管理のために直接の上位の要索に対応する情
報も取り出す必要がある），アクセス効率が向上する。

【０１９７】また，本発明ではＳＧＭＬ文書自体の情報
の他に管理用として拡張内容モデルなどを格納するが，
スペース効率の悪化は小さく抑えられている。文書要素
単位に格納する場合に上位・下位の要素へのリンク情報
は必須であり，実際の文書には出現していない可変個要
素や例外要素部分を加えても，タグ情報が３倍に増える
程度である。また，格納された文書要素のリンク付けに
用いられるインスタンス識別子は，ＳＧＭＬの文書内の
参照のための属性値としても利用可能であり，このよう
に利用するならスペース効率は向上できる。

【０１９８】２）部分編集の自由度が向上する。 本発明のチェックアウト時の削除・追加予約の手段によ
り，ＳＧＭＬ文書を部分的に編集する際に，編集対象の
最上位レベルでタグの変更や要素の分割・追加・削除な
ど従来は不可能だった編集が可能になる。

【０１９９】３）編集の独立性が高まる。 本発明では，部分編集用ＤＴＤによりＳＧＭＬ文書編集
装置１０だけで編集中の部分の整合チェックが可能であ
る。このため，部分編集中にＳＧＭＬ文書を管理するサ
ーバに全くアクセスする必要がなくなり，部分編集を例
えばオフライン形態のパーソナル・コンピュータなどで
も行えるようになるなど，編集の独立性が高まる。

【０２００】４）文書構造変化の履歴が保持できる。 拡張内容モデルと親要素の遷移を保持することで，文書
要素レベルでの追加・削除・移動の履歴を追跡すること
が可能となる。

【０２０１】５）ＳＧＭＬ文書の更新履歴付きで流通が
可能となる。 ＳＧＭＬに準拠した形式で履歴情報についても出力する
機構によって，履歴付きでＳＧＭＬ文書を異なる装置間
で交換することが可能になる。

【０２０２】６）ＤＴＤ変更時などの安全性が向上す
る。 拡張内容モデルにより，ＤＴＤを復元することができる
ので，ＤＴＤの改訂や不慮の事故によりＤＴＤが使用不
能になっても，格納されたＳＧＭＬ文書を利用可能であ
る。

【０２０３】

【発明の効果】以上説明したように，本発明は以下の効
果を奏する。 １）編集作業の独立性が高まり，作業効率が向上する。

【０２０４】本発明では，上位文書要素および前後の文
書要素を編集可能にしたままで，ＤＴＤに違反しない範
囲において，編集中の最上位の文書要素の削除とタグの
変更およびその前後に新たな文書要素を追加することが
可能であるので，担当する章を分割する場合などにＳＧ
ＭＬ文書全体を管理している装置にアクセスし直す必要
が減少する。

【０２０５】また，部分編集文書は，生成された部分編
集用ＤＴＤで独立に整合検査が可能であるため，一旦編
集対象部分を取り出した後はチェックインまで，ＳＧＭ
Ｌ文書全体を管理している装置にアクセスすることなく
編集を進めることが可能である。

【０２０６】このような部分編集の独立性が確保される
ので，ＳＧＭＬ文書本体を管理するサーバのアクセスに
伴う編集作業の停滞が少なくなり，また，オフラインの
形態のコンピュータで編集も可能になるなど作業環境の
選択範囲も広がり，共同編集における作業効率を向上さ
せることができる。

【０２０７】２）文書の再利用が容易になり文書作成・
改訂の効率が向上する。 本発明では，文書の内容・構造の変化の履歴をとりつ
つ，また，他の文書や版の部分を別の文書に取り込んで
作成管理することができる。これにより，異なる版が同
時に流通している製品や，一部の機能のみ違う製品群の
マニュアルの作成管理などにおいて，文書作成・改訂の
効率を向上させることができる。

【図面の簡単な説明】

【図１】本発明のブロック構成図である。

【図２】データの基本構造および履歴情報との対応関係
を示す図である。

【図３】ＳＧＭＬ文書の原文書の例を示す図である。

【図４】ＳＧＭＬ文書の格納例を示す図である。

【図５】拡張内容モデルの構成例を示す図である。

【図６】部分編集用ＤＴＤの生成の例を示す図である。

【図７】追加可能な要素の判定の例を説明する図であ
る。

【図８】追加予約の例を説明する図である。

【図９】削除予約の例を説明する図である。

【図１０】最上位要素のタグ変更の例を説明する図であ
る。

【図１１】クライアントが文書の編集部分を獲得するた
めの処理のフローチャート（１）である。

【図１２】クライアントが文書の編集部分を獲得するた
めの処理のフローチャート（２）である。

【図１３】部分編集用ＤＴＤと編集データを提供する処
理のフローチャート（１）である。

【図１４】部分編集用ＤＴＤと編集データを提供する処
理のフローチャート（２）である。

【図１５】拡張内容モデルを利用した部分編集用内容モ
デルおよび追加・削除候補要素リストの作成処理のフロ
ーチャート（１）である。

【図１６】拡張内容モデルを利用した部分編集用内容モ
デルおよび追加・削除候補要素リストの作成処理のフロ
ーチャート（２）である。

【図１７】改訂履歴の作成の例を説明する図である。

【図１８】履歴付きＳＧＭＬ文書のＤＴＤの例（１）を
示す図である。

【図１９】履歴付きＳＧＭＬ文書のＤＴＤの例（２）を
示す図である。

【図２０】文書編集処理のフローチャート（１）であ
る。

【図２１】文書編集処理のフローチャート（２）であ
る。

【図２２】構造編集処理のフローチャートである。

【図２３】張り付け処理のフローチャート（１）であ
る。

【図２４】張り付け処理のフローチャート（２）であ
る。

【図２５】要素削除処理のフローチャートである。

【図２６】チェックイン処理のフローチャートである。

【図２７】終了処理のフローチャートである。

【符号の説明】

１ ＳＧＭＬ文書管理装置 １０ ＳＧＭＬ文書編集装置 １１ 部分編集用ＤＴＤ整合性検査手段 １２ 履歴作成手段 ２０ ＳＧＭＬ文書交換装置 ３０ ＳＧＭＬ文書アクセス装置 ３１ 文書形式変換手段 ３２ 部分編集用ＤＴＤ作成手段 ３３ 文書形式整合性検査手段 ３４ 履歴管理手段 ４０ データベース ５０，５０’ ＳＧＭＬパーサ

Claims (17)

【特許請求の範囲】
1. 【請求項１】 ＳＧＭＬ形式の文書に対する共同執筆・
   編集・利用を支援するＳＧＭＬ文書管理装置において，
   ＳＧＭＬ文書に対する部分構造の変更を伴うことがある
   部分編集要求に対し，編集前の実際の文書構造とその編
   集状況による制約を文書全体の文書型定義に加味した部
   分構造の文書型定義を自動生成する手段と，前記生成さ
   れた部分構造の文書型定義に従って文書の整合性が維持
   できる範囲内で文書の部分編集を行う手段とを備えるこ
   とを特徴とするＳＧＭＬ文書管理装置。
2. 【請求項２】 請求項１記載のＳＧＭＬ文書管理装置に
   おいて，前記編集状況による制約は，編集対象部分の前
   後に対する文書要素の追加可能性または文書要素の削除
   可能性に関する制約であることを特徴とするＳＧＭＬ文
   書管理装置。
3. 【請求項３】 ＳＧＭＬ文書を格納するデータベースに
   対するアクセス手段を持つサーバ装置と，ＳＧＭＬ文書
   の編集対象部分を前記サーバ装置から取得しＳＧＭＬ文
   書を編集する１または複数のクライアント装置とからな
   るＳＧＭＬ文書管理装置において，前記クライアント装
   置は，ＳＧＭＬ文書の編集対象部分を選択する手段と，
   編集対象部分に対する文書要素の追加または削除を予約
   する手段と，前記編集対象部分の選択および追加予約ま
   たは削除予約に基づいて，前記サーバ装置から編集対象
   となる文書のデータと部分編集用文書型定義とを獲得す
   る手段と，獲得した文書のデータを編集する手段と，前
   記部分編集用文書型定義をもとに編集結果の整合性を検
   査する手段とを備え，前記サーバ装置は，前記クライア
   ント装置からの編集対象部分の選択，および追加予約ま
   たは削除予約の要求に対して，文書全体の文書型定義か
   ら編集対象部分に対する文書要素の追加または削除の可
   能性を解析し，文書要素の追加または削除を含む部分編
   集に対しても文書全体の整合性が保たれる部分編集用文
   書型定義を生成する手段と，編集対象となる文書のデー
   タを前記データベースから抽出し，そのデータと前記生
   成した部分編集用文書型定義とを前記クライアント装置
   へ通知する手段とを備えることを特徴とするＳＧＭＬ文
   書管理装置。
4. 【請求項４】 ＳＧＭＬ形式の文書に対する共同執筆・
   編集・利用を支援するＳＧＭＬ文書管理装置においてＳ
   ＧＭＬ文書を格納するデータベースに対するアクセス手
   段を提供するサーバ装置であって，ＳＧＭＬ文書に対す
   るアクセスを要求する装置からの編集対象部分の選択，
   および追加予約または削除予約の要求に対して，文書全
   体の文書型定義から編集対象部分に対する文書要素の追
   加または削除の可能性を解析し，文書要素の追加または
   削除を含む部分編集に対しても文書全体の整合性が保た
   れる部分編集用文書型定義を生成する手段と，編集対象
   となる文書のデータを前記データベースから抽出し，そ
   のデータと前記生成した部分編集用文書型定義とを前記
   アクセスを要求する装置へ通知する手段とを備えること
   を特徴とするＳＧＭＬ文書管理装置のサーバ装置。
5. 【請求項５】 ＳＧＭＬ形式の文書に対する共同執筆・
   編集・利用を支援するＳＧＭＬ文書管理装置においてＳ
   ＧＭＬ文書を格納するデータベースに対するアクセス手
   段を提供する装置からＳＧＭＬ文書の編集対象部分を取
   得し，そのＳＧＭＬ文書を編集するクライアント装置で
   あって，ＳＧＭＬ文書の編集対象部分を選択する手段
   と，編集対象部分に対する文書要素の追加または削除を
   予約する手段と，前記編集対象部分の選択および追加予
   約または削除予約に基づいて，前記ＳＧＭＬ文書を格納
   するデータベースに対するアクセス手段を提供する装置
   から編集対象となる文書のデータと部分編集用文書型定
   義とを獲得する手段と，獲得した文書のデータを編集す
   る手段と，前記部分編集用文書型定義をもとに編集結果
   の整合性を検査する手段とを備えることを特徴とするＳ
   ＧＭＬ文書管理装置のクライアント装置。
6. 【請求項６】 ＳＧＭＬ形式の文書に対する共同執筆・
   編集・利用を支援するＳＧＭＬ文書管理装置において，
   文書要素の複写，移動，交換，追加または削除の履歴情
   報をＳＧＭＬ文書形式で保持する手段と，保持した履歴
   情報を装置に依存しない形式で出力する手段とを備える
   ことを特徴とするＳＧＭＬ文書管理装置。
7. 【請求項７】 請求項６記載のＳＧＭＬ文書管理装置に
   おいて，前記ＳＧＭＬ文書形式は，元の文書型定義に履
   歴情報部分の宣言を加えて生成した履歴付きＳＧＭＬ文
   書の文書型定義を用いる形式であることを特徴とするＳ
   ＧＭＬ文書管理装置。
8. 【請求項８】 請求項６記載のＳＧＭＬ文書管理装置に
   おいて，前記ＳＧＭＬ文書形式は，履歴情報の文書の骨
   組みに元のＳＧＭＬ文書を埋め込んだ形式であり，改定
   履歴を差分情報として列挙してＳＧＭＬ文書本体の要素
   との対応を記述する形式であることを特徴とするＳＧＭ
   Ｌ文書管理装置。
9. 【請求項９】 請求項６記載のＳＧＭＬ文書管理装置に
   おいて，前記ＳＧＭＬ文書形式は，履歴情報の文書の骨
   組みに元のＳＧＭＬ文書を埋め込んだ形式であり，改定
   前と改定後の要素間の遷移関係を記述する形式であるこ
   とを特徴とするＳＧＭＬ文書管理装置。
10. 【請求項１０】 ＳＧＭＬ形式の文書に対する共同執筆
    ・編集・利用を支援するＳＧＭＬ文書管理装置におい
    て，ＳＧＭＬ文書を文書要素単位で格納し，それぞれに
    文書型定義中の文書要素宣言の内容モデルに対しそれに
    適合している子文書要素のインスタンス識別子を付与し
    た拡張内容モデルと対応付けて管理する手段と，前記Ｓ
    ＧＭＬ文書の編集中の部分に対応する部分編集用文書型
    定義を一時的に生成し，該当部分のみ独立に文書型定義
    に適合しているかを検査可能とする手段と，編集対象に
    おける上位文書要素および前後の文書要素を編集可能に
    したままで，前記部分編集用文書型定義に違反しない範
    囲において，編集中の最上位の文書要素の削除と総称識
    別子の変更およびその前後に新たな文書要素を追加する
    ことを可能にする手段とを備えることを特徴とするＳＧ
    ＭＬ文書管理装置。
11. 【請求項１１】 請求項１０記載のＳＧＭＬ文書管理装
    置において，文書要素の複写，移動，交換，追加または
    削除の履歴情報をＳＧＭＬ文書形式で保持する手段と，
    保持した履歴情報を装置に依存しない形式で出力する手
    段とを備えることを特徴とするＳＧＭＬ文書管理装置。
12. 【請求項１２】 請求項１１記載のＳＧＭＬ文書管理装
    置において，外部のＳＧＭＬ文書または履歴付きＳＧＭ
    Ｌ文書の入出力を行い，前記拡張内容モデル付きのＳＧ
    ＭＬ文書形式と履歴情報のないＳＧＭＬ文書形式または
    履歴情報を分離した履歴付きＳＧＭＬ文書形式との相互
    変換を行う手段を備えることを特徴とするＳＧＭＬ文書
    管理装置。
13. 【請求項１３】 ＳＧＭＬ形式の文書に対する共同執筆
    ・編集・利用を支援するＳＧＭＬ文書管理装置で用いる
    プログラムを格納したプログラム記憶媒体であって，Ｓ
    ＧＭＬ文書に対する部分構造の変更を伴うことがある部
    分編集要求に対し，編集前の実際の文書構造とその編集
    状況による制約を文書全体の文書型定義に加味した部分
    構造の文書型定義を自動生成する処理と，前記生成され
    た部分構造の文書型定義に従って文書の整合性が維持で
    きる範囲内で文書の部分編集を行う処理とを計算機に実
    行させるプログラムを格納したことを特徴とするＳＧＭ
    Ｌ文書管理装置のプログラム記憶媒体。
14. 【請求項１４】 ＳＧＭＬ形式の文書に対する共同執筆
    ・編集・利用を支援するＳＧＭＬ文書管理装置において
    ＳＧＭＬ文書を格納するデータベースに対するアクセス
    手段を提供するサーバ装置で用いるプログラムを格納し
    たプログラム記憶媒体であって，ＳＧＭＬ文書に対する
    アクセスを要求する装置からの編集対象部分の選択，お
    よび追加予約または削除予約の要求に対して，文書全体
    の文書型定義から編集対象部分に対する文書要素の追加
    または削除の可能性を解析し，文書要素の追加または削
    除を含む部分編集に対しても文書全体の整合性が保たれ
    る部分編集用文書型定義を生成する処理と，編集対象と
    なる文書のデータを前記データベースから抽出し，その
    データと前記生成した部分編集用文書型定義とを前記ア
    クセスを要求する装置へ通知する処理とを備える計算機
    に実行させるプログラムを格納したことを特徴とするＳ
    ＧＭＬ文書管理装置におけるサーバ装置のプログラム記
    憶媒体。
15. 【請求項１５】 ＳＧＭＬ形式の文書に対する共同執筆
    ・編集・利用を支援するＳＧＭＬ文書管理装置において
    ＳＧＭＬ文書を格納するデータベースに対するアクセス
    手段を提供する装置からＳＧＭＬ文書の編集対象部分を
    取得し，そのＳＧＭＬ文書を編集するクライアント装置
    で用いるプログラムを格納したプログラム記憶媒体であ
    って，ＳＧＭＬ文書の編集対象部分を選択する処理と，
    編集対象部分に対する文書要素の追加または削除を予約
    する処理と，前記編集対象部分の選択および追加予約ま
    たは削除予約に基づいて，前記ＳＧＭＬ文書を格納する
    データベースに対するアクセス手段を提供する装置から
    編集対象となる文書のデータと部分編集用文書型定義と
    を獲得する処理と，獲得した文書のデータを編集する処
    理と，前記部分編集用文書型定義をもとに編集結果の整
    合性を検査する処理とを，計算機に実行させるプログラ
    ムを格納したことを特徴とするＳＧＭＬ文書管理装置に
    おけるクライアント装置のプログラム記憶媒体。
16. 【請求項１６】 ＳＧＭＬ形式の文書に対する共同執筆
    ・編集・利用を支援するＳＧＭＬ文書管理装置で用いる
    プログラムを格納したプログラム記憶媒体であって，文
    書要素の複写，移動，交換，追加または削除の履歴情報
    をＳＧＭＬ文書形式で保持する処理と，保持した履歴情
    報を装置に依存しない形式で出力する処理とを，計算機
    に実行させるプログラムを格納したことを特徴とするＳ
    ＧＭＬ文書管理装置のプログラム記憶媒体。
17. 【請求項１７】 ＳＧＭＬ形式の文書に対する共同執筆
    ・編集・利用を支援するＳＧＭＬ文書管理装置で用いる
    プログラムを格納したプログラム記憶媒体であって，Ｓ
    ＧＭＬ文書を文書要素単位で格納し，それぞれに文書型
    定義中の文書要素宣言の内容モデルに対しそれに適合し
    ている子文書要素のインスタンス識別子を付与した拡張
    内容モデルと対応付けて管理する処理と，前記ＳＧＭＬ
    文書の編集中の部分に対応する部分編集用文書型定義を
    一時的に生成し，該当部分のみ独立に文書型定義に適合
    しているかを検査可能とする処理と，編集対象における
    上位文書要素および前後の文書要素を編集可能にしたま
    まで，前記部分編集用文書型定義に違反しない範囲にお
    いて，編集中の最上位の文書要素の削除と総称識別子の
    変更およびその前後に新たな文書要素を追加することを
    可能にする処理とを，計算機に実行させるプログラムを
    格納したことを特徴とするＳＧＭＬ文書管理装置のプロ
    グラム記憶媒体。