JP4236055B2 - 構造化文書処理装置、方法、プログラム - Google Patents

Description

本発明は、構造化文書処理装置、方法、プログラムに関する。更に詳しくは、電子データ化された構造化文書の構文解析処理を高速化する構造化処理装置、処理方法、および処理プログラムに関する。

近年、オブジェクト指向技術の発展に伴い電子データ化された構造化文書は様々な分野で利用されている。特に、インターネットの普及、Ｗｅｂサービスの進歩によって、構造化文書の一つであるＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）はますます普及してきている。ＸＭＬは、ＳＯＡ（Ｓｅｒｖｉｃｅ Ｏｒｉｅｎｔｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）や、グリッド・コンピューティングなどのソフトウェア基盤上でも広く使われ、それを処理するＸＭＬパーサ（ＸＭＬプロセッサともいう）がいくつかのベンダから提供されている。ＸＭＬパーサは、ＸＭＬ文書を構文解析し、アプリケーションがＸＭＬ文書を利用しやすくするための処理を行うためのＸＭＬの基本技術であり、ＸＭＬの更なる性能向上を追及することは極めて重要である。

そこで、特許文献１のように解析済み構造化文書とこれから解析しようとする構造化文書の差分解析に基づいてＸＭＬパーサの処理を高速化する試みがなされている。特許文献１にて発案されたＸＭＬパーサの高速化はメッセージの類似性を利用している。ここで、類似性を検知する機構としてはオートマトンを採用し、実行時にＸＭＬ文書から動的に状態遷移列（オートマトン）を形成する。また、バイト列レベルでの比較を行うことで効率的かつ高速にメッセージを比較し、差分だけを処理することで高速化を実現している。
特願２００４−３１４７１３号

本発明では、特許文献１において提案されたＸＭＬパーサ（以下、Ｄｅｌｔａｒｓｅｒと呼ぶ）の更なる向上を目指すために、以下の課題を解決することを目的とする。

Ｄｅｌｔａｒｓｅｒで提案されたオートマトンは、ＳＡＸ（Ｓｉｍｐｌｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ ｆｏｒ ＸＭＬ）イベントの粒度で状態が定義され、その状態遷移列（状態遷移図情報）として形成される。ここで、ＳＡＸイベントは、ＸＭＬ文書を解析しながら、要素（Ｅｌｅｍｅｎｔ）の始まりや終わりなどを検出するごとにアプリケーション・プログラムに対してイベントを通知するインターフェイスである。

しかし、上記の状態遷移はバイト列比較と比べるとコスト（時間）がかかる処理であり、従来の手法では状態数または遷移数の増大による性能低下が見られる。状態遷移を定義する上で状態の粒度が細かければ、バイト列比較のときの成功率が高くなるが、その反面、ドキュメント全体にかかるバイト列比較の時間は増大する。よって、高速なＸＭＬパーサを構築するために、如何に最適な粒度で状態を定義し、オートマトンを形成するかが課題である。

また別の課題は、差分解析のために必要なオートマトンの新たな状態列を作るコストである。状態を作る際には、部分処理するために必要なコンテキストを保存する、バイト列のコピーをする、などを伴いそのコストがオーバヘッドとなる。よって、如何に実行時に新しい状態遷移を作ることを避けるかが課題となる。

上述の本発明が解決する課題を更に詳しく述べる。

＜状態遷移数の増加による性能低下＞
特許文献１の発明では、オートマトンの構成方法としては、ＳＡＸイベントを一つの状態として表現していた。図１のグラフは、状態遷移数に伴う処理時間の変化を実験により計測したグラフである。図１は、同一のドキュメント（６４ＫＢのファイルサイズ）を用意し、構成する状態数（ｘ軸）を変化させたときの、バイト列マッチングにかかる平均処理時間（ｍｓ）を示す。このグラフからわかるように、状態遷移数が多いほど、処理時間が単調に増加することがわかる。例えば、空白を一つの状態として表現したときと、空白を他の状態に統合した場合は、状態数が１２０００から８０００と４０００程少なくなり、バイト列マッチングだけにかかるコストも３．２５（ｍｓ）から２．４（ｍｓ）とその性能差は約３０％になる。この実験からもわかるように、状態遷移は少なければ少ないほど差分処理によるオーバヘッドが少ない。

しかし、逆に状態数が少なければいいというものではない。状態数が少ないと、それだけ、ミスマッチの確率が高くなり、結果として状態を新たに作るコストがオーバヘッドとなる。状態遷移数をできるだけ少なく、かつマッチするようなオートマトンに最適化していくことが重要である。

＜状態遷移を作るコストが大きい＞
特許文献１の発明は、構造化文書間の差分解析を行うことによって高速化されたＸＭＬパーサであるＤｅｌｔａｒｓｅｒの基本処理を開示したものである。Ｄｅｌｔａｒｓｅｒは、差分検出を効率的に行うために、ドキュメント（文書）から実行時に動的にオートマトンを生成する。ここで、オートマトンの一つの状態遷移はＳＡＸイベントの単位であるが、通常のＸＭＬパーサの処理と比較して、状態を作るコストは高く、その処理が頻繁に起こらないようにすることが全体としての性能向上につながる。

図２は、横軸に解析するＸＭＬ文書数、縦軸に解析時間をとって、Ｄｅｌｔａｒｓｅｒと既存のＸＭＬパーサ（ＸｅｒｃｅｓやＰｉｃｃｏｌｏ）を比較したものである。例えば、ＤｅｌｔａｒｓｅｒとＸｅｒｃｅｓを比較すると、入力数が２５を超えるまでは、Ｘｅｒｃｅｓの方が高速であることがわかる。スキーマ情報を用いて、あらかじめオートマトンを構築することができれば、この部分のコストを削減し、全域でＤｅｌｔａｒｓｅｒの優位性を示すことが可能になる。

以上に述べた課題を解決すべく、本発明ではインスタンス文書の統計情報と、スキーマ情報を用いることによるオートマトンの最適化手法を提案する。スキーマ情報は、あらかじめ状態遷移列を作るのに要するコストを削減でき、更にオートマトンの状態数／遷移数を最適化することができる。これらの最適化によってＸＭＬパーサなどの構文解析処理を高速化することができる。

