JP3832830B2 - ＸＰａｔｈ評価方法、これを用いたＸＰａｔｈ評価装置及び情報処理装置 - Google Patents
ＸＰａｔｈ評価方法、これを用いたＸＰａｔｈ評価装置及び情報処理装置 Download PDFInfo
- Publication number
- JP3832830B2 JP3832830B2 JP2003122292A JP2003122292A JP3832830B2 JP 3832830 B2 JP3832830 B2 JP 3832830B2 JP 2003122292 A JP2003122292 A JP 2003122292A JP 2003122292 A JP2003122292 A JP 2003122292A JP 3832830 B2 JP3832830 B2 JP 3832830B2
- Authority
- JP
- Japan
- Prior art keywords
- xml
- xpath
- document
- evaluation
- stack
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
- G06F16/986—Document structures and storage, e.g. HTML extensions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/12—Use of codes for handling textual entities
- G06F40/14—Tree-structured documents
- G06F40/143—Markup, e.g. Standard Generalized Markup Language [SGML] or Document Type Definition [DTD]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/20—Natural language analysis
- G06F40/205—Parsing
- G06F40/221—Parsing markup language streams
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99942—Manipulating data structure, e.g. compression, compaction, compilation
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99943—Generating database or data structure, e.g. via user interface
Description
【０００１】
【発明の属する技術分野】
本発明は、ＸＭＬ（Extensible Markup Language）文書の解析技術に関し、特にＸＰａｔｈ（XML Path Language）の評価を行う解析システム及びその解析方法に関する。
【０００２】
【従来の技術】
今日、インターネットに代表されるコンピュータネットワークのパケット交換に用いられる文書記述言語として、文書の論理構造や構成要素の意味を自由に定義できるＸＭＬが広く普及している。ＸＭＬ文書をアプリケーションで利用する際に、処理対象であるＸＭＬ文書を解析することが必要となるが、このときＸＰａｔｈが利用される。ＸＰａｔｈは、ＸＭＬ文書の特定の部分を指し示す構文を規定する言語であり、Ｗ３Ｃ（World Wide Web Consortium）勧告の仕様である。ＸＰａｔｈを利用することにより、所定のＸＭＬ文書が特定の論理構造や構成要素を持つかどうかを解析することができる（例えば、非特許文献１参照）。
【０００３】
また、ＸＭＬ文書の構造は、木構造で表現することができ、Ｗ３Ｃ勧告の仕様であるＤＯＭ（Document Object Model）等を用いて表現される。ＸＰａｔｈを用いてＸＭＬ文書を解析する場合、通常、ＤＯＭ等で表現されたＸＭＬ文書全体を対象として走査し、ＸＰａｔｈにて記述された構造を当該ＸＭＬ文書が持つかどうかを調べる。したがって、ＸＭＬ文書の解析システムは、解析対象であるＸＭＬ文書全体を所定のメモリに読み込んで処理を行う必要があった。
【０００４】
【非特許文献１】
“XML Path Language (XPath) Version 1.0”、[online]、１９９９年１１月１６日、[２００３年３月４日検索]、インターネット＜http://www.w3.org/TR/xpath＞
【０００５】
【発明が解決しようとする課題】
上記のように、ＸＰａｔｈを用いてＸＭＬ文書の解析を行う場合、従来は、解析対象であるＸＭＬ文書全体を、一旦メモリの作業領域に読み込む必要があった。しかし、解析対象であるＸＭＬ文書のデータサイズが巨大である場合、これをＤＯＭ等の記述として読み込むのは、多大なメモリ使用量を要し、またＤＯＭを作成、操作する処理に多大な時間を要するという問題があった。
【０００６】
また、ＳＡＸ（The Simple API for XML）やＸＮＩのようなストリーミングベースのＡＰＩ（Application Program Interface）を用いる場合、ＡＰＩはストリーミング形式で取得されるＸＭＬ文書を順次処理できるにも関わらず、ＸＰａｔｈによる解析を行うために、一旦ＸＭＬ文書全体を読み込んでからでなければ処理を開始できないのは効率が悪い。
【０００７】
そこで本発明は、上記の問題に鑑み、ＸＭＬ文書をストリーミング処理しながらＸＰａｔｈの評価を行う解析システム及びその解析方法を実現することを目的とする。
【０００８】
【課題を解決するための手段】
上記の目的を達成する本発明は、コンピュータを用いてＸＭＬ文書に対するＸＰａｔｈの評価を行う、次のようなＸＰａｔｈ評価方法として実現される。このＸＰａｔｈ評価方法は、処理対象のＸＭＬ文書を構成するＸＭＬイベント列を順次入力する第１のステップと、入力された個々のＸＭＬイベントに対してＸＰａｔｈを順次評価すると共に、所定のＸＭＬイベントに対してこのＸＰａｔｈが部分的に成立した場合に、このＸＰａｔｈの部分的な評価の結果に関する情報を所定の記憶手段に保持する第２のステップと、ＸＭＬイベント列の入力に伴って、記憶手段に保持されている部分的な評価の結果を考慮してＸＰａｔｈの部分的な評価を繰り返し、ＸＰａｔｈの最後の部分が成立した場合に、処理対象であるＸＭＬ文書に対して、このＸＰａｔｈが成立したと評価する第３のステップとを含むことを特徴とする。
このように、入力したＸＭＬイベントに対して個別にＸＰａｔｈの評価を行っていき、その部分的な評価結果を蓄積しながら、ＸＰａｔｈ全体が成立するかどうかを判断することにより、ストリーミング処理によるＸＰａｔｈの評価が可能となる。
【０００９】
この第２のステップで行われるＸＰａｔｈの評価及び部分的な評価の結果を保持する具体的な手法として、本発明では、オートマトンを用いた手法、スタックを用いた手法、ＸＭＬイベント列の入力に伴って順次生成される文書木を用いた手法を提示する。
オートマトンを用いた手法では、評価対象であるＸＰａｔｈを表現するオートマトンを生成し、個々のＸＭＬイベントに基づいて、このオートマトンの状態を遷移させることにより、ＸＰａｔｈの評価を行う。この部分的な評価の結果は、オートマトンの状態として保持される。
【００１０】
スタックを用いた手法では、評価対象であるＸＰａｔｈをスタック要素の列で表現した第１のスタックを生成し、個々のＸＭＬイベントに基づいて処理対象のＸＭＬ文書の入れ子構造を解析する第２のスタックを生成する。そして、第１のスタックと第２のスタックとを比較することにより、ＸＰａｔｈの評価を行う。この部分的な評価の結果は、第２のスタックのスタック要素として保持される。
【００１１】
ＸＭＬイベント列の入力に伴って順次生成される文書木を用いた手法では、入力された個々のＸＭＬイベントの入力に基づいて処理対象のＸＭＬ文書の文書構造を示す文書木を順次生成していき、この文書木の生成に伴い、生成された部分までの文書木を用いてＸＰａｔｈの評価を行う。この場合、ＸＭＬイベント列の入力に伴って文書木が作成されていくので、文書木において新たなノードが追加されるたびにＸＰａｔｈを評価していき、ＸＰａｔｈが成立するかどうかを調べれば良い。しかし、ＸＰａｔｈが成立するノードが複数存在する場合もあるので、部分的な評価の結果の情報を保持しておき、後続のＸＭＬイベントに対する評価の際に用いることができる。
【００１２】
また、上記の目的を達成する他の本発明は、次のように構成されたＸＰａｔｈ評価装置としても実現される。このＸＰａｔｈ評価装置は、ストリーミング処理によるＸＰａｔｈの評価を実行する評価実行部と、処理対象のＸＭＬ文書を構成するＸＭＬイベント列を入力し、評価実行部に順次転送するＸＭＬイベント転送部とを備える。この評価実行部は、ＸＭＬイベント転送部から転送された個々のＸＭＬイベントに対してＸＰａｔｈを順次評価すると共に、所定のＸＭＬイベントに対して、このＸＰａｔｈが部分的に成立した場合に、このＸＰａｔｈの部分的な評価の結果に関する情報を保持していく。そして、このＸＰａｔｈの最後のステップが成立した場合に、ＸＭＬ文書に対して、このＸＰａｔｈが成立したと評価することを特徴とする。
【００１３】
このＸＰａｔｈ評価装置は、上述したＸＰａｔｈの評価及び部分的な評価の結果を保持する具体的な手法として、オートマトンを用いた手法を実現するため、ＸＰａｔｈを表現するオートマトンを生成するオートマトン生成部をさらに備える構成とすることができる。同様に、スタックを用いた手法を実現するため、ＸＰａｔｈをスタック要素の列で表現した第１のスタックを生成するスタック生成部をさらに備える構成とすることができる。
【００１４】
また、本発明の他のＸＰａｔｈ評価装置は、ＸＭＬ文書を構成するＸＭＬイベント列を入力し、個々のＸＭＬイベントの入力に伴い、入力されたＸＭＬイベントに基づいてＸＭＬ文書の文書構造を示す文書木を順次生成する文書木生成部と、処理対象のＸＭＬ文書を構成するＸＭＬイベント列を入力し、この文書木生成部に順次転送するＸＭＬイベント転送部と、この文書木生成部による文書木の生成に伴い、生成された部分までの文書木を用いてＸＰａｔｈの評価を行う評価実行部とを備えることを特徴とする。
【００１５】
さらに本発明は、ＸＭＬパーサと、上述したＸＰａｔｈ評価装置の機能を備えたＸＰａｔｈ評価部と、ＸＭＬパーサで生成されたＸＭＬイベントを入力し、ＸＰａｔｈ評価部によるＸＰａｔｈの評価結果に応じて、入力したＸＭＬイベントにて構成されるＸＭＬ文書に対する処理を実行するアプリケーション実行部とを備える情報処理装置として実現することもできる。
【００１６】
また本発明は、コンピュータを制御して上述したＸＰａｔｈ方法の各ステップに対応する処理を実行させるプログラム、またはコンピュータを上記ＸＰａｔｈ評価装置あるいは情報処理装置として機能させるプログラムとしても実現される。このプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録媒体に格納して配布したり、ネットワークを介して配信したりすることにより、提供することができる。
【００１７】
【発明の実施の形態】
以下、添付図面に示す実施の形態に基づいて、この発明を詳細に説明する。
本発明は、ストリーミング形式で入力される処理対象のＸＭＬ文書に対して、当該ＸＭＬ文書の入力に応じて順次ＸＰａｔｈの評価を行う。このストリーミング処理によるＸＰａｔｈの評価を実現する実施の形態として、以下ではオートマトンを用いた実施の形態（実施の形態１）、スタックを用いた実施の形態（実施の形態２）、ツリーを用いた実施の形態（実施の形態３）を説明する。なお、これらの実施の形態は、パーソナルコンピュータやワークステーション、その他のコンピュータ装置、ＰＤＡ（Personal Digital Assistant）、携帯電話等の種々の情報処理装置にて実現される。
【００１８】
〔実施の形態１〕
実施の形態１では、オートマトンを用いることにより、ＸＰａｔｈの評価のストリーミング処理を実現する。
図１は、本実施の形態を実現するのに好適な情報処理装置のハードウェア構成の例を模式的に示した図である。
図１に示す情報処理装置は、演算手段であるＣＰＵ（Central Processing Unit：中央処理装置）１０１と、Ｍ／Ｂ（マザーボード）チップセット１０２及びＣＰＵバスを介してＣＰＵ１０１に接続されたメインメモリ１０３と、同じくＭ／Ｂチップセット１０２及びＡＧＰ（Accelerated Graphics Port）を介してＣＰＵ１０１に接続されたビデオカード１０４と、ＰＣＩ（Peripheral Component Interconnect）バスを介してＭ／Ｂチップセット１０２に接続されたハードディスク１０５、ネットワークインターフェイス１０６及びＵＳＢポート１０７と、さらにこのＰＣＩバスからブリッジ回路１０８及びＩＳＡ（Industry Standard Architecture）バスなどの低速なバスを介してＭ／Ｂチップセット１０２に接続されたフロッピーディスクドライブ１０９及びキーボード／マウス１１０とを備える。
なお、図１は本実施の形態を実現するコンピュータのハードウェア構成を例示するに過ぎず、本実施の形態を適用可能であれば、他の種々の構成を取ることができる。例えば、ビデオカード１０４を設ける代わりに、ビデオメモリのみを搭載し、ＣＰＵ１０１にてイメージデータを処理する構成としても良いし、ＡＴＡ（AT Attachment）などのインターフェイスを介してＣＤ−ＲＯＭ（Compact Disc Read Only Memory）やＤＶＤ−ＲＯＭ（Digital Versatile Disc Read Only Memory）のドライブを設けても良い。
【００１９】
図２は、本実施の形態におけるＸＰａｔｈ評価手段（解析システム）の実装例を示す図である。
図２に示すように、本実施の形態による情報処理装置は、処理対象であるＸＭＬ文書の構文解析（パース）を行うＸＭＬパーサ１０と、構文解析されたＸＭＬ文書に対してＸＰａｔｈの評価を行うＸＰａｔｈ評価部２０と、ＸＰａｔｈの評価を経たＸＭＬ文書を用いて所定の情報処理を実行するアプリケーション実行部３０とを備える。
図２に示すＸＭＬパーサ１０、ＸＰａｔｈ評価部２０及びアプリケーション実行部３０は、例えば、図１に示したメインメモリ１０３に展開されたプログラムにてＣＰＵ１０１を制御することにより実現される仮想的なソフトウェアブロックである。
【００２０】
図２において、ＸＭＬパーサ１０は、処理対象のＸＭＬ文書を入力して構文解析を行い、解析結果を通知するＸＭＬイベントを出力してＸＰａｔｈ評価部２０に送る。ＸＭＬイベントは、解析対象のＸＭＬ文書の木構造（ドキュメントツリー）におけるノードごとに順次、ＸＰａｔｈ評価部２０へ送られる。ＸＭＬパーサ１０としては、ＸＭＬ文書を扱う情報処理装置で従来から用いられている既存のＸＭＬパーサを用いることができる。なお、本実施の形態において、入力対象となるＸＭＬ文書は整形式であることを前提とする。
【００２１】
ＸＰａｔｈ評価部２０は、ＸＭＬパーサ１０からＸＭＬイベントを受け取り、予め与えられたＸＰａｔｈの評価を行う。
図３は、ＸＰａｔｈ評価部２０の機能構成を説明する図である。
図３に示すように、本実施の形態のＸＰａｔｈ評価部２０は、オートマトン生成部２１と、ＸＭＬイベント転送部２２と、評価実行部２３とを備える。
【００２２】
オートマトン生成部２１は、予め与えられたＸＰａｔｈからオートマトン（状態遷移機械）を生成する。本実施の形態では、ＳＡＸやＸＮＩ等のストリーミング形式で実行されるＡＰＩを用いたアプリケーションに対してＸＰａｔｈを評価する。したがって、ストリーミング処理を行うという制約上、評価対象となるＸＰａｔｈの機能は一部制限される。例えば、評価において既に通知されたＸＭＬイベントを参照することが必要となる基準点（axis）や述語（predicate）は実現されない。しかし、実際の多くのアプリケーションにおける処理では、かかる制限が問題となることはない。
【００２３】
ここで、本実施の形態におけるＸＰａｔｈの制限を具体的に提示する。
１．ＸＰａｔｈは、ロケーションパスとする。ただし、絶対ロケーションパスは、対象であるＸＭＬ文書の木構造のルートノードからＸＰａｔｈを評価するときに限る。
２．基準点は、フォワード基準点のみとする。すなわち、次のいずれかとする。
ｓｅｌｆ
ｃｈｉｌｄ
ｄｅｓｃｅｎｄａｎｔ
ｄｅｓｃｅｎｄａｎｔ−ｏｒ−ｓｅｌｆ
ｆｏｌｌｏｗｉｎｇ
ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ
ａｔｔｒｉｂｕｔｅ
ｎａｍｅｓｐａｃｅ
ただし、ある条件と特別な実装の上でリバース基準点も使用することができる。これについては後述する。
３．述語については次のように扱う。
（１）演算子は、次のいずれかとする。
ｏｒ
ａｎｄ
＝
！＝
（２）プリミティブは、次のいずれかとする。
・ロケーションパス。ただし、その基準点は次のいずれかとする。
ａｔｔｒｉｂｕｔｅ
ｎａｍｅｓｐａｃｅ
ｓｅｌｆ
ｐａｒｅｎｔ
ａｎｃｅｓｔｏｒ
ａｎｃｅｓｔｏｒ−ｏｒ−ｓｅｌｆ
・リテラル
・数
・関数呼び出し。ただし、次のものを除く。
ｌａｓｔ（）
ｉｄ（ｏｂｊｅｃｔ）
ルートノード及び要素ノードに対するｓｔｒｉｎｇ（ｏｂｊｅｃｔ？）
【００２４】
さて、ＸＰａｔｈにおいて、省略記法を用いないロケーションパスは、基準点とノードテストと述語の連接（ステップと呼ばれる）を記号／で区切って並べたもので表される。オートマトン生成部２１は、各ステップの評価状態をオートマトンで表現する。このオートマトンは、次のような状態遷移を行う。
図４は、オートマトン生成部２１にて生成されるオートマトンを模式的に示す図である。
まず、各ステップ（個数をＮとする）を左（先頭）から順番に番号付けし、所定のトークンが読み込まれた時点でステップＫが成立している状態をステートＫとする。ここで、ステップＫが成立している状態とは、ステップＫを満たすノードの開始タグトークンが読み込まれ、その終了タグがまだ読み込まれていない状態を表すものとする。また、初期状態はステート０で表すとする。
今、ステップＫを満たすノードの開始タグトークンが読み込まれ、現在の状態がステートＫになったとする。このステートＫの状態でステップＫ＋１を満たすノードが読み込まれた場合は、ステートＫ＋１に状態が移る。一方、ステートＫの状態でステップＫの終了タグが読み込まれた場合は、ステートＫ−１に状態が移る。このような状態遷移を繰り返し、ステートＮに到達すると、ロケーションパスが満たされたと判断される。
オートマトン生成部２１によって生成された上記のようなオートマトンは、例えば図１のメインメモリ１０３の作業領域に保持され、後述する評価実行部２３の処理において使用される。
【００２５】
ＸＭＬイベント転送部２２は、ＸＭＬパーサ１０から出力されたＸＭＬイベントを入力し、ＸＭＬ文書の木構造におけるノードごとに評価実行部２３へ順次転送する。また、当該ＸＭＬイベントをアプリケーション実行部３０へも順次転送する。
【００２６】
評価実行部２３は、オートマトン生成部２１にて生成されたオートマトンを取得し、ＸＭＬイベント転送部２２から転送されたＸＭＬイベントを受け取って、ＸＭＬ文書のトークン列を順次読み込みながらオートマトンにおける状態間の遷移を行う。そして、ロケーションパスを満たすノードに対応するトークンが読み込まれた時点でそのロケーションパスが満たされたと評価する。この評価結果は、評価イベントとしてアプリケーション実行部３０に送られる。評価実行部２３による具体的な評価処理の手順については後述する。
【００２７】
図２に示したアプリケーション実行部３０は、ＸＰａｔｈ評価部２０のＸＭＬイベント転送部２２から転送されるＸＭＬイベントと評価実行部２３から出力される評価イベントとを入力し、ストリーミング処理にてＸＭＬ文書に対する処理を実行する。
【００２８】
次に、本実施の形態のＸＰａｔｈ評価部２０による処理について、さらに詳細に説明する。
上述したように、本実施の形態では、まず評価対象であるＸＰａｔｈを表現するオートマトンを生成し保持しておく。そして、処理対象のＸＭＬ文書を構成するＸＭＬイベント列を順次入力し、このＸＭＬイベントに基づいて、オートマトンの状態を遷移させることにより、ＸＰａｔｈの部分的な評価を行う。ＸＰａｔｈの部分的な評価の結果は、オートマトンの状態として保持される。
ここでは簡単のために、ロケーションパスは、述語が無いものとし、基準点ではｃｈｉｌｄとｄｅｓｃｅｎｄａｎｔのみを考える。ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ、ｆｏｌｌｏｗｉｎｇ、ｓｅｌｆ、ｄｅｓｃｅｎｄａｎｔ−ｏｒ−ｓｅｌｆ、ａｔｔｒｉｂｕｔｅ、ｎａｍｅｓｐａｃｅを基準点とするステップや述語が存在するステップの取り扱いについては後述する。
【００２９】
図５は、本実施の形態による処理に用いられるロケーションパス、オートマトン及び処理対象のＸＭＬ文書の例を示す図である。
図５（Ａ）に示すロケーションパスが与えられ、このロケーションパスの各ステップを左からステップ１、ステップ２、ステップ３と呼ぶことにする。オートマトン生成部２１により、このロケーションパスから生成されるオートマトンの状態は、図５（Ｂ）に示すようになる。
今、図５（Ｃ）に示すＸＭＬ文書が入力されたとする。このＸＭＬ文書は、ＸＭＬパーサ１０にて構文解析され、ノードごとのＸＭＬイベントとしてＸＰａｔｈ評価部２０に送られ、ＸＭＬイベント転送部２２にて評価実行部２３に順次転送される。なお、図５（Ｃ）において、＜ｔｉｔｌｅ＞＜／ｔｉｔｌｅ＞のように要素内容がない場合は＜ｔｉｔｌｅ／＞と省略表記がなされている（以下、他のＸＭＬ文書についても同様）。
【００３０】
評価実行部２３は、オートマトン生成部２１にて生成された上記のオートマトンを用い、ＸＭＬイベント転送部２２から転送されたＸＭＬイベントに基づいて当該オートマトンの状態遷移を行って、当該オートマトンに対応するロケーションパスの評価を行う。なお、実際の処理において、オートマトンの状態の遷移及び評価は、ＸＭＬ文書の入れ子構造を解析するスタック（ＸＭＬイベント列用のスタック）を、例えば図１のメインメモリ１０３のメモリ空間に構築して行う。すなわち、評価実行部２３は、ＸＭＬパーサ１０から送られるＸＭＬイベント列を、このＸＭＬイベント列用スタックに順次保持していく。
このＸＭＬイベント列用スタックは、開始タグが読み込まれたことを条件に、そのタグに対応するノードをプッシュし、終了タグが読み込まれたことを条件に、当該ノードをポップする。また、スタックのボトム（bottom）はルートノードを表すものとする。
【００３１】
したがって、評価実行部２３は、ＸＭＬイベント列の入力に応じて、ＸＭＬイベント列用スタックへのプッシュとポップを順次行っていく。この操作は、ロケーションパスが相対であるか絶対であるかに関わらず、ＸＭＬ文書の開始から終了まで一貫して行われる。この操作中、所定の開始タグが読み込まれ、そのタグに対応するノードがＸＭＬイベント列用スタックにプッシュされた場合はいつでも、当該ノードが（現在の状態をステートＫとして）ステートＫ＋１に対応するステップ（すなわちステップＫ＋１）を満たしているかどうかを判定する。この判定結果が真であった場合、現在の状態をステートＫ＋１とする。このとき、スタック要素とステートの対応付けをしておく。つまり、プッシュされたノードとそのノードによって成立したステートとのマッピングを構成する。ここで、ステート０に対しては、ロケーションパスが相対パスである場合にはコンテクストノードに対応したスタック要素が対応付けられる。またロケーションパスが絶対パスである場合はスタックのボトム（すなわちルートノード）が対応付けられるものとする。一方、ＸＭＬイベント列用スタックからのポップが行われた場合、ポップされたエレメントがステートに対応付けされているかどうかを検出し、対応付けされていたならば、状態を１つ前に戻す。
【００３２】
以下、図５を参照し、順を追って説明する。
まず、初期状態はステート０であり、トークン＜ｄｏｃｕｍｅｎｔ＞が読み込まれ、ノードｄｏｃｕｍｅｎｔがプッシュされる。このときのＸＭＬイベント列用スタックの状態は、
ｂｏｔｔｏｍ ｜ ｄｏｃｕｍｅｎｔ
となる。このノードｄｏｃｕｍｅｎｔは、ステップ１を満たすので、ステート０からステート１へ状態遷移が行われる。
【００３３】
次に、トークン＜ｔｉｔｌｅ＞が読み込まれ、ノードｔｉｔｌｅがプッシュされる。このときのＸＭＬイベント列用スタックの状態は、
ｂｏｔｔｏｍ ｜ ｄｏｃｕｍｅｎｔ ｜ ｔｉｔｌｅ
となる。このノードｔｉｔｌｅは、ステート１に対応付けられたノードｄｏｃｕｍｅｎｔのｃｈｉｌｄ：：ｃｈａｐｔｅｒという条件を満たさない。すなわち、ステップ２を満たさないので、状態遷移は行われず、そのままトークンの読み込みが続けられる。
【００３４】
ノードｔｉｔｌｅの終了タグであるトークン＜／ｔｉｔｌｅ＞が読み込まれてノードｔｉｔｌｅがポップされた後、続いてトークン＜ｃｈａｐｔｅｒ＞が読み込まれ、ノードｃｈａｐｔｅｒがプッシュされる。このノードはステップ２を満たすので、ステート１からステート２へ状態遷移が行われる。このときのＸＭＬイベント列用スタックは、
ｂｏｔｔｏｍ ｜ ｄｏｃｕｍｅｎｔ ｜ ｃｈａｐｔｅｒ
となる。次に、トークン＜／ｃｈａｐｔｅｒ＞が読み込まれ、ノードｃｈａｐｔｅｒのポップが行われる。このとき、ポップされるスタック要素には、ステート２が対応付けられている。したがってこの場合は、ポップと共に、オートマトンの状態が、ステート２からその１つ前の状態であるステート１へ遷移される。
【００３５】
この後、再びトークン＜ｃｈａｐｔｅｒ＞が読み込まれ、ノードｃｈａｐｔｅｒがプッシュされて、ステート１からステート２へ状態遷移が行われる。そしてさらに、トークン＜ｓｅｃｔｉｏｎ＞が読み込まれ、ノードｓｅｃｔｉｏｎがプッシュされると、このノードはステップ３を満たすので、ステート２からステート３へ状態遷移が行われる。この時点で評価実行部２３は、ロケーションパスが成立したと判断し、評価結果を示す評価イベントをアプリケーション実行部３０へ送信する。
なお、以上の説明では、評価実行部２３はロケーションパスが成立した場合に評価イベントを出力することとしたが、ＸＭＬイベントを１つ処理する度に成立または不成立を示す評価イベントを出力するようにしても良い。
【００３６】
次に、他のフォワード基準点（axis）の取り扱いについて説明する。
１．ａｔｔｒｉｂｕｔｅ、ｎａｍｅｓｐａｃｅの取り扱い。
基準点がａｔｔｒｉｂｕｔｅであるステップが含まれるロケーションパスを評価するには、状態遷移した際に、遷移後の状態の１つ先の状態に対応するステップを検出する。そして、そのステップがａｔｔｒｉｂｕｔｅであれば、最後に入力されたトークンの属性を用いて、当該ステップの評価を行う。この評価でノードがステップを満足した場合は、状態を１つ進める。一方、ノードがステップを満足しなかった場合は、元々の状態遷移をキャンセルする。
ｎａｍｅｓｐａｃｅに関しては、現在のコンテクストにおけるｎａｍｅｓｐａｃｅを管理しておき、ステップの評価をａｔｔｒｉｂｕｔｅの場合と同様に実行する。
なお、ａｔｔｒｉｂｕｔｅ及びｎａｍｅｓｐａｃｅに関しては、これらが成立する過程では、ＸＭＬイベント列用スタックの操作は行われない。したがって、それらの状態と対応付けられるノードは何もないことを表すＮＵＬＬノードとしておく。
【００３７】
２．ｓｅｌｆの取り扱い。
基準点がｓｅｌｆであるステップが含まれるロケーションパスを評価するには、状態遷移した際に、遷移後の状態の１つ先の状態に対応するステップを検出する。そして、そのステップがｓｅｌｆであれば、当該ステップの評価を行う。この評価でノードがステップを満足した場合は、状態を１つ進め、その先の状態に対して同じ操作を繰り返す。一方、ノードがステップを満足しなかった場合は、元々の状態遷移をキャンセルする。ｓｅｌｆが成立する過程では、ＸＭＬイベント列用スタックの操作は行われない。したがって、それらの状態と対応付けられるノードは何もないことを表すＮＵＬＬノードとしておく。
【００３８】
３．ｄｅｓｃｅｎｄａｎｔ−ｏｒ−ｓｅｌｆの取り扱い。
基準点がｄｅｓｃｅｎｄａｎｔ−ｏｒ−ｓｅｌｆであるステップが含まれるロケーションパスを評価するには、まず、そのステップの基準点がｓｅｌｆであるとみなして、上記２．の操作を行う。この操作においてステップを満足しないと判断された場合、その基準点がｄｅｓｃｅｎｄａｎｔであるとみなして評価を続行する。
【００３９】
４．ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇの取り扱い。
基準点がｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇであるステップが含まれるロケーションパスを評価するには、以下の操作を行う。
まず、ある基準点がｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇであるステップをステップＫとし、それに対応した状態をステートＫとする。基本的には、ステップＫ−１の成立時にプッシュされたノードがポップされたときのスタックトップノードに対し、そのノードに続いてプッシュされるノードがステップＫで選択するべきノードとなる。ただし、ここで注意しなければならないのは、このステップＫを満足したノードは、ステップＫで選択されるノードの候補であると同時にステップＫ−１で選択されるノードの候補でもあるということである。例えば、ロケーションパスが、
/child::document/child::chapter/following-sibling::chapter
であった場合、以下の２番目のｃｈａｐｔｅｒは、２番目のステップと、３番目のステップの両方で選択される可能性がある。
＜ｄｏｃｕｍｅｎｔ＞
＜ｃｈａｐｔｅｒ＞−−１
＜／ｃｈａｐｔｅｒ＞
＜ｃｈａｐｔｅｒ＞−−２
＜／ｃｈａｐｔｅｒ＞
＜ｃｈａｐｔｅｒ＞−−３
＜／ｃｈａｐｔｅｒ＞
＜／ｄｏｃｕｍｅｎｔ＞
このような両義性は、ｐｏｓｉｔｉｏｎに依存したノード選択を行うときは厳密な解釈が必要である。例えば、以下のロケーションパス
/child::document/child::chapter/following-sibling::chapter[1]
では、２番目と３番目のｃｈａｐｔｅｒを共に選択しなければならない。また、以下のロケーションパス
/child::document/child::chapter[2]/following-sibling::chapter
では、３番目のｃｈａｐｔｅｒを選択しなければならない。
【００４０】
そこで、本実施の形態では、ノードがステップＫ−１を満足すると判断された時点でプロセスを２つに分割し、それぞれのプロセスが２通りのロケーションパスの解釈に対応した状態遷移を続行するように処理を行う。１つのプロセスは、この時点で当該ノードと対応付けられた状態の１つ前の状態に遷移し（通常はステートＫ−２、ｓｅｌｆが含まれる場合はさらにその前の状態）、以降の評価を続行する。
もう１つのプロセスでは、次の操作を行う。まず、状態はステートＫ−１のままとする。ステートＫ−１の状態において、ノードがステップＫ−１を満足すると判断されてプッシュされたノードがポップされたときのスタックトップノードがスタックトップである間に何らかのノードがプッシュされた場合は、当該ノードがステップＫステップＫを満足するかどうかを判定する。満足するならば、状態をステートＫに遷移し、プッシュされたノードとステートＫとを対応付けて、これ以降の評価を続行する。また、ステートＫに対応付けられたノードがポップされたときは、状態をステートＫ−１に戻す。ステートＫ−１の状態において、ステップＫ−１を満足したノードの終了タグトークンが入力された場合、すなわちノードがステップＫ−１を満足すると判断されてプッシュされたノードがポップされたときのスタックトップノードがポップされた場合は、このプロセスにおいてステップＫで選択されるノードがこれ以上存在しないので操作を終了する。
【００４１】
５．ｆｏｌｌｏｗｉｎｇの取り扱い。
基準点がｆｏｌｌｏｗｉｎｇであるステップが含まれるロケーションパスを評価するには、以下の操作を行う。
この場合もロケーションパスに曖昧さが生じる可能性があるため、ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇの場合と同じ様なプロセスの分割が必要となる。まず、ある基準点がｆｏｌｌｏｗｉｎｇであるステップをステップＫとし、それに対応した状態をステートＫとする。上記４．の処理と同様に、ノードがステップＫ−１を満足すると判断された時点でプロセスを２つに分割する。１つのプロセスは、この時点で当該ノードと対応付けられた状態の１つ前の状態に遷移し、以降の評価を続行する。
もう１つのプロセスでは、次の操作を行う。まず、状態はステートＫ−１のままとする。ステートＫ−１の状態において、何らかのノードがプッシュされた場合は、ステップＫを満足するかどうかを判定する。満足するならば、状態をステートＫに遷移し、プッシュされたノードとステートＫとを対応付けて、これ以降の評価を続行する。ｆｏｌｌｏｗｉｎｇの場合は、ステートＫ−１の状態において、ステップＫ−１を満足したノードの終了タグトークンが入力されても、状態をステートＫのままにする。
【００４２】
次に、述語（predicate）の取り扱いについて説明する。
述語は、基本的には、状態遷移の瞬間にスタックに蓄積された情報から構成できるものについて取り扱うことができる。つまり、ステップＫを満たす開始タグトークンが読み込まれた場合、その状態で構成できる当該ノードについての情報、及びスタックに残っている当該ノードのａｎｃｅｓｔｏｒについての情報を述語に記述することができる。また、各ステートについてカウンタを設けることで、ポジション関数を取り扱うことが可能となる。これまで説明してきたようなステップの成立状態において、そのステップに対応したステートのカウンタを１つ増やす。このカウンタの値に基づいてポジション関数を含む述語を評価し、最終的にノードがステップを満足するか否かを判定する。
【００４３】
次に、リバース基準点の取り扱いについて説明する。
本実施の形態では、非常に限定されたロケーションパスにおいて、ｐａｒｅｎｔ、ａｎｃｅｓｔｏｒ、ａｎｃｅｓｔｏｒ−ｏｒ−ｓｅｌｆといったリバース基準点を使用することができる。上記述語の取り扱いで述べたように、現在のノードのａｎｃｅｓｔｏｒについての情報はオートマトンの状態として蓄積されている。したがって、ロケーションパスのある地点から右側のステップが全て、ｐａｒｅｎｔ、ａｎｃｅｓｔｏｒ、ａｎｃｅｓｔｏｒ−ｏｒ−ｓｅｌｆ、あるいはｓｅｌｆである場合は、その地点でスタックの操作を一旦停止し、スタックを遡りながら、それらのステップを評価していけば良い。
【００４４】
図６は、本実施の形態によるＸＭＬ文書のストリーミング処理を説明するフローチャートである。
図６に示すように、ＸＰａｔｈ評価部２０は、初期動作として、オートマトン生成部２１により、予め与えられたＸＰａｔｈのロケーションパスからオートマトンを生成しておく（Ｓｔｅｐ６０１）。処理対象であるＸＭＬ文書が入力され、ＸＭＬパーサ１０からＸＭＬイベントが送られると（Ｓｔｅｐ６０２）、ＸＰａｔｈ評価部２０の評価実行部２３により、上記のようにして、当該ＸＭＬイベントに対する先のオートマトンにおける状態遷移が順次判断される（Ｓｔｅｐ６０３）。この状態遷移が当該オートマトンに対応するロケーションパス（ＸＰａｔｈ）の部分的な評価を意味している。この部分的な評価の結果は、オートマトンの現在の状態として保持される。
そして、このオートマトンの最後の状態に達するまでＸＭＬイベントの入力及び状態遷移の判断を繰り返し、最後の状態に達したならば、このＸＭＬ文書に対してロケーションパスが成立したと評価され、評価イベントがアプリケーション実行部３０へ送られる（Ｓｔｅｐ６０４、６０５）。
アプリケーション実行部３０は、ＸＭＬパーサ１０から出力されたＸＭＬイベントと、ＸＰａｔｈ評価部２０の評価実行部２３から出力された評価イベントとを取得し、当該評価イベントに応じて当該ＸＭＬイベントを順次処理していく。処理対象のＸＭＬ文書についてＸＭＬパーサ１０から送られる全てのＸＭＬイベントに対して、Ｓｔｅｐ６０２〜６０５の処理を実行した後、本実施の形態によるＸＭＬ文書のストリーミング処理を終了する（Ｓｔｅｐ６０６）。
【００４５】
〔実施の形態２〕
実施の形態２では、実施の形態１で説明したオートマトンの状態遷移を用いた処理に相当するＸＰａｔｈの評価を、ＸＭＬ文書の入れ子構造を解析するスタックを用いて実現する。すなわち本実施の形態は、ＸＰａｔｈ及びＸＭＬイベント列を共にスタックで表現し、ＸＭＬイベントが通知される度にそれらを比較するという方法で実装される。
【００４６】
本実施の形態は、実施の形態１と同様に、例えば図１に示した情報処理装置にて実現される。
図７は、本実施の形態におけるＸＰａｔｈ評価手段（解析システム）の実装例を示す図である。
図７に示すように、本実施の形態による情報処理装置は、処理対象であるＸＭＬ文書の構文解析（パース）を行うＸＭＬパーサ１０と、構文解析されたＸＭＬ文書に対してＸＰａｔｈの評価を行うＸＰａｔｈ評価部４０と、ＸＰａｔｈの評価を経たＸＭＬ文書を用いて所定の情報処理を実行するアプリケーション実行部３０とを備える。
図７に示すＸＭＬパーサ１０、ＸＰａｔｈ評価部４０及びアプリケーション実行部３０は、例えば、図１に示したメインメモリ１０３に展開されたプログラムにてＣＰＵ１０１を制御することにより実現される仮想的なソフトウェアブロックである。なお、ＸＭＬパーサ１０及びアプリケーション実行部３０は、実施の形態１における対応する構成要素と同様であるため、同一の符号を付して説明を省略する。
【００４７】
ＸＰａｔｈ評価部４０は、ＸＭＬパーサ１０からＸＭＬイベントを受け取り、予め与えられたＸＰａｔｈの評価を行う。
図８は、ＸＰａｔｈ評価部４０の機能構成を説明する図である。
図８に示すように、本実施の形態のＸＰａｔｈ評価部４０は、スタック生成部４１と、ＸＭＬイベント転送部４２と、評価実行部４３とを備える。
【００４８】
スタック生成部４１は、予め与えられたＸＰａｔｈから、当該ＸＰａｔｈのステップを表現するデータ構造であるスタックを生成する。ＸＰａｔｈからのスタックの生成は、次のようにして行われる。
すなわち、スタック生成部４１は、ＸＰａｔｈの各ステップに対して、ノードテストと述語とをスタック要素で表現し、基準点に応じてスタックにプッシュする。例えば、ｃｈｉｌｄ：：ｐａｒａに対してはｐａｒａをスタック要素で表現し、既存のスタックにプッシュする。ここで、ノードテストと述語とは、ＸＭＬイベント列に対してそれらを適切に評価できる限り、どのようなスタック要素で表現してもよい。ただし、述語ｐｏｓｉｔｉｏｎ（）を含むときは、スタックが一致した回数を保持するためのカウンタを用意する。
【００４９】
図９は、基準点の種類と作成されるスタックとの関係を例示する図である。
また図９において、矢印（直線矢印と波線矢印）は共に、まず元のスタックを比較し、一致すれば先のスタックを比較することを表す。具体的には、直線矢印は、まず元のスタックを比較し、一致したならば、続けて先のスタックを比較することを表す。一方、波線矢印は、まず元のスタックを比較し、一致したならば、その後に特定のＸＭＬイベントが通知された場合に限り、先のスタックを比較することを表す。この場合の特定のＸＭＬイベントとは、基準点の種類（ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇかｆｏｌｌｏｗｉｎｇかの別）に応じて異なる。
・ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇの場合
元のスタックにおける先頭のスタック要素と一致したノード以降の兄弟ノードとその子孫ノードに対応するＸＭＬイベント。兄弟ノードに対応するＸＭＬイベントに対応するスタック要素を基準として、先のスタックを比較する。
・ｆｏｌｌｏｗｉｎｇの場合
元のスタックの先頭のスタック要素と一致したノード以降のノードに対応するＸＭＬイベント。ただし、その子孫ノードに対応するＸＭＬイベントを除く。そのようなノードの各々に対応するＸＭＬイベントに対応するスタック要素を基準として、先のスタックを比較する。
【００５０】
図１０は、図９に示した関係に基づいて、ＸＰａｔｈから生成されるスタックを示す図である。
（１）ｃｈａｐｔｅｒ／ｐａｒａ、
（２）ｃｈａｐｔｅｒ／ｐａｒａ［＠ｔｙｐｅ＝”ｗａｒｎｉｎｇ”］、
（３）ｃｈａｐｔｅｒ／ｐａｒａ［２］、
（４） ．／／ｐａｒａ
の各ＸＰａｔｈから図１０に示したスタックがそれぞれ生成される。なお、上記及び図１０において、ｃｈｉｌｄ基準点はＸＰａｔｈの表記規則に基づいて既述が省略されている。
スタック生成部４１によって、以上のようにして生成されたスタックは、例えば図１のメインメモリ１０３の作業領域に保持され、後述する評価実行部４３の処理において使用される。
なお、本実施の形態では、ＸＰａｔｈの機能に対して、実施の形態１の場合と同様の制限が課される。
【００５１】
ＸＭＬイベント転送部４２は、ＸＭＬパーサ１０から出力されたＸＭＬイベントを入力し、ＸＭＬ文書の木構造におけるノードごとに評価実行部４３へ順次転送する。また、当該ＸＭＬイベントをアプリケーション実行部３０へも順次転送する。
【００５２】
評価実行部４３は、スタック生成部４１にて生成されたスタックを取得し、ＸＭＬイベント転送部４２から転送されたＸＭＬイベントを受け取って、ＸＭＬ文書のトークン列を順次読み込みながらスタックを操作する。そして、ＸＰａｔｈを満たすノードに対応するトークンが読み込まれた時点でそのＸＰａｔｈが満たされたと評価する。この評価結果は、評価イベントとしてアプリケーション実行部３０に送られる。
【００５３】
本実施の形態では、上記のスタックを用いたＸＰａｔｈの評価を実現するためのデータ構造として、実施の形態１の場合と同様に、ＸＭＬ文書の入れ子構造を解析するスタック（ＸＭＬイベント列用のスタック）を導入する。すなわち、評価実行部４３は、スタック生成部４１で作成される上記のＸＰａｔｈ用のスタックとは別に、ＸＭＬイベント列用のスタックを用意し、ＸＭＬパーサ１０から送られるＸＭＬイベント列を保持する。このＸＭＬイベント列用のスタックに関しては、原則として、開始タグに対応するＸＭＬイベントを入力したならば、それをスタック要素で表現し、スタックにプッシュする。そして、終了タグに対応するＸＭＬイベントを入力したならば、スタックをポップする。また、テキスト等に対応するＸＭＬイベントを入力したならば、このＸＭＬイベントもスタック要素で表現しスタックにプッシュするが、スタックの比較が終了した後、即座に当該スタックをポップする。ここで、ＸＭＬイベントは、そのイベントが保持する情報を保持する限り、どのようなスタック要素で表現しても良い。
【００５４】
さらに評価実行部４３は、ＸＭＬイベント転送部４２からＸＭＬイベントが転送される度に、ＸＭＬ文書中の着目しているノードのＸＭＬイベントに対応するスタック要素を基準として、ＸＭＬイベント列用のスタックとＸＰａｔｈ用のスタックとを比較することにより、ＸＰａｔｈの評価を行う。ここで、スタックを比較するとは、対応するスタック要素を比較することである。また、スタック要素を比較するとは、対応するＸＭＬイベント（及びそれ以前に通知されたＸＭＬイベント）に対して、対応するノードテストと述語とを評価することである。
【００５５】
スタックの比較は、原則として、最後のスタック要素から行う。一致しないスタック要素を検出したならば、直ちに比較処理を終了する。また、毎回全てのスタック要素を比較しても良いし、比較において一致しなかったスタック要素の位置を保持しておき、次回の比較処理では当該一致しなかったスタック要素から後を比較するようにしても良い。
スタックが一致したならば、これは、最後に通知されたイベントに対応するノードに対してＸＰａｔｈがマッチしたことを意味する。ただし、ＸＰａｔｈ用のスタックにカウンタが用意されているときは、スタックが一致する度にＸＭＬイベント列用のスタックにおける対応スタック要素のカウント値をインクリメントし、ＸＰａｔｈ用のスタックのカウント値と一致したときに限り、ＸＰａｔｈがマッチしたと判断する。
【００５６】
以上のように、本実施の形態では、評価対象であるＸＰａｔｈをスタック要素の列で表現したＸＰａｔｈ用スタック（第１のスタック）を生成し、さらに処理対象であるＸＭＬ文書を構成するＸＭＬイベント列を入力して入力された個々のＸＭＬイベントに基づいて処理対象のＸＭＬ文書の入れ子構造を解析するＸＭＬイベント列用スタック（第２のスタック）を生成する。そして、第１のスタックと当該第２のスタックとを比較することにより、ＸＰａｔｈの部分的な評価を行う。ＸＰａｔｈの部分的な評価の結果は、ＸＭＬイベント列用スタックのスタック要素として保持される。
また、上述したように、ＸＭＬイベント列用スタックの操作は、実施の形態１で説明したＸＭＬイベント列用スタックの操作と同様である。したがって、このＸＭＬイベント列用スタックの操作及び比較が実施の形態１で説明したオートマトンの状態遷移に相当している。ただし、実施の形態２では、スタックに蓄積されたデータのマッチングのみでＸＰａｔｈの評価が実行されるので、実装が容易である。
【００５７】
次に、本実施の形態のＸＰａｔｈ評価部４０による処理について、さらに詳細に説明する。
図１１は、処理対象であるＸＭＬ文書の例を示す図、図１２乃至図１４は、図１１のＸＭＬ文書に対するスタックを用いた評価処理の様子を示す図である。なお、図１１では、各タグに関して、ｄｏｃｕｍｅｎｔをｄｏｃとするなど、適宜、省略表記がなされている（以下、他のＸＭＬ文書についても同様）。
ＸＰａｔｈとして図１０の（３）に示した
ｃｈａｐｔｅｒ／ｐａｒａ［２］
が与えられたものとする。すなわち、所定のＸＭＬ文書のイベント列に対して、ノードｃｈａｐｔｅｒの下位に位置する２つ目のノードｐａｒａが検出されたときに、このＸＰａｔｈの成立という評価がなされる。このＸＰａｔｈに対してスタック生成部４１にて生成されるスタックは図１０に示したとおりである。
【００５８】
図１２乃至図１４には、図１１のＸＭＬ文書に対するＳＡＸイベント列（ＸＭＬイベント列）と、各ＳＡＸイベント列を入力した際の評価実行部４３による比較の様子が順番に示されている。
最初に、ドキュメント開始を示すＳＡＸイベントstartDocumentが入力され、スタックの比較が開始される（図１２（Ａ））。この時点では、ＸＭＬイベント列用スタックのスタック要素は空（ＮＵＬＬ）である。次に、要素（ノード）の開始を示すＳＡＸイベントstartElement: docが入力され（図１２（Ｂ））、さらにトークン（ＳＡＸイベント）の読み込みが続けられる。
【００５９】
次に、要素の開始を示すＳＡＸイベントstartElement: chapterが入力され、ＸＭＬイベント列用スタックがプッシュされてＸＰａｔｈ用スタックと比較される（図１２（Ｃ））。このスタック要素は一致するが、この時点ではスタック要素ｐａｒａが一致していないので、トークン（ＳＡＸイベント）の読み込みが続けられる。続いて、ＳＡＸイベントstartElement: paraが入力され、ＸＭＬイベント列用スタックがプッシュされてＸＰａｔｈ用スタックと比較される（図１３（Ａ））。このスタック要素は一致するが、図１１のＸＭＬ文書で最初に現れたノードｐａｒａであるので、ポジション関数（ｐｏｓ＝２）を扱うためのカウンタの値（ｃｕｒｒｅｎｔ＿ｐｏｓ）が１インクリメントされ、トークン（ＳＡＸイベント）の読み込みが続けられる。
【００６０】
以後、要素の終了を示すＳＡＸイベントendElement: para、endElement: chapterが入力されてＸＭＬイベント列用スタックの対応するスタック要素がそれぞれポップされ（図１３（Ｂ）（Ｃ））、次に再びＳＡＸイベントstartElement: chapterが入力されてＸＭＬイベント列用スタックがプッシュされ、ＸＰａｔｈ用スタックと比較される（図１４（Ａ））。このスタック要素は一致し、続いてＳＡＸイベントstartElement: paraが入力され、ＸＭＬイベント列用スタックがプッシュされてＸＰａｔｈ用スタックと比較される（図１４（Ｂ））。このスタック要素は一致し、カウンタの値が１インクリメントされると、ｃｕｒｒｅｎｔ＿ｐｏｓ＝２となって、ポジション関数の要求を満たすので、図１１のＸＭＬ文書に対してＸＰａｔｈ“ｃｈａｐｔｅｒ／ｐａｒａ［２］”が成立したと評価される。
【００６１】
さて、上記の説明で、ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ及びｆｏｌｌｏｗｉｎｇに関しては、ノードはステップＫで選択されるノードの候補であると同時にステップＫ−１で選択されるノードの候補でもあるため、本実施の形態では、ステップＫ−１が成立したときにプッシュされたノードがポップされた時点でプロセスを２つに分割し、それぞれのプロセスが２通りのロケーションパスの解釈に対応したスタック操作を続行することとした。この動作について、具体例を挙げて詳細に説明する。
図１５は、処理対象であるＸＭＬ文書の例を示す図、図１６は評価対象であるＸＰａｔｈとこのＸＰａｔｈから生成されるスタックとを示す図、図１７乃至図１９は、図１５のＸＭＬ文書に対するスタックを用いた評価処理の様子を示す図である。
【００６２】
図１６に示すように、ＸＰａｔｈとして
ｃｈａｐ／ｐａｒａ［＠ｎｕｍ＝“２”］／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：ｐａｒａ
が与えられたものとする。すなわち、所定のＸＭＬ文書のイベント列に対して、ノードｃｈａｐｔｅｒの下位に位置するノードｐａｒａ ｎｕｍ＝“２”に後続する兄弟ノードｐａｒａが検出されたときに、このＸＰａｔｈの成立という評価がなされる。
【００６３】
図１７乃至図１９には、図１５のＸＭＬ文書に対するＳＡＸイベント列（ＸＭＬイベント列）と、各ＳＡＸイベント列を入力した際の評価実行部４３による比較の様子が順番に示されている。
まずドキュメント開始を示すＳＡＸイベントstartDocument、続いて要素の開始を示すＳＡＸイベントstartElement: docが入力され（図１７（Ａ）（Ｂ））、さらにトークン（ＳＡＸイベント）の読み込みが続けられる。次に、要素の開始を示すＳＡＸイベントstartElement: chapterが入力され、ＸＭＬイベント列用スタックがプッシュされてＸＰａｔｈ用スタックと比較されるが（図１７（Ｃ））、スタック要素ｐａｒａが一致していないので、トークン（ＳＡＸイベント）の読み込みが続けられる。
【００６４】
次に、ＳＡＸイベントstartElement: para,@num=1が入力され、ＸＭＬイベント列用スタックがプッシュされてＸＰａｔｈ用スタックと比較される（図１８（Ａ））。このスタック要素はＸＰａｔｈ用スタックの対応するスタック要素（ｐａｒａ＠ｎｕｍ＝２）とは一致せず、引き続きトークン（ＳＡＸイベント）の読み込みが行われる。続いて、要素の終了を示すＳＡＸイベントendElement: paraが入力され、ＸＭＬイベント列用スタックの対応するスタック要素がそれぞれポップされた後（図１８（Ｂ））、ＳＡＸイベントstartElement: para,@num=2が入力され、ＸＭＬイベント列用スタックがプッシュされてＸＰａｔｈ用スタックと比較される（図１８（Ｃ））。このスタック要素はＸＰａｔｈ用スタックの対応するスタック要素と一致する。したがって、これ以降は図１６に示したＸＰａｔｈ用スタックの後半（スタック要素ｐａｒａ）との比較を行う。
【００６５】
次に、ＳＡＸイベントendElement: paraが入力され、ＸＭＬイベント列用スタックの対応するスタック要素がそれぞれポップされた後（図１９（Ａ））、ＳＡＸイベントstartElement: para,@num=3が入力され、ＸＭＬイベント列用スタックがプッシュされてＸＰａｔｈ用スタックと比較される（図１９（Ｂ））。このスタック要素はＸＰａｔｈ用スタックの後半（スタック要素ｐａｒａ）に一致するので、図１５のＸＭＬ文書に対してＸＰａｔｈ“ｃｈａｐ／ｐａｒａ［＠ｎｕｍ＝“２”］／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：ｐａｒａ”が成立したと評価される。
【００６６】
図２０は、本実施の形態によるＸＭＬ文書のストリーミング処理を説明するフローチャートである。
図６に示すように、ＸＰａｔｈ評価部４０は、初期動作として、スタック生成部４１により、予め与えられたＸＰａｔｈのロケーションパスからＸＰａｔｈ用スタックを生成しておく（Ｓｔｅｐ２００１）。処理対象であるＸＭＬ文書が入力され、ＸＭＬパーサ１０からＸＭＬイベントが送られると（Ｓｔｅｐ２００２）、ＸＰａｔｈ評価部４０の評価実行部４３により、上記のようにして、当該ＸＭＬイベント用スタックが生成され、ＸＰａｔｈ用スタックとの比較が順次判断される（Ｓｔｅｐ２００３）。この比較結果が当該ＸＰａｔｈ用スタックにて表現されたＸＰａｔｈの部分的な評価を意味している。
そして、このＸＭＬイベント列用スタックとＸＰａｔｈ用スタックとが全て一致するまでＸＭＬイベントの入力及びスタックの比較を繰り返し、完全に一致したならば、このＸＭＬ文書に対してロケーションパスが成立したと評価され、評価イベントがアプリケーション実行部３０へ送られる（Ｓｔｅｐ２００４、２００５）。
アプリケーション実行部３０は、ＸＭＬパーサ１０から出力されたＸＭＬイベントと、ＸＰａｔｈ評価部４０の評価実行部４３から出力された評価イベントとを取得し、当該評価イベントに応じて当該ＸＭＬイベントを順次処理していく。
処理対象のＸＭＬ文書についてＸＭＬパーサ１０から送られる全てのＸＭＬイベントに対して、Ｓｔｅｐ２００２〜２００５の処理を実行した後、本実施の形態によるＸＭＬ文書のストリーミング処理を終了する（Ｓｔｅｐ２００６）。
【００６７】
〔実施の形態３〕
実施の形態３では、ストリーミング形式でＸＭＬイベント列を入力しながら当該ＸＭＬ文書に対する木（文書木：ドキュメントツリー）を順次作成していき、この文書木の作成に伴って逐次的にＸＰａｔｈの評価を行う。
上述したように、実施の形態１では、評価対象であるＸＰａｔｈからオートマトンを生成し、ストリーミング形式で入力されるＸＭＬイベント列によって当該オートマトンの状態遷移を順次行うことによってＸＰａｔｈの評価を行った。また実施の形態２では、ＸＰａｔｈのステップを第１のスタックで表現し、ストリーミング形式で入力されるＸＭＬ文書の入れ子構造を第２のスタックで表現し、これらのスタックの内容を比較することによってＸＰａｔｈの評価を行った。これらの手法は、いずれもＸＭＬイベント列のうち評価の済んだ部分については情報を喪失してしまうため、リバース基準点に関しては、非常に限定された条件下でのみ評価が可能であった。
これに対し、本実施の形態では、ＸＭＬイベント列の入力に伴って文書木を生成していくので、所定のＸＭＬイベントを入力した際に、それ以前のＸＭＬイベント列に関する情報が全て木構造として保持される。したがって、リバース基準点のステップが含まれるＸＰａｔｈに対しても何ら問題なく評価を行うことができる。
【００６８】
本実施の形態は、実施の形態１と同様に、例えば図１に示した情報処理装置にて実現される。
図２１は、本実施の形態におけるＸＰａｔｈ評価手段（解析システム）の実装例を示す図である。
図２１に示すように、本実施の形態による情報処理装置は、処理対象であるＸＭＬ文書の構文解析（パース）を行うＸＭＬパーサ１０と、構文解析されたＸＭＬ文書に対してＸＰａｔｈの評価を行うＸＰａｔｈ評価部５０と、ＸＰａｔｈの評価を経たＸＭＬ文書を用いて所定の情報処理を実行するアプリケーション実行部３０とを備える。
図２１に示すＸＭＬパーサ１０、ＸＰａｔｈ評価部５０及びアプリケーション実行部３０は、例えば、図１に示したメインメモリ１０３に展開されたプログラムにてＣＰＵ１０１を制御することにより実現される仮想的なソフトウェアブロックである。なお、ＸＭＬパーサ１０及びアプリケーション実行部３０は、実施の形態１における対応する構成要素と同様であるため、同一の符号を付して説明を省略する。
【００６９】
ＸＰａｔｈ評価部５０は、ＸＭＬパーサ１０からＸＭＬイベントを受け取り、予め与えられたＸＰａｔｈの評価を行う。
図２２は、ＸＰａｔｈ評価部５０の機能構成を説明する図である。
図２２に示すように、本実施の形態のＸＰａｔｈ評価部５０は、ＸＰａｔｈ格納部５１と、ＸＭＬイベント転送部５２と、文書木生成部５３と、評価実行部５４とを備える。
【００７０】
ＸＰａｔｈ格納部５１は、例えば図１に示したコンピュータ装置のメインメモリ１０３で実現され、予め与えられたＸＰａｔｈを保持する。ＸＭＬイベント転送部５２は、ＸＭＬパーサ１０から出力されたＸＭＬイベントを入力し、ＸＭＬ文書の木構造におけるノードごとに文書木生成部５３へ順次転送する。また、当該ＸＭＬイベントをアプリケーション実行部３０へも順次転送する。
【００７１】
文書木生成部５３は、ＸＭＬイベント転送部５２から転送されたＸＭＬイベントを受け取って、そのＸＭＬイベントまでの文書木を生成する。この文書木は、取得したＸＭＬイベントまでの構造を反映しているので、処理対象であるＸＭＬ文書全体の構造を表す文書木に対する部分木となる。また、ＸＭＬイベント列を最後まで取得した際に生成される文書木は、当該ＸＭＬ文書全体の文書木と同一となる。
文書木の生成は、ＸＭＬイベントとして当該ＸＭＬ文書の要素に対する開始タグトークンが入力されたときに新たにノードを追加することにより行われる。そして、開始タグトークンの入力によりノードを追加した場合、それ以降の挿入位置を当該ノードとする。また、当該要素に対する終了タグトークンが入力された場合、当該ノードの親ノードをそれ以降の挿入位置とする。したがって、この文書木は、文書木生成部５３がＸＭＬイベントを入力する度に更新されることとなる。
文書木生成部５３により生成（更新）された文書木は、例えば図１のメインメモリ１０３の作業領域に保持され、後述する評価実行部５４の処理において使用される。
【００７２】
評価実行部５４は、文書木生成部５３により上記の文書木が更新されると、当該文書木を用いて、ＸＰａｔｈ格納部５１に保持されているＸＰａｔｈの評価を行う。本実施の形態の評価実行部５４は、ＸＰａｔｈを評価して成立したステップに関して、当該ステップにおいて選択された文書木のノードの情報、すなわちＸＰａｔｈにおける部分的な評価結果の情報を保存する。この情報は、各ステップのステップＩＤとノードＩＤとの組（タプル）の集合｛＜ｓｉｄ１，ｎｉｄ１＞，＜ｓｉｄ１，ｎｉｄ２＞，・・・｝として表される。これを保存集合と呼ぶ。生成された保存集合は、例えば図１のメインメモリ１０３の作業領域に保持される。
保存集合において各ステップは、１番から順に番号付けされているとする。ここで、０番目のステップは特別なステップとし、このステップに対応させてルートノードを常に保存しておく。評価実行部５４の評価により選択された各ノードは、当該ノードをコンテクストノードとして、それ以降の各ステップによって選択されるノード集合が空とならない限り保存される。
【００７３】
図２３乃至図２５は、評価実行部５４による文書木及び保存集合を用いたＸＰａｔｈの評価手順を示すフローチャートであり、図２３、２４はＸＭＬイベントとして開始タグトークンが入力された場合の動作、図２５はＸＭＬイベントとして終了タグトークンが入力された場合の動作を示す。なお、説明の簡単のため、図示の動作では述語（predicate）を考慮していない。述語への対応については後述する。
図２３に示すように、評価実行部５４は、ＸＭＬイベントとして開始タグトークンが入力されると（Ｓｔｅｐ２３０１）、この要素に対応するノードＮをそれまでに生成されている文書木に挿入する（Ｓｔｅｐ２３０２）。初期的にはルートノードに対してノードＮが挿入される。そして、保存集合の各要素＜Ｓ，ｎｉｄ＞に対し、ステップＳの次の番号がつけられたステップＳ’を参照し、以下の動作を行う（Ｓｔｅｐ２３０３）。
【００７４】
評価実行部５４は、まずステップＳ’がロケーションパス（ＸＰａｔｈ）の最後かどうかを調べ（Ｓｔｅｐ２３０４）、最後ならば、さらにステップＳ’の評価が成立するかどうかを調べる（Ｓｔｅｐ２３０５）。評価が成立したならば、最後に挿入されたノードＮがＸＰａｔｈにてアドレッシングされたノードであるので、このノードＮを評価イベントとして出力する（Ｓｔｅｐ２３０６）。
ステップＳ’がロケーションパスの最後でない場合、次に評価実行部５４は、ステップＳ’の評価が成立するかどうかを調べる（Ｓｔｅｐ２３０７）。評価が成立したならば、さらにステップＳ’の次のステップＳ”における基準点に応じて、次の処理を行う。
なお、上記のＳｔｅｐ２３０５、２３０７の判断で、ステップＳ’の評価が成立しない場合、当該ＸＭＬイベントに対する処理を終了して、次のＸＭＬイベントの入力を待つ。
【００７５】
図２４に示すように、ステップＳ”の基準点がｓｅｌｆ基準点である場合、ステップＳ”を新たにステップＳ’として、評価実行部５４の処理がＳｔｅｐ２３０４の判断へ戻る（Ｓｔｅｐ２３０８、２３０９）。
【００７６】
ステップＳ”の基準点がｃｈｉｌｄ、ｄｅｓｃｅｎｄａｎｔ等のフォワード基準点である場合、まず、ノードＮをコンテクストノードとして、ステップＳ”の基準点が指定する関係を満たす入力が、この後にあり得るかどうかを判定する（Ｓｔｅｐ２３０８、２３１０）。そのような入力の可能性があるならば、タプル（ステップＩＤとノードＩＤとの組）＜Ｓ’，Ｎ＞を保存集合に追加する（Ｓｔｅｐ２３１１）。そして、既に構築された文書木におけるノードＮに対してドキュメント順で後に位置するノード集合（ｓｅｌｆを含む基準点（ｄｅｓｃｅｎｄａｎｔ−ｏｒ−ｓｅｌｆ等）の場合はノードＮ自身を含む）の各要素を新しいノードＮとし、ステップＳ”を新たにステップＳ’として、評価実行部５４の処理がＳｔｅｐ２３０４の判断へ戻る（Ｓｔｅｐ２３１２）。
ステップＳ”の基準点が指定する関係を満たす入力の可能性がないならば、タプル＜Ｓ’，Ｎ＞を保存集合に追加することなく、当該ノードＮに対してドキュメント順で後に位置するノード集合（ｓｅｌｆを含む基準点（ｄｅｓｃｅｎｄａｎｔ−ｏｒ−ｓｅｌｆ等）の場合はノードＮ自身を含む）の各要素を新しいノードＮとし、ステップＳ”を新たにステップＳ’として、評価実行部５４の処理がＳｔｅｐ２３０４の判断へ戻る（Ｓｔｅｐ２３１０、２３１２）。
【００７７】
ステップＳ”の基準点がｐａｒｅｎｔ、ａｎｃｅｓｔｏｒ等のリバース基準点である場合、既に構築された文書木におけるノードＮに対してドキュメント順で後に位置するノード集合（ｓｅｌｆを含む基準点（ａｎｃｅｓｔｏｒ−ｏｒ−ｓｅｌｆ等）の場合はノードＮ自身を含む）の各要素を新しいノードＮとし、ステップＳ”を新たにステップＳ’として、評価実行部５４の処理がＳｔｅｐ２３０４の判断へ戻る（Ｓｔｅｐ２３０８、２３１２）。
なお、以上の説明では、評価実行部５４はＸＰａｔｈが成立した場合に評価イベントを出力する（ステップ２３０６参照）こととしたが、ＸＭＬイベントを１つ処理する度に成立または不成立を示す評価イベントを出力するようにしても良いことは、実施の形態１、２の場合と同様である。
【００７８】
一方、図２５に示すように、評価実行部５４は、ＸＭＬイベントとして終了タグトークンが入力されると（Ｓｔｅｐ２５０１）、そのトークンに対応したノードを含むタプル＜Ｓ，Ｎ＞を保存集合の中から検出する（Ｓｔｅｐ２５０２）。
次に、検出されたタプルに対して、ノードＮをコンテクストノードとして、ステップＳの次の番号が付されたステップＳ’の基準点が指定する関係を満たす入力が、この後にあり得るかどうかを判定する（Ｓｔｅｐ２５０３）。そして、そのような入力の可能性のないタプルを保存集合から除去する（Ｓｔｅｐ２５０４）。
この後、処理対象であるトークンの子ノードを含むタプル＜Ｓ'，Ｎ'＞を保存集合の中から検出する（Ｓｔｅｐ２５０５）。次に、検出されたタプルに対して、ノードＮ'をコンテクストノードとして、ステップＳ'の次の番号が付されたステップＳ”の基準点が指定する関係を満たす入力が、この後にあり得るかどうかを判定する（Ｓｔｅｐ２５０６）。そして、そのような入力の可能性のないタプルを同様に保存集合から除去する（Ｓｔｅｐ２５０７）。
【００７９】
次に、上記の動作説明で省いた述語への対応について説明する。上述した動作におけるノードの評価において、述語を評価するために必要な条件がそろっている場合は、述語の評価を行う。述語の評価を行っていない場合は、述語が未評価であることを意味する付加情報をノードや保存集合に付しておき、述語の評価が仮に成功したとみなして、上記の動作を継続する。ただし、述語が未評価のノードに依存するノードの出力は保留する。述語が未評価の保存集合内の要素に対しする評価は、その後の入力によって述語の評価条件がそろった時点で行う。述語にロケーションパスが使われている場合は、評価の目的を述語を評価することに変更して図２３乃至図２５の処理を適用する。
最終的に述語の評価が成功した場合は、その評価の成功に依存していたノードを評価イベントとして出力する。一方、評価が失敗した場合は、保存集合から当該ノードを取り除き、さらに当該ノードの評価の成功を仮定して行われた全ての操作を取り消す。
【００８０】
次に、具体例を挙げて本実施の形態によるＸＰａｔｈの評価を説明する。
図２６は、処理対象であるＸＭＬ文書、そのＳＡＸイベント列および文書木を示す図である。
ＸＰａｔｈ評価部５０に、次のＸＰａｔｈ
／ａ／ｂ／ｐｒｅｃｅｄｉｎｇ−ｓｉｂｌｉｎｇ：：ｃ／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：ｄ
が与えられたものとする。すなわち、ノードａの子供であるノードｂに先行する兄弟ノードｃに後続する兄弟ノードｄが検出されたときに、このＸＰａｔｈの成立という評価がなされる。
【００８１】
図２７乃至図３６には、図２６のＸＭＬ文書に対するＳＡＸイベント列と、これに対応する文書木、及び当該文書木を用いたＸＰａｔｈの評価によって得られる保存集合の遷移の様子が順番に示されている。
最初に、ドキュメント開始を示すＳＡＸイベントstartDocumentが入力され、対応する文書木としてルートノードｄｏｃが生成される（図２７）。また、タプル（ステップＩＤとノードＩＤとの組）＜０，ｄｏｃ＞が保存集合に入れられる。続いて、要素（ノード）の開始を示すＳＡＸイベントstartElement: "a"が入力され、ルートノードｄｏｃに子ノード“ａ”が付加される（図２８）。また、ＸＰａｔｈのステップ１までが成立するので、タプル＜１，“ａ”＞が保存集合に入れられる。
【００８２】
次に、ＳＡＸイベントstartElement: "c"が入力され、ノード“ａ”に子ノード“ｃ”が付加され（図２９）、続いて、要素の終了を示すＳＡＸイベントendElement: "c"が入力される（図３０）。次に、ＳＡＸイベントstartElement: "b"が入力されると、ノード“ａ”に子ノード“ｂ”が付加される（図３１）。このとき、ノード“ｂ”の生成によりＸＰａｔｈのステップ２が成立すると共に、リバース基準点（ｐｒｅｃｅｄｉｎｇ−ｓｉｂｌｉｎｇ）のステップ３も直ちに成立する。したがって、ステップ２に関するタプルは保存集合に保持されず、ステップ３に関するタプル＜３，“ｃ”＞が保存集合に入れられる。
【００８３】
この後、ＳＡＸイベントendElement: "ｂ"が入力され（図３２）、引き続き、ＳＡＸイベントstartElement: "d"が入力されると、ノード“ａ”に子ノード“ｄ”が付加される（図３３）。このとき、ノード“ｄ”の生成によりＸＰａｔｈのステップ４（最後のステップ）まで成立するので、当該ＸＰａｔｈが成立したと評価される。したがって、ＸＰａｔｈ評価部５０の評価実行部５４からアプリケーション実行部３０へ、評価イベントとしてノード“ｄ”が出力される（図２３、Ｓｔｅｐ２３０６参照）。
【００８４】
この後、ＳＡＸイベントendElement: "d"が入力され（図３４）、続いてＳＡＸイベントendElement: "a"が入力されて、ノード“ａ”に新たな子ノードが付加される可能性がなくなったので、保存集合からステップ１のタプル＜１，“ａ”＞が除去される（図３５、図２５のＳｔｅｐ２５０３、２５０４参照）。そしてさらに、ドキュメント終了を示すＳＡＸイベントendDocumentが入力されて、処理対象であるＸＭＬ文書のイベント列の入力が終了する（図３６）。
【００８５】
図３７は、本実施の形態によるＸＭＬ文書のストリーミング処理を説明するフローチャートである。
図３７に示すように、ＸＰａｔｈ評価部５０は、処理対象であるＸＭＬ文書が入力され、ＸＭＬパーサ１０からＸＭＬイベントが送られると（Ｓｔｅｐ３７０１）、まず取得したＸＭＬイベントに基づいて文書木が生成される（Ｓｔｅｐ３７０２）。この文書木は、ＸＭＬイベントが順次入力されるに伴って更新され、最終的に処理対象のＸＭＬ文書の文書構造に対応する文書木となる。そして、ＸＰａｔｈ評価部５０の評価実行部５４により、この文書木を用いてＸＰａｔｈの評価が行われ、部分的に成立した箇所（ステップ）に関する情報が必要に応じて保存集合に蓄積される（Ｓｔｅｐ３７０３）。そして、ＸＰａｔｈ全体が成立するまでＸＭＬイベントの入力、文書木の生成およびＸＰａｔｈの評価が繰り返され、ＸＰａｔｈ全体が成立すると評価されたならば、評価イベントがアプリケーション実行部３０へ送られる（Ｓｔｅｐ３７０４、３７０５）。
アプリケーション実行部３０は、ＸＭＬパーサ１０から出力されたＸＭＬイベントと、ＸＰａｔｈ評価部５０の評価実行部５４から出力された評価イベントとを取得し、当該評価イベントに応じて当該ＸＭＬイベントを順次処理していく。処理対象のＸＭＬ文書についてＸＭＬパーサ１０から送られる全てのＸＭＬイベントに対して、Ｓｔｅｐ３７０１〜３７０５の処理を実行した後、本実施の形態によるＸＭＬ文書のストリーミング処理を終了する（Ｓｔｅｐ３７０６）。
【００８６】
以上、３つの実施の形態によって、本発明を説明した。これらの実施の形態は、ストリーミング形式で入力されるＸＭＬイベント列に対してＸＰａｔｈの部分的な評価を順次行っていき、かかる部分的な評価に関する情報を蓄積していって、最終的にＸＰａｔｈ全体の評価結果を得る。
実施の形態１、２は、ＸＭＬイベント列のストリーミング形式による入力に応じて部分的に評価していくことが可能なデータ構造にＸＰａｔｈを変換しておき、個々のＸＭＬイベントの入力に応じて順次評価を行った。一方、実施の形態３は、ＸＭＬイベント列をストリーミング形式で入力しながらＸＭＬ文書の文書木を作成していき、この文書木を用いて逐次的にＸＰａｔｈの評価を行った。
【００８７】
実施の形態１、２は、評価の済んだＸＭＬイベントに関する情報が失われるので、リバース基準点のステップに関しては、極めて限定された条件下以外では評価できない。これに対し、実施の形態３は、評価を行ったＸＭＬイベントの情報は、文書木として残っているので、リバース基準点のステップに関する評価に対する制限はない。
【００８８】
また、実施の形態１、２、３のいずれも、全てのＸＭＬイベント列を入力していない段階でＸＰａｔｈが成立すると判断された場合には、その段階でアプリケーション実行部３０による処理を開始することが可能である（ストリーミング処理）。しかしながら、実施の形態３は、ＸＰａｔｈがリバース基準点のステップを含む場合に、ＸＭＬイベントの通知と評価イベントのそれに時間差が生じることがあり、また評価イベントの通知が必ずしもドキュメント順（ドキュメントのＸＭＬ表現において各ノードのＸＭＬ表現の最初の文字が現われる順序）で行われるとは限らないため、アプリケーション実行部３０による処理が評価イベントによってＸＭＬイベントの処理を切り替えるようなものである場合は注意が必要である。実施の形態１、２にはかかる制限はない。
【００８９】
したがって、ＸＰａｔｈがリバース基準点のステップを含まない場合には、実施の形態１、２を用いる。そして、ＸＰａｔｈがリバース基準点のステップを含む場合であっても、アプリケーション実行部３０による処理が評価イベントによってＸＭＬイベントの処理を切り替えるようなものでない場合や、そのようなものであっても処理の遅延が許されるような場合には、実施の形態３を用いるといった使い分けが可能である。
実施の形態２は、入力したＸＭＬイベント列をスタックに列の情報のまま格納し、ＸＰａｔｈを表現するスタックの記憶内容と比較するだけなので、メモリの使用量が非常に少なく、かつ処理に要する時間も短い。また、比較的容易に実装可能である。したがって、いずれの実施の形態も実施可能である場合、実施の形態２を用いることが好ましい。
なお、本発明の技術的範囲は、上記３つの実施の形態に限るものではなく、技術的思想において同一である種々の変形を含むことは言うまでもない。
【００９０】
【発明の効果】
以上説明したように、本発明によれば、ＸＭＬ文書をストリーミング処理しながらＸＰａｔｈの評価を行う解析システム及びその解析方法を実現することができる。
【図面の簡単な説明】
【図１】 実施の形態１を実現するのに好適な情報処理装置のハードウェア構成の例を模式的に示した図である。
【図２】 実施の形態１におけるＸＰａｔｈ評価手段（解析システム）の実装例を示す図である。
【図３】 実施の形態１におけるＸＰａｔｈ評価部の機能構成を説明する図である。
【図４】 実施の形態１におけるオートマトン生成部にて生成されるオートマトンを模式的に示す図である。
【図５】 実施の形態１による処理に用いられるロケーションパス、オートマトン及び処理対象のＸＭＬ文書の例を示す図である。
【図６】 実施の形態１によるＸＭＬ文書のストリーミング処理を説明するフローチャートである。
【図７】 実施の形態２におけるＸＰａｔｈ評価手段（解析システム）の実装例を示す図である。
【図８】 実施の形態２におけるＸＰａｔｈ評価部の機能構成を説明する図である。
【図９】 基準点の種類と本実施の形態にて作成されるスタックとの関係を例示する図である。
【図１０】 図９に示した関係に基づいて、ＸＰａｔｈから生成されるスタックを示す図である。
【図１１】 処理対象であるＸＭＬ文書の例を示す図である。
【図１２】 図１１のＸＭＬ文書に対するスタックを用いた評価処理の様子を示す図である。
【図１３】 図１１のＸＭＬ文書に対するスタックを用いた評価処理の様子を示す図である。
【図１４】 図１１のＸＭＬ文書に対するスタックを用いた評価処理の様子を示す図である。
【図１５】 処理対象であるＸＭＬ文書の他の例を示す図である。
【図１６】 評価対象であるＸＰａｔｈとこのＸＰａｔｈから生成されるスタックとを示す図である。
【図１７】 図１５のＸＭＬ文書に対するスタックを用いた評価処理の様子を示す図である。
【図１８】 図１５のＸＭＬ文書に対するスタックを用いた評価処理の様子を示す図である。
【図１９】 図１５のＸＭＬ文書に対するスタックを用いた評価処理の様子を示す図である。
【図２０】 実施の形態２によるＸＭＬ文書のストリーミング処理を説明するフローチャートである。
【図２１】 実施の形態３におけるＸＰａｔｈ評価手段（解析システム）の実装例を示す図である。
【図２２】 実施の形態３におけるＸＰａｔｈ評価部の機能構成を説明する図である。
【図２３】 実施の形態３の評価実行部による文書木及び保存集合を用いたＸＰａｔｈの評価手順を示すフローチャートであり、ＸＭＬイベントとして開始タグトークンが入力された場合の動作を示す図である。
【図２４】 実施の形態３の評価実行部による文書木及び保存集合を用いたＸＰａｔｈの評価手順を示すフローチャートであり、ＸＭＬイベントとして開始タグトークンが入力された場合の動作を示す図である。
【図２５】 実施の形態３の評価実行部による文書木及び保存集合を用いたＸＰａｔｈの評価手順を示すフローチャートであり、ＸＭＬイベントとして終了タグトークンが入力された場合の動作を示す図である。
【図２６】 処理対象であるＸＭＬ文書、そのＳＡＸイベント列および本実施の形態で生成される文書木を示す図である。
【図２７】 ＸＭＬ文書に対するＳＡＸイベント列、文書木、保存集合の遷移の様子を示す図であり、ＳＡＸイベントstartDocumentが入力されたときの様子を示す図である。
【図２８】 ＸＭＬ文書に対するＳＡＸイベント列、文書木、保存集合の遷移の様子を示す図であり、ＳＡＸイベントstartElement: "a"が入力されたときの様子を示す図である。
【図２９】 ＸＭＬ文書に対するＳＡＸイベント列、文書木、保存集合の遷移の様子を示す図であり、ＳＡＸイベントstartElement: "c"が入力されたときの様子を示す図である。
【図３０】 ＸＭＬ文書に対するＳＡＸイベント列、文書木、保存集合の遷移の様子を示す図であり、ＳＡＸイベントendElement: "c"が入力されたときの様子を示す図である。
【図３１】 ＸＭＬ文書に対するＳＡＸイベント列、文書木、保存集合の遷移の様子を示す図であり、ＳＡＸイベントstartElement: "b"が入力されたときの様子を示す図である。
【図３２】 ＸＭＬ文書に対するＳＡＸイベント列、文書木、保存集合の遷移の様子を示す図であり、ＳＡＸイベントendElement: "ｂ"が入力されたときの様子を示す図である。
【図３３】 ＸＭＬ文書に対するＳＡＸイベント列、文書木、保存集合の遷移の様子を示す図であり、ＳＡＸイベントstartElement: "d"が入力されたときの様子を示す図である。
【図３４】 ＸＭＬ文書に対するＳＡＸイベント列、文書木、保存集合の遷移の様子を示す図であり、ＳＡＸイベントendElement: "d"が入力されたときの様子を示す図である。
【図３５】 ＸＭＬ文書に対するＳＡＸイベント列、文書木、保存集合の遷移の様子を示す図であり、ＳＡＸイベントendElement: "a"が入力されたときの様子を示す図である。
【図３６】 ＸＭＬ文書に対するＳＡＸイベント列、文書木、保存集合の遷移の様子を示す図であり、ＳＡＸイベントendDocumentが入力されたときの様子を示す図である。
【図３７】 実施の形態３によるＸＭＬ文書のストリーミング処理を説明するフローチャートである。
【符号の説明】
１０…ＸＭＬパーサ、２０、４０、５０…ＸＰａｔｈ評価部、２１…オートマトン生成部、２２、４２、５２…ＸＭＬイベント転送部、２３、４３、５４…評価実行部、３０…アプリケーション実行部、４１…スタック生成部、５１…ＸＰａｔｈ格納部、５３…文書木生成部、１０１…ＣＰＵ、１０３…メインメモリ
【発明の属する技術分野】
本発明は、ＸＭＬ（Extensible Markup Language）文書の解析技術に関し、特にＸＰａｔｈ（XML Path Language）の評価を行う解析システム及びその解析方法に関する。
【０００２】
【従来の技術】
今日、インターネットに代表されるコンピュータネットワークのパケット交換に用いられる文書記述言語として、文書の論理構造や構成要素の意味を自由に定義できるＸＭＬが広く普及している。ＸＭＬ文書をアプリケーションで利用する際に、処理対象であるＸＭＬ文書を解析することが必要となるが、このときＸＰａｔｈが利用される。ＸＰａｔｈは、ＸＭＬ文書の特定の部分を指し示す構文を規定する言語であり、Ｗ３Ｃ（World Wide Web Consortium）勧告の仕様である。ＸＰａｔｈを利用することにより、所定のＸＭＬ文書が特定の論理構造や構成要素を持つかどうかを解析することができる（例えば、非特許文献１参照）。
【０００３】
また、ＸＭＬ文書の構造は、木構造で表現することができ、Ｗ３Ｃ勧告の仕様であるＤＯＭ（Document Object Model）等を用いて表現される。ＸＰａｔｈを用いてＸＭＬ文書を解析する場合、通常、ＤＯＭ等で表現されたＸＭＬ文書全体を対象として走査し、ＸＰａｔｈにて記述された構造を当該ＸＭＬ文書が持つかどうかを調べる。したがって、ＸＭＬ文書の解析システムは、解析対象であるＸＭＬ文書全体を所定のメモリに読み込んで処理を行う必要があった。
【０００４】
【非特許文献１】
“XML Path Language (XPath) Version 1.0”、[online]、１９９９年１１月１６日、[２００３年３月４日検索]、インターネット＜http://www.w3.org/TR/xpath＞
【０００５】
【発明が解決しようとする課題】
上記のように、ＸＰａｔｈを用いてＸＭＬ文書の解析を行う場合、従来は、解析対象であるＸＭＬ文書全体を、一旦メモリの作業領域に読み込む必要があった。しかし、解析対象であるＸＭＬ文書のデータサイズが巨大である場合、これをＤＯＭ等の記述として読み込むのは、多大なメモリ使用量を要し、またＤＯＭを作成、操作する処理に多大な時間を要するという問題があった。
【０００６】
また、ＳＡＸ（The Simple API for XML）やＸＮＩのようなストリーミングベースのＡＰＩ（Application Program Interface）を用いる場合、ＡＰＩはストリーミング形式で取得されるＸＭＬ文書を順次処理できるにも関わらず、ＸＰａｔｈによる解析を行うために、一旦ＸＭＬ文書全体を読み込んでからでなければ処理を開始できないのは効率が悪い。
【０００７】
そこで本発明は、上記の問題に鑑み、ＸＭＬ文書をストリーミング処理しながらＸＰａｔｈの評価を行う解析システム及びその解析方法を実現することを目的とする。
【０００８】
【課題を解決するための手段】
上記の目的を達成する本発明は、コンピュータを用いてＸＭＬ文書に対するＸＰａｔｈの評価を行う、次のようなＸＰａｔｈ評価方法として実現される。このＸＰａｔｈ評価方法は、処理対象のＸＭＬ文書を構成するＸＭＬイベント列を順次入力する第１のステップと、入力された個々のＸＭＬイベントに対してＸＰａｔｈを順次評価すると共に、所定のＸＭＬイベントに対してこのＸＰａｔｈが部分的に成立した場合に、このＸＰａｔｈの部分的な評価の結果に関する情報を所定の記憶手段に保持する第２のステップと、ＸＭＬイベント列の入力に伴って、記憶手段に保持されている部分的な評価の結果を考慮してＸＰａｔｈの部分的な評価を繰り返し、ＸＰａｔｈの最後の部分が成立した場合に、処理対象であるＸＭＬ文書に対して、このＸＰａｔｈが成立したと評価する第３のステップとを含むことを特徴とする。
このように、入力したＸＭＬイベントに対して個別にＸＰａｔｈの評価を行っていき、その部分的な評価結果を蓄積しながら、ＸＰａｔｈ全体が成立するかどうかを判断することにより、ストリーミング処理によるＸＰａｔｈの評価が可能となる。
【０００９】
この第２のステップで行われるＸＰａｔｈの評価及び部分的な評価の結果を保持する具体的な手法として、本発明では、オートマトンを用いた手法、スタックを用いた手法、ＸＭＬイベント列の入力に伴って順次生成される文書木を用いた手法を提示する。
オートマトンを用いた手法では、評価対象であるＸＰａｔｈを表現するオートマトンを生成し、個々のＸＭＬイベントに基づいて、このオートマトンの状態を遷移させることにより、ＸＰａｔｈの評価を行う。この部分的な評価の結果は、オートマトンの状態として保持される。
【００１０】
スタックを用いた手法では、評価対象であるＸＰａｔｈをスタック要素の列で表現した第１のスタックを生成し、個々のＸＭＬイベントに基づいて処理対象のＸＭＬ文書の入れ子構造を解析する第２のスタックを生成する。そして、第１のスタックと第２のスタックとを比較することにより、ＸＰａｔｈの評価を行う。この部分的な評価の結果は、第２のスタックのスタック要素として保持される。
【００１１】
ＸＭＬイベント列の入力に伴って順次生成される文書木を用いた手法では、入力された個々のＸＭＬイベントの入力に基づいて処理対象のＸＭＬ文書の文書構造を示す文書木を順次生成していき、この文書木の生成に伴い、生成された部分までの文書木を用いてＸＰａｔｈの評価を行う。この場合、ＸＭＬイベント列の入力に伴って文書木が作成されていくので、文書木において新たなノードが追加されるたびにＸＰａｔｈを評価していき、ＸＰａｔｈが成立するかどうかを調べれば良い。しかし、ＸＰａｔｈが成立するノードが複数存在する場合もあるので、部分的な評価の結果の情報を保持しておき、後続のＸＭＬイベントに対する評価の際に用いることができる。
【００１２】
また、上記の目的を達成する他の本発明は、次のように構成されたＸＰａｔｈ評価装置としても実現される。このＸＰａｔｈ評価装置は、ストリーミング処理によるＸＰａｔｈの評価を実行する評価実行部と、処理対象のＸＭＬ文書を構成するＸＭＬイベント列を入力し、評価実行部に順次転送するＸＭＬイベント転送部とを備える。この評価実行部は、ＸＭＬイベント転送部から転送された個々のＸＭＬイベントに対してＸＰａｔｈを順次評価すると共に、所定のＸＭＬイベントに対して、このＸＰａｔｈが部分的に成立した場合に、このＸＰａｔｈの部分的な評価の結果に関する情報を保持していく。そして、このＸＰａｔｈの最後のステップが成立した場合に、ＸＭＬ文書に対して、このＸＰａｔｈが成立したと評価することを特徴とする。
【００１３】
このＸＰａｔｈ評価装置は、上述したＸＰａｔｈの評価及び部分的な評価の結果を保持する具体的な手法として、オートマトンを用いた手法を実現するため、ＸＰａｔｈを表現するオートマトンを生成するオートマトン生成部をさらに備える構成とすることができる。同様に、スタックを用いた手法を実現するため、ＸＰａｔｈをスタック要素の列で表現した第１のスタックを生成するスタック生成部をさらに備える構成とすることができる。
【００１４】
また、本発明の他のＸＰａｔｈ評価装置は、ＸＭＬ文書を構成するＸＭＬイベント列を入力し、個々のＸＭＬイベントの入力に伴い、入力されたＸＭＬイベントに基づいてＸＭＬ文書の文書構造を示す文書木を順次生成する文書木生成部と、処理対象のＸＭＬ文書を構成するＸＭＬイベント列を入力し、この文書木生成部に順次転送するＸＭＬイベント転送部と、この文書木生成部による文書木の生成に伴い、生成された部分までの文書木を用いてＸＰａｔｈの評価を行う評価実行部とを備えることを特徴とする。
【００１５】
さらに本発明は、ＸＭＬパーサと、上述したＸＰａｔｈ評価装置の機能を備えたＸＰａｔｈ評価部と、ＸＭＬパーサで生成されたＸＭＬイベントを入力し、ＸＰａｔｈ評価部によるＸＰａｔｈの評価結果に応じて、入力したＸＭＬイベントにて構成されるＸＭＬ文書に対する処理を実行するアプリケーション実行部とを備える情報処理装置として実現することもできる。
【００１６】
また本発明は、コンピュータを制御して上述したＸＰａｔｈ方法の各ステップに対応する処理を実行させるプログラム、またはコンピュータを上記ＸＰａｔｈ評価装置あるいは情報処理装置として機能させるプログラムとしても実現される。このプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録媒体に格納して配布したり、ネットワークを介して配信したりすることにより、提供することができる。
【００１７】
【発明の実施の形態】
以下、添付図面に示す実施の形態に基づいて、この発明を詳細に説明する。
本発明は、ストリーミング形式で入力される処理対象のＸＭＬ文書に対して、当該ＸＭＬ文書の入力に応じて順次ＸＰａｔｈの評価を行う。このストリーミング処理によるＸＰａｔｈの評価を実現する実施の形態として、以下ではオートマトンを用いた実施の形態（実施の形態１）、スタックを用いた実施の形態（実施の形態２）、ツリーを用いた実施の形態（実施の形態３）を説明する。なお、これらの実施の形態は、パーソナルコンピュータやワークステーション、その他のコンピュータ装置、ＰＤＡ（Personal Digital Assistant）、携帯電話等の種々の情報処理装置にて実現される。
【００１８】
〔実施の形態１〕
実施の形態１では、オートマトンを用いることにより、ＸＰａｔｈの評価のストリーミング処理を実現する。
図１は、本実施の形態を実現するのに好適な情報処理装置のハードウェア構成の例を模式的に示した図である。
図１に示す情報処理装置は、演算手段であるＣＰＵ（Central Processing Unit：中央処理装置）１０１と、Ｍ／Ｂ（マザーボード）チップセット１０２及びＣＰＵバスを介してＣＰＵ１０１に接続されたメインメモリ１０３と、同じくＭ／Ｂチップセット１０２及びＡＧＰ（Accelerated Graphics Port）を介してＣＰＵ１０１に接続されたビデオカード１０４と、ＰＣＩ（Peripheral Component Interconnect）バスを介してＭ／Ｂチップセット１０２に接続されたハードディスク１０５、ネットワークインターフェイス１０６及びＵＳＢポート１０７と、さらにこのＰＣＩバスからブリッジ回路１０８及びＩＳＡ（Industry Standard Architecture）バスなどの低速なバスを介してＭ／Ｂチップセット１０２に接続されたフロッピーディスクドライブ１０９及びキーボード／マウス１１０とを備える。
なお、図１は本実施の形態を実現するコンピュータのハードウェア構成を例示するに過ぎず、本実施の形態を適用可能であれば、他の種々の構成を取ることができる。例えば、ビデオカード１０４を設ける代わりに、ビデオメモリのみを搭載し、ＣＰＵ１０１にてイメージデータを処理する構成としても良いし、ＡＴＡ（AT Attachment）などのインターフェイスを介してＣＤ−ＲＯＭ（Compact Disc Read Only Memory）やＤＶＤ−ＲＯＭ（Digital Versatile Disc Read Only Memory）のドライブを設けても良い。
【００１９】
図２は、本実施の形態におけるＸＰａｔｈ評価手段（解析システム）の実装例を示す図である。
図２に示すように、本実施の形態による情報処理装置は、処理対象であるＸＭＬ文書の構文解析（パース）を行うＸＭＬパーサ１０と、構文解析されたＸＭＬ文書に対してＸＰａｔｈの評価を行うＸＰａｔｈ評価部２０と、ＸＰａｔｈの評価を経たＸＭＬ文書を用いて所定の情報処理を実行するアプリケーション実行部３０とを備える。
図２に示すＸＭＬパーサ１０、ＸＰａｔｈ評価部２０及びアプリケーション実行部３０は、例えば、図１に示したメインメモリ１０３に展開されたプログラムにてＣＰＵ１０１を制御することにより実現される仮想的なソフトウェアブロックである。
【００２０】
図２において、ＸＭＬパーサ１０は、処理対象のＸＭＬ文書を入力して構文解析を行い、解析結果を通知するＸＭＬイベントを出力してＸＰａｔｈ評価部２０に送る。ＸＭＬイベントは、解析対象のＸＭＬ文書の木構造（ドキュメントツリー）におけるノードごとに順次、ＸＰａｔｈ評価部２０へ送られる。ＸＭＬパーサ１０としては、ＸＭＬ文書を扱う情報処理装置で従来から用いられている既存のＸＭＬパーサを用いることができる。なお、本実施の形態において、入力対象となるＸＭＬ文書は整形式であることを前提とする。
【００２１】
ＸＰａｔｈ評価部２０は、ＸＭＬパーサ１０からＸＭＬイベントを受け取り、予め与えられたＸＰａｔｈの評価を行う。
図３は、ＸＰａｔｈ評価部２０の機能構成を説明する図である。
図３に示すように、本実施の形態のＸＰａｔｈ評価部２０は、オートマトン生成部２１と、ＸＭＬイベント転送部２２と、評価実行部２３とを備える。
【００２２】
オートマトン生成部２１は、予め与えられたＸＰａｔｈからオートマトン（状態遷移機械）を生成する。本実施の形態では、ＳＡＸやＸＮＩ等のストリーミング形式で実行されるＡＰＩを用いたアプリケーションに対してＸＰａｔｈを評価する。したがって、ストリーミング処理を行うという制約上、評価対象となるＸＰａｔｈの機能は一部制限される。例えば、評価において既に通知されたＸＭＬイベントを参照することが必要となる基準点（axis）や述語（predicate）は実現されない。しかし、実際の多くのアプリケーションにおける処理では、かかる制限が問題となることはない。
【００２３】
ここで、本実施の形態におけるＸＰａｔｈの制限を具体的に提示する。
１．ＸＰａｔｈは、ロケーションパスとする。ただし、絶対ロケーションパスは、対象であるＸＭＬ文書の木構造のルートノードからＸＰａｔｈを評価するときに限る。
２．基準点は、フォワード基準点のみとする。すなわち、次のいずれかとする。
ｓｅｌｆ
ｃｈｉｌｄ
ｄｅｓｃｅｎｄａｎｔ
ｄｅｓｃｅｎｄａｎｔ−ｏｒ−ｓｅｌｆ
ｆｏｌｌｏｗｉｎｇ
ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ
ａｔｔｒｉｂｕｔｅ
ｎａｍｅｓｐａｃｅ
ただし、ある条件と特別な実装の上でリバース基準点も使用することができる。これについては後述する。
３．述語については次のように扱う。
（１）演算子は、次のいずれかとする。
ｏｒ
ａｎｄ
＝
！＝
（２）プリミティブは、次のいずれかとする。
・ロケーションパス。ただし、その基準点は次のいずれかとする。
ａｔｔｒｉｂｕｔｅ
ｎａｍｅｓｐａｃｅ
ｓｅｌｆ
ｐａｒｅｎｔ
ａｎｃｅｓｔｏｒ
ａｎｃｅｓｔｏｒ−ｏｒ−ｓｅｌｆ
・リテラル
・数
・関数呼び出し。ただし、次のものを除く。
ｌａｓｔ（）
ｉｄ（ｏｂｊｅｃｔ）
ルートノード及び要素ノードに対するｓｔｒｉｎｇ（ｏｂｊｅｃｔ？）
【００２４】
さて、ＸＰａｔｈにおいて、省略記法を用いないロケーションパスは、基準点とノードテストと述語の連接（ステップと呼ばれる）を記号／で区切って並べたもので表される。オートマトン生成部２１は、各ステップの評価状態をオートマトンで表現する。このオートマトンは、次のような状態遷移を行う。
図４は、オートマトン生成部２１にて生成されるオートマトンを模式的に示す図である。
まず、各ステップ（個数をＮとする）を左（先頭）から順番に番号付けし、所定のトークンが読み込まれた時点でステップＫが成立している状態をステートＫとする。ここで、ステップＫが成立している状態とは、ステップＫを満たすノードの開始タグトークンが読み込まれ、その終了タグがまだ読み込まれていない状態を表すものとする。また、初期状態はステート０で表すとする。
今、ステップＫを満たすノードの開始タグトークンが読み込まれ、現在の状態がステートＫになったとする。このステートＫの状態でステップＫ＋１を満たすノードが読み込まれた場合は、ステートＫ＋１に状態が移る。一方、ステートＫの状態でステップＫの終了タグが読み込まれた場合は、ステートＫ−１に状態が移る。このような状態遷移を繰り返し、ステートＮに到達すると、ロケーションパスが満たされたと判断される。
オートマトン生成部２１によって生成された上記のようなオートマトンは、例えば図１のメインメモリ１０３の作業領域に保持され、後述する評価実行部２３の処理において使用される。
【００２５】
ＸＭＬイベント転送部２２は、ＸＭＬパーサ１０から出力されたＸＭＬイベントを入力し、ＸＭＬ文書の木構造におけるノードごとに評価実行部２３へ順次転送する。また、当該ＸＭＬイベントをアプリケーション実行部３０へも順次転送する。
【００２６】
評価実行部２３は、オートマトン生成部２１にて生成されたオートマトンを取得し、ＸＭＬイベント転送部２２から転送されたＸＭＬイベントを受け取って、ＸＭＬ文書のトークン列を順次読み込みながらオートマトンにおける状態間の遷移を行う。そして、ロケーションパスを満たすノードに対応するトークンが読み込まれた時点でそのロケーションパスが満たされたと評価する。この評価結果は、評価イベントとしてアプリケーション実行部３０に送られる。評価実行部２３による具体的な評価処理の手順については後述する。
【００２７】
図２に示したアプリケーション実行部３０は、ＸＰａｔｈ評価部２０のＸＭＬイベント転送部２２から転送されるＸＭＬイベントと評価実行部２３から出力される評価イベントとを入力し、ストリーミング処理にてＸＭＬ文書に対する処理を実行する。
【００２８】
次に、本実施の形態のＸＰａｔｈ評価部２０による処理について、さらに詳細に説明する。
上述したように、本実施の形態では、まず評価対象であるＸＰａｔｈを表現するオートマトンを生成し保持しておく。そして、処理対象のＸＭＬ文書を構成するＸＭＬイベント列を順次入力し、このＸＭＬイベントに基づいて、オートマトンの状態を遷移させることにより、ＸＰａｔｈの部分的な評価を行う。ＸＰａｔｈの部分的な評価の結果は、オートマトンの状態として保持される。
ここでは簡単のために、ロケーションパスは、述語が無いものとし、基準点ではｃｈｉｌｄとｄｅｓｃｅｎｄａｎｔのみを考える。ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ、ｆｏｌｌｏｗｉｎｇ、ｓｅｌｆ、ｄｅｓｃｅｎｄａｎｔ−ｏｒ−ｓｅｌｆ、ａｔｔｒｉｂｕｔｅ、ｎａｍｅｓｐａｃｅを基準点とするステップや述語が存在するステップの取り扱いについては後述する。
【００２９】
図５は、本実施の形態による処理に用いられるロケーションパス、オートマトン及び処理対象のＸＭＬ文書の例を示す図である。
図５（Ａ）に示すロケーションパスが与えられ、このロケーションパスの各ステップを左からステップ１、ステップ２、ステップ３と呼ぶことにする。オートマトン生成部２１により、このロケーションパスから生成されるオートマトンの状態は、図５（Ｂ）に示すようになる。
今、図５（Ｃ）に示すＸＭＬ文書が入力されたとする。このＸＭＬ文書は、ＸＭＬパーサ１０にて構文解析され、ノードごとのＸＭＬイベントとしてＸＰａｔｈ評価部２０に送られ、ＸＭＬイベント転送部２２にて評価実行部２３に順次転送される。なお、図５（Ｃ）において、＜ｔｉｔｌｅ＞＜／ｔｉｔｌｅ＞のように要素内容がない場合は＜ｔｉｔｌｅ／＞と省略表記がなされている（以下、他のＸＭＬ文書についても同様）。
【００３０】
評価実行部２３は、オートマトン生成部２１にて生成された上記のオートマトンを用い、ＸＭＬイベント転送部２２から転送されたＸＭＬイベントに基づいて当該オートマトンの状態遷移を行って、当該オートマトンに対応するロケーションパスの評価を行う。なお、実際の処理において、オートマトンの状態の遷移及び評価は、ＸＭＬ文書の入れ子構造を解析するスタック（ＸＭＬイベント列用のスタック）を、例えば図１のメインメモリ１０３のメモリ空間に構築して行う。すなわち、評価実行部２３は、ＸＭＬパーサ１０から送られるＸＭＬイベント列を、このＸＭＬイベント列用スタックに順次保持していく。
このＸＭＬイベント列用スタックは、開始タグが読み込まれたことを条件に、そのタグに対応するノードをプッシュし、終了タグが読み込まれたことを条件に、当該ノードをポップする。また、スタックのボトム（bottom）はルートノードを表すものとする。
【００３１】
したがって、評価実行部２３は、ＸＭＬイベント列の入力に応じて、ＸＭＬイベント列用スタックへのプッシュとポップを順次行っていく。この操作は、ロケーションパスが相対であるか絶対であるかに関わらず、ＸＭＬ文書の開始から終了まで一貫して行われる。この操作中、所定の開始タグが読み込まれ、そのタグに対応するノードがＸＭＬイベント列用スタックにプッシュされた場合はいつでも、当該ノードが（現在の状態をステートＫとして）ステートＫ＋１に対応するステップ（すなわちステップＫ＋１）を満たしているかどうかを判定する。この判定結果が真であった場合、現在の状態をステートＫ＋１とする。このとき、スタック要素とステートの対応付けをしておく。つまり、プッシュされたノードとそのノードによって成立したステートとのマッピングを構成する。ここで、ステート０に対しては、ロケーションパスが相対パスである場合にはコンテクストノードに対応したスタック要素が対応付けられる。またロケーションパスが絶対パスである場合はスタックのボトム（すなわちルートノード）が対応付けられるものとする。一方、ＸＭＬイベント列用スタックからのポップが行われた場合、ポップされたエレメントがステートに対応付けされているかどうかを検出し、対応付けされていたならば、状態を１つ前に戻す。
【００３２】
以下、図５を参照し、順を追って説明する。
まず、初期状態はステート０であり、トークン＜ｄｏｃｕｍｅｎｔ＞が読み込まれ、ノードｄｏｃｕｍｅｎｔがプッシュされる。このときのＸＭＬイベント列用スタックの状態は、
ｂｏｔｔｏｍ ｜ ｄｏｃｕｍｅｎｔ
となる。このノードｄｏｃｕｍｅｎｔは、ステップ１を満たすので、ステート０からステート１へ状態遷移が行われる。
【００３３】
次に、トークン＜ｔｉｔｌｅ＞が読み込まれ、ノードｔｉｔｌｅがプッシュされる。このときのＸＭＬイベント列用スタックの状態は、
ｂｏｔｔｏｍ ｜ ｄｏｃｕｍｅｎｔ ｜ ｔｉｔｌｅ
となる。このノードｔｉｔｌｅは、ステート１に対応付けられたノードｄｏｃｕｍｅｎｔのｃｈｉｌｄ：：ｃｈａｐｔｅｒという条件を満たさない。すなわち、ステップ２を満たさないので、状態遷移は行われず、そのままトークンの読み込みが続けられる。
【００３４】
ノードｔｉｔｌｅの終了タグであるトークン＜／ｔｉｔｌｅ＞が読み込まれてノードｔｉｔｌｅがポップされた後、続いてトークン＜ｃｈａｐｔｅｒ＞が読み込まれ、ノードｃｈａｐｔｅｒがプッシュされる。このノードはステップ２を満たすので、ステート１からステート２へ状態遷移が行われる。このときのＸＭＬイベント列用スタックは、
ｂｏｔｔｏｍ ｜ ｄｏｃｕｍｅｎｔ ｜ ｃｈａｐｔｅｒ
となる。次に、トークン＜／ｃｈａｐｔｅｒ＞が読み込まれ、ノードｃｈａｐｔｅｒのポップが行われる。このとき、ポップされるスタック要素には、ステート２が対応付けられている。したがってこの場合は、ポップと共に、オートマトンの状態が、ステート２からその１つ前の状態であるステート１へ遷移される。
【００３５】
この後、再びトークン＜ｃｈａｐｔｅｒ＞が読み込まれ、ノードｃｈａｐｔｅｒがプッシュされて、ステート１からステート２へ状態遷移が行われる。そしてさらに、トークン＜ｓｅｃｔｉｏｎ＞が読み込まれ、ノードｓｅｃｔｉｏｎがプッシュされると、このノードはステップ３を満たすので、ステート２からステート３へ状態遷移が行われる。この時点で評価実行部２３は、ロケーションパスが成立したと判断し、評価結果を示す評価イベントをアプリケーション実行部３０へ送信する。
なお、以上の説明では、評価実行部２３はロケーションパスが成立した場合に評価イベントを出力することとしたが、ＸＭＬイベントを１つ処理する度に成立または不成立を示す評価イベントを出力するようにしても良い。
【００３６】
次に、他のフォワード基準点（axis）の取り扱いについて説明する。
１．ａｔｔｒｉｂｕｔｅ、ｎａｍｅｓｐａｃｅの取り扱い。
基準点がａｔｔｒｉｂｕｔｅであるステップが含まれるロケーションパスを評価するには、状態遷移した際に、遷移後の状態の１つ先の状態に対応するステップを検出する。そして、そのステップがａｔｔｒｉｂｕｔｅであれば、最後に入力されたトークンの属性を用いて、当該ステップの評価を行う。この評価でノードがステップを満足した場合は、状態を１つ進める。一方、ノードがステップを満足しなかった場合は、元々の状態遷移をキャンセルする。
ｎａｍｅｓｐａｃｅに関しては、現在のコンテクストにおけるｎａｍｅｓｐａｃｅを管理しておき、ステップの評価をａｔｔｒｉｂｕｔｅの場合と同様に実行する。
なお、ａｔｔｒｉｂｕｔｅ及びｎａｍｅｓｐａｃｅに関しては、これらが成立する過程では、ＸＭＬイベント列用スタックの操作は行われない。したがって、それらの状態と対応付けられるノードは何もないことを表すＮＵＬＬノードとしておく。
【００３７】
２．ｓｅｌｆの取り扱い。
基準点がｓｅｌｆであるステップが含まれるロケーションパスを評価するには、状態遷移した際に、遷移後の状態の１つ先の状態に対応するステップを検出する。そして、そのステップがｓｅｌｆであれば、当該ステップの評価を行う。この評価でノードがステップを満足した場合は、状態を１つ進め、その先の状態に対して同じ操作を繰り返す。一方、ノードがステップを満足しなかった場合は、元々の状態遷移をキャンセルする。ｓｅｌｆが成立する過程では、ＸＭＬイベント列用スタックの操作は行われない。したがって、それらの状態と対応付けられるノードは何もないことを表すＮＵＬＬノードとしておく。
【００３８】
３．ｄｅｓｃｅｎｄａｎｔ−ｏｒ−ｓｅｌｆの取り扱い。
基準点がｄｅｓｃｅｎｄａｎｔ−ｏｒ−ｓｅｌｆであるステップが含まれるロケーションパスを評価するには、まず、そのステップの基準点がｓｅｌｆであるとみなして、上記２．の操作を行う。この操作においてステップを満足しないと判断された場合、その基準点がｄｅｓｃｅｎｄａｎｔであるとみなして評価を続行する。
【００３９】
４．ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇの取り扱い。
基準点がｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇであるステップが含まれるロケーションパスを評価するには、以下の操作を行う。
まず、ある基準点がｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇであるステップをステップＫとし、それに対応した状態をステートＫとする。基本的には、ステップＫ−１の成立時にプッシュされたノードがポップされたときのスタックトップノードに対し、そのノードに続いてプッシュされるノードがステップＫで選択するべきノードとなる。ただし、ここで注意しなければならないのは、このステップＫを満足したノードは、ステップＫで選択されるノードの候補であると同時にステップＫ−１で選択されるノードの候補でもあるということである。例えば、ロケーションパスが、
/child::document/child::chapter/following-sibling::chapter
であった場合、以下の２番目のｃｈａｐｔｅｒは、２番目のステップと、３番目のステップの両方で選択される可能性がある。
＜ｄｏｃｕｍｅｎｔ＞
＜ｃｈａｐｔｅｒ＞−−１
＜／ｃｈａｐｔｅｒ＞
＜ｃｈａｐｔｅｒ＞−−２
＜／ｃｈａｐｔｅｒ＞
＜ｃｈａｐｔｅｒ＞−−３
＜／ｃｈａｐｔｅｒ＞
＜／ｄｏｃｕｍｅｎｔ＞
このような両義性は、ｐｏｓｉｔｉｏｎに依存したノード選択を行うときは厳密な解釈が必要である。例えば、以下のロケーションパス
/child::document/child::chapter/following-sibling::chapter[1]
では、２番目と３番目のｃｈａｐｔｅｒを共に選択しなければならない。また、以下のロケーションパス
/child::document/child::chapter[2]/following-sibling::chapter
では、３番目のｃｈａｐｔｅｒを選択しなければならない。
【００４０】
そこで、本実施の形態では、ノードがステップＫ−１を満足すると判断された時点でプロセスを２つに分割し、それぞれのプロセスが２通りのロケーションパスの解釈に対応した状態遷移を続行するように処理を行う。１つのプロセスは、この時点で当該ノードと対応付けられた状態の１つ前の状態に遷移し（通常はステートＫ−２、ｓｅｌｆが含まれる場合はさらにその前の状態）、以降の評価を続行する。
もう１つのプロセスでは、次の操作を行う。まず、状態はステートＫ−１のままとする。ステートＫ−１の状態において、ノードがステップＫ−１を満足すると判断されてプッシュされたノードがポップされたときのスタックトップノードがスタックトップである間に何らかのノードがプッシュされた場合は、当該ノードがステップＫステップＫを満足するかどうかを判定する。満足するならば、状態をステートＫに遷移し、プッシュされたノードとステートＫとを対応付けて、これ以降の評価を続行する。また、ステートＫに対応付けられたノードがポップされたときは、状態をステートＫ−１に戻す。ステートＫ−１の状態において、ステップＫ−１を満足したノードの終了タグトークンが入力された場合、すなわちノードがステップＫ−１を満足すると判断されてプッシュされたノードがポップされたときのスタックトップノードがポップされた場合は、このプロセスにおいてステップＫで選択されるノードがこれ以上存在しないので操作を終了する。
【００４１】
５．ｆｏｌｌｏｗｉｎｇの取り扱い。
基準点がｆｏｌｌｏｗｉｎｇであるステップが含まれるロケーションパスを評価するには、以下の操作を行う。
この場合もロケーションパスに曖昧さが生じる可能性があるため、ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇの場合と同じ様なプロセスの分割が必要となる。まず、ある基準点がｆｏｌｌｏｗｉｎｇであるステップをステップＫとし、それに対応した状態をステートＫとする。上記４．の処理と同様に、ノードがステップＫ−１を満足すると判断された時点でプロセスを２つに分割する。１つのプロセスは、この時点で当該ノードと対応付けられた状態の１つ前の状態に遷移し、以降の評価を続行する。
もう１つのプロセスでは、次の操作を行う。まず、状態はステートＫ−１のままとする。ステートＫ−１の状態において、何らかのノードがプッシュされた場合は、ステップＫを満足するかどうかを判定する。満足するならば、状態をステートＫに遷移し、プッシュされたノードとステートＫとを対応付けて、これ以降の評価を続行する。ｆｏｌｌｏｗｉｎｇの場合は、ステートＫ−１の状態において、ステップＫ−１を満足したノードの終了タグトークンが入力されても、状態をステートＫのままにする。
【００４２】
次に、述語（predicate）の取り扱いについて説明する。
述語は、基本的には、状態遷移の瞬間にスタックに蓄積された情報から構成できるものについて取り扱うことができる。つまり、ステップＫを満たす開始タグトークンが読み込まれた場合、その状態で構成できる当該ノードについての情報、及びスタックに残っている当該ノードのａｎｃｅｓｔｏｒについての情報を述語に記述することができる。また、各ステートについてカウンタを設けることで、ポジション関数を取り扱うことが可能となる。これまで説明してきたようなステップの成立状態において、そのステップに対応したステートのカウンタを１つ増やす。このカウンタの値に基づいてポジション関数を含む述語を評価し、最終的にノードがステップを満足するか否かを判定する。
【００４３】
次に、リバース基準点の取り扱いについて説明する。
本実施の形態では、非常に限定されたロケーションパスにおいて、ｐａｒｅｎｔ、ａｎｃｅｓｔｏｒ、ａｎｃｅｓｔｏｒ−ｏｒ−ｓｅｌｆといったリバース基準点を使用することができる。上記述語の取り扱いで述べたように、現在のノードのａｎｃｅｓｔｏｒについての情報はオートマトンの状態として蓄積されている。したがって、ロケーションパスのある地点から右側のステップが全て、ｐａｒｅｎｔ、ａｎｃｅｓｔｏｒ、ａｎｃｅｓｔｏｒ−ｏｒ−ｓｅｌｆ、あるいはｓｅｌｆである場合は、その地点でスタックの操作を一旦停止し、スタックを遡りながら、それらのステップを評価していけば良い。
【００４４】
図６は、本実施の形態によるＸＭＬ文書のストリーミング処理を説明するフローチャートである。
図６に示すように、ＸＰａｔｈ評価部２０は、初期動作として、オートマトン生成部２１により、予め与えられたＸＰａｔｈのロケーションパスからオートマトンを生成しておく（Ｓｔｅｐ６０１）。処理対象であるＸＭＬ文書が入力され、ＸＭＬパーサ１０からＸＭＬイベントが送られると（Ｓｔｅｐ６０２）、ＸＰａｔｈ評価部２０の評価実行部２３により、上記のようにして、当該ＸＭＬイベントに対する先のオートマトンにおける状態遷移が順次判断される（Ｓｔｅｐ６０３）。この状態遷移が当該オートマトンに対応するロケーションパス（ＸＰａｔｈ）の部分的な評価を意味している。この部分的な評価の結果は、オートマトンの現在の状態として保持される。
そして、このオートマトンの最後の状態に達するまでＸＭＬイベントの入力及び状態遷移の判断を繰り返し、最後の状態に達したならば、このＸＭＬ文書に対してロケーションパスが成立したと評価され、評価イベントがアプリケーション実行部３０へ送られる（Ｓｔｅｐ６０４、６０５）。
アプリケーション実行部３０は、ＸＭＬパーサ１０から出力されたＸＭＬイベントと、ＸＰａｔｈ評価部２０の評価実行部２３から出力された評価イベントとを取得し、当該評価イベントに応じて当該ＸＭＬイベントを順次処理していく。処理対象のＸＭＬ文書についてＸＭＬパーサ１０から送られる全てのＸＭＬイベントに対して、Ｓｔｅｐ６０２〜６０５の処理を実行した後、本実施の形態によるＸＭＬ文書のストリーミング処理を終了する（Ｓｔｅｐ６０６）。
【００４５】
〔実施の形態２〕
実施の形態２では、実施の形態１で説明したオートマトンの状態遷移を用いた処理に相当するＸＰａｔｈの評価を、ＸＭＬ文書の入れ子構造を解析するスタックを用いて実現する。すなわち本実施の形態は、ＸＰａｔｈ及びＸＭＬイベント列を共にスタックで表現し、ＸＭＬイベントが通知される度にそれらを比較するという方法で実装される。
【００４６】
本実施の形態は、実施の形態１と同様に、例えば図１に示した情報処理装置にて実現される。
図７は、本実施の形態におけるＸＰａｔｈ評価手段（解析システム）の実装例を示す図である。
図７に示すように、本実施の形態による情報処理装置は、処理対象であるＸＭＬ文書の構文解析（パース）を行うＸＭＬパーサ１０と、構文解析されたＸＭＬ文書に対してＸＰａｔｈの評価を行うＸＰａｔｈ評価部４０と、ＸＰａｔｈの評価を経たＸＭＬ文書を用いて所定の情報処理を実行するアプリケーション実行部３０とを備える。
図７に示すＸＭＬパーサ１０、ＸＰａｔｈ評価部４０及びアプリケーション実行部３０は、例えば、図１に示したメインメモリ１０３に展開されたプログラムにてＣＰＵ１０１を制御することにより実現される仮想的なソフトウェアブロックである。なお、ＸＭＬパーサ１０及びアプリケーション実行部３０は、実施の形態１における対応する構成要素と同様であるため、同一の符号を付して説明を省略する。
【００４７】
ＸＰａｔｈ評価部４０は、ＸＭＬパーサ１０からＸＭＬイベントを受け取り、予め与えられたＸＰａｔｈの評価を行う。
図８は、ＸＰａｔｈ評価部４０の機能構成を説明する図である。
図８に示すように、本実施の形態のＸＰａｔｈ評価部４０は、スタック生成部４１と、ＸＭＬイベント転送部４２と、評価実行部４３とを備える。
【００４８】
スタック生成部４１は、予め与えられたＸＰａｔｈから、当該ＸＰａｔｈのステップを表現するデータ構造であるスタックを生成する。ＸＰａｔｈからのスタックの生成は、次のようにして行われる。
すなわち、スタック生成部４１は、ＸＰａｔｈの各ステップに対して、ノードテストと述語とをスタック要素で表現し、基準点に応じてスタックにプッシュする。例えば、ｃｈｉｌｄ：：ｐａｒａに対してはｐａｒａをスタック要素で表現し、既存のスタックにプッシュする。ここで、ノードテストと述語とは、ＸＭＬイベント列に対してそれらを適切に評価できる限り、どのようなスタック要素で表現してもよい。ただし、述語ｐｏｓｉｔｉｏｎ（）を含むときは、スタックが一致した回数を保持するためのカウンタを用意する。
【００４９】
図９は、基準点の種類と作成されるスタックとの関係を例示する図である。
また図９において、矢印（直線矢印と波線矢印）は共に、まず元のスタックを比較し、一致すれば先のスタックを比較することを表す。具体的には、直線矢印は、まず元のスタックを比較し、一致したならば、続けて先のスタックを比較することを表す。一方、波線矢印は、まず元のスタックを比較し、一致したならば、その後に特定のＸＭＬイベントが通知された場合に限り、先のスタックを比較することを表す。この場合の特定のＸＭＬイベントとは、基準点の種類（ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇかｆｏｌｌｏｗｉｎｇかの別）に応じて異なる。
・ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇの場合
元のスタックにおける先頭のスタック要素と一致したノード以降の兄弟ノードとその子孫ノードに対応するＸＭＬイベント。兄弟ノードに対応するＸＭＬイベントに対応するスタック要素を基準として、先のスタックを比較する。
・ｆｏｌｌｏｗｉｎｇの場合
元のスタックの先頭のスタック要素と一致したノード以降のノードに対応するＸＭＬイベント。ただし、その子孫ノードに対応するＸＭＬイベントを除く。そのようなノードの各々に対応するＸＭＬイベントに対応するスタック要素を基準として、先のスタックを比較する。
【００５０】
図１０は、図９に示した関係に基づいて、ＸＰａｔｈから生成されるスタックを示す図である。
（１）ｃｈａｐｔｅｒ／ｐａｒａ、
（２）ｃｈａｐｔｅｒ／ｐａｒａ［＠ｔｙｐｅ＝”ｗａｒｎｉｎｇ”］、
（３）ｃｈａｐｔｅｒ／ｐａｒａ［２］、
（４） ．／／ｐａｒａ
の各ＸＰａｔｈから図１０に示したスタックがそれぞれ生成される。なお、上記及び図１０において、ｃｈｉｌｄ基準点はＸＰａｔｈの表記規則に基づいて既述が省略されている。
スタック生成部４１によって、以上のようにして生成されたスタックは、例えば図１のメインメモリ１０３の作業領域に保持され、後述する評価実行部４３の処理において使用される。
なお、本実施の形態では、ＸＰａｔｈの機能に対して、実施の形態１の場合と同様の制限が課される。
【００５１】
ＸＭＬイベント転送部４２は、ＸＭＬパーサ１０から出力されたＸＭＬイベントを入力し、ＸＭＬ文書の木構造におけるノードごとに評価実行部４３へ順次転送する。また、当該ＸＭＬイベントをアプリケーション実行部３０へも順次転送する。
【００５２】
評価実行部４３は、スタック生成部４１にて生成されたスタックを取得し、ＸＭＬイベント転送部４２から転送されたＸＭＬイベントを受け取って、ＸＭＬ文書のトークン列を順次読み込みながらスタックを操作する。そして、ＸＰａｔｈを満たすノードに対応するトークンが読み込まれた時点でそのＸＰａｔｈが満たされたと評価する。この評価結果は、評価イベントとしてアプリケーション実行部３０に送られる。
【００５３】
本実施の形態では、上記のスタックを用いたＸＰａｔｈの評価を実現するためのデータ構造として、実施の形態１の場合と同様に、ＸＭＬ文書の入れ子構造を解析するスタック（ＸＭＬイベント列用のスタック）を導入する。すなわち、評価実行部４３は、スタック生成部４１で作成される上記のＸＰａｔｈ用のスタックとは別に、ＸＭＬイベント列用のスタックを用意し、ＸＭＬパーサ１０から送られるＸＭＬイベント列を保持する。このＸＭＬイベント列用のスタックに関しては、原則として、開始タグに対応するＸＭＬイベントを入力したならば、それをスタック要素で表現し、スタックにプッシュする。そして、終了タグに対応するＸＭＬイベントを入力したならば、スタックをポップする。また、テキスト等に対応するＸＭＬイベントを入力したならば、このＸＭＬイベントもスタック要素で表現しスタックにプッシュするが、スタックの比較が終了した後、即座に当該スタックをポップする。ここで、ＸＭＬイベントは、そのイベントが保持する情報を保持する限り、どのようなスタック要素で表現しても良い。
【００５４】
さらに評価実行部４３は、ＸＭＬイベント転送部４２からＸＭＬイベントが転送される度に、ＸＭＬ文書中の着目しているノードのＸＭＬイベントに対応するスタック要素を基準として、ＸＭＬイベント列用のスタックとＸＰａｔｈ用のスタックとを比較することにより、ＸＰａｔｈの評価を行う。ここで、スタックを比較するとは、対応するスタック要素を比較することである。また、スタック要素を比較するとは、対応するＸＭＬイベント（及びそれ以前に通知されたＸＭＬイベント）に対して、対応するノードテストと述語とを評価することである。
【００５５】
スタックの比較は、原則として、最後のスタック要素から行う。一致しないスタック要素を検出したならば、直ちに比較処理を終了する。また、毎回全てのスタック要素を比較しても良いし、比較において一致しなかったスタック要素の位置を保持しておき、次回の比較処理では当該一致しなかったスタック要素から後を比較するようにしても良い。
スタックが一致したならば、これは、最後に通知されたイベントに対応するノードに対してＸＰａｔｈがマッチしたことを意味する。ただし、ＸＰａｔｈ用のスタックにカウンタが用意されているときは、スタックが一致する度にＸＭＬイベント列用のスタックにおける対応スタック要素のカウント値をインクリメントし、ＸＰａｔｈ用のスタックのカウント値と一致したときに限り、ＸＰａｔｈがマッチしたと判断する。
【００５６】
以上のように、本実施の形態では、評価対象であるＸＰａｔｈをスタック要素の列で表現したＸＰａｔｈ用スタック（第１のスタック）を生成し、さらに処理対象であるＸＭＬ文書を構成するＸＭＬイベント列を入力して入力された個々のＸＭＬイベントに基づいて処理対象のＸＭＬ文書の入れ子構造を解析するＸＭＬイベント列用スタック（第２のスタック）を生成する。そして、第１のスタックと当該第２のスタックとを比較することにより、ＸＰａｔｈの部分的な評価を行う。ＸＰａｔｈの部分的な評価の結果は、ＸＭＬイベント列用スタックのスタック要素として保持される。
また、上述したように、ＸＭＬイベント列用スタックの操作は、実施の形態１で説明したＸＭＬイベント列用スタックの操作と同様である。したがって、このＸＭＬイベント列用スタックの操作及び比較が実施の形態１で説明したオートマトンの状態遷移に相当している。ただし、実施の形態２では、スタックに蓄積されたデータのマッチングのみでＸＰａｔｈの評価が実行されるので、実装が容易である。
【００５７】
次に、本実施の形態のＸＰａｔｈ評価部４０による処理について、さらに詳細に説明する。
図１１は、処理対象であるＸＭＬ文書の例を示す図、図１２乃至図１４は、図１１のＸＭＬ文書に対するスタックを用いた評価処理の様子を示す図である。なお、図１１では、各タグに関して、ｄｏｃｕｍｅｎｔをｄｏｃとするなど、適宜、省略表記がなされている（以下、他のＸＭＬ文書についても同様）。
ＸＰａｔｈとして図１０の（３）に示した
ｃｈａｐｔｅｒ／ｐａｒａ［２］
が与えられたものとする。すなわち、所定のＸＭＬ文書のイベント列に対して、ノードｃｈａｐｔｅｒの下位に位置する２つ目のノードｐａｒａが検出されたときに、このＸＰａｔｈの成立という評価がなされる。このＸＰａｔｈに対してスタック生成部４１にて生成されるスタックは図１０に示したとおりである。
【００５８】
図１２乃至図１４には、図１１のＸＭＬ文書に対するＳＡＸイベント列（ＸＭＬイベント列）と、各ＳＡＸイベント列を入力した際の評価実行部４３による比較の様子が順番に示されている。
最初に、ドキュメント開始を示すＳＡＸイベントstartDocumentが入力され、スタックの比較が開始される（図１２（Ａ））。この時点では、ＸＭＬイベント列用スタックのスタック要素は空（ＮＵＬＬ）である。次に、要素（ノード）の開始を示すＳＡＸイベントstartElement: docが入力され（図１２（Ｂ））、さらにトークン（ＳＡＸイベント）の読み込みが続けられる。
【００５９】
次に、要素の開始を示すＳＡＸイベントstartElement: chapterが入力され、ＸＭＬイベント列用スタックがプッシュされてＸＰａｔｈ用スタックと比較される（図１２（Ｃ））。このスタック要素は一致するが、この時点ではスタック要素ｐａｒａが一致していないので、トークン（ＳＡＸイベント）の読み込みが続けられる。続いて、ＳＡＸイベントstartElement: paraが入力され、ＸＭＬイベント列用スタックがプッシュされてＸＰａｔｈ用スタックと比較される（図１３（Ａ））。このスタック要素は一致するが、図１１のＸＭＬ文書で最初に現れたノードｐａｒａであるので、ポジション関数（ｐｏｓ＝２）を扱うためのカウンタの値（ｃｕｒｒｅｎｔ＿ｐｏｓ）が１インクリメントされ、トークン（ＳＡＸイベント）の読み込みが続けられる。
【００６０】
以後、要素の終了を示すＳＡＸイベントendElement: para、endElement: chapterが入力されてＸＭＬイベント列用スタックの対応するスタック要素がそれぞれポップされ（図１３（Ｂ）（Ｃ））、次に再びＳＡＸイベントstartElement: chapterが入力されてＸＭＬイベント列用スタックがプッシュされ、ＸＰａｔｈ用スタックと比較される（図１４（Ａ））。このスタック要素は一致し、続いてＳＡＸイベントstartElement: paraが入力され、ＸＭＬイベント列用スタックがプッシュされてＸＰａｔｈ用スタックと比較される（図１４（Ｂ））。このスタック要素は一致し、カウンタの値が１インクリメントされると、ｃｕｒｒｅｎｔ＿ｐｏｓ＝２となって、ポジション関数の要求を満たすので、図１１のＸＭＬ文書に対してＸＰａｔｈ“ｃｈａｐｔｅｒ／ｐａｒａ［２］”が成立したと評価される。
【００６１】
さて、上記の説明で、ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ及びｆｏｌｌｏｗｉｎｇに関しては、ノードはステップＫで選択されるノードの候補であると同時にステップＫ−１で選択されるノードの候補でもあるため、本実施の形態では、ステップＫ−１が成立したときにプッシュされたノードがポップされた時点でプロセスを２つに分割し、それぞれのプロセスが２通りのロケーションパスの解釈に対応したスタック操作を続行することとした。この動作について、具体例を挙げて詳細に説明する。
図１５は、処理対象であるＸＭＬ文書の例を示す図、図１６は評価対象であるＸＰａｔｈとこのＸＰａｔｈから生成されるスタックとを示す図、図１７乃至図１９は、図１５のＸＭＬ文書に対するスタックを用いた評価処理の様子を示す図である。
【００６２】
図１６に示すように、ＸＰａｔｈとして
ｃｈａｐ／ｐａｒａ［＠ｎｕｍ＝“２”］／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：ｐａｒａ
が与えられたものとする。すなわち、所定のＸＭＬ文書のイベント列に対して、ノードｃｈａｐｔｅｒの下位に位置するノードｐａｒａ ｎｕｍ＝“２”に後続する兄弟ノードｐａｒａが検出されたときに、このＸＰａｔｈの成立という評価がなされる。
【００６３】
図１７乃至図１９には、図１５のＸＭＬ文書に対するＳＡＸイベント列（ＸＭＬイベント列）と、各ＳＡＸイベント列を入力した際の評価実行部４３による比較の様子が順番に示されている。
まずドキュメント開始を示すＳＡＸイベントstartDocument、続いて要素の開始を示すＳＡＸイベントstartElement: docが入力され（図１７（Ａ）（Ｂ））、さらにトークン（ＳＡＸイベント）の読み込みが続けられる。次に、要素の開始を示すＳＡＸイベントstartElement: chapterが入力され、ＸＭＬイベント列用スタックがプッシュされてＸＰａｔｈ用スタックと比較されるが（図１７（Ｃ））、スタック要素ｐａｒａが一致していないので、トークン（ＳＡＸイベント）の読み込みが続けられる。
【００６４】
次に、ＳＡＸイベントstartElement: para,@num=1が入力され、ＸＭＬイベント列用スタックがプッシュされてＸＰａｔｈ用スタックと比較される（図１８（Ａ））。このスタック要素はＸＰａｔｈ用スタックの対応するスタック要素（ｐａｒａ＠ｎｕｍ＝２）とは一致せず、引き続きトークン（ＳＡＸイベント）の読み込みが行われる。続いて、要素の終了を示すＳＡＸイベントendElement: paraが入力され、ＸＭＬイベント列用スタックの対応するスタック要素がそれぞれポップされた後（図１８（Ｂ））、ＳＡＸイベントstartElement: para,@num=2が入力され、ＸＭＬイベント列用スタックがプッシュされてＸＰａｔｈ用スタックと比較される（図１８（Ｃ））。このスタック要素はＸＰａｔｈ用スタックの対応するスタック要素と一致する。したがって、これ以降は図１６に示したＸＰａｔｈ用スタックの後半（スタック要素ｐａｒａ）との比較を行う。
【００６５】
次に、ＳＡＸイベントendElement: paraが入力され、ＸＭＬイベント列用スタックの対応するスタック要素がそれぞれポップされた後（図１９（Ａ））、ＳＡＸイベントstartElement: para,@num=3が入力され、ＸＭＬイベント列用スタックがプッシュされてＸＰａｔｈ用スタックと比較される（図１９（Ｂ））。このスタック要素はＸＰａｔｈ用スタックの後半（スタック要素ｐａｒａ）に一致するので、図１５のＸＭＬ文書に対してＸＰａｔｈ“ｃｈａｐ／ｐａｒａ［＠ｎｕｍ＝“２”］／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：ｐａｒａ”が成立したと評価される。
【００６６】
図２０は、本実施の形態によるＸＭＬ文書のストリーミング処理を説明するフローチャートである。
図６に示すように、ＸＰａｔｈ評価部４０は、初期動作として、スタック生成部４１により、予め与えられたＸＰａｔｈのロケーションパスからＸＰａｔｈ用スタックを生成しておく（Ｓｔｅｐ２００１）。処理対象であるＸＭＬ文書が入力され、ＸＭＬパーサ１０からＸＭＬイベントが送られると（Ｓｔｅｐ２００２）、ＸＰａｔｈ評価部４０の評価実行部４３により、上記のようにして、当該ＸＭＬイベント用スタックが生成され、ＸＰａｔｈ用スタックとの比較が順次判断される（Ｓｔｅｐ２００３）。この比較結果が当該ＸＰａｔｈ用スタックにて表現されたＸＰａｔｈの部分的な評価を意味している。
そして、このＸＭＬイベント列用スタックとＸＰａｔｈ用スタックとが全て一致するまでＸＭＬイベントの入力及びスタックの比較を繰り返し、完全に一致したならば、このＸＭＬ文書に対してロケーションパスが成立したと評価され、評価イベントがアプリケーション実行部３０へ送られる（Ｓｔｅｐ２００４、２００５）。
アプリケーション実行部３０は、ＸＭＬパーサ１０から出力されたＸＭＬイベントと、ＸＰａｔｈ評価部４０の評価実行部４３から出力された評価イベントとを取得し、当該評価イベントに応じて当該ＸＭＬイベントを順次処理していく。
処理対象のＸＭＬ文書についてＸＭＬパーサ１０から送られる全てのＸＭＬイベントに対して、Ｓｔｅｐ２００２〜２００５の処理を実行した後、本実施の形態によるＸＭＬ文書のストリーミング処理を終了する（Ｓｔｅｐ２００６）。
【００６７】
〔実施の形態３〕
実施の形態３では、ストリーミング形式でＸＭＬイベント列を入力しながら当該ＸＭＬ文書に対する木（文書木：ドキュメントツリー）を順次作成していき、この文書木の作成に伴って逐次的にＸＰａｔｈの評価を行う。
上述したように、実施の形態１では、評価対象であるＸＰａｔｈからオートマトンを生成し、ストリーミング形式で入力されるＸＭＬイベント列によって当該オートマトンの状態遷移を順次行うことによってＸＰａｔｈの評価を行った。また実施の形態２では、ＸＰａｔｈのステップを第１のスタックで表現し、ストリーミング形式で入力されるＸＭＬ文書の入れ子構造を第２のスタックで表現し、これらのスタックの内容を比較することによってＸＰａｔｈの評価を行った。これらの手法は、いずれもＸＭＬイベント列のうち評価の済んだ部分については情報を喪失してしまうため、リバース基準点に関しては、非常に限定された条件下でのみ評価が可能であった。
これに対し、本実施の形態では、ＸＭＬイベント列の入力に伴って文書木を生成していくので、所定のＸＭＬイベントを入力した際に、それ以前のＸＭＬイベント列に関する情報が全て木構造として保持される。したがって、リバース基準点のステップが含まれるＸＰａｔｈに対しても何ら問題なく評価を行うことができる。
【００６８】
本実施の形態は、実施の形態１と同様に、例えば図１に示した情報処理装置にて実現される。
図２１は、本実施の形態におけるＸＰａｔｈ評価手段（解析システム）の実装例を示す図である。
図２１に示すように、本実施の形態による情報処理装置は、処理対象であるＸＭＬ文書の構文解析（パース）を行うＸＭＬパーサ１０と、構文解析されたＸＭＬ文書に対してＸＰａｔｈの評価を行うＸＰａｔｈ評価部５０と、ＸＰａｔｈの評価を経たＸＭＬ文書を用いて所定の情報処理を実行するアプリケーション実行部３０とを備える。
図２１に示すＸＭＬパーサ１０、ＸＰａｔｈ評価部５０及びアプリケーション実行部３０は、例えば、図１に示したメインメモリ１０３に展開されたプログラムにてＣＰＵ１０１を制御することにより実現される仮想的なソフトウェアブロックである。なお、ＸＭＬパーサ１０及びアプリケーション実行部３０は、実施の形態１における対応する構成要素と同様であるため、同一の符号を付して説明を省略する。
【００６９】
ＸＰａｔｈ評価部５０は、ＸＭＬパーサ１０からＸＭＬイベントを受け取り、予め与えられたＸＰａｔｈの評価を行う。
図２２は、ＸＰａｔｈ評価部５０の機能構成を説明する図である。
図２２に示すように、本実施の形態のＸＰａｔｈ評価部５０は、ＸＰａｔｈ格納部５１と、ＸＭＬイベント転送部５２と、文書木生成部５３と、評価実行部５４とを備える。
【００７０】
ＸＰａｔｈ格納部５１は、例えば図１に示したコンピュータ装置のメインメモリ１０３で実現され、予め与えられたＸＰａｔｈを保持する。ＸＭＬイベント転送部５２は、ＸＭＬパーサ１０から出力されたＸＭＬイベントを入力し、ＸＭＬ文書の木構造におけるノードごとに文書木生成部５３へ順次転送する。また、当該ＸＭＬイベントをアプリケーション実行部３０へも順次転送する。
【００７１】
文書木生成部５３は、ＸＭＬイベント転送部５２から転送されたＸＭＬイベントを受け取って、そのＸＭＬイベントまでの文書木を生成する。この文書木は、取得したＸＭＬイベントまでの構造を反映しているので、処理対象であるＸＭＬ文書全体の構造を表す文書木に対する部分木となる。また、ＸＭＬイベント列を最後まで取得した際に生成される文書木は、当該ＸＭＬ文書全体の文書木と同一となる。
文書木の生成は、ＸＭＬイベントとして当該ＸＭＬ文書の要素に対する開始タグトークンが入力されたときに新たにノードを追加することにより行われる。そして、開始タグトークンの入力によりノードを追加した場合、それ以降の挿入位置を当該ノードとする。また、当該要素に対する終了タグトークンが入力された場合、当該ノードの親ノードをそれ以降の挿入位置とする。したがって、この文書木は、文書木生成部５３がＸＭＬイベントを入力する度に更新されることとなる。
文書木生成部５３により生成（更新）された文書木は、例えば図１のメインメモリ１０３の作業領域に保持され、後述する評価実行部５４の処理において使用される。
【００７２】
評価実行部５４は、文書木生成部５３により上記の文書木が更新されると、当該文書木を用いて、ＸＰａｔｈ格納部５１に保持されているＸＰａｔｈの評価を行う。本実施の形態の評価実行部５４は、ＸＰａｔｈを評価して成立したステップに関して、当該ステップにおいて選択された文書木のノードの情報、すなわちＸＰａｔｈにおける部分的な評価結果の情報を保存する。この情報は、各ステップのステップＩＤとノードＩＤとの組（タプル）の集合｛＜ｓｉｄ１，ｎｉｄ１＞，＜ｓｉｄ１，ｎｉｄ２＞，・・・｝として表される。これを保存集合と呼ぶ。生成された保存集合は、例えば図１のメインメモリ１０３の作業領域に保持される。
保存集合において各ステップは、１番から順に番号付けされているとする。ここで、０番目のステップは特別なステップとし、このステップに対応させてルートノードを常に保存しておく。評価実行部５４の評価により選択された各ノードは、当該ノードをコンテクストノードとして、それ以降の各ステップによって選択されるノード集合が空とならない限り保存される。
【００７３】
図２３乃至図２５は、評価実行部５４による文書木及び保存集合を用いたＸＰａｔｈの評価手順を示すフローチャートであり、図２３、２４はＸＭＬイベントとして開始タグトークンが入力された場合の動作、図２５はＸＭＬイベントとして終了タグトークンが入力された場合の動作を示す。なお、説明の簡単のため、図示の動作では述語（predicate）を考慮していない。述語への対応については後述する。
図２３に示すように、評価実行部５４は、ＸＭＬイベントとして開始タグトークンが入力されると（Ｓｔｅｐ２３０１）、この要素に対応するノードＮをそれまでに生成されている文書木に挿入する（Ｓｔｅｐ２３０２）。初期的にはルートノードに対してノードＮが挿入される。そして、保存集合の各要素＜Ｓ，ｎｉｄ＞に対し、ステップＳの次の番号がつけられたステップＳ’を参照し、以下の動作を行う（Ｓｔｅｐ２３０３）。
【００７４】
評価実行部５４は、まずステップＳ’がロケーションパス（ＸＰａｔｈ）の最後かどうかを調べ（Ｓｔｅｐ２３０４）、最後ならば、さらにステップＳ’の評価が成立するかどうかを調べる（Ｓｔｅｐ２３０５）。評価が成立したならば、最後に挿入されたノードＮがＸＰａｔｈにてアドレッシングされたノードであるので、このノードＮを評価イベントとして出力する（Ｓｔｅｐ２３０６）。
ステップＳ’がロケーションパスの最後でない場合、次に評価実行部５４は、ステップＳ’の評価が成立するかどうかを調べる（Ｓｔｅｐ２３０７）。評価が成立したならば、さらにステップＳ’の次のステップＳ”における基準点に応じて、次の処理を行う。
なお、上記のＳｔｅｐ２３０５、２３０７の判断で、ステップＳ’の評価が成立しない場合、当該ＸＭＬイベントに対する処理を終了して、次のＸＭＬイベントの入力を待つ。
【００７５】
図２４に示すように、ステップＳ”の基準点がｓｅｌｆ基準点である場合、ステップＳ”を新たにステップＳ’として、評価実行部５４の処理がＳｔｅｐ２３０４の判断へ戻る（Ｓｔｅｐ２３０８、２３０９）。
【００７６】
ステップＳ”の基準点がｃｈｉｌｄ、ｄｅｓｃｅｎｄａｎｔ等のフォワード基準点である場合、まず、ノードＮをコンテクストノードとして、ステップＳ”の基準点が指定する関係を満たす入力が、この後にあり得るかどうかを判定する（Ｓｔｅｐ２３０８、２３１０）。そのような入力の可能性があるならば、タプル（ステップＩＤとノードＩＤとの組）＜Ｓ’，Ｎ＞を保存集合に追加する（Ｓｔｅｐ２３１１）。そして、既に構築された文書木におけるノードＮに対してドキュメント順で後に位置するノード集合（ｓｅｌｆを含む基準点（ｄｅｓｃｅｎｄａｎｔ−ｏｒ−ｓｅｌｆ等）の場合はノードＮ自身を含む）の各要素を新しいノードＮとし、ステップＳ”を新たにステップＳ’として、評価実行部５４の処理がＳｔｅｐ２３０４の判断へ戻る（Ｓｔｅｐ２３１２）。
ステップＳ”の基準点が指定する関係を満たす入力の可能性がないならば、タプル＜Ｓ’，Ｎ＞を保存集合に追加することなく、当該ノードＮに対してドキュメント順で後に位置するノード集合（ｓｅｌｆを含む基準点（ｄｅｓｃｅｎｄａｎｔ−ｏｒ−ｓｅｌｆ等）の場合はノードＮ自身を含む）の各要素を新しいノードＮとし、ステップＳ”を新たにステップＳ’として、評価実行部５４の処理がＳｔｅｐ２３０４の判断へ戻る（Ｓｔｅｐ２３１０、２３１２）。
【００７７】
ステップＳ”の基準点がｐａｒｅｎｔ、ａｎｃｅｓｔｏｒ等のリバース基準点である場合、既に構築された文書木におけるノードＮに対してドキュメント順で後に位置するノード集合（ｓｅｌｆを含む基準点（ａｎｃｅｓｔｏｒ−ｏｒ−ｓｅｌｆ等）の場合はノードＮ自身を含む）の各要素を新しいノードＮとし、ステップＳ”を新たにステップＳ’として、評価実行部５４の処理がＳｔｅｐ２３０４の判断へ戻る（Ｓｔｅｐ２３０８、２３１２）。
なお、以上の説明では、評価実行部５４はＸＰａｔｈが成立した場合に評価イベントを出力する（ステップ２３０６参照）こととしたが、ＸＭＬイベントを１つ処理する度に成立または不成立を示す評価イベントを出力するようにしても良いことは、実施の形態１、２の場合と同様である。
【００７８】
一方、図２５に示すように、評価実行部５４は、ＸＭＬイベントとして終了タグトークンが入力されると（Ｓｔｅｐ２５０１）、そのトークンに対応したノードを含むタプル＜Ｓ，Ｎ＞を保存集合の中から検出する（Ｓｔｅｐ２５０２）。
次に、検出されたタプルに対して、ノードＮをコンテクストノードとして、ステップＳの次の番号が付されたステップＳ’の基準点が指定する関係を満たす入力が、この後にあり得るかどうかを判定する（Ｓｔｅｐ２５０３）。そして、そのような入力の可能性のないタプルを保存集合から除去する（Ｓｔｅｐ２５０４）。
この後、処理対象であるトークンの子ノードを含むタプル＜Ｓ'，Ｎ'＞を保存集合の中から検出する（Ｓｔｅｐ２５０５）。次に、検出されたタプルに対して、ノードＮ'をコンテクストノードとして、ステップＳ'の次の番号が付されたステップＳ”の基準点が指定する関係を満たす入力が、この後にあり得るかどうかを判定する（Ｓｔｅｐ２５０６）。そして、そのような入力の可能性のないタプルを同様に保存集合から除去する（Ｓｔｅｐ２５０７）。
【００７９】
次に、上記の動作説明で省いた述語への対応について説明する。上述した動作におけるノードの評価において、述語を評価するために必要な条件がそろっている場合は、述語の評価を行う。述語の評価を行っていない場合は、述語が未評価であることを意味する付加情報をノードや保存集合に付しておき、述語の評価が仮に成功したとみなして、上記の動作を継続する。ただし、述語が未評価のノードに依存するノードの出力は保留する。述語が未評価の保存集合内の要素に対しする評価は、その後の入力によって述語の評価条件がそろった時点で行う。述語にロケーションパスが使われている場合は、評価の目的を述語を評価することに変更して図２３乃至図２５の処理を適用する。
最終的に述語の評価が成功した場合は、その評価の成功に依存していたノードを評価イベントとして出力する。一方、評価が失敗した場合は、保存集合から当該ノードを取り除き、さらに当該ノードの評価の成功を仮定して行われた全ての操作を取り消す。
【００８０】
次に、具体例を挙げて本実施の形態によるＸＰａｔｈの評価を説明する。
図２６は、処理対象であるＸＭＬ文書、そのＳＡＸイベント列および文書木を示す図である。
ＸＰａｔｈ評価部５０に、次のＸＰａｔｈ
／ａ／ｂ／ｐｒｅｃｅｄｉｎｇ−ｓｉｂｌｉｎｇ：：ｃ／ｆｏｌｌｏｗｉｎｇ−ｓｉｂｌｉｎｇ：：ｄ
が与えられたものとする。すなわち、ノードａの子供であるノードｂに先行する兄弟ノードｃに後続する兄弟ノードｄが検出されたときに、このＸＰａｔｈの成立という評価がなされる。
【００８１】
図２７乃至図３６には、図２６のＸＭＬ文書に対するＳＡＸイベント列と、これに対応する文書木、及び当該文書木を用いたＸＰａｔｈの評価によって得られる保存集合の遷移の様子が順番に示されている。
最初に、ドキュメント開始を示すＳＡＸイベントstartDocumentが入力され、対応する文書木としてルートノードｄｏｃが生成される（図２７）。また、タプル（ステップＩＤとノードＩＤとの組）＜０，ｄｏｃ＞が保存集合に入れられる。続いて、要素（ノード）の開始を示すＳＡＸイベントstartElement: "a"が入力され、ルートノードｄｏｃに子ノード“ａ”が付加される（図２８）。また、ＸＰａｔｈのステップ１までが成立するので、タプル＜１，“ａ”＞が保存集合に入れられる。
【００８２】
次に、ＳＡＸイベントstartElement: "c"が入力され、ノード“ａ”に子ノード“ｃ”が付加され（図２９）、続いて、要素の終了を示すＳＡＸイベントendElement: "c"が入力される（図３０）。次に、ＳＡＸイベントstartElement: "b"が入力されると、ノード“ａ”に子ノード“ｂ”が付加される（図３１）。このとき、ノード“ｂ”の生成によりＸＰａｔｈのステップ２が成立すると共に、リバース基準点（ｐｒｅｃｅｄｉｎｇ−ｓｉｂｌｉｎｇ）のステップ３も直ちに成立する。したがって、ステップ２に関するタプルは保存集合に保持されず、ステップ３に関するタプル＜３，“ｃ”＞が保存集合に入れられる。
【００８３】
この後、ＳＡＸイベントendElement: "ｂ"が入力され（図３２）、引き続き、ＳＡＸイベントstartElement: "d"が入力されると、ノード“ａ”に子ノード“ｄ”が付加される（図３３）。このとき、ノード“ｄ”の生成によりＸＰａｔｈのステップ４（最後のステップ）まで成立するので、当該ＸＰａｔｈが成立したと評価される。したがって、ＸＰａｔｈ評価部５０の評価実行部５４からアプリケーション実行部３０へ、評価イベントとしてノード“ｄ”が出力される（図２３、Ｓｔｅｐ２３０６参照）。
【００８４】
この後、ＳＡＸイベントendElement: "d"が入力され（図３４）、続いてＳＡＸイベントendElement: "a"が入力されて、ノード“ａ”に新たな子ノードが付加される可能性がなくなったので、保存集合からステップ１のタプル＜１，“ａ”＞が除去される（図３５、図２５のＳｔｅｐ２５０３、２５０４参照）。そしてさらに、ドキュメント終了を示すＳＡＸイベントendDocumentが入力されて、処理対象であるＸＭＬ文書のイベント列の入力が終了する（図３６）。
【００８５】
図３７は、本実施の形態によるＸＭＬ文書のストリーミング処理を説明するフローチャートである。
図３７に示すように、ＸＰａｔｈ評価部５０は、処理対象であるＸＭＬ文書が入力され、ＸＭＬパーサ１０からＸＭＬイベントが送られると（Ｓｔｅｐ３７０１）、まず取得したＸＭＬイベントに基づいて文書木が生成される（Ｓｔｅｐ３７０２）。この文書木は、ＸＭＬイベントが順次入力されるに伴って更新され、最終的に処理対象のＸＭＬ文書の文書構造に対応する文書木となる。そして、ＸＰａｔｈ評価部５０の評価実行部５４により、この文書木を用いてＸＰａｔｈの評価が行われ、部分的に成立した箇所（ステップ）に関する情報が必要に応じて保存集合に蓄積される（Ｓｔｅｐ３７０３）。そして、ＸＰａｔｈ全体が成立するまでＸＭＬイベントの入力、文書木の生成およびＸＰａｔｈの評価が繰り返され、ＸＰａｔｈ全体が成立すると評価されたならば、評価イベントがアプリケーション実行部３０へ送られる（Ｓｔｅｐ３７０４、３７０５）。
アプリケーション実行部３０は、ＸＭＬパーサ１０から出力されたＸＭＬイベントと、ＸＰａｔｈ評価部５０の評価実行部５４から出力された評価イベントとを取得し、当該評価イベントに応じて当該ＸＭＬイベントを順次処理していく。処理対象のＸＭＬ文書についてＸＭＬパーサ１０から送られる全てのＸＭＬイベントに対して、Ｓｔｅｐ３７０１〜３７０５の処理を実行した後、本実施の形態によるＸＭＬ文書のストリーミング処理を終了する（Ｓｔｅｐ３７０６）。
【００８６】
以上、３つの実施の形態によって、本発明を説明した。これらの実施の形態は、ストリーミング形式で入力されるＸＭＬイベント列に対してＸＰａｔｈの部分的な評価を順次行っていき、かかる部分的な評価に関する情報を蓄積していって、最終的にＸＰａｔｈ全体の評価結果を得る。
実施の形態１、２は、ＸＭＬイベント列のストリーミング形式による入力に応じて部分的に評価していくことが可能なデータ構造にＸＰａｔｈを変換しておき、個々のＸＭＬイベントの入力に応じて順次評価を行った。一方、実施の形態３は、ＸＭＬイベント列をストリーミング形式で入力しながらＸＭＬ文書の文書木を作成していき、この文書木を用いて逐次的にＸＰａｔｈの評価を行った。
【００８７】
実施の形態１、２は、評価の済んだＸＭＬイベントに関する情報が失われるので、リバース基準点のステップに関しては、極めて限定された条件下以外では評価できない。これに対し、実施の形態３は、評価を行ったＸＭＬイベントの情報は、文書木として残っているので、リバース基準点のステップに関する評価に対する制限はない。
【００８８】
また、実施の形態１、２、３のいずれも、全てのＸＭＬイベント列を入力していない段階でＸＰａｔｈが成立すると判断された場合には、その段階でアプリケーション実行部３０による処理を開始することが可能である（ストリーミング処理）。しかしながら、実施の形態３は、ＸＰａｔｈがリバース基準点のステップを含む場合に、ＸＭＬイベントの通知と評価イベントのそれに時間差が生じることがあり、また評価イベントの通知が必ずしもドキュメント順（ドキュメントのＸＭＬ表現において各ノードのＸＭＬ表現の最初の文字が現われる順序）で行われるとは限らないため、アプリケーション実行部３０による処理が評価イベントによってＸＭＬイベントの処理を切り替えるようなものである場合は注意が必要である。実施の形態１、２にはかかる制限はない。
【００８９】
したがって、ＸＰａｔｈがリバース基準点のステップを含まない場合には、実施の形態１、２を用いる。そして、ＸＰａｔｈがリバース基準点のステップを含む場合であっても、アプリケーション実行部３０による処理が評価イベントによってＸＭＬイベントの処理を切り替えるようなものでない場合や、そのようなものであっても処理の遅延が許されるような場合には、実施の形態３を用いるといった使い分けが可能である。
実施の形態２は、入力したＸＭＬイベント列をスタックに列の情報のまま格納し、ＸＰａｔｈを表現するスタックの記憶内容と比較するだけなので、メモリの使用量が非常に少なく、かつ処理に要する時間も短い。また、比較的容易に実装可能である。したがって、いずれの実施の形態も実施可能である場合、実施の形態２を用いることが好ましい。
なお、本発明の技術的範囲は、上記３つの実施の形態に限るものではなく、技術的思想において同一である種々の変形を含むことは言うまでもない。
【００９０】
【発明の効果】
以上説明したように、本発明によれば、ＸＭＬ文書をストリーミング処理しながらＸＰａｔｈの評価を行う解析システム及びその解析方法を実現することができる。
【図面の簡単な説明】
【図１】 実施の形態１を実現するのに好適な情報処理装置のハードウェア構成の例を模式的に示した図である。
【図２】 実施の形態１におけるＸＰａｔｈ評価手段（解析システム）の実装例を示す図である。
【図３】 実施の形態１におけるＸＰａｔｈ評価部の機能構成を説明する図である。
【図４】 実施の形態１におけるオートマトン生成部にて生成されるオートマトンを模式的に示す図である。
【図５】 実施の形態１による処理に用いられるロケーションパス、オートマトン及び処理対象のＸＭＬ文書の例を示す図である。
【図６】 実施の形態１によるＸＭＬ文書のストリーミング処理を説明するフローチャートである。
【図７】 実施の形態２におけるＸＰａｔｈ評価手段（解析システム）の実装例を示す図である。
【図８】 実施の形態２におけるＸＰａｔｈ評価部の機能構成を説明する図である。
【図９】 基準点の種類と本実施の形態にて作成されるスタックとの関係を例示する図である。
【図１０】 図９に示した関係に基づいて、ＸＰａｔｈから生成されるスタックを示す図である。
【図１１】 処理対象であるＸＭＬ文書の例を示す図である。
【図１２】 図１１のＸＭＬ文書に対するスタックを用いた評価処理の様子を示す図である。
【図１３】 図１１のＸＭＬ文書に対するスタックを用いた評価処理の様子を示す図である。
【図１４】 図１１のＸＭＬ文書に対するスタックを用いた評価処理の様子を示す図である。
【図１５】 処理対象であるＸＭＬ文書の他の例を示す図である。
【図１６】 評価対象であるＸＰａｔｈとこのＸＰａｔｈから生成されるスタックとを示す図である。
【図１７】 図１５のＸＭＬ文書に対するスタックを用いた評価処理の様子を示す図である。
【図１８】 図１５のＸＭＬ文書に対するスタックを用いた評価処理の様子を示す図である。
【図１９】 図１５のＸＭＬ文書に対するスタックを用いた評価処理の様子を示す図である。
【図２０】 実施の形態２によるＸＭＬ文書のストリーミング処理を説明するフローチャートである。
【図２１】 実施の形態３におけるＸＰａｔｈ評価手段（解析システム）の実装例を示す図である。
【図２２】 実施の形態３におけるＸＰａｔｈ評価部の機能構成を説明する図である。
【図２３】 実施の形態３の評価実行部による文書木及び保存集合を用いたＸＰａｔｈの評価手順を示すフローチャートであり、ＸＭＬイベントとして開始タグトークンが入力された場合の動作を示す図である。
【図２４】 実施の形態３の評価実行部による文書木及び保存集合を用いたＸＰａｔｈの評価手順を示すフローチャートであり、ＸＭＬイベントとして開始タグトークンが入力された場合の動作を示す図である。
【図２５】 実施の形態３の評価実行部による文書木及び保存集合を用いたＸＰａｔｈの評価手順を示すフローチャートであり、ＸＭＬイベントとして終了タグトークンが入力された場合の動作を示す図である。
【図２６】 処理対象であるＸＭＬ文書、そのＳＡＸイベント列および本実施の形態で生成される文書木を示す図である。
【図２７】 ＸＭＬ文書に対するＳＡＸイベント列、文書木、保存集合の遷移の様子を示す図であり、ＳＡＸイベントstartDocumentが入力されたときの様子を示す図である。
【図２８】 ＸＭＬ文書に対するＳＡＸイベント列、文書木、保存集合の遷移の様子を示す図であり、ＳＡＸイベントstartElement: "a"が入力されたときの様子を示す図である。
【図２９】 ＸＭＬ文書に対するＳＡＸイベント列、文書木、保存集合の遷移の様子を示す図であり、ＳＡＸイベントstartElement: "c"が入力されたときの様子を示す図である。
【図３０】 ＸＭＬ文書に対するＳＡＸイベント列、文書木、保存集合の遷移の様子を示す図であり、ＳＡＸイベントendElement: "c"が入力されたときの様子を示す図である。
【図３１】 ＸＭＬ文書に対するＳＡＸイベント列、文書木、保存集合の遷移の様子を示す図であり、ＳＡＸイベントstartElement: "b"が入力されたときの様子を示す図である。
【図３２】 ＸＭＬ文書に対するＳＡＸイベント列、文書木、保存集合の遷移の様子を示す図であり、ＳＡＸイベントendElement: "ｂ"が入力されたときの様子を示す図である。
【図３３】 ＸＭＬ文書に対するＳＡＸイベント列、文書木、保存集合の遷移の様子を示す図であり、ＳＡＸイベントstartElement: "d"が入力されたときの様子を示す図である。
【図３４】 ＸＭＬ文書に対するＳＡＸイベント列、文書木、保存集合の遷移の様子を示す図であり、ＳＡＸイベントendElement: "d"が入力されたときの様子を示す図である。
【図３５】 ＸＭＬ文書に対するＳＡＸイベント列、文書木、保存集合の遷移の様子を示す図であり、ＳＡＸイベントendElement: "a"が入力されたときの様子を示す図である。
【図３６】 ＸＭＬ文書に対するＳＡＸイベント列、文書木、保存集合の遷移の様子を示す図であり、ＳＡＸイベントendDocumentが入力されたときの様子を示す図である。
【図３７】 実施の形態３によるＸＭＬ文書のストリーミング処理を説明するフローチャートである。
【符号の説明】
１０…ＸＭＬパーサ、２０、４０、５０…ＸＰａｔｈ評価部、２１…オートマトン生成部、２２、４２、５２…ＸＭＬイベント転送部、２３、４３、５４…評価実行部、３０…アプリケーション実行部、４１…スタック生成部、５１…ＸＰａｔｈ格納部、５３…文書木生成部、１０１…ＣＰＵ、１０３…メインメモリ
Claims (13)
- コンピュータによりＸＭＬ文書に対するＸＰａｔｈの評価を行うＸＰａｔｈ評価方法であって、
前記コンピュータにおけるＸＰａｔｈ評価部のＸＭＬイベント転送部が、処理対象の前記ＸＭＬ文書を構成するＸＭＬイベント列を順次入力する第１のステップと、
前記ＸＰａｔｈ評価部のオートマトン生成部が、評価対象であるＸＰａｔｈのステップに対応する状態を有し前記ＸＭＬイベント列が当該ステップを満たす場合に状態遷移するオートマトンを生成し、記憶手段に格納する第２のステップと、
前記ＸＰａｔｈ評価部の評価実行部が、前記ＸＭＬイベント転送部に入力された前記ＸＭＬイベント列が前記ＸＰａｔｈのステップを満たすか否かを判断し、判断結果に応じて前記記憶手段に格納されている前記オートマトンの状態を遷移させ、当該オートマトンの状態に応じて、最後に入力された当該ＸＭＬイベント列までに対する当該ＸＰａｔｈの評価を行う第３のステップと、
前記評価実行部が、前記ＸＭＬイベント転送部による前記ＸＭＬイベント列の入力に伴って、入力された当該ＸＭＬイベント列までの評価を繰り返し、前記オートマトンの状態の遷移により当該オートマトンの最後の状態に達したならば、前記処理対象のＸＭＬ文書は前記ＸＰａｔｈにて記述された構造を持つと評価する第４のステップと
を含むことを特徴とするＸＰａｔｈ評価方法。 - コンピュータによりＸＭＬ文書に対するＸＰａｔｈの評価を行うＸＰａｔｈ評価方法であって、
前記コンピュータにおけるＸＰａｔｈ評価部のＸＭＬイベント転送部が、処理対象の前記ＸＭＬ文書を構成するＸＭＬイベント列を順次入力する第１のステップと、
前記ＸＰａｔｈ評価部のスタック生成部が、評価対象であるＸＰａｔｈのステップをスタック要素の列で表現した第１のスタックを生成し、記憶手段に格納する第２のステップと、
前記ＸＰａｔｈ評価部の評価実行部が、前記ＸＭＬイベント転送部に入力された前記ＸＭＬイベント列に基づいて前記処理対象のＸＭＬ文書の入れ子構造を解析するための第２のスタックを生成し、当該第２のスタックと前記記憶手段に格納されている前記第１のスタックとを比較し、比較結果に応じて、最後に入力された当該ＸＭＬイベント列までに対する前記ＸＰａｔｈの評価を行う第３のステップと、
前記評価実行部が、前記ＸＭＬイベント転送部による前記ＸＭＬイベント列の入力に伴って、入力された当該ＸＭＬイベント列までの評価を繰り返し、前記第１のスタックと前記第２のスタックとが一致したならば、前記処理対象のＸＭＬ文書は前記ＸＰａｔｈにて記述された構造を持つと評価する第４のステップと
を含むことを特徴とするＸＰａｔｈ評価方法。 - コンピュータによりＸＭＬ文書に対するＸＰａｔｈの評価を行うＸＰａｔｈ評価方法であって、
前記コンピュータにおけるＸＰａｔｈ評価部のＸＭＬイベント転送部が、処理対象の前記ＸＭＬ文書を構成するＸＭＬイベント列を順次入力する第１のステップと、
前記ＸＰａｔｈ評価部の文書木生成部が、前記ＸＭＬイベント転送部による前記ＸＭＬイベント列の入力に応じて、最後に入力された当該ＸＭＬイベント列までの文書構造を示す文書木を生成する第２のステップと、
前記ＸＰａｔｈ評価部の評価実行部が、前記ＸＭＬイベント転送部による前記ＸＭＬイベント列の入力に伴って、前記文書木生成部により生成された前記文書木に基づいて、当該最後に入力されたＸＭＬイベント列までに対する前記ＸＰａｔｈの評価を行う第３のステップと
を含むことを特徴とするＸＰａｔｈ評価方法。 - 評価対象であるＸＰａｔｈのステップに対応する状態を有しＸＭＬイベント列が当該ステップを満たす場合に状態遷移するオートマトンを生成するオートマトン生成部と、
前記オートマトンを用いてＸＭＬ文書が前記ＸＰａｔｈにて記述された構造を持つか否かを評価する評価実行部と、
処理対象のＸＭＬ文書を構成するＸＭＬイベント列を入力し、前記評価実行部に順次転送するＸＭＬイベント転送部とを備え、
前記評価実行部は、
前記ＸＭＬイベント転送部からの前記ＸＭＬイベント列の入力に伴って、入力された当該ＸＭＬイベント列が前記ＸＰａｔｈのステップを満たすか否かを判断し、判断結果に応じて前記オートマトンの状態を遷移させ、当該オートマトンの状態に応じて、最後に入力された当該ＸＭＬイベント列までに対するＸＰａｔｈの評価を行い、当該オートマトンの状態の遷移により当該オートマトンの最後の状態に達したならば、当該処理対象のＸＭＬ文書は前記ＸＰａｔｈにて記述された構造を持つと評価することを特徴とするＸＰａｔｈ評価装置。 - 評価対象であるＸＰａｔｈのステップをスタック要素の列で表現した第１のスタックを生成するスタック生成部と、
前記第１のスタックを用いてＸＭＬ文書が前記ＸＰａｔｈにて記述された構造を持つか否かを評価する評価実行部と、
処理対象のＸＭＬ文書を構成するＸＭＬイベント列を入力し、前記評価実行部に順次転送するＸＭＬイベント転送部とを備え、
前記評価実行部は、
前記ＸＭＬイベント転送部からの前記ＸＭＬイベント列の入力に伴って、入力された当該ＸＭＬイベント列に基づいて前記処理対象のＸＭＬ文書の入れ子構造を解析するための第２のスタックを生成し、当該第２のスタックと前記第１のスタックとを比較し、比較結果に応じて、最後に入力された当該ＸＭＬイベント列までに対する前記ＸＰａｔｈの評価を行い、当該第１のスタックと当該第２のスタックとが一致したならば、当該処理対象のＸＭＬ文書は前記ＸＰａｔｈにて記述された構造を持つと評価することを特徴とするＸＰａｔｈ評価装置。 - 処理対象のＸＭＬ文書の文書構造を示す文書木を生成する文書木生成部と、
前記文書木を用いてＸＭＬ文書がＸＰａｔｈにて記述された構造を持つか否かを評価する評価実行部とを備え、
前記文書木生成部は、前記処理対象のＸＭＬ文書を構成するＸＭＬイベント列を順次入力し、入力した当該ＸＭＬイベント列までの文書構造を示す文書木を順次生成し、
前記評価実行部は、前記文書木生成部により生成された前記文書木に基づいて、最後に入力された前記ＸＭＬイベント列までに対する前記ＸＰａｔｈの評価を行うことを特徴とするＸＰａｔｈ評価装置。 - 処理対象のＸＭＬ文書を解析してＸＭＬイベント列を生成するＸＭＬパーサと、
前記ＸＭＬパーサにて生成された前記ＸＭＬイベント列を順次入力し、入力した個々のＸＭＬイベントに対してストリーミング処理にてＸＰａｔｈの評価を行うＸＰａｔｈ評価部と、
前記ＸＭＬパーサで生成された前記ＸＭＬイベントを入力し、前記ＸＰａｔｈ評価部によるＸＰａｔｈの評価結果に応じて、当該ＸＭＬイベントにて構成される前記ＸＭＬ文書に対する処理を実行するアプリケーション実行部とを備え、
前記ＸＰａｔｈ評価部は、
評価対象であるＸＰａｔｈのステップに対応する状態を有し前記ＸＭＬイベント列が当該ステップを満たす場合に状態遷移するオートマトンを生成するオートマトン生成部と、
前記オートマトンを用いてＸＭＬ文書が前記ＸＰａｔｈにて記述された構造を持つか否かを評価する評価実行部と、
前記ＸＭＬパーサから前記ＸＭＬイベント列を順次入力し、前記評価実行部に転送するＸＭＬイベント転送部とを備え、
前記評価実行部は、
前記ＸＭＬイベント転送部からの前記ＸＭＬイベント列の入力に伴って、入力された当該ＸＭＬイベント列が前記ＸＰａｔｈのステップを満たすか否かを判断し、判断結果に応じて前記オートマトンの状態を遷移させ、当該オートマトンの状態に応じて、最後に入力された当該ＸＭＬイベント列までに対するＸＰａｔｈの評価を行い、当該オートマトンの状態の遷移により当該オートマトンの最後の状態に達したならば、当該処理対象のＸＭＬ文書は前記ＸＰａｔｈにて記述された構造を持つと評価することを特徴とする情報処理装置。 - 処理対象のＸＭＬ文書を解析してＸＭＬイベント列を生成するＸＭＬパーサと、
前記ＸＭＬパーサにて生成された前記ＸＭＬイベント列を順次入力し、入力した個々のＸＭＬイベントに対してストリーミング処理にてＸＰａｔｈの評価を行うＸＰａｔｈ評価部と、
前記ＸＭＬパーサで生成された前記ＸＭＬイベントを入力し、前記ＸＰａｔｈ評価部によるＸＰａｔｈの評価結果に応じて、当該ＸＭＬイベントにて構成される前記ＸＭＬ文書に対する処理を実行するアプリケーション実行部とを備え、
前記ＸＰａｔｈ評価部は、
評価対象であるＸＰａｔｈのステップをスタック要素の列で表現した第１のスタックを生成するスタック生成部と、
前記第１のスタックを用いてＸＭＬ文書が前記ＸＰａｔｈにて記述された構造を持つか否かを評価する評価実行部と、
前記ＸＭＬパーサから前記ＸＭＬイベント列を順次入力し、前記評価実行部に転送するＸＭＬイベント転送部とを備え、
前記評価実行部は、
前記ＸＭＬイベント転送部からの前記ＸＭＬイベント列の入力に伴って、入力された当該ＸＭＬイベント列に基づいて前記処理対象のＸＭＬ文書の入れ子構造を解析するための第２のスタックを生成し、当該第２のスタックと前記第１のスタックとを比較し、比較結果に応じて、最後に入力された当該ＸＭＬイベント列までに対する前記ＸＰａｔｈの評価を行い、当該第１のスタックと当該第２のスタックとが一致したならば、当該処理対象のＸＭＬ文書は前記ＸＰａｔｈにて記述された構造を持つと評価することを特徴とする情報処理装置。 - 処理対象のＸＭＬ文書を解析してＸＭＬイベント列を生成するＸＭＬパーサと、
前記ＸＭＬパーサにて生成された前記ＸＭＬイベント列を順次入力し、入力した個々のＸＭＬイベントに対してストリーミング処理にてＸＰａｔｈの評価を行うＸＰａｔｈ評価部と、
前記ＸＭＬパーサで生成された前記ＸＭＬイベントを入力し、前記ＸＰａｔｈ評価部によるＸＰａｔｈの評価結果に応じて、当該ＸＭＬイベントにて構成される前記ＸＭＬ文書に対する処理を実行するアプリケーション実行部とを備え、
前記ＸＰａｔｈ評価部は、
処理対象のＸＭＬ文書の文書構造を示す文書木を生成する文書木生成部と、
前記文書木を用いてＸＭＬ文書が前記ＸＰａｔｈにて記述された構造を持つか否かを評価する評価実行部とを備え、
前記文書木生成部は、前記ＸＭＬパーサから前記ＸＭＬイベント列を順次入力し、入力した当該ＸＭＬイベント列までの文書構造を示す文書木を順次生成し、
前記評価実行部は、前記文書木生成部により生成された前記文書木に基づいて、最後に入力された前記ＸＭＬイベント列までに対する前記ＸＰａｔｈの評価を行うことを特徴とする情報処理装置。 - コンピュータを制御して、ＸＭＬ文書に対するＸＰａｔｈの評価を行うプログラムであって、
処理対象の前記ＸＭＬ文書を構成するＸＭＬイベント列を順次入力する第１の処理と、
評価対象であるＸＰａｔｈのステップに対応する状態を有し前記ＸＭＬイベント列が当該ステップを満たす場合に状態遷移するオートマトンを生成し、記憶手段に格納する第２の処理と、
入力された前記ＸＭＬイベント列が前記ＸＰａｔｈのステップを満たすか否かを判断し、判断結果に応じて前記記憶手段に格納されている前記オートマトンの状態を遷移させ、当該オートマトンの状態に応じて、最後に入力された当該ＸＭＬイベント列までに対する当該ＸＰａｔｈの評価を行う第３の処理と、
入力された当該ＸＭＬイベント列までの評価を繰り返し、前記オートマトンの状態の遷移により当該オートマトンの最後の状態に達したならば、前記処理対象のＸＭＬ文書は前記ＸＰａｔｈにて記述された構造を持つと評価する第４の処理と
を前記コンピュータに実行させることを特徴とするプログラム。 - コンピュータを制御して、ＸＭＬ文書に対するＸＰａｔｈの評価を行うプログラムであって、
処理対象の前記ＸＭＬ文書を構成するＸＭＬイベント列を順次入力する第１の処理と、
評価対象であるＸＰａｔｈのステップをスタック要素の列で表現した第１のスタックを生成し、記憶手段に格納する第２の処理と、
入力された前記ＸＭＬイベント列に基づいて前記処理対象のＸＭＬ文書の入れ子構造を解析するための第２のスタックを生成し、当該第２のスタックと前記記憶手段に格納されている前記第１のスタックとを比較し、比較結果に応じて、最後に入力された当該ＸＭＬイベント列までに対する前記ＸＰａｔｈの評価を行う第３の処理と、
前記ＸＭＬイベント列の入力に伴って、入力された当該ＸＭＬイベント列までの評価を繰り返し、前記第１のスタックと前記第２のスタックとが一致したならば、前記処理対象のＸＭＬ文書は前記ＸＰａｔｈにて記述された構造を持つと評価する第４の処理と
を前記コンピュータに実行させることを特徴とするプログラム。 - コンピュータを制御して、ＸＭＬ文書に対するＸＰａｔｈの評価を行うプログラムであって、
処理対象の前記ＸＭＬ文書を構成するＸＭＬイベント列を順次入力する第１のステップと、
前記ＸＭＬイベント列の入力に応じて、最後に入力された当該ＸＭＬイベント列までの文書構造を示す文書木を生成する第２のステップと、
前記ＸＭＬイベント列の入力に伴って、生成された前記文書木に基づいて、当該最後に入力されたＸＭＬイベント列までに対する前記ＸＰａｔｈの評価を行う第３のステップとを前記コンピュータに実行させることを特徴とするプログラム。 - 請求項１０から請求項１２のいずれかに記載のプログラムを、コンピュータが読み取り可能に記録した記録媒体。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003122292A JP3832830B2 (ja) | 2003-04-25 | 2003-04-25 | ＸＰａｔｈ評価方法、これを用いたＸＰａｔｈ評価装置及び情報処理装置 |
| US10/815,423 US7523119B2 (en) | 2003-04-25 | 2004-04-01 | XPath evaluation and information processing |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003122292A JP3832830B2 (ja) | 2003-04-25 | 2003-04-25 | ＸＰａｔｈ評価方法、これを用いたＸＰａｔｈ評価装置及び情報処理装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004326578A JP2004326578A (ja) | 2004-11-18 |
| JP3832830B2 true JP3832830B2 (ja) | 2006-10-11 |
Family
ID=33500571
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003122292A Expired - Fee Related JP3832830B2 (ja) | 2003-04-25 | 2003-04-25 | ＸＰａｔｈ評価方法、これを用いたＸＰａｔｈ評価装置及び情報処理装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7523119B2 (ja) |
| JP (1) | JP3832830B2 (ja) |
Families Citing this family (71)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7346848B1 (en) | 2000-06-21 | 2008-03-18 | Microsoft Corporation | Single window navigation methods and systems |
| US6883168B1 (en) | 2000-06-21 | 2005-04-19 | Microsoft Corporation | Methods, systems, architectures and data structures for delivering software via a network |
| US7000230B1 (en) | 2000-06-21 | 2006-02-14 | Microsoft Corporation | Network-based software extensions |
| US7191394B1 (en) | 2000-06-21 | 2007-03-13 | Microsoft Corporation | Authoring arbitrary XML documents using DHTML and XSLT |
| US7624356B1 (en) | 2000-06-21 | 2009-11-24 | Microsoft Corporation | Task-sensitive methods and systems for displaying command sets |
| US7155667B1 (en) | 2000-06-21 | 2006-12-26 | Microsoft Corporation | User interface for integrated spreadsheets and word processing tables |
| US6948135B1 (en) | 2000-06-21 | 2005-09-20 | Microsoft Corporation | Method and systems of providing information to computer users |
| US7058644B2 (en) * | 2002-10-07 | 2006-06-06 | Click Commerce, Inc. | Parallel tree searches for matching multiple, hierarchical data structures |
| US7415672B1 (en) | 2003-03-24 | 2008-08-19 | Microsoft Corporation | System and method for designing electronic forms |
| US7370066B1 (en) | 2003-03-24 | 2008-05-06 | Microsoft Corporation | System and method for offline editing of data files |
| US7275216B2 (en) | 2003-03-24 | 2007-09-25 | Microsoft Corporation | System and method for designing electronic forms and hierarchical schemas |
| US7913159B2 (en) | 2003-03-28 | 2011-03-22 | Microsoft Corporation | System and method for real-time validation of structured data files |
| US7296017B2 (en) | 2003-03-28 | 2007-11-13 | Microsoft Corporation | Validation of XML data files |
| US7451392B1 (en) | 2003-06-30 | 2008-11-11 | Microsoft Corporation | Rendering an HTML electronic form by applying XSLT to XML using a solution |
| US7406660B1 (en) | 2003-08-01 | 2008-07-29 | Microsoft Corporation | Mapping between structured data and a visual surface |
| US7334187B1 (en) | 2003-08-06 | 2008-02-19 | Microsoft Corporation | Electronic form aggregation |
| US8819072B1 (en) | 2004-02-02 | 2014-08-26 | Microsoft Corporation | Promoting data from structured data files |
| US7496837B1 (en) | 2004-04-29 | 2009-02-24 | Microsoft Corporation | Structural editing with schema awareness |
| US7774620B1 (en) | 2004-05-27 | 2010-08-10 | Microsoft Corporation | Executing applications at appropriate trust levels |
| US9171100B2 (en) | 2004-09-22 | 2015-10-27 | Primo M. Pettovello | MTree an XPath multi-axis structure threaded index |
| US7692636B2 (en) | 2004-09-30 | 2010-04-06 | Microsoft Corporation | Systems and methods for handwriting to a screen |
| US7516399B2 (en) * | 2004-09-30 | 2009-04-07 | Microsoft Corporation | Structured-document path-language expression methods and systems |
| US8918710B2 (en) * | 2004-10-05 | 2014-12-23 | Oracle International Corporation | Reducing programming complexity in applications interfacing with parsers for data elements represented according to a markup language |
| US7712022B2 (en) | 2004-11-15 | 2010-05-04 | Microsoft Corporation | Mutually exclusive options in electronic forms |
| US7721190B2 (en) | 2004-11-16 | 2010-05-18 | Microsoft Corporation | Methods and systems for server side form processing |
| US7904801B2 (en) | 2004-12-15 | 2011-03-08 | Microsoft Corporation | Recursive sections in electronic forms |
| US7937651B2 (en) | 2005-01-14 | 2011-05-03 | Microsoft Corporation | Structural editing operations for network forms |
| US8996991B2 (en) * | 2005-02-11 | 2015-03-31 | Fujitsu Limited | System and method for displaying an acceptance status |
| US7500184B2 (en) * | 2005-02-11 | 2009-03-03 | Fujitsu Limited | Determining an acceptance status during document parsing |
| US7725834B2 (en) | 2005-03-04 | 2010-05-25 | Microsoft Corporation | Designer-created aspect for an electronic form template |
| US8010515B2 (en) | 2005-04-15 | 2011-08-30 | Microsoft Corporation | Query to an electronic form |
| US20060271850A1 (en) * | 2005-05-06 | 2006-11-30 | Didier Gombert | Method and apparatus for transforming a printer into an XML printer |
| US8200975B2 (en) | 2005-06-29 | 2012-06-12 | Microsoft Corporation | Digital signatures for network forms |
| US7548926B2 (en) * | 2005-10-05 | 2009-06-16 | Microsoft Corporation | High performance navigator for parsing inputs of a message |
| US7899817B2 (en) | 2005-10-05 | 2011-03-01 | Microsoft Corporation | Safe mode for inverse query evaluations |
| US7664742B2 (en) | 2005-11-14 | 2010-02-16 | Pettovello Primo M | Index data structure for a peer-to-peer network |
| US8001459B2 (en) | 2005-12-05 | 2011-08-16 | Microsoft Corporation | Enabling electronic documents for limited-capability computing devices |
| US7933928B2 (en) | 2005-12-22 | 2011-04-26 | Oracle International Corporation | Method and mechanism for loading XML documents into memory |
| US20070174309A1 (en) * | 2006-01-18 | 2007-07-26 | Pettovello Primo M | Mtreeini: intermediate nodes and indexes |
| JP2007200097A (ja) * | 2006-01-27 | 2007-08-09 | Seiko Epson Corp | レイアウト方法 |
| US8082493B2 (en) * | 2006-04-10 | 2011-12-20 | Oracle International Corporation | Streaming XML patch |
| US8429526B2 (en) * | 2006-04-10 | 2013-04-23 | Oracle International Corporation | Efficient evaluation for diff of XML documents |
| JP4539613B2 (ja) * | 2006-06-28 | 2010-09-08 | 富士ゼロックス株式会社 | 画像形成装置、画像生成方法およびプログラム |
| US8010889B2 (en) * | 2006-10-20 | 2011-08-30 | Oracle International Corporation | Techniques for efficient loading of binary XML data |
| KR100845234B1 (ko) * | 2006-11-14 | 2008-07-09 | 한국전자통신연구원 | 통신 소프트웨어 구조에서의 도메인 프로파일 파싱 장치 및그 방법 |
| FR2909198B1 (fr) * | 2006-11-24 | 2010-11-26 | Canon Kk | Procede et dispositif de filtrage d'elements d'un document structure a partir d'une expression. |
| US7716210B2 (en) | 2006-12-20 | 2010-05-11 | International Business Machines Corporation | Method and apparatus for XML query evaluation using early-outs and multiple passes |
| US7552119B2 (en) * | 2006-12-20 | 2009-06-23 | International Business Machines Corporation | Apparatus and method for skipping XML index scans with common ancestors of a previously failed predicate |
| US20080235260A1 (en) * | 2007-03-23 | 2008-09-25 | International Business Machines Corporation | Scalable algorithms for mapping-based xml transformation |
| FR2914452B1 (fr) * | 2007-03-27 | 2010-08-13 | Canon Kk | Procede et un dispositif d'evaluation d'au moins un predicat d'une expression sur des elements d'un document structure. |
| US20080244380A1 (en) * | 2007-03-27 | 2008-10-02 | Canon Kabushiki Kaisha | Method and device for evaluating an expression on elements of a structured document |
| US8086597B2 (en) * | 2007-06-28 | 2011-12-27 | International Business Machines Corporation | Between matching |
| US7895189B2 (en) * | 2007-06-28 | 2011-02-22 | International Business Machines Corporation | Index exploitation |
| US8250062B2 (en) * | 2007-11-09 | 2012-08-21 | Oracle International Corporation | Optimized streaming evaluation of XML queries |
| US8543898B2 (en) | 2007-11-09 | 2013-09-24 | Oracle International Corporation | Techniques for more efficient generation of XML events from XML data sources |
| US9842090B2 (en) * | 2007-12-05 | 2017-12-12 | Oracle International Corporation | Efficient streaming evaluation of XPaths on binary-encoded XML schema-based documents |
| US7475338B1 (en) * | 2007-12-20 | 2009-01-06 | International Business Machines Corporation | Method for dual operational mode parsing of a xml document |
| JP5228498B2 (ja) * | 2008-01-22 | 2013-07-03 | 富士通株式会社 | 検索方法 |
| JP5125662B2 (ja) * | 2008-03-24 | 2013-01-23 | 富士通株式会社 | クエリ変換方法および検索装置 |
| US7882138B1 (en) | 2008-03-27 | 2011-02-01 | Sonoa Networks India (PVT) Ltd. | Progressive evaluation of predicate expressions in streaming XPath processor |
| US8117188B1 (en) | 2008-03-27 | 2012-02-14 | Sonoa Networks India (PVT) Ltd. | Evaluation of multiple Xpath queries in a streaming XPath processor |
| US8397158B1 (en) * | 2008-03-31 | 2013-03-12 | Sonoa Networks India (PVT) Ltd | System and method for partial parsing of XML documents and modification thereof |
| US7865502B2 (en) * | 2008-04-10 | 2011-01-04 | International Business Machines Corporation | Optimization of extensible markup language path language (XPATH) expressions in a database management system configured to accept extensible markup language (XML) queries |
| US8429196B2 (en) | 2008-06-06 | 2013-04-23 | Oracle International Corporation | Fast extraction of scalar values from binary encoded XML |
| US8024325B2 (en) * | 2008-06-25 | 2011-09-20 | Oracle International Corporation | Estimating the cost of XML operators for binary XML storage |
| US8286074B2 (en) * | 2008-09-30 | 2012-10-09 | International Business Machines Corporation | XML streaming parsing with DOM instances |
| US8630997B1 (en) * | 2009-03-05 | 2014-01-14 | Cisco Technology, Inc. | Streaming event procesing |
| TWI390443B (zh) * | 2009-08-04 | 2013-03-21 | Univ Nat Taiwan Science Tech | 使用在可擴展性標示語言之串流路徑查詢機制系統與方法 |
| US8631028B1 (en) | 2009-10-29 | 2014-01-14 | Primo M. Pettovello | XPath query processing improvements |
| JP5998942B2 (ja) * | 2013-01-08 | 2016-09-28 | 富士通株式会社 | 更新方法、更新プログラム、および照合処理装置 |
| CN108614808B (zh) * | 2016-12-12 | 2020-09-04 | 北大方正集团有限公司 | Xml文档的排版方法及排版装置 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003084987A (ja) * | 2001-09-11 | 2003-03-20 | Internatl Business Mach Corp <Ibm> | Ｘｍｌ文書の妥当性を検証するためのオートマトンの生成方法、ｘｍｌ文書の妥当性検証方法、ｘｍｌ文書の妥当性を検証するためのオートマトンの生成システム、ｘｍｌ文書の妥当性検証システムおよびプログラム |
| US20040010752A1 (en) * | 2002-07-09 | 2004-01-15 | Lucent Technologies Inc. | System and method for filtering XML documents with XPath expressions |
| US7171407B2 (en) * | 2002-10-03 | 2007-01-30 | International Business Machines Corporation | Method for streaming XPath processing with forward and backward axes |
-
2003
- 2003-04-25 JP JP2003122292A patent/JP3832830B2/ja not_active Expired - Fee Related
-
2004
- 2004-04-01 US US10/815,423 patent/US7523119B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US7523119B2 (en) | 2009-04-21 |
| JP2004326578A (ja) | 2004-11-18 |
| US20040261019A1 (en) | 2004-12-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3832830B2 (ja) | ＸＰａｔｈ評価方法、これを用いたＸＰａｔｈ評価装置及び情報処理装置 | |
| US11693839B2 (en) | Parser for schema-free data exchange format | |
| Carroll | Signing RDF graphs | |
| JP4656868B2 (ja) | 構造化文書作成装置 | |
| US7975220B2 (en) | Apparatus, program product and method for structured document management | |
| US7941417B2 (en) | Processing structured electronic document streams using look-ahead automata | |
| JP4236055B2 (ja) | 構造化文書処理装置、方法、プログラム | |
| US8838642B2 (en) | Generating and navigating binary XML data | |
| JP4740060B2 (ja) | 重複データ検出プログラム、重複データ検出方法および重複データ検出装置 | |
| US7822788B2 (en) | Method, apparatus, and computer program product for searching structured document | |
| US8260790B2 (en) | System and method for using indexes to parse static XML documents | |
| JP2005070911A (ja) | 構造化文書のデータを検索する装置および方法 | |
| US8065283B2 (en) | Term synonym generation | |
| KR101221306B1 (ko) | 데이터 구조를 항해하기 위한 방법 및 시스템 | |
| US10754859B2 (en) | Encoding edges in graph databases | |
| JP2010250449A (ja) | 情報処理装置、情報処理方法 | |
| Bai et al. | Para-g: Path pattern query processing on large graphs | |
| JP2010186412A (ja) | 文書管理方法及び管理装置 | |
| JP4649339B2 (ja) | ＸＰａｔｈ処理装置、ＸＰａｔｈ処理方法、ＸＰａｔｈ処理プログラム、および、記憶媒体 | |
| JP2008243075A (ja) | 構造化文書管理装置及び方法 | |
| JP6753190B2 (ja) | 文書検索装置及びプログラム | |
| Saeedan et al. | dsJSON: A Distributed SQL JSON Processor | |
| JP2008209996A (ja) | 検索索引作成装置・検索索引作成方法及び検索索引作成プログラム | |
| JP2005215950A (ja) | 符号化された文書データの検索方法及びそのプログラム | |
| JP2005011215A (ja) | 情報処理装置、情報処理方法、及びプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050901 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051004 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20051226 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20060131 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060425 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20060428 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060704 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20060706 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060714 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100728 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |