(57)【要約】【課題】  フォーマットが異なる場合でも、１つ構造化文書中に別の構造化文書の一部分であるフラグメントを挿入することができる情報処理装置及びその制御方法、プログラムを提供する。【解決手段】  構造化文書に挿入する構造化文書フラグメントのフォーマットを判定する。判定した構造化文書フラグメントのフォーマットと、構造化文書のフォーマットとの組み合わせに基づいて、構造化文書フラグメントを解析する。解析結果に基づいて、構造化文書フラグメントのフォーマットを構造化文書のフォーマットに変換して、構造化文書に挿入する。【選択図】  図５
2013089048.tif 000002
【特許請求の範囲】
【請求項１】
構造化文書に、前記構造化文書の一部を構成可能である構造化文書フラグメントを挿入して１つの構造化文書を作成する情報処理装置であって、
前記構造化文書に挿入する前記構造化文書フラグメントのフォーマットを判定する判定手段と、
前記判定手段で判定した前記構造化文書フラグメントのフォーマットと、前記構造化文書のフォーマットとの組み合わせに基づいて、前記構造化文書フラグメントを解析する解析手段と、
前記解析手段の解析結果に基づいて、前記構造化文書フラグメントのフォーマットを前記構造化文書のフォーマットに変換して、前記構造化文書に挿入する挿入手段と
を有することを特徴とする情報処理装置。
【請求項２】
前記解析手段は、前記構造化文書のフォーマットと前記構造化文書フラグメントのフォーマットが異なる場合、前記構造化文書フラグメントのフォーマットに従う解析処理によって前記構造化文書フラグメントを解析する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記解析手段は、前記構造化文書のフォーマットと前記構造化文書フラグメントのフォーマットが同一で、かつ前記フォーマットが特定のフォーマットである場合、前記構造化文書フラグメントの特定のフォーマットに従う解析処理によって前記構造化文書フラグメントを解析する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項４】
前記構造化文書のフォーマット及び構造化文書フラグメントのフォーマットは、ＸＭＬ、Ｅｆｆｉｃｉｅｎｔ  ＸＭＬ  Ｉｎｔｅｒｃｈａｎｇｅ、及びＦａｓｔ  Ｉｎｆｏｓｅｔのいずれかである
ことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
【請求項５】
前記解析手段は、前記構造化文書フラグメントの内部状態の情報を用いて、該構造化文書フラグメントを解析する
ことを特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記内部状態は、少なくともＸＭＬにおける名前空間ＵＲＩと名前空間プレフィックスの情報である
ことを特徴とする請求項５に記載の情報処理装置。
【請求項７】
前記挿入手段は、前記構造化文書のフォーマットと、前記解析手段による解析結果から、前記構造化文書フラグメントを前記構造化文書に直接挿入可能であるかを判定し、直接挿入可能である場合には、前記構造化文書フラグメントの少なくとも一部を前記構造化文書に直接挿入する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項８】
前記挿入手段は、前記構造化文書のフォーマットと前記構造化文書フラグメントのフォーマットが、ともにテキストＸＭＬ形式である場合に、前記構造化文書フラグメントを前記構造化文書に直接挿入可能であると判定する
ことを特徴とする請求項７に記載の情報処理装置。
【請求項９】
前記挿入手段は、前記構造化文書のフォーマットと前記構造化文書フラグメントのフォーマットが、ともにＥｆｆｉｃｉｅｎｔ  ＸＭＬ  Ｉｎｔｅｒｃｈａｎｇｅ形式であり、かつ、前記構造化文書フラグメントがＳｅｌｆＣｏｎｔａｉｎｅｄイベントから始まる場合に、前記構造化文書フラグメントを前記構造化文書に直接挿入可能であると判定する
ことを特徴とする請求項７に記載の情報処理装置。
【請求項１０】
構造化文書に、前記構造化文書の一部を構成可能である構造化文書フラグメントを挿入して１つの構造化文書を作成する情報処理装置の制御方法であって、
判定手段が、前記構造化文書に挿入する前記構造化文書フラグメントのフォーマットを判定する判定工程と、
解析手段が、前記判定工程で判定した前記構造化文書フラグメントのフォーマットと、前記構造化文書のフォーマットとの組み合わせに基づいて、前記構造化文書フラグメントを解析する解析工程と、
挿入手段が、前記解析工程の解析結果に基づいて、前記構造化文書フラグメントのフォーマットを前記構造化文書のフォーマットに変換して、前記構造化文書に挿入する挿入工程と
を有することを特徴とする情報処理装置の制御方法。
【請求項１１】
構造化文書に、前記構造化文書の一部を構成可能である構造化文書フラグメントを挿入して１つの構造化文書を作成する情報処理装置の制御をコンピュータに機能させるためのプログラムであって、
前記コンピュータを、
前記構造化文書に挿入する前記構造化文書フラグメントのフォーマットを判定する判定手段と、
前記判定手段で判定した前記構造化文書フラグメントのフォーマットと、前記構造化文書のフォーマットとの組み合わせに基づいて、前記構造化文書フラグメントを解析する解析手段と、
前記解析手段の解析結果に基づいて、前記構造化文書フラグメントのフォーマットを前記構造化文書のフォーマットに変換して、前記構造化文書に挿入する挿入手段と
して機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、構造化文書に、構造化文書の一部を構成可能である構造化文書フラグメントを挿入して１つの構造化文書を作成する情報処理装置及びその制御方法、プログラムに関するものである。
【背景技術】
【０００２】
ＸＭＬをはじめとする構造化文書を作成する際、その構造化文書のフラグメント（特定の一部分）を別の文書作成モジュールで作成して合成したい、ということがある。より具体的には、ＸＭＬ文書中の特定の要素のみを別の文書作成モジュールが作成し、それを別の文書（親文書と呼ぶ）の途中に挿入する、という場合である。例えば、ａという要素のみを持つＸＭＬ文書”＜ａ＞〜＜／ａ＞”に対し、”＜ｂ＞１２３＜／ｂ＞”というフラグメントを挿入するとする。このときは、そのフラグメントを単に”＜ａ＞”と”＜ａ／＞”の間に挿入すればよい。
【０００３】
しかし、近年では文書サイズ削減や処理高速化のため、ＸＭＬ文書の意味を変更せずにバイナリ化を行うバイナリＸＭＬの技術が普及しており、ＸＭＬ文書にもいくつかのフォーマットが現れてきている。このような状況で、フラグメントをそのまま親文書に挿入すると、親文書とフラグメントのフォーマットが異なる場合に不正な（仕様違反）文書となってしまう。そのため、挿入時には何らかの変換等の処理を施さなければならない。
【０００４】
構造化文書フラグメントを挿入する際に、何らかの処理を施したものを挿入するということも従来行われている。例えば、挿入するフラグメントを含む構造化文書全体を取得し、それにスタイルシートを用いた変換処理を行ってから、フラグメントを親文書に挿入する、という技術がある（特許文献１）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００２−１８３１１６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１に開示される構成は、スタイルシートによる変換であり、フォーマットの違いについては解決できないという問題がある。また、フラグメントを含む構造化文書全体を取得して処理を行っているため、フラグメントのみを受け取った場合には正しい処理ができないという問題がある。
【０００７】
そのため、親文書とフラグメントは常に同じフォーマットにしなければならず、すべての文書作成モジュールが同じフォーマットを出力するようにしなければならない。バイナリＸＭＬは新しい技術であり、これに対して、現在の多くの文書作成モジュールは従来どおりのテキスト形式のＸＭＬ文書を出力するようになっているため、これらすべてをバイナリＸＭＬに対応させるのは非常に手間がかかる。すなわち、バイナリＸＭＬによる圧縮や高速化の恩恵を受けられないことを意味する。
【０００８】
本発明は上記の課題を解決するためになされたものであり、フォーマットが異なる場合でも、１つ構造化文書中に別の構造化文書の一部分であるフラグメントを挿入することができる情報処理装置及びその制御方法、プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
構造化文書に、前記構造化文書の一部を構成可能である構造化文書フラグメントを挿入して１つの構造化文書を作成する情報処理装置であって、
前記構造化文書に挿入する前記構造化文書フラグメントのフォーマットを判定する判定手段と、
前記判定手段で判定した前記構造化文書フラグメントのフォーマットと、前記構造化文書のフォーマットとの組み合わせに基づいて、前記構造化文書フラグメントを解析する解析手段と、
前記解析手段の解析結果に基づいて、前記構造化文書フラグメントのフォーマットを前記構造化文書のフォーマットに変換して、前記構造化文書に挿入する挿入手段と
を有する。
【発明の効果】
【００１０】
本発明によれば、１つの構造化文書とそれに挿入する別の構造化文書のフラグメントのフォーマットを合わせることが不要になり、高速な処理が可能になる。
【図面の簡単な説明】
【００１１】
【図１】情報処理装置のハードウェア構成を示す図である。
【図２】情報処理装置のソフトウェア構成を示す図である。
【図３】ＳＯＡＰ通信部の処理を示すフローチャートである。
【図４】ＳＯＡＰ通信部が制御するフラグメント挿入処理を示すフローチャートである。
【図５】フラグメント挿入処理の詳細を。
【図６】ＸＭＬ作成処理を示すフローチャートである。
【図７】ＳＯＡＰ通信部の設定ファイルの一例を示す図である。
【図８】ＸＭＬ作成・解析用インターフェースとイベント型一覧を示す図である。
【図９】ＳＯＡＰ通信部が出力するＳＯＡＰメッセージの一例を示す図である。
【図１０】ＳＯＡＰメッセージを作成するときに呼ばれるメソッド一覧を示す図である。
【図１１】名前空間スタックの一例を示す図である。
【図１２】ＸＭＬフラグメントの一例を示す図である。
【図１３】ＮｅｘｔＥｖｅｎｔメソッドの処理を示すフローチャートである。
【図１４】ＸＭＬフォーマット変換処理を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下、本発明の実施形態について、図面を参照して説明する。なお、以下の実施の形態は特許請求の範囲に関る本発明を限定するものではなく、また、本実施の形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。尚、同一な構成については、同一の符号を付して説明する。
【００１３】
本発明の実施形態である構造化文書を処理する情報処理装置のハードウェア構成を図１に示す。情報処理装置は単一の装置で実現してもよいし、必要に応じて複数の各機能を分散して実現するようにしてもよい。複数の装置で構成される場合は、互いに通信可能なようにＬｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＬＡＮ）等のネットワーク回線で接続される。
【００１４】
図１において、１０２は情報処理装置１００全体を制御するＣｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ（ＣＰＵ）である。１０３は変更を必要としないプログラムやパラメータを格納するＲｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ（ＲＯＭ）である。１０４は外部装置等から供給されるプログラムやデータを一時記憶するＲａｎｄａｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ（ＲＡＭ）である。１０５は装置に固定して設置されたハードディスク、着脱可能なフレキシブルディスク（ＦＤ）やＣｏｍｐａｃｔ  Ｄｉｓｃ（ＣＤ）等の光ディスク、磁気カード等を含む外部記憶装置である。１０６はネットワーク回線と接続するためのネットワークインターフェースである。１０１は１０２から１０６の各ユニットを通信可能に接続するシステムバスである。
【００１５】
この情報処理装置１００は他の装置と通信を行う装置で、その通信データフォーマットはＸＭＬ形式である。ＸＭＬはテキスト形式のデータであるが、近年ではバイナリ形式のフォーマット（特定のフォーマット）も規定されている。これは主に文書のサイズ削減と処理の高速化のために各種圧縮技術等を施したものであり、文書が持つ情報としてはＸＭＬと互換性を持つものの、フォーマットとしての互換性はない。互換性がないとは、あるフォーマットを解析するプログラムでもう一方のフォーマットの文書を解析することができないことである。また、バイナリ形式のＸＭＬフォーマットはいくつの種類があり、ＥＸＩ（Ｅｆｆｉｃｉｅｎｔ  ＸＭＬ  Ｉｎｔｅｒｃｈａｎｇｅ形式）やＦａｓｔ  Ｉｎｆｏｓｅｔ形式等がある。
【００１６】
尚、一般にＸＭＬとはテキスト形式のものを指すが、本明細書で単に「ＸＭＬ」としたときはテキスト形式とバイナリ形式の両方を指している。また、テキスト形式のＸＭＬのみを指す場合は「テキストＸＭＬ」、バイナリ形式のＸＭＬを指す場合は「バイナリＸＭＬ」、あるいはより具体的に「Ｆａｓｔ  Ｉｎｆｏｓｅｔ」や「ＥＸＩ」等の個別の名称を用いる。
【００１７】
次に、本実施形態のソフトウェア構成を図２に示す。ＳＯＡＰ通信部２０１は、ＳＯＡＰメッセージと呼ばれるＸＭＬ形式の文書の送受信を行う。テキストＸＭＬ作成部２０２はテキスト形式の文書を作成する。ＥＸＩ作成部２０３はＥＸＩ形式の文書を作成する。尚、ＥＸＩ作成部２０３は、バイナリ形式のＸＭＬの１つとしてＥＸＩ形式の文書を作成するが、それ以外のバイナリ形式のＸＭＬを作成することも可能である。
【００１８】
フォーマット判定部２０４はＸＭＬ文書のフォーマット（テキストＸＭＬ、ＥＸＩ等）を判定する。テキストＸＭＬ解析部２０５はテキストＸＭＬを解析する。ＥＸＩ解析部２０６はＥＸＩを解析する。尚、ＥＸＩ解析部２０６は、バイナリ形式のＸＭＬの１つとしてＥＸＩ形式の文書を解析するが、それ以外のバイナリ形式のＸＭＬを解析することも可能である。２０７、２０８は通信アプリケーションであり、ＳＯＡＰ通信部２０１を用いて他の装置と通信を行うアプリケーションソフトウェアである。
【００１９】
尚、ＳＯＡＰ（Simple Object Access Protocol）は汎用的な通信プロトコルである。このＳＯＡＰでは、１つの装置が複数のＳＯＡＰアプリケーション（通信アプリケーション２０７、２０８等）を持ち、共通のＳＯＡＰ通信部を利用する構成は現在広く行われている方式である。
【００２０】
ＳＯＡＰ通信部２０１がＳＯＡＰメッセージを作成するフローを図３に示す。まず、ＳＯＡＰ通信部２０１は、ＳＯＡＰ通信全般に関する設定ファイルを読み込む（ステップＳ３０２）。この設定ファイルは外部記憶装置１０５に保存されており、あらかじめ設定しされている。また、設定ファイルは少なくともＸＭＬ文書のフォーマットの情報と、ＥＸＩの場合にはＥＸＩオプションの情報を記述している。
【００２１】
これにより、ＳＯＡＰ通信部２０１は、ＳＯＡＰメッセージを作成するために、テキストＸＭＬ作成部２０２とＥＸＩ作成部２０３のどちらを使うかを選択するための判定を行う。より具体的には、ＳＯＡＰ通信部２０１は、設定ファイルで記述されるフォーマットの情報が、ＥＸＩであるか否かを判定する（ステップＳ３０３）。ＥＸＩである場合（ステップＳ３０３でＹＥＳ）、ステップＳ３０４に進み、ＥＸＩ作成部２０３を選択する。一方、ＥＸＩでない場合（ステップＳ３０３でＮＯ）、ステップＳ３０５に進み、テキストＸＭＬ作成部２０２を作成する。
【００２２】
設定ファイルはテキスト形式で、パラメータと値をスペースで区切った形式となっている。具体例としては、図７の７ａ及び７ｂのようになる。７ａがフォーマットがＥＸＩの例、７ｂがフォーマットがテキストＸＭＬの例を示している。ここで、設定ファイルが７ａであるとすると、フォーマットはＥＸＩ、オプションとしてＰｒｅｓｅｒｖｅＰｒｅｆｉｘが設定されている。この場合、ＳＯＡＰ通信部２０１は、ＥＸＩ作成部２０３を選択する（ステップＳ３０４）。
【００２３】
前述のとおりテキストＸＭＬとＥＸＩは、フォーマットは異なるもののほぼ同じデータモデルを有する。そのため、作成用のメソッドもほぼ同じものにすることができる。図８の８ａにＥＸＩ作成部２０３及びテキストＸＭＬ作成部２０２のインターフェースを示す。ここで、ＷｒｉｔｅＳｅｌｆＣｏｎｔａｉｎｅｄ及びＳｅｔＯｐｔｉｏｎの２つはＥＸＩ作成部２０３のみが持ち、その他のメソッドは両者が同じ名前のものを持つ。また、ＷｒｉｔｅＲａｗメソッドの引数は記していないが、これは特殊なメソッドでありＸＭＬフラグメントと呼ばれるデータを引数に取る。ＷｒｉｔｅＲａｗメソッド及びＸＭＬフラグメントについては後述する。
【００２４】
尚、図８の８ｂは、ＸＭＬ文書・フラグメントの解析に使われるメソッドである。また、図８の８ｃは、図８の８ａのインターフェースで用いる、各種イベントである。図８の８ｃでは、イベント型と、その略称、及びその意味を示している。例えば、イベント型「ＳｔａｒｔＥｌｅｍｅｎｔ」は、略称が「ＳＥ」であり、その意味は開始タグである。
【００２５】
フォーマットがＥＸＩの場合には、ＥＸＩオプションの設定が必要であり、ＳＯＡＰ通信部２０１は、ＥＸＩオプションの設定を行う（ステップＳ３０６）。ＥＸＩオプションの設定にはＳｅｔＯｐｔｉｏｎメソッドを使い、その値として、設定ファイルに記述されているＰｒｅｓｅｒｖｅＰｒｅｆｉｘを指定する。ＥＸＩオプションにはいくつの種類があるが、それぞれの詳細については本発明とは関連が低いため説明は省略する。但し、ＥＸＩオプションの設定によって、出力されるデータのフォーマットが変わるという点は重要である。例えば、ここで指定されたＰｒｅｓｅｒｖｅＰｒｅｆｉｘオプションは、ＥＸＩ文書中に名前空間プレフィックスの値を保存するか、しないかを決める。
【００２６】
ＥＸＩオプションを指定したら、ＳＯＡＰ通信部２０１は、ＳＯＡＰメッセージのうち、他モジュール担当部分（つまり、フラグメント挿入箇所）の直前までを作成する（ステップＳ３０７）。ＳＯＡＰ通信部２０１が作成するＳＯＡＰメッセージは、テキストＸＭＬ形式の場合、図９の９ａとなる。ＳＯＡＰメッセージ全体はＥｎｖｅｌｏｐｅ（＜ｓｏａｐ：Ｅｎｖｅｌｏｐｅ〜＜／ｓｏａｐ：Ｅｎｖｅｌｏｐｅ＞）という要素に含まれる。また、その中にＨｅａｄｅｒ要素（＜ｓｏａｐ：Ｈｅａｄｅｒ＞〜＜／ｓｏａｐ：Ｈｅａｄｅｒ＞）とＢｏｄｙ要素（＜ｓｏａｐ：Ｂｏｄｙ＞〜＜ｓｏａｐ：Ｂｏｄｙ＞）が含まれる。Ｈｅａｄｅｒ要素には、通信の制御を行う情報が格納されるものであり、ＳＯＡＰ通信部２０１が処理を担当する。一方、Ｂｏｄｙ要素は転送されるデータ本体であり、通信アプリケーション２０７等が処理を担当する。従って、ステップＳ３０７では、ＳＯＡＰ通信部２０１は、ＳＯＡＰメッセージ中の図９の９ａ０７に相当する箇所までを作成する。
【００２７】
ＳＯＡＰ通信部２０１がこのＳＯＡＰメッセージを作成するために呼ぶメソッドは図１０のとおりである。ＥＸＩ及びテキストＸＭＬいずれの場合もこの１００１から１００９の順でメソッドが呼ばれる。また、ステップＳ３０７では、このうちの１００１から１００６までのメソッドが呼ばれる。
【００２８】
設定ファイルに対して、最初に記述するものは、Ｅｎｖｅｌｏｐｅ開始タグであるため、ＳＯＡＰ通信部２０１は、１００１に示すＷｒｉｔｅＳｔａｒｔＥｌｅｍｅｎｔメソッドを呼ぶ。引数はＰｒｅｆｉｘ＝”ｓｏａｐ”、名前空間ＵＲＩはＮａｍｅｓｐａｃｅＵＲＩ＝”ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００３／０５／ｓｏａｐ−ｅｎｖｅｌｏｐｅ”である。また、ＬｏｃａｌＮａｍｅは”Ｅｎｖｅｌｏｐｅ”である。
【００２９】
尚、名前空間ＵＲＩの文字列は一般に長くなるため、本明細書では、以降、このＵＲＩを［ｎｓ−ｓｏａｐ］と記述する。
【００３０】
ここで、ＥＸＩ作成部２０３によるＷｒｉｔｅＳｔａｒｔＥｌｅｍｅｎｔメソッドの動作を図６（ａ）に示す。また、ＥＸＩ作成部２０３は作成中に適宜変化する内部状態を持ち、これには深さと名前空間テーブルが含まれる。深さ（ｄｅｐｔｈ）は整数であり、現在の要素の階層の深さを表す。初期状態は０である。名前空間スタックは深さ、プレフィックス、名前空間ＵＲＩの３つからなるデータのスタック形式の情報であり、図１１のようなデータである。初期状態は１１ａのように、空の状態である。
【００３１】
ＷｒｉｔｅＳｔａｒｔＥｌｅｍｅｎｔメソッドでは、まず、指定された開始タグイベントを書き込む（ステップＳ６ａ０２）。開始タグイベントは少なくとも名前空間ＵＲＩとローカル名を持ち、また、ＰｒｅｓｅｒｖｅＰｒｅｆｉｘオプションがある場合はさらにプレフィックスの情報を持つデータである。出力されるＥＸＩ文書全体は図９の９ｂに示すが、この段階では９ｂ０２の開始タグイベント（ＳＥイベント）が出力された状態である。
【００３２】
ＥＸＩ文書はバイナリ形式であるため、ここではＥＸＩ文書の構成を、図９の９ｂでは、表形式で表す。ＥＸＩ文書は最初に９ｂ０１に示すようなオプション情報（ＥＸＩヘッダ）があり、以降９ｂ０２からは各イベント（図８の８ｃで示されるような）のデータが記述される。各イベントは少なくともイベントの種類（Ｔｙｐｅ）の情報を有し、また、その種類に応じてローカル名（ＬｏｃａｌＮａｍｅ）や値（Ｖａｌｕｅ）を有する。イベントの種類によっては何の情報を持つかは異なり、情報を持たないものはハイフン（−）で示している。
【００３３】
ＷｒｉｔｅＳｔａｒｔＥｌｅｍｅｎｔメソッドは、次に、ｄｅｐｔｈの値を１増加する（ステップＳ６ａ０３）。よって、１になる。次に、指定されたＰｒｅｆｉｘ（ここでは”ｓｏａｐ”）がＮａｍｅｓｐａｃｅＵＲＩ（［ｎｓ−ｓｏａｐ］）にバインドされているか否かを判定する（ステップＳ６ａ０４）。バインドされている場合（ステップＳ６ａ０４でＹＥＳ）、処理を終了する。一方、バインドされていない場合（ステップＳ６ａ０４でＮＯ）、ステップＳ６ａ０５に進む。
【００３４】
名前空間のバインドの状態は名前空間スタックを参照することで得られる。現在、図１１の１１ａの状態であり、”ｓｏａｐ”に関する情報はない。よって、この場合、９ｂ０３のＮＳイベント（名前空間宣言）を書き込む（ステップＳ６ａ０５）。次に、名前空間スタックに、このプレフィックス、ＵＲＩ、現在のｄｅｐｔｈを登録する（ステップＳ６ａ０６）。この結果、名前空間スタックは図１１の１１ｂのようになる。これでＷｒｉｔｅＳｔａｒｔＥｌｅｍｅｎｔメソッドの処理を終了する。
【００３５】
次に、ＳＯＡＰ通信部２０１は、図９の９ａ０３に相当する箇所の記述を行うため、図１０の１００２に示すＷｒｉｔｅＮｓＤｅｃｌメソッドを呼ぶ。引数はＰｒｅｆｉｘ＝”ｅｎｃ”、ＮａｍｅｓｐａｃｅＵＲＩ＝”ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／０４／ｘｍｌｅｎｃ＃”である（先ほどと同様、このＵＲＩの文字列を［ｎｓ−ｅｎｃ］で表す）。
【００３６】
ＥＸＩ作成部２０３によるＷｒｉｔｅＮｓＤｅｃｌメソッドの動作を図６（ｃ）に示す。ＷｒｉｔｅＮｓＤｅｃｌメソッドは、名前空間スタックに、ｄｅｐｔｈ、プレフィックス、ＵＲＩの３つがすべて等しいデータがあるか否かを判定する（ステップＳ６ｃ０２）。等しいデータがある場合（ステップＳ６ｃ０２でＹＥＳ）、処理を終了する。一方、等しいデータがない場合（ステップＳ６ｃ０２でＮＯ）、ステップＳ６ｃ０３に進み、ＮＳイベントを書き込む（ステップＳ６ｃ０３）。次に、名前空間スタックに、指定されたプレフィックス、ＵＲＩ、現在のｄｅｐｔｈ−１を追加する（ステップＳ６ｃ０４）。その結果、図９の９ｂ０４のＮＳイベントが書き込まれ、名前空間スタックは図１１の１１ｃのようになる。
【００３７】
同様に、図９の９ａ０４に相当する開始タグイベントを書き込むため、図１０の１００３に示すＷｒｉｔｅＳｔａｒｔＥｌｅｍｅｎｔメソッドを呼ぶ。このときは、指定されたプレフィックス（”ｓｏａｐ”）とＵＲＩ（［ｎｓ−ｓｏａｐ］）はすでに名前空間スタック１１ｃに含まれているため、ＮＳイベントは出力されない。また、ｄｅｐｔｈの値は２になる。
【００３８】
以降で、本来は、ＳＯＡＰヘッダの内容が書き込まれるが、本発明とは関連が低いため、ここでは、ＳＯＡＰヘッダの内容については省略する。ＳＯＡＰヘッダの内容が書き込まれると、図９の９ａ０６に相当する終了タグイベントを書き込むため、図１０の１００５に示すＷｒｉｔｅＥｎｄＥｌｅｍｅｎｔメソッドを呼ぶ。
【００３９】
ＥＸＩ作成部２０３によるＷｒｉｔｅＥｎｄＥｌｅｍｅｎｔメソッドの動作を図６（ｂ）に示す。まず、終了タグイベントを書き込む（ステップＳ６ｂ０２）。これにより、図９の９ｂ０７の終了タグイベント（ＥＥイベント）が出力される。次に、ｄｅｐｔｈの値を１減少する（ステップＳ６ｂ０３）。現在の値は２であったため、１になる。そして、名前空間スタックのうち、「ｄｅｐｔｈ＜現在のｄｅｐｔｈ」となっているものを削除する（ステップＳ６ｂ０４）。この段階の名前空間スタックの状態は１１ｃであり、その１１ｃにおけるｄｅｐｔｈはいずれも１であり、この条件を満たさない。よって、ここでは何もしない。これで、ＷｒｉｔｅＥｎｄＥｌｅｍｅｎｔメソッドの処理は終了する。
【００４０】
この名前空間スタックにあるデータのｄｅｐｔｈと、現在のｄｅｐｔｈにより、名前空間の有効範囲が適切に管理されている。つまり、名前空間ＵＲＩは、それが指定された開始タグに対応する終了タグまでであるというＸＭＬの仕様に基づく処理が行われている。
【００４１】
以降、同様に、図９の９ａ０７に相当する開始タグイベントを書き込むため、図１０の１００６のＷｒｉｔｅＳｔａｒｔＥｌｅｍｅｎｔメソッドを呼び、図９の９ｂ０８の開始タグイベントが出力される。９ｂ０２から９ｂ０８のイベントが出力されることにより、ステップＳ３０７の処理が終了する。
【００４２】
次に、ＳＯＡＰ通信部２０１は、Ｂｏｄｙの中身となるデータ（ＸＭＬ文書の一部を構成するデータ）を通信アプリケーション（例えば、通信アプリケーション２０７等から受け取る（ステップＳ３０８）。ここで、このようなＸＭＬ文書の一部を構成するデータをＸＭＬフラグメントと呼び、また、本明細書では単にフラグメントと呼ぶ。
【００４３】
例えば、通信アプリケーション２０７が作成したフラグメントを図１２の１２ａに示す。ＳＯＡＰ通信部２０１は、図１２の１２ａに示す文字列そのものを受け取り、そのフラグメントをＳＯＡＰメッセージに書き込む（ステップＳ３０９）。この処理は、ＷｒｉｔｅＲａｗメソッドを呼ぶことで行われる。前述のとおり、ＷｒｉｔｅＲａｗメソッドはフラグメントを引数に取る。
【００４４】
ＥＸＩ作成部２０３及びテキストＸＭＬ作成部２０２が持つＷｒｉｔｅＲａｗメソッドの処理を図４に示す。まず、与えられたフラグメントのフォーマットを判定する（ステップＳ４０２）。
【００４５】
尚、ＥＸＩのデータは、その仕様により、必ず最初にＤｉｓｔｉｎｇｕｉｓｈｉｎｇ  Ｂｉｔｓと呼ばれるビット列から始まり、最初のバイトの上位２ビットは１０となる。一方、テキストＸＭＬで使われる文字エンコーディングは通常ＵＴＦ−８またはＵＴＦ−１６である。ＵＴＦ−８では１０から始まるバイトはその仕様上存在しない。
【００４６】
また、テキストＸＭＬの仕様では、ＵＴＦ−１６を扱う場合は必ずＢＯＭ（Ｂｙｔｅ  Ｏｒｄｅｒ  Ｍａｒｋ）と呼ばれる特殊な文字を最初に入れることになっている。ＢＯＭも最初のビットは１０ではない。従って、最初の２ビットが１０であればＥＸＩ、それ以外はテキストＸＭＬとみなすことができる。
【００４７】
図１２の場合、１２ａのフラグメントも文字列であるため、最初の２ビットが１０になることはなく、テキストＸＭＬであると判定される。
【００４８】
次に、親子関係にある構造化文書である親文書（構造化文書からなる親構造化文書）と子文書（構造化文書の一部を構成可能である構造化文書フラグメント）の組み合わせによって、４種類の処理（ステップＳ４０４からステップＳ４０７）のいずれかを行う。本例の場合、現在、親文書はＥＸＩ文書であり、子文書であるフラグメントはテキストＸＭＬと判定される。従って、ＥＸＩ文書へのテキストＸＭＬフラグメントの挿入処理を実行する（ステップＳ４０７）。
【００４９】
この挿入処理の詳細を図５（ａ）に示す。この場合、親文書と子文書（フラグメント）のフォーマットが異なるため直接挿入することはできず、テキストＸＭＬフラグメントのフォーマットをＥＸＩに変換することになる。テキストＸＭＬフラグメントをＥＸＩに変換することは、つまり、テキストＸＭＬを解析し、その解析結果をＥＸＩ作成部２０３を用いて書き出す、ということである。しかし、テキストＸＭＬフラグメントの解析は、ＸＭＬ文書全体を解析するＸＭＬパーサでは解析できないことがある。これは、ＸＭＬフラグメントは、それ単独ではＸＭＬ文書としての仕様を満たしていないことがあるからである。そして、図１２の１２ａのフラグメントもそのようなケースの１つである。
【００５０】
例えば、図１２の１２ａにおいて、１２ａ０１行は＜ｅｎｃ：ＣｉｐｈｅｒＤａｔａ＞であり、テキストＸＭＬの仕様から、これが開始タグであることが判別できる。また、プレフィックスは”ｅｎｃ”、ローカル名は”ＣｉｐｈｅｒＤａｔａ”である。しかし、名前空間ＵＲＩは判別することができない。なぜなら、プレフィックスである”ｅｎｃ”に対応する名前空間ＵＲＩの定義がないためである。
【００５１】
そのため、ＥＸＩ作成部２０３は、ｄｅｐｔｈを０にした名前空間スタックをテキストＸＭＬ解析部２０５に渡す（ステップＳ５ａ０２）。現在の名前空間スタックは、図１１の１１ｃの状態であり、これらのｄｅｐｔｈを０にしたもの、つまり、図１１の１１ｄの名前空間スタックが渡される。そして、その名前空間スタックをテキストＸＭＬ解析部２０５で解析する。ＸＭＬ文書・フラグメントの解析に使われるメソッドを図８の８ｂに示す。ＸＭＬ作成の場合と同様、テキストＸＭＬとバイナリＸＭＬでインターフェースはほぼ同じである。ＧｅｔＯｐｔｉｏｎメソッドのみはＥＸＩ解析部２０６のみが持ち、それ以外は両者が同じ名前のメソッドを持つ。
【００５２】
これらのメソッドを使って、テキストＸＭＬ解析部２０５はテキストＸＭＬを解析する（ステップＳ５ａ０３）。そして、テキストＸＭＬ解析部２０５は、解析結果をＥＸＩ作成部２０３に入力する（ステップＳ５ａ０４）。これにより、テキストＸＭＬフラグメントをＥＸＩ文書の一部として挿入することができる。
【００５３】
この処理を図１４に示す。まず、図８の８ｂにあるメソッドのうち、ＮｅｘｔＥｖｅｎｔメソッドを繰り返し使うことで、フラグメント中のすべてのイベントを辿ることが可能である。そこで、次の取得対象のイベントを取得する（ステップＳ１４０２）。
【００５４】
イベントを取得すると、ＧｅｔＴｙｐｅメソッドでイベントの情報としてその種類を取得する（ステップＳ１４０４）。次に、その種類と同じ種類のイベントを出力するＥＸＩ作成部２０３（／テキストＸＭＬ作成部２０２）のメソッドに対して、イベントのデータを渡す（ステップＳ１４０５）。このとき、イベントのデータの取得には、ＧｅｔＰｒｅｆｉｘメソッド、ＧｅｔＮａｍｅｓｐａｃｅＵＲＩメソッド、ＧｅｔＬｏｃａｌＮａｍｅメソッド、ＧｅｔＶａｌｕｅメソッドの結果を用いる。その結果、フラグメントはＥＸＩ文書の一部として出力される。
【００５５】
次に、取得対象の全イベントを取得したか否かを判定する。全イベントを取得していない場合（ステップＳ１４０６でＮＯ）、ステップＳ１４０２に戻り、次のイベントを取得する。一方、全イベントを取得した場合（ステップＳ１４０６でＹＥＳ）、処理を終了する。
【００５６】
次に、テキストＸＭＬ解析部２０５のＮｅｘｔＥｖｅｎｔメソッドの詳細を図１３に示す。テキストＸＭＬ解析部２０５には、図１１の１１ｄに示す名前空間スタックが渡されていることに注意されたい。まず、処理対象の次のイベントがあるか否かを判定する（ステップＳ１３０２）。イベントがない場合（ステップＳ１３０２でＮＯ）、処理を終了する。一方、イベントがある場合（ステップＳ１０３２でＹＥＳ）、ステップＳ１３０３に進み、そのイベントを解析する（ステップＳ１３０３）。次に、解析結果に基づいて、イベントの種類を判定して、その判定した種類に基づいて処理を分岐する（ステップＳ１３０４）。
【００５７】
具体的には、イベントが開始タグイベント（ＳＥ）、終了タグイベント（ＥＥ）、それ以外のイベントであるかに基づいて、処理を分岐する。
【００５８】
図１２の１２ａのフラグメントの場合は、最初のイベントである１２ａ０１を解析する。これは開始タグイベントであるため、ステップＳ１３０５に進む。但し、１２ａ０１には名前空間宣言はないため、この場合、ステップＳ１３０５はスキップする。次に、プレフィックスから名前空間ＵＲＩを探索する（ステップＳ１３０６）。プレフィックスは”ｅｎｃ”であるが、図１２の１２ａのフラグメントにはこのプレフィックスが示す名前空間ＵＲＩの情報がない。しかし、名前空間スタックは、図１１の１１ｄのようになっており、”ｅｎｃ”が表すＵＲＩが”ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／０４／ｘｍｌｅｎｃ＃”であることがわかる。このようにして、本来解析できないテキストＸＭＬフラグメントの解析が可能になる。そして、ｄｅｐｔｈの値を１増加する（ステップＳ１３０７）。
【００５９】
尚、名前空間スタックのスコープ管理はＥＸＩ作成部２０３と同様、ｄｅｐｔｈの情報を用いて管理されており、ステップ１３０７や、ステップＳ１３０９、ステップＳ１３１０で処理されている。ここで、ステップＳ１３０８〜ステップＳ１３１０は、イベントが終了タグイベント（ＥＥ）の場合の処理である。ステップＳ１３０８は、ステップＳ１３０６と同様である。次に、ｄｅｐｔｈの値を１減少する（ステップＳ１３０９）。そして、名前空間スタックのうち、ｄｅｐｔｈが等しいものを削除する（ステップＳ１３１０）。
【００６０】
このようにして、ＳＯＡＰ通信部２０１がＥＸＩ形式のＳＯＡＰメッセージを作成し、通信アプリケーションがテキストＸＭＬフラグメントを作成した場合でも、ＥＸＩ文書として出力することができる。
【００６１】
次に、ＳＯＡＰ通信部２０１がＥＸＩ形式でＳＯＡＰメッセージを作成し、通信アプリケーション２０８が出力するＥＸＩフラグメントを挿入する場合について説明する。また、このときのＥＸＩフラグメントを図１２ｂに示す。すなわち、これは１２ａに表すテキストＸＭＬフラグメントに対応するＥＸＩフラグメントである。
【００６２】
ＳＯＡＰ通信部２０１は先ほどと同様、ステップＳ３０２から開始し、ステップＳ３０８までは同じ結果になる。つまり、図９の９ｂの９ｂ０８まで出力した状態である。次に、ステップＳ３０９の処理、詳しくは、図４の処理を行う。このとき、ステップＳ４０２において、フラグメントはＥＸＩと判定される。従って、このケースでは、ＥＸＩ文書へのＥＸＩフラグメントの挿入処理を実行する（ステップＳ４０５）。
【００６３】
この挿入処理の詳細を図５（ｃ）に示す。まず、ＥＸＩヘッダにあるオプションを読み込む（ステップＳ５ｃ０２）。図１２の１２ｂのＥＸＩフラグメントのオプションは、１２ｂ０１の情報である。これと親文書のオプションと比較して、同じであるか否かを判定する（ステップＳ５ｃ０３）。同じである場合（ステップＳ５ｃ０３でＹＥＳ）、ステップＳ５ｃ０４へ進む。一方、同じでない場合（ステップＳ５ｃ０３でＮＯ）、ステップＳ５ｃ０８へ進む。
【００６４】
親文書は図９の９ｂにおける９ｂ０１から９ｂ０８の状態であるが、このうちのオプションは９ｂ０１である。このとき、２つのオプションは一致している。そのため、この場合、最初のイベントを読み込む（ステップＳ５ｃ０４）。次に、読み込んだイベントがＳＣ（ＳｅｌｆＣｏｎｔａｉｎｅｄ）イベントであるか否かを判定する（ステップＳ５ｃ０５）。ＳＣ（ＳｅｌｆＣｏｎｔａｉｎｅｄ）イベントである場合（ステップＳ５ｃ０５でＹＥＳ）、ステップＳ５ｃ０６へ進む。一方、ＳＣ（ＳｅｌｆＣｏｎｔａｉｎｅｄ）イベントでない場合（ステップＳ５ｃ０５でＮＯ）、ステップＳ５ｃ０８へ進む。
【００６５】
本例の場合、最初のイベントは、図１２の１２ｂの１２ｂ０２のＳＣ（ＳｅｌｆＣｏｎｔａｉｎｅｄ）イベントである。ＳＣイベントはＥＸＩに特有のイベントであり、ＥＸＩの符号化規則がここでリセットされることを意味する。通常、ＥＸＩの符号化規則（イベントの種類や内容といった情報を、どのようなビット列で表すかの規則）が、イベントが進むごとに変更されることになっている。そのため、あるＥＸＩフラグメントを別のＥＸＩ文書の途中に挿入することはできない。ＳＣイベントは、符号化規則がリセットされるため、図１２の１２ｂの１２ｂ０３以降のイベントは初期状態から行われている。従って、このＥＸＩフラグメントは、図１２の１２ｂの１２ｂ０２のＳＣイベント以降をそのまま親文書に挿入可能である。よって、現在（ＳＣイベント）のバイトオフセットを取得する（ステップＳ５ｃ０６）。そして、そのオフセット以降をそのまま出力する（ステップＳ５ｃ０７）。つまり、ＥＸＩフラグメントをＥＸＩ文書に直接挿入可能である。
【００６６】
これにより、ステップＳ３０９の処理が終了する。次のステップＳ３１０は、先ほどと同様である。このようにして、ＥＸＩフラグメントが挿入されたＥＸＩ文書が出力される。結果として、図９の９ｂの９ｂ０８と９ｂ０９の間に、図１２の１２ｂの１２ｂ０２から１２ｂ０５が挿入されたものになる。図９の９ｂの９ｂ０２から９ｂ０８と、図１２の１２ｂの１２ｂ０３以降はその符号化規則が異なるものになっているが、図１２の１２の１２ｂ０２のＳＣイベントによって符号化規則がリセットされる。そのため、ＥＸＩ解析部２０６も、問題なく解析することが可能である。
【００６７】
尚、親文書のＥＸＩ文書と子文書のＥＸＩフラグメントのオプションが異なる場合（ステップＳ５ｃ０３でＮＯ）や、ＥＸＩフラグメントがＳＣイベントで始まらない場合（ステップＳ５ｃ０５でＮＯ）、ＥＸＩフラグメントをそのまま挿入することができない。そのため、この場合は、イベントの解析結果をＥＸＩ作成部２０３に入力する（ステップＳ５ｃ０８）。これは、つまり、異なる符号化規則で符号化されたＥＸＩフラグメントを変換して出力するということである。この処理は図１４の処理と同様である。
【００６８】
この結果、図９の９ｂの９ｂ０８と９ｂ０９の間に、図１２の１２ｃの１２ｃ０２から１２ｃ０４が挿入されたＥＸＩ文書が作成される。但し、図１２の１２ｃの１２ｃ０２から１２ｃ０４はその意味は変わらないものの、親文書の符号化規則に従って再符号化されているため、ビット表現としては異なるものになっている。
【００６９】
以上で、ＳＯＡＰ通信部２０１がＥＸＩ形式のＳＯＡＰメッセージを出力する場合に、通信アプリケーションがテキストＸＭＬ・ＥＸＩフラグメントのいずれを出力した場合でも、正しいＥＸＩ文書を出力することができる。また、ＥＸＩフラグメントを直接挿入可能である場合には、そのまま埋め込むことでＥＸＩフラグメントの変換処理をなくし、処理を高速化可能である。
【００７０】
今度は、ＳＯＡＰ通信部２０１がテキストＸＭＬ形式のＳＯＡＰメッセージを出力する場合について説明する。つまり、設定ファイルが７ｂのようになっている場合である。このときも先ほどと同様、通信アプリケーションがテキストＸＭＬフラグメント１２ａを出力する場合と、ＥＸＩフラグメント（１２ｂ、１２ｃ）を出力する場合がある。
【００７１】
ＳＯＡＰ通信部２０１の処理は同様に図３に従う。但し、文書の作成にテキストＸＭＬ作成部２０２を選択する（ステップＳ３０５）。よって、ステップＳ３０７まで処理した段階で、図９の９ａにおける９ａ０１から９ａ０７までが出力された状態になる。
【００７２】
ここで、フラグメントを受け取るが（ステップＳ３０８）、ここで、図１２の１２ｂのＥＸＩフラグメントを受け取る場合を説明する。このときは、ステップＳ３０９、つまり図４の処理において、テキストＸＭＬ文書へのＥＸＩフラグメントの挿入処理を実行する（ステップＳ４０６）。
【００７３】
この挿入処理の詳細を図５（ｂ）に示す。親文書と子文書（フラグメント）のフォーマットが異なるため直接挿入することはできず、ＥＸＩフラグメントをテキストＸＭＬとして変換することになる。この処理は図１４と同様である。また、図１２の１２ｂに示すように、ＥＸＩフラグメントの開始タグ・終了タグイベントには名前空間ＵＲＩの情報が含まれている。これは、つまり、先に説明したテキストＸＭＬフラグメントの解析処理にあった問題（プレフィックスに対応する名前空間ＵＲＩが不明である）がないことを意味する。よって、ＥＸＩフラグメントは特別な処理をすることなくＥＸＩ解析部２０６で解析可能である（ステップＳ５ｂ０２）。あとは、この解析結果をテキストＸＭＬ作成部２０２に入力すればよい（ステップＳ５ｂ０３）。この挿入処理と、続くステップＳ３１０を行うことで、図９の９ａの９ａ０７と９ａ０８の間に、図１２の１２ａが挿入されたテキストＸＭＬ文書が出力される。
【００７４】
最後に、テキストＸＭＬ文書中にテキストＸＭＬフラグメントが渡された場合を説明する。つまり、図９の９ａ０７まで出力した状態で、図１２の１２ａが渡された場合である。このときは従来通りの処理であり、テキストＸＭＬフラグメントをそのまま出力する（ステップＳ４０４）。つまり、テキストＸＭＬフラグメントをテキストＸＭＬ文書に直接挿入可能である。結果として、図９の９ａ０７と９ａ０８の間に図１２の１２ａが挿入されたテキストＸＭＬ文書が出力される。
【００７５】
以上のように、本実施形態では、ＳＯＡＰ通信部２０１と通信アプリケーション２０７等がそれぞれＥＸＩ形式・テキストＸＭＬ形式を出力する場合の４つのパターンがあり、いずれの場合も正しいＸＭＬ文書として出力される。また、本実施形態によれば、特に、親文書がＥＸＩの場合は、子文書がテキストＸＭＬの場合でも全体をＥＸＩとして出力するため、サイズの削減や高速な処理が可能である。
【００７６】
尚、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステムまたは装置に供給し、そのシステムまたは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【図１】
2013089048.tif 000003
【図２】
2013089048.tif 000004
【図３】
2013089048.tif 000005
【図４】
2013089048.tif 000006
【図５】
2013089048.tif 000007
【図６】
2013089048.tif 000008
【図７】
2013089048.tif 000009
【図８】
2013089048.tif 000010
【図９】
2013089048.tif 000011
【図１０】
2013089048.tif 000012
【図１１】
2013089048.tif 000013
【図１２】
2013089048.tif 000014
【図１３】
2013089048.tif 000015
【図１４】
2013089048.tif 000016