なお、構造化文書の例としては、ＸＭＬの他、ＸＨＴＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）、ＳＧＭＬ（Ｓｔａｎｄａｒｄ Ｇｅｎｅｒａｌｉｚｅｄ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）があげられる。

具体的には以下の解決手段を有する構造化文書の処理装置、処理方法、処理プログラムを提供する。これらの装置、方法、プログラムは実施形態が異なるのみで実質的な技術内容は同一であるので、以下では代表して構造化文書処理装置における解決手段について説明する。

（１）電子データ化された構造化文書を構文解析する構造化文書処理装置であって、本装置は、オートマトン生成部によって、構造化文書を区分化可能とする複数の状態の状態遷移列を生成する。この状態遷移列（オートマトン）の生成の際、構造化文書の実体であるインスタンス文書の統計情報を用いて状態遷移状態列における遷移状態の統合と前記統計情報を用いて遷移状態の反復的要素が出現する回数のパターンを統計的に求めるインスタンス文書解析部を本装置は備える。また、本装置は構造化文書から状態遷移列を生成の際、構造化文書の情報の構造や形式を定義するスキーマ情報を用いて状態遷移列における状態遷移の統合を行うスキーマ情報解析部を備える。更に、インスタンス文書解析部とスキーマ情報解析部が生成したオートマトンを相互に最適化するオートマトン最適化部とを備える。インスタンス文書解析部とスキーマ情報解析部は共にオートマトンを最適化するが、一方で最適化したオートマトンを他方で更に最適化することができる。

（２）前記の構造化文書がＸＭＬ文書であり、前記の区分化可能とする複数の状態がＳＡＸイベントで定義される、（１）に記載の構造化文書処理装置を提供する。（１）の装置は、構造化文書として特にＸＭＬに限定しないが、本明細書の実施形態では、構造化文書がＸＭＬ、状態を特定するのがＳＡＸイベントの場合を想定して記述する。

（３）前記のインスタンス文書解析部における前記状態遷移の統合において、前記状態遷移ごとにＩＤを付加し、連続的にマッチする状態遷移をＩＤのリストとして記憶し、このＩＤのリストを用いて連続的にマッチする状態遷移の回数をカウントする連続状態遷移計数部を更に備える、（１）に記載の構造化文書処理装置を提供する。これは、状態遷移の統合の具体的手段を示したものである。

（４）前記のオートマトン最適化部は、インスタンス文書解析部が検知する反復的要素に対して、反復的要素が入れ子になっている場合にも最適化する、（１）に記載の構造化文書処理装置を提供する。

（５）前記のインスタンス文書解析部において、構造化文書の中の要素間に出現する任意の数の空白文字のパターンを統計情報によって同定する、（１）に記載の文書構造解析装置を提供する。

上記の（３）〜（５）は、状態遷移の統合の具体的手段を示したものである。詳しくは後述する。

以上のような解決手段を備えた構造化文書処理装置は、構造化文書を状態解析した結果生成する状態遷移列をインスタンス文書やスキーマ情報を用いて統合する。インスタンス文書を用いたオートマトンの最適化とスキーマ情報を用いた最適化は、前述したように互いに離反的なものでなく一方の最適化の後、更に最適化することも可能である。このような処理によって、後に構文解析が必要な状態数を減らす作用を奏し、状態遷移にかかるコストを削減することができる。

本発明によれば、ＸＭＬなどの構造化文書処理において、入力としているインスタンス文書から動的に統計情報を取得し、高速な解析を行う技術と、スキーマ情報という静的な情報を組み合わせることで、既に述べた課題を解消することができる。したがって、Ｄｅｌｔａｒｓｅｒなどの構造化文書処理装置の適用範囲を広げることが可能となる。

以下、本発明を実施形態に即して図を参照しながら説明する。

図３は、本発明の一つの実施形態に係る構造化文書処理装置１０の機能ブロックの概略を示したものである。ただし、以下の説明に示される構成は一例であり、本発明はかかる構成に限定されるものではない。

構造化文書処理装置１０は、操作員等の入力を受付ける入力部１、処理された結果を出力する出力部２、入出力データや中間データを記憶する記憶部４を含む。更に、構造化文書処理装置１０は、入力されたインスタンス文書を解析するインスタンス文書解析部５、あらかじめ定められたスキーマ言語によって定義されたスキーマ情報を解析するスキーマ情報解析部６、状態遷移列（オートマトン）を生成するオートマトン生成部７ａ、およびインスタンス文書解析部５とスキーマ情報解析部が統合した状態遷移列を相互に最適化するオートマトン最適化部７、構造化文書をさまざまな構文を解析する文書構文解析部８、および構文解析処理された結果を、必要とするアプリケーション・プログラムに通知し、アプリケーション・プログラムとのインターフェイスとなるＡＰＩ部９とを備える。

入力部１は、キーボードやマウスなどの一般的な入力装置の他、データをファイルとして受付ける入力手段を含む。出力部２は、ＣＲＴや液晶装置のような表示装置の他、データをファイルとして出力する出力手段を含む。また、オプションとして通信部３を備え、外部のシステムとデータの入出力を通信で行うようにしてもよい。

本処理装置の入力データである構造化文書２０には、インスタンス文書２１とスキーマ情報２２が含まれる。ただしスキーマ情報は省略され得る。スキーマ情報が省略された場合は、あらかじめ定められたＤｅｆａｕｌｔが使用される。インスタンス文書２１は、構造化文書２０の実体であり、入力部を介してインスタンス文書解析部５によって、状態解析される。状態解析されたデータ（状態遷移列）はインスタンス文書統計情報４ａとして記憶部４に蓄積される。この状態解析された文書は解析済み元構造化文書４ｂとして、次に解析されるべき構造化文書の差分解析のために利用される。

また、インスタンス文書解析部５は、複数の状態遷移を統合させるために、状態遷移ごとにＩＤを付加し、連続的にマッチする状態遷移をＩＤのリストとして記憶し、そのＩＤリストを用いて連続的にマッチする状態遷移の回数をカウントする処理を行う機能を持つ連続状態遷移計数部（図示せず）を含む。

