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

Abstract

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

Description

【０００１】
本発明は、たとえばＭＰＥＧ−７などのようにＸＭＬベースで構造化されたドキュメントのコーディングおよびデコーディングに関する。ＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）はドキュメント構造定義用の標準であり、構造化されたデータをテキストファイルで表示するために用いられ、たとえばＸＨＴＭＬのベースを成している。ＸＭＬベースで構造化されたこのようなドキュメントは以下ではスキーマとも称する多数の構造化要素に基づいており、それらはたとえばドキュメント型定義（ＤＴＤ）、ＸＭＬスキーマまたはマルチメディア記述スキーマ（ＤＳ）を用いて指定することができる。
【０００２】
ＩＳＯ／ＩＥＣ ＣＤ １５９３８−１ Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ の立案書 − Ｍｕｌｔｉｍｅｄｉａ Ｃｏｎｔｅｎｔ Ｄｅｓｃｒｉｐｔｉｏｎ Ｉｎｔｅｒｆａｃｅ： Ｓｙｓｔｅｍ， ＩＳＯ／ＩＥＣ ＪＴＣ １ ＳＣ２９／ＷＧ１１／Ｎ３７０１， Ｌａ Ｂａｕｌｅ （Ｆｒａｎｃｅ）， １０． ２０００の殊に第１５〜２２頁によって、ＭＰＥＧ−７データファイルのバイナリフォーマットおよびツリーブランチコードテーブルを用いたナビゲーションパスの構造が知られている。
【０００３】
本発明は、構造化されたＸＭＬドキュメントのコーディングの最適化に関する。そして本発明の基礎とする課題は、たとえばＭＰＥＧ−７ドキュメントなどのようなＸＭＬベースのコンテント記述のバイナリ表現機能を改善する方法において、伝送すべきデータ量をできるかぎり僅かにし、ドキュメント内のサーチプロセスをできるかぎり簡単にし、さらに個々のスキーマテンプレートに含まれていないインスタンス化されたドキュメントの拡張をできるかぎり僅かな手間で行えるようにすることである。
【０００４】
本発明によればこの課題は、請求項１，２，５，７に記載された特徴より解決される。その他の請求項には本発明による方法の有利な実施形態が示されている。
【０００５】
上述のＩＳＯ／ＩＥＣの立案書には殊に、ＸＭＬドキュメントの構造をデータツリーとして解釈できることが示されており、記述の各要素はこのツリーのノードに対応する。ノードの構造はドキュメントの基礎を成すスキーマ中の定義により規定される。これによりたとえば子要素の型および個数が定義される。この種のノードのプロトタイプは、たとえばこの立案書の第１９頁に記載されている。このようなツリー構造ノードは、要素または複合型の名前、子要素の参照に用いられる符号語ＴＢＣ（ツリーブランチコード Ｔｒｅｅ Ｂｒａｎｃｈ Ｃｏｄｅ）もつフィールド、ならびに対応する子要素への参照を成すツリーブランチから成る。さらにこの立案書には、ＴＢＣが２つのコンポーネントすなわちスキーマブランチとポジション情報とに分けられていることが示されており、その際、スキーマ情報はスキーマ中に子要素として現れる要素から導出される一方、ポジション情報は何度も現れる可能性のある要素に対するポジション情報を有している。ここで子要素の種類として考えられるのは、やはり子要素を含むことのできる形式である複合型 Ｃｏｍｐｌｅｘ Ｔｙｐｅの要素、あるいは子要素を含むことのできない形式である単純型 Ｓｉｍｐｌｅ Ｔｙｐｅ の要素もしくは属性である。フィールド＃ｐｏｓｔｉｏｎの長さは、スキーマ中で指定されている該当する要素の最大個数（”ｍａｘＯｃｃｕｒｓ”）によって規定される。たとえば最大数が７よりも大きいかまたは制限されていない場合には、コーディングすべきポジションを表すことができるまで、フィールドが適応的に伸ばされる。このような分割は、現時点のインスタンス化においていくつの子が存在するのかまたは存在することができるのかに左右されることなく、スキーマブランチコードまたはＳＢＣ ”ＳｃｈｅｍａＢｒａｎｃｈＣｏｄｅ が常に同じままという特性をもつ。
【０００６】
ドキュメント内で移動する目的で、ＴＢＣつまりスキーマブランチコード ＳｃｈｅｍａＢｒａｎｃｈＣｏｄｅおよび場合によってはポジションコードが並置され、これはドキュメント内のパスを表す。望ましい要素に辿りついたならば、最後のコードがテーブルに挿入される。望ましい要素がさらに別の子を持てないならば、つまり属性または単純型であるならば、このターミネーションコードは不要であり、送信されない。この場合には引き続き、属性または単純型の要素がコーディングされて伝送される。
【０００７】
次に、図面を参照しながら実施例に基づき本発明について詳しく説明する。
【０００８】
図１Ａ〜図１Ｄは、圧縮改善について説明するために様々な要素の型のアドレッシングの様子を示す図である。
【０００９】
図２はＸＭＬスキーマテキストを示す図である。
【００１０】
図２Ａおよび図２Ｂは、図２のスキーマテキストに属するノードテーブルを示す図である。
【００１１】
図３Ａおよび図３Ｂは、本発明によるサーチ方式の改善について説明する図である。
【００１２】
図４Ａおよび図４Ｂは、拡張性の改善について説明するためデータストリームの抜粋を示す図である。
【００１３】
図５Ａおよび図５Ｂは、拡張性の改善について説明するため拡張されたツリーブランチノードを示す図である。
【００１４】
図６Ａおよび図６Ｂは、図２および図２Ｂと同様であるが拡張された要素とともに示す図である。
【００１５】
図７および図８は、未知の要素を飛び越えるためのデコーダのためのシーケンスを示す図である。
【００１６】
本発明は基本的に以下のように構成されている。すなわち、２つの異なるスキーマブランチコードが用いられ、これら２つのコードのうち一方がかなり頻繁に利用され、したがって圧縮が働かされ、スキーマブランチコードとポジションコードがまとめられ、さらにスキーマブランチコードのためのビット長がいっしょに伝送される。この場合、参照される要素の型が第１の部分だけにより指定され、伝送すべきスキーマバージョン番号とデコーダにとって既知である固定的に定められた拡張ストラテジとに基づき、拡張性の改善が実現される。
【００１７】
圧縮の改善
図１Ａには単純型要素（ｓｉｍｐｌｅ ｔｙｐｅ ｅｌｅｍｅｎｔ）または属性の従来のアドレッシングが、図１Ｂには複合型要素（ｃｏｍｐｌｅｘ ｔｙｐｅ ｅｌｅｍｅｎｔ）の従来のアドレッシングが示されており、これは公知の方法に対応するものである。図１Ｃおよび図１Ｄには、本発明の方法による相応のアドレッシング方法が示されている。この図から明らかなように、それぞれ異なる２つのスキーマブランチコードＳＢＣ−ＡおよびＳＢＣ−Ｂが用いられており、共通のスキーマブランチコードＳＢＣ−Ｂだけではない。冒頭で述べたようにこの種のアドレスパスは連結されたＴＢＣコードから成り、つまり必要であるならば各スキーマブランチコードＳＢＣ−Ａの間にもポジションコード＃ｐｏｓが設けられており、終端においてのみパスターミネーションコードを伴うスキーマブランチコードが設けられ、これにはさらに別のポジション情報は伴わず、その後に共通のスキーマブランチコードＳＢＣ−Ｂが設けられ、これにはツリー構造のリーフを成す単純型または属性の要素も含まれている可能性がある。
【００１８】
連結されたＴＢＣコードから成る経路の既述の構造からわかるように、パスの最後のＴＢＣだけが属性または単純型要素を参照指示することができる。先行するすべてのＴＢＣは複合型要素を参照指示しなければならず、その理由はそれらだけが子要素をもつことができるからである。そこで本発明による方法の場合、ドキュメント内のポジショニング用コードの長さを冒頭で述べたＩＳＯ／ＩＥＣ立案書よりも低減することを目的として、各ノードごとにスキーマブランチコード＃ＳｃｈｅｍａＢｒａｎｃｈＣｏｄｅのための２つの異なるテーブルが導入される。テーブルＡには複合型の要素だけしか含まれておらず、つまり子要素のをもつことのできる要素だけしか含まれていない。他方のテーブルにはすべての要素が含まれており、つまり属性および単純型要素も含まれている。しかしここではパスターミネーション用のＳＢＣを予約する必要がない。これら両方のテーブルのスキーマブランチコードを以下ではＳＢＣ−ＡもしくはＳＢＣ−Ｂと称する。パス全体はやはりＴＢＣの連結によって形成され、その際、ＳＢＣ−Ａおよび場合によっては相応のポジションコード＃ｐｏｓｉｔｉｏｎ−ｃｏｄｅを伴う最後のＴＢＣを除いてすべてのＴＢＣが形成される。テーブルＡを用いて作成されたパスの最初の部分の終端は、ターミネーションコードたとえばすべてのビット１によって合図される。その後、テーブルＢから読み取られるスキーマブランチコード＃ＳｃｈｅｍａＢｒａｎｃｈＣｏｄｅをもつＴＢＣが必ず続く。ここで注意しなければならないことは、属性または単純型要素がアドレッシングされるときには本発明による方法においてもターミネーションコードを送信しなければならないことである。スキーマブランチコードの長さは可能な要素の個数に依存するので、テーブルＡ中のコードつまりコードＳＢＣ−Ａはそれに応じて短くなる。コードＳＢＣ−ＡがコードＳＢＣ−Ｂよりも相当頻繁に利用されることも、圧縮に好適な影響を及ぼす。
【００１９】
図２にはＸＭＬスキーマテキストの一例が描かれており、図２Ａおよび図２ＢにはＳＢＣ−ＡおよびＳＢＣ−Ｂのための対応するノードテーブルが示されている。この図から分かるように、ＳＢＣ−Ａについてはスキーマブランチコードを短くすることができる。それというのもここでは、単純型要素と属性を参照する必要がないからである。
【００２０】
サーチ機能の改善
バイナリ表現に必要とされるがＩＳＯ／ＩＥＣ立案書による方法によっては制約されていない機能は、ドキュメント内の所定の要素の簡略化されたサーチである。このサーチは簡単なフィルタメカニズムにより以下のようにして最適なかたちで実行することができ、これはドキュメント内のサーチされる要素を一義的にアドレッシングする事前に求められたビット列をビットストリーム内でパターン比較によりサーチすることによって行われる。ドキュメントツリーにおいて所定の要素を迅速にサーチするときにはビットストリームが構文解析され、適正なパスフラグメントについて言及された要素だけが詳細に考察される。ＩＳＯ／ＩＥＣ立案書に記載されている方法については、この種のフィルタリングは制約なしでは実行不可能である。その理由は、この場合のスキーマにおける少なくとも１つの要素の最大数が７よりも大きいかまたは制限されていないと、ポジションコード＃ＰｏｓｉｔｉｏｎＣｏｄｅの長さを事前に決めることはできないからである。
【００２１】
そこで本発明による方法の場合にはビットストリームの簡単なフィルタリングを目的として、パスを記述するツリーブランチノード（ＴＢＣ）の部分的な再ソートが行われる。その際、ポジションコードはパスの終端にずらされる。これにより得られる利点は、スキーマブランチフラグメント＃ＳｃｈｅｍａＢｒａｎｃｈＦｒａｇｍｅｎｔを含むパスの最初の部分は参照された要素の型だけしか指定しないことである。
【００２２】
択一的な解決手法によれば第１のステップにおいて、ポジションコード＃ＰｏｓｉｔｉｏｎＣｏｄｅが固定長の部分と可変長の部分とに分割される。第２のステップにおいて可変長の部分がＴＢＣから取り出され、パスの終端にずらされる。
【００２３】
これにより絶対アドレスの場合であれば、所定の要素のサーチのためにすでに事前にビットパターンを定めることができる。相対アドレスを使用した場合、パターンはドキュメント内の現在ポジションに依存する。この場合には新たな方法によって簡略化が行われ、フィルタリングのためにポジションコード＃ＰｏｓｉｔｉｏｎＣｏｄｅをデコーディングして評価する必要がなくなる。
【００２４】
完全な参照のためには完全なポジションコード＃ＰｏｓｉｔｉｏｎＣｏｄｅを含めてパス全体を読み出してデコーディングする必要があり、そのようにすればノードごとに参照された子要素に適正に分岐させることができる。
【００２５】
この方法のインプリメントを簡単にする目的でパスの最初に、ポジションコードを後置することなくパスの全長Ｌに関する情報を典型的にはビットで送信することができ、このようにすることでポジションコードに対するポインタＺもいっしょに送ることができ、したがってＳＢＣに対しパラレルに適正なポジションをデコーディングすることができる。このことにより付加的に、サーチされる要素に対する特定のポジション（＃ｐｏｓｉｔｉｏｎ）のサーチも実現され、パスの一部分が各デコーダにとって既知ではないような以下で説明する拡張性の事例に対してもサーチがサポートされる。
【００２６】
図３Ａには、従来の方法における単純型要素または属性のアドレッシングの一例としてこの関係が示されている。図３Ｂには、本発明による方法に関して同様のことが示されている。図３Ｂからわかるように、それぞれ１つのパスにおけるすべてのスキーマブランチコードＳＢＣ−Ｂ１〜ＳＢＣ−Ｂ５が相前後して配置されていて、これは全体として長さＬを有しており、この長さＬは開始直後に最初に伝送される。ポジションコード＃ｐｏｓ１〜＃ｐｏｓ５はＳＢＣから分離されており、相前後して配置されている。このスキーマパターン定義からビット長Ｌを有する絶対アドレッシングのためのビットパターンを求めることができ、したがってパターン比較によりビットストリームのフィルタリングが可能となる。
【００２７】
拡張性の改善
ＩＳＯ／ＩＥＣ立案書のアルゴリズムに基づくコーディングスキーマはコンテキスト依存型であり、つまり各要素ごとにコンテキストにより決められた別の可能性だけがコーディングされる。デコーダはスキーマ定義を知っているときのみ、ビットパターンを読み出して適正に解釈することができる。デコーダはどのＴＢＣコードがどの要素を参照指示するのか、各要素内のビットコードの長さはどれくらいかを知っていなければならず、その目的は各パスフラグメントごとに適正な数のビットが読み出されるようにするためである。
【００２８】
実践においては、新しい境界条件たとえば新しいメタデータカテゴリを考慮する目的で、定義済みのスキーマをあとから拡張する事態が頻繁に発生することになる。このような拡張をオプションの要素または属性とすることができる。古いスキーマ定義に従って作成されＸＭＬテキストフォーム中に保持されているドキュメントは、新しい定義に関しても引き続き有効である（上位互換）。しかしそれらを継承により導出されたデータ型としてもよく、制約の場合（ｄｒｉｖｅｄ ｂｙ ｒｅｓｔｒｉｃｔｉｏｎ）にはＴＢＣを保持し、あるいは拡張の場合（ｄｅｒｉｖｅｄ ｂｙ ｅｘｔｅｎｓｉｏｎ）には以下で説明するように、拡張されたＴＢＣテーブルを保持する。
【００２９】
しかしながらたとえばＩＳＯ／ＩＥＣ立案書に示されているようなドキュメントのバイナリ表現の場合、このことはあてはまらない。なぜならばそこでは新しい要素／属性は、事前に別の要素／属性をアドレッシングしたＴＢＣに割り当てられる可能性があるからである。本発明による方法であれば、この欠点を以下の規則によって回避することができる。
【００３０】
本発明による方法によれば新しいオプションの要素は、ツリー構造ノードＴＳＮ（Ｔｒｅｅ Ｓｔｒｕｃｔｕｒｅ Ｎｏｄｅ）において既存の後ろにのみ挿入することができ、かつ場合によっては存在するパスターミネーションコード Ｐａｔｈ Ｔｅｒｍｉｎａｔｉｏｎ Ｃｏｄｅ の前にのみ挿入することができる。ここで新しい要素にはこれまで利用されていなかったスキーマブランチコードＳＢＣが割り当てられ、その際に既存の要素はそのスキーマブランチコード割り当てを失わない。
【００３１】
拡張によって長くなったアドレスを用いたアドレッシングが行われることになるならば、コード長の変化に起因してすべてのバイナリ表現をもはやデコーディングできなくなってしまう。この問題を解決するため、本発明によれば以下のアドレッシングが取り入れられる。
【００３２】
新しい要素／属性は、スキーマブランチコードに関して既存の要素／属性の後ろおよびツリー構造ノードＴＳＮにおいて場合によっては存在するパスターミネーションの前にエントリされる。その際にスキーマブランチコードがもはや利用できなければ、アドレッシングが１つのビット分または複数のビット分だけたとえば最上位ビットの分だけ拡張される。既存のコードはたとえばゼロで拡張される。例外はパスターミネーションコードであって、これは１により拡張され、したがってツリー構造ノードの最後のノードはそのままである。その後、新しい要素／属性は新たに利用可能になったスキーマブランチコードＳＢＣに割り当てられる。スキーマブランチコードのビット長変化はデコーダに通知しなければならない。インクリメンタルな拡張性を実現する目的で、スキーマの先行のバージョンが既知でなければならない。このために個々のバージョンの完全な情報を記憶する必要はない。そうではなく相応に修正されたツリー構造ノードの新たなバージョンのスキーマブランチコードのビット数または個数だけを記憶し、必要に応じて伝送すればよく、その際、誤りのあるコードを識別できるようにするためには２つ目のやり方が有利である。この情報は、変更されたコーディング済みのスキーマブランチコードの前に伝送する必要がある。このようにしてスキーマブランチコードのビット長がスキーマのバージョン番号と結合される。あるドキュメントをバイナリコーディングする前、使用されるスキーマのバージョンだけを指定すればよく、従来のように使用されているすべてのスキーマを伝送しなくてもよい。たとえばＩＳＯ／ＩＥＣ立案書のビットストリーム定義をバージョン情報用のフィールド分だけ拡張することができる。バージョンコントロールが実行されない場合には、確実に既知である参照としてたとえばＭＰＥＧー７などのような標準におけるスキーマ定義が使用される。このスキーマ定義をたとえばバージョン１と決めることができる。この種のバージョン情報のための１つの実施例を以下に示す。
【００３３】
この実施例の場合にはＩＳＯ／ＩＥＣ立案書で指定されているようなストリームヘッダ中に、バージョン情報もビット長情報も付加的に格納される。この目的で図４に示されているような情報がデータストリーム中に格納される。
【００３４】
標準化されたバージョンには一義的なバージョン識別子を割り当てることができ、これは図４ＡではＭ７＿Ｖｅｒｓｉｏｎ＿ＩＤとして指定されている。さらに書九件の拡張を拡張識別子で表すことができ、これは図４ＡではＥＸｔｅｎｓｉｏｎ＿ＩＤと指定されている。拡張されたツリー構造ノードＴＳＮのビット長もビットストリーム中に格納することができる。これは図４Ａに示されているように、フラグＤＳ＿Ｅｘｔｅｎｓｉｏｎによって通知される。拡張されたツリー構造ノードＴＳＮのツリーブランチコードＴＢＣのビット長情報は、図４Ａに示されているＤＳ＿Ｕｐｄａｔｅ＿Ｉｎｆｏ（）において図４Ｂに示されているようにコーディングされる。Ｎｕｍｂｅｒ＿ｏｆ＿ｃｈａｎｇｅｄ＿ｎｏｄｅｓという記号によって変更されたツリー構造ノードの個数が通報される。この個数は、ＩＳＯ／ＩＥＣ立案書で提案されているポジション情報に従い可変長でコーディングすることができる。
【００３５】
変更されたツリー構造ノードの情報はビットストリームにおいて、ナビゲーション命令Ｎａｖｉｇａｔｉｏｎ＿ＣｏｍｍａｎｄおよびナビゲーションパスＮａｖｉｇａｔｉｏｎ＿Ｐａｔｈ（）によってアドレッシングすることができる。その場合、アドレッシングされたノードと同じ型であるあとで伝送されるすべての要素に適用される。以下では、変更された符号語長ＳＢＣ＿Ｌｅｎｇｔｈまたはスキーマブランチコードの変更された個数はデータストリームに挿入される。符号語長または個数はやはり、Ｎｕｍｂｅｒ＿ｏｆ＿ｃｈａｎｇｅｄ＿ｎｏｄｅｓのコーディングにも使用される方法に従いコーディングされる。
【００３６】
別の実施例の場合、変更されたツリー構造ノードは、スキーマにおいて複合型のダイレクトなアドレッシングにより識別することができる。このダイレクトなアドレッシングはたとえば、スキーマ中に定義された複合型のカウントにより達成することができる。
【００３７】
さらに別の問題として挙げられるのは、新しいスキーマに従いコーディングされたドキュメントが先行のスキーマ定義だけしか知らないデコーダによってデコーディングされることである（下位互換）。ＸＭＬベースのテキストのＸＭＬドキュメントの場合、このことは古いスキーマ中ですでに既知であった要素については可能である。これは２つの特性に基づいている。
【００３８】
−古いスキーマ中で定義されていた複合型の要素はそのまま保持されているが、含まれている要素や属性もしくはデータ型については異なっている可能性がある。
【００３９】
−要素の開始マークおよび終了マークいわゆるタグにより新しい要素を飛び越えることができ、既知の要素をデコーディングすることができる。
【００４０】
先行のアドレッシングのやり方に従い上記の例で示したように様々なバージョンのツリー構造ノードのビット長が伝送される場合、拡張されたツリー構造ノードの既知の要素は、まだ先行のスキーマに基づき動作している「古い」デコーダによって処理することができる。ただし新しい要素に至るパス識別子はこの「古い」デコーダによって飛び越えることができず、デコーダはもはやデコーディングを続けることができなくなる。この重要な機能をサポートする目的で本発明による方法の場合には下位互換のコーディング済みドキュメントに対し以下の代案が適用される。
【００４１】
ａ）ＴＳＮ中の新しい要素／属性がアドレッシングされると、その要素／属性のための完全なサブツリーまたは後続ツリーに関するビットの個数が、挿入されたＮビットの内容データも含めてまえもって付加的に伝送される。このようにしてデコーダは自身にとって既知でないやり方でコーディングされた次のＮビットを飛び越えて、既知のＴＳＮのところから再開することができる。
【００４２】
ｂ）新しい要素／属性を含むパスの伝送後、一義的な同期シーケンスが伝達され、デコーダはこの同期シーケンスを既知のＴＳＮのところから再開するのに利用できる。
【００４３】
ｃ）新しい要素を含むパスを伝達するとき、完全なスキーマの一部分を成すそのパスのＴＳＮを事前に伝送する必要がある。
【００４４】
ｄ）新しい要素を含むパスを伝達するとき、完全なスキーマをまえもって伝送する必要がある。
【００４５】
代案ｃ）およびｄ）の場合、デコーダは新たに追加されたドキュメントの内容もデコーディングすることができ、必要に応じてこれを記憶するかまたは後続処理することができる。
【００４６】
図５ａおよび図５ｂに示されている例はスキーマ定義の新しいバージョンにおける変更を表しており、図５ａには複合型要素の拡張されたツリー構造ノードが、図５ｂには変形されたスキーマにおける拡張されたツリー構造ノードが描かれている。要素３〜６は新しいバージョンに付け加えられている。スキーマブランチコードの長さはこれにより２から３に伸ばされている。しかしこれまでのアドレスは、ＭＳＢとしてゼロだけ拡張されたことを除いてそのまま維持される。
【００４７】
次に、拡張されたスキーマ要素のコーディングに関する一例を図６Ａおよび図６Ｂに示す。ここでは出発点として、図２との関連で使われた例を用いる。わかりやすくするためこの図面では、ノードテーブルを分割する上述の方法は省略する。また、もとのスキーマ ”ＰｕｒｃｈａｓｅＯｒｄｅｒＴｙｐｅ” をいくつかの要素だけ拡張することにする。図６Ａ中、図２とは異なる拡張は太字で示されている。
【００４８】
つまりここでは要素 ”ｂｉｌｌＴｏ”， ”ＭｅｔｈｏｄＯｆＰａｙｍｅｎｔ”， ”ＢａｎｋＤａｔａ” が新たに挿入される。したがって新しいツリーブランチコードテーブルをこれに応じて拡張する必要がある。このためすべての可能性をコーディングするには３つのビットでは不十分である。図６ｂを参照しながら、４つのビットを用いたツリーブランチコードのこのような拡張について詳しく説明する。
【００４９】
さて、大枠となるこのような条件のもとで２つの事例を扱う。
【００５０】
事例１：
古いスキーマ定義に従ってコーディングされたドキュメントが、新しいスキーマを知っているデコーダに伝送される。コーディング済みのドキュメントの基礎を成すバージョン番号を最初にデコーダに伝達しなければならない。この目的でデコーダは、各バージョン番号ごとにすべての要素に対しスキーマブランチコードＳＢＣのビット幅または個数の格納されているテーブルをもっている。これによりデコーダにおいて、”ＰｒｕｃｈａｓｅＯｒｄｅｒＴｙｐｅ” 型の要素は４つのビットではなく３つのビットだけでコーディングされていることが確認される。この情報を用いるだけでドキュメントを適正にデコーディングすることができる。
【００５１】
事例２：
古いスキーマ定義に従ってコーディングされたドキュメントが、古いスキーマだけしか知らないデコーダに伝送される。デコーダはスキーマのバージョン番号に基づき、未知の要素が伝送される可能性があること、未知の要素は異なるビット幅でコーディングされている可能性のあることを識別する。要素の新たなビット幅をデコーダは知っていなければならず、その理由はさもないとエンコーダとの同期を失ってしまうからである。この場合、個々の要素をビット幅に対応づける情報たとえばテーブルが本来のドキュメントの前に伝送されるかまたは、デコーダは指定されたアドレス（ＵＲＩ）のところでこの情報をアクセスすることができる。
【００５２】
本発明の方法によればエンコーダは、ドキュメントのコーディングに関して４つの可能なオプションをもっている。
【００５３】
オプション１：
新しい要素ごとに、図７に示されているような下位の適切なサブツリーの長さが伝送される。デコーダはスキーマブランチコード０１０１に基づき、標準スキーマ中に含まれていない要素がアドレッシングされていることを識別する。これに応じてデコーダは次のビットを未知の要素の長さＬと解釈する。この長さ情報は、ＩＳＯ／ＩＥＣドラフトに示されているような適応的な可変の整数コーディングに従って行うことができる。この長さ情報を用いてデコーダは下位のサブツリー ”ｂｉｌｌＴｏ”を飛び越え、＃ＳｃｈｅｍａＢｒａｎｃｈ−Ｃｏｄｅ ００１０ のところから再開する。そして次の要素 ”ｃｏｍｍｅｎｔ” から再びデコーディングすることができる。
【００５４】
オプション２：
図８に示されているように、新しい要素の後で一義的な同期シーケンスが伝達される。デコーダは、規範的に定められた再同期マーカを見つけるまでビットストリームを構文解析し、その後、再びデコーディングを継続する。この方法の場合には複数の新しい要素をひとまとまりでコーディングすることができ、最後の要素の後にはじめて再同期マークを伝送することができる。
【００５５】
オプション３：
新しい要素を含むツリー構造ノードならびにドキュメントツリー中のそれらのポジションが、本来のドキュメントの前に伝送される。したがってこの手法の場合、デコーダにとって既知であるスキーマが更新される。このためドキュメントの伝送は、スキーマが既知である状況に応じて行われる。しかも新しいスキーマを識別する一義的なバージョン番号が割り当てられるならば、デコーダは新たに伝送されたスキーマをそれらの新しい要素に関して既知の要素を拡張するために用いることができる。
【００５６】
オプション４：
１つの完全な新しいスキーマが伝送される。この場合、デコーダはドキュメントを、それが既知のスキーマに従ってコーディングされたように取り扱うことができる。しかも新しいスキーマを識別する一義的なバージョン番号が割り当てられるならば、デコーダは新たに伝送されたスキーマをそれらの新しい要素に関して既知の要素を拡張するために用いることができる。
【００５７】
なお、本発明による個々の方法をそれ自体単独でまたは組み合わせて実施することができる。
【図面の簡単な説明】
【図１】
図１Ａ〜図１Ｄは、圧縮改善について説明するために様々な要素の型のアドレッシングの様子を示す図である。
【図２】
図２はＸＭＬスキーマテキストを示す図である。
【図２Ａ】
図２のスキーマテキストに属するノードテーブルを示す図である。
【図２Ｂ】
図２のスキーマテキストに属するノードテーブルを示す図である。
【図３Ａ】
本発明によるサーチ方式の改善について説明する図である。
【図３Ｂ】
本発明によるサーチ方式の改善について説明する図である。
【図４Ａ】
拡張性の改善について説明するためデータストリームの抜粋を示す図である。
【図４Ｂ】
拡張性の改善について説明するためデータストリームの抜粋を示す図である。
【図５Ａ】
拡張性の改善について説明するため拡張されたツリーブランチノードを示す図である。
【図５Ｂ】
拡張性の改善について説明するため拡張されたツリーブランチノードを示す図である。
【図６Ａ】
図２および図２Ｂと同様であるが拡張された要素とともに示す図である。
【図６Ｂ】
図２および図２Ｂと同様であるが拡張された要素とともに示す図である。
【図７】
未知の要素を飛び越えるためのデコーダのためのシーケンスを示す図である。
【図８】
未知の要素を飛び越えるためのデコーダのためのシーケンスを示す図である。

