構造化文書に、前記構造化文書の一部を構成可能である構造化文書フラグメントを挿入して1つの構造化文書を作成する情報処理装置であって、前記構造化文書に挿入する前記構造化文書フラグメントのフォーマットを判定する判定手段と、前記判定手段で判定した前記構造化文書フラグメントのフォーマットと、前記構造化文書のフォーマットとの組み合わせに基づいて、前記構造化文書フラグメントを解析する解析手段と、前記解析手段の解析結果に基づいて、前記構造化文書フラグメントのフォーマットを前記構造化文書のフォーマットに変換して、前記構造化文書に挿入する挿入手段とを有することを特徴とする情報処理装置。前記解析手段は、前記構造化文書のフォーマットと前記構造化文書フラグメントのフォーマットが異なる場合、前記構造化文書フラグメントのフォーマットに従う解析処理によって前記構造化文書フラグメントを解析することを特徴とする請求項1に記載の情報処理装置。前記解析手段は、前記構造化文書のフォーマットと前記構造化文書フラグメントのフォーマットが同一で、かつ前記フォーマットが特定のフォーマットである場合、前記構造化文書フラグメントの特定のフォーマットに従う解析処理によって前記構造化文書フラグメントを解析することを特徴とする請求項1に記載の情報処理装置。前記構造化文書のフォーマット及び構造化文書フラグメントのフォーマットは、XML、EfficientXMLInterchange、及びFastInfosetのいずれかであることを特徴とする請求項1乃至3のいずれか1項に記載の情報処理装置。前記解析手段は、前記構造化文書フラグメントの内部状態の情報を用いて、該構造化文書フラグメントを解析することを特徴とする請求項4に記載の情報処理装置。前記内部状態は、少なくともXMLにおける名前空間URIと名前空間プレフィックスの情報であることを特徴とする請求項5に記載の情報処理装置。前記挿入手段は、前記構造化文書のフォーマットと、前記解析手段による解析結果から、前記構造化文書フラグメントを前記構造化文書に直接挿入可能であるかを判定し、直接挿入可能である場合には、前記構造化文書フラグメントの少なくとも一部を前記構造化文書に直接挿入することを特徴とする請求項1に記載の情報処理装置。前記挿入手段は、前記構造化文書のフォーマットと前記構造化文書フラグメントのフォーマットが、ともにテキストXML形式である場合に、前記構造化文書フラグメントを前記構造化文書に直接挿入可能であると判定することを特徴とする請求項7に記載の情報処理装置。前記挿入手段は、前記構造化文書のフォーマットと前記構造化文書フラグメントのフォーマットが、ともにEfficientXMLInterchange形式であり、かつ、前記構造化文書フラグメントがSelfContainedイベントから始まる場合に、前記構造化文書フラグメントを前記構造化文書に直接挿入可能であると判定することを特徴とする請求項7に記載の情報処理装置。構造化文書に、前記構造化文書の一部を構成可能である構造化文書フラグメントを挿入して1つの構造化文書を作成する情報処理装置の制御方法であって、判定手段が、前記構造化文書に挿入する前記構造化文書フラグメントのフォーマットを判定する判定工程と、解析手段が、前記判定工程で判定した前記構造化文書フラグメントのフォーマットと、前記構造化文書のフォーマットとの組み合わせに基づいて、前記構造化文書フラグメントを解析する解析工程と、挿入手段が、前記解析工程の解析結果に基づいて、前記構造化文書フラグメントのフォーマットを前記構造化文書のフォーマットに変換して、前記構造化文書に挿入する挿入工程とを有することを特徴とする情報処理装置の制御方法。構造化文書に、前記構造化文書の一部を構成可能である構造化文書フラグメントを挿入して1つの構造化文書を作成する情報処理装置の制御をコンピュータに機能させるためのプログラムであって、前記コンピュータを、前記構造化文書に挿入する前記構造化文書フラグメントのフォーマットを判定する判定手段と、前記判定手段で判定した前記構造化文書フラグメントのフォーマットと、前記構造化文書のフォーマットとの組み合わせに基づいて、前記構造化文書フラグメントを解析する解析手段と、前記解析手段の解析結果に基づいて、前記構造化文書フラグメントのフォーマットを前記構造化文書のフォーマットに変換して、前記構造化文書に挿入する挿入手段として機能させることを特徴とするプログラム。しかしながら、特許文献1に開示される構成は、スタイルシートによる変換であり、フォーマットの違いについては解決できないという問題がある。また、フラグメントを含む構造化文書全体を取得して処理を行っているため、フラグメントのみを受け取った場合には正しい処理ができないという問題がある。そのため、親文書とフラグメントは常に同じフォーマットにしなければならず、すべての文書作成モジュールが同じフォーマットを出力するようにしなければならない。バイナリXMLは新しい技術であり、これに対して、現在の多くの文書作成モジュールは従来どおりのテキスト形式のXML文書を出力するようになっているため、これらすべてをバイナリXMLに対応させるのは非常に手間がかかる。すなわち、バイナリXMLによる圧縮や高速化の恩恵を受けられないことを意味する。本発明は上記の課題を解決するためになされたものであり、フォーマットが異なる場合でも、1つ構造化文書中に別の構造化文書の一部分であるフラグメントを挿入することができる情報処理装置及びその制御方法、プログラムを提供することを目的とする。構造化文書に、前記構造化文書の一部を構成可能である構造化文書フラグメントを挿入して1つの構造化文書を作成する情報処理装置であって、前記構造化文書に挿入する前記構造化文書フラグメントのフォーマットを判定する判定手段と、前記判定手段で判定した前記構造化文書フラグメントのフォーマットと、前記構造化文書のフォーマットとの組み合わせに基づいて、前記構造化文書フラグメントを解析する解析手段と、前記解析手段の解析結果に基づいて、前記構造化文書フラグメントのフォーマットを前記構造化文書のフォーマットに変換して、前記構造化文書に挿入する挿入手段とを有する。本発明によれば、1つの構造化文書とそれに挿入する別の構造化文書のフラグメントのフォーマットを合わせることが不要になり、高速な処理が可能になる。以下、本発明の実施形態について、図面を参照して説明する。なお、以下の実施の形態は特許請求の範囲に関る本発明を限定するものではなく、また、本実施の形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。尚、同一な構成については、同一の符号を付して説明する。本発明の実施形態である構造化文書を処理する情報処理装置のハードウェア構成を図1に示す。情報処理装置は単一の装置で実現してもよいし、必要に応じて複数の各機能を分散して実現するようにしてもよい。複数の装置で構成される場合は、互いに通信可能なようにLocalAreaNetworkLAN等のネットワーク回線で接続される。図1において、102は情報処理装置100全体を制御するCentralProcessingUnitCPUである。103は変更を必要としないプログラムやパラメータを格納するReadOnlyMemoryROMである。104は外部装置等から供給されるプログラムやデータを一時記憶するRandamAccessMemoryRAMである。105は装置に固定して設置されたハードディスク、着脱可能なフレキシブルディスクFDやCompactDiscCD等の光ディスク、磁気カード等を含む外部記憶装置である。106はネットワーク回線と接続するためのネットワークインターフェースである。101は102から106の各ユニットを通信可能に接続するシステムバスである。この情報処理装置100は他の装置と通信を行う装置で、その通信データフォーマットはXML形式である。XMLはテキスト形式のデータであるが、近年ではバイナリ形式のフォーマット特定のフォーマットも規定されている。これは主に文書のサイズ削減と処理の高速化のために各種圧縮技術等を施したものであり、文書が持つ情報としてはXMLと互換性を持つものの、フォーマットとしての互換性はない。互換性がないとは、あるフォーマットを解析するプログラムでもう一方のフォーマットの文書を解析することができないことである。また、バイナリ形式のXMLフォーマットはいくつの種類があり、EXIEfficientXMLInterchange形式やFastInfoset形式等がある。尚、一般にXMLとはテキスト形式のものを指すが、本明細書で単にXMLとしたときはテキスト形式とバイナリ形式の両方を指している。また、テキスト形式のXMLのみを指す場合はテキストXML、バイナリ形式のXMLを指す場合はバイナリXML、あるいはより具体的にFastInfosetやEXI等の個別の名称を用いる。次に、本実施形態のソフトウェア構成を図2に示す。SOAP通信部201は、SOAPメッセージと呼ばれるXML形式の文書の送受信を行う。テキストXML作成部202はテキスト形式の文書を作成する。EXI作成部203はEXI形式の文書を作成する。尚、EXI作成部203は、バイナリ形式のXMLの1つとしてEXI形式の文書を作成するが、それ以外のバイナリ形式のXMLを作成することも可能である。フォーマット判定部204はXML文書のフォーマットテキストXML、EXI等を判定する。テキストXML解析部205はテキストXMLを解析する。EXI解析部206はEXIを解析する。尚、EXI解析部206は、バイナリ形式のXMLの1つとしてEXI形式の文書を解析するが、それ以外のバイナリ形式のXMLを解析することも可能である。207、208は通信アプリケーションであり、SOAP通信部201を用いて他の装置と通信を行うアプリケーションソフトウェアである。尚、SOAPSimpleObjectAccessProtocolは汎用的な通信プロトコルである。このSOAPでは、1つの装置が複数のSOAPアプリケーション通信アプリケーション207、208等を持ち、共通のSOAP通信部を利用する構成は現在広く行われている方式である。SOAP通信部201がSOAPメッセージを作成するフローを図3に示す。まず、SOAP通信部201は、SOAP通信全般に関する設定ファイルを読み込むステップS302。この設定ファイルは外部記憶装置105に保存されており、あらかじめ設定しされている。また、設定ファイルは少なくともXML文書のフォーマットの情報と、EXIの場合にはEXIオプションの情報を記述している。これにより、SOAP通信部201は、SOAPメッセージを作成するために、テキストXML作成部202とEXI作成部203のどちらを使うかを選択するための判定を行う。より具体的には、SOAP通信部201は、設定ファイルで記述されるフォーマットの情報が、EXIであるか否かを判定するステップS303。EXIである場合ステップS303でYES、ステップS304に進み、EXI作成部203を選択する。一方、EXIでない場合ステップS303でNO、ステップS305に進み、テキストXML作成部202を作成する。設定ファイルはテキスト形式で、パラメータと値をスペースで区切った形式となっている。具体例としては、図7の7a及び7bのようになる。7aがフォーマットがEXIの例、7bがフォーマットがテキストXMLの例を示している。ここで、設定ファイルが7aであるとすると、フォーマットはEXI、オプションとしてPreservePrefixが設定されている。この場合、SOAP通信部201は、EXI作成部203を選択するステップS304。前述のとおりテキストXMLとEXIは、フォーマットは異なるもののほぼ同じデータモデルを有する。そのため、作成用のメソッドもほぼ同じものにすることができる。図8の8aにEXI作成部203及びテキストXML作成部202のインターフェースを示す。ここで、WriteSelfContained及びSetOptionの2つはEXI作成部203のみが持ち、その他のメソッドは両者が同じ名前のものを持つ。また、WriteRawメソッドの引数は記していないが、これは特殊なメソッドでありXMLフラグメントと呼ばれるデータを引数に取る。WriteRawメソッド及びXMLフラグメントについては後述する。尚、図8の8bは、XML文書フラグメントの解析に使われるメソッドである。また、図8の8cは、図8の8aのインターフェースで用いる、各種イベントである。図8の8cでは、イベント型と、その略称、及びその意味を示している。例えば、イベント型StartElementは、略称がSEであり、その意味は開始タグである。フォーマットがEXIの場合には、EXIオプションの設定が必要であり、SOAP通信部201は、EXIオプションの設定を行うステップS306。EXIオプションの設定にはSetOptionメソッドを使い、その値として、設定ファイルに記述されているPreservePrefixを指定する。EXIオプションにはいくつの種類があるが、それぞれの詳細については本発明とは関連が低いため説明は省略する。但し、EXIオプションの設定によって、出力されるデータのフォーマットが変わるという点は重要である。例えば、ここで指定されたPreservePrefixオプションは、EXI文書中に名前空間プレフィックスの値を保存するか、しないかを決める。EXIオプションを指定したら、SOAP通信部201は、SOAPメッセージのうち、他モジュール担当部分つまり、フラグメント挿入箇所の直前までを作成するステップS307。SOAP通信部201が作成するSOAPメッセージは、テキストXML形式の場合、図9の9aとなる。SOAPメッセージ全体はEnvelope<soap:Envelope~</soap:Envelope>という要素に含まれる。また、その中にHeader要素<soap:Header>~</soap:Header>とBody要素<soap:Body>~<soap:Body>が含まれる。Header要素には、通信の制御を行う情報が格納されるものであり、SOAP通信部201が処理を担当する。一方、Body要素は転送されるデータ本体であり、通信アプリケーション207等が処理を担当する。従って、ステップS307では、SOAP通信部201は、SOAPメッセージ中の図9の9a07に相当する箇所までを作成する。SOAP通信部201がこのSOAPメッセージを作成するために呼ぶメソッドは図10のとおりである。EXI及びテキストXMLいずれの場合もこの1001から1009の順でメソッドが呼ばれる。また、ステップS307では、このうちの1001から1006までのメソッドが呼ばれる。設定ファイルに対して、最初に記述するものは、Envelope開始タグであるため、SOAP通信部201は、1001に示すWriteStartElementメソッドを呼ぶ。引数はPrefix=soap、名前空間URIはNamespaceURI=http://www.w3.org/2003/05/soap-envelopeである。また、LocalNameはEnvelopeである。尚、名前空間URIの文字列は一般に長くなるため、本明細書では、以降、このURIを[ns-soap]と記述する。ここで、EXI作成部203によるWriteStartElementメソッドの動作を図6aに示す。また、EXI作成部203は作成中に適宜変化する内部状態を持ち、これには深さと名前空間テーブルが含まれる。深さdepthは整数であり、現在の要素の階層の深さを表す。初期状態は0である。名前空間スタックは深さ、プレフィックス、名前空間URIの3つからなるデータのスタック形式の情報であり、図11のようなデータである。初期状態は11aのように、空の状態である。WriteStartElementメソッドでは、まず、指定された開始タグイベントを書き込むステップS6a02。開始タグイベントは少なくとも名前空間URIとローカル名を持ち、また、PreservePrefixオプションがある場合はさらにプレフィックスの情報を持つデータである。出力されるEXI文書全体は図9の9bに示すが、この段階では9b02の開始タグイベントSEイベントが出力された状態である。EXI文書はバイナリ形式であるため、ここではEXI文書の構成を、図9の9bでは、表形式で表す。EXI文書は最初に9b01に示すようなオプション情報EXIヘッダがあり、以降9b02からは各イベント図8の8cで示されるようなのデータが記述される。各イベントは少なくともイベントの種類Typeの情報を有し、また、その種類に応じてローカル名LocalNameや値Valueを有する。イベントの種類によっては何の情報を持つかは異なり、情報を持たないものはハイフン-で示している。WriteStartElementメソッドは、次に、depthの値を1増加するステップS6a03。よって、1になる。次に、指定されたPrefixここではsoapがNamespaceURI[ns-soap]にバインドされているか否かを判定するステップS6a04。バインドされている場合ステップS6a04でYES、処理を終了する。一方、バインドされていない場合ステップS6a04でNO、ステップS6a05に進む。名前空間のバインドの状態は名前空間スタックを参照することで得られる。現在、図11の11aの状態であり、soapに関する情報はない。よって、この場合、9b03のNSイベント名前空間宣言を書き込むステップS6a05。次に、名前空間スタックに、このプレフィックス、URI、現在のdepthを登録するステップS6a06。この結果、名前空間スタックは図11の11bのようになる。これでWriteStartElementメソッドの処理を終了する。次に、SOAP通信部201は、図9の9a03に相当する箇所の記述を行うため、図10の1002に示すWriteNsDeclメソッドを呼ぶ。引数はPrefix=enc、NamespaceURI=http://www.w3.org/2001/04/xmlencである先ほどと同様、このURIの文字列を[ns-enc]で表す。EXI作成部203によるWriteNsDeclメソッドの動作を図6cに示す。WriteNsDeclメソッドは、名前空間スタックに、depth、プレフィックス、URIの3つがすべて等しいデータがあるか否かを判定するステップS6c02。等しいデータがある場合ステップS6c02でYES、処理を終了する。一方、等しいデータがない場合ステップS6c02でNO、ステップS6c03に進み、NSイベントを書き込むステップS6c03。次に、名前空間スタックに、指定されたプレフィックス、URI、現在のdepth-1を追加するステップS6c04。その結果、図9の9b04のNSイベントが書き込まれ、名前空間スタックは図11の11cのようになる。同様に、図9の9a04に相当する開始タグイベントを書き込むため、図10の1003に示すWriteStartElementメソッドを呼ぶ。このときは、指定されたプレフィックスsoapとURI[ns-soap]はすでに名前空間スタック11cに含まれているため、NSイベントは出力されない。また、depthの値は2になる。以降で、本来は、SOAPヘッダの内容が書き込まれるが、本発明とは関連が低いため、ここでは、SOAPヘッダの内容については省略する。SOAPヘッダの内容が書き込まれると、図9の9a06に相当する終了タグイベントを書き込むため、図10の1005に示すWriteEndElementメソッドを呼ぶ。EXI作成部203によるWriteEndElementメソッドの動作を図6bに示す。まず、終了タグイベントを書き込むステップS6b02。これにより、図9の9b07の終了タグイベントEEイベントが出力される。次に、depthの値を1減少するステップS6b03。現在の値は2であったため、1になる。そして、名前空間スタックのうち、depth<現在のdepthとなっているものを削除するステップS6b04。この段階の名前空間スタックの状態は11cであり、その11cにおけるdepthはいずれも1であり、この条件を満たさない。よって、ここでは何もしない。これで、WriteEndElementメソッドの処理は終了する。この名前空間スタックにあるデータのdepthと、現在のdepthにより、名前空間の有効範囲が適切に管理されている。つまり、名前空間URIは、それが指定された開始タグに対応する終了タグまでであるというXMLの仕様に基づく処理が行われている。以降、同様に、図9の9a07に相当する開始タグイベントを書き込むため、図10の1006のWriteStartElementメソッドを呼び、図9の9b08の開始タグイベントが出力される。9b02から9b08のイベントが出力されることにより、ステップS307の処理が終了する。次に、SOAP通信部201は、Bodyの中身となるデータXML文書の一部を構成するデータを通信アプリケーション例えば、通信アプリケーション207等から受け取るステップS308。ここで、このようなXML文書の一部を構成するデータをXMLフラグメントと呼び、また、本明細書では単にフラグメントと呼ぶ。例えば、通信アプリケーション207が作成したフラグメントを図12の12aに示す。SOAP通信部201は、図12の12aに示す文字列そのものを受け取り、そのフラグメントをSOAPメッセージに書き込むステップS309。この処理は、WriteRawメソッドを呼ぶことで行われる。前述のとおり、WriteRawメソッドはフラグメントを引数に取る。EXI作成部203及びテキストXML作成部202が持つWriteRawメソッドの処理を図4に示す。まず、与えられたフラグメントのフォーマットを判定するステップS402。尚、EXIのデータは、その仕様により、必ず最初にDistinguishingBitsと呼ばれるビット列から始まり、最初のバイトの上位2ビットは10となる。一方、テキストXMLで使われる文字エンコーディングは通常UTF-8またはUTF-16である。UTF-8では10から始まるバイトはその仕様上存在しない。また、テキストXMLの仕様では、UTF-16を扱う場合は必ずBOMByteOrderMarkと呼ばれる特殊な文字を最初に入れることになっている。BOMも最初のビットは10ではない。従って、最初の2ビットが10であればEXI、それ以外はテキストXMLとみなすことができる。図12の場合、12aのフラグメントも文字列であるため、最初の2ビットが10になることはなく、テキストXMLであると判定される。次に、親子関係にある構造化文書である親文書構造化文書からなる親構造化文書と子文書構造化文書の一部を構成可能である構造化文書フラグメントの組み合わせによって、4種類の処理ステップS404からステップS407のいずれかを行う。本例の場合、現在、親文書はEXI文書であり、子文書であるフラグメントはテキストXMLと判定される。従って、EXI文書へのテキストXMLフラグメントの挿入処理を実行するステップS407。この挿入処理の詳細を図5aに示す。この場合、親文書と子文書フラグメントのフォーマットが異なるため直接挿入することはできず、テキストXMLフラグメントのフォーマットをEXIに変換することになる。テキストXMLフラグメントをEXIに変換することは、つまり、テキストXMLを解析し、その解析結果をEXI作成部203を用いて書き出す、ということである。しかし、テキストXMLフラグメントの解析は、XML文書全体を解析するXMLパーサでは解析できないことがある。これは、XMLフラグメントは、それ単独ではXML文書としての仕様を満たしていないことがあるからである。そして、図12の12aのフラグメントもそのようなケースの1つである。例えば、図12の12aにおいて、12a01行は<enc:CipherData>であり、テキストXMLの仕様から、これが開始タグであることが判別できる。また、プレフィックスはenc、ローカル名はCipherDataである。しかし、名前空間URIは判別することができない。なぜなら、プレフィックスであるencに対応する名前空間URIの定義がないためである。そのため、EXI作成部203は、depthを0にした名前空間スタックをテキストXML解析部205に渡すステップS5a02。現在の名前空間スタックは、図11の11cの状態であり、これらのdepthを0にしたもの、つまり、図11の11dの名前空間スタックが渡される。そして、その名前空間スタックをテキストXML解析部205で解析する。XML文書フラグメントの解析に使われるメソッドを図8の8bに示す。XML作成の場合と同様、テキストXMLとバイナリXMLでインターフェースはほぼ同じである。GetOptionメソッドのみはEXI解析部206のみが持ち、それ以外は両者が同じ名前のメソッドを持つ。これらのメソッドを使って、テキストXML解析部205はテキストXMLを解析するステップS5a03。そして、テキストXML解析部205は、解析結果をEXI作成部203に入力するステップS5a04。これにより、テキストXMLフラグメントをEXI文書の一部として挿入することができる。この処理を図14に示す。まず、図8の8bにあるメソッドのうち、NextEventメソッドを繰り返し使うことで、フラグメント中のすべてのイベントを辿ることが可能である。そこで、次の取得対象のイベントを取得するステップS1402。イベントを取得すると、GetTypeメソッドでイベントの情報としてその種類を取得するステップS1404。次に、その種類と同じ種類のイベントを出力するEXI作成部203/テキストXML作成部202のメソッドに対して、イベントのデータを渡すステップS1405。このとき、イベントのデータの取得には、GetPrefixメソッド、GetNamespaceURIメソッド、GetLocalNameメソッド、GetValueメソッドの結果を用いる。その結果、フラグメントはEXI文書の一部として出力される。次に、取得対象の全イベントを取得したか否かを判定する。全イベントを取得していない場合ステップS1406でNO、ステップS1402に戻り、次のイベントを取得する。一方、全イベントを取得した場合ステップS1406でYES、処理を終了する。次に、テキストXML解析部205のNextEventメソッドの詳細を図13に示す。テキストXML解析部205には、図11の11dに示す名前空間スタックが渡されていることに注意されたい。まず、処理対象の次のイベントがあるか否かを判定するステップS1302。イベントがない場合ステップS1302でNO、処理を終了する。一方、イベントがある場合ステップS1032でYES、ステップS1303に進み、そのイベントを解析するステップS1303。次に、解析結果に基づいて、イベントの種類を判定して、その判定した種類に基づいて処理を分岐するステップS1304。具体的には、イベントが開始タグイベントSE、終了タグイベントEE、それ以外のイベントであるかに基づいて、処理を分岐する。図12の12aのフラグメントの場合は、最初のイベントである12a01を解析する。これは開始タグイベントであるため、ステップS1305に進む。但し、12a01には名前空間宣言はないため、この場合、ステップS1305はスキップする。次に、プレフィックスから名前空間URIを探索するステップS1306。プレフィックスはencであるが、図12の12aのフラグメントにはこのプレフィックスが示す名前空間URIの情報がない。しかし、名前空間スタックは、図11の11dのようになっており、encが表すURIがhttp://www.w3.org/2001/04/xmlencであることがわかる。このようにして、本来解析できないテキストXMLフラグメントの解析が可能になる。そして、depthの値を1増加するステップS1307。尚、名前空間スタックのスコープ管理はEXI作成部203と同様、depthの情報を用いて管理されており、ステップ1307や、ステップS1309、ステップS1310で処理されている。ここで、ステップS1308~ステップS1310は、イベントが終了タグイベントEEの場合の処理である。ステップS1308は、ステップS1306と同様である。次に、depthの値を1減少するステップS1309。そして、名前空間スタックのうち、depthが等しいものを削除するステップS1310。このようにして、SOAP通信部201がEXI形式のSOAPメッセージを作成し、通信アプリケーションがテキストXMLフラグメントを作成した場合でも、EXI文書として出力することができる。次に、SOAP通信部201がEXI形式でSOAPメッセージを作成し、通信アプリケーション208が出力するEXIフラグメントを挿入する場合について説明する。また、このときのEXIフラグメントを図12bに示す。すなわち、これは12aに表すテキストXMLフラグメントに対応するEXIフラグメントである。SOAP通信部201は先ほどと同様、ステップS302から開始し、ステップS308までは同じ結果になる。つまり、図9の9bの9b08まで出力した状態である。次に、ステップS309の処理、詳しくは、図4の処理を行う。このとき、ステップS402において、フラグメントはEXIと判定される。従って、このケースでは、EXI文書へのEXIフラグメントの挿入処理を実行するステップS405。この挿入処理の詳細を図5cに示す。まず、EXIヘッダにあるオプションを読み込むステップS5c02。図12の12bのEXIフラグメントのオプションは、12b01の情報である。これと親文書のオプションと比較して、同じであるか否かを判定するステップS5c03。同じである場合ステップS5c03でYES、ステップS5c04へ進む。一方、同じでない場合ステップS5c03でNO、ステップS5c08へ進む。親文書は図9の9bにおける9b01から9b08の状態であるが、このうちのオプションは9b01である。このとき、2つのオプションは一致している。そのため、この場合、最初のイベントを読み込むステップS5c04。次に、読み込んだイベントがSCSelfContainedイベントであるか否かを判定するステップS5c05。SCSelfContainedイベントである場合ステップS5c05でYES、ステップS5c06へ進む。一方、SCSelfContainedイベントでない場合ステップS5c05でNO、ステップS5c08へ進む。本例の場合、最初のイベントは、図12の12bの12b02のSCSelfContainedイベントである。SCイベントはEXIに特有のイベントであり、EXIの符号化規則がここでリセットされることを意味する。通常、EXIの符号化規則イベントの種類や内容といった情報を、どのようなビット列で表すかの規則が、イベントが進むごとに変更されることになっている。そのため、あるEXIフラグメントを別のEXI文書の途中に挿入することはできない。SCイベントは、符号化規則がリセットされるため、図12の12bの12b03以降のイベントは初期状態から行われている。従って、このEXIフラグメントは、図12の12bの12b02のSCイベント以降をそのまま親文書に挿入可能である。よって、現在SCイベントのバイトオフセットを取得するステップS5c06。そして、そのオフセット以降をそのまま出力するステップS5c07。つまり、EXIフラグメントをEXI文書に直接挿入可能である。これにより、ステップS309の処理が終了する。次のステップS310は、先ほどと同様である。このようにして、EXIフラグメントが挿入されたEXI文書が出力される。結果として、図9の9bの9b08と9b09の間に、図12の12bの12b02から12b05が挿入されたものになる。図9の9bの9b02から9b08と、図12の12bの12b03以降はその符号化規則が異なるものになっているが、図12の12の12b02のSCイベントによって符号化規則がリセットされる。そのため、EXI解析部206も、問題なく解析することが可能である。尚、親文書のEXI文書と子文書のEXIフラグメントのオプションが異なる場合ステップS5c03でNOや、EXIフラグメントがSCイベントで始まらない場合ステップS5c05でNO、EXIフラグメントをそのまま挿入することができない。そのため、この場合は、イベントの解析結果をEXI作成部203に入力するステップS5c08。これは、つまり、異なる符号化規則で符号化されたEXIフラグメントを変換して出力するということである。この処理は図14の処理と同様である。この結果、図9の9bの9b08と9b09の間に、図12の12cの12c02から12c04が挿入されたEXI文書が作成される。但し、図12の12cの12c02から12c04はその意味は変わらないものの、親文書の符号化規則に従って再符号化されているため、ビット表現としては異なるものになっている。以上で、SOAP通信部201がEXI形式のSOAPメッセージを出力する場合に、通信アプリケーションがテキストXMLEXIフラグメントのいずれを出力した場合でも、正しいEXI文書を出力することができる。また、EXIフラグメントを直接挿入可能である場合には、そのまま埋め込むことでEXIフラグメントの変換処理をなくし、処理を高速化可能である。今度は、SOAP通信部201がテキストXML形式のSOAPメッセージを出力する場合について説明する。つまり、設定ファイルが7bのようになっている場合である。このときも先ほどと同様、通信アプリケーションがテキストXMLフラグメント12aを出力する場合と、EXIフラグメント12b、12cを出力する場合がある。SOAP通信部201の処理は同様に図3に従う。但し、文書の作成にテキストXML作成部202を選択するステップS305。よって、ステップS307まで処理した段階で、図9の9aにおける9a01から9a07までが出力された状態になる。ここで、フラグメントを受け取るがステップS308、ここで、図12の12bのEXIフラグメントを受け取る場合を説明する。このときは、ステップS309、つまり図4の処理において、テキストXML文書へのEXIフラグメントの挿入処理を実行するステップS406。この挿入処理の詳細を図5bに示す。親文書と子文書フラグメントのフォーマットが異なるため直接挿入することはできず、EXIフラグメントをテキストXMLとして変換することになる。この処理は図14と同様である。また、図12の12bに示すように、EXIフラグメントの開始タグ終了タグイベントには名前空間URIの情報が含まれている。これは、つまり、先に説明したテキストXMLフラグメントの解析処理にあった問題プレフィックスに対応する名前空間URIが不明であるがないことを意味する。よって、EXIフラグメントは特別な処理をすることなくEXI解析部206で解析可能であるステップS5b02。あとは、この解析結果をテキストXML作成部202に入力すればよいステップS5b03。この挿入処理と、続くステップS310を行うことで、図9の9aの9a07と9a08の間に、図12の12aが挿入されたテキストXML文書が出力される。最後に、テキストXML文書中にテキストXMLフラグメントが渡された場合を説明する。つまり、図9の9a07まで出力した状態で、図12の12aが渡された場合である。このときは従来通りの処理であり、テキストXMLフラグメントをそのまま出力するステップS404。つまり、テキストXMLフラグメントをテキストXML文書に直接挿入可能である。結果として、図9の9a07と9a08の間に図12の12aが挿入されたテキストXML文書が出力される。以上のように、本実施形態では、SOAP通信部201と通信アプリケーション207等がそれぞれEXI形式テキストXML形式を出力する場合の4つのパターンがあり、いずれの場合も正しいXML文書として出力される。また、本実施形態によれば、特に、親文書がEXIの場合は、子文書がテキストXMLの場合でも全体をEXIとして出力するため、サイズの削減や高速な処理が可能である。尚、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェアプログラムを、ネットワーク又は各種記憶媒体を介してシステムまたは装置に供給し、そのシステムまたは装置のコンピュータまたはCPUやMPU等がプログラムを読み出して実行する処理である。