スキーマ情報解析部６は、例えば、ＤＴＤ（Ｄｏｃｕｍｅｎｔ Ｔｙｐｅ Ｄｅｆｉｎｉｔｉｏｎ）やＷ３Ｃ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ） ＸＭＬ Ｓｃｈｅｍａなどのスキーマ言語によって作成されたＸＭＬ文書の構造や形式を定義するスキーマ情報を解析する。

インスタンス文書の統計情報やスキーマ情報を用いた処理の詳細については、後述する。

文書構文解析部８は、構造化文書２０の構文の中身を実際に解析する。例えばＸＭＬ文書では要素や内容を解析して、ＳＡＸイベントやＤＯＭツリーといったアプリケーション・プログラムが利用しやすい形に変換する。この際に新たに解析すべき構造化文書２０の状態遷移列と、記憶部４に蓄積した既に解析済みの解析済み元構造化文書４ｂ群の状態遷移列との差分を検知し、差分のみを解析することによって処理効率をあげている。本明細書では後述するように、この状態遷移列を表現したものとして状態遷移図を示している。

なお、差分解析の具体的方法については特許文献１に示されているので本明細書では記載を省略する。

アプリケーション・プログラム３０は、ＡＰＩを通して本構造化文書解析装置にアクセスする。ＡＰＩ部（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）９は、例えばＸＭＬ文書の場合、ＤＯＭや、ＳＡＸといった標準的なインターフェイスを提供する。なお、ＡＰＩ部９は、特に図示していないが、広義の入出力部としての役割も果たす。

上記の説明によって明らかなように、構造化文書処理装置１０は、パーソナルコンピュータやサーバのようなコンピュータであってよく、必要な機能を備えたコンピュータプログラムをインストールすることで実現される。以下、構造化文書処理装置１０が行う処理手法の内容について説明する。

前述の課題で述べたように、オートマトンの状態遷移に伴うパフォーマンスへの影響は小さくない。この課題を解決するために、本発明ではオートマトンを最適化することによる状態遷移数を減らす手法を提供する。例としては、状態遷移の分岐がほとんどなく、ある一定の状態遷移のパス（道筋）しか通らない場合には、そのパスを複数の状態として表す意味がない場合などである。このような場合には、それらの複数の状態を一つの状態に統合することで、状態遷移数を減らすことができる。

本発明では、ＸＭＬインスタンス文書に関する以下の２つの情報を活用して、オートマトンを最適化する。
（Ａ）インスタンス文書の統計情報
（Ｂ）スキーマの情報

各手法は相反的なものではなく、一方の手法を補完するものである。つまり、（Ａ）の統計情報を使って最適化したオートマトンに更に、（Ｂ）のスキーマ情報を使うことによって、十分な統計情報の取得に必要な文書セットを処理する前に、最適化されたオートマトンが早く得ることができる。また、（Ｂ）によって最適化したオートマトンに、（Ａ）の統計情報を用いることによって、スキーマには記述されていない、実行時の傾向を反映することができる。次に（Ａ）、（Ｂ）のそれぞれの情報を用いた最適化について述べる。

（Ａ）インスタンス文書の統計情報を活用した最適化
本手法は、インスタンス文書の統計情報を用いてオートマトンを最適化し、ＸＭＬパーサの高速化を実現する手法である。具体的には、以下の２つの手法を提供する。

（Ａ−１）複数の状態遷移の統合
（Ａ−２）反復的な要素の出現回数のパターンに適応したオートマトンの作成
以下に各手法の詳細について述べる。

（Ａ−１）複数の状態遷移の統合
前述したように、特許文献１に開示されたＤｅｌｔａｒｓｅｒの更なる高速化には状態遷移に伴うコストは無視できない。よって、バイト列マッチングの際に、高い確率で連続してマッチする状態遷移が存在すれば、それらの状態を別々に表現するのではなく、一つの状態遷移として表現した方が良い。例えば、＜ｎａｍｅ＞ ＩＢＭ ＜／ｎａｍｅ＞と言ったＸＭＬの文字列を処理する際、通常、“＜ｎａｍｅ＞”，“ＩＢＭ”，“＜／ｎａｍｅ＞”といった状態遷移が作成されるが、毎回すべてこれらの状態にマッチするのであれば、”＜ｎａｍｅ＞ ＩＢＭ ＜／ｎａｍｅ＞”と統合して表現した方が良い。この統合を統計的な情報を用いて行う。

まず、連続してマッチ（一致）する状態遷移列を発見する必要がある。各状態遷移を識別するため、各状態遷移にＩＤ（識別子）を付与する。既に存在する状態遷移にマッチするたびに、その状態遷移のＩＤを記録し、ＩＤのリスト（以後、ＩＤリストと呼ぶ）に追加する。マッチが終了した時点で位置する状態（状態Ｓｎと表す。ただしｎは自然数。）で、ＩＤの記録を終了する。

連続してマッチし、ＩＤリストの長さが２以上になる時、ＩＤリストに含まれる状態遷移群は、状態遷移統合（複数の状態遷移を一つの状態遷移としてまとめること）の対象候補となる。また、ＩＤリストには、カウンターが設けられる。カウンターは、処理対象のインスタンス文書セットの中で、状態遷移列の出現頻度を統計的に解析するために用いられる。ＩＤリストとカウンターは状態Ｓ１に格納されて管理される。同一のＩＤリストのカウント方法には様々な方法が考えられるが、例えば、適切なハッシュ関数を作り、ＩＤリストのハッシュ値をキーとして、その値としてカウンターを持つようにすることで実現できる。

例えば、＜Ａ＞＜Ｂ＞１＜／Ｂ＞＜／Ａ＞，＜Ａ＞＜Ｂ＞２＜／Ｂ＞＜／Ａ＞というように、＜Ｂ＞のテキストノードの値が変化するような文書を扱うケースを考える。この時、図４のようなオートマトンが作成され、それぞれの状態遷移にはＩＤが付与される。

この例では、１００文書を処理する際に、状態遷移のＩＤが１と２が連続してマッチし、ＩＤが４と５の状態遷移が連続してマッチする文書が８０文書出現するとする。このとき、ＩＤリストをカウントするためのハッシュ表は、状態３と状態６に格納される。

