構造化文書転送システム
【課題】送信側が送信データのフォーマットの詳細を理解していなくても、受信側が必要とするデータのみを受信することが可能な構造化文書転送システムを提供する。
【解決手段】送信装置は、構造化文書の解析及びノード情報の取得依頼を受信する手段１０７と、ノード情報を作成する解析手段１０６と、構造化文書のノードに対する条件を受信する手段と、ノード情報が条件に合っているかを比較する比較手段と、条件に合っているノード情報を送信する手段とを有し、受信装置は、構造化文書の解析及びノード情報の取得依頼を送信する手段と、構造化文書のノードに対する条件を送信する手段と、ノード情報を受信する手段とを有する。
【解決手段】送信装置は、構造化文書の解析及びノード情報の取得依頼を受信する手段１０７と、ノード情報を作成する解析手段１０６と、構造化文書のノードに対する条件を受信する手段と、ノード情報が条件に合っているかを比較する比較手段と、条件に合っているノード情報を送信する手段とを有し、受信装置は、構造化文書の解析及びノード情報の取得依頼を送信する手段と、構造化文書のノードに対する条件を送信する手段と、ノード情報を受信する手段とを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は構造化文書の処理、特に構造化文書の送信処理に好適な構造化文書転送システムに関する。
【背景技術】
【０００２】
近年情報機器のネットワーク化が進み、さまざまなデータを機器同士でやり取りするようになった。送信されるデータはテキストや画像、音声など様々な種類があるが、近年ではデータフォーマットにＸＭＬ（Extensible Markup Language）を基にしたものを用いるケースが多くなっている。
【０００３】
ＸＭＬはＷ３Ｃ（World Wide Web Consortium）によって標準化されており、特定のプラットフォームに依存しないフォーマットである。このため様々な機器間でデータ交換が可能になり、また構文を解析するパーサを共通化できるというメリットもある。ＸＭＬデータを送信する場合は、通常ＸＭＬデータを一つのファイルとみなし、ＨＴＴＰなどのプロトコルで通常のファイル転送と同じように処理する。
【０００４】
しかし、あるデータを受信して処理を行う際に、必ずしもすべてのデータが必要であるとは限らない。例えばＳＶＧ（Scalable Vector Graphics）で書かれた１０ページの文書があり、そのうちの５ページ目だけの情報が欲しい、という場合である。このようにあるデータの一部分のみを受信したいという要望は以前から存在し、その解決策も提案されている。例えば特許文献１に記載のように、画像や音声データを取得するときに、前半部分のみやヘッダのみ取得するという方法である。
【０００５】
【特許文献１】特開２０００−２８５００６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、従来の方法では送信側が様々なデータのフォーマットを詳細に知っていなければならず実装が困難であり、また新しいフォーマットには対応できないという問題があった。例えば、複数ページからなるＳＶＧデータが単一のファイルからなっている際に、特定のページの情報だけを受信するということは、送信側がＳＶＧのフォーマットの詳細を理解していなければ不可能である。
【０００７】
そこで本発明は、送信側が送信データのフォーマットの詳細を理解していなくても、受信側が必要とするデータのみを受信することが可能な構造化文書転送システムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
前記目的を達成するために本発明は、構造化文書を保持し、受信装置からの受信の依頼に対して該構造化文書を送信する送信装置と、前記構造化文書を受信して処理を行う前記受信装置からなる構造化文書転送システムであって、
前記送信装置は、前記構造化文書の解析及びノード情報の取得依頼を受信する手段と、
前記構造化文書を解析して前記ノード情報を作成する解析手段と、
前記構造化文書のノードに対する条件を受信する手段と、
前記解析手段によって得られた前記ノード情報が前記条件に合っているかを比較する比較手段と、
前記比較手段によって前記条件に合っているとみなされた前記ノード情報を送信する手段とを有し、
前記受信装置は、前記構造化文書の解析及びノード情報の取得依頼を送信する手段と、
前記構造化文書のノードに対する条件を送信する手段と、
前記ノード情報を受信する手段とを有することを特徴とする。
【発明の効果】
【０００９】
本発明の構造化文書処理転送システムによれば、構造化文書を送信する際に、送信者が送信データのフォーマットの詳細を理解していなくても受信側が必要なデータのみを送信することが可能になる。よって、様々なフォーマットのデータの転送量を削減することが可能になる。
【発明を実施するための最良の形態】
【００１０】
以下、図面に基づき、本発明による構造化文書転送システムの好適な実施の形態を説明する。
本発明の実施形態における構造化文書を処理する構造化文書処理システムの送信装置の構成を図１に示す。同図においてＣＰＵ１０１は、システム制御部であり装置全体を制御する。ＲＯＭ１０２は、ＣＰＵ１０１の制御プログラムや各種固定データを格納するものである。ＲＡＭ１０３は、ＳＲＡＭ，ＤＲＡＭなどで構成され、プログラム制御変数などを格納するものである。また、各種設定パラメータ、各種ワークバッファなども、ＲＡＭ１０３に格納される。記憶部１０４はハードディスクなどであり、ファイルデータを格納するものである。
【００１１】
ネットワークインタフェース１０５はＬＡＮボードやモデムといったネットワークインタフェースであり、ネットワーク上の他の機器との通信を可能とするものである。構造化文書解析部１０６は、ＸＭＬなどの構造化文書の解析を行い、ノード情報をＲＡＭ１０３に保存するものであり、プル型のＡＰＩを持つものである。
【００１２】
なおプル型パーサとは、ＳＡＸ（Ｓｉｍｐｌｅ ＡＰＩ ｆｏｒ ＸＭＬ）のようなイベント駆動型ではなく、アプリケーションからノード取得要求を受けて、それに対してノード情報を返すモデルのパーサである。このようなＸＭＬパーサは、例えばMicrosoft（登録商標）のＸｍｌＴｅｘｔＲｅａｄｅｒクラスなどがある。
【００１３】
リクエスト処理部１０７は、図４に示すリクエスト（依頼）を解析し、リクエストに応じた処理を行い、リプライを返すものである。ＸＰａｔｈ処理部１０８はＸＰａｔｈ式を保持し、構造化文書解析部１０６によって作成されたノード情報が指定されたＸＰａｔｈにマッチするかを判断するものである。
【００１４】
リクエスト処理部１０７が受理可能なリクエストの詳細を図４に示す。ＯｐｅｎＦｉｌｅは、これから解析する文書を指定するものであり、実際の解析は行わない。成功した場合はそのセッションのＩＤを返す。以降のリクエスト（取得依頼）はすべて引数にこのセッションＩＤを指定する。ＳｅｔＥｘｐｒは、取得するノードかを判断する条件を指定するものである。条件はＸＰａｔｈ式で指定する。ＧｅｔＮｏｄｅは次の１ノードのノード情報、ノード条件を読み込んで解析するものである。
【００１５】
ノードとはＸＭＬを構成する単位であり、開始タグ、終了タグ、文字列データ、処理命令などの単位である。文書の最後まで解析しているときは“ＥｎｄＯｆＦｉｌｅ”が返される。ＣｌｏｓｅＦｉｌｅは取得を終了するものである。これにより、解析に使用されていたＲＡＭ上の情報などがすべて破棄される。
【００１６】
実際にリクエスト及びリプライの送受信をする際には、これらのリクエストを適切なフォーマットにする必要がある。このための方法は既にいくつかの方法が存在するが、ここではＨＴＴＰを用い、ＵＲＬ中に含める方法で行う。サーバ３０１の構造化文書転送サービスのＵＲＬを次のようにし、リクエスト名及び引数をその後に付けることとする。
ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｏｒｇ／ｓｅｒｖ
また、書式は次の形式である。
？ｍｅｔｈｏｄ＝リクエスト名＆引数名＝引数・・・
【００１７】
リプライは通常のＨＴＴＰリプライで送信され、ＢＯＤＹ部に実際の値が格納する。例えば、ＧｅｔＮｏｄｅリクエストで引数にセッションＩＤ＝３を指定し、それが成功した場合には図６のメッセージが交換される。図６において、６０１がリクエスト、６０２がリプライである。
【００１８】
ＨＴＴＰのリクエストは「ＨＴＴＰリクエスト名 ＵＲＩ ＨＴＴＰバージョン」となっている。ここではＨＴＴＰのバージョンとして１．１が使用されている。リプライは「ＨＴＴＰバージョン ステータスコード フレーズ」があり、その後に実際のデータが格納される。このときは成功しているため「１．１ ２００ ＯＫ」となり、それ以下にノード情報が格納される。
【００１９】
ＧｅｔＮｏｄｅリクエストのリプライとしてノード情報を返すが、このノード情報も何らかのフォーマットでシリアライズする。これは例えば「ノードの型名：名前，値」というフォーマットで送信する。型名にはＳｔａｒｔＥｌｅｍｅｎｔ（開始タグ）、
ＥｎｄＥｌｅｍｅｎｔ（終了タグ）、Ａｔｔｒｉｂｕｔｅ（属性）などになる。
【００２０】
６０２のメッセージは＜ａ ｂ＝"ｃ"＞というノード情報を送信したときのものである。もちろん、その他のフォーマットも使用可能である。また、よく知られているように、ＵＲＬで使えない文字を使用する場合には適切にエスケープする必要がある。例えば引数に’／’という文字が含まれる場合は、その部分を％２Ｆとする。
【００２１】
受信装置の構成を図２に示す。図において、ＣＰＵ２０１からネットワークインタフェース２０５まではそれぞれ、図１のＣＰＵ１０１から１０５ネットワークインタフェースまでと同様である。ＳＶＧ処理部１０６は、プル型のＸＭＬパーサＡＰＩを用いてＳＶＧデータの描画などの処理を行うものである。リクエスト生成部２０７は、図４に示すプル型のＸＭＬパーサＡＰＩを持ち、ＳＶＧ処理部２０６から受けた命令を、ネットワークインタフェース２０５を用いて送信し、更にリプライを受信するものである。
【００２２】
この構造化文書処理装置は、図３に示すネットワークに接続されている。３０１に示す送信装置と、３０２に示す受信装置がネットワーク３０３によって接続されており、相互に通信が可能となっている。また、送信装置３０１はｅｘａｍｌｅ．ｏｒｇというホスト名が付けられている。
【００２３】
送信装置３０１は、図５に示されるＳＶＧの文書を持っているものとする。ＳＶＧ文書のｐａｇｅ要素は文書のページを表すものである。つまり、この文書は５０３から５０５、５０６から５０８、５０９から５１０の３ページで構成されている。このＳＶＧからｎページ目のみを描画するには、ｎ回目のｐａｇｅ要素のみを取得する必要があり、それ以外は取得の必要がない。
【００２４】
受信装置３０２が送信装置３０１上に保持されているＸＭＬデータの一部のみを取得するときの送信装置３０１の処理の流れを図７に、また、受信装置３０２の処理の流れを図１２にそれぞれ示す。ここではｔｅｓｔ．ｓｖｇの２ページ目のみを取得して描画する例を示す。
【００２５】
先ずＳＶＧ処理部２０６が、ｔｅｓｔ．ｓｖｇを取得するために、ＯｐｅｎＦｉｌｅリクエストをリクエスト生成部２０５に渡す。ＯｐｅｎＦｉｌｅを受け取ったリクエスト生成部は、ＯｐｅｎＦｉｌｅリクエストを送信装置３０１に送信する。なお、このとき引数はｔｅｓｔ．ｓｖｇを指定する（ステップＳ１２０１）。ＳＶＧ処理部からリクエスト生成部のリクエストは通常のプログラミング言語の関数呼び出しなど、メモリ内部での受け渡しになっている。このリクエストをネットワーク上に送信するためにシリアライズを行って（ステップＳ１２０２）、送信する（ステップＳ１２０３）。シリアライズは前述のようにＨＴＴＰのＧＥＴメソッドに変換することで実現できる。
【００２６】
この場合は次のようになる。
ＧＥＴ ／ｓｅｒｖ？ｍｅｔｈｏｄ＝ＯｐｅｎＦｉｌｅ＆ｆｉｌｅ＝ｔｅｓｔ．ｓｖｇ
このメッセージを受信装置３０２が受信し（ステップＳ７０１）、デシリアライズを行う（ステップＳ７０２）。デシリアライズの結果ＯｐｅｎＦｉｌｅリクエストとして認識し、リクエストの処理を行う（ステップＳ７０３）。
【００２７】
このリクエスト処理の詳細が、図８から図１１に示される。即ち、図８〜図１１はそれぞれＯｐｅｎＦｉｌｅ、ＳｅｔＥｘｐｒ、ＧｅｔＮｏｄｅ、ＣｌｏｓｅＦｉｌｅリクエストの処理を示している。この場合はＯｐｅｎＦｉｌｅなので図８の処理を実行する。
【００２８】
先ずｔｅｓｔ．ｓｖｇが送信可能かを調べる（ステップＳ８０１）。ｔｅｓｔ．ｓｖｇが存在しない場合や、読み込み権限がない場合は失敗となり、エラー情報を送信して終了する（ステップＳ８０４）。
【００２９】
成功した場合は構造化文書解析準備など、セッションの作成を行い、そのＩＤも作成する（ステップＳ８０２）。次に、このセッションＩＤをリプライとして送信する（ステップＳ８０３）。ここではセッションＩＤとして”１２”が返されたとする。これでＯｐｅｎＦｉｌｅの処理は終了である。このときエラーが発生していた場合は処理全体を終了させる（ステップＳ７０４）。
【００３０】
成功した場合は、そのリクエストがＣｌｏｓｅＦｉｌｅかどうかを確認する（ステップＳ７０５）。ＣｌｏｓｅＦｉｌｅであれば処理を終了する。それ以外の場合は再びクエストを待つ（ステップＳ７０１）。リプライとして送信された”１２”という情報を、受信装置３０２が受信する（ステップＳ１２０４）。リプライはＳＶＧ処理部に渡される（ステップＳ１２０５）。
【００３１】
次に、ＳＶＧ処理部は必要なノード情報の条件を設定するため、ＳｅｔＥｘｐｒリクエストを呼び出す。２ページ目の処理に必要な情報は「ｓｖｇ要素内のｐａｇｅＳｅｔ要素内にある２番目のｐａｇｅ要素内の情報」であり、これをＸＰａｔｈ式で表すと次のようになる。
”／ｓｖｇ／ｐａｇｅＳｅｔ／ｐａｇｅ[２]”
よってこの式と先ほどのセッションＩＤがリクエスト生成部に渡される。
この結果以下のリクエストが生成、送信される。
ＧＥＴ ／ｓｅｒｖ？ｍｅｔｈｏｄ＝ＳｅｔＥｘｐｒ＆ｓｉｄ＝１２＆ｅｘｐｒ＝％２Ｆ／ｓｖｇ％２Ｆ／ｐａｇｅＳｅｔ％２Ｆｐａｇｅ％５Ｂ２％５Ｄ １．１
となる。なお’／’、’[’、’]’はＵＲＬ内で直接使用できないため、それぞれ％２Ｆ、％５Ｂ、％５Ｄに置きかえる。このリクエストも同様に受信、デシリアライズされ、リクエストの処理が行われる（ステップＳ７０１、ステップＳ７０２、ステップＳ７０３）。
【００３２】
ＳｅｔＥｘｐｒは図９に従って処理される。先ず指定されたセッションがあるかを確認する（ステップＳ９０１）。存在しなければエラー情報が送信され（ステップＳ９０５）、終了する。この場合、セッションＩＤである１２は、先ほど作成されて保存されているため存在しているため、ＸＰａｔｈ式の文法が合っているかをＸＰａｔｈ処理部１０８によって確認する（ステップＳ９０２）。文法違反であればエラー情報を送信して終了する（ステップＳ９０５）。
【００３３】
ＸＰａｔｈ式が合っていれば、ノード情報との比較用の内部情報として格納する（ステップＳ９０３）。そしてＳｅｔＥｘｐｒの成功時のリプライである”SUCCESS”を送信する（ステップＳ９０４）。
【００３４】
次にＳＶＧ処理部は実際のノード取得を行うため、ＧｅｔＮｏｄｅリクエストを呼び出す。このリクエストもリクエスト生成部に渡され、以下のような形式で送信される。
ＧＥＴ ／ｓｅｒｖ？ｍｅｔｈｏｄ＝ＧｅｔＮｏｄｅ＆ｓｉｄ＝１２ １．１
このリクエストも同様に受信、デシリアライズされ、図１０に従って処理される。
【００３５】
先ず、ＳｅｔＥｘｐｒリクエストの処理と同様に、セッションの存在を確認する（ステップＳ１００１）。次に、対象文書をすべて読んだかを確認する（ステップＳ１００２）。この段階ではまだ読んでいないため、対象文書を1ノード読み込む（ステップＳ１００３）。この結果最初のノードであるｓｖｇタグ（５０１）が読み込まれる。
【００３６】
次にＸＰａｔｈ式が指定されているかを確認する（ステップＳ１００４）。指定されていなければ、読み込んだノード情報を送信する（ステップＳ１００６）。この場合は指定されているため、ＸＰａｔｈ式とマッチしているかを確認する。
【００３７】
ｓｖｇタグ５０１の位置をＸＰａｔｈ式で表すと”／ｓｖｇ”であるため、マッチしていない。よってこの情報は破棄し（ステップＳ１００７）、再びステップＳ１００２以降の処理を行う。このようにしてノードを上から順に一つずつたどると、５０６のｐａｇｅタグのときにＸＰａｔｈ式にマッチする。マッチした場合はこのノードの情報を送信し（ステップＳ１００６）、処理を終了する。
【００３８】
クライアント３０２はこのノード情報を受信し（ステップＳ１２０４）、情報をＳＶＧ処理部２０６に渡す。ＳＶＧ処理部はこの情報を用いて処理を行う。その後、ＳＶＧ処理部は更にノード情報を取得するためＧｅｔＮｏｄｅリクエストを呼び出す。これも前述したＧｅｔＮｏｄｅリクエストと同様に処理され、ｃｉｒｃｌｅタグ５０７が読み込まれる。このノードはＸＰａｔｈ式にマッチした要素内の情報であるため、ノード情報が送信される（ステップＳ１００６）。以下同様にＧｅｔＮｏｄｅに対して、５０８の終了タグまでノード情報が送信される。
【００３９】
更に次にＧｅｔＮｏｄｅリクエストが呼ばれると、これ以上マッチするノードがないため文書終端（５１２）まで解析され、ＥｎｄＯｆＦｉｌｅが返される（ステップＳ１００９）。このリプライにより、ＳＶＧ処理部２０６は、これ以上必要な情報がないことがわかり、取得終了のためＣｌｏｓｅＦｉｌｅリクエストを呼び出す。
【００４０】
ＣｌｏｓｅＦｉｌｅリクエストは図１１に従って処理される。ＳｅｔＥｘｐｒなどと同様、セッションの存在を確認し（ステップＳ１１０１）、存在すればセッション情報を破棄する（ステップＳ１１０２）。そして”SUCCESS”をリプライとして送信する（ステップＳ１１０３）。このリプライを受信して、ＳＶＧ処理部に渡すことで処理はすべて終了となる。
【００４１】
以上の処理を行うことで構造化文書を受信するときに、受信側にとって必要な情報のみ取得することを、送信側が文書フォーマットの詳細を識別することなしに行うことが可能になる。
【００４２】
なお、本実施形態では通信が必ず正しく行われることを前提としているが、ネットワーク回線の切断などによって期待しているリクエストまたはリプライが返って来ないことがあり得る。このような事態に対応するため、タイムアウト時間を設定し、指定された時間内に通信がない場合は、それまでの情報を破棄し、それ以降の処理を中断させる、といった処理が必要であることは言うまでもない。
【００４３】
本実施形態では、取得するノードの条件としてＸＰａｔｈを用いたが、その他の方式で行うことも可能である。また、ノードの種類と名前で指定し、「次のａｂｃ要素まで取得」という指定も可能である。
また、本実施形態では必要なノードを取得するのにすべてＧｅｔＮｏｄｅリクエストを用いて一つずつ取得していた。しかしならが、必要な範囲が特定できる場合は、指定された範囲までをすべて取得するようなリクエストを追加することも可能である。
【００４４】
更に、本実施形態のように受信側が取得リクエストを出し、それに応じてノード情報を取得するというプル型の方式ではなく、指定されたノードのみを送信側が非同期に送信すると言うプッシュ型にすることも可能である。
また、送信装置はリクエストを受信してから構造化文書の解析を行っていたが、リクエストが来る前にある程度解析を行い、その情報をキャッシュしておくことで、より高速に処理することも可能である。
また、本実施形態でははじめに受信側が送信側に対して文書取得要求を送信しているが、はじめに送信側から送信要求を送ることで処理を開始することも可能である。
【図面の簡単な説明】
【００４５】
【図１】本発明の構造化文書転送システムにおける送信装置の構成を示すブロック図である。
【図２】本発明の構造化文書転送システムにおける受信装置の構成を示すブロック図である。
【図３】本発明の構造化文書転送システムの構成を示す図である。
【図４】本発明の構造化文書転送システムに係る構造化文書解析部が持つＡＰＩの一覧を示す図である。
【図５】本発明の実施形態における転送されるＳＶＧ文書の例を示す図である。
【図６】本発明の構造化文書転送システムに係る送信装置の処理の概要を示すフローチャートである。
【図７】本発明の構造化文書転送システムにおけるノード取得リクエストの処理の詳細を示すフローチャートである。
【図８】本発明の構造化文書転送システムにおけるノード読み飛ばしリクエストの処理の詳細を示すフローチャートである。
【図９】本発明の構造化文書転送システムにおけるノード読み飛ばしリクエストの処理の詳細を示すフローチャートである。
【図１０】本発明の構造化文書転送システムにおけるノード読み飛ばしリクエストの処理の詳細を示すフローチャートである。
【図１１】本発明の構造化文書転送システムにおけるノード読み飛ばしリクエストの処理の詳細を示すフローチャートである。
【図１２】本発明の構造化文書転送システムにおけるノード取得リクエストの処理の詳細を示すフローチャートである。
【符号の説明】
【００４６】
１０１ ＣＰＵ
１０２ ＲＯＭ
１０３ ＲＡＭ
１０４ 記憶部
１０５ ネットワークインタフェース
１０６ 構造化文書解析部
１０７ リクエスト処理部
１０８ ＸＰａｔｈ処理部
２０１ ＣＰＵ
２０２ ＲＯＭ
２０３ ＲＡＭ
２０４ 記憶部
２０５ ネットワークインタフェース
２０６ ＳＶＧ処理部
２０７ リクエスト生成部
２０８ 表示部
３０１ 送信装置
３０２ 受信装置
【技術分野】
【０００１】
本発明は構造化文書の処理、特に構造化文書の送信処理に好適な構造化文書転送システムに関する。
【背景技術】
【０００２】
近年情報機器のネットワーク化が進み、さまざまなデータを機器同士でやり取りするようになった。送信されるデータはテキストや画像、音声など様々な種類があるが、近年ではデータフォーマットにＸＭＬ（Extensible Markup Language）を基にしたものを用いるケースが多くなっている。
【０００３】
ＸＭＬはＷ３Ｃ（World Wide Web Consortium）によって標準化されており、特定のプラットフォームに依存しないフォーマットである。このため様々な機器間でデータ交換が可能になり、また構文を解析するパーサを共通化できるというメリットもある。ＸＭＬデータを送信する場合は、通常ＸＭＬデータを一つのファイルとみなし、ＨＴＴＰなどのプロトコルで通常のファイル転送と同じように処理する。
【０００４】
しかし、あるデータを受信して処理を行う際に、必ずしもすべてのデータが必要であるとは限らない。例えばＳＶＧ（Scalable Vector Graphics）で書かれた１０ページの文書があり、そのうちの５ページ目だけの情報が欲しい、という場合である。このようにあるデータの一部分のみを受信したいという要望は以前から存在し、その解決策も提案されている。例えば特許文献１に記載のように、画像や音声データを取得するときに、前半部分のみやヘッダのみ取得するという方法である。
【０００５】
【特許文献１】特開２０００−２８５００６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、従来の方法では送信側が様々なデータのフォーマットを詳細に知っていなければならず実装が困難であり、また新しいフォーマットには対応できないという問題があった。例えば、複数ページからなるＳＶＧデータが単一のファイルからなっている際に、特定のページの情報だけを受信するということは、送信側がＳＶＧのフォーマットの詳細を理解していなければ不可能である。
【０００７】
そこで本発明は、送信側が送信データのフォーマットの詳細を理解していなくても、受信側が必要とするデータのみを受信することが可能な構造化文書転送システムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
前記目的を達成するために本発明は、構造化文書を保持し、受信装置からの受信の依頼に対して該構造化文書を送信する送信装置と、前記構造化文書を受信して処理を行う前記受信装置からなる構造化文書転送システムであって、
前記送信装置は、前記構造化文書の解析及びノード情報の取得依頼を受信する手段と、
前記構造化文書を解析して前記ノード情報を作成する解析手段と、
前記構造化文書のノードに対する条件を受信する手段と、
前記解析手段によって得られた前記ノード情報が前記条件に合っているかを比較する比較手段と、
前記比較手段によって前記条件に合っているとみなされた前記ノード情報を送信する手段とを有し、
前記受信装置は、前記構造化文書の解析及びノード情報の取得依頼を送信する手段と、
前記構造化文書のノードに対する条件を送信する手段と、
前記ノード情報を受信する手段とを有することを特徴とする。
【発明の効果】
【０００９】
本発明の構造化文書処理転送システムによれば、構造化文書を送信する際に、送信者が送信データのフォーマットの詳細を理解していなくても受信側が必要なデータのみを送信することが可能になる。よって、様々なフォーマットのデータの転送量を削減することが可能になる。
【発明を実施するための最良の形態】
【００１０】
以下、図面に基づき、本発明による構造化文書転送システムの好適な実施の形態を説明する。
本発明の実施形態における構造化文書を処理する構造化文書処理システムの送信装置の構成を図１に示す。同図においてＣＰＵ１０１は、システム制御部であり装置全体を制御する。ＲＯＭ１０２は、ＣＰＵ１０１の制御プログラムや各種固定データを格納するものである。ＲＡＭ１０３は、ＳＲＡＭ，ＤＲＡＭなどで構成され、プログラム制御変数などを格納するものである。また、各種設定パラメータ、各種ワークバッファなども、ＲＡＭ１０３に格納される。記憶部１０４はハードディスクなどであり、ファイルデータを格納するものである。
【００１１】
ネットワークインタフェース１０５はＬＡＮボードやモデムといったネットワークインタフェースであり、ネットワーク上の他の機器との通信を可能とするものである。構造化文書解析部１０６は、ＸＭＬなどの構造化文書の解析を行い、ノード情報をＲＡＭ１０３に保存するものであり、プル型のＡＰＩを持つものである。
【００１２】
なおプル型パーサとは、ＳＡＸ（Ｓｉｍｐｌｅ ＡＰＩ ｆｏｒ ＸＭＬ）のようなイベント駆動型ではなく、アプリケーションからノード取得要求を受けて、それに対してノード情報を返すモデルのパーサである。このようなＸＭＬパーサは、例えばMicrosoft（登録商標）のＸｍｌＴｅｘｔＲｅａｄｅｒクラスなどがある。
【００１３】
リクエスト処理部１０７は、図４に示すリクエスト（依頼）を解析し、リクエストに応じた処理を行い、リプライを返すものである。ＸＰａｔｈ処理部１０８はＸＰａｔｈ式を保持し、構造化文書解析部１０６によって作成されたノード情報が指定されたＸＰａｔｈにマッチするかを判断するものである。
【００１４】
リクエスト処理部１０７が受理可能なリクエストの詳細を図４に示す。ＯｐｅｎＦｉｌｅは、これから解析する文書を指定するものであり、実際の解析は行わない。成功した場合はそのセッションのＩＤを返す。以降のリクエスト（取得依頼）はすべて引数にこのセッションＩＤを指定する。ＳｅｔＥｘｐｒは、取得するノードかを判断する条件を指定するものである。条件はＸＰａｔｈ式で指定する。ＧｅｔＮｏｄｅは次の１ノードのノード情報、ノード条件を読み込んで解析するものである。
【００１５】
ノードとはＸＭＬを構成する単位であり、開始タグ、終了タグ、文字列データ、処理命令などの単位である。文書の最後まで解析しているときは“ＥｎｄＯｆＦｉｌｅ”が返される。ＣｌｏｓｅＦｉｌｅは取得を終了するものである。これにより、解析に使用されていたＲＡＭ上の情報などがすべて破棄される。
【００１６】
実際にリクエスト及びリプライの送受信をする際には、これらのリクエストを適切なフォーマットにする必要がある。このための方法は既にいくつかの方法が存在するが、ここではＨＴＴＰを用い、ＵＲＬ中に含める方法で行う。サーバ３０１の構造化文書転送サービスのＵＲＬを次のようにし、リクエスト名及び引数をその後に付けることとする。
ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｏｒｇ／ｓｅｒｖ
また、書式は次の形式である。
？ｍｅｔｈｏｄ＝リクエスト名＆引数名＝引数・・・
【００１７】
リプライは通常のＨＴＴＰリプライで送信され、ＢＯＤＹ部に実際の値が格納する。例えば、ＧｅｔＮｏｄｅリクエストで引数にセッションＩＤ＝３を指定し、それが成功した場合には図６のメッセージが交換される。図６において、６０１がリクエスト、６０２がリプライである。
【００１８】
ＨＴＴＰのリクエストは「ＨＴＴＰリクエスト名 ＵＲＩ ＨＴＴＰバージョン」となっている。ここではＨＴＴＰのバージョンとして１．１が使用されている。リプライは「ＨＴＴＰバージョン ステータスコード フレーズ」があり、その後に実際のデータが格納される。このときは成功しているため「１．１ ２００ ＯＫ」となり、それ以下にノード情報が格納される。
【００１９】
ＧｅｔＮｏｄｅリクエストのリプライとしてノード情報を返すが、このノード情報も何らかのフォーマットでシリアライズする。これは例えば「ノードの型名：名前，値」というフォーマットで送信する。型名にはＳｔａｒｔＥｌｅｍｅｎｔ（開始タグ）、
ＥｎｄＥｌｅｍｅｎｔ（終了タグ）、Ａｔｔｒｉｂｕｔｅ（属性）などになる。
【００２０】
６０２のメッセージは＜ａ ｂ＝"ｃ"＞というノード情報を送信したときのものである。もちろん、その他のフォーマットも使用可能である。また、よく知られているように、ＵＲＬで使えない文字を使用する場合には適切にエスケープする必要がある。例えば引数に’／’という文字が含まれる場合は、その部分を％２Ｆとする。
【００２１】
受信装置の構成を図２に示す。図において、ＣＰＵ２０１からネットワークインタフェース２０５まではそれぞれ、図１のＣＰＵ１０１から１０５ネットワークインタフェースまでと同様である。ＳＶＧ処理部１０６は、プル型のＸＭＬパーサＡＰＩを用いてＳＶＧデータの描画などの処理を行うものである。リクエスト生成部２０７は、図４に示すプル型のＸＭＬパーサＡＰＩを持ち、ＳＶＧ処理部２０６から受けた命令を、ネットワークインタフェース２０５を用いて送信し、更にリプライを受信するものである。
【００２２】
この構造化文書処理装置は、図３に示すネットワークに接続されている。３０１に示す送信装置と、３０２に示す受信装置がネットワーク３０３によって接続されており、相互に通信が可能となっている。また、送信装置３０１はｅｘａｍｌｅ．ｏｒｇというホスト名が付けられている。
【００２３】
送信装置３０１は、図５に示されるＳＶＧの文書を持っているものとする。ＳＶＧ文書のｐａｇｅ要素は文書のページを表すものである。つまり、この文書は５０３から５０５、５０６から５０８、５０９から５１０の３ページで構成されている。このＳＶＧからｎページ目のみを描画するには、ｎ回目のｐａｇｅ要素のみを取得する必要があり、それ以外は取得の必要がない。
【００２４】
受信装置３０２が送信装置３０１上に保持されているＸＭＬデータの一部のみを取得するときの送信装置３０１の処理の流れを図７に、また、受信装置３０２の処理の流れを図１２にそれぞれ示す。ここではｔｅｓｔ．ｓｖｇの２ページ目のみを取得して描画する例を示す。
【００２５】
先ずＳＶＧ処理部２０６が、ｔｅｓｔ．ｓｖｇを取得するために、ＯｐｅｎＦｉｌｅリクエストをリクエスト生成部２０５に渡す。ＯｐｅｎＦｉｌｅを受け取ったリクエスト生成部は、ＯｐｅｎＦｉｌｅリクエストを送信装置３０１に送信する。なお、このとき引数はｔｅｓｔ．ｓｖｇを指定する（ステップＳ１２０１）。ＳＶＧ処理部からリクエスト生成部のリクエストは通常のプログラミング言語の関数呼び出しなど、メモリ内部での受け渡しになっている。このリクエストをネットワーク上に送信するためにシリアライズを行って（ステップＳ１２０２）、送信する（ステップＳ１２０３）。シリアライズは前述のようにＨＴＴＰのＧＥＴメソッドに変換することで実現できる。
【００２６】
この場合は次のようになる。
ＧＥＴ ／ｓｅｒｖ？ｍｅｔｈｏｄ＝ＯｐｅｎＦｉｌｅ＆ｆｉｌｅ＝ｔｅｓｔ．ｓｖｇ
このメッセージを受信装置３０２が受信し（ステップＳ７０１）、デシリアライズを行う（ステップＳ７０２）。デシリアライズの結果ＯｐｅｎＦｉｌｅリクエストとして認識し、リクエストの処理を行う（ステップＳ７０３）。
【００２７】
このリクエスト処理の詳細が、図８から図１１に示される。即ち、図８〜図１１はそれぞれＯｐｅｎＦｉｌｅ、ＳｅｔＥｘｐｒ、ＧｅｔＮｏｄｅ、ＣｌｏｓｅＦｉｌｅリクエストの処理を示している。この場合はＯｐｅｎＦｉｌｅなので図８の処理を実行する。
【００２８】
先ずｔｅｓｔ．ｓｖｇが送信可能かを調べる（ステップＳ８０１）。ｔｅｓｔ．ｓｖｇが存在しない場合や、読み込み権限がない場合は失敗となり、エラー情報を送信して終了する（ステップＳ８０４）。
【００２９】
成功した場合は構造化文書解析準備など、セッションの作成を行い、そのＩＤも作成する（ステップＳ８０２）。次に、このセッションＩＤをリプライとして送信する（ステップＳ８０３）。ここではセッションＩＤとして”１２”が返されたとする。これでＯｐｅｎＦｉｌｅの処理は終了である。このときエラーが発生していた場合は処理全体を終了させる（ステップＳ７０４）。
【００３０】
成功した場合は、そのリクエストがＣｌｏｓｅＦｉｌｅかどうかを確認する（ステップＳ７０５）。ＣｌｏｓｅＦｉｌｅであれば処理を終了する。それ以外の場合は再びクエストを待つ（ステップＳ７０１）。リプライとして送信された”１２”という情報を、受信装置３０２が受信する（ステップＳ１２０４）。リプライはＳＶＧ処理部に渡される（ステップＳ１２０５）。
【００３１】
次に、ＳＶＧ処理部は必要なノード情報の条件を設定するため、ＳｅｔＥｘｐｒリクエストを呼び出す。２ページ目の処理に必要な情報は「ｓｖｇ要素内のｐａｇｅＳｅｔ要素内にある２番目のｐａｇｅ要素内の情報」であり、これをＸＰａｔｈ式で表すと次のようになる。
”／ｓｖｇ／ｐａｇｅＳｅｔ／ｐａｇｅ[２]”
よってこの式と先ほどのセッションＩＤがリクエスト生成部に渡される。
この結果以下のリクエストが生成、送信される。
ＧＥＴ ／ｓｅｒｖ？ｍｅｔｈｏｄ＝ＳｅｔＥｘｐｒ＆ｓｉｄ＝１２＆ｅｘｐｒ＝％２Ｆ／ｓｖｇ％２Ｆ／ｐａｇｅＳｅｔ％２Ｆｐａｇｅ％５Ｂ２％５Ｄ １．１
となる。なお’／’、’[’、’]’はＵＲＬ内で直接使用できないため、それぞれ％２Ｆ、％５Ｂ、％５Ｄに置きかえる。このリクエストも同様に受信、デシリアライズされ、リクエストの処理が行われる（ステップＳ７０１、ステップＳ７０２、ステップＳ７０３）。
【００３２】
ＳｅｔＥｘｐｒは図９に従って処理される。先ず指定されたセッションがあるかを確認する（ステップＳ９０１）。存在しなければエラー情報が送信され（ステップＳ９０５）、終了する。この場合、セッションＩＤである１２は、先ほど作成されて保存されているため存在しているため、ＸＰａｔｈ式の文法が合っているかをＸＰａｔｈ処理部１０８によって確認する（ステップＳ９０２）。文法違反であればエラー情報を送信して終了する（ステップＳ９０５）。
【００３３】
ＸＰａｔｈ式が合っていれば、ノード情報との比較用の内部情報として格納する（ステップＳ９０３）。そしてＳｅｔＥｘｐｒの成功時のリプライである”SUCCESS”を送信する（ステップＳ９０４）。
【００３４】
次にＳＶＧ処理部は実際のノード取得を行うため、ＧｅｔＮｏｄｅリクエストを呼び出す。このリクエストもリクエスト生成部に渡され、以下のような形式で送信される。
ＧＥＴ ／ｓｅｒｖ？ｍｅｔｈｏｄ＝ＧｅｔＮｏｄｅ＆ｓｉｄ＝１２ １．１
このリクエストも同様に受信、デシリアライズされ、図１０に従って処理される。
【００３５】
先ず、ＳｅｔＥｘｐｒリクエストの処理と同様に、セッションの存在を確認する（ステップＳ１００１）。次に、対象文書をすべて読んだかを確認する（ステップＳ１００２）。この段階ではまだ読んでいないため、対象文書を1ノード読み込む（ステップＳ１００３）。この結果最初のノードであるｓｖｇタグ（５０１）が読み込まれる。
【００３６】
次にＸＰａｔｈ式が指定されているかを確認する（ステップＳ１００４）。指定されていなければ、読み込んだノード情報を送信する（ステップＳ１００６）。この場合は指定されているため、ＸＰａｔｈ式とマッチしているかを確認する。
【００３７】
ｓｖｇタグ５０１の位置をＸＰａｔｈ式で表すと”／ｓｖｇ”であるため、マッチしていない。よってこの情報は破棄し（ステップＳ１００７）、再びステップＳ１００２以降の処理を行う。このようにしてノードを上から順に一つずつたどると、５０６のｐａｇｅタグのときにＸＰａｔｈ式にマッチする。マッチした場合はこのノードの情報を送信し（ステップＳ１００６）、処理を終了する。
【００３８】
クライアント３０２はこのノード情報を受信し（ステップＳ１２０４）、情報をＳＶＧ処理部２０６に渡す。ＳＶＧ処理部はこの情報を用いて処理を行う。その後、ＳＶＧ処理部は更にノード情報を取得するためＧｅｔＮｏｄｅリクエストを呼び出す。これも前述したＧｅｔＮｏｄｅリクエストと同様に処理され、ｃｉｒｃｌｅタグ５０７が読み込まれる。このノードはＸＰａｔｈ式にマッチした要素内の情報であるため、ノード情報が送信される（ステップＳ１００６）。以下同様にＧｅｔＮｏｄｅに対して、５０８の終了タグまでノード情報が送信される。
【００３９】
更に次にＧｅｔＮｏｄｅリクエストが呼ばれると、これ以上マッチするノードがないため文書終端（５１２）まで解析され、ＥｎｄＯｆＦｉｌｅが返される（ステップＳ１００９）。このリプライにより、ＳＶＧ処理部２０６は、これ以上必要な情報がないことがわかり、取得終了のためＣｌｏｓｅＦｉｌｅリクエストを呼び出す。
【００４０】
ＣｌｏｓｅＦｉｌｅリクエストは図１１に従って処理される。ＳｅｔＥｘｐｒなどと同様、セッションの存在を確認し（ステップＳ１１０１）、存在すればセッション情報を破棄する（ステップＳ１１０２）。そして”SUCCESS”をリプライとして送信する（ステップＳ１１０３）。このリプライを受信して、ＳＶＧ処理部に渡すことで処理はすべて終了となる。
【００４１】
以上の処理を行うことで構造化文書を受信するときに、受信側にとって必要な情報のみ取得することを、送信側が文書フォーマットの詳細を識別することなしに行うことが可能になる。
【００４２】
なお、本実施形態では通信が必ず正しく行われることを前提としているが、ネットワーク回線の切断などによって期待しているリクエストまたはリプライが返って来ないことがあり得る。このような事態に対応するため、タイムアウト時間を設定し、指定された時間内に通信がない場合は、それまでの情報を破棄し、それ以降の処理を中断させる、といった処理が必要であることは言うまでもない。
【００４３】
本実施形態では、取得するノードの条件としてＸＰａｔｈを用いたが、その他の方式で行うことも可能である。また、ノードの種類と名前で指定し、「次のａｂｃ要素まで取得」という指定も可能である。
また、本実施形態では必要なノードを取得するのにすべてＧｅｔＮｏｄｅリクエストを用いて一つずつ取得していた。しかしならが、必要な範囲が特定できる場合は、指定された範囲までをすべて取得するようなリクエストを追加することも可能である。
【００４４】
更に、本実施形態のように受信側が取得リクエストを出し、それに応じてノード情報を取得するというプル型の方式ではなく、指定されたノードのみを送信側が非同期に送信すると言うプッシュ型にすることも可能である。
また、送信装置はリクエストを受信してから構造化文書の解析を行っていたが、リクエストが来る前にある程度解析を行い、その情報をキャッシュしておくことで、より高速に処理することも可能である。
また、本実施形態でははじめに受信側が送信側に対して文書取得要求を送信しているが、はじめに送信側から送信要求を送ることで処理を開始することも可能である。
【図面の簡単な説明】
【００４５】
【図１】本発明の構造化文書転送システムにおける送信装置の構成を示すブロック図である。
【図２】本発明の構造化文書転送システムにおける受信装置の構成を示すブロック図である。
【図３】本発明の構造化文書転送システムの構成を示す図である。
【図４】本発明の構造化文書転送システムに係る構造化文書解析部が持つＡＰＩの一覧を示す図である。
【図５】本発明の実施形態における転送されるＳＶＧ文書の例を示す図である。
【図６】本発明の構造化文書転送システムに係る送信装置の処理の概要を示すフローチャートである。
【図７】本発明の構造化文書転送システムにおけるノード取得リクエストの処理の詳細を示すフローチャートである。
【図８】本発明の構造化文書転送システムにおけるノード読み飛ばしリクエストの処理の詳細を示すフローチャートである。
【図９】本発明の構造化文書転送システムにおけるノード読み飛ばしリクエストの処理の詳細を示すフローチャートである。
【図１０】本発明の構造化文書転送システムにおけるノード読み飛ばしリクエストの処理の詳細を示すフローチャートである。
【図１１】本発明の構造化文書転送システムにおけるノード読み飛ばしリクエストの処理の詳細を示すフローチャートである。
【図１２】本発明の構造化文書転送システムにおけるノード取得リクエストの処理の詳細を示すフローチャートである。
【符号の説明】
【００４６】
１０１ ＣＰＵ
１０２ ＲＯＭ
１０３ ＲＡＭ
１０４ 記憶部
１０５ ネットワークインタフェース
１０６ 構造化文書解析部
１０７ リクエスト処理部
１０８ ＸＰａｔｈ処理部
２０１ ＣＰＵ
２０２ ＲＯＭ
２０３ ＲＡＭ
２０４ 記憶部
２０５ ネットワークインタフェース
２０６ ＳＶＧ処理部
２０７ リクエスト生成部
２０８ 表示部
３０１ 送信装置
３０２ 受信装置
【特許請求の範囲】
【請求項１】
構造化文書を保持し、受信装置からの受信の依頼に対して該構造化文書を送信する送信装置と、前記構造化文書を受信して処理を行う前記受信装置からなる構造化文書転送システムであって、
前記送信装置は、前記構造化文書の解析及びノード情報の取得依頼を受信する手段と、
前記構造化文書を解析して前記ノード情報を作成する解析手段と、
前記構造化文書のノードに対する条件を受信する手段と、
前記解析手段によって得られた前記ノード情報が前記条件に合っているかを比較する比較手段と、
前記比較手段によって前記条件に合っているとみなされた前記ノード情報を送信する手段とを有し、
前記受信装置は、前記構造化文書の解析及びノード情報の取得依頼を送信する手段と、
前記構造化文書のノードに対する条件を送信する手段と、
前記ノード情報を受信する手段とを有することを特徴とする構造化文書転送システム。
【請求項２】
前記構造化文書は、ＸＭＬであることを特徴とする請求項１に記載の構造化文書転送システム。
【請求項３】
前記送信装置は、非同期に前記受信装置に送信することを特徴とする請求項１に記載の構造化文書転送システム。
【請求項４】
前記送信装置は、前記ノードの取得依頼に対応して前記ノード情報を送信することを特徴とする請求項１に記載の構造化文書転送システム。
【請求項５】
前記ノードに対するノード条件は、ＸＰａｔｈで指定されることを特徴とする請求項１に記載の構造化文書転送システム。
【請求項６】
前記解析手段は、予め前記ノード情報の解析を行い、該ノード情報を保持しておく手段を持つことを特徴とする請求項１に記載の構造化文書転送システム。
【請求項１】
構造化文書を保持し、受信装置からの受信の依頼に対して該構造化文書を送信する送信装置と、前記構造化文書を受信して処理を行う前記受信装置からなる構造化文書転送システムであって、
前記送信装置は、前記構造化文書の解析及びノード情報の取得依頼を受信する手段と、
前記構造化文書を解析して前記ノード情報を作成する解析手段と、
前記構造化文書のノードに対する条件を受信する手段と、
前記解析手段によって得られた前記ノード情報が前記条件に合っているかを比較する比較手段と、
前記比較手段によって前記条件に合っているとみなされた前記ノード情報を送信する手段とを有し、
前記受信装置は、前記構造化文書の解析及びノード情報の取得依頼を送信する手段と、
前記構造化文書のノードに対する条件を送信する手段と、
前記ノード情報を受信する手段とを有することを特徴とする構造化文書転送システム。
【請求項２】
前記構造化文書は、ＸＭＬであることを特徴とする請求項１に記載の構造化文書転送システム。
【請求項３】
前記送信装置は、非同期に前記受信装置に送信することを特徴とする請求項１に記載の構造化文書転送システム。
【請求項４】
前記送信装置は、前記ノードの取得依頼に対応して前記ノード情報を送信することを特徴とする請求項１に記載の構造化文書転送システム。
【請求項５】
前記ノードに対するノード条件は、ＸＰａｔｈで指定されることを特徴とする請求項１に記載の構造化文書転送システム。
【請求項６】
前記解析手段は、予め前記ノード情報の解析を行い、該ノード情報を保持しておく手段を持つことを特徴とする請求項１に記載の構造化文書転送システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２００９−１９９１８５（Ｐ２００９−１９９１８５Ａ）
【公開日】平成２１年９月３日（２００９．９．３）
【国際特許分類】
【出願番号】特願２００８−３７９００（Ｐ２００８−３７９００）
【出願日】平成２０年２月１９日（２００８．２．１９）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２１年９月３日（２００９．９．３）
【国際特許分類】
【出願日】平成２０年２月１９日（２００８．２．１９）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]