説明

構造化文書検証装置、構造化文書検証方法および構造化文書検証プログラム

【課題】対象となる構造化文書が大量に存在する場合であっても、構造化文書が文書型定義に合致するか否かの検証を効率的に行うことのできる構造化文書検証装置を提供する。
【解決手段】所定の文書型定義にしたがい記述された複数の構造化文書を保持する構造化文書保持手段114と、構造化文書に含まれる要素と、当該要素の構造位置とを対応付けた構造索引を保持する構造索引保持手段118と、文書型定義に含まれる各要素の構造位置を示すパス式を生成するパス式生成手段120と、構造化文書が文書型定義にしたがっているか否かの文書型検証を要求する検証指示を取得する検証指示取得手段130,140と、パス式に含まれる各要素の構造位置と、構造索引保持手段118が保持する構造索引に含まれる構造位置とを比較することにより、文書型検証を行う文書型検証手段134,142とを備えた。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、構造化文書の検証を行う構造化文書検証装置、構造化文書検証方法および構造化文書検証プログラムに関するものである。
【背景技術】
【0002】
構造化文書には、構造化文書に含まれる要素の関係を定義する文書型定義にしたがって記述されたものがある。文書型定義にしたがって記述された構造化文書を計算機プログラムで利用する場合には、文書型定義に合致することが確認された構造化文書のみを利用対象とすることが要求される場合がある。また、文書型定義にしたがって記述された構造化文書をデータベースに格納する場合も同様である。
【0003】
これらの場合には、構造化文書が文書型定義に合致するか否かを検証する必要がある。検証方法としては、文書型定義中の型定義をオートマトン化し、それに対象文書のnodeを順に入力していったときの状態遷移先が受理状態となるかどうかを調べる方法により検証を行う方法が知られている(例えば、「特許文献1」参照)。また、文書型定義を意味規則の集合として記述し、その規則を文書データに適用することで妥当性の検証を行う方法も知られている(例えば、「特許文献2」参照)。
【0004】
【特許文献1】特開2003−84987号公報
【特許文献2】特開2004−118850号公報
【発明の開示】
【発明が解決しようとする課題】
【0005】
しかしながら、すでにデータベースに構造化文書が格納された後の更新時や問い合わせ言語による検索時においても格納されている文書データ群が文書型定義に合致するかどうかの検証を行う必要がある。
【0006】
また、データベースに格納されている構造化文書を対象に、所定の検索式によって取得した対象データ群をある関数に渡すとき、対象データ群がその関数の引数が意図する型に合致するかを検証を行う必要がある。
【0007】
これらの場合においては、各構造化文書に対して、検証にかかる処理を行う必要があり、データベースに大量の構造化文書が格納されている場合には、処理量が増加するという問題があった。
【0008】
本発明は、上記に鑑みてなされたものであって、対象となる構造化文書が大量に存在する場合であっても、構造化文書が文書型定義に合致するか否かの検証を効率的に行うことのできる構造化文書検証装置、構造化文書検証方法および構造化文書検証プログラムを提供することを目的とする。
【課題を解決するための手段】
【0009】
上述した課題を解決し、目的を達成するために、本発明は、構造化文書検証装置であって、構造化文書に含まれる要素の関係を定義する文書型定義にしたがい記述された複数の構造化文書を保持する構造化文書保持手段と、前記構造化文書保持手段が保持する前記構造化文書に含まれる要素と、当該要素の前記構造化文書における構造位置とを対応付けた構造索引を保持する構造索引保持手段と、前記文書型定義を保持する文書型定義保持手段と、前記文書型定義保持手段が保持する前記文書型定義に基づいて、前記文書型定義に含まれる各要素の前記構造位置を示すパス式を生成するパス式生成手段と、前記構造化文書保持手段が保持する複数の前記構造化文書が、前記文書型定義にしたがっているか否かの文書型検証を要求する検証指示を取得する検証指示取得手段と、前記検証指示取得手段が前記検証指示を取得した場合に、前記パス式生成手段により生成された前記パス式に含まれる各要素の構造位置と、前記構造索引保持手段が保持する前記構造索引に含まれる構造位置とを比較することにより、前記文書型検証を行う文書型検証手段とを備えたことを特徴とする。
【0010】
また、本発明の他の形態は、構造化文書検証方法であって、構造化文書に含まれる要素の関係を定義する文書型定義を保持する文書型定義保持手段が保持する前記文書型定義に基づいて、前記文書型定義に含まれる各要素の前記構造位置を示すパス式を生成するパス式生成ステップと、前記文書型定義にしたがい記述された複数の構造化文書を保持する構造化文書保持手段が保持する複数の前記構造化文書が、前記文書型定義にしたがっているか否かの文書型検証を要求する検証指示を取得する検証指示取得ステップと、前記検証指示取得ステップにおいて前記検証指示を取得した場合に、前記パス式生成手段により生成された前記パス式に含まれる各要素の構造位置と、前記構造化文書保持手段が保持する前記構造化文書に含まれる要素と、当該要素の前記構造化文書における構造位置とを対応付けた構造索引を保持する構造索引保持手段が保持する前記構造索引に含まれる構造位置とを比較することにより、前記文書型検証を行う文書型検証ステップとを有することを特徴とする。
【0011】
また、本発明の他の形態は、構造化文書検証処理をコンピュータに実行させる構造化文書検証プログラムであって、構造化文書に含まれる要素の関係を定義する文書型定義を保持する文書型定義保持手段が保持する前記文書型定義に基づいて、前記文書型定義に含まれる各要素の前記構造位置を示すパス式を生成するパス式生成ステップと、前記文書型定義にしたがい記述された複数の構造化文書を保持する構造化文書保持手段が保持する複数の前記構造化文書が、前記文書型定義にしたがっているか否かの文書型検証を要求する検証指示を取得する検証指示取得ステップと、前記検証指示取得ステップにおいて前記検証指示を取得した場合に、前記パス式生成手段により生成された前記パス式に含まれる各要素の構造位置と、前記構造化文書保持手段が保持する前記構造化文書に含まれる要素と、当該要素の前記構造化文書における構造位置とを対応付けた構造索引を保持する構造索引保持手段が保持する前記構造索引に含まれる構造位置とを比較することにより、前記文書型検証を行う文書型検証ステップとを有することを特徴とする。
【発明の効果】
【0012】
本発明にかかる構造化文書検証装置によれば、構造化文書保持手段が、構造化文書に含まれる要素の関係を定義する文書型定義にしたがい記述された複数の構造化文書を保持し、構造索引保持手段が、構造化文書保持手段が保持する構造化文書に含まれる要素と、当該要素の構造化文書における構造位置とを対応付けた構造索引を保持し、文書型定義保持手段が、文書型定義を保持し、パス式生成手段が、文書型定義保持手段が保持する文書型定義に基づいて、文書型定義に含まれる各要素の構造位置を示すパス式を生成し、検証指示取得手段が、構造化文書保持手段が保持する複数の構造化文書が、文書型定義にしたがっているか否かの文書型検証を要求する検証指示を取得し、文書型検証手段が、検証指示取得手段が検証指示を取得した場合に、パス式生成手段により生成されたパス式に含まれる各要素の構造位置と、構造索引保持手段が保持する構造索引に含まれる構造位置とを比較することにより、文書型検証を行うので、対象となる構造化文書が大量に存在する場合であっても、効率的に構造化文書が文書型定義に合致するか否かの検証を効率的に行うことができるという効果を奏する。
【0013】
また、本発明の他の形態にかかる構造化文書検証方法によれば、パス式生成ステップにおいて、構造化文書に含まれる要素の関係を定義する文書型定義を保持する文書型定義保持手段が保持する文書型定義に基づいて、文書型定義に含まれる各要素の構造位置を示すパス式を生成し、検証指示取得ステップにおいて、文書型定義にしたがい記述された複数の構造化文書を保持する構造化文書保持手段が保持する複数の構造化文書が、文書型定義にしたがっているか否かの文書型検証を要求する検証指示を取得し、文書型検証ステップにおいて、検証指示取得ステップにおいて検証指示を取得した場合に、パス式生成手段により生成されたパス式に含まれる各要素の構造位置と、構造化文書保持手段が保持する構造化文書に含まれる要素と、当該要素の構造化文書における構造位置とを対応付けた構造索引を保持する構造索引保持手段が保持する構造索引に含まれる構造位置とを比較することにより、文書型検証を行うので、対象となる構造化文書が大量に存在する場合であっても、効率的に構造化文書が文書型定義に合致するか否かの検証を効率的に行うことができるという効果を奏する。
【0014】
また、本発明の他の形態にかかる構造化文書検証プログラムによれば、パス式生成ステップにおいて、構造化文書に含まれる要素の関係を定義する文書型定義を保持する文書型定義保持手段が保持する文書型定義に基づいて、文書型定義に含まれる各要素の構造位置を示すパス式を生成し、検証指示取得ステップにおいて、文書型定義にしたがい記述された複数の構造化文書を保持する構造化文書保持手段が保持する複数の構造化文書が、文書型定義にしたがっているか否かの文書型検証を要求する検証指示を取得し、文書型検証ステップにおいて、検証指示取得ステップにおいて検証指示を取得した場合に、パス式生成手段により生成されたパス式に含まれる各要素の構造位置と、構造化文書保持手段が保持する構造化文書に含まれる要素と、当該要素の構造化文書における構造位置とを対応付けた構造索引を保持する構造索引保持手段が保持する構造索引に含まれる構造位置とを比較することにより、文書型検証を行うので、対象となる構造化文書が大量に存在する場合であっても、効率的に構造化文書が文書型定義に合致するか否かの検証を効率的に行うことができるという効果を奏する。
【発明を実施するための最良の形態】
【0015】
以下に、本発明にかかる構造化文書検証装置、構造化文書検証方法および構造化文書検証プログラムの実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。
【0016】
図1は、実施の形態にかかる構造化文書検証装置10の機能構成を示すブロック図である。構造化文書検証装置10は、文書型定義取得部100と、文書型定義データベース(DB)102と、構造化文書取得部110と、第1検証部112と、構造化文書DB114と、構造索引生成部116と、構造索引DB118と、パス式生成部120と、パス式DB122と、更新要求取得部130と、パス式抽出部132と、第2検証部134と、更新部136と、検索条件取得部140と、第3検証部142と、出力部144とを備えている。
【0017】
文書型定義取得部100は、文書型定義を取得する。ここで、文書型定義とは、構造化文書に含まれる要素の関係に関する定義である。構造化文書としては、例えばXML(Extensible Markup Language)が、それに対する文書型定義としては、例えばXML Schemaによって記述されるものがある。
【0018】
図2は、文書型定義の一例を示す図である。文書型定義200のうち例えば記述202は、rootの下にnode1、node2およびnode3が存在することを示している。すなわち、この文書型定義200にしたがう構造化文書においては、rootの下にnode1、node2およびnode3が存在すれば、この部分は記述202にしたがって記述されていることがわかる。
【0019】
再び説明を図1に戻す。構造化文書取得部110は、構造化文書を取得する。さらに、構造化文書に対応する文書型定義を指定する情報を取得する。第1検証部112は、構造化文書取得部110が取得した構造化文書に対し文書型定義が指定されている場合には、構造化文書が対応する文書型定義に合致するか否かを検証する。具体的には、文書型定義DB102に格納されている文書型定義を利用して妥当性の検証を行う。なお、構造化文書に対する文書型定義が指定されていない場合には、妥当性検証は行わない。さらに、妥当でない場合には、第1検証部112は妥当でない旨を出力してもよい。
【0020】
構造化文書DB114は、構造化文書取得部110が取得した構造化文書を保持する。なお、第1検証部112による検証が行われた構造化文書については、妥当であると判断された構造化文書のみが対象となる。
【0021】
図3−1から図3−4は、構造化文書の一例を示す図である。なお、図3−1に示す構造化文書301、図3−2に示す構造化文書302および図3−3に示す構造化文書303は、文書型定義200にしたがい記述された構造化文書である。すなわち、これらの構造化文書301〜303は、第1検証部112により文書型定義200に合致すると判断されて構造化文書DB114に格納される。図3−4に示す構造化文書304は、文書型定義200に合致せず構造化文書DB114には格納されない。
【0022】
再び説明を図1に戻す。構造索引生成部116は、構造化文書取得部110が取得した構造化文書の構造索引を生成する。構造索引は、文書、数値、語彙など構造化文書の内容に対する索引である。第1検証部112による検証が行われた構造化文書については、妥当であると判断された構造化文書のみが構造索引の対象となる。
【0023】
図4は、構造索引のデータ構成を示す図である。構造索引においては、ノード位置と、ノードの有無とが対応付けられている。ノードとは、構造化文書における要素である。図4に示すようにノードは階層構造を有している。ノード位置は、この階層構造における位置を示す情報である。ノード位置は、構造位置に相当する。具体的には、所定のノードのノード位置は、このノードの1つ下の層のノード、すなわち子ノードとの関係により指定される。さらに、同一のノードを上位の層のノード、すなわち親ノードとするノードが複数存在する場合、すなわちノード位置が同一である場合には、各ノードは、要素オーダーにより識別される。
【0024】
例えば、図4に示す例においては、ノード位置は、node1の要素オーダー1、child1の要素オーダー1、要素オーダー2などノード名と、要素オーダーにより特定される。
【0025】
さらに、所定のノード位置にノードが存在する場合には、構造索引において、ノードIDがノード位置に対応付けられている。ノードIDとは、各ノードを含む構造化文書を識別し、さらにこの構造化文書内におけるノードに対応する記述を識別する情報である。図4に示す例においては、例えば、child3の要素オーダー5に対応付けられているノードIDにより、構造化文書114に格納されている所定の文書中の、child3に関する記述を特定することができる。
【0026】
図4に示す構造索引400は、構造化文書311,312により生成されたものである。構造化文書311に含まれるノードのノードIDを白丸で示している。構造化文書312に含まれるノードIDを黒丸で示している。
【0027】
構造化文書311,312は、ともにnode1のノードを含んでいる。したがって、構造索引400のnode1のノードには、構造化文書311,312のnode1に対するノードIDが格納されている。
【0028】
また、構造化文書311には、要素オーダー1にchild1のノードが存在する。したがって、構造索引400のうち、child1の要素オーダー1に対応付けて構造化文書311のchild1のノードIDが格納されている。また、構造化文書311のnode1の要素オーダー2には、child2が存在する。したがって、構造索引400において、child2の要素オーダー2に対応付けて構造化文書311のchild2のノードIDが格納されている。
【0029】
このように、構造索引は、構造化文書DB114に格納されている複数の構造化文書中の各ノードに対するノードIDとノード位置とを対応付けている。したがって、構造索引を参照することにより、構造化文書を参照しなくとも、所定のノード位置にノードが存在する構造化文書の数を特定することができる。さらに、node1のノードの下位にchild1のノードが存在するような、所定の関係を有する複数のノードを有する構造化文書の数を特定することができる。同一のパスを有する要素の有無についても特定することができる。
【0030】
再び説明を図1に戻す。パス式生成部120は、文書型定義取得部100が取得した文書型定義に基づいて、パス式を生成する。ここで、パス式は、基本的には文書型定義を検索式のようにXpathなどで記述したものである。パス式においては、さらに文書型定義における出現回数に関する条件やパスのオーダーを指定することができる。
【0031】
図5から図9は、パス式を生成する処理を説明するための図である。図5は、文書型定義に含まれる部分スキーマ210を示す図である。図6は、部分スキーマ210中のchild2に付与された条件と、条件にしたがい生成されるパス式とを示す図である。パス式生成部120は、この条件にしたがいパス式を生成する。なお、属性に関する必須指定があるものはそれを先頭にし、その後にノードに関する内容を記述する。図6に示す例において属性は、「@」以下に記述されている。
【0032】
図7は、文書型定義に含まれる部分スキーマ212を示す図である。図8は、部分スキーマ212における(x)部分における指定と、指定にしたがい生成されるパス式とを示す図である。パス式生成部120は、この指定にしたがいパス式を生成する。なお、{orderd}とは、パス式の記述通りの順序でなければならないことを示している。
【0033】
図9は、図2に示す文書型定義200中のnode2の定義204から生成されたパス式214を示す図である。パス式生成部120は、文書型定義200中のすべての定義をパス式に変換する。なお、図9に示すパス式において、[ ]中最後の「./ex:node2」は、node2が繰り返されることを示している。何回繰り返されるかは、対象とする構造化文書により異なる。このため、パス式生成部120は、「./ex:node2」はこれ以上は展開しない。パス式DB122は、パス式生成部120により生成されたパス式を格納する。各パス式はいずれの文書型定義に対応するかを識別する識別情報に対応付けて格納される。
【0034】
再び説明を図1に戻す。更新要求取得部130は、更新要求を取得する。更新要求とは、構造化文書DB114に格納されている1または2以上の構造化文書の内容を一部変更する更新要求である。更新要求には、更新すべき構造化文書を識別する文書IDが含まれている。さらに、一部を更新する場合には、更新する部分を指定する情報が含まれている。
【0035】
パス式抽出部132は、更新要求取得部130が更新要求を取得すると、構造化文書全体の更新である場合には構造化文書に対応するパス式をすべてパス式DB122から抽出する。構造化文書の一部の更新である場合には、構造化文書の一部に対応するパス式のみをパス式DB122から抽出する。構造化文書の一部についての更新としては、例えば、図3−1に示す構造化文書301のうちnode2の定義部分のみの更新がある。
【0036】
第2検証部134は、パス式抽出部132からパス式を取得する。さらに、構造索引DB118に格納されている構造索引を更新要求に示される更新内容にしたがって更新する。そして、更新後の構造索引と、パス式抽出部132から取得したパス式とを比較することにより検証を行う。
【0037】
更新部136は、第2検証部134による検証により妥当であると判断された場合、すなわち構造索引とパス式とが合致した場合には、更新後の文書を構造化文書DB114に、更新後の構造索引を構造索引DB118に登録する。
【0038】
検索条件取得部140は、検索条件を取得する。例えば、検索を行うための関数から検索条件を取得する。検索条件は、検索対象となる構造化文書を特定する情報を含んでおり、加えて、検索対象となる構造化文書に対する文書型定義を特定する情報を含んでいる。検索条件取得部140は、さらに妥当性検証に必要なパス式の抽出をパス式抽出部132に指示する。
【0039】
第3検証部142は、パス式抽出部132からパス式を取得する。さらに、構造索引DB118から、検索対象となっている構造化文書に対する構造索引を抽出する。そして、パス式と構造索引とを比較することにより検証を行う。出力部144は、第3検証部142による検証結果を出力する。例えば、所定の関数から検索条件を取得した場合には、この関数に対し検索結果を返す。
【0040】
図10は、構造化文書検証装置10による検索時の妥当性検証処理を示すフローチャートである。なお、構造化文書検証処理は、一般的なXPathの評価と、構造索引中のオーダー区分を確認する操作とを含む処理である。
【0041】
まず、検索条件取得部140は、検索条件を取得する(ステップS100)。ここで、検索条件は、文書型検証、すなわち妥当性検証を指示する妥当性検証指示を含んでいる。検索条件により特定される文書型定義を特定する(ステップS102)。次に、この文書型定義に対応するパス式、すなわち検証対象となるパス式がパス式DB122に格納されている場合には(ステップS104,Yes)、ステップS110へ進む。
【0042】
一方、検証対象となるパス式がパス式DB122に格納されていない場合には(ステップS104,No)、検索条件取得部140は、パス式生成部120にパス式生成を指示する。すなわち、検索条件取得部140は、パス式生成制御手段として機能する。
【0043】
パス式生成部120は、検証対象となる文書型定義に基づいて、パス式を生成する(ステップS106)。次に、パス式生成部120は、パス式をパス式DB122に登録する(ステップS108)。次に、第3検証部142は、構造索引DB118から検証対象となる構造索引を抽出する(ステップS110)。さらに、第3検証部142は、パス式DB122から検証対象となるパス式を抽出する(ステップS112)。そして、第3検証部142は、パス式と構造索引とを比較することにより、文書型検証を行う(ステップS114)。
【0044】
構造索引がパス式に合致した場合には(ステップS116,Yes)、構造索引に含まれるすべての構造化文書が妥当であるので、すべての構造化文書を検索に関する関数に返す(ステップS122)。一方、パス式に合致しない場合には(ステップS116,No)、さらに構造化文書DB114における構造化文書を調べることにより、パス式に合致しない構造化文書または合致する構造化文書を特定する(ステップS124)。そして、パス式に合致する構造化文書のみを検索に関する関数に返す(ステップS126)。以上で、構造化文書検証装置10による検索時の妥当性検証処理が完了する。
【0045】
このように、構造化文書DB114に格納されている構造化文書の数にかかわらず、構造索引とパス式とを比較するだけで妥当性検証を行うことができるので、処理の効率化を図ることができる。
【0046】
図11は、図3−1から図3−3に示される構造化文書301〜303により作成された構造索引410を示す図である。この構造索引のうち「node2」の部分が対応する文書型定義に合致するか否かを検証する処理について図10にしたがい具体的に説明する。
【0047】
まず、検索条件を取得すると(ステップS100)、検索対象となる文書型定義を特定する(ステップS102)。次に、文書型定義に対応するパス式がパス式DB122に格納されているか否かを確認する(ステップS104)。格納されている場合には(ステップS104,Yes)、ステップS110へ進む。格納されていない場合には、対象となる文書型定義からパス式を生成し(ステップS106)、パス式DB122に格納する(ステップS108)。
【0048】
次に、検証対象となる構造索引、すなわち図11に示す構造索引を構造索引DB118から抽出する(ステップS110)。次に、検証対象となるパス式をパス式DB122から抽出する(ステップS112)。例えば、図9に示すパス式214の繰り返し部分のように展開すべき部分を含む場合には、この部分を構造索引にあわせて展開する。具体的には、構造索引410が定まるとnode2の子ノードとして存在するnode2の数がわかる。そこで、この数だけnode2をパス式に展開する。
【0049】
図11に示す構造索引410に対して展開されるパス式は、以下のようになる。

