XMLベースのコンテンツ記述のバイナリ表現機能を改善する方法において、インスタンス化されたXMLドキュメントの構造はツリー状のデータ構造に対応し、各ツリーノードはコンテンツ記述の1つの要素を成し、スキーマ中に定義された構造を有しており、該スキーマは、ツリーブランチコードTBCをもつツリーノードを有しており、前記ツリーブランチコードはスキーマブランチコードを有しており、デコーダは未知の要素をもつパスを読み飛ばし、個々の要素の後ろに位置するツリー構造のビット数ならびにその内容が伝送されてデコーダは該ビット数だけ飛び越えるかまたは、新たな要素をもつパスの伝送後に一義的な同期シーケンスを伝達して、既知のスキーマに属するツリーノードに到達して初めてデコーダがリスタートされることを特徴とする、XMLベースのコンテンツ記述のバイナリ表現機能を改善する方法。XMLベースのコンテンツ記述のバイナリ表現機能を改善する方法において、インスタンス化されたXMLドキュメントの構造はツリー状のデータ構造に対応し、各ツリーノードはコンテンツ記述の1つの要素を成し、スキーマ中に定義された構造を有しており、該スキーマは、ツリーブランチコードTBCをもつツリーノードを有しており、前記ツリーブランチコードはスキーマブランチコードを有しており、デコーダは、これまでのスキーマに整合しない新たな要素をもつパスのデコーディングにあたり、事前に所属のツリー構造ノードまたは完全な1つのスキーマが伝達されることを特徴とする、XMLベースのコンテンツ記述のバイナリ表現機能を改善する方法。本発明は、構造化されたXMLドキュメントのコーディングの最適化に関する。そして本発明の基礎とする課題は、たとえばMPEG-7ドキュメントなどのようなXMLベースのコンテント記述のバイナリ表現機能を改善する方法において、伝送すべきデータ量をできるかぎり僅かにし、ドキュメント内のサーチプロセスをできるかぎり簡単にし、さらに個々のスキーマテンプレートに含まれていないインスタンス化されたドキュメントの拡張をできるかぎり僅かな手間で行えるようにすることである。本発明によればこの課題は、インスタンス化されたXMLドキュメントの構造はツリー状のデータ構造に対応し、各ツリーノードはコンテンツ記述の1つの要素を成し、スキーマ中に定義された構造を有しており、該スキーマは、ツリーブランチコードをもつツリーノードを有しており、前記ツリーブランチコードはスキーマブランチコードを有しており、デコーダは未知の要素をもつパスを読み飛ばし、個々の要素の後ろに位置するツリー構造のビット数ならびにその内容が伝送されてデコーダは該ビット数だけ飛び越えるかまたは、新たな要素をもつパスの伝送後に一義的な同期シーケンスを伝達して、既知のスキーマに属するツリーノードに到達して初めてデコーダがリスタートされることを特徴とする、XMLベースのコンテンツ記述のバイナリ表現機能を改善する方法により解決される。さらに本発明の課題は、インスタンス化されたXMLドキュメントの構造はツリー状のデータ構造に対応し、各ツリーノードはコンテンツ記述の1つの要素を成し、スキーマ中に定義された構造を有しており、該スキーマは、ツリーブランチコードをもつツリーノードを有しており、前記ツリーブランチコードはスキーマブランチコードを有しており、デコーダは、これまでのスキーマに整合しない新たな要素をもつパスのデコーディングにあたり、事前に所属のツリー構造ノードまたは完全な1つのスキーマが伝達されることを特徴とする、XMLベースのコンテンツ記述のバイナリ表現機能を改善する方法により解決される。上述のISO/IECの立案書には殊に、XMLドキュメントの構造をデータツリーとして解釈できることが示されており、記述の各要素はこのツリーのノードに対応する。ノードの構造はドキュメントの基礎を成すスキーマ中の定義により規定される。これによりたとえば子要素の型および個数が定義される。この種のノードのプロトタイプは、たとえばこの立案書の第19頁に記載されている。このようなツリー構造ノードは、要素または複合型の名前、子要素の参照に用いられる符号語TBCツリーブランチコードTreeBranchCodeをもつフィールド、ならびに対応する子要素への参照を成すツリーブランチから成る。さらにこの立案書には、TBCが2つのコンポーネントすなわちスキーマブランチとポジション情報とに分けられていることが示されており、その際、スキーマ情報はスキーマ中に子要素として現れる要素から導出される一方、ポジション情報は何度も現れる可能性のある要素に対するポジション情報を有している。ここで子要素の種類として考えられるのは、やはり子要素を含むことのできる形式である複合型ComplexTypeの要素、あるいは子要素を含むことのできない形式である単純型SimpleTypeの要素もしくは属性である。フィールドpostionの長さは、スキーマ中で指定されている該当する要素の最大個数maxOccursによって規定される。たとえば最大数が7よりも大きいかまたは制限されていない場合には、コーディングすべきポジションを表すことができるまで、フィールドが適応的に伸ばされる。このような分割は、現時点のインスタンス化においていくつの子が存在するのかまたは存在することができるのかに左右されることなく、スキーマブランチコードまたはSBCSchemaBranchCodeが常に同じままという特性をもつ。ドキュメント内で移動する目的で、TBCつまりスキーマブランチコードSchemaBranchCodeおよび場合によってはポジションコードが並置され、これはドキュメント内のパスを表す。望ましい要素に辿りついたならば、最後のコードがテーブルに挿入される。望ましい要素がさらに別の子を持てないならば、つまり属性または単純型であるならば、このターミネーションコードは不要であり、送信されない。この場合には引き続き、属性または単純型の要素がコーディングされて伝送される。次に、図面を参照しながら実施例に基づき本発明について詳しく説明する。本発明は基本的に以下のように構成されている。すなわち、2つの異なるスキーマブランチコードが用いられ、これら2つのコードのうち一方がかなり頻繁に利用され、したがって圧縮が働かされ、スキーマブランチコードとポジションコードがまとめられ、さらにスキーマブランチコードのためのビット長がいっしょに伝送される。この場合、参照される要素の型が第1の部分だけにより指定され、伝送すべきスキーマバージョン番号とデコーダにとって既知である固定的に定められた拡張ストラテジとに基づき、拡張性の改善が実現される。圧縮の改善図1Aには単純型要素simpletypeelementまたは属性の従来のアドレッシングが、図1Bには複合型要素complextypeelementの従来のアドレッシングが示されており、これは公知の方法に対応するものである。図1Cおよび図1Dには、本発明の方法による相応のアドレッシング方法が示されている。この図から明らかなように、それぞれ異なる2つのスキーマブランチコードSBC-AおよびSBC-Bが用いられており、共通のスキーマブランチコードSBC-Bだけではない。冒頭で述べたようにこの種のアドレスパスは連結されたTBCコードから成り、つまり必要であるならば各スキーマブランチコードSBC-Aの間にもポジションコードposが設けられており、終端においてのみパスターミネーションコードを伴うスキーマブランチコードが設けられ、これにはさらに別のポジション情報は伴わず、その後に共通のスキーマブランチコードSBC-Bが設けられ、これにはツリー構造のリーフを成す単純型または属性の要素も含まれている可能性がある。連結されたTBCコードから成る経路の既述の構造からわかるように、パスの最後のTBCだけが属性または単純型要素を参照指示することができる。先行するすべてのTBCは複合型要素を参照指示しなければならず、その理由はそれらだけが子要素をもつことができるからである。そこで本発明による方法の場合、ドキュメント内のポジショニング用コードの長さを冒頭で述べたISO/IEC立案書よりも低減することを目的として、各ノードごとにスキーマブランチコードSchemaBranchCodeのための2つの異なるテーブルが導入される。テーブルAには複合型の要素だけしか含まれておらず、つまり子要素をもつことのできる要素だけしか含まれていない。他方のテーブルにはすべての要素が含まれており、つまり属性および単純型要素も含まれている。しかしここではパスターミネーション用のSBCを予約する必要がない。これら両方のテーブルのスキーマブランチコードを以下ではSBC-AもしくはSBC-Bと称する。パス全体はやはりTBCの連結によって形成され、その際、SBC-Aおよび場合によっては相応のポジションコードpositioncodeを伴う最後のTBCを除いてすべてのTBCが形成される。テーブルAを用いて作成されたパスの最初の部分の終端は、ターミネーションコードたとえばすべてのビット1によって合図される。その後、テーブルBから読み取られるスキーマブランチコードSchemaBranchCodeをもつTBCが必ず続く。ここで注意しなければならないことは、属性または単純型要素がアドレッシングされるときには本発明による方法においてもターミネーションコードを送信しなければならないことである。スキーマブランチコードの長さは可能な要素の個数に依存するので、テーブルA中のコードつまりコードSBC-Aはそれに応じて短くなる。コードSBC-AがコードSBC-Bよりも相当頻繁に利用されることも、圧縮に好適な影響を及ぼす。図2にはXMLスキーマテキストの一例が描かれており、図2Aおよび図2BにはSBC-AおよびSBC-Bのための対応するノードテーブルが示されている。この図から分かるように、SBC-Aについてはスキーマブランチコードを短くすることができる。それというのもここでは、単純型要素と属性を参照する必要がないからである。サーチ機能の改善バイナリ表現に必要とされるがISO/IEC立案書による方法によっては制約されていない機能は、ドキュメント内の所定の要素の簡略化されたサーチである。このサーチは簡単なフィルタメカニズムにより以下のようにして最適なかたちで実行することができ、これはドキュメント内のサーチされる要素を一義的にアドレッシングする事前に求められたビット列をビットストリーム内でパターン比較によりサーチすることによって行われる。ドキュメントツリーにおいて所定の要素を迅速にサーチするときにはビットストリームが構文解析され、適正なパスフラグメントについて言及された要素だけが詳細に考察される。ISO/IEC立案書に記載されている方法については、この種のフィルタリングは制約なしでは実行不可能である。その理由は、この場合のスキーマにおける少なくとも1つの要素の最大数が7よりも大きいかまたは制限されていないと、ポジションコードPositionCodeの長さを事前に決めることはできないからである。そこで本発明による方法の場合にはビットストリームの簡単なフィルタリングを目的として、パスを記述するツリーブランチノードTBCの部分的な再ソートが行われる。その際、ポジションコードはパスの終端にずらされる。これにより得られる利点は、スキーマブランチフラグメントSchemaBranchFragmentを含むパスの最初の部分は参照された要素の型だけしか指定しないことである。択一的な解決手法によれば第1のステップにおいて、ポジションコードPositionCodeが固定長の部分と可変長の部分とに分割される。第2のステップにおいて可変長の部分がTBCから取り出され、パスの終端にずらされる。これにより絶対アドレスの場合であれば、所定の要素のサーチのためにすでに事前にビットパターンを定めることができる。相対アドレスを使用した場合、パターンはドキュメント内の現在ポジションに依存する。この場合には新たな方法によって簡略化が行われ、フィルタリングのためにポジションコードPositionCodeをデコーディングして評価する必要がなくなる。完全な参照のためには完全なポジションコードPositionCodeを含めてパス全体を読み出してデコーディングする必要があり、そのようにすればノードごとに参照された子要素に適正に分岐させることができる。この方法のインプリメントを簡単にする目的でパスの最初に、ポジションコードを後置することなくパスの全長Lに関する情報を典型的にはビットで送信することができ、このようにすることでポジションコードに対するポインタZもいっしょに送ることができ、したがってSBCに対しパラレルに適正なポジションをデコーディングすることができる。このことにより付加的に、サーチされる要素に対する特定のポジションpositionのサーチも実現され、パスの一部分が各デコーダにとって既知ではないような以下で説明する拡張性の事例に対してもサーチがサポートされる。図3Aには、従来の方法における単純型要素または属性のアドレッシングの一例としてこの関係が示されている。図3Bには、本発明による方法に関して同様のことが示されている。図3Bからわかるように、それぞれ1つのパスにおけるすべてのスキーマブランチコードSBC-B1~SBC-B5が相前後して配置されていて、これは全体として長さLを有しており、この長さLは開始直後に最初に伝送される。ポジションコードpos1~pos5はSBCから分離されており、相前後して配置されている。このスキーマパターン定義からビット長Lを有する絶対アドレッシングのためのビットパターンを求めることができ、したがってパターン比較によりビットストリームのフィルタリングが可能となる。拡張性の改善ISO/IEC立案書のアルゴリズムに基づくコーディングスキーマはコンテキスト依存型であり、つまり各要素ごとにコンテキストにより決められた別の可能性だけがコーディングされる。デコーダはスキーマ定義を知っているときのみ、ビットパターンを読み出して適正に解釈することができる。デコーダはどのTBCコードがどの要素を参照指示するのか、各要素内のビットコードの長さはどれくらいかを知っていなければならず、その目的は各パスフラグメントごとに適正な数のビットが読み出されるようにするためである。実践においては、新しい境界条件たとえば新しいメタデータカテゴリを考慮する目的で、定義済みのスキーマをあとから拡張する事態が頻繁に発生することになる。このような拡張をオプションの要素または属性とすることができる。古いスキーマ定義に従って作成されXMLテキストフォーム中に保持されているドキュメントは、新しい定義に関しても引き続き有効である上位互換。しかしそれらを継承により導出されたデータ型としてもよく、制約の場合drivedbyrestrictionにはTBCを保持し、あるいは拡張の場合derivedbyextensionには以下で説明するように、拡張されたTBCテーブルを保持する。しかしながらたとえばISO/IEC立案書に示されているようなドキュメントのバイナリ表現の場合、このことはあてはまらない。なぜならばそこでは新しい要素/属性は、事前に別の要素/属性をアドレッシングしたTBCに割り当てられる可能性があるからである。本発明による方法であれば、この欠点を以下の規則によって回避することができる。本発明による方法によれば新しいオプションの要素は、ツリー構造ノードTSNTreeStructureNodeにおいて既存の後ろにのみ挿入することができ、かつ場合によっては存在するパスターミネーションコードPathTerminationCodeの前にのみ挿入することができる。ここで新しい要素にはこれまで利用されていなかったスキーマブランチコードSBCが割り当てられ、その際に既存の要素はそのスキーマブランチコード割り当てを失わない。拡張によって長くなったアドレスを用いたアドレッシングが行われることになるならば、コード長の変化に起因してすべてのバイナリ表現をもはやデコーディングできなくなってしまう。この問題を解決するため、本発明によれば以下のアドレッシングが取り入れられる。新しい要素/属性は、スキーマブランチコードに関して既存の要素/属性の後ろおよびツリー構造ノードTSNにおいて場合によっては存在するパスターミネーションの前にエントリされる。その際にスキーマブランチコードがもはや利用できなければ、アドレッシングが1つのビット分または複数のビット分だけたとえば最上位ビットの分だけ拡張される。既存のコードはたとえばゼロで拡張される。例外はパスターミネーションコードであって、これは1により拡張され、したがってツリー構造ノードの最後のノードはそのままである。その後、新しい要素/属性は新たに利用可能になったスキーマブランチコードSBCに割り当てられる。スキーマブランチコードのビット長変化はデコーダに通知しなければならない。インクリメンタルな拡張性を実現する目的で、スキーマの先行のバージョンが既知でなければならない。このために個々のバージョンの完全な情報を記憶する必要はない。そうではなく相応に修正されたツリー構造ノードの新たなバージョンのスキーマブランチコードのビット数または個数だけを記憶し、必要に応じて伝送すればよく、その際、誤りのあるコードを識別できるようにするためには2つ目のやり方が有利である。この情報は、変更されたコーディング済みのスキーマブランチコードの前に伝送する必要がある。このようにしてスキーマブランチコードのビット長がスキーマのバージョン番号と結合される。あるドキュメントをバイナリコーディングする前、使用されるスキーマのバージョンだけを指定すればよく、従来のように使用されているすべてのスキーマを伝送しなくてもよい。たとえばISO/IEC立案書のビットストリーム定義をバージョン情報用のフィールド分だけ拡張することができる。バージョンコントロールが実行されない場合には、確実に既知である参照としてたとえばMPEGー7などのような標準におけるスキーマ定義が使用される。このスキーマ定義をたとえばバージョン1と決めることができる。この種のバージョン情報のための1つの実施例を以下に示す。この実施例の場合にはISO/IEC立案書で指定されているようなストリームヘッダ中に、バージョン情報もビット長情報も付加的に格納される。この目的で図4に示されているような情報がデータストリーム中に格納される。標準化されたバージョンには一義的なバージョン識別子を割り当てることができ、これは図4AではM7_Version_IDとして指定されている。さらに書九件の拡張を拡張識別子で表すことができ、これは図4AではEXtension_IDと指定されている。拡張されたツリー構造ノードTSNのビット長もビットストリーム中に格納することができる。これは図4Aに示されているように、フラグDS_Extensionによって通知される。拡張されたツリー構造ノードTSNのツリーブランチコードTBCのビット長情報は、図4Aに示されているDS_Update_Infoにおいて図4Bに示されているようにコーディングされる。Number_of_changed_nodesという記号によって変更されたツリー構造ノードの個数が通報される。この個数は、ISO/IEC立案書で提案されているポジション情報に従い可変長でコーディングすることができる。変更されたツリー構造ノードの情報はビットストリームにおいて、ナビゲーション命令Navigation_CommandおよびナビゲーションパスNavigation_Pathによってアドレッシングすることができる。その場合、アドレッシングされたノードと同じ型であるあとで伝送されるすべての要素に適用される。以下では、変更された符号語長SBC_Lengthまたはスキーマブランチコードの変更された個数はデータストリームに挿入される。符号語長または個数はやはり、Number_of_changed_nodesのコーディングにも使用される方法に従いコーディングされる。別の実施例の場合、変更されたツリー構造ノードは、スキーマにおいて複合型のダイレクトなアドレッシングにより識別することができる。このダイレクトなアドレッシングはたとえば、スキーマ中に定義された複合型のカウントにより達成することができる。さらに別の問題として挙げられるのは、新しいスキーマに従いコーディングされたドキュメントが先行のスキーマ定義だけしか知らないデコーダによってデコーディングされることである下位互換。XMLベースのテキストのXMLドキュメントの場合、このことは古いスキーマ中ですでに既知であった要素については可能である。これは2つの特性に基づいている。-古いスキーマ中で定義されていた複合型の要素はそのまま保持されているが、含まれている要素や属性もしくはデータ型については異なっている可能性がある。-要素の開始マークおよび終了マークいわゆるタグにより新しい要素を飛び越えることができ、既知の要素をデコーディングすることができる。先行のアドレッシングのやり方に従い上記の例で示したように様々なバージョンのツリー構造ノードのビット長が伝送される場合、拡張されたツリー構造ノードの既知の要素は、まだ先行のスキーマに基づき動作している古いデコーダによって処理することができる。ただし新しい要素に至るパス識別子はこの古いデコーダによって飛び越えることができず、デコーダはもはやデコーディングを続けることができなくなる。この重要な機能をサポートする目的で本発明による方法の場合には下位互換のコーディング済みドキュメントに対し以下の代案が適用される。aTSN中の新しい要素/属性がアドレッシングされると、その要素/属性のための完全なサブツリーまたは後続ツリーに関するビットの個数が、挿入されたNビットの内容データも含めてまえもって付加的に伝送される。このようにしてデコーダは自身にとって既知でないやり方でコーディングされた次のNビットを飛び越えて、既知のTSNのところから再開することができる。b新しい要素/属性を含むパスの伝送後、一義的な同期シーケンスが伝達され、デコーダはこの同期シーケンスを既知のTSNのところから再開するのに利用できる。c新しい要素を含むパスを伝達するとき、完全なスキーマの一部分を成すそのパスのTSNを事前に伝送する必要がある。d新しい要素を含むパスを伝達するとき、完全なスキーマをまえもって伝送する必要がある。代案cおよびdの場合、デコーダは新たに追加されたドキュメントの内容もデコーディングすることができ、必要に応じてこれを記憶するかまたは後続処理することができる。図5aおよび図5bに示されている例はスキーマ定義の新しいバージョンにおける変更を表しており、図5aには複合型要素の拡張されたツリー構造ノードが、図5bには変形されたスキーマにおける拡張されたツリー構造ノードが描かれている。要素3~6は新しいバージョンに付け加えられている。スキーマブランチコードの長さはこれにより2から3に伸ばされている。しかしこれまでのアドレスは、MSBとしてゼロだけ拡張されたことを除いてそのまま維持される。次に、拡張されたスキーマ要素のコーディングに関する一例を図6Aおよび図6Bに示す。ここでは出発点として、図2との関連で使われた例を用いる。わかりやすくするためこの図面では、ノードテーブルを分割する上述の方法は省略する。また、もとのスキーマPurchaseOrderTypeをいくつかの要素だけ拡張することにする。図6A中、図2とは異なる拡張は太字で示されている。つまりここでは要素billToMethodOfPaymentBankDataが新たに挿入される。したがって新しいツリーブランチコードテーブルをこれに応じて拡張する必要がある。このためすべての可能性をコーディングするには3つのビットでは不十分である。図6bを参照しながら、4つのビットを用いたツリーブランチコードのこのような拡張について詳しく説明する。さて、大枠となるこのような条件のもとで2つの事例を扱う。事例1:古いスキーマ定義に従ってコーディングされたドキュメントが、新しいスキーマを知っているデコーダに伝送される。コーディング済みのドキュメントの基礎を成すバージョン番号を最初にデコーダに伝達しなければならない。この目的でデコーダは、各バージョン番号ごとにすべての要素に対しスキーマブランチコードSBCのビット幅または個数の格納されているテーブルをもっている。これによりデコーダにおいて、PruchaseOrderType型の要素は4つのビットではなく3つのビットだけでコーディングされていることが確認される。この情報を用いるだけでドキュメントを適正にデコーディングすることができる。事例2:古いスキーマ定義に従ってコーディングされたドキュメントが、古いスキーマだけしか知らないデコーダに伝送される。デコーダはスキーマのバージョン番号に基づき、未知の要素が伝送される可能性があること、未知の要素は異なるビット幅でコーディングされている可能性のあることを識別する。要素の新たなビット幅をデコーダは知っていなければならず、その理由はさもないとエンコーダとの同期を失ってしまうからである。この場合、個々の要素をビット幅に対応づける情報たとえばテーブルが本来のドキュメントの前に伝送されるかまたは、デコーダは指定されたアドレスURIのところでこの情報をア本発明の方法によればエンコーダは、ドキュメントのコーディングに関して4つの可能なオプションをもっている。オプション1:新しい要素ごとに、図7に示されているような下位の適切なサブツリーの長さが伝送される。デコーダはスキーマブランチコード0101に基づき、標準スキーマ中に含まれていない要素がアドレッシングされていることを識別する。これに応じてデコーダは次のビットを未知の要素の長さLと解釈する。この長さ情報は、ISO/IECドラフトに示されているような適応的な可変の整数コーディングに従って行うことができる。この長さ情報を用いてデコーダは下位のサブツリーbillToを飛び越え、SchemaBranchCode0010のところから再開する。そして次の要素commentから再びデコーディングすることができる。オプション2:図8に示されているように、新しい要素の後で一義的な同期シーケンスが伝達される。デコーダは、規範的に定められた再同期マーカを見つけるまでビットストリームを構文解析し、その後、再びデコーディングを継続する。この方法の場合には複数の新しい要素をひとまとまりでコーディングすることができ、最後の要素の後にはじめて再同期マークを伝送することができる。オプション3:新しい要素を含むツリー構造ノードならびにドキュメントツリー中のそれらのポジションが、本来のドキュメントの前に伝送される。したがってこの手法の場合、デコーダにとって既知であるスキーマが更新される。このためドキュメントの伝送は、スキーマが既知である状況に応じて行われる。しかも新しいスキーマを識別する一義的なバージョン番号が割り当てられるならば、デコーダは新たに伝送されたスキーマをそれらの新しい要素に関して既知の要素を拡張するために用いることができる。オプション4:1つの完全な新しいスキーマが伝送される。この場合、デコーダはドキュメントを、それが既知のスキーマに従ってコーディングされたように取り扱うことができる。しかも新しいスキーマを識別する一義的なバージョン番号が割り当てられるならば、デコーダは新たに伝送されたスキーマをそれらの新しい要素に関して既知の要素を拡張するために用いることができる。なお、本発明による個々の方法をそれ自体単独でまたは組み合わせて実施することができる。