JP2008090459A - 構造化文書管理システム及びプログラム - Google Patents

Abstract

【課題】構造化文書内部に対する更新操作のうち、クライアントから予め通知することが要求されている更新操作をリアルタイムに検知して通知できるようにする。
【解決手段】テーブル記憶部１０９は、任意のクライアントから要求された通知対象とするノードを示すノード情報及び通知対象とする更新操作の種類を含む更新通知条件を記憶する。ドキュメント管理部１０２は、任意のクライアントからの更新要求に応じ、指定の構造化文書に対して要求された更新操作を行い、更新操作が行われたノードを示すノード情報及び更新操作の種類を更新通知管理部１０６に渡す。更新通知管理部１０６は、渡されたノード情報の示すノード及び更新操作の種類のテーブル記憶部１０９に記憶されている更新通知条件に対する一致性を世代関係を踏まえて検証し、一致性が認められた場合に、対応する更新通知条件の設定を要求したクライアント端末への更新通知を行う。
【選択図】 図２

Description

本発明は、構造化文書を構造化文書データベースに格納して管理する構造化文書管理システムに係り、特に構造化文書内部に対する更新操作を検知するのに好適な構造化文書管理システム及びプログラムに関する。

一般に、ＸＭＬ（Extensible Markup Language）文書に代表される構造化文書では、タグと呼ばれる文字列で階層的な構造が表現される。構造化文書管理システムは、構造化文書をデータベース（構造化文書データベース）に格納して管理する。構造化文書管理システムでは、構造化文書データベースへの新たな構造化文書の新規登録、登録済みの構造化文書の削除、更には構造化文書の更新などのイベントが発生する。

一方、表形式のデータをリレーショナルデータベース（ＲＤＢ）に格納して管理するシステムとして、リレーショナルデータベース管理システム（ＲＤＢ管理システム）が知られている。ＲＤＢ管理システム（ＲＤＢＭＳ）においても、ＲＤＢへの新たな表形式データ（テーブルのデータ）の新規登録、登録済みの表形式データの削除、更には表形式データの更新などのイベントが発生する。

ＲＤＢ管理システムは、ＳＱＬ（Structured Query Language）の規格で規定されたトリガ機能（第１の更新通知機能）とベンダ毎に提供される更新通知機能（第２の更新通知機能）とを組み合わせることによって、上述のイベントの発生を検知して、そのイベント発生をクライアント（クライアント端末）に通知する。トリガ機能は、テーブル単位、或いはテーブルの行単位に何らかの操作が行われたことを検知する機能である（例えば、非特許文献１参照）。ベンダ毎に提供される更新通知機能は、トリガ機能の拡張機能であり、例えばテーブルの列単位に何らかの操作が行われたことを検知してクライアントに通知する機能である（例えば、非特許文献２参照）。これらの機能は、データ構造が確定しているという表形式データの特徴を利用することによって実現されている。
＜ＵＲＬ；http://www.microsoft.com/japan/sql/prodinfo/compare/prk/vsOracle4_7.mspx＞（平成１８年９月２５日検索） ＜ＵＲＬ；http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/nav/portal_5.htm＞（平成１８年９月２５日検索）

上述したように、ＲＤＢ管理システムは、ＲＤＢへの新たな表形式データの新規登録、登録済みの表形式データの削除、更には表形式データの更新などのイベントの発生を検知して、そのイベント発生をクライアント（クライアント端末）に通知することができる。

構造化文書管理システムにおいても、構造化文書データベースへの新たな構造化文書の新規登録、登録済みの構造化文書の削除、更には構造化文書の更新などのイベントが発生する。そこで、このようなイベントを検知してネットワーク経由でクライアントに通知する機能を、構造化文書管理システムに持たせることが要求されている。

しかし、構造化文書管理システムにおいて上述のイベントを検知する機能を実現することは容易ではない。その理由は次の通りである。まず、ＲＤＢ管理システムにおいてイベント検知の対象となるデータは、データ構造が確定している表形式データである。このため、ＲＤＢ管理システムでは、テーブルに対する操作から、テーブル単位だけでなく、テーブルの行単位、列単位に何らかの操作が行われたことを検知（トリガ）することができる。しかし、構造化文書管理システムにおいてイベント検知の対象とされるデータは、構造に重複や曖昧さなどを許可する高い記述性を有する構造化文書である。このような構造化文書をイベント検知の対象とした場合、ＲＤＢ管理システムで適用されているようなイベント検知技術を応用しただけでは、構造化文書単位での新規追加や削除は検知できても、構造化文書内部の変更を検知することは難しい。

そこで、例えばクライアント側から構造化文書管理システムの構造化文書データベースをネットワークを介してポーリングし、構造化文書の前回との違いをチェックすることが考えられる。しかしポーリングでは、ネットワークや構造化文書管理システムにも負荷がかかるだけでなく、更新情報の検知がリアルタイムに行えない。

本発明は上記事情を考慮してなされたものでその目的は、構造化文書データベースに格納されている構造化文書内部に対する更新操作のうち、クライアントから予め通知することが要求されている更新操作をリアルタイムに検知して当該クライアントに通知できる構造化文書管理システム及びプログラムを提供することにある。

