JP2011129156A - Ｍｐｅｇ−７および他のｘｍｌベースのコンテンツ記述のバイナリ表現機能を改善する方法 - Google Patents

Abstract

【課題】ＸＭＬベースのコンテント記述のバイナリ表現機能の改善にあたり、伝送すべきデータ量を僅かにし、ドキュメント内のサーチプロセスを簡単にし、個々のスキーマテンプレートに含まれていないインスタンス化されたドキュメントの拡張を僅かな手間で行えるようにする。
【解決手段】インスタンス化されたＸＭＬドキュメントの構造はツリー状のデータ構造に対応し、各ツリーノードはコンテンツ記述の１つの要素を成し、スキーマ中に定義された構造を有している。デコーダは未知の要素をもつパスを読み飛ばし、個々の要素の後ろに位置するツリー構造のビット数とその内容とが伝送されて、デコーダはこのビット数だけ飛び越えるかまたは、新たな要素をもつパスの伝送後に一義的な同期シーケンスを伝達して、既知のスキーマに属するツリーノードに到達して初めてデコーダがリスタートされる。
【選択図】図１

Description

本発明は、たとえばＭＰＥＧ−７などのようにＸＭＬベースで構造化されたドキュメントのコーディングおよびデコーディングに関する。ＸＭＬ（extensible markup language）はドキュメント構造定義用の標準であり、構造化されたデータをテキストファイルで表示するために用いられ、たとえばＸＨＴＭＬのベースを成している。ＸＭＬベースで構造化されたこのようなドキュメントは以下ではスキーマとも称する多数の構造化要素に基づいており、それらはたとえばドキュメント型定義（ＤＴＤ）、ＸＭＬスキーマまたはマルチメディア記述スキーマ（ＤＳ）を用いて指定することができる。

ISO/IEC CD 15938-1 Information Technology の立案書 - Multimedia Content Description Interface: System, ISO/IEC JTC 1 SC29/WG11/N3701, La Baule (France), 10. 2000の殊に第１５〜２２頁によって、ＭＰＥＧ−７データファイルのバイナリフォーマットおよびツリーブランチコードテーブルを用いたナビゲーションパスの構造が知られている。

SO/IEC CD 15938-1 Information Technology の立案書

本発明は、構造化されたＸＭＬドキュメントのコーディングの最適化に関する。そして本発明の基礎とする課題は、たとえばＭＰＥＧ−７ドキュメントなどのようなＸＭＬベースのコンテント記述のバイナリ表現機能を改善する方法において、伝送すべきデータ量をできるかぎり僅かにし、ドキュメント内のサーチプロセスをできるかぎり簡単にし、さらに個々のスキーマテンプレートに含まれていないインスタンス化されたドキュメントの拡張をできるかぎり僅かな手間で行えるようにすることである。

本発明によればこの課題は、インスタンス化されたＸＭＬドキュメントの構造はツリー状のデータ構造に対応し、各ツリーノードはコンテンツ記述の１つの要素を成し、スキーマ中に定義された構造を有しており、該スキーマは、ツリーブランチコードをもつツリーノードを有しており、前記ツリーブランチコードはスキーマブランチコードを有しており、デコーダは未知の要素をもつパスを読み飛ばし、個々の要素の後ろに位置するツリー構造のビット数ならびにその内容が伝送されてデコーダは該ビット数だけ飛び越えるかまたは、新たな要素をもつパスの伝送後に一義的な同期シーケンスを伝達して、既知のスキーマに属するツリーノードに到達して初めてデコーダがリスタートされることを特徴とする、ＸＭＬベースのコンテンツ記述のバイナリ表現機能を改善する方法により解決される。さらに本発明の課題は、インスタンス化されたＸＭＬドキュメントの構造はツリー状のデータ構造に対応し、各ツリーノードはコンテンツ記述の１つの要素を成し、スキーマ中に定義された構造を有しており、該スキーマは、ツリーブランチコードをもつツリーノードを有しており、前記ツリーブランチコードはスキーマブランチコードを有しており、デコーダは、これまでのスキーマに整合しない新たな要素をもつパスのデコーディングにあたり、事前に所属のツリー構造ノードまたは完全な１つのスキーマが伝達されることを特徴とする、ＸＭＬベースのコンテンツ記述のバイナリ表現機能を改善する方法により解決される。