この仕組みによって、十分な統計情報を得たところで、連続して出現する状態遷移列が統計的にどのくらいの頻度で出現するかがわかり、ある閾値を設けることで、その閾値を越えた頻度を持つ状態遷移列は一つの状態遷移に統合することが可能である。この際、基本的には、統合前の状態遷移群は残される。これは万が一、統合前の状態遷移を必要とするような文書が来たとき（例えば、＜Ａ＞＜Ｃ＞＄Ｃ＜／Ｃ＞＜／Ａ＞などの文書）に、再び、＜Ａ＞を表す状態遷移を作ることを避けるためである。ただし、このような文書が統計上ほとんどないような場合には、消去するような仕組みを作ることも可能である。

上記の例を挙げると、閾値を仮に８０％以上の確率で同一のＩＤリストが出現する際には状態統合をするとする。また、統合前の状態は消去することにする。この場合、図４のオートマトンは、図５のようなオートマトンに最適化される。

（Ａ−２）反復的な要素の出現回数のパターンに適応したオートマトンの作成
ある要素が反復的に（注：この文書では繰り返しと反復の２つの用語が出てくるが、どちらも同じ意味である）出現するケースを考える。Ｄｅｌｔａｒｓｅｒではこのようなケースを表現するオートマトンとして、以下の２つタイプのオートマトンが作成可能である。

１）ループ型オートマトン
繰り返しの要素が出現する際、その要素を表す状態が既に作られている場合は、その状態に戻り、１回目と同じ状態遷移が行われる。図６に、これによって繰り返しがループ型の状態遷移となる場合のオートマトンを示した。

２）展開型オートマトン
繰り返しの要素が出現する際、既にその要素を表す状態が既に作られたとしても、別途状態遷移を作る。図７に、この場合の繰り返しが１直線型の状態遷移となる場合のオートマトンを示した。

前者のオートマトンの利点は、余分な状態遷移が作成されず、オートマトンがコンパクトであり、状態数／遷移数に伴うメモリ使用量に関する懸念も後者の方法と比べて少ない。しかし、状態Ｓ３から状態Ｓ２に遷移した後、次にどの状態に遷移すべきかを判断する際に、Ｓ１とＳ３の２つの候補があり、遷移の判断に伴うコスト（バイト列マッチング及びコンテキスト（要素スタックや名前空間など）の計算）が後者より大きい。

一方、後者の方法は、状態数が多くなるが、状態遷移の先の候補が一つであるので、状態遷移にかかるコストは前者より小さい。ただ、要素の繰り返しの回数が常にランダムなときには、出現する繰り返しの数だけ要素が現れてしまうので、その場合には後者の方法は向かない。この場合、前者のオートマトンを選択することが賢明である。

この２つのタイプのオートマトンのどちらを選択するかを統計的に選択する方法を述べる。基本的な方針は、まず前者の方法でオートマトンを構成していく。次に、処理の対象となるインスタンス文書の集合に対して、繰り返しを検知し、その繰り返しの回数を数える。回数が統計的にある固定の数であったと判断され、その回数がある閾値を越えていない場合に、後者の展開型オートマトンに最適化される。また、統計的に回数にちりばりがあり、ランダムであった場合は、前者のループ型オートマトンを使用する。

（１）繰り返しの検知方法
図６のループ型オートマトンを例に取ると、同じ経路を辿って状態Ｓ２に戻っていることをまず検知する必要がある。これには通過した状態遷移のＩＤを記録することで実現する。つまり、図６の場合、ＩＤが｛２，３，４｝と言った経路が状態２に追加される。このＩＤリストは、前述した連続した状態遷移列（連続状態遷移列と呼ぶ）とは別のものであり、繰り返しを検知するために記録される状態遷移列を反復状態遷移列と呼ぶことにする。反復状態遷移列は、連続状態遷移列と異なり、マッチするかどうかにかかわらず、通過した状態遷移を記録するものである。

例えば、＜Ｘ＞＜Ａ＞１＜／Ａ＞＜Ａ＞２＜／Ａ＞＜Ａ＞３＜／Ａ＞＜／Ｘ＞の文書の場合を考える。この場合＜Ｘ＞の後に、＜Ａ＞＄Ａ＜／Ａ＞のセットが３回出現するので、状態遷移ＩＤが２，３，４の列が状態Ｓ２に３回記録される。この反復回数のパターンを見出すために、処理する対象の文書セットに対して同じように記録し、統計的な手法で、その回数がある程度ランダムなものか、ある固定値の回数が多いなどの情報が得られる。これらの情報を元に、例えば固定回数の場合、前述の後者の展開型オートマトンに最適化し、ランダムと判断した場合には、前者のループ型オートマトンをそのまま使用する。

（２）反復の要素が入れ子になる場合への対処
反復は入れ子の構造として出現することがある。例えば、図８のＸＭＬインスタンス文書では、最も内側の＜Ｃ＞要素が任意の回数で出現し、その外側の＜Ｂ＞の要素は２回出現するような文書である。この文書をオートマトンとして表現すると、図９のループ型オートマトンになる。ここで、タグ＜Ａ＞などによって発生する状態遷移をＩＤ番号と共に、Ｔ_ｉｄ＝１［＜Ａ＞］のように表すものとする。このような入れ子で反復の要素が出現した場合でも、（１）の反復の回数を数えられるようにすることが必要である。
本手法は、ループの中に更にループがある入れ子構造に関して、以下の手順でそれぞれの繰り返し回数を数える。

以下、図１０のフローチャートを参照して説明する。

まず、最も内側のループを検出し、それを初期の「内側ループ」とする（ステップＳ１）。
次に、内側ループに関して（１）の方法を用いて繰り返し回数を記録する（ステップＳ２）。
更に、内側ループを囲む最も近い外側ループを検出した場合（ステップＳ３：Ｙｅｓ）、内側ループの回数が１回以上であっても、１回のループのＩＤリストのみを通過した状態遷移列として記録する（ステップＳ４）。外側ループに関しては、そのＩＤリストのカウンターを用いて繰り返し回数を数える（ステップＳ５）。このステップＳ３で外側ループが検出されない場合は（ステップＳ３：Ｎｏ）、終了する。
更に、外側ループを内側ループにし（ステップＳ６）、ステップＳ３、ステップＳ４、ステップＳ５の処理を実行する。