本発明の１つの観点によれば、構造化文書の集合を格納する構造化文書データベースを備えた構造化文書管理システムが提供される。このシステムは、任意のクライアント端末からの更新通知条件設定要求によって指定された、更新要求構造化文書に対する更新操作発生時の通知対象とするノードを示す第１のノード情報及び通知対象とする更新操作の種類を示す第１の更新操作種類情報を含む更新通知条件を記憶する記憶手段と、任意のクライアント端末からの更新要求に応じて、当該更新要求で指定された構造化文書に対して要求された更新操作を行う構造化文書管理手段であって、更新操作が行われたノードを示す第２のノード情報及び更新操作の種類を示す第２の更新操作種類情報を出力する構造化文書管理手段と、前記第２のノード情報の示すノード及び前記第２の更新操作種類情報の示す更新操作の種類の前記記憶手段に記憶されている更新通知条件に対する一致性を検証する一致性検証手段であって、ノード情報に関しては、当該更新通知条件に含まれている前記第１のノード情報の示すノードに対する前記第２のノード情報の示すノードの世代関係の有無に基づき一致性を検証する一致性検証手段と、前記一致性検証手段によって一致性が認められた場合に、対応する更新通知条件の設定を要求したクライアント端末に前記第２のノード情報及び前記第２の更新操作種類情報を通知する更新通知手段とを具備する。

本発明によれば、クライアント（クライアント端末）から予め通知することが要求されているノード情報で示されるノードと世代関係のある、構造化文書内の任意のノードに対して行われた更新操作、つまりクライアントが指定したノード情報で示されるノード以下の任意のノードに対して行われた更新操作をリアルタイムで検知して当該クライアントに通知できる。

以下、本発明の実施の形態につき図面を参照して説明する。
図１は本発明の一実施形態に係る構造化文書管理システムを含むクライアント−サーバシステムのハードウェア構成を示すブロック図である。図１のクライアント−サーバシステムは、構造化文書管理システム１０と、クライアント端末２０を含む複数のクライアント端末（クライアント）とから構成される。各クライアント端末上では、構造化文書管理システム１０を利用するアプリケーション（アプリケーションプログラム）が動作する。クライアント端末２０を含む複数のクライアント端末は、ローカルエリアネットワーク（ＬＡＮ）のようなネットワーク３０を介して、構造化文書管理システム１０と接続されている。なお、図１では、クライアント端末２０以外のクライアント端末は省略されている。

構造化文書管理システム１０は、構造化文書を管理する構造化文書管理サーバ（サーバコンピュータ）１１と、当該サーバ１１が有する外部記憶装置１２とから構成される。構造化文書管理サーバ１１は主メモリのようなメモリ１１０を有する。外部記憶装置１２は例えば磁気ディスク装置であり、構造化文書管理プログラム１２１、構造化文書データベース１２２及び更新通知条件管理テーブル１２３を格納する。

構造化文書管理プログラム１２１は、構造化文書を構造化文書データベース１２２に格納して管理する処理を構造化文書管理サーバ１１に実行させるのに用いられる。構造化文書データベース１２２は、構造化文書の集合を保存する。構造化文書データベース１２２は更に、当該データベース１２２に格納される構造化文書に基づいて作成される索引データも保存する。この索引データは、構造化文書を検索するのに用いられる。更新通知条件管理テーブル１２３については後述する。

図２は構造化文書管理システム１０の主として機能構成を示すブロック図である。構造化文書管理システム１０は、構造化文書データベース１２２に加えて、コマンド管理部１０１、ドキュメント管理部１０２、検索エンジン部１０３、構造情報抽出部１０４、索引管理部１０５、更新通知管理部１０６及びデータベース操作部１０７の各処理部を含む。構造化文書管理システム１０はまた、更新通知条件管理テーブル１０８を格納するテーブル記憶部１０９を含む。

処理部１０１乃至１０７は、図１の構造化文書管理サーバ１１が外部記憶装置１２に格納されている構造化文書管理プログラム１２１を読み込んで実行することにより実現されるものとする。このプログラム１２１は、コンピュータ読み取り可能な記憶媒体に予め格納して頒布可能である。また、このプログラム１２１が、ネットワーク３０を介して構造化文書管理サーバ１１にダウンロードされても構わない。テーブル記憶部１０９は、図１の構造化文書管理サーバ１１のメモリ１１０内に確保される。このテーブル記憶部１０９には、例えば構造化文書管理サーバ１１の立ち上げ時に、外部記憶装置１２に格納されている更新通知条件管理テーブル１２３が更新通知条件管理テーブル１０８としてロードされる。

図３は、構造化文書データベース１２２に格納される構造化文書の一例を示す。図３の構造化文書はＸＭＬ形式の文書（ＸＭＬ文書）であり、ＸＭＬ（構造化文書）の特徴を明示する例である。図３の構造化文書は、要素名がｂｉｂの１対のタグ（ｂｉｂタグ）と当該１対のｂｉｂタグで囲まれた要素内容とから構成されるｂｉｂ要素（ｂｉｂノード）を含む。ｂｉｂノードの下位（の階層）には、３つのｂｏｏｋノード（ｂｏｏｋ要素）３０１，３０２及び３０３が存在する。ｂｏｏｋノード３０１〜３０３は、それぞれ構造が異なる。即ちｂｏｏｋノード３０１はその下位にａｕｔｈｏｒノードを１つ含むが、ｂｏｏｋノード３０２はその下位にａｕｔｈｏｒノードを２つ含む。また、ｂｏｏｋノード３０３は、その下位にａｕｔｈｏｒノードを含まないものの、代わりにｐｕｂｌｉｓｈｅｒノードを含む。