Claims (8)

1. ＸＭＬベースのコンテンツ記述のバイナリ表現機能を改善する方法において、
   インスタンス化されたＸＭＬドキュメントの構造はツリー状のデータ構造に対応し、各ツリーノードはコンテンツ記述の１つの要素を成し、スキーマ中に定義された構造を有しており、
   該スキーマは、ツリーブランチコード（ＴＢＣ）をもつツリーノードを有しており、
   前記ツリーブランチコードはスキーマブランチコードを有しており、スキーマの定義に従い所属の子ノードが何度も現れる場合にはポジションコード（＃ＰＯＳ）も有しており、
   コーディングにあたり各ノードごとにスキーマブランチコードのための２つの異なるテーブルが形成され、
   第１のテーブル（ＳＢＣ−Ａ）はもっぱら複合型要素とパスターミネーションコードだけを含み、該テーブルのデータ構造により子ノードへの分岐が許可され、第２のテーブル（ＳＢＣ−Ｂ）は複合型要素のほかにも属性および単純型要素を含み、該要素はツリー状データ構造のリーフを成し、
   個々のパス全体は、１つのパス全体の最終ノードを除いて前記第１のテーブルからのツリーノードだけが用いられるよう、ツリーノードのチェーンにより形成され、最終ツリーノードが第２のテーブルから取り出され、該パスの最後から２番目のノードはパスターミネーションコードを含むことを特徴とする、
   ＸＭＬベースのコンテンツ記述のバイナリ表現機能を改善する方法。