例えば、図８をＸＭＬのインスタンス文書として考える。この場合、ＩＤリスト｛３，４，５｝の状態遷移列がＳ３に記録される。Ｃの要素は繰り返し出現するので、ＩＤリスト｛３，４，５｝の状態遷移はループとなる。Ｃ要素の繰り返しが終了し、要素Ｂの終了タグが現れると、状態Ｓ２に遷移するが、（１）の繰り返し検知方法のみを述べると、｛１，２，３，４，５，３，４，５，３，４，５，３，４，５，６，７｝というＩＤリストができる。このＩＤリスト内の３，４，５というＩＤ列に関しては任意の回数が現れる回数が出現する場合があり、（２）の手法はこれを避けるためにある。（２）の手法を適用すると、｛３，４，５｝はループ構造であるのでその外側のループでは１回のループとみなして、｛１，２，３，４，５，６，７｝というＩＤリストとして表現され、繰り返しを適切に数えることができる。

図９に、図８に示したインスタンス文書の最適化前のオートマトンを示す。また、（２）によって最適化した後は、図１１のように内側はループ型オートマトンにし、外側は展開型オートマトンとなる。

他のケースでも同様のことが実現できることを示すために、図１２のインスタンス文書の例を示す。このケースでは、最も内側のＣの要素のループは固定回数であるが、Ｂの要素が任意の回数のループである場合である。このケースでも上記の手法を用いて適切に繰り返しの回数を数えることができる。その結果、図１３のようなオートマトンに展開される。

（Ｂ）スキーマ情報を活用したオーマトンの最適化と事前構築
オートマトンの最適化に活用できるスキーマ情報を本開示書ではＷ３Ｃで規定されたＸＭＬ Ｓｃｈｅｍａを用いるが、ＤＴＤ、ＲＥＬＡＸ（ＲＥｇｕｌａｒ ＬＡｎｇｕａｇｅ ｄｅｓｃｒｉｐｔｉｏｎ ｆｏｒ ＸＭＬ） ＮＧ等の他のスキーマ言語も利用できる。

最適化に伴うフローを図１４に示す。まず始めに、処理する要素が属性を持つかどうかに分類され（図１４左側）、更に、その要素が単純型か複合型かに分類される（図１４右側）。単純型とは単純内容モデルで属性を持たない要素を指す。また、単純内容モデルとは子要素としてテキストノードのみを受け入れるものである。それ以外のすべての要素（属性を持つ単純内容やその他の内容モデル）は複合型として定義されている。この他にテキストノードと子要素の両方が混在する混在内容も存在するが、本明細書では考慮しない。

以下にそれぞれの場合の最適化方法を述べる。

（Ｂ−１）単純型要素の場合
（１）単純内容の要素が固定値を持つ場合
ｘｓｄ：ｅｌｅｍｅｎｔでは、ｆｉｘｅｄ属性が指定されると、単純内容の要素はこの属性を使って特定の値に固定できる。

例）
ＸＭＬ Ｓｃｈｅｍａ： ＜ｘｓｄ：ｅｌｅｍｅｎｔ ｎａｍｅ＝“ｎａｍｅ” ｔｙｐｅ＝“ｘｓｄ：ｓｔｒｉｎｇ” ｆｉｘｅｄ＝“ＩＢＭ”／＞
ＸＭＬ インスタンス： ＜ｎａｍｅ＞ ＩＢＭ ＜／ｎａｍｅ＞

スキーマの情報がなければ、“＜ｎａｍｅ＞”，“ＩＢＭ”，“＜／ｎａｍｅ＞”とそれぞれ状態として定義し、図１５のように３つの状態列ができるが、スキーマの情報を用いることによって、図１６に示すように、３つの状態を一つの状態に統合することができる。このように、スキーマ情報を用いることで、状態数を統合し処理を高速化することができる。

（２）値の候補が指定されている場合
スキーマに属性値または要素間の値の候補が指定されている場合、その情報を用いて、あらかじめ、それらの状態遷移を作ることができる（オートマトンの事前構築）。

（Ｂ−２）複合型要素の場合
（１）ある要素の次に出現する要素が確定している場合
ＸＭＬ Ｓｃｈｅｍａのｘｓｄ：ｓｅｑｕｅｎｃｅが指定されている場合、ｍｉｎＯｃｃｕｒｓが０以外であれば、ある要素の次に出現する要素が決まっている。Ｘｓｄ：ｓｅｑｕｅｎｃｅは要素の順序付きグループを定義するコンポジタである。この情報を用いることによって、２つの別々の状態を一つの状態に統合することが可能である。

例として、図１７のＸＭＬ Ｓｃｈｅｍａを用いた以下のＸＭＬインスタンスについて見てみる。
ＸＭＬインスタンス
＜Ｘ＞＜Ａ＞１＜／Ａ＞＜Ｂ＞２＜／Ｂ＞＜Ｃ＞３＜／Ｃ＞＜／Ｘ＞
このＸＭＬインスタンスは、通常以下の１１回の状態遷移となるが、（“＜Ｘ＞”，“＜Ａ＞”，１，“＜／Ａ＞”，“＜Ｂ＞”，２，“＜／Ｂ＞”，“＜Ｃ＞”，３，“＜／Ｃ＞”，“＜／Ｘ＞”）スキーマ情報を用いれば、以下のように７回の状態数に削減できる。
“＜Ｘ＞＜Ａ＞”，１，“＜／Ａ＞＜Ｂ＞”，２，“＜／Ｂ＞＜Ｃ＞”，３，“＜／Ｃ＞＜／Ｘ＞”

（２）ある要素の次に出現する要素の候補が確定している場合
Ｘｓｄ：ｃｈｏｉｃｅで指定されている場合、ある要素の次に出現する要素の候補があらかじめわかる。この情報を用いることによって、あらかじめ、状態遷移を作ることができ、状態遷移を作るコストを減らすことができる。Ｘｓｄ：ｃｈｏｉｃｅは排他的な（どれか１つだけを選択できる）要素またはコンポジタのグループを定義するコンポジタである。Ｘｓｄ：ｃｈｏｉｃｅはちなみに、ｍａｘＯｃｃｕｒｓをｕｎｂｏｕｎｄｅｄ、または回数を限定して指定することができる。