図４は、更新通知条件管理テーブル１０８のデータ構造例を示す。更新通知条件管理テーブル１０８の各エントリは更新通知条件を保持する。更新通知条件は、クライアント端末から要求された構造化文書（内のノード）を対象とする更新操作が実行された場合に、その更新操作に関する情報をクライアント端末（当該情報の通知を予め要求していたクライアント端末）に通知するための条件を示す。

更新通知条件は、任意のクライアント端末からの更新通知条件設定要求によって指定された、更新要求構造化文書に対する更新操作発生時の通知対象とするノードを示すノード情報（第１のノード情報）と、通知対象ノードに対する通知対象とする更新操作の種類を示す更新操作種類情報（第２の更新操作種類情報）との組を含む。更新通知条件はまた、当該条件を識別する情報（条件ＩＤ）を含む。
構造化文書の各ノードは一般にＸＰａｔｈで表される。そこで本実施形態においても、各ノードをＸＰａｔｈで表現する。

図４の更新通知条件管理テーブル１０８の例では、次の３つの更新条件
条件ＩＤ＝１：「／ｂｉｂ／ｂｏｏｋ」＋「更新」
条件ＩＤ＝２：「／ｂｉｂ／ｂｏｏｋ／ａｕｔｈｏｒ」＋「追加」
条件ＩＤ＝３：「／ｂｉｂ／ｂｏｏｋ／ｐｒｉｃｅ」＋「削除」
が設定されている。上記「／ｂｉｂ…」中の「／ｂｉｂ」は、ルートノードの下位のノード（子ノード）がｂｉｂノードであることを示す。

条件ＩＤ＝１の更新通知条件は、「／ｂｉｂ／ｂｏｏｋ」以下のノードが「更新」されたら通知すること、
条件ＩＤ＝２の更新通知条件は、「／ｂｉｂ／ｂｏｏｋ／ａｕｔｈｏｒ」ノードそれ自体が「追加」されたら通知すること、
条件ＩＤ＝３の更新通知条件は、「／ｂｉｂ／ｂｏｏｋ／ｐｒｉｃｅ」以下のノードが削除されたら通知すること
をそれぞれ示す。

よって、例えば、「ａｕｔｈｏｒ」の名前が変更された場合、或いはｂｏｏｋノードの下位に「ｐｕｂｌｉｓｈｅｒ」ノードが追加された場合、或いはｐｒｉｃｅの値が変更された場合には、条件ＩＤ＝１の更新通知条件が成立する。また、「ａｕｔｈｏｒ」が１人追加され場合（ａｕｔｈｏｒノードの追加時）には、条件ＩＤ＝２の更新通知条件が成立する。

再び図２を参照すると、コマンド管理部１０１は、クライアント端末からネットワーク３０を介して与えられる各種のコマンド（要求）を受け付けて当該コマンドの種別を判別する。コマンド管理部１０１は、コマンドの種別の判別結果に応じてドキュメント管理部１０２、検索エンジン部１０３、索引管理部１０５及び更新通知管理部１０６のいずれかに当該コマンドの指定する処理を実行させる。

ドキュメント管理部１０２は、構造化文書データベース１２２を対象に構造化文書の管理を司る構造化文書管理手段として機能する。この構造化文書の管理は、任意のクライアント端末からの要求（更新要求）に応じて、構造化文書データベース１２２に構造化文書を登録し、或いは当該データベース１２２に既に登録されている構造化文書を更新・削除する操作を含む。この操作を、説明の簡略化のために一括りにして更新操作と呼ぶこともある。ドキュメント管理部１０２は、更新操作が行われたノードを示すノード情報（第２のノード情報）及び更新操作の種類を示す更新操作種類情報（第２の更新操作種類情報）を更新通知管理部１０６に渡す。なお、以下の説明では、「更新操作の種類を示す更新操作種類情報」を単に「更新操作の種類」と表現する。

検索エンジン部１０３は、クライアント端末からの検索要求に従い、当該検索要求で指定される検索条件に合致する構造化文書を構造化文書データベース１２２に格納されている索引データを利用して当該データベース１２２から検索する。構造情報抽出部１０４は、ドキュメント管理部１０２による更新操作（構造化文書管理）に必要な、当該更新操作の対象とする構造化文書の構造（ノード）を表す構造情報（ノード情報）を抽出する。

索引管理部１０５は、構造化文書データベース１２２に格納されている構造化文書を検索するのに用いられる索引データを管理する。この索引データの管理は、索引データの作成、作成された索引データの構造化文書データベース１２２への格納、当該データベース１２２からの索引データの検索を含む。

更新通知管理部１０６は、ドキュメント管理部１０２から渡されたノード情報（第２のノード情報）の示すノード及び更新操作の種類の更新通知条件管理テーブル１０８に保持されている更新通知条件に対する一致性を検証する一致性検証機能を有する。特にノード情報に関しては、更新通知管理部１０６は、更新通知条件に含まれているノード情報（第１のノード情報）の示すノードに対するドキュメント管理部１０２から渡されたノード情報の示すノードの世代関係の有無に基づき一致性を検証する。更新通知管理部１０６はまた、一致性が認められた場合に、対応する更新通知条件の設定を要求したクライアント端末に、ドキュメント管理部１０２から渡されたノード情報及び更新操作種類を通知する更新通知機能を有する。