2. ＸＭＬベースのコンテンツ記述のバイナリ表現機能を改善する方法において、
   インスタンス化されたＸＭＬドキュメントの構造はツリー状のデータ構造に対応し、各ツリーノードはコンテンツ記述の１つの要素を成し、スキーマ中に定義された構造を有しており、
   該スキーマは、ツリーブランチコード（ＴＢＣ）をもつツリーノードを有しており、
   前記ツリーブランチコードはスキーマブランチコードを有しており、スキーマの定義に従い所属の子ノードが何度も現れる場合にはポジションコード（＃ＰＯＳ）も有しており、
   １つのパス全体は、すべてのポジションコードが該パスの終端にずらされるようソートしなおされることを特徴とする、
   ＸＭＬベースのコンテンツ記述のバイナリ表現機能を改善する方法。
3. パス全体の最初にパスの全長（Ｌ）に関する情報が送信され、スキーマブランチコードだけが捕捉され、ポジションコードは捕捉されない、請求項２記載の方法。
4. ポジションコードが固定長部分と可変長部分とに分割され、該可変長部分はツリーブランチコードから取り出され、パスの終端にずらされる、請求項２記載の方法。
5. ＸＭＬベースのコンテンツ記述のバイナリ表現機能を改善する方法において、
   インスタンス化されたＸＭＬドキュメントの構造はツリー状のデータ構造に対応し、各ツリーノードはコンテンツ記述の１つの要素を成し、スキーマ中に定義された構造を有しており、
   該スキーマは、ツリーブランチコード（ＴＢＣ）をもつツリーノードを有しており、
   前記ツリーブランチコードはスキーマブランチコードを有しており、
   既存のスキーマの拡張は、すべてが使用されるまで１つのツリーノードにおいて未使用のスキーマブランチコードが新たな要素による拡張に使われることにより行われ、その後、必要に応じてスキーマブランチコードのビット長（Ｂ）が高められ、コンテンツ記述の適正なデコーディングのためビット長の変更がデコーダに通知されることを特徴とする、
   ＸＭＬベースのコンテンツ記述のバイナリ表現機能を改善する方法。