上述のＩＳＯ／ＩＥＣの立案書には殊に、ＸＭＬドキュメントの構造をデータツリーとして解釈できることが示されており、記述の各要素はこのツリーのノードに対応する。ノードの構造はドキュメントの基礎を成すスキーマ中の定義により規定される。これによりたとえば子要素の型および個数が定義される。この種のノードのプロトタイプは、たとえばこの立案書の第１９頁に記載されている。このようなツリー構造ノードは、要素または複合型の名前、子要素の参照に用いられる符号語ＴＢＣ（ツリーブランチコード Tree Branch Code）をもつフィールド、ならびに対応する子要素への参照を成すツリーブランチから成る。さらにこの立案書には、ＴＢＣが２つのコンポーネントすなわちスキーマブランチとポジション情報とに分けられていることが示されており、その際、スキーマ情報はスキーマ中に子要素として現れる要素から導出される一方、ポジション情報は何度も現れる可能性のある要素に対するポジション情報を有している。ここで子要素の種類として考えられるのは、やはり子要素を含むことのできる形式である複合型 Complex Typeの要素、あるいは子要素を含むことのできない形式である単純型 Simple Type の要素もしくは属性である。フィールド#postionの長さは、スキーマ中で指定されている該当する要素の最大個数（"maxOccurs"）によって規定される。たとえば最大数が７よりも大きいかまたは制限されていない場合には、コーディングすべきポジションを表すことができるまで、フィールドが適応的に伸ばされる。このような分割は、現時点のインスタンス化においていくつの子が存在するのかまたは存在することができるのかに左右されることなく、スキーマブランチコードまたはＳＢＣ "SchemaBranchCode が常に同じままという特性をもつ。

ドキュメント内で移動する目的で、ＴＢＣつまりスキーマブランチコード SchemaBranchCodeおよび場合によってはポジションコードが並置され、これはドキュメント内のパスを表す。望ましい要素に辿りついたならば、最後のコードがテーブルに挿入される。望ましい要素がさらに別の子を持てないならば、つまり属性または単純型であるならば、このターミネーションコードは不要であり、送信されない。この場合には引き続き、属性または単純型の要素がコーディングされて伝送される。

次に、図面を参照しながら実施例に基づき本発明について詳しく説明する。

Ａ〜Ｄは圧縮改善について説明するために様々な要素の型のアドレッシングの様子を示す図 ＸＭＬスキーマテキストを示す図 スキーマテキストに属するノードテーブルを示す図 スキーマテキストに属するノードテーブルを示す図 本発明によるサーチ方式の改善について説明する図 本発明によるサーチ方式の改善について説明する図 拡張性の改善について説明するためデータストリームの抜粋を示す図 拡張性の改善について説明するためデータストリームの抜粋を示す図 拡張性の改善について説明するため拡張されたツリーブランチノードを示す図 拡張性の改善について説明するため拡張されたツリーブランチノードを示す図 図２および図２Ｂと同様であるが拡張された要素とともに示す図 図２および図２Ｂと同様であるが拡張された要素とともに示す図 未知の要素を飛び越えるためのデコーダのためのシーケンスを示す図 未知の要素を飛び越えるためのデコーダのためのシーケンスを示す図

本発明は基本的に以下のように構成されている。すなわち、２つの異なるスキーマブランチコードが用いられ、これら２つのコードのうち一方がかなり頻繁に利用され、したがって圧縮が働かされ、スキーマブランチコードとポジションコードがまとめられ、さらにスキーマブランチコードのためのビット長がいっしょに伝送される。この場合、参照される要素の型が第１の部分だけにより指定され、伝送すべきスキーマバージョン番号とデコーダにとって既知である固定的に定められた拡張ストラテジとに基づき、拡張性の改善が実現される。

圧縮の改善
図１Ａには単純型要素（simple type element）または属性の従来のアドレッシングが、図１Ｂには複合型要素（complex type element）の従来のアドレッシングが示されており、これは公知の方法に対応するものである。図１Ｃおよび図１Ｄには、本発明の方法による相応のアドレッシング方法が示されている。この図から明らかなように、それぞれ異なる２つのスキーマブランチコードＳＢＣ−ＡおよびＳＢＣ−Ｂが用いられており、共通のスキーマブランチコードＳＢＣ−Ｂだけではない。冒頭で述べたようにこの種のアドレスパスは連結されたＴＢＣコードから成り、つまり必要であるならば各スキーマブランチコードＳＢＣ−Ａの間にもポジションコード#posが設けられており、終端においてのみパスターミネーションコードを伴うスキーマブランチコードが設けられ、これにはさらに別のポジション情報は伴わず、その後に共通のスキーマブランチコードＳＢＣ−Ｂが設けられ、これにはツリー構造のリーフを成す単純型または属性の要素も含まれている可能性がある。