データベース操作部１０７は、ドキュメント管理部１０２、検索エンジン部１０３、構造情報抽出部１０４、索引管理部１０５及び更新通知管理部１０６が構造化文書データベース１２２をアクセスするためのインタフェースとして機能する。

次に、本実施形態の動作について、（１）更新通知条件設定処理、（２）更新通知処理を伴う更新処理（更新通知付き更新処理）を例に、順に説明する。

（１）更新通知条件設定処理
まず、更新通知条件設定処理について図５のフローチャートを参照して説明する。
今、クライアント端末２０が、構造化文書管理システム１０から更新されたことの通知（更新通知）を受けたい「通知対象のノード及び通知対象の更新操作の種類」を決定したものとする。クライアント端末２０は、この決定された「通知対象のノード及び通知対象の更新操作の種類」の情報（つまり更新通知条件）が付された更新通知条件設定要求を、ネットワーク３０を介して構造化文書管理システム１０に送信する。

構造化文書管理システム１０のコマンド管理部１０１は、クライアント端末２０からの更新通知条件設定要求（更新通知条件設定コマンド）を受け付けると、当該要求の種別を判別し、この例のように更新通知条件設定要求の場合には当該要求を更新通知管理部１０６に渡して、更新通知条件設定を要求する（ステップＳ１）。

更新通知管理部１０６は更新通知条件設定要求を受け取ると更新通知条件設定手段として機能する。更新通知管理部１０６はまず、テーブル記憶部１０９に格納されている更新通知条件管理テーブル１０８を参照して、更新通知条件設定要求で指定されている更新通知条件が当該テーブル１０８に既に登録されているかを判定する（ステップＳ２）。もし、指定された更新通知条件が更新通知条件管理テーブル１０８に登録されていない場合には、更新通知管理部１０６は当該更新通知条件を新たな条件として当該テーブル１０８に追加する（ステップＳ３）。また更新通知管理部１０６は、更新通知条件管理テーブル１０８に追加された更新通知条件の条件ＩＤを、更新通知条件設定を要求したクライアント端末２０と対応付けて、図示せぬ更新通知先管理テーブルに登録する。

更新通知条件管理テーブル１０８に更新通知条件が追加された場合など、当該テーブル１０８が更新された場合に、更新通知管理部１０６は、その更新を外部記憶装置１２に格納されている更新通知条件管理テーブル１２３に反映する処理を、例えば構造化文書管理システム１０での処理の空き時間に、或いは構造化文書管理システム１０の電源がオフされる際に、或いは定期的に実行する。

（２）更新通知付き更新処理
次に、更新通知付き更新処理について図６のフローチャートを参照して説明する。
今、クライアント端末２０から構造化文書管理システム１０に対して、構造化文書に対する更新操作（更新、登録または削除）を指定する更新要求が送信されたものとする。

コマンド管理部１０１は、クライアント端末２０からの更新要求（更新要求コマンド）を受け付けると、当該要求の種別を判別し、この例のように更新要求の場合には当該要求をドキュメント管理部１０２に渡して、更新操作を要求する（ステップＳ１１）。

ドキュメント管理部１０２は更新要求を受け取ると、構造情報抽出部１０４を用いて当該要求で指定された構造化文書の構造を示す構造情報を抽出する（ステップＳ１２）。ここでは、更新要求で指定された構造化文書を構造情報抽出部１０４が解析することにより、ＸＰａｔｈで表現されるノード情報が構造情報として抽出される。

ドキュメント管理部１０２は、抽出された構造情報（ノード情報）に基づき、クライアント端末２０からの更新要求で指定された構造化文書に対する更新操作を、データベース操作部１０７を用いて実行する（ステップＳ１３）。この更新操作では、必要ならば索引管理部１０５を用いて索引データも更新される。

ドキュメント管理部１０２は、更新操作（ステップＳ１３）を実行すると、上記抽出された構造情報（ノード情報）のうち、当該更新操作が行われた構造（ノード）を示す構造情報（ノード情報）と当該更新操作の種類との組を更新通知管理部１０６に渡す（ステップＳ１４）。

更新通知管理部１０６は、ドキュメント管理部１０２からノード情報と更新操作の種類との組を受け取ると、その組に一致する更新通知条件が更新通知条件管理テーブル１０８にあるかを調べる一致性検証処理を次の手順で実行する。

まず更新通知管理部１０６は、更新通知条件管理テーブル１０８から未処理の１エントリの情報（更新通知条件）を取り出す（ステップＳ１５，Ｓ１６）。ここでは、１行目のエントリの情報、即ち条件ＩＤ＝１の更新通知条件が取り出されたものとする。

更新通知管理部１０６は、ドキュメント管理部１０２から受け取った情報に含まれているノード情報（更新ノード情報）の、取り出された更新通知条件中のノード情報に対する一致性を判定する（ステップＳ１７）。この判定は、例えば、更新通知条件中のノード情報、つまり通知対象とするノードのＸＰａｔｈ（通知対象とするノードへのパスを表す文字列）をキーとした前方一致で行われる。