6. 少なくとも１つのスキーマバージョンがデコーダに記憶され、記憶されているバージョンに対し相対的なスキーマ変更の呼び出し用情報だけが送信されるかまたは、記憶されているバージョンに対し相対的なスキーマ変更がそのまま送信される、請求項５記載の方法。
7. ＸＭＬベースのコンテンツ記述のバイナリ表現機能を改善する方法において、
   インスタンス化されたＸＭＬドキュメントの構造はツリー状のデータ構造に対応し、各ツリーノードはコンテンツ記述の１つの要素を成し、スキーマ中に定義された構造を有しており、
   該スキーマは、ツリーブランチコード（ＴＢＣ）をもつツリーノードを有しており、
   前記ツリーブランチコードはスキーマブランチコードを有しており、
   デコーダは未知の要素をもつパスを読み飛ばし、個々の要素の後ろに位置するツリー構造のビット数ならびにその内容が伝送されてデコーダは該ビット数だけ飛び越えるかまたは、新たな要素をもつパスの伝送後に一義的な同期シーケンスを伝達して、既知のスキーマに属するツリーノードに到達して初めてデコーダがリスタートされることを特徴とする、
   ＸＭＬベースのコンテンツ記述のバイナリ表現機能を改善する方法。
8. ＸＭＬベースのコンテンツ記述のバイナリ表現機能を改善する方法において、
   インスタンス化されたＸＭＬドキュメントの構造はツリー状のデータ構造に対応し、各ツリーノードはコンテンツ記述の１つの要素を成し、スキーマ中に定義された構造を有しており、
   該スキーマは、ツリーブランチコード（ＴＢＣ）をもつツリーノードを有しており、
   前記ツリーブランチコードはスキーマブランチコードを有しており、
   デコーダは、これまでのスキーマに整合しない新たな要素をもつパスのデコーディングにあたり、事前に所属のツリー構造ノードまたは完全な１つのスキーマが伝達されることを特徴とする、
   ＸＭＬベースのコンテンツ記述のバイナリ表現機能を改善する方法。

Images