./node2[./n2child1 and ./n2child2{2-3}or ./n2child3 or ./node2[./n2child1 and ./n2child2{2-3} or ./n2child3 or ./node2[./n2child1 and ./n2child2{2-3}or ./n2child3] {ordered}]{ordered}]{ordered}
【0050】
図11に示す例においては、ノード412の下位にノード414が存在する。ノード414の下位には、ノード416が存在する。これに対応して、図12に示すようにnode2が3回現れるパス式が展開される。
【0051】
次に、第2検証部134は、パス式にしたがい検証を行う(ステップS114)。なお、パス式の左側の記述から順に検証する。まず必須の「att1」属性存在を調べると、構造索引410に確かに存在する。
【0052】
次に{ordered}の指定に従いパス式の左から順に調べる。具体的には、「n2child1」の存在を調べる。「n2child1」のノード421を抽出する。ノード421の各ノードIDは、すべて要素オーダー1に対応付けられている。したがって、3つの構造化文書301〜303は、いずれもパス式の「n2child1」に合致する。
【0053】
次に、「n2child2」について調べる。「n2child2」のノード422が抽出される。さらに、パス式の{2−3}からノード422におけるノードIDの出現回数が2−3個であるか否かを調べる。いずれの構造化文書においても先の「n2child1」にノードIDが必ず1つ存在する。したがって、「n2child2」に対応付けられているノードIDは、要素オーダー2以降に対応付けられているはずである。したがって、要素オーダー4までに2−3個のノードIDが対応付けられているはずである。構造化文書が3つあるので、「n2child2」のノード422には、最小で6個、最大で9個のノードIDが対応付けられているはずである。
【0054】
実際には、ノード422においては、要素オーダー2〜4に7個のノードIDが対応付けられている。したがって、3つの構造化文書301〜303は、いずれもパス式の「n2child2{2−3}」に合致する。
【0055】
次に、「n2child3」について調べる。「n2child3」に対応するノードIDは存在しなくてもよい。また、存在する場合には、要素オーダー4または5以降に対応付けられているはずである。「n2child2」に要素オーダー2以降が割り当てられ、かつ2〜3個のノードIDが対応付けられているためである。
【0056】
実際には、「n2child3」のノード423においては、要素オーダー4に1つのノードIDのみが対応付けられている。したがって、残り2つの構造化文書においては、「n2child3」に対応するノードIDは存在しない。すなわち、3つの構造化文書301〜303は、いずれもパス式の「n2child3」に合致する。
【0057】
次に、「node2」について調べる。「node2」に対応するノードIDは存在しなくてもよい。存在する場合には、要素オーダー4以降に対応付けられているはずである。
【0058】
実際には、「node2」のノード414においては、要素オーダー4と5にそれぞれ1つずつノードIDが対応付けられている。したがって、残り1つの構造化文書においては、「node2」に対応するノードIDは存在しない。すなわち、3つの構造化文書301〜303は、いずれもパス式の「node2」に合致する。以上の処理をパス式の最後まで行うことにより、構造索引410がパス式に合致しているか否かがわかる。
【0059】
構造索引410においては、「/root/node2」以下のノードに対してパス式が成り立つことがわかる。したがって、「/root/node2」以下のデータ群は、node2に対するパス式に合致し(ステップS116,Yes)、すべての構造化文書301〜303が関数に返される(ステップS122)。
【0060】
図12は、図3−1から図3−4に示される構造化文書301〜304により作成された構造索引430を示す図である。構造索引430に対し、図9に示すパス式214を適用する場合には、パス式抽出部132は、まずパス式214の「/ex.node2」を展開する。これにより、構造索引410に対して得られるパス式と同様のパス式が得られる。
【0061】
このパス式に対し検証を行うと(ステップS114)、属性のノード431、node2のノード432、n2child1のノード433、n2child2のノード434、n2child3のノード435、node2のノード436、n2child1のノード437、n2child2のノード438、n2child3のノード439までパス式に合致する。
【0062】
node2のノード440においては、要素オーダー4以降にノードIDが対応付けられているはずである。しかし、構造索引430においては、要素オーダー3にもノードIDが対応付けられている。したがって、パス式に合致ない。
すなわち、パス式に合致せず(ステップS116,No)、合致する構造化文書のみが関数に返される(ステップS126)。
【0063】
以上のように、文書型定義に基づいて作成したパス式と構造索引のみを利用することにより、構造化文書DB114に格納されている複数の構造化文書に対する妥当性検証を行うことができる。
【0064】
図13は、構造化文書検証装置10による更新時の妥当性検証処理を示すフローチャートである。更新時の構造化文書検証処理においては、まず、更新要求取得部130は、更新要求を取得する(ステップS140)。更新要求は、妥当性検証指示を含んでいる。次に、更新要求取得部130は、更新対象となる文書型定義を特定する(ステップS142)。次に、この文書型定義に対応するパス式、すなわち更新対象となるパス式がパス式DB122に格納されている場合には(ステップS144,Yes)、ステップS150へ進む。
【0065】
一方、更新対象となるパス式がパス式DB122に格納されていない場合には(ステップS144,No)、更新要求取得部130は、パス式生成部120にパス式生成を指示する。パス式生成部120は、更新対象となる文書型定義に基づいて、パス式を生成する(ステップS146)。すなわち、更新要求取得部130は、パス式生成制御手段として機能する。
【0066】
次に、パス式生成部120は、パス式をパス式DB122に登録する(ステップS148)。次に、第2検証部134は、構造索引DB118から更新対象となる構造索引を抽出する(ステップS150)。次に、更新部136は、抽出された構造索引を更新要求にしたがい更新する(ステップS152)。次に、パス式抽出部132は、パス式DB122から更新対象となるパス式を抽出する(ステップS154)。そして、第2検証部134は、パス式と更新後の構造索引とを比較することにより、文書型検証を行う(ステップS156)。
【0067】
構造索引がパス式に合致した場合には(ステップS158,Yes)、構造索引に含まれるすべての構造化文書が妥当であるので、更新部136は、更新後の構造索引を構造索引DB118に登録する。すなわち、構造索引DB118を更新する(ステップS160)。次に、更新部136は、更新要求にしたがい、構造化文書DB114を更新する(ステップS162)。一方、パス式に合致しない場合には(ステップS158,No)、エラーを通知する(ステップS164)。以上で、構造化文書検証装置10による更新時の妥当性検証処理が完了する。
【0068】
このように、更新時においても、構造索引のみを参照することにより、更新後の構造化文書に対する妥当性検証を行うことができる。したがって、更新内容が複数の構造化文書にわたる場合であっても、構造索引のみを参照するだけで妥当性検証を行うことができるので、処理の効率化を図ることができる。
【0069】
図14は、実施の形態1にかかる構造化文書検証装置10のハードウェア構成を示す図である。構造化文書検証装置10は、ハードウェア構成として、構造化文書検証装置10における構造化文書検証処理を実行する構造化文書検証プログラムなどが格納されているROM52と、ROM52内のプログラムに従って構造化文書検証装置10の各部を制御するCPU51と、構造化文書検証装置10の制御に必要な種々のデータを記憶するRAM53と、ネットワークに接続して通信を行う通信I/F57と、各部を接続するバス62とを備えている。
【0070】
先に述べた構造化文書検証装置10における構造化文書検証プログラムは、インストール可能な形式又は実行可能な形式のファイルでCD−ROM、フロッピー(登録商標)ディスク(FD)、DVD等のコンピュータで読み取り可能な記録媒体に記録されて提供されてもよい。
【0071】
この場合には、構造化文書検証プログラムは、構造化文書検証装置10において上記記録媒体から読み出して実行することにより主記憶装置上にロードされ、上記ソフトウェア構成で説明した各部が主記憶装置上に生成されるようになっている。
【0072】
また、本実施の形態の構造化文書検証プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。
【0073】
以上、本発明を実施の形態を用いて説明したが、上記実施の形態に多様な変更または改良を加えることができる。
【0074】
そうした変更例としては、本実施の形態においては、第1検証部112は、文書型定義に基づいて構造化文書の妥当性検証を行っていたが、これにかえて、第2検証部134や第3検証部142と同様に、構造索引を参照して構造化文書の妥当性検証を行ってもよい。
【図面の簡単な説明】
【0075】
【図1】構造化文書検証装置10の機能構成を示すブロック図である。
【図2】文書型定義の一例を示す図である。
【図3−1】構造化文書の一例を示す図である。
【図3−2】構造化文書の一例を示す図である。
【図3−3】構造化文書の一例を示す図である。
【図3−4】構造化文書の一例を示す図である。
【図4】構造索引のデータ構成を示す図である。
【図5】文書型定義に含まれる部分スキーマ210を示す図である。
【図6】部分スキーマ210中のchild2に付与された条件と、条件にしたがい生成されるパス式とを示す図である。
【図7】文書型定義に含まれる部分スキーマ212を示す図である。
【図8】部分スキーマ212における(x)部分における指定と、指定にしたがい生成されるパス式とを示す図である。
【図9】図2に示す文書型定義200中のnode2の定義204から生成されたパス式を示す図である。
【図10】構造化文書検証装置10による検索時の妥当性検証処理を示すフローチャートである。
【図11】図3−1から図3−3に示される構造化文書301〜303により作成された構造索引410を示す図である。
【図12】図3−1から図3−4に示される構造化文書301〜304により作成された構造索引430を示す図である。
【図13】構造化文書検証装置10による更新時の妥当性検証処理を示すフローチャートである。
【図14】実施の形態1にかかる構造化文書検証装置10のハードウェア構成を示す図である。
【符号の説明】
【0076】
10 構造化文書検証装置
51 CPU
52 ROM
53 RAM
57 通信I/F
62 バス
100 文書型定義取得部
102 文書型定義DB
110 構造化文書取得部
112 第1検証部
114 構造化文書DB
116 構造索引生成部
118 構造索引DB
120 パス式生成部
122 パス式DB
130 更新要求取得部
132 パス式抽出部
134 第2検証部
136 更新部
140 検索条件取得部
142 第3検証部
144 出力部