今、図３に示される構造化文書の先頭のｂｏｏｋノード３０１の要素内容に含まれる「ｐｒｉｃｅ」（つまりｂｏｏｋノード３０１の子ノードであるｐｒｉｃｅノードの要素内容）が１５００から２０００に変更されたものとする。この場合、ドキュメント管理部１０２から更新通知管理部１０６に渡される情報は、ノード情報「／ｂｉｂ／ｂｏｏｋ／ｐｒｉｃｅ」と更新操作の種類「更新」とである。

更新通知管理部１０６は、ドキュメント管理部１０２から渡されたノード情報「／ｂｉｂ／ｂｏｏｋ／ｐｒｉｃｅ」の、更新通知条件管理テーブル１０８から取り出された更新通知条件に含まれているノード情報に対する一致性を前方一致で確認する（ステップＳ１７）。

図４に示す更新通知条件管理テーブル１０８の例では、１行目のエントリの更新通知条件（条件ＩＤ＝１の更新通知条件）に含まれているノード情報は「／ｂｉｂ／ｂｏｏｋ」である。この場合、一致（前方一致）が確認される（ステップＳ１７）。この前方一致を確認（判定）することは、ノード情報「／ｂｉｂ／ｂｏｏｋ／ｐｒｉｃｅ」で示されるノード（ｐｒｉｃｅノード）とノード情報「／ｂｉｂ／ｂｏｏｋ」で示されるノード（ｂｏｏｋノード）とが世代関係にあること（ここでは、ｐｒｉｃｅノードがｂｏｏｋノードの子ノードである親子関係にあること）を検証することと等価である。

ステップＳ１７で一致が判定されると、更新通知管理部１０６は、ドキュメント管理部１０２から渡されたノード情報（更新操作が行われたノードの情報）を通知の候補とする。次に更新通知管理部１０６は、ドキュメント管理部１０２から渡された更新操作の種類（ここでは「更新」）が、当該一致判定に用いられたノード情報を含む更新通知条件中の更新操作の種類（ここでは、条件ＩＤ＝１の更新通知条件に含まれている更新操作の種類「更新」）に一致するかを判定する（ステップＳ１８）。この例のように一致が判定されるならば、更新通知管理部１０６は、更新通知先管理テーブルによって条件ＩＤ＝１に対応付けられているクライアント端末に対して、ステップＳ１７及び１８で一致が判定された情報、即ち更新操作が行われたノードの情報「／ｂｉｂ／ｂｏｏｋ／ｐｒｉｃｅ」と当該更新操作の種類「更新」との組を、コマンド管理部１０１を介して通知する（ステップＳ１９）。

すると、更新通知管理部１０６はステップＳ１５に戻る。そして更新通知管理部１０６は、更新通知条件管理テーブル１０８に未処理のエントリが残っているならば（ステップＳ１５）、そのエントリの情報（更新通知条件）を取り出す（ステップＳ１６）。ここでは、２行目のエントリの情報、即ち条件ＩＤ＝２の更新通知条件が取り出されたものとする。

図４に示す更新通知条件管理テーブル１０８の例では、２行目のエントリの更新通知条件（条件ＩＤ＝２の更新通知条件）に含まれているノードは「／ｂｉｂ／ｂｏｏｋ／ａｕｔｈｏｒ」である。この場合、ステップＳ１７において不一致が判定される。

すると更新通知管理部１０６は、更新通知条件管理テーブル１０８に未処理のエントリが残っているならば（ステップＳ１５）、そのエントリの情報（更新通知条件）を取り出す（ステップＳ１６）。ここでは、３行目のエントリの情報、即ち条件ＩＤ＝３の更新通知条件が取り出されたものとする。

図４に示す更新通知条件管理テーブル１０８の例では、３行目のエントリの更新通知条件（条件ＩＤ＝３の更新通知条件）に含まれているノードは「／ｂｉｂ／ｂｏｏｋ／ｐｒｉｃｅ」である。この場合、ステップＳ１７において一致（完全一致）が判定される。

ステップＳ１７で一致が判定されると、更新通知管理部１０６は、ドキュメント管理部１０２から渡された更新操作の種類「更新」が、当該一致判定に用いられた更新通知条件に含まれている更新操作の種類（ここでは、条件ＩＤ＝３の更新通知条件に含まれている更新操作の種類「削除」）に一致するかを判定する（ステップＳ１８）。この例のように不一致が判定されるならば、更新通知管理部１０６はステップＳ１９をスキップしてステップＳ１５に戻る。そして、本実施形態のように更新通知条件管理テーブル１０８の最後のエントリまで処理し終えたならば（ステップＳ１５）、クライアント端末２０からの更新要求に対する更新通知付き更新処理は終了する。

本実施形態では、ｂｏｏｋノード３０１の要素内容に含まれる「ｐｒｉｃｅ」が変更された場合を想定している。しかし、他のｂｏｏｋノード３０２または３０３の要素内容に含まれる「ｐｒｉｃｅ」が変更された場合は勿論、ｂｏｏｋノード３０１〜３０３の要素内容に含まれる「ｔｉｔｌｅ」など、「ｂｏｏｋ」ノード以下のノード（例えば、子ノード、孫ノードなど）のいかなる更新でも、条件ＩＤ＝１の更新通知条件に（前方）一致して、更新操作が行われたノードの情報と「更新」との組がクライアント端末２０に通知される。