（３）順不同の要素グループを記述するコンポジタ
Ｘｓｄ：ａｌｌは、その出現回数が０回または１回であるような順不同の要素グループを記述するために使う。図１８に例を示す。

このスキーマは、Ａ，Ｂ，Ｃが順不同で１回ずつ出現することを示している（ｍｉｎＯｃｃｕｒ＝１がｄｅｆａｕｌｔ）。この場合、状態数の削減の観点からは、＜Ａ＞，＜Ｂ＞，＜Ｃ＞のすべての組み合わせ（例えば、＜Ａ／＞＜Ｂ／＞＜Ｃ／＞を１つの状態で表現）を事前構築すればよい。オートマトンのサイズを考慮する場合は、実行後、実際にはある一定期間以上使われないノードを削減するなどの手法が考えられる。

（４）繰り返しの場合
ｍａｘＯｃｃｕｒｓがｕｎｂｏｕｎｄｅｄと指定されているときは、様々な回数の要素が来るとわかるので、（自信を持って）、繰り返し専用の状態遷移が作成される。

（Ｂ−３）要素が属性を持つ場合
（１）属性値が固定の場合
スキーマに属性値または要素間の値が固定値として指定されている場合、その情報を用いて、前後の状態と統合することが可能である。ｘｓｄ：ａｔｔｒｉｂｕｔｅでｆｉｘｅｄ属性を指定すると、その属性の値は固定され、ここで指定された値に等しくなければならない。以下にＸＭＬ ＳｃｈｅｍａとＸＭＬインスタンスの例を示す。

ＸＭＬ Ｓｃｈｅｍａ： ＜ｘｓｄ：ａｔｔｒｉｂｕｔｅ ｎａｍｅ＝“ｙｅａｒ” ｔｙｐｅ＝“ｘｓｄ：ｄａｔｅ” ｆｉｘｅｄ＝“２００４”／＞
ＸＭＬインスタンス ＜ｉｔｅｍ ｙｅａｒ＝“２００４”＞

（２）属性値の候補が指定されている場合
候補値を用いて、状態遷移を事前構築できる。以下のようなＸＭＬ Ｓｃｈｅｍａの場合、ｉｄ属性値としては、ｒｅｄ，ｂｌｕｅ，ｇｒｅｅｎのみが出現することが定義されている。この情報を用いて、事前に状態遷移を作成することができる。例としてＸＭＬ Ｓｃｈｅｍａを図１９に示す。

（Ｃ）空白が出現したときの対処方法
ＸＭＬは要素間に任意の数の空白の出現を許す。これまでに説明した状態遷移の最適化は、いずれも空白が含まれない場合のみを例に挙げていた。しかしながら、ＸＭＬでは空白文字の出現に対する制約が緩く、要素間に任意の数の空白が出現することや、要素名の中に空白が出現することもあり得る。本発明はこのような空白の揺らぎに対しては、（Ａ）のインスタンス文書の統計情報を活用して解決する。

図２０に空白による状態遷移の例を示す。空白による状態遷移はコンテキスト上変わりなく、図中のＩＤ＝２，２’の状態遷移のようにループの状態遷移が作られる。ＩＤ＝２の状態遷移は、＜Ａ＞と＜Ｂ＞の間に空白が３回現れたケース（＜Ａ＞□□□＜Ｂ＞）であり、ＩＤ＝２’は、＜Ａ＞と＜Ｂ＞の間に空白が５回現れるケース（＜Ａ＞□□□□□＜Ｂ＞）だとする。この場合、（Ａ）の統計情報を用いると、どちらの状態遷移が統計的に多く遷移するかを検知することができる。これによって、空白の数のパターンが同定でき、同じように他の状態遷移と統合することができる。

図２１、２２に本発明の実施例の結果を示す。ここでは、ＩＢＭの既存のＸＭＬパーサ製品Ａを基に本発明の手法を実装した例について行った実験結果を示している。ＸＭＬパーサ製品Ａは、スキーマを中間表現（Ｉｎｔｅｒｍｅｄｉａｔｅ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）に変換し、仮想機械上で実行することでスキーマの検証を行うアーキテクチャとなっている。本実験では、ｘｓｄ：ｓｅｑｕｅｎｃｅを処理する命令であるＲｅａｄＯｎｅインストラクションが、次に出現すべき要素が一つに決定していることを利用して、本発明で提案したオートマトンの最適化を行った。実験環境および、使用したＸＭＬ Ｓｃｈｅｍａファイル、ＸＭＬインスタンスファイルの例は以下の通りである。

＜実験環境＞
−Ｔｈｉｎｋ Ｐａｄ（登録商標） Ｔ４３ ２６６８−７２Ｊ（Ｐｅｎｔｉｕｍ（登録商標） Ｍ ７６０，２．０ＧＨｚ，１ＧＢ ＲＡＭ）
−Ｗｉｎｄｏｗｓ（登録商標） ＸＰ Ｐｒｏｆｅｓｓｉｏｎａｌ
−Ｊａｖａ（登録商標） ＶＭ：Ｓｕｎ ＪＶＭ １．４．２
−比較対象
１）Ｄｅｌｔａｒｓｅｒ：特許文献１の発明を実装したＸＭＬパーサ
２）Ｓｃｈｅｍａ−ａｗａｒｅ Ｄｅｌｔａｒｓｅｒ：本発明の手法を適用したＤｅｌｔａｒｓｅｒ
−比較方法
１）１万回のウォーミングアップの後、１万回実行し、その平均時間を算出した。
２）すべてのテキスト要素は（同じテキストであっても）部分処理を行った。
−テスト文書
１）図２１に記載のＸＭＬ Ｓｃｈｅｍａファイル
２）図２２に記載のＸＭＬインスタンス文書

＜実験結果＞
様々なサイズのＸＭＬインスタンスを用いて本手法（Ｓｃｈｅｍａ−ａｗａｒｅ Ｄｅｌｔａｒｓｅｒ）の効果を測定した。実験結果を図２３、図２４に示す。これらの図においてはＸＭＬインスタンスのファイル名（ｘｘｘ．ｘｍｌ）が、そのドキュメントサイズ（バイト数）を表している。また、処理結果の計測時間をｍｓｅｃで示している。