連結されたＴＢＣコードから成る経路の既述の構造からわかるように、パスの最後のＴＢＣだけが属性または単純型要素を参照指示することができる。先行するすべてのＴＢＣは複合型要素を参照指示しなければならず、その理由はそれらだけが子要素をもつことができるからである。そこで本発明による方法の場合、ドキュメント内のポジショニング用コードの長さを冒頭で述べたＩＳＯ／ＩＥＣ立案書よりも低減することを目的として、各ノードごとにスキーマブランチコード#SchemaBranchCodeのための２つの異なるテーブルが導入される。テーブルＡには複合型の要素だけしか含まれておらず、つまり子要素をもつことのできる要素だけしか含まれていない。他方のテーブルにはすべての要素が含まれており、つまり属性および単純型要素も含まれている。しかしここではパスターミネーション用のＳＢＣを予約する必要がない。これら両方のテーブルのスキーマブランチコードを以下ではＳＢＣ−ＡもしくはＳＢＣ−Ｂと称する。パス全体はやはりＴＢＣの連結によって形成され、その際、ＳＢＣ−Ａおよび場合によっては相応のポジションコード#position-codeを伴う最後のＴＢＣを除いてすべてのＴＢＣが形成される。テーブルＡを用いて作成されたパスの最初の部分の終端は、ターミネーションコードたとえばすべてのビット１によって合図される。その後、テーブルＢから読み取られるスキーマブランチコード#SchemaBranchCodeをもつＴＢＣが必ず続く。ここで注意しなければならないことは、属性または単純型要素がアドレッシングされるときには本発明による方法においてもターミネーションコードを送信しなければならないことである。スキーマブランチコードの長さは可能な要素の個数に依存するので、テーブルＡ中のコードつまりコードＳＢＣ−Ａはそれに応じて短くなる。コードＳＢＣ−ＡがコードＳＢＣ−Ｂよりも相当頻繁に利用されることも、圧縮に好適な影響を及ぼす。

図２にはＸＭＬスキーマテキストの一例が描かれており、図２Ａおよび図２ＢにはＳＢＣ−ＡおよびＳＢＣ−Ｂのための対応するノードテーブルが示されている。この図から分かるように、ＳＢＣ−Ａについてはスキーマブランチコードを短くすることができる。それというのもここでは、単純型要素と属性を参照する必要がないからである。

サーチ機能の改善
バイナリ表現に必要とされるがＩＳＯ／ＩＥＣ立案書による方法によっては制約されていない機能は、ドキュメント内の所定の要素の簡略化されたサーチである。このサーチは簡単なフィルタメカニズムにより以下のようにして最適なかたちで実行することができ、これはドキュメント内のサーチされる要素を一義的にアドレッシングする事前に求められたビット列をビットストリーム内でパターン比較によりサーチすることによって行われる。ドキュメントツリーにおいて所定の要素を迅速にサーチするときにはビットストリームが構文解析され、適正なパスフラグメントについて言及された要素だけが詳細に考察される。ＩＳＯ／ＩＥＣ立案書に記載されている方法については、この種のフィルタリングは制約なしでは実行不可能である。その理由は、この場合のスキーマにおける少なくとも１つの要素の最大数が７よりも大きいかまたは制限されていないと、ポジションコード#PositionCodeの長さを事前に決めることはできないからである。

そこで本発明による方法の場合にはビットストリームの簡単なフィルタリングを目的として、パスを記述するツリーブランチノード（ＴＢＣ）の部分的な再ソートが行われる。その際、ポジションコードはパスの終端にずらされる。これにより得られる利点は、スキーマブランチフラグメント#SchemaBranchFragmentを含むパスの最初の部分は参照された要素の型だけしか指定しないことである。

択一的な解決手法によれば第１のステップにおいて、ポジションコード#PositionCodeが固定長の部分と可変長の部分とに分割される。第２のステップにおいて可変長の部分がＴＢＣから取り出され、パスの終端にずらされる。