また本実施形態においては、更新操作が行われたノードが通知対象とするノードであるかを判定するのに、通知対象とするノードへのパスを表す文字列（パス文字列）の前方一致検索が用いられる。しかし、親子関係のようなパス同士の世代関係を識別できるならば、前方一致検索以外の手段を用いても構わない。

［変形例］
次に上記実施形態の変形例について説明する。
上記実施形態では、更新通知条件に含まれるノード情報の示すノード（通知対象ノード）は明確なパスで指定される。この場合、パスで指定されるノード以下の任意の更新までは検知できる。しかし、このようなパスでは、例えば「どこかにあるｐｒｉｃｅノード」を通知対象として指定できない。

ところがＸＰａｔｈには、このような曖昧性のあるパスの表記手法、つまり複数のパス（構造）をまとめて示す表記手法がある。上述の「どこかにあるｐｒｉｃｅノード」は、「／／ｐｒｉｃｅ」によって表現される。また、例えば、「／＊／ｐｒｉｃｅ」の表記により、ルートノードより２階層下のｐｒｉｃｅノードを定義することもできる。通知対象ノードを、このような曖昧性のあるパスで指定することにより、更新通知の柔軟度を高めることが可能になる。

そこで本変形例では、更新通知条件管理テーブル１０８（１２２）に、曖昧性のあるパスで表現されるノード情報を含む更新通知条件が登録されるのを許している。まず、曖昧性のあるパスについて、図７を参照して説明する。図７は、構造化文書データベース１２２に格納される構造化文書の一例を示す。図７の構造化文書は、ホームセンターノード（ホームセンター要素）を含む。ホームセンターノードの下位には、ホームセンターで扱う商品である「机」、「椅子」及び「ベッド」に関する、机ノード７０１、椅子ノード７０２及びベッドノード７０３の３つの子ノードが存在する。このように、ホームセンターノードの３つの子ノードの構造は全て異なる。その一方、机ノード７０１、椅子ノード７０２及びベッドノード７０３の子ノードは、いずれも価格ノードである。

ここで、図７に示す構造化文書において、上述の商品のいずれかの価格が変更になった場合に通知が欲しいという場合に、クライアント端末２０は通知対象とするノード（つまり価格ノード）へのパスを曖昧性のあるパス「／／価格」で指定する。このような曖昧性のあるパスを用いて通知対象ノードを指定した場合、本変形例では、構造化文書管理システム１０における更新通知条件設定処理及び更新通知付き更新処理に、以下に述べる第１及び第２の手法のいずれかが適用される。

（１）第１の手法
第１の手法では、上記実施形態と同様の通知条件設定処理及び更新通知付き更新処理が行われる。

まず、第１の手法を適用した場合の更新通知条件設定処理について図５のフローチャートを援用して説明する。ここでは、「／／価格」のような曖昧性のあるパスも、上記実施形態で適用されたような明確なパスと同様に扱わる。つまり、クライアント端末２０が、「／／価格」及び「更新」の組を更新通知条件として設定することを構造化文書管理システム１０に要求した場合、更新通知管理部１０６は図５の判定ステップＳ２を実行する。

もし、要求された「／／価格」及び「更新」の組が更新通知条件管理テーブル１０８に登録されていないならば（図５ステップＳ２）、更新通知管理部１０６は当該「／／価格」及び「更新」の組をそのまま更新通知条件として更新通知条件管理テーブル１０８に追加する（図５ステップＳ３）。

次に、第１の手法を適用した場合の更新通知付き更新処理について図６のフローチャートを援用して説明する。ここでは更新通知管理部１０６は、更新通知条件管理テーブル１０８から曖昧性のあるパスを含む更新通知条件が取り出された場合に（図６ステップＳ１６）、更新操作が行われたノード（構造）が当該曖昧性のあるパスに含まれるかを判定する（図６ステップＳ１７）。

（２）第２の手法
第２の手法では、「／／価格」のような「曖昧性のあるパス」及び「更新操作の種類」（例えば「更新」）の組は、テーブル記憶部１０９内の更新通知条件管理テーブル１０８とは別の領域に、曖昧更新通知条件として格納される。図８は、テーブル記憶部１０９内に、更新通知条件管理テーブル１０８に加えて、「曖昧性のあるパス」を含む更新通知条件（曖昧更新通知条件）を格納する曖昧更新通知条件管理テーブル１１８が配置されている状態を示す。この場合、外部記憶装置１２には、曖昧更新通知条件管理テーブル１１８に対応する曖昧更新通知条件管理テーブルが格納される。構造化文書管理システム１０の立ち上げ時には、この曖昧更新通知条件管理テーブルが、テーブル記憶部１０９内に曖昧更新通知条件管理テーブル１１８としてロードされる。

次に、第２の手法を適用した場合の更新通知条件設定処理について、上記実施形態と相違する点を中心に、図９のフローチャートを参照して説明する。更新通知管理部１０６はクライアント端末２０が送信した更新通知条件設定要求をコマンド管理部１０１から受け取ると、当該要求で指定されている更新通知条件に「曖昧性のあるパス」が含まれているかを判定する（ステップＳ２１）。もし、「曖昧性のあるパス」が含まれていないならば、更新通知管理部１０６は図５のステップＳ２以降に相当する処理を実行する。