図２３、図２４から明らかなように、どのドキュメントに対しても、１３％から３０％の高速化が図られている。本実験では、ｘｓｄ：ｓｅｑｕｅｎｃｅの場合の最適化のみ測定を行ったが、他の最適化ケースであっても、スキーマ情報を用いて状態遷移の数を減らすことによって、高速化できることは本実験により自明である。また、本実験により、状態遷移を統合することによる高速化は示せたので、インスタンス文書の統計的な文書を用いた最適化を用いた方法も効果があることがあると言える。

ＸＭＬ解析処理が必要なアプリケーションに対して、インスタンス文書の統計情報とスキーマ情報が付与されていれば、本手法が適用できる。例えば、特定のＸＭＬマークアップ言語の処理系や、Ｗｅｂサービスを処理するミドルウエアで本発明を用いることができる。

また、統計情報を用いたオートマトンの最適化による効果は本明細書では示していない。しかし、スキーマ情報を用いた手法と同等の効果か、それ以上が期待できる。なぜなら、実行時の文書のパターンをオートマトンに反映させることにより、スキーマ情報に現れる情報と現れない情報の両者をオートマトン最適化に使用できるからである。また、スキーマ情報にはない状態統合化のための多くの情報がインスタンス文書の統計処理によって得られるからである。ただし、統計情報を用いる手法は、適切な統計情報を得るまでに試行回数が必要であるのでその時間は余分にかかるということには注意が必要である。

以上、本発明を実施形態、および実施例を用いて説明したが、本発明の技術的範囲は上記実施形態に記載の範囲に限定されない。上記実施形態に、多様な変更または改良を加えることが可能である。また、そのような変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

本発明における一つの実施形態として説明した構造化文書処理装置、または構造化文書処理方法は、コンピュータ上のシステムまたはコンピュータにその機能を実行させるプログラムによって実現可能である。また、上記プログラムを格納するコンピュータ可読の記録媒体は、電子的、磁気的、光学的、電磁的、赤外線または半導体システム（または、装置または機器）であることができる。コンピュータ可読の記録媒体の例には、半導体またはソリッド・ステート記憶装置、磁気テープ、取り外し可能なコンピュータ可読の媒体の例には、半導体またはソリッド・ステート記憶装置、磁気テープ、取り外し可能なコンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、リードオンリー・メモリ（ＲＯＭ）、リジッド磁気ディスクおよび光ディスクが含まれる。現時点における光ディスクの例には、コンパクト・ディスク−リードオンリー・メモリ（ＣＤ−ＲＯＭ）、コンパクト・ディスク−リード／ライト（ＣＤ−Ｒ／Ｗ）およびＤＶＤが含まれる。

状態数の変化に伴う平均処理時間の増加を示した図である。 Ｄｅｌｔａｒｓｅｒと既存のＸＭＬパーサの状態遷移の作成オーバヘッドの比較を示した図である。 本発明の一実施形態としての構造化文書処理装置の機能ブロック図を示した図である。 各状態遷移へのＩＤの付加と反復要素のカウント方法を示した図である。 最適化後のオートマトンを示した図である。 ループ型オートマトンを示した図である。 展開型オートマトンを示した図である。 ＸＭＬインスタンス文書１を示した図である。 ＸＭＬインスタンス文書１の最適化前オートマトンの構成を示した図である。 反復要素が入れ子になる場合の処理フローを示した図である。 ＸＭＬインスタンス文書１の最適化後オートマトンの構成を示した図である。 ＸＭＬインスタンス文書２を示した図である。 ＸＭＬインスタンス文書２の最適化後オートマトンの構成を示した図である。 最適化処理の分類図を示した図である。 単純型要素の場合の最適化前オートマトンを示した図である。 単純型要素の場合の最適化後オートマトンを示した図である。 ＸＭＬ Ｓｃｈｅｍａ例１を示した図である。 コンポジタを示した図である。 ＸＭＬ Ｓｃｈｅｍａ例２を示した図である。 空白による状態遷移例を示した図である。 実施例１における実験用ＸＭＬ Ｓｃｈｅｍａを示した図である。 実施例１における実験用ＸＭＬインスタンス文書の例を示した図である。 実施例１の実験結果を示した図である。 実施例１の実験結果グラフを示した図である。

符号の説明

１ 入力部
２ 出力部
３ 通信部
４ 記憶部
４ａ インスタンス文書統計情報
４ｂ 解析済み元構造化文書
５ インスタンス文書解析部
６ スキーマ情報解析部
７ オートマトン最適化部
８ 構文解析部
９ ＡＰＩ部
１０ 構造化文書処理装置
２０ 構造化文書
２１ インスタンス文書
２２ スキーマ情報
３０ アプリケーション・プログラム

Claims (19)

1. 電子データ化された構造化文書を構文解析する構造化文書処理装置であって、
   前記構造化文書を複数のノードに区分化可能とする複数の状態の状態遷移列を生成するオートマトン生成部と、
   前記構造化文書の実体であるインスタンス文書を状態解析した結果を示す状態遷移間のマッチングを調べて、連続してマッチングする状態遷移の出現頻度を示すデータである統計情報を得て、前記統計情報で示される前記出現頻度が所定の頻度閾値を超えた場合に、前記オートマトン生成部で生成された状態遷移列について前記マッチングした状態遷移を一つの状態遷移として統合し、さらに、前記状態遷移において反復的に現れる反復的要素を検知して当該反復的要素が出現する反復回数を求め、該反復回数が所定の反復閾値を超えたか否かに応じてオートマトンの型を選択してオートマトンを最適化するインスタンス文書解析部と、
   前記構造化文書の情報の構造や形式を定義するスキーマ情報を解析して処理すべき要素が属性を有しているかに応じて、前記オートマトン生成部が生成した前記状態遷移列についてその状態遷移を統合してオートマトンを最適化するスキーマ情報解析部と、
   前記インスタンス文書解析部が最適化したオートマトンと前記スキーマ情報解析部が最適化したオートマトンとを互いに補完してさらに最適化するオートマトン最適化部と、
   を備える、構造化文書処理装置。