これにより絶対アドレスの場合であれば、所定の要素のサーチのためにすでに事前にビットパターンを定めることができる。相対アドレスを使用した場合、パターンはドキュメント内の現在ポジションに依存する。この場合には新たな方法によって簡略化が行われ、フィルタリングのためにポジションコード#PositionCodeをデコーディングして評価する必要がなくなる。

完全な参照のためには完全なポジションコード#PositionCodeを含めてパス全体を読み出してデコーディングする必要があり、そのようにすればノードごとに参照された子要素に適正に分岐させることができる。

この方法のインプリメントを簡単にする目的でパスの最初に、ポジションコードを後置することなくパスの全長Ｌに関する情報を典型的にはビットで送信することができ、このようにすることでポジションコードに対するポインタＺもいっしょに送ることができ、したがってＳＢＣに対しパラレルに適正なポジションをデコーディングすることができる。このことにより付加的に、サーチされる要素に対する特定のポジション（#position）のサーチも実現され、パスの一部分が各デコーダにとって既知ではないような以下で説明する拡張性の事例に対してもサーチがサポートされる。

図３Ａには、従来の方法における単純型要素または属性のアドレッシングの一例としてこの関係が示されている。図３Ｂには、本発明による方法に関して同様のことが示されている。図３Ｂからわかるように、それぞれ１つのパスにおけるすべてのスキーマブランチコードＳＢＣ−Ｂ１〜ＳＢＣ−Ｂ５が相前後して配置されていて、これは全体として長さＬを有しており、この長さＬは開始直後に最初に伝送される。ポジションコード#pos1〜#pos5はＳＢＣから分離されており、相前後して配置されている。このスキーマパターン定義からビット長Ｌを有する絶対アドレッシングのためのビットパターンを求めることができ、したがってパターン比較によりビットストリームのフィルタリングが可能となる。

拡張性の改善
ＩＳＯ／ＩＥＣ立案書のアルゴリズムに基づくコーディングスキーマはコンテキスト依存型であり、つまり各要素ごとにコンテキストにより決められた別の可能性だけがコーディングされる。デコーダはスキーマ定義を知っているときのみ、ビットパターンを読み出して適正に解釈することができる。デコーダはどのＴＢＣコードがどの要素を参照指示するのか、各要素内のビットコードの長さはどれくらいかを知っていなければならず、その目的は各パスフラグメントごとに適正な数のビットが読み出されるようにするためである。

実践においては、新しい境界条件たとえば新しいメタデータカテゴリを考慮する目的で、定義済みのスキーマをあとから拡張する事態が頻繁に発生することになる。このような拡張をオプションの要素または属性とすることができる。古いスキーマ定義に従って作成されＸＭＬテキストフォーム中に保持されているドキュメントは、新しい定義に関しても引き続き有効である（上位互換）。しかしそれらを継承により導出されたデータ型としてもよく、制約の場合（drived by restriction）にはＴＢＣを保持し、あるいは拡張の場合（derived by extension）には以下で説明するように、拡張されたＴＢＣテーブルを保持する。

しかしながらたとえばＩＳＯ／ＩＥＣ立案書に示されているようなドキュメントのバイナリ表現の場合、このことはあてはまらない。なぜならばそこでは新しい要素／属性は、事前に別の要素／属性をアドレッシングしたＴＢＣに割り当てられる可能性があるからである。本発明による方法であれば、この欠点を以下の規則によって回避することができる。

本発明による方法によれば新しいオプションの要素は、ツリー構造ノードＴＳＮ（Tree Structure Node）において既存の後ろにのみ挿入することができ、かつ場合によっては存在するパスターミネーションコード Path Termination Code の前にのみ挿入することができる。ここで新しい要素にはこれまで利用されていなかったスキーマブランチコードＳＢＣが割り当てられ、その際に既存の要素はそのスキーマブランチコード割り当てを失わない。

拡張によって長くなったアドレスを用いたアドレッシングが行われることになるならば、コード長の変化に起因してすべてのバイナリ表現をもはやデコーディングできなくなってしまう。この問題を解決するため、本発明によれば以下のアドレッシングが取り入れられる。

