EXIEfficientXMLInterchangeストリームをデコードするEXIデコーダであって、少なくとも1つのデータ型を定義したXMLによる第1スキーマからEXI仕様にしたがって生成される第1の型文法と、少なくとも1つのデータ型を定義したXMLによる第2スキーマから前記EXI仕様にしたがって生成される型文法のうち、前記第1の型文法と共通する型文法を除いた第2の型文法とを記憶する文法ストアと、EXIストリームを受信するストリーム入力部と、前記EXIストリームが前記第1スキーマに対応するものであるときは、前記第1の型文法に基づき前記EXIストリームをデコードし、前記EXIストリームが前記第2スキーマに対応するものであるときは、前記文法ストアに記憶された前記第1の型文法のうち前記共通する型文法と、前記第2の型文法とに基づき、前記EXIストリームをデコードするパーサ部と、を備えたEXIデコーダ。前記EXIストリームが前記第1スキーマおよび前記第2スキーマのうちどのスキーマに対応するかを、EXIヘッダオプションに含まれるスキーマIDに基づいて判断するヘッダ解析部をさらに備え、前記パーサ部は、前記解析部による判断結果に基づいて、前記EXIストリームが前記第1スキーマおよび前記第2スキーマのうちどのスキーマに対応するかを決定することを特徴とする請求項1に記載のEXIデコーダ。EXIEfficientXMLInterchangeストリームをデコードするプログラムであって、少なくとも1つのデータ型を定義したXMLによる第1スキーマからEXI仕様にしたがって生成される第1の型文法と、少なくとも1つのデータ型を定義したXMLによる第2スキーマから前記EXI仕様にしたがって生成される型文法のうち、前記第1の型文法と共通する型文法を除いた第2の型文法とを記憶する文法ストアにアクセスするステップと、EXIストリームを受信するストリーム入力ステップと、前記EXIストリームが前記第1スキーマに対応するものであるときは、前記第1の型文法に基づき前記EXIストリームをデコードし、前記EXIストリームが前記第2スキーマに対応するものであるときは、前記文法ストアに記憶された前記第1の型文法のうち前記共通する型文法と、前記第2の型文法とに基づき、前記EXIストリームをデコードするパーサステップと、をコンピュータに実行させるためのプログラム。前記EXIストリームが前記第1スキーマおよび前記第2スキーマのうちどのスキーマに対応するかを、EXIヘッダオプションに含まれるスキーマIDに基づいて判断するヘッダ解析ステップをさらに前記コンピュータに実行させ、前記パーサステップは、前記解析ステップによる判断結果に基づいて、前記EXIストリームが前記第1スキーマおよび前記第2スキーマのうちどのスキーマに対応するかを決定することを特徴とする請求項3に記載のプログラム。EXIによる情報交換を目的とした際に、標準あるいは基盤となるスキーマに対して、個々のベンダ等が拡張したデータ型を定義することが考えられる。このとき、拡張スキーマの個別定義により、個々のベンダ拡張スキーマ全体に対する状態機械型文法がそれぞれ必要になってしまい、実装に必要となるROMサイズ等の記憶領域サイズが増大してしまう。これは、EXIにおいては符号化復号に用いる状態機械の状態数が変化することで符号のビット幅が変化してしまうことに由来する固有の問題である。本発明の一実施形態は、EXIストリームをデコードするEXIデコーダであって、文法ストアと、ストリーム入力部と、パーサ部とを備える。前記文法ストアは、少なくとも1つのデータ型を定義したXMLによる第1スキーマからEXI仕様にしたがって生成される第1の型文法と、少なくとも1つのデータ型を定義したXMLによる第2スキーマから前記EXI仕様にしたがって生成される型文法のうち、前記第1の型文法と共通する型文法を除いた第2の型文法と、を記憶する。前記ストリーム入力部は、EXIストリームを受信する。前記パーサ部は、前記EXIストリームが前記第1スキーマに対応するものであるときは、前記第1の型文法に基づき前記EXIストリームをデコードし、前記EXIストリームが前記第2スキーマに対応するものであるときは、前記文法ストアに記憶された前記第1の型文法のうち前記共通する型文法と、前記第2の型文法とに基づき、前記EXIストリームをデコードする。図1に、本発明の実施形態に係る複数スキーマ対応EXIデコーダの構成を示す。ストリーム入力部11は、EXIストリームの入力を受け取る。入力されるストリームは、TCPIPあるいはUDPIPのようなネットワーク、もしくは、ファイルシステムからの読み出しによる任意のバイト列である。ストリーム入力部11は、EXIストリームに含まれるヘッダおよびヘッダオプションをヘッダ解析部12に、ストリーム本体をパーサ部17に渡す。ヘッダ解析部12は、EXIストリームのヘッダおよび、ヘッダオプションを解析し、EXIストリームのオプションを抽出する。オプションは、スキーマIdを含んでいる。schemaIdは、文法選択部13と、ストリングテーブル初期化ベクタ選択部15に渡される。文法ストア14は、パーサ部17が利用する可能性がある全てのスキーマに対応する全てのEXI文法と、個々の文法がどのschemaIdにおいて利用されるのかという情報文法セット表とを保持している。当該情報は、ビットマップ等の手段により構成される。また、文法ストア14は、一部の文法たとえばxsitypeから呼び出される文法については、型Typeを表わすQNameQualifiedNameと文法との対応関係を示すテーブルを持つ。なお、xsitypeは、特にXMLSchemaInstance仕様により定義される、XML要素解釈の際の型指定を明示的に行うための仕様である。文法ストア14の構成の例を図5に示す。図5における1は、該当する文法が利用、0は該当する文法が利用されないことを示す。たとえばschemaId4の場合、文法A、Bは利用されるが、文法Zは利用されない。なお文法A、B、Zは、文法名を抽象的に表したものである。ns0a、ns0b、ns1a等は、QNameを抽象的に表したものである。ns0ns1が名前空間に相当し、ab等が、ローカル名に相当する。より詳細に、型文法はそれぞれの型に対応する状態機械文法であり、左側のschemaIdをキーとしたビットマップで個々のschemaIdで利用可能な文法が示される。また、図中右側のテーブルはQNameをキーとして、型文法をルックアップする。文法選択部13は、ヘッダ解析部12から通知されたschemaIdから、利用する文法の組と、文法セット表の該当部分schemaIdに対応する文法セット表を、文法ストア14より選択し、パーサ部17に送る。ストリングテーブル初期化ベクタストア16は、パーサ部17が利用する可能性がある全てのストリングテーブル初期化ベクタと、schemaIdとの対応関係を保持している。ストリングテーブル初期化ベクタストア16の具体例な構成は、全てのストリング全てのストリング初期化ベクタが保存されているROM領域と、schemaIdそれぞれに対応するストリングへの参照の列で構成するなどといった方法で実現する。ストリングテーブル初期化ベクタ選択部15は、ヘッダ解析部12から通知されたschemaIdから、利用するストリングテーブル初期化ベクタを決定し、パーサ部17に送る。パーサ部17は、ストリングテーブル初期化ベクタ選択部15から送られたストリングテーブル初期ベクタにより、ストリングテーブルを初期化上書きし、初期化されたストリングテーブルと、文法選択部13から与えられた文法および文法セット表とから、ストリーム入力部11から渡されたストリームを処理する。すなわち当該ストリームを、XML文書を構成するイベント列たとえばSAXイベントへ変換し、変換したイベント列を、アプリケーション図示せずに渡す。アプリケーションでは当該イベント列から、元となるXML文書の内容を解釈し、所定の動作を行う。ストリングテーブルおよび初期化ベクタの詳細な説明については、後述する。以下に、EXIストリームの構造、EXIストリームヘッダの構造、EXI文法の構造、ストリングテーブル初期化ベクタ、パース処理について説明する。EXIストリームは、EXIストリームヘッダとヘッダオプション、本文に相当するストリームから成る。ヘッダオプションは、特定のスキーマにもとづくEXI文書EXIのストリームである。ストリームは、イベントコードと値の組が繰り返される構造になっている。XMLにおけるタグによる文書の構造化は、上記値の部分に、子要素に相当する、イベントコードと値の組の繰り返しが再帰的に登場することにより表現される。EXIストリーム本体の構造例を図2に示す。このイベントコードが、EXI文法により定義されることで、XML文書構造のEXIへの効率的なエンコーディングが実現される。EXIストリームヘッダの構造は、非特許文献1の第5節に定義されている。ヘッダ構造は、必ず含まれる固定長のヘッダ部分に加え、EXIオプションが存在する場合がある。存在するかどうかは、ヘッダ部分のPresenceBitにより区別される。EXIオプションは、それ自身がEXI仕様により定められるスキーマにより記述されたEXI文書である。EXIオプションにはさまざまな記述が可能であるが、本実施形態において重要な要素はschemaIdである。schemaIdは、送信側のEXIエンコーダが、本EXIデコーダに、EXIストリームに含まれるデータが、どのスキーマを利用してエンコードされたものであるかつまり、元となるXML文書が、どのスキーマを利用してEXIストリームにエンコードされたかという情報を伝えるための文字列である。XML文書は、イベント列に変換された上、当該スキーマからEXI仕様にしたがって生成されるEXI文法にしたがって、EXIエンコーダにより、EXIストリームにエンコードされる。スキーマからEXI文法を生成する方法は、非特許文献1に記述されている。ここでは、文法に含まれる要素について説明する。一つの文法は、スキーマで定義される各々の型に対して、各々一つの状態機械を定義したものである。具体的には個々の文法は、次の構成を含む。各々の型のラベルと、これに対応する状態機械状態機械を構成する状態の集合各々の状態からその状態機械を構成する自身または他の状態に対する遷移また、EXIの文法は、各々の状態遷移に以下の要素を定義する。イベント型イベントに対する補助要素イベントの値の型他の型か、あるいは整数integer、文字列などの組み込み型を示す次の遷移状態文法ストア14は、以上の形式で定義される文法を格納する記憶領域である。個々の型に対応する型文法はそれぞれ独立して格納される。その上で、文法ストア14は、型を示すQNameと、型文法との関係を、schemaId毎に記録する文法セット表図5参照を持つ。文法選択部13は、ヘッダ解析部12から入力されたschemaIdをもとに文法セット表から該当する部分を読み出し、schemaIdに対応する文法セット表と、該当する文法を、パーサ部17に渡す。文法セット表には、個々の型文法への参照が含まれるため、パーサはschemaIdとQNameの組から、各々の型文法を知ることができる。ここでストリングテーブルおよび初期化ベクタについて詳しく述べる。EXIにおいては、既知の文字列の再送を避けるためにストリングテーブルが用いられる。ストリングテーブルは、非特許文献1の第73節で定義されている、規定文字列ならびにドキュメント中に登場した文字列の再利用のために用いる表である。エンコーダとデコーダで同じ内容に初期化され、また文字列の送出の際にエンコーダ側とデコーダ側で同様に変更される。スキーマ内に登場する文字列や、XMLドキュメント内に2度以上登場する同じ文字列を、番号で参照するために用いる。具体的には、ストリーム中に登場した文字列に順に番号を振り、これを再利用する。具体的には、イベントコードに対応する値の部分に当該番号が指定される。なお、番号が振られない文字列については、その文字列がそのまま、イベントコードに対応する値の部分として含まれる。文法生成に利用したXMLスキーマに含まれる名前空間のURLは、ストリングテーブルの初期化に用いられる。例えばスキーマ中に含まれるタグ名の表現は、この初期化されたストリングテーブルにおける名前空間を用いた番号で指定を行う。従って、同じ文法構造であっても、利用するスキーマによって、ストリングテーブルに含まれるURLの初期値が異なる。これを解決するために、個々のschemaIdに対応するストリングテーブル初期化ベクタを用意し、これをメモリに格納しておく。また、入力されたEXIストリームのschemaIdに対応して、ストリングテーブルの初期化ベクタを選択する。選択したストリングテーブル初期化ベクタをパーサ部17に渡し、パーサ部17は、渡されたストリングテーブル初期化ベクタで、ストリングテーブルを初期化する。ストリングテーブルについてさらに具体的に説明する。ストリングテーブルは、URIプレフィックスQName中のURIとローカル名値の4つで用いられる。また、効率的な符号化のために、ストリングテーブルは、以下のパーティションに分割される。URIURIと、QName中のURI部を格納するプレフィックスプレフィックスが所属するURI毎に作成するローカル名ローカル名が所属する名前空間毎にテーブルを作成する値その値が登場したエレメントあるいはアトリビュートが所属する名前空間と、グローバルな値を格納するパーティションとの両方に動的に記述する。以下、URIパーティションならびにローカル名パーティションの初期化について具体的に述べる。まず、説明のため基本スキーマを図6に示す。図6に示した基本スキーマは、架空の食器メーカーSaucersCoが以下の要件で定義した注文書のXMLスキーマの抜粋である。1一つの注文書は複数の種類の皿の注文からなる2皿は色で指定するこのスキーマに基づく注文書の例を図7に示す。この文書では、青色の皿を14枚注文している。また図6の基本スキーマに定義された型に対応する状態遷移図を図10および図11に示す。図10はorderTypeの状態遷移図、図11はplateTypeの状態遷移図を示す。URIパーティションの初期化方法は、非特許文献1の付録D1に具体的に記述されている。これに従うと、図6に示した基本スキーマにおける初期化ベクタは以下のような形になる。CompactIDの0から3までに対応するURIが仕様により定まる定数であり、CompactIDの4以降がスキーマに由来する名前空間である。同様に、ローカル名に対応するストリングテーブルの初期化ベクタは、それぞれの名前空間毎に作られる。XMLの規約から導出される初期化ベクタについては、非特許文献1の付録D3を参照されたい。ここでは、特にスキーマに由来するもののみ記述する。図6に示した基本スキーマに由来するローカル名は以下の通りである。ここでは基本スキーマを例にして、説明したが、後述する拡張スキーマの場合も同様にして行われる。上述したように、ストリングテーブル初期化ベクタ選択部15は、ヘッダ解析部12から通知されたschemaIdに応じて、ストリングテーブル初期化ベクタ上記の例では、URIパーティションならびにローカル名パーティション等の各テーブルを選択し、パーサ部17に通知する。パーサ部17では、通知された初期化ベクタで、ストリングテーブルを初期化する。EXIにおけるパーサ部17でのパース処理は、次の手順で行う。具体的には、これはプッシュダウンオートマトンに相当する。パーサ部17には、文法選択部13から、schemaIdに対応する文法セット表が与えられている。初期文法はEXI仕様により決まっているので、当該文法セット表に対応する初期状態から、以下のようなステップでデコードを開始する。1現在の文法が指示するビット幅でストリームからデータを読み出し、これをイベントコード前述したイベントコードと値の組に含まれるイベントコードとする2イベントコードに対応する遷移を、現在の状態に対応する遷移表から読み出す3イベント型を記録し、対応する値前述したイベントコードと値の組に含まれる値を読み出す。ここでの値は遷移に記録された値の型により読み出し方法が規定される。なお、イベント型がSEあるいはATの場合は、対応する値は、他の型文法そのものを示す場合がある。このときは、パース処理は再帰的に、指示された型文法に移行し、移行した型文法が終了すると、現文法の処理に復帰する。このため、遷移先の文法を示す値のことをterminalと呼ぶ。4本文法が継続する場合には、次の状態を示す。現文法が終了しないため、このときの値をnonterminalと呼ぶ。パース処理のさらに詳細な説明については、非特許文献1を参照されたい。以下、前述した基本スキーマ図6、および当該スキーマに基づく注文書図7をベースに、本実施形態の具体例を示す。上述したように、図6は、架空の食器メーカーSaucersCoが以下の要件で注文書のXMLスキーマを定義したものであった。1一つの注文書は複数の種類の皿の注文からなる2皿は色で指定するここで、SausersCoが事業拡大に伴い、模様つきの皿の取り扱いをはじめたとする。先の要件定義には、皿の模様は含まれなかったため、基本スキーマに基づく注文書では、同じ色で違う模様の皿を取り扱うことができない。そこで何らかの方法でスキーマを拡張する必要がある。図8は、基本スキーマにおけるplateTypeを拡張したpatternedPlateTypeを実装したスキーマ拡張スキーマを示す。当該拡張スキーマで定義された各型に対応する状態遷移図を図12、図13、図14に示す。図12は、orderTypeに対応する状態遷移図、図13は、plateTypeに対応する状態遷移図、図14は、patternedPlateTypeに対応する状態遷移図を示す。注文者は、模様なしの皿を注文する際はplateタグを用い、模様のある皿を注文する際にはpatternedPlateタグを用いて、XML文書を記述すればよい。模様のある皿を注文する場合のXML文書の記述例を図9に示す。XMLの処理であればこの方式で何の問題もないが、この注文を業務の効率のためにEXIで行おうとすると、非効率な面が存在することがわかる。すなわち基本スキーマおよび拡張スキーマごとにEXI文法状態機械を用意しなければならないため、スキーマが増えるにつれ実装しなければならないコードの量が線形に増えてしまい、非効率である。スキーマ由来文法SchemaInformedGrammarで動作するEXIにおいては、XMLスキーマにより定義される型情報に従って文法を生成する。文法とは即ち状態機械であり、これをエンコーダとデコーダが共有し、状態遷移に一定の方式により小さい番号を割り当て、これを送信するのに最小限のビット数を用いることによりエンコーダ側とデコーダ側で文書情報を共有する。拡張スキーマでは、基本スキーマからorderタグが変化しており、基本スキーマに対応する状態機械をそのまま用いてもデコードできない。つまり、エンコーダ側とデコーダ側で情報の共有ができなくなってしまう。具体的には、状態遷移の番号が変化してしまう点、また、ある状態からの遷移の総数を表現するのに最小限のビット数が変化する点の2点から、デコードに失敗してしまう。例えば、遷移の総数が4から5に増えると、状態を表現するのに必要なビット数は2ビットから3ビットになる。このビット数は状態機械から決定するため、エンコーダ側とデコーダ側で状態機械を共有できていないと読み取りのビット数がずれてしまい、以降のデコードができなくなる。ここで、図10および図12に基づき、拡張スキーマを用いた場合のorderタグの変化を具体的に示す。上述したように、図10は、基本スキーマにおけるordertypeの状態遷移図、図12は、拡張スキーマにおけるodertypeの状態遷移図を示す。両図を比較して分かるように、基本スキーマを拡張したことで、ordertypeの状態遷移図が変化したことがわかる。このため、基本スキーマと拡張スキーマ間での状態機械の共有は困難である。つまり、タグを追加したことにより状態数が変化してしまい、その結果EXIのイベントコードの作成方法も変化してしまう。なお、図中、2種類の各弧についているラベルはそれぞれ、イベント名と繰り返しルールである。また、上述したorderタグの変化に加え、patternedPlateTypeは、基本スキーマには存在しない。このため、EXIにおいては図6の基本スキーマと、図8の拡張スキーマの両方にそれぞれ個別に対応するEXI文法状態機械を持つ必要がある。このことを図3に示す。図3は、従来におけるEXI文法のメモリ格納方式のイメージ図である。このように、スキーマが増えるにつれ実装しなければならないコードの量が線形に増えてしまい、非効率である。そこで本実施形態では、個々の文法について同一か否かを判定した上で、同一のものについてはschemaIdなどのストリームの特徴によらないものとして、メモリを共通化することを特徴としている。状態機械型文法が同一であるかの判断は以下のように行うことができる。状態機械Xと状態機械Yがあったとき、Xの全ての状態に対しYの状態のなかで対になる状態が存在し、それぞれの対になる2つの状態に対して、全ての遷移が等しいことを確認する。これらが全て成立した際、2つの状態機械は同一のものであると言える。取り扱う全てのスキーマの全ての型文法について以上の同一性判定を行い、同一な型文法についてはいずれか一つのみをメモリに格納する。全てのスキーマに対応する型文法を一つにまとめて格納すると、どの構文がどの文法で利用する文法かがわからなくなってしまう。それぞれの型文法がどのスキーマに登場したものかをビットマップ等により保存する。文法ストア14は個々の文法に加え、このビットマップ、およびQNameに対してどの文法が対応するのかの参照表や、schemaIdごとの初期文法を保存することにより、全てのスキーマに含まれる全ての文法セットから、今回利用する文法に対応する文法セットを得ることができる。本例の場合、拡張スキーマに定義されたorderType、plateType、patternedPlateTypeのうち、plateTypeに対応する型文法が、基本スキーマと共通する図11と図13を比較して分かるように状態遷移図が両スキーマで同一である。したがって、文法ストアには、基本スキーマで定義されたorderType、plateTypeにそれぞれ対応する型文法と、拡張スキーマに定義されたorderType、patternedPlateTypeにそれぞれ対応する型文法を記憶しておけばよい。plateTypeに対応する型文法は両スキーマで共有する。このように、文法を切り替える機構を導入することにより、多数のスキーマに対して実装しなければならない文法の量を最小化できる。つまり、複数のスキーマ由来文法を切り替えて利用するEXIプロセッサにおいて、共通する文法を最大化しつつEXIストリームの特徴を利用して利用する構文を切り替えることにより、プログラムサイズメモリ使用量を低減できる。図4に提案方式に基づくEXI文法のメモリ格納方式のイメージ図を示す。本実施形態は、そのまま組込み機器の通信に利用可能である。例えばXMLスキーマにより定義したペイロードを、EXI符号化して通信を行うホームネットワークプロトコルがあったとする。無線を利用することが多いホームネットワークにおいて、ペイロードサイズを削減できる厳格スキーマ由来文法は有利な方式であるが、一方で拡張のためには個々の拡張スキーマに対応する必要がある。この時、従来ではXMLスキーマを拡張する度に対応するスキーマに対応する全ての文法をメモリに格納しなければならず、資源制約の厳しいシステムで利用するには不適切である。提案方式により、拡張差分に対応する文法のみで拡張スキーマを実装可能になる。これにより、より低価格低スペックの家電センサメータ等の組込み機器にさまざまな拡張を実装することが容易になる。EXIの文法サイズは状態遷移の数にほぼ比例する。このことから、95を共有し5を拡張した2つの文法があった場合、従来では2つの文法をそれぞれ実装する必要が出たのに対して、提案方式では105分で十分である。上記の説明ではデコーダを中心にして本実施形態およびその効果を説明したが、エンコーダの場合も同様に本実施形態を適用可能である。基本スキーマの状態機械型文法をベースとして、拡張スキーマに対しては拡張された型に対応する部分にのみ状態機械型文法を追加することで、基本スキーマと拡張スキーマで状態機械を共有できる。これにより、エンコーダの記憶領域サイズを節約できる。以上のように、本実施形態により、基本スキーマを表現する状態機械型文法を一切変更することなく拡張スキーマを実装可能になる。その結果、基本スキーマ由来の状態機械と拡張スキーマ由来の状態機械の共通部分が最大となり、プログラムサイズメモリ使用量が減り、EXI処理系が搭載可能な組込み機器の種類が増える。なお、以上に説明した実施形態におけるEXIデコーダは、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、EXIデコーダにおけるストリーム入力部、ヘッダ解析部、文法選択部、ストリングテーブル初期化ベクタ選択部、およびパーサ部は、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、EXIデコーダは、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、CD-ROMなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、文法ストアおよびストリングテーブル初期化ベクタストアは、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはCD-R、CD-RW、DVD-RAM、DVD-Rなどの記憶媒体などを適宜利用して実現することができる。