2. 前記構造化文書がＸＭＬ文書である、請求項１に記載の構造化文書処理装置。
3. 前記区分化可能とする複数の状態がＳＡＸイベントで定義される、請求項１に記載の構造化文書処理装置。
4. 前記インスタンス文書解析部には、前記状態遷移ごとにＩＤを付加し、同一の状態遷移が存在するか否かを調べて存在すると、当該状態遷移をマッチングしたと判定し、ＩＤリストに当該ＩＤを記録し、該ＩＤリストを用いて連続的にマッチングする状態遷移の回数をカウントする連続状態遷移計数部が備えられる、請求項１に記載の構造化文書処理装置。
5. 前記オートマトン最適化部は、前記インスタンス文書解析部が検知する前記反復的要素に対して、前記反復的要素が入れ子になっている場合にも最適化する、請求項１に記載の構造化文書処理装置。
6. 前記インスタンス文書解析部において前記構造化文書の中の要素間に出現する任意の数の空白文字のパターンを前記統計情報によって同定する、請求項１に記載の文書構造解析装置。
7. コンピュータによって電子データ化された構造化文書を構文解析する構造化文書処理方法であって、
   前記コンピュータが
   オートマトン生成手段によって前記構造化文書を複数のノードに区分化可能とする複数の状態の状態遷移列を生成する第１のステップと、
   インスタンス文書解析手段によって前記構造化文書の実体であるインスタンス文書を状態解析した結果を示す状態遷移間のマッチングを調べて、連続してマッチングする状態遷移の出現頻度を示すデータである統計情報を得て、前記統計情報で示される前記出現頻度が所定の頻度閾値を超えた場合に、前記オートマトン生成手段で生成された状態遷移列について前記マッチングした状態遷移を一つの状態遷移として統合し、さらに、前記状態遷移において反復的に現れる反復的要素を検知して当該反復的要素が出現する反復回数を求め、該反復回数が所定の反復閾値を超えたか否かに応じてオートマトンの型を選択してオートマトンを最適化する第２のステップと、
   スキーマ情報解析手段によって前記構造化文書の情報の構造や形式を定義するスキーマ情報を解析して処理すべき要素が属性を有しているかに応じて、前記オートマトン生成手段が生成した前記状態遷移列についてその状態遷移を統合してオートマトンを最適化する第３のステップと、
   オートマトン最適化手段によって、前記インスタンス文書解析手段が最適化したオートマトンと前記スキーマ情報解析手段が最適化したオートマトンとを互いに補完してさらに最適化する第４のステップと、
   を実行する構造化文書処理方法。
8. 前記構造化文書がＸＭＬ文書である、請求項７に記載の構造化文書処理方法。
9. 前記区分化可能とする複数の状態がＳＡＸイベントで定義される、請求項７に記載の構造化文書処理方法。
10. 前記第２のステップでは、前記状態遷移ごとにＩＤを付加し、同一の状態遷移が存在するか否かを調べて存在すると、当該状態遷移をマッチングしたと判定し、ＩＤリストに当該ＩＤを記録し、該ＩＤリストを用いて連続的にマッチングする状態遷移の回数をカウントする請求項７に記載の構造化文書処理方法。
11. 前記第２のステップにおいて、前記反復的要素に対して、前記反復的要素が入れ子になっている場合にも最適化する、請求項７に記載の構造化文書処理方法。
12. 前記第２のステップにおいて前記構造化文書の中の要素間に出現する任意の数の空白文字のパターンを前記統計情報によって同定する、請求項７に記載の文書構造解析方法。
13. コンピュータによって実行され、電子データ化された構造化文書を構文解析するコンピュータ・プログラムであって、
    前記コンピュータに、
    オートマトン生成手段によって前記構造化文書を複数のノードに区分化可能とする複数の状態の状態遷移列を生成する第１のステップと、
    インスタンス文書解析手段によって前記構造化文書の実体であるインスタンス文書を状態解析した結果を示す状態遷移間のマッチングを調べて、連続してマッチングする状態遷移の出現頻度を示すデータである統計情報を得て、前記統計情報で示される前記出現頻度が所定の頻度閾値を超えた場合に、前記オートマトン生成手段で生成された状態遷移列について前記マッチングした状態遷移を一つの状態遷移として統合し、さらに、前記状態遷移において反復的に現れる反復的要素を検知して当該反復的要素が出現する反復回数を求め、該反復回数が所定の反復閾値を超えたか否かに応じてオートマトンの型を選択してオートマトンを最適化する第２のステップと、
    スキーマ情報解析手段によって前記構造化文書の情報の構造や形式を定義するスキーマ情報を解析して処理すべき要素が属性を有しているかに応じて、前記オートマトン生成手段が生成した前記状態遷移列についてその状態遷移を統合してオートマトンを最適化する第３のステップと、
    オートマトン最適化手段によって、前記インスタンス文書解析手段が最適化したオートマトンと前記スキーマ情報解析手段が最適化したオートマトンとを互いに補完してさらに最適化する第４のステップと、
    を実行させるコンピュータ・プログラム。
14. 前記構造化文書がＸＭＬ文書である、請求項１３に記載のコンピュータ・プログラム。
15. 前記区分化可能とする複数の状態がＳＡＸイベントで定義される、請求項１３に記載のコンピュータ・プログラム。
16. 前記第２のステップでは、前記状態遷移ごとにＩＤを付加し、同一の状態遷移が存在するか否かを調べて存在すると、当該状態遷移をマッチングしたと判定し、ＩＤリストに当該ＩＤを記録し、該ＩＤリストを用いて連続的にマッチングする状態遷移の回数をカウントする請求項１３に記載のコンピュータ・プログラム。
17. 前記第２のステップにおいて、前記反復的要素に対して、前記反復的要素が入れ子になっている場合にも最適化する、請求項１３に記載のコンピュータ・プログラム。
18. 前記第２のステップにおいて前記構造化文書の中の要素間に出現する任意の数の空白文字のパターンを前記統計情報によって同定するステップを更に実行させる請求項１３に記載のコンピュータ・プログラム。
19. 請求項１３乃至請求項１８のいずれか１項に記載のコンピュータ・プログラムを記録する記録媒体。

Images