新しい要素／属性は、スキーマブランチコードに関して既存の要素／属性の後ろおよびツリー構造ノードＴＳＮにおいて場合によっては存在するパスターミネーションの前にエントリされる。その際にスキーマブランチコードがもはや利用できなければ、アドレッシングが１つのビット分または複数のビット分だけたとえば最上位ビットの分だけ拡張される。既存のコードはたとえばゼロで拡張される。例外はパスターミネーションコードであって、これは１により拡張され、したがってツリー構造ノードの最後のノードはそのままである。その後、新しい要素／属性は新たに利用可能になったスキーマブランチコードＳＢＣに割り当てられる。スキーマブランチコードのビット長変化はデコーダに通知しなければならない。インクリメンタルな拡張性を実現する目的で、スキーマの先行のバージョンが既知でなければならない。このために個々のバージョンの完全な情報を記憶する必要はない。そうではなく相応に修正されたツリー構造ノードの新たなバージョンのスキーマブランチコードのビット数または個数だけを記憶し、必要に応じて伝送すればよく、その際、誤りのあるコードを識別できるようにするためには２つ目のやり方が有利である。この情報は、変更されたコーディング済みのスキーマブランチコードの前に伝送する必要がある。このようにしてスキーマブランチコードのビット長がスキーマのバージョン番号と結合される。あるドキュメントをバイナリコーディングする前、使用されるスキーマのバージョンだけを指定すればよく、従来のように使用されているすべてのスキーマを伝送しなくてもよい。たとえばＩＳＯ／ＩＥＣ立案書のビットストリーム定義をバージョン情報用のフィールド分だけ拡張することができる。バージョンコントロールが実行されない場合には、確実に既知である参照としてたとえばＭＰＥＧー７などのような標準におけるスキーマ定義が使用される。このスキーマ定義をたとえばバージョン１と決めることができる。この種のバージョン情報のための１つの実施例を以下に示す。

この実施例の場合にはＩＳＯ／ＩＥＣ立案書で指定されているようなストリームヘッダ中に、バージョン情報もビット長情報も付加的に格納される。この目的で図４に示されているような情報がデータストリーム中に格納される。

標準化されたバージョンには一義的なバージョン識別子を割り当てることができ、これは図４ＡではＭ７＿Ｖｅｒｓｉｏｎ＿ＩＤとして指定されている。さらに書九件の拡張を拡張識別子で表すことができ、これは図４ＡではＥＸｔｅｎｓｉｏｎ＿ＩＤと指定されている。拡張されたツリー構造ノードＴＳＮのビット長もビットストリーム中に格納することができる。これは図４Ａに示されているように、フラグＤＳ＿Ｅｘｔｅｎｓｉｏｎによって通知される。拡張されたツリー構造ノードＴＳＮのツリーブランチコードＴＢＣのビット長情報は、図４Ａに示されているＤＳ＿Ｕｐｄａｔｅ＿Ｉｎｆｏ（）において図４Ｂに示されているようにコーディングされる。Ｎｕｍｂｅｒ＿ｏｆ＿ｃｈａｎｇｅｄ＿ｎｏｄｅｓという記号によって変更されたツリー構造ノードの個数が通報される。この個数は、ＩＳＯ／ＩＥＣ立案書で提案されているポジション情報に従い可変長でコーディングすることができる。

変更されたツリー構造ノードの情報はビットストリームにおいて、ナビゲーション命令Ｎａｖｉｇａｔｉｏｎ＿ＣｏｍｍａｎｄおよびナビゲーションパスＮａｖｉｇａｔｉｏｎ＿Ｐａｔｈ（）によってアドレッシングすることができる。その場合、アドレッシングされたノードと同じ型であるあとで伝送されるすべての要素に適用される。以下では、変更された符号語長ＳＢＣ＿Ｌｅｎｇｔｈまたはスキーマブランチコードの変更された個数はデータストリームに挿入される。符号語長または個数はやはり、Ｎｕｍｂｅｒ＿ｏｆ＿ｃｈａｎｇｅｄ＿ｎｏｄｅｓのコーディングにも使用される方法に従いコーディングされる。

別の実施例の場合、変更されたツリー構造ノードは、スキーマにおいて複合型のダイレクトなアドレッシングにより識別することができる。このダイレクトなアドレッシングはたとえば、スキーマ中に定義された複合型のカウントにより達成することができる。

