本発明は、XML(eXtensible Markup Language)文書等の構造化文書を処理する装置、方法、及びプログラムに係り、詳しくは解析済みの構造化文書と新規構造化文書との対比に基づく処理を行う構造化文書処理装置、構造化文書処理方法及びプログラムに関するものである。
特許文献1は、SGML(Standard Generalized Markup Language)等の構造化文書が、版ごとに、削除、挿入、変更等の編集を加えられるときに、各版がどのようになっていたかの情報を表示する版管理方法を開示する。該版管理方法では、記憶するデータ量を低減しつつ、各版における変更点を具体的に示すために、初版は、構造化文書の全内容を保存するものの、2版以降の各版は、前版との差分情報のみを保存している。そして、従来の差分情報の表示態様では、本版における変更前の内容及び変更後の内容が、その表示エリアを別々にしてかつタグ付きのテキストで表示するもので(特許文献1の図4(b))、対比の視認性が悪かったのに対し、特許文献1に係る版管理方法では、各構造箇所ごとに、削除、挿入、変更内容が対比されるようにして(特許文献1の図14)、対比の視認性を高めている。すなわち、特許文献1の発明では、差分情報自体を、構造化文書により保存している(特許文献1の図6及び図18)。
特許文献2は、構造化文書の構文解析を高速化するために、1個のアプリケーション・プログラムから繰返し、構文解析を要求される1個の構造化文書について、あるいは相互に異なる複数個のアプリケーション・プログラムから共通に、構文解析を要求される1個の構造化文書について、該構造化文書の構文解析結果としてのイベント・セット情報を予め記憶しておき、その後、該構造化文書について構文解析をアプリケーション・プログラムから再度、要求されるときには、該構造化文書について再度、構文解析することなく、記憶中のイベント・セット情報を読み出して、該イベント・セット情報から一連のイベントを再生して、該アプリケーション・プログラムへ通知している。
一方、通常のテキスト文書において類似度の高い文書を高速に検出する手法はいくつか提案されている(例:非特許文献1,2)。
また、オートマトンを適応的に用いる方法は、学習オートマトンとして既に研究された領域である(例:非特許文献3)。
さらに、SIA(System Integrated Automaton for SAX)パーサ(Parser)がある(非特許文献4)。
解析済みXML文書に対して類似度の高いものから差分を取り出す単純かつ自明な方法は、バイト列もしくは文字列に対して単純に差分を取っていけばよい。この差分解析方法については、古くからいくつも提案がある(非特許文献5)。
特開平9−319632号公報
特開2004−62716公報
米国CiteSeer.IST(科学文献ディジタル図書館:scientific literature digital library )、"類似木マッチング・システム(A System for Approximate Tree Matching)[online]、[平成16年9月1日検索]、インターネット<http://citeseer.ist.psu.edu/tsong−li92system.html>
米国CiteSeer.IST(科学文献ディジタル図書館:scientific literature digital library )、"無方向非サイクリック・グラフと関連問題との編集距離について(On the editing distance between undirected acyclic graphs and related problems)[online]、[平成16年9月1日検索]、インターネット<http://citeseer.ist.psu.edu/zhang95editing.html>
ツセッツリン(M.L.)著「生物学システムにおけるオートマトン理論及びモデリング」、ニューヨーク及びロンドンのアカデミック・プレス社、1973年。(Tsetlin, M.L., "Automaton Theory and the Modelling of Biological Systems," New York and London, Academic Press, 1973.)
"SAX用システム統合オートマトン(System Integrated Automaton for SAX)[online]、[平成16年9月1日検索]、インターネット<http://www.geocities.com/siaparser/resources/siaidea.html>
P.ヘッケル著、「ファイル間の相違を分離する技術」、ACMコミュニケーション出版社、1978年4月。(P.Heckel, "A Technique for Isolating Differences Between Files." Communication of the ACM, Apr78)
特許文献1の版管理装置は、版管理における情報記憶量を節約するために、差分情報を利用することを開示するものの、構造化文書の構文解析を高速化するための具体的技術についてはなんら言及していない。
特許文献2の構造化文書処理装置は、すでに構文解析済みの構造化文書について、アプリケーション・プログラムより再度、構文解析要求があったときの高速化には、適用できるが、構文解析済みの構造化文書とは異なる構造化文書について、構文解析要求があったときには、それに対処できない。
XMLの類似文書の従来の検索技術(非特許文献1,非特許文献2)はすべてパース済みの文書に対して類似度を判定するものであり、パース処理を効率化するという目的には用いることができない。
オートマトンを文書に単純に適用するだけでは(非特許文献3)、XMLの構造やXMLの整形式を考慮されないので、整形式かどうかの検証などの時間のかかる操作を必要としてしまい、効率の面で大きな問題がある。
SIAパーサ(非特許文献4)は、SAXイベントに対して、オートマトン(学習可)を利用して、XMLの木構造自身の文法を認識して処理しようとするものであり、パース(構文解析)を行っていないテキストからそのまま適用できるものではない。
非特許文献5等には、未解析XML文書の構文解析の高速化についての示唆はない。
本発明の目的は、構造化文書間の類似関係を効率的に検出する構造化文書処理装置、構造化文書処理方法及びプログラムを提供することである。
本発明の他の目的は、新規構造化文書の構文解析を高速化することができる構造化文書処理装置、構造化文書処理方法及びプログラムを提供することである。
本発明のさらに他の目的は、他の構造化文書の構文解析を利用して、新規構造化文書の構文解析を高速化する際に、適切な他の構造化文書を高速で探し出すことのできる構造化文書処理装置、構造化文書処理方法及びプログラムを提供することである。
本発明の構造化文書処理装置、構造化文書処理方法及びプログラムでは、元構造化文書と新構造化文書との類似度を調べるために、状態遷移機械(オートマトン)を利用する。すなわち、元構造化文書は、その構造区分に係る複数個のノードとしての複数個の元ノードに区分され、それら元ノードは、状態遷移図上の各状態(本明細書では、状態遷移図上の状態を、「ノード」とも呼んでいる。)に対応させられて、状態遷移図が作成される。状態遷移図では、それら元ノードの状態遷移は、元構造化文書の先頭から末尾への出現順に対応付けられている。新構造化文書は、同様に、その構造区分に係る複数個のノードとしての複数個の新ノードに区分され、それら新ノードは、新構造化文書の先頭から末尾への出現順に順番付けされる。新構造化文書における新ノード及び状態遷移図上の元ノードが、それらの順番に従って選択対として抽出され、各選択対の元ノード及び新ノードの相互の一致性が調べられる。
構造化文書には、階層化された構造化文書が含まれ、階層化された構造化文書とは、例えば、XML文書やSGML文書である。なお、「一致性」とは、典型的には、完全一致を意味するが、これに限定されない。選択対の元ノード及び新ノードが、ノードの属性値のみが相違するときも、一致性有りとすることもできる。例えば、XMLパーサ等への本発明の適用において、元構造化文書の構文解析結果を新構造化文書の構文解析結果として利用するか否かについての基準を設け、選択対の元ノード及び新ノードが、完全一致ではなく、相違点があるものの、該基準を満足できる程度の相違であるならば、両者は一致性有りと判定することができる。
本発明の適用例として、XMLパーサ、構造化文書の相互の類似度に基づく構造化文書クラスの推測装置、構造化文書の相互の類似度に基づく構造化文書間の関連付け装置、及び大学教授が、学生より新規提出されたレポート(=構造化文書)について、他の学生から既提出済みのレポート(=構造化文書)に対する同一部分及び相違部分を把握することを支援する装置がある。
本発明としての構造化文書用構文解析装置、方法及びプログラムでは、元構造化文書は、すでに構文解析が済まされた構造化文書であり、これに対して、新構造化文書は、これから構文解析を行なおうとするものである。元構造化文書及び新構造化文書は、元構造化文書の構文解析結果を新構造化文書の構文解析結果として再利用するのに都合のよい内容部分単位に区分される。該内容部分単位は、例えば構造化文書の構造区分(例:構造化文書のノード)であってよい。そして、元構造化文書及び新構造化文書は、それらの内容部分単位同士で、先頭から末尾への順番に基づき、記述の観点から一致性を調べられる。元構造化文書及び新構造化文書は、幾つかの内容部分単位において一致性がなくても、文書全体において所定の一致性が認められるならば、元構造化文書の構文解析結果を利用して、新構造化文書の構文解析結果を行なう。例えば、新構造化文書の内容部分単位に係る構文解析結果として、元構造化文書の内容部分単位に係る構文解析結果をそのまま使用する。元構造化文書の内容部分単位の構文解析結果を構文解析結果として利用できない新構造化文書の内容部分単位については、もし、その解析結果が必要であるときには、それを構文解析することになる。
本発明では、複数個の元構造化文書の中から、新構造化文書の構文解析に利用する適切な元構造化文書を探し出すために、状態遷移機械を利用する。状態遷移機械は、新構造化文書の各新ノードに対して、それと一致性のある、状態遷移図上の元ノードを探し出し、状態遷移図上において、一致性のある元ノードについての遷移履歴を調べる。該遷移履歴に基づき所定の1個の元構造化文書が選択される。該元構造化文書は、好ましくは、記述内容が新構造化文書に最類似する元構造化文書であるが、新構造化文書に対する元構造化文書の類似度が基準値以上であるときは、該元構造化文書が、該新構造化文書に最類似の元構造化文書でなくても、選択されてよいとする。基準値とは、例えば、状態遷移図上の元ノードに一致性有りと判定された新構造化文書の新ノードの個数を計数し、計数値が、該新構造化文書の新ノードの総数に対する割合に対し、該割合の値である。
本発明によれば、元構造化文書の類似関係を、状態遷移機械を用いて効率的に検出することができる。
本発明によれば、元構造化文書及び新構造化文書を、内容部分単位で対比し、この対比結果から元構造化文書及び新構造化文書の全体の一致性が認められると、新構造化文書の各内容部分単位の構文解析として、既解析済みの元構造化文書の対応の内容部分単位の構文解析結果を利用する。これにより、新構造化文書は、その全部について構文解析することを省略され、新構造化文書の構文解析の高速化を図ることができる。
本発明によれば、複数個の元構造化文書の状態遷移情報が1個の状態遷移図にまとめられ、状態遷移機械は、新構造化文書のノードに基づき状態遷移図上のノードを辿ることにより、新構造化文書の構文解析に利用できる適切な元構造化文書を探し出す。したがって、元構造化文書の個数に対する状態遷移図情報記憶量の低減化、及び複数個の元構造化文書の中から所望の元構造化文書の抽出の高速化を実現できる。
図1は構造化文書処理装置100の機能ブロック図である。構造化文書処理装置100は、状態遷移図情報記憶手段101、選定対抽出手段102、一致性判定手段103、ノード認定手段104、遷移履歴情報生成手段105、及び類似度検出手段106を有している。状態遷移図情報記憶手段101は、構造区分に係る複数個のノードとしての複数個の元ノードに区分化可能となっている元構造化文書109に対し、該元構造化文書109の元ノードが元構造化文書109の先頭からの出現順に遷移する状態遷移図に係る情報を状態遷移図情報として記憶する。選定対抽出手段102は、構造区分に係る複数個のノードとしての複数個の新ノードに区分化可能となっている新構造化文書110に対し、新構造化文書110の先頭からの新ノードの出現順及び状態遷移図におけるノード遷移順に従い、それぞれ新構造化文書110及び状態遷移図において相互に対応する新ノード及び元ノードの対を選定対として抽出する。一致性判定手段103は、選定対の元ノード及び新ノードに対し、それらの一致性の有無をそれらの記述に基づき判定する。ノード認定手段104は、一致性有りの判定のときには選定対の元ノード及び新ノードに対し、元ノードを新ノードの被利用ノードに認定する。遷移履歴情報生成手段105は、状態遷移図上の複数個の被利用ノードを遷移順に進む遷移履歴に係る情報を遷移履歴情報として生成する。類似度検出手段106は、遷移履歴情報に基づき元構造化文書109と新構造化文書110との類似度を検出する。
図1の構造化文書処理装置100と後述の図3の構造化文書処理方法130とは、発明のカテゴリがそれぞれ装置及び方法と相違するのみで、実質的な技術内容は同一であるので、両者を代表して構造化文書処理装置100について説明を行なう。元構造化文書109及び新構造化文書110は例えばXML文書やSGML文書である。XML文書では、ノードとは、例えば、後述の図18や図27のリーフ・ノードに相当するものであり、例えば、SAXインターフェースのイベントに対応する。すなわち、XML文書のノードとは、タグ(”<”から次の”>”までの記述部分)又はコンテント部分(タグの外の記述部分)である。元構造化文書109は典型的には、複数個であって、この場合、構造化文書処理装置100は、例えば、複数個の元構造化文書109の中から新構造化文書110に最類似の元構造化文書109、又は基準を満足する程度に類似している1個の元構造化文書109を探し出したりする。
図1では、元構造化文書109及び新構造化文書110は1:1となっているが、n(nは2以上の整数):1の関係であることを除外しない。元構造化文書109が1個である場合は、新構造化文書110に対する該1個の元構造化文書109の類似度が調べられる。元構造化文書109がn個である場合は、新構造化文書110に対する全部又は幾つかの元構造化文書109の類似度が調べられる。
典型的には、選定対抽出手段102は、それが抽出した選定対に対して、一致性判定手段103が一致性無しと判定すると、一致性無しと判定された選定対については、その新ノードは変更せずに維持して、元ノードはノード遷移順番が次の元ノードへ抽出して、すなわち選定対の中身を更新させて、一致性判定手段103に再度の一致性判定を行なわせる。新ノードが状態遷移図のどの元ノードに対しても一致性無しということが判明すると、選定対抽出手段102は、選定対の新ノードを出現順番が次のものへ変更する。
元構造化文書109が複数個存在するとき、状態遷移図は、各元構造化文書109ごとに存在してもよいし、全部の元構造化文書109に共通に存在してもよい(例:図32)。状態遷移図が各元構造化文書109ごとに存在する場合には、選定対抽出手段102は、新構造化文書110に対する類似度を現在、調べようとしている元構造化文書109専用の状態遷移図を使用して、選定対における元構造化文書109側の元ノードを捜索することになる。状態遷移図が全部の元構造化文書109に共通に存在するときは、典型的には、複数の元構造化文書109に重複する状態遷移は状態遷移図において1個にまとめられている(例:図32において構造化文書A,Bに対して状態615→616)。
選定対における元ノード及び新ノードの一致性は、典型的には記述の完全一致であるが、これに限定しない。後述の図43のように、要素名(例:ds:Reference)が同一であるが、属性(例:URI)の値が異なる相違が選定対における元ノード及び新ノードにあったとしても、両者は一致性有りと判定することができる。元構造化文書109の構文解析結果を新構造化文書110の構文解析結果として利用するか否かについての基準を設け、選択対の元ノード及び新ノードの相違が、該基準をクリアできる範囲であれば、新構造化文書110の構文解析について、元構造化文書109の構文解析結果に利用価値があると認めて、両者は一致性有りと判定するのが好ましい。
構造化文書処理装置100の利用例として次のものが挙げられる。
(a1)1個の元構造化文書109と新構造化文書110との類似度を調べ、類似度が基準値以上であれば、元構造化文書109の構文解析結果を新構造化文書110の構文解析結果として利用するSAX(Simple API for XML)インターフェース
(a2)複数個の元構造化文書109の中から最類似の元構造化文書109又は基準値以上の類似度をもつ1個の元構造化文書109を探し出し、該元構造化文書109の構文解析結果を新構造化文書110の構文解析結果として利用するSAXインターフェース
(b)各元構造化文書109への類似度に基づく新構造化文書110の文書クラスの推測又は元構造化文書109−新構造化文書110間の関連付け
(c)大学教授が、新しく提出されたレポートに対し、すでに提出済みの多数のレポートのどれに類似するかを知る際の支援装置や、さらに、類似する提出済みのレポートのどこが同一で、どこが異なるかを知る際の支援装置
こうして、構造化文書処理装置100は、状態遷移機械を利用して、1個又は複数個の元構造化文書109と新構造化文書110との類似度を効率的かつ高速に検出することができる。
図2は構造化文書処理装置120の機能ブロック図である。構造化文書処理装置120は、状態遷移図情報記憶手段101、選定対抽出手段102、一致性判定手段103、ノード認定手段104、遷移履歴情報生成手段105、類似度検出手段106、構文解析結果記憶手段121、利用認定手段122及び元構造化文書利用手段123を有している。構造化文書処理装置120の状態遷移図情報記憶手段101〜類似度検出手段106は、図1の構造化文書処理装置100のそれらと同一である。構造化文書処理装置100との相違点について述べる。構文解析結果記憶手段121は、元構造化文書109の各ノードについての構文解析結果を記憶する。利用認定手段122は、元構造化文書109及び新構造化文書110の類似度が基準値以上であるときには、元構造化文書109を新構造化文書110の被利用構造化文書と認定する。元構造化文書利用手段123は、新構造化文書110の新ノードに係る構文解析結果として、該新構造化文書110の被利用構造化文書におけるノードであって該新ノードの被利用ノードに係る構文解析結果を利用する。
図2の構造化文書処理装置120と後述の図4の構造化文書処理方法140とは、発明のカテゴリがそれぞれ装置及び方法と相違するのみで、実質的な技術内容は同一であるので、両者を代表して構造化文書処理装置120について説明を行なう。「元構造化文書109及び新構造化文書110の類似度が基準値以上であるとき」とは、元構造化文書109が複数個ある場合に、最類似の元構造化文書109であるときを除外しない。ただし、該最類似の元構造化文書109は、「新構造化文書110との類似度が基準値以上であるとき」の条件を具備する必要がある。新構造化文書110の被利用構造化文書と認定された元構造化文書109は、その所定の元ノード(被利用ノード)に係る構文解析結果が、新構造化文書110の対応の新ノードに係る構文解析結果として利用されるが、この理由は、元構造化文書109及び新構造化文書110の類似度が基準値以上であるときには、新構造化文書110の全体を構文解析するよりも、すでに構文解析済みの元構造化文書109の構文解析結果を利用して、新構造化文書110の構文解析を行った方が構文解析を高速化することができるからである。したがって、利用認定手段122における基準値は、元構造化文書109の構文解析結果の利用が新構造化文書110の構文解析の高速化に寄与できるかの観点から設定される。構造化文書処理装置120をSAXインターフェースに適用する場合、元構造化文書109に、新ノードの被利用ノードに相当する元ノードがないときには、該新ノードについては、新規に構文解析することになる。構造化文書処理装置120をWebサービスにおけるSOAPメッセージの構文解析に適用する場合、元構造化文書109の構文解析結果は、例えばテンプレート(例:図40)としてあらかじめ用意され、新構造化文書110から適宜抽出したデータを該テンプレートの空白部に記入して、新構造化文書110用の構文解析結果を完成させる。
構造化文書処理装置120では、状態遷移機械を利用して、これにより、新構造化文書110の構文解析結果として利用できる構文解析結果をもつ元構造化文書109を高速に探し出したり、SOAPメッセージの構文解析に利用できるテンプレートを高速に探し出すことができる。
図3は構造化文書処理方法130のフローチャートである。S131(状態遷移図情報記憶ステップ)では、構造区分に係る複数個のノードとしての複数個の元ノードに区分化可能となっている元構造化文書に対し、該元構造化文書の元ノードが元構造化文書における先頭からの出現順に遷移する状態遷移図に係る情報を状態遷移図情報として記憶する。S132(選定対抽出ステップ)では、構造区分に係る複数個のノードとしての複数個の新ノードに区分化可能となっている新構造化文書に対し、新構造化文書における先頭からの新ノードの出現順及び状態遷移図におけるノード遷移順に従い、それぞれ新構造化文書及び状態遷移図において相互に対応する新ノード及び元ノードの対を選定対として抽出する。S133(一致性判定ステップ)では、選定対の元ノード及び新ノードに対し、それらの一致性の有無をそれらの記述に基づき判定する。S134(ノード認定ステップ)では、一致性有りの判定のときには選定対の元ノード及び新ノードに対し該元ノードを該新ノードの被利用ノードに認定する。
S135では、一致性判定を終了するか否かを判定し、該判定の結果が正であれば、S136へ進み、否であれば、S132へ戻る。S135における判定が正になる場合とは、例えば、新構造化文書110の全部のノードについて、一致性判定を終了したとか、新構造化文書110において、状態遷移図のどの元ノードにも一致性の無い新ノードが所定値以上に達し、該新構造化文書110について、これ以上、一致性判定を続けるのに意義がないと判断したときとかである。
S136(遷移履歴情報生成ステップ)では、状態遷移図上の複数個の被利用ノードを遷移順に進む遷移履歴に係る情報を遷移履歴情報として生成する。S137(類似度検出ステップ)では、遷移履歴情報に基づき元構造化文書と新構造化文書との類似度を検出する。
図4は別の構造化文書処理方法140のフローチャートである。構造化文書処理方法140において、構造化文書処理方法130(図3)のステップと同一のステップについては同符号を指示し、構造化文書処理方法130との相違点について説明する。
S141(構文解析結果記憶ステップ)では、元構造化文書の各ノードについての構文解析結果を記憶する。なお、S131とS141との順番は入れ替えてもよい。S142では、S137で検出した類似度か基準値以上であるか否かを判定し、該判定の結果が正であるときのみ、以降の処理としての元構造化文書109の利用処理へ進む。
S143(利用認定ステップ)では、元構造化文書及び新構造化文書の類似度が基準値以上であるときには(S142の判定が正)、元構造化文書を新構造化文書の被利用構造化文書と認定する。S144(元構造化文書利用ステップ)では、新構造化文書の新ノードに係る構文解析結果として、該新構造化文書の被利用構造化文書における新ノードの被利用ノードに係る構文解析結果を利用する。
ここで、「構造化文書処理装置100等」とは、前述した構造化文書処理装置100(図1)及び構造化文書処理装置120(図2)、並びに後述の構造化文書処理装置210(図6)、構造化文書処理装置220(図7)、構造化文書処理装置300(図13)及び構造化文書処理装置320(図14)を指すものとする。また、「構造化文書処理方法130等」とは、前述した構造化文書処理方法130(図3)及び構造化文書処理方法140(図4)、並びに後述する構造化文書処理方法250(図8)、構造化文書処理方法260(図9)、構造化文書処理方法270(図10〜図12)、構造化文書処理方法340(図15)、構造化文書処理方法360(図16)及び構造化文書処理方法380(図17)を指すものとする。構造化文書処理装置100等及び構造化文書処理方法130等は、ハードウェア、ソフトウェア、又はそれらの組み合わせにより実現可能である。ハードウェアとソフトウェアとの組み合わせによる実行において、所定のプログラムを有するコンピュータシステムにおける実行が典型的な例と挙げられる。かかる場合、該所定プログラムが該コンピュータシステムにロードされ実行されることにより、該プログラムは、コンピュータシステムを制御し、これら構造化文書処理装置100等に係る処理を実行させる。このプログラムは、任意の言語・コード・表記によって表現可能な命令群から構成される。そのような命令群は、システムが特定の機能を直接、又は(a)他の言語・コード・表記への変換、(c)他の媒体への複製、のいずれか一方もしくは双方が行われた後に、実行することを可能にするものである。もちろん、構造化文書処理装置100等は、そのようなプログラム自体のみならず、プログラムを記録した媒体もその範囲に含むものである。構造化文書処理装置100等の機能を実行するためのプログラムは、フレキシブル・ディスク、MO、CD−ROM、DVD、ハード・ディスク装置、ROM、MRAM、RAM等の任意のコンピュータ読み取り可能な記録媒体に格納することができる。かかるプログラムは、記録媒体への格納のために、通信回線で接続する他のコンピュータシステムからダウンロードしたり、他の記録媒体から複製したりすることができる。また、かかるプログラムは、圧縮し、又は複数に分割して、単一又は複数の記録媒体に格納することもできる。
図5は構造化文書処理装置100等や構造化文書処理方法130等のためのプログラムが実装されるコンピュータ160の概略構成図である。該プログラムは、構造化文書処理装置100等の各手段としてコンピュータ160を機能させる。また、該プログラムは、構造化文書処理方法130等の各ステップをコンピュータ160に実行させる。コンピュータ本体161はCPU162及び主記憶装置163を含み、CPU162はさらに演算装置164及び制御装置165を含む。演算装置164は、演算、比較及び判断等を行い、制御装置165は主記憶装置163や演算装置164等を制御する。システム・バス170は、データ・バス、アドレス・バス及び制御バスから成り、CPU162、主記憶装置163、入力インターフェース175、入出力インターフェース176、及び出力インターフェース177が接続されている。入力装置180は例えばキー・ボードや読出し専用CDドライブ等であり、データを入力インターフェース175を介してシステム・バス170へ送る。外部記憶装置177は、例えば、HD(ハードディスク)装置や読書き可能なCDドライブ等であり、入出力インターフェース176を介してシステム・バス170とデータを送受する。出力装置182は、例えばディスプレイやプリンタであり、出力インターフェース177を介してシステム・バス170からのデータを受ける。100等のプログラムは、例えばHD装置等の外部記憶装置181に保存され、実行時には主記憶装置163へ読み込まれる。
図6は構造化文書処理装置210の機能ブロック図である。構造化文書処理装置210は、アプリケーション・プログラムからの構造化文書の構文解析要求に対し、該構造化文書を構文解析して、その構文解析結果をアプリケーション・プログラムへ通知するものであり、記憶手段212、判別手段213、解析手段214、及び通知手段215を有している。記憶手段212は、構文解析済みの構造化文書としての元構造化文書についてその内容及びその構文解析結果をそれぞれ元内容及び元解析結果として記憶する。判別手段213は、アプリケーション・プログラムから構文解析を要求された構造化文書としての新構造化文書に対し、該新構造化文書の内容と元構造化文書の元内容とを、所定の対応関係を持つ内容部分同士で対比して、新構造化文書の各内容部分が、元構造化文書の元解析結果を利用できる第1の内容部分となっているか、又は元構造化文書の元解析結果を利用できない第2の内容部分となっているかを判別する。解析手段214は、新構造化文書の第2の内容部分を構文解析してその構文解析結果としての新解析部分を出力する。通知手段215は、新構造化文書の第1の内容部分の構文解析結果としては、該第1の内容部分に対応する元構造化文書の元解析結果の部分をアプリケーション・プログラムへ通知し、また新構造化文書の第2の内容部分の構文解析結果としては新解析部分をアプリケーション・プログラムへ通知する。
構造化文書処理装置210のみならず、後述の構造化文書処理装置20及び構造化文書処理方法において、構造化文書とは、例えばSGML(Standard Generalized Markup Language)文書やXML文書である。記憶手段212及び後述の記憶手段21とは、例えばハード・ディスク装置やキャッシュ・メモリである。キャッシュ・メモリの記憶は、コンピュータの電源オフに伴い、消失するので、コンピュータの次の作動時にも、元構造化文書の構文解析結果を利用するためには、キャッシュ・メモリ上の元構造化文書の構文解析結果に係るデータはバックアップのためハード・ディスク装置へ適宜、保存する必要がある。
通常、構造化文書を構文解析するには、構造化文書の字句解析や構造化文書の整形式検査も必要になる。したがって、構造化文書の構文解析の処理には構造化文書の字句解析の処理や整形式の検査処理が包含される。そして、構文解析結果が記憶手段212,221に記憶される元構造化文書は、当然に字句解析及び整形式検査が済まされたものとなっている。字句解析や整形式検査を包含する典型的な構文解析には次の処理が含まれる。
(a)XML文書の文字コードをユニコード(Unicode)の所定の文字に復号する。
(b)XML文書内の文字列に対して、タグを認識し、この認識に基づき、要素名、属性名、属性値、テキスト・ノードの文字列について、XMLの生成規則に適合しているか否かを検査する。
(c)名前空間の処理では、名前空間の宣言を認識し、それぞれの要素、属性の接頭辞から名前空間のURIをバインドする。
記憶手段212に記憶される元構造化文書の構文解析結果は、DOM(Document Object Model)インターフェースのツリー構造に係る情報であってもよいし、SAX(Simple API for XML)インターフェースの一連のイベントに係る情報であってもよい。判別手段213における第1及び第2の内容部分の判別は、例えば、相互に対比する新構造化文書及び元構造化文書の内容部分同士が一致するか否かが基準とされ、一致すれば、新構造化文書の該当内容部分は、第1の内容部分であると判断され、不一致であれば、新構造化文書の該当内容部分は、第2の内容部分であると判断される。構文解析結果をイベントの情報形式とする場合、相互に対比する新構造化文書及び元構造化文書の内容部分はイベントに対応するものとすることができる。
こうして、新構造化文書の構文解析結果をアプリケーション・プログラムへ通知する場合に、新構造化文書の内容の内、第1の内容部分は、新たに構文解析することなく、その構文解析結果としてすでに構文解析済みの元構造化文書の対応構文解析結果部分を代替できるので、新構造化文書全体の構文解析処理時間が短縮される。
図7は別の構造化文書処理装置220の機能ブロック図である。構造化文書処理装置220は、アプリケーション・プログラムからの構造化文書の構文解析要求に対し、該構造化文書を構文解析し、その構文解析結果としての一連のイベントをアプリケーション・プログラムへ通知する。構造化文書処理装置220は、記憶手段221、一致判定手段222、分類手段223、解析手段224、及び通知手段225を有している。記憶手段221は、構文解析済みの構造化文書としての元構造化文書についてその内容と各構造区分に係る構文解析結果とをそれぞれ元内容及び各元解析区分として記憶する。一致判定手段222は、元構造化文書の元内容とアプリケーション・プログラムから構文解析を要求された構造化文書としての新構造化文書の内容とを、それらの相互に対応する構造区分同士でかつ文書の先頭側にある構造区分同士から順番に、相互に一致するか否かの一致判定を実施する。分類手段223は、新構造化文書の各構造区分を、該構造区分に係る一致判定の正否によりそれぞれ第1の分類の構造区分と第2の分類の構造区分とに分類する。解析手段224は、分類手段223により第2の分類の構造区分と分類された構造区分を構文解析してその構文解析結果としての新解析区分を生成する。通知手段225は、新構造化文書の先頭の構造区分から末尾の構造区分の方への順番に各構造区分に係るイベントをアプリケーション・プログラムへ通知する。通知手段225は、新構造化文書の各構造区分が、第1の分類の構造区分であれば、該構造区分の構文解析結果として、該構造区分に対応する元構造化文書の元解析区分に係るイベントをアプリケーション・プログラムへ通知する。通知手段225は、第2の分類の構造区分であれば、該構造区分の構文解析結果として、該構造区分についての新解析区分に係るイベントをアプリケーション・プログラムへ通知する。
構造化文書処理装置220は例えばSAXインターフェースである。構造区分とは、例えばSAXのイベントに対応付けることのできる区分である。構造区分は、SAXで定義されているイベントだけに対応つけてもよいし、設計者がSAXで定義されているイベントに新規のイベントを追加したり、複数個のイベントを統合したりしてもよい。ただし、設計者がイベントを追加したり、統合したりするときは、それら変更イベントからSAX定義のイベントへ変換できるものである必要がある。後述するように、SAXのイベントと設計者が追加したり統合したイベントとを併せて、「イベントの種類」と呼んでいる。
構造化文書処理装置220では、新構造化文書の内容を全部、構文解析することなく、新構造化文書において元構造化文書の内容との不一致が生じた構造区分のみが構文解析され、新構造化文書の残りの内容部分は、該内容部分に対応する元構造化文書に係る元解析区分を使用して、アプリケーション・プログラムへのイベントの通知に対処する。したがって、新構造化文書の構文解析時間を短縮できる。
構造化文書処理装置220には、次に機能ごとに説明するそれら各機能を任意の組み合わせで、適宜、追加できる。それら各機能には、新たに追加された機能だけでなく、実装済みの機能の具体化したものも含まれる。それら各機能は、手段を追加したり、及び/又は、実装済みの手段の処理内容を具体化したりすることにより達成される。
解析手段224、一致判定手段222、及び通知手段225が寄与する機能について説明する。解析手段224は、構造区分の構文解析には該構文解析の結果に基づいて判明する検査であって新構造化文書が非整形式の構造化文書であるか否かの検査を含む。一致判定手段222は、新構造化文書の構造区分についての一致判定の結果が否であれば、該構造区分についての解析手段による非整形式の検査が終了するまで該構造区分の次の構造区分についての一致判定を保留し、検査により新構造化文書が非整形式であると判明すれば、新構造化文書に係る一致判定を中止する。通知手段225は、検査により新構造化文書が非整形式であると判明すれば、アプリケーション・プログラムへ、イベントの代わりに該新構造化文書が非整形式の構造化文書である旨を通知する。
SAXの規定では、アプリケーション・プログラムから構文解析を要求された構造化文書が非整形式の構造化文書である場合には、アプリケーション・プログラムへ構文解析結果としての一連のイベントを構造化文書の構造区分に係る順番で通知する代わりに、非整形式の構造化文書である旨を通知することになっている。具体的な非整形式の構造化文書とは、例えば、開始タグと終了タグとの名前が不一致であるものとか、1個の要素に、同じ名前の属性名が2個以上、存在するものとかである。なお、妥当な(Valid)XML文書は、整形式のXML文書の内の特殊なものである。通常の整形式のXML文書を構文解析する場合には、XMLの構文規則だけが必要であるが、妥当なXML文書を構文解析する場合には、XMLの構文規則の他に、DTD(Document Type Definition)が必要になる。構造化文書が整形式であるか否かは、通常、新構造化文書において整形式の検査中の構造区分単独では検査できず、新構造化文書の先頭の構造区分から検査中の構造区分までの範囲の構文解析結果情報が必要になる。該範囲の構文解析結果情報の内、第1の分類の各構造区分の構文解析結果情報については、元構造化文書の対応する元解析区分が利用される。
新構造化文書が非整形式の構造化文書であるかは、新構造化文書の先頭から末尾の方へ新構造化文書の内容を所定の判明箇所まで検査していく必要があり、従来の構造化文書処理装置の整形式検査過程では、新構造化文書をその先頭から判明箇所まで全部の内容を構文解析しなければならなかったの対し、構造化文書処理装置220における整形式検査過程では、元構造化文書の構造区分と同一の新構造化文書の構造区分については、その構文解析を省略して、判明箇所へ到達するので、到達時間が早まる。結果、新構造化文書が非整形式であるか否かの検査を早めて、アプリケーション・プログラムに通知することができる。
一致判定手段222が寄与する構造化文書処理装置220の機能について説明する。一致判定手段222において、一致判定は、新構造化文書の内容と元構造化文書の内容との相互に対応する構造区分同士内で、先頭から末尾の方へ1バイト又は1文字のデータを単位として一致するか否かを判定していくものとなっている。
先頭から末尾の方へ1バイト又は1文字のデータ単位で、元構造化文書及び新構造化文書の内容が一致するか否かを検査する場合、構造化文書における各データの位置は、構造化文書の先頭からのバイト数及び文字数で把握でき、検査が能率的となる。
次に、記憶手段221、最類似構造化文書選択手段31、及び一致判定手段222が寄与する構造化文書処理装置220の機能について説明する。記憶手段221は、相互に異なる複数個の元構造化文書に係る元内容及び元解析区分を記憶する。最類似構造化文書選択手段31は、元内容及び元解析区分が記憶手段221に記憶されている複数個の元構造化文書の中から元内容が新構造化文書の内容に最も類似する元構造化文書を最類似構造化文書として選択する。一致判定手段222は、一致判定に係る元構造化文書を最類似構造化文書にする。
新構造化文書に対して最類似の元構造化文書がどれかは例えば後述する基準により決定される。最類似の元構造化文書でなくても、新構造化文書に対する差分量が所定内の元構造化文書であれば、新構造化文書の構文解析の高速化に十分に寄与することができる。
サーバ等検出手段232及び最類似構造化文書選択手段231が寄与する構造化文書処理装置220の機能について説明する。サーバ等検出手段232は、新構造化文書はWebサービスにおいてクライアントからのリクエストに対するサーバからのレスポンスに係るものであり、該リクエストからリクエスト先のサーバ及びオペレーションを検出する。最類似構造化文書選択手段231は、検出したサーバ及びオペレーションに基づいて最類似構造化文書を選択する。
Webサービスでは、クライアント(リクエスタ)がサーバ(プロバイダ)にリクエストを送信し、これに対して、サーバがクライアントへレスポンスを送信するようになっている。クライアント側において、サーバ及びオペレーションが新構造化文書に係るものと同一である元構造化文書は、新構造化文書と類似することは容易に予想が着く。なぜなら、XML文書はアプリケーション・プログラムによって生成されるが、アプリケーション・プログラムはXMLでエンコードされたメッセージを生成する処理はライブラリやアプリケーション・サーバなどのミドルウェアに任されていることが多いからである。すなわち、同じライブラリによって生成された同様の内容のXML文書のバイト列や文字列は似通ってくる。したがって、サーバ及びオペレーションが新構造化文書に係るものと同一である元構造化文書を最類似構造化文書に選択することにより、新構造化文書の構文解析の処理時間を短縮できる。
URL検出手段233及び最類似構造化文書選択手段231が寄与する構造化文書処理装置220の機能について説明する。URL検出手段233は、新構造化文書はWebサービスのリクエストに係るものであり、該リクエストの送信先のURLを検出する。最類似構造化文書選択手段231は、検出したURLに基づいて最類似構造化文書を選択する。
典型的なサーバでは、1個のオペレーションに対して1個のURLを割当てる。したがって、サーバ側において、URLが新構造化文書に係るものと同一である元構造化文書は、新構造化文書と類似することは容易に予想が着く。したがって、URLが新構造化文書に係るものと同一である元構造化文書を最類似構造化文書に選択することにより、新構造化文書の構文解析の処理時間を短縮できる。
差分量計算手段234及び分類手段223が寄与する構造化文書処理装置220の機能について説明する。差分量計算手段234は、一致判定が否となるごとに、新構造化文書の内容と元構造化文書の内容との差分量を一単位、増大させる。分類手段223は、差分量が閾値を越えると、最後に一致判定対象となった構造区分から文書末尾の構造区分までの全部の構造区分について第2の分類の構造区分に分類する。
閾値は任意に設定できる。閾値は例えば新構造化文書のサイズの増大に応じて大きい値にすることができる。新構造化文書の内容と元構造化文書の内容との差分量は、両者における対応構造区分が不一致となっている個数に比例するとともに、新構造化文書の内容の先頭から末尾へ向かって差分量が計算されていく。そして、新構造化文書の文書途中において、差分量が閾値を越えると、新構造化文書に対する元構造化文書の類似度は低いとして、すなわち該元構造化文書の構文解析結果を該新構造化文書の構文解析結果に利用することは難が多いとして、両者の対比は取止め、新構造化文書において最後の一致判定対象となった構造区分から文書末尾の構造区分までの全部の構造区分は第2の分類の構造区分に分類される。これにより、それら全部の構造区分は、解析手段224により解析されて、それらの新解析区分が生成され、新解析区分に係るイベントがアプリケーション・プログラムへ通知される。なお、新構造化文書において、最後の一致判定対象となった構造区分から文書末尾の構造区分までの全部の構造区分に限定せず、新構造化文書の全部の構造区分を第2の分類の構造区分に分類して、すなわち、新構造化文書全体を構文解析することも可能である。
差分量計算手段234及び一致判定手段222が寄与する構造化文書処理装置220の機能について説明する。差分量計算手段234は、一致判定が否となるごとに、新構造化文書の内容と元構造化文書の内容との差分量を一単位、増大させる。一致判定手段222は、差分量が閾値を越えると、現在の元構造化文書を別の元構造化文書へ交換し、新構造化文書と交換前の元構造化文書に対して実施した処理と同一の処理を新構造化文書と交換後の元構造化文書について最初から再実施する。
元構造化文書の選択によっては、選択がまずく、元構造化文書が予想に反して新構造化文書と類似していない場合がある。また、新構造化文書のサイズが大きい場合には、元構造化文書の交換回数を所定値以内とすれば、結局、元構造化文書の構文解析結果を利用しての新構造化文書の構文解析の方が、該新構造化文書を丸々構造化文書するよりも構文解析処理時間の短縮が見込まれる場合がある。元構造化文書の交換回数を所定値以内に制限しつつ、新構造化文書の構文解析に元構造化文書の構文解析結果を利用することにより、新構造化文書の構文解析処理速度を速めることができる。
図8は構造化文書処理方法250のフローチャートである。該構造化文書処理方法は、アプリケーション・プログラムからの構造化文書の構文解析要求に対し、該構造化文書を構文解析して、その構文解析結果をアプリケーション・プログラムへ通知する。構造化文書処理方法は、S252(記憶ステップ)、S253(判別ステップ)、S254(解析ステップ)、及びS255(通知ステップ)を有している。S252(記憶ステップ)では、構文解析済みの構造化文書としての元構造化文書についてその内容及びその構文解析結果をそれぞれ元内容及び元解析結果として記憶する。S253(判別ステップ)では、アプリケーション・プログラムから構文解析を要求された構造化文書としての新構造化文書に対し、該新構造化文書の内容と元構造化文書の元内容とを、所定の対応関係を持つ内容部分同士で対比して、新構造化文書の各内容部分が、元構造化文書の元解析結果を利用できる第1の内容部分となっているか、又は元構造化文書の元解析結果を利用できない第2の内容部分となっているかを判別する。S254(解析ステップ)では、新構造化文書の第2の内容部分を構文解析してその構文解析結果としての新解析部分を出力する。S255(通知ステップ)では、新構造化文書の第1の内容部分の構文解析結果としては、該第1の内容部分に対応する元構造化文書の元解析結果の部分をアプリケーション・プログラムへ通知し、また新構造化文書の第2の内容部分の構文解析結果としては新解析部分をアプリケーション・プログラムへ通知する。
図9は別の構造化文書処理方法260のフローチャートである。該別の構造化文書処理方法は、アプリケーション・プログラムからの構造化文書の構文解析要求に対し、該構造化文書を構文解析し、その構文解析結果としての一連のイベントをアプリケーション・プログラムへ通知するものである。構造化文書処理方法は、S261(記憶ステップ)、S262(一致判定ステップ)、S263,S264(分類ステップ)、S265(解析ステップ)、及びS266(通知ステップ)を有している。S261(記憶ステップ)では、構文解析済みの構造化文書としての元構造化文書についてその内容と各構造区分に係る構文解析結果とをそれぞれ元内容及び各元解析区分として記憶する。S262(一致判定ステップ)では、元構造化文書の元内容とアプリケーション・プログラムから構文解析を要求された構造化文書としての新構造化文書の内容とを、それらの相互に対応する構造区分同士でかつ文書の先頭側にある構造区分同士から順番に、相互に一致するか否かの一致判定を実施する。S263,S264(分類ステップ)では、新構造化文書の各構造区分を、該構造区分に係る一致判定の正否によりそれぞれ第1の分類の構造区分と第2の分類の構造区分とに分類する。S265(解析ステップ)では、S263,S264(分類ステップ)において第2の分類の構造区分と分類された構造区分を構文解析してその構文解析結果としての新解析区分を生成する。S266(通知ステップ)では、新構造化文書の先頭の構造区分から末尾の構造区分の方への順番に各構造区分に係るイベントをアプリケーション・プログラムへ通知する。S266(通知ステップ)では、構造化文書の各構造区分が、第1の分類の構造区分であれば、該構造区分の構文解析結果として、該構造区分に対応する元構造化文書の元解析区分に係るイベントをアプリケーション・プログラムへ通知し、また、第2の分類の構造区分であれば、該構造区分の構文解析結果として、該構造区分についての新解析区分に係るイベントをアプリケーション・プログラムへ通知する。
ここで、説明の便宜上、元構造化文書及び新構造化文書の「現在位置」について定義する。元構造化文書及び新構造化文書の「現在位置」とは、S262において一致判定を行なう元構造化文書及び新構造化文書における対応構造区分に係る位置を、それぞれいうものとする。S267(末尾到達判定ステップ)では、元構造化文書及び新構造化文書の現在位置を、S266においてアプリケーション・プログラムへイベントを通知した構造区分に対応する分だけ、文書末尾の方へ移動させ、該移動の結果、現在位置が元構造化文書及び新構造化文書の末尾になったか否かを判定する。そして、該判定が正であるならば、該ルーチンを終了し、否であるならば、S262へ戻る。
図9に係る別の構造化文書処理方法は、さらに、種々の機能を任意の組み合わせで追加可能になっている。それら各機能は、新しいステップを追加したり、又は装備済みのステップの処理内容を具体化したりすることにより実現される。図10〜図12は図9に係る構造化文書処理方法260に対し、種々の機能を追加した構造化文書処理方法270のフローチャートの部分図である。以下、図9〜図12のいずれかを参照しつつ、該構造化文書処理方法270の追加機能について説明する。
追加機能の1つは、S265(解析ステップ)、S262(一致判定ステップ)、S271(非整形式判定ステップ)及びS272(通知ステップ)により実現される。図10において、S265(解析ステップ)では、構造区分の構文解析には該構文解析の結果に基づいて判明する検査であって新構造化文書が非整形式の構造化文書であるか否かの検査を含ませる。S271(非整形式判定ステップ)では、該構造区分についてのS265(解析ステップ)における構文解析の結果、新構造化文書が非整形式であるか否かの非整形式判定を実施する。S271において、判定結果が正であれば、S272(通知ステップ)へ進んでから、該ルーチンを終了する。すなわち、S262(一致判定ステップ)では、新構造化文書の構造区分についての一致判定の結果が否であれば、該構造区分についての解析手段による非整形式の検査が終了するまで該構造区分の次の構造区分についての一致判定を保留し、検査により新構造化文書が非整形式であると判明すれば、新構造化文書に係る一致判定を中止する。S272(通知ステップ)では、検査により新構造化文書が非整形式であると判明すれば、アプリケーション・プログラムへ、イベントの代わりに該新構造化文書が非整形式の構造化文書である旨を通知する。
別の追加機能はS262(一致判定ステップ)により実現される。図9において、S262(一致判定ステップ)では、一致判定は、新構造化文書の内容と元構造化文書の内容との相互に対応する構造区分同士内で、先頭から末尾の方へ1バイト又は1文字のデータを単位として一致するか否かを判定していくものである。
他の追加機能は、S261(記憶ステップ)、S276(最類似構造化文書選択ステップ)及びS262(一致判定ステップ)により実現される。図11において、S261(記憶ステップ)では、相互に異なる複数個の元構造化文書についてその内容とその元解析区分とを記憶する。S276(最類似構造化文書選択ステップ)では、S261(記憶ステップ)において記憶した複数個の元構造化文書の中から元内容が新構造化文書の内容に最も類似する元構造化文書を最類似構造化文書として選択する。S262(一致判定ステップ)では、一致判定に係る元構造化文書を最類似構造化文書にする。
別の機能はS278(サーバ等検出ステップ)及びS276(最類似構造化文書選択ステップ)により実現される。図11において、S278(サーバ等検出ステップ)では、新構造化文書はWebサービスにおいてクライアントからのリクエストに対するサーバからのレスポンスに係るものであり、該リクエストからリクエスト先のサーバ及びオペレーションを検出する。S276(最類似構造化文書選択ステップ)では、検出したサーバ及びオペレーションに基づいて最類似構造化文書を選択する。
別の機能はS280(URL検出ステップ)及びS276(最類似構造化文書選択ステップ)により実現される。S280(URL検出ステップ)では、新構造化文書はWebサービスのリクエストに係るものであり、該リクエストの送信先のURLを検出する。S276(最類似構造化文書選択ステップ)では、検出したURLに基づいて最類似構造化文書を選択する。
別の機能は、S283、S262内の2個のサブステップS284,S285、及びS287により実現される。図12において、S283(差分量初期値設定ステップ)では、差分量に初期値として0が設定される。S284(差分量計算ステップ)では、S262における一致判定が否となるごとに、新構造化文書の内容と元構造化文書の内容との差分量を一単位、増大させる。S285(差分量判定ステップ)では、差分量が閾値より大きいか否かを判定し、判定が正になると、S287へ進む。S287(分類ステップ)では、新構造化文書において、最後に一致判定対象となった構造区分から文書末尾の構造区分までの全部の構造区分について第2の分類の構造区分に分類し、S265へ進む。
別の機能は、S283、S262内の2個のサブステップS284,S285、及びS288により実現される。図12において、S283(差分量初期値設定ステップ)では、差分量に初期値として0が設定される。S284(差分量計算ステップ)では、S262における一致判定が否となるごとに、新構造化文書の内容と元構造化文書の内容との差分量を一単位、増大させる。S285(差分量判定ステップ)では、差分量が閾値より大きいか否かを判定し、判定が正になるや、S288(元構造化文書交換ステップ)へ進む。S288では、現在の元構造化文書を別の元構造化文書へ交換し、S283へ戻る。
S285の判定が正である場合、該ルーチンを終了させてもよい(S285→END)。
図13は別の構造化文書処理装置300の機能ブロック図である。構造化文書処理装置300は、状態遷移図情報記憶手段301、選定対抽出手段302、一致性判定手段303、ノード認定手段304、遷移履歴情報生成手段305、被利用構造化文書選択手段306及び元構造化文書利用手段307を有している。状態遷移図情報記憶手段301は、各元構造化文書109が構造区分に係る複数個のノードとしての複数個の元ノードに区分化可能となっている複数個の元構造化文書109に対し、各元構造化文書109の元ノードが元構造化文書109の先頭からの出現順に遷移する状態遷移図に係る情報を状態遷移図情報として記憶する。状態遷移図情報記憶手段301は、また、複数の元構造化文書109の内の複数の元構造化文書109に重複する状態遷移は状態遷移図上において共通化された状態遷移となっている。選定対抽出手段302は、構造区分に係る複数個のノードとしての複数個の新ノードに区分化可能となっている新構造化文書110に対し、新構造化文書110の先頭からの新ノードの出現順及び状態遷移図におけるノード遷移順に従い、それぞれ新構造化文書110及び状態遷移図において相互に対応する新ノード及び元ノードの対を選定対として抽出する。一致性判定手段303は、選定対の元ノード及び新ノードに対し、それらの一致性の有無をそれらの記述に基づき判定する。ノード認定手段304は、一致性有りの判定のときには選定対の元ノード及び新ノードに対し該元ノードを該新ノードの被利用ノードに認定する。遷移履歴情報生成手段305は、状態遷移図上の複数個の被利用ノードを遷移順に進む遷移履歴に係る情報を遷移履歴情報として生成する。被利用構造化文書選択手段306は、遷移履歴情報に基づき1個の元構造化文書109を新構造化文書110の被利用構造化文書として選択する。元構造化文書利用手段307は、新構造化文書110の新ノードに係る構文解析結果として、該新構造化文書110の被利用構造化文書におけるノードであって該新ノードの被利用ノードに係る構文解析結果を利用する。
図13の構造化文書処理装置300と後述の図15の構造化文書処理方法340とは、発明のカテゴリがそれぞれ装置及び方法と相違するのみで、実質的な技術内容は同一であるので、両者を代表して構造化文書処理装置300について説明を行なう。状態遷移図(例:図32)は、複数個n(図32では、n=3)の元構造化文書109に係る状態遷移を含んでいる。複数個m(m≦n。図32では、m=2)の元構造化文書109に重複する状態遷移(図32では、元構造化文書A,Bについての状態615→状態616)は、状態遷移図においてまとめられ、すなわち共通化されている。この共通化により、状態遷移図情報の記憶のために必要な量を、元構造化文書109の総個数及び総ノード数の割りに低減することができる。なお、複数個の元構造化文書109に重複する状態遷移は、状態遷移図上で必ず共通化されていなければならないとは限定していない。典型的には、選定対抽出手段302は、それが認定した選定対に対して、一致性判定手段303が一致性無しと判定すると、不一致判定の選定対の元ノードはそのままとしつつ、被利用ノードを遷移順番が次の被利用ノードへ変更して、選定対を更新する。そして、新ノードが状態遷移図のどの元ノードに対しても一致性無しということが判明すると、選定対の新ノードが出現順番が次のものに変更される。
例えば、状態遷移図上の状態遷移が後述の図31の状態遷移図600における状態601から状態602又は状態608へのように分岐する場合がある。これに対して、状態遷移機械が状態601まで進み、新構造化文書の次のノードが「<y/>」であるとき、「<y/>」の全部を認知してから、該「<y/>」としての新ノードに対応する元ノードが状態602か状態608かを探すのは、状態遷移図上の分岐先の元ノードが多数になるに連れて、処理時間が膨大になってしまう。そこで、分岐点では、各状態を予めソーティングしておき、新ノードの「<」が出現した時点で(新ノードのバイト列の1番目のバイト又は文字列の1番目の文字が判明した時点で)、すなわち、状態602の「text」とは異なることが分かるや、状態602は一致性判定の候補から外し、状態608だけを一致性判定の候補に絞り、これにより、処理速度を高速化するのが好ましい。これに対処するため、構造化文書処理装置300の発展型では、状態遷移図情報記憶手段301は、状態遷移図情報について、状態遷移の分岐部分では、分岐先の複数個のノードの記述(該記述はバイト列又は文字列)をソーティングして記憶している。また、選定対抽出手段302は、分岐先の全部のノードを選定対の元ノードとし、すなわち、選定対では、1個の新ノードに対して元ノードは複数個として、選定対を抽出し、一致性判定手段303へ手渡す。一致性判定手段303は、1個の新ノードとしてのバイト列又は文字列を最初のバイト又は文字から順に見つつ、各バイト又は各文字に一致する元ノードのみへ一致性判定の候補を順次、絞り込み(この絞込みは元ノードのソーティングのために高速に進むことができる。)、最後まで候補として残った1個の元ノードと、新ノードに対する一致性判定を行う。
被利用構造化文書選択手段306が新構造化文書110の被利用構造化文書として選定する元構造化文書109とは、例えば、状態遷移が状態遷移図における新構造化文書110の遷移履歴と最も多く重複する元構造化文書109であり、状態遷移が状態遷移図における新構造化文書110の遷移履歴と最も多く重複する元構造化文書109とは例えば、該遷移履歴上に新構造化文書110に対して最も多くの被利用ノードをもつ元構造化文書109である。
新構造化文書の新ノードに対応する被利用ノードが被利用構造化文書に存在しない場合には、該新ノードは、被利用構造化文書に対する差分となる。差分と相当する新ノードに係る構文解析結果は、元構造化文書109の構文解析結果を利用できないので、もし、該差分に該当する新ノードに係る構文解析結果が必要である場合には、該新ノードは、それ自体を構文解析して、構文解析結果を得る。
こうして、状態遷移機械を使用することにより、新構造化文書110の構文解析のために、適切に利用できる構文解析結果をもつ元構造化文書109を効率的に見つけ出し、該元構造化文書109の構文解析結果を利用して、新構造化文書110の構文解析を高速化することができる。
図14は別の構造化文書処理装置320の機能ブロック図である。構造化文書処理装置320は、状態遷移図情報記憶手段301、選定対抽出手段302、一致性判定手段303、ノード認定手段304、遷移履歴情報生成手段305、被利用構造化文書選択手段306及び元構造化文書利用手段307の他に、元ノード追加手段321、状態遷移経路追加手段322、属性変数値記憶手段326及びテキスト・ノード変数値記憶手段327を追加されている。状態遷移図情報記憶手段301〜元構造化文書利用手段307は、図13の構造化文書処理装置300のそれらとほぼ同一である。また、元ノード追加手段321、状態遷移経路追加手段322、属性変数値記憶手段326及びテキスト・ノード変数値記憶手段327は、それらの全部が構造化文書処理装置320に装備される必要はなく、(a)元ノード追加手段321と状態遷移経路追加手段322だけ、(b)属性変数値記憶手段326だけ、(c)テキスト・ノード変数値記憶手段327だけ、及び(a)〜(c)の任意の組み合わせで構造化文書処理装置320に装備することができる。
元ノード追加手段321は、状態遷移図上のどの元ノードに選定対関係になっても元ノードとの一致性無しである新ノードとしての第1の新ノードに対し、該第1の新ノードを遷移先として遷移元になる状態遷移関係をもつ元ノードであって状態遷移図上の元ノードから、第1の新ノードへの状態遷移を形成しつつ、第1の新ノードを状態遷移図上に第1の元ノードとして新規に追加する(例:図30の状態608)。構造化文書における先頭からのノードの出現順でノードの先後を定義するとともに、コンテキストとは、内容を一意に把握する対象としてのノードを対象ノードと呼ぶことにして、構造化文書先頭から該対象ノードへの到達前までの構造化文書記述に含まれる記述部分であって、該対象ノードの内容を、該対象ノードの記述自体と協働して、一意に規定する記述部分と定義する。この定義は、後述の構造化文書処理方法360においても使用する。一致性判定手段303は、第1の新ノードより後ろの新ノードとしての第2の新ノードに対して、該第2の新ノードに係る選定対としての合流判定用選定対では、記述と共にコンテキストに関しても元ノードと新ノードとの一致性を判定する。状態遷移経路追加手段322は、合流判定用選定対における第2の新ノード及び第2の元ノードが記述及びコンテキストの両方に関して一致性有りとする判定がなされたときには、第1の元ノードから第2の元ノードへの状態遷移経路を新規に追加する(例:図31の状態608→状態603)。
元ノード追加手段321等を追加装備した構造化文書処理装置320と後述の図16の構造化文書処理方法360とは、発明のカテゴリがそれぞれ装置及び方法と相違するのみで、実質的な技術内容は同一であるので、両者を代表して構造化文書処理装置320について説明を行なう。「第1の新ノードより後ろの新ノードとしての第2の新ノード」と限定している理由は、第2の新ノードが第1の新ノードの次の新ノードとは限らないからである。第1の新ノードの次の新ノードは、対応する元ノードが状態遷移図上になく、かつ後述の(a)〜(c)等の理由により、状態遷移図に追加されないことがあるからである。
構造化文書処理装置320は、記述の観点で、新構造化文書と一致する元構造化文書が状態遷移図上に登録されていないときに、該新構造化文書の構文解析を状態遷移図に追加する機能を有している。これにより、状態遷移図に登録されている元構造化文書を豊富化し、追加登録後は、元構造化文書として追加登録した新構造化文書に類似する新構造化文書を受け付けたときに適切に対処できる。なお、状態遷移図に元ノードとして新ノードを追加される新構造化文書には、適当な条件を付けることが望ましい。条件としては、例えば、構文解析結果について既登録済みの元構造化文書に係る構文解析結果とは十分に相違する新構造化文書であって、今後、類似の新構造化文書の頻繁な到来が予想される新構造化文書であるということである。
元ノード追加手段321は、新構造化文書110の新ノードが第1の新ノードであれば、必ず、第1の新ノードを状態遷移図に第1の元ノードとして新規に追加するものではない。第1の新ノードであっても、状態遷移図に登録しない方が、すなわち、今後に受け付ける新構造化文書110において、該第1の新ノードについては、元構造化文書109の被利用ノードに係る構文解析結果を利用せずに、構文解析しても、構文解析の処理速度がさほど低下しないことが予想される場合や、相互にさほど相違しない元構造化文書109は状態遷移図にむやみに登録しない方が、処理速度を改善できる場合があるからである。第1の新ノードを登録しない例として次のものが挙げられる。
(a)短いTextイベント(例えば4文字より短いもの)
(b)既に状態遷移機械中に多数の重複状態として出現するイベント
(c)規則性に乏しいPI(Processing Information)イベントやCommentイベント(XML文書では、<!--〜-->の記述となる。)
状態遷移経路追加手段322では、選択対の元ノード及び新ノードの一致性について、記述の観点のみならず、コンテキストの観点からも検査(check)される。コンテキストには、例えば、実体宣言のリスト、現在有効な名前空間、ノードの階層などが含まれる。元ノード及び新ノードの記述が形式的に同一であっても、コンテキストによっては、実質的な内容が同一にならないことがあり、内容の同一を検査するために、コンテキストについての一致性も検査している、コンテキストについての一致性検査により、新構造化文書110について、整形式の検査が、状態遷移図上の遷移先の元構造化文書の決定と併せて行われることになり、新構造化文書110の構文解析を速めることができる。なお、元ノード追加手段321では、コンテキストの観点からの一致性検査が省略されているのは、状態遷移図上の元構造化文書109は整形式を保証されており、新構造化文書110の状態遷移図が状態遷移図上の元ノードから分岐するまでは、整形式を保証された元ノードを辿っているので、記述のみの一致性があれば、元構造化文書109が整形式であることを保証されるからである。
整形式(Well-formed)のXML文書を認識する状態遷移機械(オートマトン)を構築するためには、少なくとも実体参照宣言、名前空間宣言及び要素(ノード)の階層をコンテキストにすればよい。しかしながら、コンテキストの定義を緩める(=より多くの場所で合流ができるようにする)と、状態遷移機械の状態が担っているコンテキストの空間を広げることができる。
状態遷移図情報は例えば辞書で管理されるのが好ましい。「×」を直積演算記号として、項目1(ノードの記述)×項目2(該ノードのコンテキスト)→状態とする。辞書では、状態を登録するとともに、項目1,2に基づき状態を引くことができるようになっている。例えば、一致性判定手段303は、一致性検定手段を内蔵し、一致性検定手段は、第2の新ノードに対して、その記述及びコンテキストを項目として辞書を引き、辞書における状態(ノード)の有無を調べることができるように、なっている。状態が辞書に存在していれば、一致性判定手段303における判定は一致性有りとされる。こうして、第2の元ノードの検索を高速化できる。また、これに対応して、元ノード追加手段321は、元ノードを状態遷移図上に追加する際は、該追加の処理と共に、該追加した元ノードを項目1,2を使用して辞書から探し出せるように辞書に該元ノードを登録する。
属性変数値記憶手段326を追加装備した構造化文書処理装置320と後述の図17の構造化文書処理方法380(特にS384及びS385の範囲)とは、発明のカテゴリがそれぞれ装置及び方法と相違するのみで、実質的な技術内容は同一であるので、両者を代表して構造化文書処理装置320について説明を行なう。属性変数値記憶手段326を装備する構造化文書処理装置320は、選定対における元ノード及び新ノードが、完全一致でなく、多少相違していても、一致性有りと判断して、被利用構造化文書の元構造化文書109の解析済みの構文解析結果を新構造化文書110の構文解析に利用することかできる。
図13の構造化文書処理装置300に対する属性変数値記憶手段326付き構造化文書処理装置320の相違点について述べる。状態遷移図情報記憶手段301が記憶する状態遷移図情報では、状態遷移図上の所定の元ノードは、所定の属性を属性変数とする属性変数付き元ノードに設定されている。一致性判定手段303は、選定対における元ノードが属性変数付き元ノードであり、かつ選定対における元ノード及び新ノードの要素名及び属性名が同一であるとき、選定対における元ノード及び新ノードの一致性が有りとする。属性変数値記憶手段326は、一致性有りの選定対に対し、該選定対の元ノードが属性変数付き元ノードであるとき、選定対の新ノードの属性値を属性変数値として記憶する。元構造化文書利用手段307は、新構造化文書110の新ノードに係る構文解析結果として、該新構造化文書110の被利用構造化文書のノードであって該新構造化文書110の新ノードの被利用ノードに係る構文解析結果を使用する場合に、被利用ノードが属性変数付き元ノードであるとき、新構造化文書110の新ノードの被利用ノードに係る構文解析結果における属性変数に、属性変数値を代入した構文解析結果を、新構造化文書110の新ノードの被利用ノードに係る構文解析結果として使用する。
ノードの属性値の関数化については、後述の図43及び図45に詳細に説明するとおりである。具体的には、状態遷移図上の属性変数付き元ノードには、属性変数(図43の例では属性名URIの属性変数$some−variable)が設定され、状態遷移図上の属性変数付き元ノードに対して一致性有りの選定対関係にある新構造化文書110の新ノードの属性値(図43の例では、#myBody)が属性変数に対応付けられて記憶される。新構造化文書110の被利用構造化文書となった元構造化文書109に対し、元構造化文書109の属性変数付き元ノードに係る構文解析結果の属性変数の該当位置に、新ノードの属性値(図43の例では、#myBody)が代入され、該新ノードに係る構文解析結果とされる。
テキスト・ノード変数値記憶手段327を追加装備した構造化文書処理装置320と後述の図17の構造化文書処理方法380(特にS388及びS389の範囲)とは、発明のカテゴリがそれぞれ装置及び方法と相違するのみで、実質的な技術内容は同一であるので、両者を代表して構造化文書処理装置320について説明を行なう。テキスト・ノード変数値記憶手段327を装備する構造化文書処理装置320は、選定対における元ノード及び新ノードが、共にテキスト・ノードであるものの、内容についてはまったく相違していても、一致性有りと判断して、被利用構造化文書の元構造化文書109の解析済みの構文解析結果を新構造化文書110の構文解析に利用する。
図13の構造化文書処理装置300に対するテキスト・ノード変数値記憶手段327付き構造化文書処理装置320の相違点について述べる。状態遷移図情報記憶手段301は、状態遷移図上の所定のテキスト・ノードとしての元ノードはテキスト・ノード変数に設定されている。一致性判定手段303は、選定対における元ノード及び新ノードがそれぞれテキスト・ノード変数及びテキスト・ノードであるとき、元ノード及び新ノードの一致性が有りとする。テキスト・ノード変数値記憶手段327は、一致性有りの選定対に対し、該選定対の元ノードがテキスト・ノード変数であるとき、選定対の新ノードのテキストをテキスト・ノード変数値として記憶する。元構造化文書利用手段307は、新構造化文書110の新ノードに係る構文解析結果として、該新構造化文書110の被利用構造化文書のノードであって該新構造化文書110の新ノードの被利用ノードに係る構文解析結果を使用する場合に、被利用ノードがテキスト・ノード変数であるとき、新構造化文書110の新ノードの被利用ノードに係る構文解析結果におけるテキスト・ノード変数にテキスト・ノード変数値を代入した構文解析結果を、新構造化文書110の新ノードの被利用ノードに係る構文解析結果として使用する。
テキスト・ノードの関数化については、後述の図44及び図45に詳細に説明するとおりである。具体的には、状態遷移図上の所定のテキスト・ノードには、テキスト・ノード変数(図44の例ではテキスト・ノード変数$some−variableが設定され、状態遷移図上のテキスト・ノード変数に対して一致性有りの選定対関係にある新構造化文書110の新ノードのテキスト内容(図a44の例では、EULddytSo1...)がテキスト・ノード変数に対応付けられて記憶される。新構造化文書110の被利用構造化文書となった元構造化文書109に対し、そのテキスト・ノード変数に対応付けられて記憶されている新構造化文書110のテキスト内容があるとき、被利用構造化文書としての元構造化文書109におけるテキスト・ノード変数の箇所に、テキスト内容EULddytSo1...が代入されて、該属性変数付き元ノードに係る構文解析結果が新構造化文書110の新ノードに係る構文解析結果として利用される。
SOAPメッセージ、特にWS−Security付きSOAPメッセージの構文解析処理への構造化文書処理装置320の適用では、各元構造化文書はそれぞれテンプレート化(図40)されているのが好ましい。また、構造化文書処理装置320は、また、遷移履歴の各遷移履歴部分に対応するモジュールであってWS−Securityの処理に必要なモジュール(図46のトークン・コンシューマ703及び署名コンシューマ704,暗号コンシューマ705)を呼び出して、各モジュールに新構造化文書としてのSOAPメッセージのメッセージ部分の構文解析についての処理を任せる。テープレートは、各モジュール専用に複数、用意され、モジュールごとに適切な1個のテンプレートが選択される。トークン・コンシューマ703と署名コンシューマ704とは、テンプレートの使用に当たり、SOAPメッセージのモジュール該当部分の正規化が行なわれる。正規化とは、名前空間宣言の追加、属性の並べ替えである(正規化の具体的処理は図47及び図48に関連して後述する。)。すなわち、構造化文書処理装置320は、新構造化文書としてのSOAPメッセージの構文解析を省略できる元構造化文書としての(非正規化)テンプレートの他に、それら(非正規化)テンプレートに対応する正規化されたテンプレート(例:図47のテンプレート745)を用意して、正規化されたテンプレートのブランク部に、SOAPメッセージから抽出した属性値やテキスト・ノード変数値を書き込み、その後、ダイジェスト値等を算出する。
構造化文書処理装置320では、さらに、WS−Security付きSOAPメッセージを復号化したデータ用にテンプレートを用意し、状態遷移機械することができる(詳説は図49に関連して後述する。)。すなわち、コンテンツ部(図49のテンプレート内の$contents)をテキスト・ノード変数とし、その他のノードは構文解析済みとしている復号データ用テンプレートが用意され、復号したSOAPメッセージ(XML文書)に基づき、復号したコンテンツ値を抽出するとともに、状態繊維機械を用いて所望の復号データ用テンプレートを選択し、該選択した復号データ用テンプレートのコンテンツ部にコンテンツ値を代入する。
図15は構造化文書処理方法340のフローチャートである。S342(状態遷移図情報記憶ステップ)では、各元構造化文書が、構造区分に係る複数個のノードとしての複数個の元ノードに区分化可能となっている複数個の元構造化文書に対し、各元構造化文書の元ノードが元構造化文書における先頭からの出現順に遷移する状態遷移図に係る情報を状態遷移図情報として記憶する。S342では、また、複数の元構造化文書に重複する状態遷移は状態遷移図上において共通化された状態遷移となっている。S343(選定対抽出ステップ)では、構造区分に係る複数個のノードとしての複数個の新ノードに区分化可能となっている新構造化文書に対し、新構造化文書における先頭からの新ノードの出現順及び状態遷移図におけるノード遷移順に従い、それぞれ新構造化文書及び状態遷移図において相互に対応する新ノード及び元ノードの対を選定対として抽出する。S344(一致性判定ステップ)では、選定対の元ノード及び新ノードに対し、それらの一致性の有無をそれらの記述に基づき判定する。S345(ノード認定ステップ)では、一致性有りの判定のときには選定対の元ノード及び新ノードに対し該元ノードを該新ノードの被利用ノードに認定する。
S346では、一致性判定を終了するか否かを判定し、終了するならば、S347へ進み、続行するならば、S343へ戻る。S346において一致性判定を終了するときとは、例えば、(a)新構造化文書110の全部の新ノードについて一致性判定が終了したとき、(b)今回の新構造化文書110が、特異であって、状態遷移図上に一致性のある元ノードが見つからない新ノードの個数が閾値以上となったときである。(b)の場合には、今回の新構造化文書110における不一致の新ノードについては、後述の構造化文書処理方法360のように、状態遷移図上に元ノードとして追加してもよい。
S347(遷移履歴情報生成ステップ)では、状態遷移図上の複数個の被利用ノードを遷移順に進む遷移履歴に係る情報を遷移履歴情報として生成する。S348(被利用構造化文書選択ステップ)では、遷移履歴情報に基づき1個の元構造化文書を新構造化文書の被利用構造化文書として選択する。S349(元構造化文書利用ステップ)では、新構造化文書の新ノードに係る構文解析結果として、該新構造化文書の被利用構造化文書における新ノードの被利用ノードに係る構文解析結果を利用する。
図16は構造化文書処理方法360の主要部のフローチャートである。構造化文書処理方法360において、S342以前のステップ及びS347以後のステップは、図15の構造化文書処理方法340のステップと同一であり、図示を省略している。構造化文書処理方法340との相違点について説明する。
構造化文書処理方法360において、S365(元ノード追加ステップ)では、状態遷移図上のどの元ノードに選定対関係になっても元ノードとの一致性無しである新ノードとしての第1の新ノードに対し、該第1の新ノードを遷移先として遷移元になる状態遷移関係をもつ元ノードであって状態遷移図上の元ノードから、第1の新ノードへの状態遷移を形成しつつ、第1の新ノードを状態遷移図上に第1の元ノードとして新規に追加する。S344(一致性判定ステップ)のS367では、第1の新ノードより後ろの新ノードとしての第2の新ノードに対して、該第2の新ノードに係る選定対としての合流判定用選定対では、記述と共にコンテキストに関しても元ノードと新ノードとの一致性を判定する。S368(状態遷移経路追加ステップ)では、合流判定用選定対における第2の新ノード及び第2の元ノードが記述及びコンテキストの両方に関して一致性有りとする判定がなされたときには(S367の判定結果が正)、第1の元ノードから第2の元ノードへの状態遷移経路を新規に追加する。
図16では、構造化文書処理方法360におけるS344の中身の詳細及びS368等の進行経路が示されている。S361,S362,S367はS344のサブステップとなっている。また、S365の処理後は、S343へ戻る。S368の処理後は、S343へ戻る。S367における判定が否であれば、S365へ進み、S367における新ノードを第1の元ノードとして状態遷移図に追加される。S367における判定が否であるとき、S365ではなく、S343へ戻ることもできる。S365,S368を有しない構造化文書処理方法340(図15)のS344は、その中身がS362のみであると考えることができる。S362では、選定対の元ノード及び新ノードは記述のみの観点から一致性が判定される。
図17は構造化文書処理方法380のフローチャートである。構造化文書処理方法340(図15)のステップと同一のステップは、構造化文書処理方法340のステップと同一のステップ番号で指示している。構造化文書処理方法380において、構造化文書処理方法340のステップに対して処理内容を具体化又は付加したステップについては、構造化文書処理方法340のステップのステップ番号に”b”を添えた番号で指示している。構造化文書処理方法340に対する構造化文書処理方法380の相違点について説明する。構造化文書処理方法380では、構造化文書処理方法340に対して、S384,S385,S388,S389が追加されているが、(a)S384,385のみの追加、又は(b)S388,S389のみの追加であってもよい。
所定の要素名における所定の属性値の相違は一致性の範囲とする構造化文書処理方法380において、S341b(状態遷移図情報記憶ステップ)では、状態遷移図上の所定の元ノードは、所定の属性を属性変数とする属性変数付き元ノードに設定されている。S343b(一致性判定ステップ)では、選定対における元ノードが属性変数付き元ノードであり、かつ選定対における元ノード及び新ノードの要素名及び属性名が同一であるとき、選定対における元ノード及び新ノードの一致性が有りとする。S385(属性変数値記憶ステップ)では、一致性有りの選定対に対し、該選定対の元ノードが属性変数付き元ノードであるとき(S384)、選定対の新ノードの属性値を属性変数値として記憶する。S349b(元構造化文書利用ステップ)では、新構造化文書の新ノードに係る構文解析結果として、該新構造化文書の被利用構造化文書のノードであって該新構造化文書の新ノードの被利用ノードに係る構文解析結果を使用する場合に、被利用ノードが属性変数付き元ノードであるとき、新構造化文書の新ノードの被利用ノードに係る構文解析結果における属性変数に、属性変数値を代入した構文解析結果を、新構造化文書の新ノードの被利用ノードに係る構文解析結果として使用する。
所定のテキスト・ノードのテキストの相違は一致性の範囲とする構造化文書処理方法380において、S341b(状態遷移図情報記憶ステップ)では、状態遷移図上の所定のテキスト・ノードとしての元ノードはテキスト・ノード変数に設定されている。S343b(一致性判定ステップ)では、選定対における元ノード及び新ノードがそれぞれテキスト・ノード変数及びテキスト・ノードであるとき、元ノード及び新ノードの一致性が有りとする。S389(テキスト・ノード変数値記憶ステップ)では、一致性有りの選定対に対し、該選定対の元ノードがテキスト・ノード変数であるとき(S388)、選定対の新ノードのテキストをテキスト・ノード変数値として記憶する。S349b(元構造化文書利用ステップ)では、新構造化文書の新ノードに係る構文解析結果として、該新構造化文書の被利用構造化文書のノードであって該新構造化文書の新ノードの被利用ノードに係る構文解析結果を使用する場合に、被利用ノードがテキスト・ノード変数であるとき、新構造化文書の新ノードの被利用ノードに係る構文解析結果を、新ノードのテキスト・ノード変数値とする。
実施例1では、元構造化文書と新構造化文書とは、構造に係る区分としての構造区分(例えばノード)同士で対比される場合において、元構造化文書の状態遷移図を利用することなく、記述内容としてのバイト列又は文字を直接、対比される。すなわち、新構造化文書の構造区分のバイト列又は文字は、元構造化文書の対応する構造区分のバイト列又は文字列と対比され、この対比に基づき新構造化文書の各構造区分の解析結果として、利用できる元構造化文書の構造区分の有無が調べられる。なお、実施例1において、構造化文書としてXMLが採用されている。
XML文書の構文解析は大きな計算時間を必要とする。大量のXML文書を処理するシステムではこの負荷を軽減することが求められている。 XML文書は、人間が書きやすく読みやすい形式であり、その性質から機械が読み書きする形式の構文としては冗長性が非常に高い。冗長性が高いことによって生じる具体的な負荷は次のようなものである。
(a)文字コードの復号化のステップにおいて、XMLの文法はUnicodeの文字セットを用いて記述されているため、それぞれの文字コード(ASCII、ISO-8859-1、UTF-8、Shift-JIS など)をUnicodeのどの文字に当たるかを復号化する必要がある。
(b)字句解析及び構文解析のステップでは、XML文書の文字列に対して、タグを認識し、それぞれの要素名や属性名、属性値、テキスト・ノードの文字列などがそこで用いて良い文字集合以外の文字を使っていないか、などXMLの生成規則に照らして構文が間違っていないかの検査が行われる。
(c)整形式の検査では開始タグと終了タグの名前が一致しているか、一つの要素に同じ名前の属性名が2つ以上存在しないか、などが確かめられる。
(d)名前空間の処理では名前空間の宣言を認識し、それぞれの要素、属性の接頭辞から名前空間のURIをバインドする、また、宣言されていない接頭辞が使われていないか検査する必要がある。
XMLでは同様のことは様々なバイト列、文字列で表すことができるが、実際に流通しているバイト列や文字列は似通っている。特にXMLのWebサービスなどの場合、その傾向は顕著である。XML文書はアプリケーション・プログラムによって生成されるが、アプリケーション・プログラムはXMLでエンコードされたメッセージを生成する処理はライブラリやアプリケーション・サーバなどのミドルウェアに任されていることが多い。したがって、同じライブラリによって生成された同様の内容のXML文書のバイト列や文字列は似通ってくる。XML文書の従来の構文解析では、このような類似性を利用してこなかったのに対し、本発明はこのような類似性を活用することに着眼している。
本発明によるXML構文解析器において、1回目のXML文書の処理では既存のXML構文解析器と同様の構文解析を行い、それに加えてバイト列(又は文字列)としてそのXML文書を所定の記憶装置に保存する。
図18はXML文書の構文解析結果を保存するデータ構造を示している。図18はUML(Unified Modeling Language)のクラス図に準拠した表記形式で記載されている。XML文書の構文解析結果は、該クラス図に基づくデータ構造としてのイベントに分解されて、所定の記憶装置に保存される。本発明では、XML文書を所定の構造区分により区分化するが、該区分化は例えば、図18のクラス図のツリー構造においてリーフの位置にあるクラスのイベントに基づき行なわれる。該クラス図において、定義されているイベントは、SAX(Simple API for XML)で定義されているイベントとは完全に一致させてもよいが、適宜変更することも可能である。元XML文書の構文解析結果を新XML文書の構文解析に効率的に利用するために、SAXで定義されているイベントとは別に新たに追加したり、SAXで定義されている複数個のイベントを1個に統合したりすることも可能である。
図19はイベントとXML文書の構文解析結果との対応関係を示すマッピング・オブジェクト図である。該オブジェクト図もUMLの表記形式に準拠している。
構文解析結果の記録では、解析結果であるすべてのイベントを記録し、それぞれのイベント位置、つまりXML文書の何バイト目(何文字目)から何バイト目(何文字目)の部分に当たるかを記録する。
差分抽出(差分抽出のアルゴリズムと差分保存のデータ構造)について説明する。XML文書についての2回目以降の処理では、まず保存されている構文解析済みのXML文書との比較処理を行う。この比較処理にはバイト単位(あるいは文字単位)の差分を計算する。ここでの差分計算では計算時間の効率的なものが求められる。この差分計算には既存のさまざまなアルゴリズムを用いることが可能であるが、本発明ではXML構文解析器に特化した効率的な差分生成を行う。
あらかじめある閾値を決めておき、差分計算の途中でもその時点での差分の大きさがその閾値を越えた場合に類似性が低いと判断し処理を打ち切る。本来厳密に差分を計算する場合、比較する文書の長さをNとすると最悪の場合Nの二乗オーダーの比較回数が必要である。しかし、比較する2つの文書がほとんど同じである場合、その比較回数は非常に少なくなる。例えばM(M<<N)の長さ以上の差分がない場合には、比較回数は最悪でもMの二乗のオーダーとなる。このように非常に類似性が高いもののみを対象にすることで効率化が可能である。本発明における差分計算は非常に類似性が高いもののみを取り出すことを目的としている。
図20は差分を取る際に、差分量が閾値を越えていないかどうかを判定するルーチンのフローチャートである。まず、S401において、現在位置(両XML文書の現在の対比位置)が両XML文書の末尾に到達したか否かを判定し、判定が正なら、該ルーチンを終了し、否であれば、S402へ進む。S402では、両XML文書において、現在位置に係る区分の内容が相互に一致するか否かを判定する。S402の判定が正であれば、S403へ進み、否であればS404へ進む。S403では、両XML文書において、現在位置を次の区分の先頭へ進める。S404では、両XML文書の差分を抽出する。S405では、差分の量を計算し、該計算した差分量が所定の閾値を越えていないかを判定する。差分量の計算は、例えば、更新前の差分量と、S404で計算した区分の差分に係る量との和を更新後の差分量とするものである。例えば、差分量の初期値を0とし、S402の判定が否となるごとに、差分量を1ずつインクリメントするように、差分量を計算することもできる。S405の判定が正であれば、該ルーチンを終了し、否であれば、S406へ進む。S406では、両XML文書において現在位置を差分抽出区分だけそれぞれ文書末尾の方へ進め、S401へ戻る。
実際に差分を抽出する際は、XMLの構造を認識しながら行う。具体的には、XML文書の内容が食い違ったところで、対応する解析済みのイベントを取り出し、そのイベントの開始点から新しい文書に対して部分的にパースを行う。このパース結果によってその後の処理が分かれる。
図21は元XML文書と新XML文書とのイベントが相違したときのパース処理ルーチンのフローチャートである。元XML文書c1と新XML文書c2との一致・不一致の判定における対比単位は、1バイト又は1文字とされ、c1において、不一致の対比単位が属するイベントev1を抽出する(S411)。次に、c2において、c1のev1の開始点に対応する位置から1イベント分、c2をパースする。この時に、パースが行なわれたc2のイベントをev2と呼ぶことにする。ev2のパースにより、c2が整形式であるか非整形式であるかも判明する。S415において、c2が整形式であると判定された場合には、S418へ進み、c2が非整形式であると判定された場合には、S416へ進む。S416では、アプリケーション・プログラムへイベントの通知に代えて、c2が非整形式である旨の通知を行って、該ルーチンを終了する。
S418以降は、ev1,ev2の内容によって、処理は以下のように場合分けされる。
(1)ev2がDT(Document Type:文書タイプ)であり、しかも、ev1がev2と同一のイベントではない場合(S418→S419):DTは文書全体に対して実体参照に影響を与えるので、この部分が変更されていた場合にはすべて通常のパースを行う(S419)。
(2)ev1がEndElementの場合(S422→S423):この場合、新文書が整形式であるならば、かならず(XML文書のツリー構造における)同一の深さでev1と同一のEndElementが出現するはずなので、深さが同一でev1とev2が一致するところまで新文書に対して部分パースを行い(S423)、生成されたイベント列を差分イベント列(具体的には、後述の図24のS471で説明するevidiff[j]の部分イベント列のこと)とする。
(3)イベントの種類が同一である場合(S425の判定が正):単にイベントというと、SAXで定義されているイベントに限定される虞があるので、ここで、イベントの種類を定義する。イベントの種類とは、図18のクラス図におけるリーフに相当するイベントのことである。前述したように、該リーフに相当するイベントは、SAXのイベントとは厳密に一致させる必要がなく、元XML文書の構文解析結果としてのイベントを十分に利用したり、出現頻度の少ないイベントをまとめることにより、処理時間を速めたりするために、SAXのイベントの他に、イベントを適宜追加したり、SAXの複数個のイベントを1個に統合したりしたイベントを含むものである。
(3−1)ev2がStartElementであり、ev1,ev2の名前空間宣言が相互に異なるとき(S425→S426→S427):
[具体例]
元XML文書:<a xmlns="ns1"> <b/> </a>
新XML文書:<a xmlns="ns2"> <b/> </a>
この場合には要素中にあるQNameがすべて異なる可能性があるので、要素内をすべてパースする(S427)。(部分木の解析)
(3−2) それ以外のとき(S425→S426→S428):ev1とev2とで、非局所的に影響が異なるものは何もないので、ev2をev1の差分として採用する(S428)。
(4)イベントの種類が異なる場合(S425の判定が否):
(4−1) ev2がStartElementであるとき(S431→S427):(3−1)と同様にev2に対応する要素をパースする(S427)。結果は差分として採用する。
[具体例]
元XML文書:<a> <b/> </a>
新XML文書:<a> <b> test </b> </a>
(4−2) それ以外のとき(S431→S428):ev2は非局所的に影響を与えないので、ev2を差分として採用する(S428)。
このようにして差分量を計算し、差分量がある決められた閾値よりも大きくなった場合には処理を切り替える。差分量に応じて、新XML文書に対する処理は次のように場合分けされる。
(a)差分が十分に小さい比較対象のXML文書が見つかった場合:生成された差分を元に、元のイベント列とマージし、アプリケーション・プログラムに通知する。この場合、生成済みイベントのほとんどが再利用されることが期待される。
(b)差分が十分に小さい比較対象のXML文書が見つからなかった場合:差分による構文解析はあきらめ、1回目のXML文書の解析と同じように、既存のXML構文解析器と同様の構文解析を行い、それに加えてバイト列(又は文字列)としてそのXML文書を保存し、構文解析結果を記録する。これによってこのXML文書も以降の構文解析の比較対象に加えられ、以後このXML文書に対し類似性の高い文書の構文解析も効率化することができる。
図22は差分量に基づくXML文書の処理に係るルーチンのフローチャートである。元XML文書及び新XML文書の対応構造区分同士について一致及び不一致が検査され、元XML文書に対する新XML文書の差分量が計算される(S435)。差分量が閾値を越えると、又は元XML文書と新XML文書との全部の対応構造区分同士の一致及び不一致の検査が終了すると、S436において、差分量が閾値を越えているか否かの判定が行なわれ、判定が否であれば、S437へ進み、また、判定が正であれば、S438へ進む。S437では、元XML文書の構文解析結果を利用した通知がアプリケーション・プログラムへ行われる。S438では、新XML文書について通常の構文解析、すなわち、構文解析を、その文書先頭から又は元構文解析の構文解析結果の利用を断念したイベントから、文書末尾まで、構文解析する処理を実施する。S439では、新XML文書について、S438の構文解析結果を記憶装置に保存する。こうして、新XML文書は、以降、元XML文書としての役割を果たす。図23は最終的な差分情報を表現したクラス図である。
図24は新XML文書についての構文解析結果生成(リプレイ)に係るフローチャートである。SAXとして動作する場合には、解析済みのXML文書のイベント列をSAXイベントに変換しながら、順に再通知し、差分があるイベントに関してはそのイベントを差分と合成し、アプリケーション・プログラムに通知する。図24において、表記はオブジェクト指向型の言語、例えばJava(登録商標)の規定に従っている。すなわち「.」はインスタンスのメソドを表す。「.length」は配列の長さを返す。配列は0から(*.length-1)まで定義される。S460では、配列events1[ ]には、元XML文書のイベント列を代入し、配列evdiff[ ]には 新XML文書の差分に係るイベント列を代入し、i及びjには初期値として0を代入する。S461において、新XML文書に関して全部のイベントの通知が終了したか否かを検査し、未終了であれば、S462以降へ進む。S462において、新XML文書の現在の差分(evdiff[j])が元XML文書の現在のイベント(events[i])に対応しているか、すなわち、現在のevdiff[j]が現在のevents[i]に代替されるべきものであるかを調べ、また、現在のevdiff[j]が配列evdiff[ ]内であるかを調べ、共に正であるならば、S470へ進み、いずれか一方が否であるならば、S463へ進む。
S462の判定が否であるならば、現在のevents1[i]をアプリケーション・プログラムへ通知して(S463,S464)、iをインクリメントして(S465)、S461へ戻る。
S462の判定が正であるならば、kに0を代入してする(S470)。各evdiff[j}には、その部分イベント配列event_j_sub[k]が対応付けられており、該event_j_sub[k]は、新XML文書においてevent[j]に対応して新規に構文解析して得たイベントに対応している。こうして、現在のevdiff[j}に対応する部分イベント列event_j_sub[k]の各々をアプリケーション・プログラムへ通知する(S471→S472→S473→S474→S471・・・)。通知対象の部分イベント列に対応する通知が終了すると、iをevdiff[j]に対応する、evetnts[]の長さ分だけインクリメントし(S479)、さらに、jをインクリメントし(S480)、S461へ戻る。
さらに、具体的に説明する。
[実施例1の構文解析処理例1]
1回目に以下のようなXML文書を元XML文書として構文解析したとする。
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:doGetCachedPage xmlns:ns1="urn:GoogleSearch"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<key xsi:type="xsd:string">00000000000000000000000000000000</key>
<url xsi:type="xsd:string">http://www.google.com/</url>
</ns1:doGetCachedPage>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
この時保存される解析結果は以下のようになる。
00: Start Document: (0, 0), -
01: Start Element: (0, 88), "SOAP-ENV:Envelope" ..
..(省略)..
12: Characters: (777, 22), "http://www.google.com/"
..(省略)..
20: End Document: (2109, 0), -
例えば、12行の(777, 22)とは、"http://www.google.com/"の先頭の"h"が元XML文書の最初の文字から777番目にあり、"http://www.google.com/"の合計文字数は22個であることを意味している。
次に以下のようなXML文書を新XML文書として構文解析する場合を考える、
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:doGetCachedPage xmlns:ns1="http://www.yahoo.com/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<key xsi:type="xsd:string">00000000000000000000000000000000</key>
<url xsi:type="xsd:string">http://www.yahoo.com/</url>
</ns1:doGetCachedPage>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
新XML文書では、元XML文書の「http://www.google.com/」が「http://www.yahoo.com/」に変わっているだけである。
差分抽出:
このとき、本発明の処理系は、解析済みの文書と比較していって、787文字目まで(http://www.yahoo.com/のうちhttp://www.まで)は一致していることを確認し、788文字目が異なっている(解析済みXML文書では「g」、新XML文書では「y」)ことを発見する。
保存されている処理結果から、777文字目からの22文字に含まれる788文字目は、テキスト・ノード(Characters)中にあることが分かる。新規文書の777文字目から、テキスト・ノードとして部分XML文書解析を行い、798文字目(「</url>」の先頭)まで進む。部分XML文書解析により得られたテキスト・ノード「http://www.yahoo.com」を、解析済み文書中のテキスト・ノード「http://www.google.com/」の代替であるとして記憶し、差分量変数を0から1にする。
差分量が閾値を越えていないため、バイト列比較を続ける。解析済み文書の799文字目(次のイベントの始まり)と、新規文書の798文字目から、一致していることを確認していく。両者の終わりまで一致していることを確認し、差分抽出処理を終える。
これによって得られた差分結果を以下に示す。
Offset 12 length 1 => length 1
< Characters "http://www.google.com/"
> Characters "http://www.yahoo.com/"
「Offset 12 length 1 => length 1」において、「Offset 12」は元XML文書における前述解析結果の12行目を意味し、新XML文書では、元XML文書の解析結果の12行目が変更されて、元XML文書における12行目の1個(「=>」の左のlength 1)のイベントが、新XML文書の1個(「 =>」の右のlength 1)のイベントと置き換えられていることを意味している。
結果生成:
SAXイベントとして、0番目から11番目までは、解析済みの文書のものを利用する。12番目のイベントは新規に部分処理したテキスト・ノード「http://www.yahoo.com/」を用いる。13番目から20番目は、解析済みの文書のものを利用する。
[実施例1の構文解析処理例2]
次の例として、以下の文章が既に解析済みであったとする。
<aaa>
<bbb xxx="xxx"/>
</aaa>
この時保存されている解析結果は以下のようになっている。
00: Start Document: (0, 0), -
01: Start Element: (0, 5), "aaa"
02: Characters: (5, 3), "\n "
03: Empty Element: (8, 16), "bbb", [Attribute Name "xxx", Value "xxx"]
04: Characters: (24, 1), "\n"
05: End Element: (25, 6), "aaa"
06: End Document: (31, 0), -
次に以下のような新XML文書の対応文章を構文解析する場合を考える。
<aaa>
<ccc yyy="zzz"> test </ccc>
</aaa>
この文書では、9文字目(半角スペースを1文字として計算。\nは改行を意味し、1文字として計算。)が「b」と「c」で異なっていることがまず発見される。保存されている解析結果から、9文字目は解析済み文書のEmptyElementイベント「<bbb xxx="xxx"/>」に当たることが分かる。新文書では9文字目を含むイベントを解析するとStartElementイベント「<ccc yyy="zzz">」であることが分かる。イベントの種類が異なり、新文書側のイベントがStartElementであることから部分木の解析を行う。このStartElementに対応するEndElementまで、つまり「<ccc yyy="zzz"> test </ccc>」の部分の解析を行う。その後、文字列の差分計算に戻る。このような計算により、この例では次のようなイベントの差分が得られる。
Offset 3 length 1 => length 3
< EmptyElement "bbb", [Attribute Name "xxx", Value "xxx"]
> StartElement "ccc", [Attribute Name "yyy", Value "zzz"]
> Characters " test "
> EndElement "ccc"
結果生成:
SAXイベントとして、0番目から2番目までは、解析済みの文書のものを利用する。3番目から5番目のイベントは新規に部分処理した3つのイベントを用いる。6番目から8番目は、解析済みの文書の4番目から6番目ものを利用する。
[実施例1の構文解析処理例3]
次の例として、以下の文章が既に解析済みであったとする。
<aaa>
<bbb xxx="xxx"/>
</aaa>
この時、以下の新XML文書の文章を差分解析することを考える。
<aaa>
<bbb xxx="xxx"> </ccc>
</aaa>
新XML文書では、22文字目が「/」と「>」で異なっていることがまず発見される。保存されている解析結果から、22文字目は解析済み文書のEmptyElementイベント「<bbb xxx="xxx"/>」に当たることが分かる。新文書では23文字目を含むイベントを解析するとStartElementイベント「<bbb xxx="xxx">」であることが分かる。イベントの種類が異なり、新文書側のイベントがStartElementであることから部分木の解析を行う。このStartElementに対応するEndElementまで、つまり「<bbb xxx="xxx"> </ccc>」の部分の解析を行う。ところが、このEndElementはエレメント名がStartElementと対応していないため、非整形式であることが分かり、解析結果はエラーとなる。
[Webサービスへの実施例1の適用例]
本発明が有効に機能する場面を挙げる。図25はWebサービスのシステム構成図である。インターネット500又はイントラネットには、複数個のサーバ(プロバイダ)501a〜501nと共に、複数個のクライアント(リクエスタ)502a〜502mが接続されている。Webサービスでは、各サーバ501a〜501nは、各クライアント502a〜502mからのリクエストのメッセージを受け付け、それに対してレスポンスのメッセージを返すようになっている。これらメッセージは、SOAPにより規定されるXML文書となっている。本発明の構造化文書処理装置は、例えば、これらサーバ501a〜501n及びクライアント502a〜502mに実装されて、メッセージの構文解析を行なう。Webサービスでは、構文解析するXML文書は、Webサービスの相手方(サーバが本人であれば、相手方はクライアントであり、クライアントが本人であれば、相手方はサーバとなる。)が作成したものであるが、本発明の構造化文書処理装置において構文解析するXML文書(新構造化文書)は、構造化文書処理装置が実装されているコンピュータ本人の所定のアプリケーション・プログラムが作成したり、コンピュータ自身のハード・ディスク装置に格納されているXML文書のこともあり得ることに注意されたい。Webサービスにおける本発明の適用の具体例を説明する。
(a)Webサービスのクライアントにおいて、サーバからのレスポンスのXML文書を構文解析する場合。この場合、クライアント側ではどのサーバのどのオペレーションに対してリクエストしたかはあらかじめ分かっているので、クライアントでどのXML文書と比較すればよいかは分かっていることになる。つまり、クライアントではオペレーションごとに最初の1つのXML文書を比較対象として保存し、以後そのオペレーションを呼ぶ場合は選択的にそのXML文書と比較すればよいことになる。このように処理することで比較対象が増加することはない。
(b)Webサービスでのサーバにおいて、クライアントからのリクエストのXML文書を構文解析する場合。サーバではあらかじめ1つのオペレーションに対しては1つのURLを割り当てる構成をとる。この場合、リクエストのURLによって比較対象のXML文書を切り替えることで比較対象の数を減らすことが可能である。また、リクエスト元のIPアドレス、リクエストのUser-Agentヘッダなどの情報を元にどのクライアントからのリクエストかを判断し、比較対象を減らすことも可能である。このように処理することで比較対象が増加することはない。
[実施例1の改良例]
本発明では構文解析を繰り返し行ううちに、比較対象のXML文書の数が増加し処理が非効率になる場合が考えられる。しかし、類似性の非常に高い文書が1つ見つかった時点で以降の比較は必要なく、また類似性の低いXML文書との比較では早い段階で類似性の閾値を越え、処理を打ち切ることができるため大きな負荷とはならない。
それでも途中までほぼ同じであり、それ以降大きく異なるようなXML文書との比較ではある程度の時間がかかり非効率になる。そのような場合のための工夫として、比較するXML文書の比較順を変更することや、比較対象のXML文書の数に上限を定めておくことなどが挙げられる。比較順の変更や比較対象XMLの削除には、それまでにその構文解析結果がどれくらい使われているかの統計情報を用いる手法や、LRU(Least Recently Used)、FIFO(First In First Out)などのキャッシュ・エントリの交換アルゴリズムを流用することもできる。
[実施例1の実験結果]
ある処理系で作られたXML文書を解析済みの場合、同じ処理系で作られたXML文書を解析する処理が高速化される。解析済みでない文書を解析する処理は遅くなる。同じ処理系で作られた類似の文書を頻繁に処理する場合には、全体として解析処理が高速化されることになる。
本発明は、WebSphere(米国IBM社の販売するサーバ名)のようなアプリケーション・サーバにおけるWebサービスの処理を高速化する上で非常に有効である。Webサービスの処理では、XML処理のオーバーヘッドが大きいことが問題となっているが、本発明はこの問題に対処するものである。
図26は従来技術と本発明とでの構文解析結果の処理時間を対比した実験グラフである。最も普遍的に使われている従来型のSAXパーサであるApache Xerces 2.6.2のSAXパーサ(Xerces2 SAX)と、本発明(Diff+EventReplay)により、様々なXML文書(579 bytes + 1 change、974 bytes + 8 changes、5024bytes + 16 changes)を処理した時間を計測した。処理時間は構文解析を同一処理を1000回繰返した総計時間である。changeとは、元XML文書と新XML文書とで相違するイベント数である。元XML文書の1個のイベントが新XML文書では複数個のイベントに置き換わる場合もあるが、実験では、元XML文書と新XML文書とで相違するイベントは1:1に対応しており、例えば、8 changesとは、8個のイベントにおいて、元XML文書と新XML文書とて相違していることを意味する。実験環境は、ノートパソコンThink Pad T30(クロック周波数1.8GHz、メモリ512MB。"Think Pad"はIBM社製ノートパソコンの登録商標。)上のSun JDK1.3である。各サイズのXML文書において、左から順番にT1〜T5とし、T1は新XML文書のバイト形式で読み取るのに要する時間、T2は新XML文書を文字形式で読み取る時間、T3は従来のSAXパーサ(Xerces2 SAX)での処理時間、T4は新XML文書における差分部分を構文解析するのに要した時間、T5はT4+リプレイ(イベント列の通知時間)である。本発明の処理時間は、T1+T5又は、T2+T5となるが、従来の処理時間T4に対して処理時間を短縮できた。
実施例2では、元構造化文書及び新構造化文書について、それらの構造区分(例えばノード)を単位として対比する場合には、状態遷移機械の状態遷移図が利用される。該実施例では、XML文書が構造化文書として採用されている。なお、状態遷移機械の状態遷移図における各状態を、被利用構造化文書の構造区分に対応付けて、適宜、「ノード」と呼ぶことにする。
図27は状態遷移機械の状態遷移図において状態として登録されるノードについて、図18と同様に、UMLのクラス図形式で示したものである。ツリー構造のリーフに相当するノードが状態遷移図に登録される。これらリーフに相当するノードは、SAXのイベントに対応付けられている。
例として、次のXML文書c21を考える。
c21:<p:e xmlns:p="urn:example">text<x a="ccc" p:b="ddd"/></p:e>
XML文書c21を、図27のUML図のリーフ・ノードに係るイベントにパースした場合には、次のような結果を得る。なお、各行において、左端の番号は、説明の便宜のための行番号である。
801:[StartTag: name="e" uri="urn:example"
802: {Attributes: }
803: {NSDecls: (prefix="p", uri="urn:example")}]
804:[Text: value="text"]
805: [EmptyElementTag: name="x" uri=""
806: {Attribute: (name="a", uri="", value="ccc")
807: (name="b", uri="urn:example", value="ddd"}]
808: [EndTag: name="e" uri="urn:example"]
行番号801〜803,804,805〜807,808が状態遷移図の各ノードに対応している。状態遷移機械を作成するときには、これらのイベントの列を状態(ノード)の列とみなし、それらを単に文書の順序で並べればよい。図28はXML文書c21に係る状態遷移図600である。XML文書c21は、状態601〜状態604をもつ。
図29は状態遷移機械の制御方法630のフローチャートである。最初に、状態遷移機械を始状態に設定する(S631)。S632では、状態遷移機械において、次に遷移可能な状態(以下、「Cn」と呼ぶ。)が存在するか否かを判定する。S632の判定が正である場合には、S635へ進み、否である場合にはS645へ進む。S635では、状態遷移機械における状態Cnを構成するバイト列Boと、Boに対応する新構造化文書の対応バイト列Bnであって新構造化文書の現在位置としてのバイトから始まるバイト列Bnとをバイト単位で対比する。具体的には、Bnにおいて現在位置としてのバイトと、該バイトと対比するBoのバイトとを、バイト列Bn,Boの先頭から末尾の方へ1個ずつ進める。S636では、バイト列Bo,Bnが完全に一致したか否かを判定し、該判定の結果が正であれば、S637へ進み、否であれば、S646へ進む。S637では、状態遷移機械の状態をCnへ遷移させる。すなわち、状態遷移機械の現在状態をCnにする。S638では、状態遷移機械において現在状態が終状態か否かを判定し、該判定の結果が正であれば、制御方法630を終了し、否であれば、S632へ戻る。
S645では、新構造化文書の現在位置としてのバイトを先頭バイトとするバイト列Bnであって新構造化文書の現在位置が存在するノードに係るバイト列Bnについて、パースを行う(1個のノードに係るバイト列のパースのことを適宜、「部分パース」と呼ぶことにする。)。該部分パースでは、新構造化文書の現在位置に係るコンテキスト(コンテキストの例:現在有効な実体宣言・名前空間宣言・要素の階層から構成される。)を使用する。S646では、S645の部分パースに基づき、辞書を使って、該部分パース結果にコンテキスト及び記述の一致するノードとしての遷移先ノードが状態遷移機械の状態遷移図上にあるかを調べる。S647では、S646の調査により遷移先ノードか見つかったか否かを判定し、該判定の結果が正であれば、S648へ進み、否であれば、S649へ進む。S648では、状態遷移機械の現在のノードを遷移先ノードへ変更する。また、必要であれば、状態遷移図上に遷移先ノードへの遷移経路を作成する(例:図30の状態608から状態603へ引いた経路)。S648の後は、S632へ戻る。S649では、部分パース結果に基づき状態遷移図上にノードを追加する(例:図30の状態608)。また、該追加ノードに対して遷移元になっているノードから該追加ノードへ遷移経路を作成する(例:図30の状態601から状態608へ引いた経路)。S649の後、S645へ戻る。
例として、図28の状態遷移図を備える状態遷移機械を次の新XML文書c22に対して適用した場合を考える。図30及び図31は、状態遷移機械の作動に伴う状態遷移図の更新状態を示している。
c22:<p:e xmlns:p="urn:example"><y/><x a="ccc" p:b="ddd"/></p:e>
まず、状態遷移は、現在解析している場所から、次に遷移可能な状態が持っているバイト列に対してマッチした場合にのみ行えるものとする。初期状態(図30の上端の二重丸)の次の状態601は「<p:e xmlns:p="urn:example">」というバイト列を持っているので、文書の先頭から見て同じバイト列に文書がマッチした場合にのみ、状態遷移が行える。XML文書c22でもバイト列は一致しているので、解析中のXML文書c22の位置は以下の▽で示した場所に移り、状態遷移機械は状態601に遷移する。
<p:e xmlns:p="urn:example">▽<y/><x a="ccc" p:b="ddd"/></p:e>
次の状態は「text」というバイト列を持っているので、"t"と、"<"の比較が行われるが、これはマッチしないので、状態を遷移することができない。状態遷移ができなかった場合には、現在の状態が持っているコンテキスト(現在有効な実体宣言・名前空間宣言・要素の階層から構成される)から部分パースを行う(各状態はその状態に対応するイベントおよびコンテキストが保持されているものとする)。パースした結果、下記のイベントを得る。
[EmptyElementTag: name="y" uri="" {Attribute: }]
そして、そのイベントに対して合流できる状態がないかどうかを探し出す。現状態と合流できる状態とはコンテキストが一致していなくてはならない。なぜなら、この条件を破ってしまうと、状態遷移機械の遷移履歴からXML全体が整形式であることを保証することができず、毎回遷移履歴に対して整形式をチェックする必要があるからである。このためには、ハッシュによる辞書を利用する。イベント及びコンテキストに対しては適切なハッシュ関数を定義しておき、ハッシュ値が計算されているとする。いま、状態遷移機械に対する辞書として、「(コンテキスト × イベント) → 状態」というような対応が用意されているとする。いま、イベントとしては、「<y/>」を用い、コンテキストとしては、「要素"e"の下であり、名前空間としては接頭辞"p"にたいして"urn:example"が定義されており、実体宣言は空」というものを用いて、この辞書を用いて対応する状態を探す。当然、「<y/>」をイベントとして持つ状態は存在しないので、合流することはできないまま、部分パースが続けられることになる。この時、状態遷移機械を更新しながらパースする場合は(もちろん、解析時にできパース速度を上げるために、状態遷移機械をこの時点では更新しないということもできる)、図30のように状態遷移機械を更新する。
そして、引き続き部分パースがおこなわれる。次は下記のイベントを得る。
[EmptyElementTag: name="x" uri=""
{Attribute: (name="a", uri="", value="ccc")
(name="b", uri="urn:example", value="ddd"}]
さきほどと同じように辞書から対応する状態を見つけ出す。今回は、対応する状態を見つけ出すことができ、次の状態は、図30の状態603となる。
もし、状態遷移機械を更新する場合には、図31のように、状態状態608,603をそれぞれ遷移元及び遷移先とする遷経路を新規に作成する。なお、この合流できる状態が複数見つかった場合には、適当に一つを選び出す方法でもかまわないが、分岐したところから最も近い状態に合流すると効率がよいので、距離を計算して最も近い場所を選び出すという方法を取るとよい。
この走査の結果、次に遷移する可能性のある状態Cnとして、「</p:e>」があることになり、新XML文書の現在位置に係るノードに対して、この状態Cnが持つバイト列とのマッチ判定が行われる。新XML文書c22もこれとマッチするので、遷移が行われ、最後に終状態(図31の下端の二重丸)に到達し、この時点で新XML文書c22も終了するので、解析が完了する。元XML文書c21としての解析済み文書とどのように対応するかは、遷移履歴から分かる。新しく作られたのではない状態に対応するところが、解析済み文書と対応するところであり、新しく作られるか、もしくは対応する状態がない部分が、差分情報ということになる。
状態遷移機械に対応する辞書で無駄な項目を追加しない手法について説明する。
本発明では、状態遷移機械の更新時、新しい状態に対応する項目を辞書に追加するのだが、あまり特徴のないイベント、頻繁に出現する割には文書の構造に影響を与えないイベント、様々なコンテキストに出現するイベントに対しては新たに辞書登録を行わないようにすることもできる。これにより、無駄な合流の操作や無駄な分岐先の増加によって効率が低下することを避けられる。
状態遷移機械を更新する際には、その新しい状態に対応する項目を辞書に追加しておく。このことにより、合流先を高速に見つけ出すことができる。しかし、この手法は、XML文書において同一のイベントがあったときはその後の文書構造も類似している可能性が高いという性質を利用しているため、例えば、改行のみのテキストイベントなどを、この辞書に登録しておくと、無駄に合流の操作を行ったり、無駄に分岐先を増やしてしまったりすることにつながり、効率が悪くなってしまう。これを避けるためには、あまり特徴のないイベント、頻繁に出現する割には、様々なコンテキストに出現するイベントに対しては新たに辞書登録を行わない、もしくは辞書から削除するなどの手法を取るとよい。具体的には、以下のようなイベントを辞書に登録しない、もしくは削除するなどの手法が考えられる。
(a)短いTextイベント(例えば4文字より短いもの)
(b)既に状態遷移機械中に多数の重複状態として出現するイベント
(c)規則性に乏しいPIイベントやCommentイベント
分岐点で高速に分岐先を探索する手法について説明する。
本発明では、状態遷移機械中の状態遷移の分岐について、あらかじめ、分岐できる状態のバイト列に関してはソートをしておき、解析しようとする文書のバイト列を利用して、バイナリサーチを行うこともできる。これにより、いくつも分岐がある場合にも、対数時間で効率に遷移することができる。
いま、図31の状態を備える状態遷移機械が既に用意されていたとする。この状態遷移機械を用いて、記述が下記のものとなっている文書c23を解析するものとする。
c23:<p:e xmlns:p="urn:example"><y/>xyz</p:e>
既に述べたような方法で、最初の状態にはすぐに遷移される。したがって、状態遷移機械は状態状態601に行き着く。ここで遷移可能な状態は「text」および「<y/>」であるが、バイト列単位のマッチングをこの2個のイベント双方で単純に行う場合、分岐が2個の場合はよいが、いくつも分岐がある場合には0(N)の時間を要することになってしまい、効率的でない。この場合、あらかじめ、分岐できる状態のバイト列に関してはソートをしておき、解析しようとする文書のバイト列を利用してバイナリサーチを行う。つまり、まず、"<"が来た時点で"t"よりも"<"のほうが小さいのでバイナリサーチにおいて、すぐに「<y/>」だけに候補を絞ることができる。
次に、最類似する解析済み文書を見つける手法について説明する。
実施例2では、状態遷移機械に対して、文書を解析したときに作った状態や遷移したことを記録しておくことにより、新規文書と最も類似する解析済み文書を得るようにする。新規文書がどの状態を遷移したかを、記録されている状態や遷移と比較することにより、最も多く対応する状態や遷移の記録されている文書が、最も類似する解析済み文書であることが分かる。
例えば、以下の3個のXML文書A,B,Cがあったとする。図32はそれらA〜Cを解析して生成した状態遷移図である。
文書A: <a>x<b>y</b></a>
文書B: <a>x<c>z</c></a>
文書C: <d>z</d>
そして、新しく次の文書Dを解析するものとする。
文書D: <a><b>y</b><c>x</c></a>
図33は前述した手法(状態遷移図への状態の追加、合流)を用いて、XML文書Dの状態の遷移を示したものである。図33において、太い線は解析した結果の遷移履歴を表している。この中で、文書Aに該当する状態は5個、文書Bに該当する状態は4個、文書Cに該当する状態はまったくないので、文書Dに最も類似する文書は文書Aであると結論付けられる。
[実施例2の利用例:その1]
この機構は既存文書の類似構造と、その差分を高速に抽出することができるので、差分処理に適している。例えば、類似したクエリを多量に処理するべきウェブ・サービスに適用すると、パースする部分を最小限に抑えられるため、速度は飛躍的に向上する。しかも、キャッシュしておく解析済み文書を増やしても分岐探索には高々O(logN)しかかからないため、最悪でも速度はO(logN)しかかからない。実際には同一の状態は新たに作られないので、効率はもっとよいことが期待される。
例えば、差分パーサとしてこの技術を適用した場合には、具体的には以下のような構成をとることになる。
(a)キャッシュするXML文書をもとにして、図33で説明した機構をもとづいて状態遷移機械を作成する。
(b)新規に解析するXML文書に対して、図33で説明した方法で差分を抽出し、差分部分だけを部分パースする。
(c)解析結果は、状態遷移機械の各状態の遷移履歴に基づいて全体をパーサ利用側に返却する。
一般的に、この手法が有効であることは言えないが、ある局面で非常に有効であるということに関しては、定性的に大きな根拠がある。ここでは、ウェブ・サービスについてその根拠を説明する。
処理対象のXML文書のバイト列表現がバリエーションに富む場合には、オートマトン中の既存パスに対応する場合が少なくなってマッチする頻度が下がり、またオートマトンの状態数が爆発して大量の記憶域を消費することになる。Webサービスの場合に問題となるのは、異なるスキーマ間、および異なるシリアライザ実装間での、バイト列表現のバリエーションであると考えてよい。Webサービスでは、XML文書(SOAPメッセージ)生成側は通常WSDLで指示されたスキーマに基づいてデータバインディングが行われ、パラメータからXML文書が生成されるからである。
しかしながら、現実的なWebサービスにおいては、このバリエーション爆発は問題とならない。本処理系を用いるようなWebサービス・ミドルウェアが取り扱うスキーマは少数であることが普通である。これは、一つのWebサービス・プロバイダが提供するサービスは、ルーター的なものを除けば、固定であり、数も多くないからである。また、シリアライザ実装数は、少なくはないが、爆発するほどではない。ある一時期に用いられる実装系は、いくつかのベンダーの、最新に近い版のものに集中するからである。
実際上、処理対象は、いくつかの文法(3型文法のバリエーション)クラスに収まり、クラスごとに大量の(バイト列表現の似た)XML文書があることになる。類似文書の処理は実施例1などを用いて高速に処理できるため、全体として高速な処理が可能になる。
[実施例2の利用例:その2)
例えば、多量のXML文書を、この形式の状態遷移機械に登録しておいて、類似文書を検索するために用いることができる。これによって、下記の処理(a)及び(b)に用いることができる。これは特にスキーマが固定されていて、大量の3型文法の枠内で収まる類似文書を処理しなくてはならないときに有効な手段である。
(a)文書編集時に類似文書との変更点などを提示する。これによって、テンプレート的に類似文書を活用することできたり、既存文書から見た履歴を抽出して提示することができたりするようになる。
(b)文書クラスを推測し、その文書クラスに沿った適切な処理にわたす。例えば、レポート用の文書と判別すれば、そのレポート用のマークアップ定義を見て、処理を行うなどの補助ができるようになる。
[実施例2の利用例:その3]
この手法の状態遷移機械だけでは、類似度の高い実際の文書インスタンスを復元することはできない。このためには、「最類似する解析済み文書を見つける手法」で説明したように、文書インスタンスIDを状態に記憶させておいて、適切なデータベースなどでその文書インスタンスIDから文書インスタンスを取り出すことができるようにしておけばよい。
もしくは、このようなデータベースをそのまま持たせては効率的ではないという用途の場合には、文書インスタンスIDから、状態遷移機械の遷移パスに対応する辞書を作るという方法でもよい。なお、遷移パスは、各状態へのリファレンスの列で定義することができるため、一文書につき高々n個のリファレンスですみ、記憶効率もよい。
[実施例2の利点:整形式検証の効率化]
本発明の処理系では、以下の処理を同時に高速にこなしている点に大きな意義がある。
(a)新規文書との類似文書の特定
(b)新規文書との差分抽出
(c)新規文書の整形式検証
(c)の整形式検証を(a)及び(b)と同時に行わないとすると、別途、整形式検証を行う必要がでてくるが、その処理は重い。
例えば、974bytesのSOAPメッセージ(doGoogleSearch)について、本発明を利用して、同時に整形式検証を行った場合と、別途整形式検証を行った場合の処理時間を比較すると、別途整形式検証を行った場合には、全体で1.7倍の処理時間を要している。本発明では、コンテキストが一致するように状態遷移を制限することによって、マッチした新規文書は、常に整形式であることを保証している。そのため、既処理文書とマッチすることがわかった時点で、その新規文書に対して別途製形式検証を行う必要はなく、そのコストはかからずに済む。
[実施例2の利点:複数文書の解析に対する意義]
図34は実施例2を実際にウェブ・サービスのクエリに対して用いて、差分解析を行った場合の実験例を示す。キャッシュ済みの文書数が増えても、処理時間にはほとんど変化がないことが分かる。なお、図34において、縦軸の単位としての「us」とはマイクロ・セカンドを意味している。処理済の文書を1つ1つ比較していく従来技術では、文書数が増えると処理時間は線形的に増加してしまうが、実施例2に係る状態遷移機械を適用すれば、文書数が増えてもほとんど処理時間は増加しない。
図35は、処理対象の(互いに類似でない)文書の種類(サービスの違い、実装系の違い)が増えていった場合に、既存の従来技術を適用したパーサでは、実施例2に係る状態遷移機械を適用したパーサに比べて、処理速度が低下していく様子を示している。既存技術については、論理値である。文書の種類間で、バイト列レベルの違いが甚だしい場合、2文書を比較して類似でないことを早く検出できる。グラフでは、その平均コストが全体のマッチングの何パーセントになるかによって、既存技術の場合の処理速度を4つ(1%、5%、10%、20%)示した。
[実施例2の利点: 記憶領域]
Amazon Webサービスのリクエスト・メッセージ15種類に対し、メッセージを生成するSOAP処理系を4種類仮定し、15×4=60種類のXML文書を生成した。図36はこの60種類のXML文書を記憶した場合のメモリ使用量を示している。
状態遷移機械を利用する実施例2の場合にも、記憶する文書数が増えるに従い必要とする記憶領域は増加する。しかし、記憶領域の増加量は記憶する文書の数にほぼ比例しており、記憶量が爆発するようなことはない。システムのメモリ量を勘案して記憶文書数の最大値を設定することで、メモリ不足による性能低下は避けることが可能である。また、メモリに制限があるときには、最も利用頻度の高い遷移のみを残し、参照の消えた状態を削除することによってメモリ量を抑えることができる。
[実施例2の利点:記憶していない文書に対する処理時間]
図37は前述の60文書に対して、あらかじめ記憶している文書数を0文書から60文書まで変化させて処理時間を計測した。そのグラフを以下に示す。計測には60文書すべてが用いられ、全体で10000文書の処理を行っている。計測時には状態遷移機械の更新は行われず。あらかじめ生成済みの状態遷移機械が常に使われている。なお、グラフにはないが、差分パーサを用いない場合の解析時間は1300ms程度であり、12文書以上、つまり全体の5分の1程度の類似文書を記憶している場合に差分パーサの方が高速に処理を行えることが分かる。0文書つまり一つも記憶していない場合に非常に値が悪いが、これは部分パーサの実装が不完全で、余計な処理が入っているためではある。しかし、グラフから分かるとおり、少しでも再利用できる部分があれば差分パーサの効果が現れていることが読み取れる。さらに、実際の使用状況では動的に類似度の高い文書に対して状態遷移機械が更新されるため、文書の類似率は比較的高い値になることが予想される。
図38はSOAPメッセージ処理装置700の構成図である。SOAPエンジン701は、SOAPメッセージを受信すると、WSSコンシューマ702(Web services security Consumer)を呼び出し、セキュリティの処理はその中で実行される。その後、SOAPエンジン701は、メッセージ中のアプリケーション・データを処理するために、デシリアライザ709を呼び出してから、アプリケーション・オブジェクト710を呼び出す。実施例3は、WSSコンシューマ702での処理を効率化するものであり、以下ではその中味を説明する。
図38にもあるように、WSSコンシューマ702では、受信したメッセージの内容により、トークン・コンシューマ703、 署名コンシューマ704及び 暗号コンシューマ705を呼び出しながら処理を進める。例えば、メッセージがセキュリティ・トークンと署名のみを含んでいる場合、暗号コンシューマ705は呼び出されない。
図39はWSSコンシューマ702の処理部分のフローチャートである。実施例3では、後述するように一旦処理したメッセージからテンプレートを抽出して、これを再利用する。抽出されたテンプレートは利便性の点から、状態遷移マシン(Automaton)にまとめられており、これにより、受信したメッセージにマッチするテンプレートを効率的に選択することができる。マッチするテンプレートがない場合には、通常の方法で処理されるが、この際にテンプレートを抽出して状態マシンに追加する。マッチするテンプレートが有る場合には、トークン、署名、暗号化などの構成要素に応じて、それぞれの処理を呼び出し、テンプレートを利用しながら効率的に処理を進めていく。
図40はテンプレートの概念的に示した図である。この図は、X.509証明書をセキュリティ・トークンとして、それを利用した署名を含んだメッセージから抽出されるテンプレートになっている。受信したメッセージの中で、属性やテキスト・ノードを変化する部分(変数)として捉えることにより、テンプレートは生成される。但し、名前空間宣言と、変換(Transform)アルゴリズムは変数ではなく、固定値として扱っている。
図40のようなテンプレートが複数ある場合、受信したメッセージと個別にマッチングするのは効率が悪い。そこで、実施例3では、これらのテンプレートは図41のような状態遷移機械としてまとめられている。この例では、名前空間接頭子が違う2つのテンプレートがまとめられている(wsseとsecが違う)。
実施例3において、状態遷移機械のノードは以下の4種類がある。
(a)開始タグ・ノード:開始タグに対応している。名前空間宣言、属性などを含んでいる。属性の通常変数として表現されており、受信したメッセージとのマッチングにより、値が代入される。
(b)終了タグ・ノード:終了タグに対応している。開始タグとは違い属性などはないので、変数も定義されていない。
(c)空タグ・ノード:空タグに対応している。開始タグと同様に、属性などに関する変数を含んでいる。
(d)コンテント・ノード:テキスト・ノードに対応している。受信したメッセージとのマッチングにより、テキストが抽出される。マッチングの際に、この部分にXMLの部分木が対応することが分かった場合には、状態遷移機械の更新を行う。
図42は状態遷移機械を利用して、受信したメッセージを処理する方法に係る説明図である。受信した(incoming)メッセージを前から順に、各状態とマッチングして、状態をたどっていく様子が示されている。マッチングを進める際には、開始タグ・ノードやテキスト・ノードで定義されている変数への代入も行われる。図43及び図44は受信メッセージからそれぞれ属性値及びテキストを抽出する説明図である。
受信したメッセージを状態遷移機械とマッチングして成功した場合、マッチングの結果は状態ノードの列として表現される。このようなノードの列をテンプレート・インスタンスと呼び、ノードの列に加えて、代入された値も表現するようにしている。図45はテンプレート・インスタンスの一例を示している。
図46はテンプレート・インスタンスの処理に係る説明図である。図38及び図39に示したように、WSSコンシューマ702は、受信したメッセージの内容に応じて、トークン、暗号、署名を処理するモジュール適宜呼び出すようになっている。図46に示すように、何を呼び出すかはテンプレート・インスタンスに基づいて決められており、ここでは、単純に出現した順に対応したモジュールを呼び出す様子が示されている。
図46において、セキュリティの構成要素に応じて、処理モジュールが呼び出されるようになっているが、署名検証と復号化モジュールに関しては、これまで述べてきた方法だけでは十分には対処できない。署名検証では、署名対象を正規化 (Canonicalize) する処理が必要である。例えば、以下のようなメッセージを考えてみる。なお、左端の数字850〜855は、説明の便宜上、付加した行番号である。
850:<S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope" xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"….>
851: <S:Header> …. </S:Header>
852: <S:Body wsu:Id="myBody">
853: <tru:StockSymbol xmlns:tru="http://www.fabrikam123.com/payloads">QQQ</tru:StockSymbol>
854: </S:Body>
855:</S:Envelope>
ボディ要素が署名対象であるとすると、この部分を正規化する必要があり、名前空間宣言の追加、属性の並べ替えなどの処理が必要である。その結果、上記のメッセージは以下のようになる。
860:<S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope" xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"….>
861: <S:Header> …. </S:Header>
862: <S:Body xmlns:S="http://www.w3.org/2001/12/soap-envelope"
863: xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"
864: wsu:Id="myBody">
865: <tru:StockSymbol xmlns:tru="http://www.fabrikam123.com/payloads">QQQ</tru:StockSymbol>
866: </S:Body>
867:</S:Envelope>
変換前の852行が変換後では、862〜864行となっており、862行及び863行において、名前空間の定義が追加されていることに注意されたい。このような処理をするには、図41 のような状態遷移機械だけでは不十分であり、署名対象の解析処理が必要になってしまう。そこで、実施例3では、署名対象処理に関しては、図47に示すように正規化されたテンプレート745を用意して対処する。この中では、署名対象に関しては、もともとのメッセージから抽出したテンプレート744に加え、それを正規化したものから作られたテンプレート745も用意しておく(S751)。メッセージを受信すると、元のテンプレートとのマッチングにより、変数部分を抽出する(S752)。そして、抽出した変数部分を正規化されたテンプレート745に埋め込み(S753)、最後にダイジェスト値を計算する(S754)。このような手順により、XMLの解析は一切せずに、署名検証に必要なダイジェスト値の計算が可能になる。
図48は正規化されたテンプレートと状態遷移機械の関連付けに係る説明図である。署名対象の始まりの部分(<S:Body wsu:Id="$id")において正規化されたテンプレート(C14Nのテンプレート)を状態遷移機械の対応ノードへリンクし、各状態(ノード)においては変数の対応関係も表現するようにしている。
復号化に関しても、XMLの解析を避ける方が望ましい。XML暗号化では、復号化したものは、UTF−8のバイト列であり、改めてXMLの解析をする必要がある。このような解析を避けるために、実施例3では、復号化した部分に関してのテンプレートも用意し、バイト列のマッチングにより通常のXML解析を回避する。図49は復号化処理におけるテンプレート使用の説明図である。暗号データ(EncryptedData)に対応するバイト列に対応して、復号化データのためのテンプレートが用意されており、受信したメッセージの復号化された部分はこのテンプレートとマッチングが行われる。
XMLの解析は重い処理であり、さらに WS−Securityでは、それに加えて、正規化の処理や復号化後のXMLの解析も必要である。本発明により、これらのXMLの解析処理を省くことができ、性能向上に大きく貢献できる。
構造化文書処理装置の機能ブロック図である。
別の構造化文書処理装置の機能ブロック図である。
構造化文書処理方法のフローチャートである。
別の構造化文書処理方法のフローチャートである。
構造化文書処理装置等や構造化文書処理方法等のプログラムが実装されるコンピュータの概略構成図である。
他の構造化文書処理装置の機能ブロック図である。
別の構造化文書処理装置の機能ブロック図である。
他の構造化文書処理方法のフローチャートである。
別の構造化文書処理方法のフローチャートである。
図9に係る別の構造化文書用構文解析方法に種々の機能を追加した場合のフローチャートの第1の部分図である。
図9に係る別の構造化文書用構文解析方法に種々の機能を追加した場合のフローチャートの第2の部分図である。
図9に係る別の構造化文書用構文解析方法に種々の機能を追加した場合のフローチャートの第3の部分図である。トの部分図である。
さらに別の構造化文書処理装置の機能ブロック図である。
さらに他の構造化文書処理装置の機能ブロック図である。
さらに別の構造化文書処理方法のフローチャートである。
さらに他の構造化文書処理方法の主要部のフローチャートである。
別の構造化文書処理方法のフローチャートである。
XML文書の構文解析結果を保存するデータ構造を示す図である。
イベントとXML文書の構文解析結果との対応関係を示すマッピング・オブジェクト図である。
差分を取る際に、差分量が閾値を越えていないかどうかを判定するルーチンのフローチャートである。
元XML文書と新XML文書とのイベントが相違したときのパース処理ルーチンのフローチャートである。
差分量に基づくXML文書の処理に係るルーチンのフローチャートである。
最終的な差分情報を表現したクラス図である。
新XML文書についての構文解析結果生成(リプレイ)に係るフローチャートである。
Webサービスのシステム構成図である。
従来技術と本発明とでの構文解析結果の処理時間を対比した実験グラフである。
状態遷移機械の状態遷移図において状態として登録されるノードについてUMLのクラス図形式で示したものである。
XML文書c21に係る状態遷移図である。
状態遷移機械の制御方法のフローチャートである。
状態遷移図上にノードを追加する説明図である。
状態遷移機械の作動に伴う状態遷移図の更新状態を示す図である。
複数個のXML文書に係る状態遷移図である。
状態遷移図への状態の追加、合流の手法によるXML文書Dの状態の遷移を示したものである。
実施例2を実際にウェブ・サービスのクエリに対して用いて差分解析を行った場合の実験例を示す図である。
実施例2に係る状態遷移機械を適用したパーサに比べて、処理速度が低下していく様子を示す図である。
この60種類のXML文書を記憶した場合のメモリ使用量を示す図である。
前述の60文書に対して、あらかじめ記憶している文書数を0文書から60文書まで変化させて処理時間を計測した
SOAPメッセージ処理装置の構成図である。
WSSコンシューマの処理部分のフローチャートである。
テンプレートの概念的に示した図である。
複数個のテンプレートをまとめた状態遷移図である。
状態遷移機械を利用して、受信したメッセージを処理する方法に係る説明図である。
受信メッセージから属性値及びテキストを抽出する説明図である。
受信メッセージからテキストを抽出する説明図である。
テンプレート・インスタンスの一例を示す図である。
テンプレート・インスタンスの処理に係る説明図である。
正規化されたテンプレートを利用してダイジェスト値を計算する説明図である。
正規化されたテンプレートと状態遷移機械の関連付けに係る説明図である。
復号化処理におけるテンプレート使用の説明図である。
符号の説明
100:構造化文書処理装置、101:状態遷移図情報記憶手段、102:選定対認定手段、103:一致性判定手段、104:ノード認定手段、105:遷移履歴情報生成手段、106:類似度検出手段、109:元構造化文書、110:新構造化文書、120:構造化文書処理装置、121:構文解析結果記憶手段、122:利用認定手段、123:元構造化文書利用手段、130:構造化文書処理方法、140:構造化文書処理方法、210:構造化文書用構文解析装置、212:記憶手段、213:判別手段、214:解析手段、215:通知手段、20:構造化文書用構文解析装置、21:記憶手段、22:一致判定手段、23:分類手段、24:解析手段、25:通知手段、31:最類似構造化文書選択手段、32:サーバ等検出手段、33:URL検出手段、34:差分量計算手段、300:構造化文書処理装置、301:状態遷移図情報記憶手段、302:選定対認定手段、303:一致性判定手段、304:ノード認定手段、305:遷移履歴情報生成手段、306:被利用構造化文書選択手段、307:元構造化文書利用手段、320:構造化文書処理装置、321:元ノード追加手段、322:状態遷移経路追加手段、326:属性変数値記憶手段、327:テキスト・ノード変数値記憶手段、340:構造化文書処理方法、360:構造化文書処理方法、380:構造化文書処理方法。