これに対し、「曖昧性のあるパス」が含まれているならば（ステップＳ２１）、更新通知管理部１０６は、当該「曖昧性のあるパス」を含む指定された更新通知条件が曖昧更新通知条件として曖昧更新通知条件管理テーブル１１８に既に登録されているかを判定する（ステップＳ２２）。もし、指定された更新通知条件が曖昧更新通知条件管理テーブル１１８に登録されていない場合には、更新通知管理部１０６は当該更新通知条件を曖昧更新通知条件として当該テーブル１１８に追加する（ステップＳ２３）。

次に更新通知管理部１０６は、指定された更新通知条件に含まれている「曖昧性のあるパス」を当該「曖昧性のあるパス」に一致する「明確なパス」に展開することで、指定された更新通知条件を、「明確なパス」を含む更新通知条件に展開する（ステップＳ２４）。ここで、更新操作の種類は、指定された更新通知条件から「明確なパス」を含む更新通知条件にそのまま引き継がれる。

「曖昧性のあるパス」が「／／価格」の場合、図７の構造化文書の例では、「／／価格」は、次の３つの「明確なパス」
／ホームセンター／机／価格
／ホームセンター／椅子／価格
／ホームセンター／ベッド／価格
に展開される。図７の構造化文書の場合、「曖昧性のあるパス」として「／＊／＊／価格」を用いても、上述した３つの「明確なパス」に展開される。

更新通知管理部１０６は、展開された「明確なパス」を含む更新通知条件の各々について、更新通知条件管理テーブル１０８に既に登録されているかを判定する（ステップＳ２５〜Ｓ２７）。もし、登録されていない場合には、更新通知管理部１０６は該当する更新通知条件を更新通知条件管理テーブル１０８に追加する（ステップＳ２８）。

次に、第２の手法を適用した場合の更新通知付き更新処理について、上記実施形態と相違する点を中心に、図１０のフローチャートを参照して説明する。

今、クライアント端末２０から構造化文書管理システム１０に対して、構造化文書に対する更新操作（更新、登録または削除）を指定する更新要求が送信されたものとする。この場合、構造化文書管理システム１０では、まず図６のステップＳ１１〜１４に相当する処理（ステップＳ３０）が実行される。

すると更新通知管理部１０６は、更新操作が行われたノードへのパス（を示すノード情報）が、更新通知条件管理テーブル１０８に登録されているかを判定する（ステップＳ３１）。もし、更新操作が行われたノードへのパスが、更新通知条件管理テーブル１０８に未登録の場合、更新通知管理部１０６はステップＳ３２に進む。

ステップＳ３２において更新通知管理部１０６は、更新操作が行われたノードへのパスが、曖昧更新通知条件管理テーブル１１８に登録されているいずれかの曖昧更新通知条件に合致するかを判定する。もし、更新操作が行われたノードへのパスが曖昧更新通知条件に合致するならば、更新通知管理部１０６は、当該パス（を示すノード情報）と更新操作の種類との組を含む更新通知条件を、更新通知条件管理テーブル１０８に追加する（ステップＳ３３）。

ここでは、更新操作が行われたノードへのパスが、既登録の更新通知条件に存在しなかったパス「／ホームセンター／犬小屋／価格」であったものとする（ステップＳ３１）。このパス「／ホームセンター／犬小屋／価格」は、曖昧更新通知条件「／／価格」に合致する（ステップＳ３２）。この場合、更新通知管理部１０６は、パス「／ホームセンター／犬小屋／価格」と更新操作の種類との組を含む更新通知条件を、更新通知条件管理テーブル１０８に追加する（ステップＳ３３）。このようにして上記の例では、通知対象ノードとして曖昧性のあるパス「／／価格」が更新通知条件設定要求で指定されたことに対応して、当該要求の受け付け時に３つのパス「／ホームセンター／机／価格」、「／ホームセンター／椅子／価格」及び「／ホームセンター／ベッド／価格」が更新通知条件管理テーブル１０８に登録されるだけでなく、実際の更新操作時に、パス「／ホームセンター／犬小屋／価格」が当該テーブル１０８に登録される。
ステップＳ３３が実行された後の動作は上記実施形態と同様であり、図６のステップＳ１５〜Ｓ１９に相当する処理（ステップＳ３４）が行われる。

なお、本発明は、上記実施形態またはその変形例そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態またはその変形例に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態またはその変形例に示される全構成要素から幾つかの構成要素を削除してもよい。

本発明の一実施形態に係る構造化文書管理システムを含むクライアント−サーバシステムのハードウェア構成を示すブロック図。 図１に示される構造化文書管理システムの主として機能構成を示すブロック図。 図１に示される構造化文書データベースに格納される構造化文書の一例を示す図。 図２に示される更新通知条件管理テーブルのデータ構造例を示す図。 同実施形態における更新通知条件設定処理の手順を示すフローチャート。 同実施形態における更新通知付き更新処理の手順を示すフローチャート。 同実施形態の変形例で適用される曖昧性のあるパスを説明するのに用いられる構造化文書の一例を示す図。 上記更新通知条件管理テーブルに加えて、同実施形態の変形例で適用される曖昧更新通知条件管理テーブルがテーブル記憶部に配置されている状態を示す図。 上記変形例において第２の手法を適用した場合の更新通知条件設定処理の手順を示すフローチャート。 上記変形例において第２の手法を適用した場合の更新通知付き更新処理の手順を示すフローチャート。