さらに別の問題として挙げられるのは、新しいスキーマに従いコーディングされたドキュメントが先行のスキーマ定義だけしか知らないデコーダによってデコーディングされることである（下位互換）。ＸＭＬベースのテキストのＸＭＬドキュメントの場合、このことは古いスキーマ中ですでに既知であった要素については可能である。これは２つの特性に基づいている。
−古いスキーマ中で定義されていた複合型の要素はそのまま保持されているが、含まれている要素や属性もしくはデータ型については異なっている可能性がある。
−要素の開始マークおよび終了マークいわゆるタグにより新しい要素を飛び越えることができ、既知の要素をデコーディングすることができる。

先行のアドレッシングのやり方に従い上記の例で示したように様々なバージョンのツリー構造ノードのビット長が伝送される場合、拡張されたツリー構造ノードの既知の要素は、まだ先行のスキーマに基づき動作している「古い」デコーダによって処理することができる。ただし新しい要素に至るパス識別子はこの「古い」デコーダによって飛び越えることができず、デコーダはもはやデコーディングを続けることができなくなる。この重要な機能をサポートする目的で本発明による方法の場合には下位互換のコーディング済みドキュメントに対し以下の代案が適用される。
ａ）ＴＳＮ中の新しい要素／属性がアドレッシングされると、その要素／属性のための完全なサブツリーまたは後続ツリーに関するビットの個数が、挿入されたＮビットの内容データも含めてまえもって付加的に伝送される。このようにしてデコーダは自身にとって既知でないやり方でコーディングされた次のＮビットを飛び越えて、既知のＴＳＮのところから再開することができる。
ｂ）新しい要素／属性を含むパスの伝送後、一義的な同期シーケンスが伝達され、デコーダはこの同期シーケンスを既知のＴＳＮのところから再開するのに利用できる。
ｃ）新しい要素を含むパスを伝達するとき、完全なスキーマの一部分を成すそのパスのＴＳＮを事前に伝送する必要がある。
ｄ）新しい要素を含むパスを伝達するとき、完全なスキーマをまえもって伝送する必要がある。

代案ｃ）およびｄ）の場合、デコーダは新たに追加されたドキュメントの内容もデコーディングすることができ、必要に応じてこれを記憶するかまたは後続処理することができる。

図５ａおよび図５ｂに示されている例はスキーマ定義の新しいバージョンにおける変更を表しており、図５ａには複合型要素の拡張されたツリー構造ノードが、図５ｂには変形されたスキーマにおける拡張されたツリー構造ノードが描かれている。要素３〜６は新しいバージョンに付け加えられている。スキーマブランチコードの長さはこれにより２から３に伸ばされている。しかしこれまでのアドレスは、ＭＳＢとしてゼロだけ拡張されたことを除いてそのまま維持される。

次に、拡張されたスキーマ要素のコーディングに関する一例を図６Ａおよび図６Ｂに示す。ここでは出発点として、図２との関連で使われた例を用いる。わかりやすくするためこの図面では、ノードテーブルを分割する上述の方法は省略する。また、もとのスキーマ "PurchaseOrderType" をいくつかの要素だけ拡張することにする。図６Ａ中、図２とは異なる拡張は太字で示されている。

つまりここでは要素 "billTo", "MethodOfPayment", "BankData" が新たに挿入される。したがって新しいツリーブランチコードテーブルをこれに応じて拡張する必要がある。このためすべての可能性をコーディングするには３つのビットでは不十分である。図６ｂを参照しながら、４つのビットを用いたツリーブランチコードのこのような拡張について詳しく説明する。

さて、大枠となるこのような条件のもとで２つの事例を扱う。

事例１：
古いスキーマ定義に従ってコーディングされたドキュメントが、新しいスキーマを知っているデコーダに伝送される。コーディング済みのドキュメントの基礎を成すバージョン番号を最初にデコーダに伝達しなければならない。この目的でデコーダは、各バージョン番号ごとにすべての要素に対しスキーマブランチコードＳＢＣのビット幅または個数の格納されているテーブルをもっている。これによりデコーダにおいて、"PruchaseOrderType" 型の要素は４つのビットではなく３つのビットだけでコーディングされていることが確認される。この情報を用いるだけでドキュメントを適正にデコーディングすることができる。