【特許請求の範囲】
【請求項1】
構造化文書に含まれる要素の関係を定義する文書型定義にしたがい記述された複数の構造化文書を保持する構造化文書保持手段と、
前記構造化文書保持手段が保持する前記構造化文書に含まれる要素と、当該要素の前記構造化文書における構造位置とを対応付けた構造索引を保持する構造索引保持手段と、
前記文書型定義を保持する文書型定義保持手段と、
前記文書型定義保持手段が保持する前記文書型定義に基づいて、前記文書型定義に含まれる各要素の前記構造位置を示すパス式を生成するパス式生成手段と、
前記構造化文書保持手段が保持する複数の前記構造化文書が、前記文書型定義にしたがっているか否かの文書型検証を要求する検証指示を取得する検証指示取得手段と、
前記検証指示取得手段が前記検証指示を取得した場合に、前記パス式生成手段により生成された前記パス式に含まれる各要素の構造位置と、前記構造索引保持手段が保持する前記構造索引に含まれる構造位置とを比較することにより、前記文書型検証を行う文書型検証手段と
を備えたことを特徴とする構造化文書検証装置。
【請求項2】
前記パス式生成手段は、前記文書型定義に基づいて、各要素の出現順番および出現回数を示す前記パス式を生成することを特徴とする請求項1に記載の構造化文書検証装置。
【請求項3】
前記検証指示取得手段は、前記構造化文書保持手段が保持する複数の構造化文書の一部についての前記文書型検証を要求する前記検証指示を取得し、
前記文書型検証手段は、前記検証指示が指定する前記構造化文書の一部に対応する前記パス式に含まれる各要素の構造位置と、前記構造索引保持手段が保持する前記構造索引のうち前記構造文書の一部に対応する構造位置とを比較することにより、前記文書型検証を行うことを特徴とする請求項1または2に記載の構造化文書検証装置。
【請求項4】
前記パス式生成手段により生成された前記パス式を保持するパス式保持手段と、
前記検証指示取得手段が前記検証指示を取得したときに、前記パス式保持手段が前記パス式を保持しない場合に、前記パス式生成手段に対し前記パス式の生成を指示するパス式生成制御手段と
をさらに備え、
前記パス式生成手段は、前記パス式生成制御手段により前記パス式の生成を指示された場合に、前記パス式を生成することを特徴とする請求項1から3のいずれか一項に記載の構造化文書検証装置。
【請求項5】
構造化文書に含まれる要素の関係を定義する文書型定義を保持する文書型定義保持手段が保持する前記文書型定義に基づいて、前記文書型定義に含まれる各要素の前記構造位置を示すパス式を生成するパス式生成ステップと、
前記文書型定義にしたがい記述された複数の構造化文書を保持する構造化文書保持手段が保持する複数の前記構造化文書が、前記文書型定義にしたがっているか否かの文書型検証を要求する検証指示を取得する検証指示取得ステップと、
前記検証指示取得ステップにおいて前記検証指示を取得した場合に、前記パス式生成手段により生成された前記パス式に含まれる各要素の構造位置と、前記構造化文書保持手段が保持する前記構造化文書に含まれる要素と、当該要素の前記構造化文書における構造位置とを対応付けた構造索引を保持する構造索引保持手段が保持する前記構造索引に含まれる構造位置とを比較することにより、前記文書型検証を行う文書型検証ステップと
を有することを特徴とする構造化文書検証方法。
【請求項6】
構造化文書検証処理をコンピュータに実行させる構造化文書検証プログラムであって、
構造化文書に含まれる要素の関係を定義する文書型定義を保持する文書型定義保持手段が保持する前記文書型定義に基づいて、前記文書型定義に含まれる各要素の前記構造位置を示すパス式を生成するパス式生成ステップと、
前記文書型定義にしたがい記述された複数の構造化文書を保持する構造化文書保持手段が保持する複数の前記構造化文書が、前記文書型定義にしたがっているか否かの文書型検証を要求する検証指示を取得する検証指示取得ステップと、
前記検証指示取得ステップにおいて前記検証指示を取得した場合に、前記パス式生成手段により生成された前記パス式に含まれる各要素の構造位置と、前記構造化文書保持手段が保持する前記構造化文書に含まれる要素と、当該要素の前記構造化文書における構造位置とを対応付けた構造索引を保持する構造索引保持手段が保持する前記構造索引に含まれる構造位置とを比較することにより、前記文書型検証を行う文書型検証ステップと
を有することを特徴とする構造化文書検証プログラム。

【図1】
image rotate

【図2】
image rotate

【図3−1】
image rotate

【図3−2】
image rotate

【図3−3】
image rotate

【図3−4】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate

【図14】
image rotate


【公開番号】特開2008−83857(P2008−83857A)
【公開日】平成20年4月10日(2008.4.10)
【国際特許分類】
【出願番号】特願2006−261352(P2006−261352)
【出願日】平成18年9月26日(2006.9.26)
【出願人】(000003078)株式会社東芝 (54,554)
【Fターム(参考)】