符号の説明

１０…構造化文書管理システム、１１…構造化文書管理サーバ（構造化文書管理サーバコンピュータ）、１２…外部記憶装置、２０…クライアント端末、３０…ネットワーク、１０１…コマンド管理部、１０２…ドキュメント管理部（構造化文書管理手段）、１０４…構造情報抽出部、１０６…更新通知管理部（一致性検証手段、更新通知手段、更新通知条件設定手段）、１０８，１２３…更新通知条件管理テーブル、１０９…テーブル記憶部、１１８…曖昧更新通知条件管理テーブル、１２１…構造化文書管理プログラム、１２２…構造化文書データベース。

Claims (5)

1. 構造化文書の集合を格納する構造化文書データベースと、
   任意のクライアント端末からの更新通知条件設定要求によって指定された、更新要求構造化文書に対する更新操作発生時の通知対象とするノードを示す第１のノード情報及び通知対象とする更新操作の種類を示す第１の更新操作種類情報を含む更新通知条件を記憶する記憶手段と、
   任意のクライアント端末からの更新要求に応じて、当該更新要求で指定された構造化文書に対して要求された更新操作を行う構造化文書管理手段であって、更新操作が行われたノードを示す第２のノード情報及び更新操作の種類を示す第２の更新操作種類情報を出力する構造化文書管理手段と、
   前記第２のノード情報の示すノード及び前記第２の更新操作種類情報の示す更新操作の種類の前記記憶手段に記憶されている更新通知条件に対する一致性を検証する一致性検証手段であって、ノード情報に関しては、当該更新通知条件に含まれている前記第１のノード情報の示すノードに対する前記第２のノード情報の示すノードの世代関係の有無に基づき一致性を検証する一致性検証手段と、
   前記一致性検証手段によって一致性が認められた場合に、対応する更新通知条件の設定を要求したクライアント端末に前記第２のノード情報及び前記第２の更新操作種類情報を通知する更新通知手段と
   を具備することを特徴とする構造化文書管理システム。
2. 前記第１及び第２のノード情報は、それぞれルートノードから該当するノードまでのパスを表す第１及び第２のパス文字列で構成されており、
   前記一致性検証手段は、世代関係の有無を、前記第２のパス文字列の前記第１のパス文字列に対する前方一致により検証する
   ことを特徴とする請求項１記載の構造化文書管理システム。
3. 任意のクライアント端末からの更新通知条件設定要求を受けて、当該更新通知条件設定要求によって指定された、前記第１のノード情報及び前記第１の更新操作種類情報を含む更新通知条件を前記記憶手段に設定登録する更新通知条件設定手段であって、前記第１のノード情報が複数の構造をまとめて示す特定表記を持つ場合に、前記構造化文書データベースに格納されている構造化文書から、当該特定表記を持つノード情報で指定されるノードを抽出することにより、前記特定表記を持つ第１のノード情報を、当該抽出されたノードを一意に特定する第１のノード情報に展開して、当該展開された第１のノード情報を含む更新通知条件を前記記憶手段に設定登録する更新通知条件設定手段を更に具備することを特徴とする請求項１記載の構造化文書管理システム。
4. 前記更新通知条件設定手段は、前記特定表記を持つ第１のノード情報を含む更新通知条件を曖昧更新通知条件として前記記憶手段に設定登録し、
   前記一致性検証手段は、前記第２のノード情報を前記第１のノード情報として含む更新通知条件が前記記憶手段に登録されていない場合、前記記憶手段に登録されている前記曖昧更新通知条件の中に、前記第２のノード情報の示すノードを通知対象ノードとする曖昧更新通知条件が存在するかを判定し、
   前記更新通知条件設定手段は、前記曖昧更新通知条件が存在する場合、前記第２のノード情報を前記第１のノード情報として含む更新通知条件を前記記憶手段に設定登録する
   ことを特徴とする請求項３記載の構造化文書管理システム。
5. 記憶手段を有するコンピュータであって、構造化文書データベースに格納される構造化文書を管理するコンピュータに、
   任意のクライアント端末からの更新通知条件設定要求によって指定された、更新要求構造化文書に対する更新操作発生時の通知対象とするノードを示す第１のノード情報及び通知対象とする更新操作の種類を示す第１の更新操作種類情報を含む更新通知条件を前記記憶手段に設定登録するステップと、
   任意のクライアント端末からの更新要求に応じて、当該更新要求で指定された構造化文書に対して要求された更新操作を行うステップと、
   前記更新操作が行われたノードを示す第２のノード情報及び更新操作の種類を示す第２の更新操作種類情報を出力するステップと、
   前記第２のノード情報の示すノード及び前記第２の更新操作種類情報の示す更新操作の種類の前記記憶手段に記憶されている更新通知条件に対する一致性を検証するステップであって、ノード情報に関しては、当該更新通知条件に含まれている前記第１のノード情報の示すノードに対する前記第２のノード情報の示すノードの世代関係の有無に基づき一致性を検証するステップと、
   一致性が認められた場合に、対応する更新通知条件の設定を要求したクライアント端末に前記第２のノード情報及び前記第２の更新操作種類情報を通知するステップと
   を実行させるためのプログラム。

Images