事例２：
古いスキーマ定義に従ってコーディングされたドキュメントが、古いスキーマだけしか知らないデコーダに伝送される。デコーダはスキーマのバージョン番号に基づき、未知の要素が伝送される可能性があること、未知の要素は異なるビット幅でコーディングされている可能性のあることを識別する。要素の新たなビット幅をデコーダは知っていなければならず、その理由はさもないとエンコーダとの同期を失ってしまうからである。この場合、個々の要素をビット幅に対応づける情報たとえばテーブルが本来のドキュメントの前に伝送されるかまたは、デコーダは指定されたアドレス（ＵＲＩ）のところでこの情報をア
本発明の方法によればエンコーダは、ドキュメントのコーディングに関して４つの可能なオプションをもっている。

オプション１：
新しい要素ごとに、図７に示されているような下位の適切なサブツリーの長さが伝送される。デコーダはスキーマブランチコード０１０１に基づき、標準スキーマ中に含まれていない要素がアドレッシングされていることを識別する。これに応じてデコーダは次のビットを未知の要素の長さＬと解釈する。この長さ情報は、ＩＳＯ／ＩＥＣドラフトに示されているような適応的な可変の整数コーディングに従って行うことができる。この長さ情報を用いてデコーダは下位のサブツリー "billTo"を飛び越え、#SchemaBranch-Code 0010 のところから再開する。そして次の要素 "comment" から再びデコーディングすることができる。

オプション２：
図８に示されているように、新しい要素の後で一義的な同期シーケンスが伝達される。デコーダは、規範的に定められた再同期マーカを見つけるまでビットストリームを構文解析し、その後、再びデコーディングを継続する。この方法の場合には複数の新しい要素をひとまとまりでコーディングすることができ、最後の要素の後にはじめて再同期マークを伝送することができる。

オプション３：
新しい要素を含むツリー構造ノードならびにドキュメントツリー中のそれらのポジションが、本来のドキュメントの前に伝送される。したがってこの手法の場合、デコーダにとって既知であるスキーマが更新される。このためドキュメントの伝送は、スキーマが既知である状況に応じて行われる。しかも新しいスキーマを識別する一義的なバージョン番号が割り当てられるならば、デコーダは新たに伝送されたスキーマをそれらの新しい要素に関して既知の要素を拡張するために用いることができる。

オプション４：
１つの完全な新しいスキーマが伝送される。この場合、デコーダはドキュメントを、それが既知のスキーマに従ってコーディングされたように取り扱うことができる。しかも新しいスキーマを識別する一義的なバージョン番号が割り当てられるならば、デコーダは新たに伝送されたスキーマをそれらの新しい要素に関して既知の要素を拡張するために用いることができる。

なお、本発明による個々の方法をそれ自体単独でまたは組み合わせて実施することができる。

Claims (2)

1. ＸＭＬベースのコンテンツ記述のバイナリ表現機能を改善する方法において、
   インスタンス化されたＸＭＬドキュメントの構造はツリー状のデータ構造に対応し、各ツリーノードはコンテンツ記述の１つの要素を成し、スキーマ中に定義された構造を有しており、
   該スキーマは、ツリーブランチコード（ＴＢＣ）をもつツリーノードを有しており、
   前記ツリーブランチコードはスキーマブランチコードを有しており、
   デコーダは未知の要素をもつパスを読み飛ばし、個々の要素の後ろに位置するツリー構造のビット数ならびにその内容が伝送されてデコーダは該ビット数だけ飛び越えるかまたは、新たな要素をもつパスの伝送後に一義的な同期シーケンスを伝達して、既知のスキーマに属するツリーノードに到達して初めてデコーダがリスタートされることを特徴とする、
   ＸＭＬベースのコンテンツ記述のバイナリ表現機能を改善する方法。
2. ＸＭＬベースのコンテンツ記述のバイナリ表現機能を改善する方法において、
   インスタンス化されたＸＭＬドキュメントの構造はツリー状のデータ構造に対応し、各ツリーノードはコンテンツ記述の１つの要素を成し、スキーマ中に定義された構造を有しており、
   該スキーマは、ツリーブランチコード（ＴＢＣ）をもつツリーノードを有しており、
   前記ツリーブランチコードはスキーマブランチコードを有しており、
   デコーダは、これまでのスキーマに整合しない新たな要素をもつパスのデコーディングにあたり、事前に所属のツリー構造ノードまたは完全な１つのスキーマが伝達されることを特徴とする、
   ＸＭＬベースのコンテンツ記述のバイナリ表現機能を改善する方法。

Images