JP2004510279A

JP2004510279A - 文書の送受信方法、ｘｍｌ符号化方法及びその装置、並びにｘｍｌ復号方法

Info

Publication number: JP2004510279A
Application number: JP2002533104A
Authority: JP
Inventors: ワン，　アーネスト，　イュー，　チャン
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2000-10-06
Filing date: 2001-10-05
Publication date: 2004-04-02
Anticipated expiration: 2021-10-05
Also published as: JP4574114B2; KR100566019B1; US7647552B2; AUPR063400A0; DE60129232D1; EP1323064A1; CN1455901A; CN1244062C; DE60129232T2; WO2002029602A1; ATE366441T1; EP1323064B1; US20040028049A1; EP1323064A4; KR20030061819A

Abstract

階層表現（１０２）により記述される文書（１０４）の構造の少なくとも一部を送受信する方法（９００）が開示される。方法は、文書（１０４）の階層表現（ツリー構造など）を識別する（９０２）。識別はＸＭＬタグを使用して実行されるのが好ましい。表現は複数のデータパケットへとパケット化される（９０６）。少なくとも１つのリンクが１対のパケット間に作成される（９０８）。このリンクは、表現の対応するコンポーネント（構造及び内容など）間の相互接続を表すように機能する。パケットから送受信用のストリームが形成される（９１０）。リンクはパケット内の階層表現を維持する。

Description

【０００１】
【発明の属する技術分野】
本発明は、ＸＭＬ（ＥｘｔｅｎｓｉｂｌｅＭａｒｋｕｐＬａｎｇｕａｇｅ）文書の符号化に関し、特に、ＸＭＬ文書の圧縮、ストリーミング、探索、及び動的構築のうちの少なくとも１つに関する。
【０００２】
【背景】
ＭＰＥＧ−７記述のストリーミング、ダウンロード、及び格納をより効率的にするために、記述を符号化・圧縮することができる。ＭＰＥＧ−７記述の配信に関する多くの問題の分析は、２進符号化に使用される形式の考察を伴うものであった。ＷＡＰ（ｔｈｅＷｉｒｅｌｅｓｓＡｐｐｌｉｃａｔｉｏｎＰｒｏｔｏｃｏｌＦｏｒｕｍ）からのＷＢＸＭＬ提案、Ｍｉｌｌａｕアルゴリズム、及びＸＭｉｌｌアルゴリズムなどのＸＭＬに対する既存の符号化方式がそれぞれ考慮されてきた。
【０００３】
ＷＢＸＭＬに関して説明すると、頻繁に使用されるＸＭＬタグ、属性、及び値には大域コード空間からの固定のコード集合が割り当てられる。文書インスタンスを通して繰り返されるアプリケーション固有のタグ名、属性名、及び一部の属性値には一部の局所コード空間からのコードが割り当てられる。ＷＢＸＭＬはＸＭＬ文書の構造を維持する。内容のみならず文書型定義（ＤＴＤ）で定義されていない属性値もインライン方式で格納、あるいは、ストリングテーブルに格納することが可能である。文書のコード空間のテーブルは特定の種類のアプリケーションにとって既知であるか、あるいは、文書と共に送信されることが期待されている。
【０００４】
ＷＢＸＭＬがタグ及び属性をトークン化する間、テキスト内容は圧縮されない。ＷＡＰで使用されるために提案されたものであり且つＷＢＸＭＬの設計の対象である無線用マーク付け言語（ＷＭＬ）文書の場合、通常、テキスト内容が制限されているので圧縮がなくても十分であろうが、ＷＢＸＭＬは通常のテキスト記載のＸＭＬ文書にとってあまり効率の良い符号化形式とは考えられていない。Ｍｉｌｌａｕアプローチは、従来のテキスト圧縮アルゴリズムを使用してテキストを圧縮することによってＷＢＸＭＬ符号化形式を拡張する。また、Ｍｉｌｌａｕはスキーマ及びデータ型を利用することで基本データ型の属性値の圧縮の改善を可能にする。
【０００５】
Ｘｍｉｌｌアルゴリズムの作者は更に複雑な符号化方式を提示しているが、これはＷＢＸＭＬに基づいていない。組込みデータ型の値を符号化するためのＤＴＤ及びスキーマにおける型情報を符号化・使用する構造とテキストとを分離することの他に、この方式は：
（ｉ）同じ型又は関連する型の要素を複数のコンテナへとグループ分けし（冗長度を高めるため）、
（ｉｉ）異なる圧縮プログラムを使用して各コンテナを別々に圧縮し、
（ｉｉｉ）原始的な圧縮プログラムをより複雑な圧縮プログラムへと結合できるようにし、
（ｉｖ）非常に専門的なデータ型に対して新規の専門の圧縮プログラムを使用できるようにした。
【０００６】
しかし、既存の符号化方式は圧縮のみを目的として設計されている。ＸＭＬ文書のストリーミングには対応していない。また、依然としてＸＰａｔｈ／ＸＰｏｉｎｔｅｒアドレッシング方式を使用して要素を効率的に配置することができず、文書の構築中に、これを徐々に符号化することもできない。
【０００７】
【発明の概要】
本開示の一面によると、階層表現により記述される文書の構造の少なくとも一部を送受信する方法であって、
前記文書の前記表現を識別するステップと、
前記表現を所定のサイズを有する複数のデータパケットへとパケット化するステップであって、１対の前記パケット間に前記表現の対応するコンポーネント間の相互接続を表す少なくとも１つのリンクを作成することを含むステップと、
前記データパケットから送受信用のストリームを形成するステップとを含み、前記リンクは前記パケット内の前記表現を維持する方法が提供される。
【０００８】
本開示の別の一面によると、階層表現により記述される文書の構造の少なくとも一部を送受信する方法であって、
前記表現の少なくとも１つの部分を識別し、前記部分を所定サイズの少なくとも１つのパケットへとパケット化するステップを含み、前記表現の１つ以上の前記部分が１つの前記パケットに収まらない場合、前記１つのパケットから前記収まらない部分がパケット化されて形成される少なくとも１つの更なる前記パケットまでの少なくとも１つのリンクを定義し、前記リンクは前記パケット中の前記文書の階層構造を維持することを特徴とする方法が提供される。
【０００９】
本開示の別の一面によると、ＸＭＬ文書の構造へのアクセスを容易にする方法であって、
前記文書の階層表現を識別するステップと、
前記表現を所定パケットサイズの複数のパケットへとパケット化するステップと、
前記パケット間にリンクを形成してパケット内で表現できない前記表現の部分を定義し、それにより、パケット化解除後の前記表現の再現を可能にするステップと、
を含むことを特徴とする方法が提供される。
【００１０】
ここで開示される符号化／復号化方式は、構造符号化とテキスト符号化を分離し、組込みデータ型の値を符号化するためのスキーマ及びデータ型を使用する。加えて、本開示はストリーミングをサポートし、ＸＰａｔｈ／ＸＰｏｉｎｔｅｒのようなアドレッシングメカニズムを使用する効率的な探索を可能にする。また、これにより、ＸＭＬ文書は構築中に符号化／ストリーミングできるようになる。これらの特徴は、同報通信及びモバイルアプリケーションにとっては重要である。ここで開示される符号化／復号化方式は、更に複数の名前空間をサポートし、ビットストリームのＥＢＮＦ定義及び拡張可能エンコーダを構築するためのインタフェースの集合を提供する。
【００１１】
【詳細な説明】
図１から図７、図９、及び図１０を参照して説明するＸＭＬ文書を符号化／復号化する方法は、図８に示すような汎用コンピュータシステム８００を使用して実施されるのが好ましい。図１から図７のプロセスは、コンピュータシステム８００内で実行されるアプリケーションプログラムなどのソフトウェアとして実現されても良い。特に、この方法の各ステップは、コンピュータにより実行されるソフトウェア中の命令により実施される。ソフトウェアは、復号化／復号化方法を実行する１つの部分と、この符号化／復号化方法とユーザとの間のユーザインタフェースを管理する別の部分との２つの別々の部分に分割されても良い。ソフトウェアは、例えば、以下に記述するような記憶装置を含むコンピュータ可読な媒体に格納されても良い。ソフトウェアは、コンピュータ可読な媒体からコンピュータへとロードされ、コンピュータにより実行される。このようなソフトウェア又はコンピュータプログラムを記録したコンピュータ可読な媒体は、コンピュータプログラム製品である。コンピュータにおいてコンピュータプログラム製品を使用することにより、ＸＭＬ文書を符号化／復号化するための有利な装置を実現するのが好ましい。
【００１２】
コンピュータシステム８００は、コンピュータモジュール８０１、キーボード８０２及びマウス８０３などの入力装置、並びにプリンタ８１５及び表示装置８１４を含む出力装置を含む。変復調（モデム）送受信装置８１６は、コンピュータモジュール８０１が、例えば、電話回線８２１又はその他の機能媒体を介して接続可能な通信ネットワーク８２０と通信を行なうのに使用される。モデム８１６は、インターネット及び構内通信網（ＬＡＮ）又は広域通信網（ＷＡＮ）などのその他のネットワークシステムへのアクセス権を取得するのに使用することができる。図示するように、サーバコンピュータシステム８５０はネットワーク８２０へと接続し、コンピュータシステム８００と通信を行なうことができる。サーバコンピュータシステム８５０は、通常、コンピュータシステム８００と同様の構造を有し、及び／又は、コンピュータシステム８００と同様にあるいはこれに対して相補的に動作可能である。例えば、コンピュータシステム８００がＸＭＬ符号化関数を実行し、サーバコンピュータ８５０が相補的なＸＭＬ復号化関数を実行しても良い。また、その逆であっても良い。
【００１３】
コンピュータモジュール８０１は、通常、少なくとも１つのプロセッサユニット８０５、例えば、半導体ランダムアクセスメモリ（ＲＡＭ）及び読出し専用メモリ（ＲＯＭ）から形成されるメモリユニット８０６、ビデオインタフェース８０７とキーボード８０２、マウス８０３、及びオプションとしてのジョイスティック（不図示）用のＩ／Ｏインタフェース８１３とを含む入出力（Ｉ／Ｏ）インタフェース、並びにモデム８１６用のインタフェース８０８を含む。記憶装置８０９が設けられるが、この記憶装置８０９は、通常、ハードディスクドライブ８１０及びフロッピーディスクドライブ８１１を含む。磁気テープドライブ（不図示）を使用しても良い。ＣＤ−ＲＯＭドライブ８１２は、通常、不揮発性のデータソースとして設けられる。コンピュータモジュール８０１の構成要素８０５から８１３は、通常、相互接続バス８０４を介して、コンピュータシステム８００の動作モードが、当業者には既知の従来の動作モードになるように通信を行なう。上述の構成を実施可能なコンピュータの例としては、ＩＢＭ−ＰＣ及びその互換機、ＳｕｎＳｐａｒｃｓｔａｔｉｏｎ、又はそれを進化させた同様のコンピュータシステムがある。
【００１４】
通常、アプリケーションプログラムはハードディスクドライブ８１０に常駐し、プロセッサ８０５による実行の際に読み出されて制御される。プログラムとコンピュータネットワーク８２０から取り込まれるデータとの中間記憶装置は、半導体メモリ８０６を使用し、場合によってはハードディスクドライブ８１０と協働させるように使用して達成されても良い。アプリケーションプログラムは、ＣＤ−ＲＯＭ又はフロッピーディスク上に符号化された形でユーザに供給され、対応するドライブ８１２又は８１１を介して読み取られる場合もあれば、ネットワーク８２０からモデム装置８１６を介してユーザが読み取る場合もある。更に、このソフトウェアは、磁気テープ、ＲＯＭ又は集積回路、光磁気ディスク、コンピュータモジュール８０１と別の装置との間の無線又は赤外線の伝送チャネル、ＰＣＭＣＩＡカードなどのコンピュータ可読なカード、並びに電子メール送受信及びウェブサイトなどに記録された情報などを含むインターネット又はイントラネットを含む他のコンピュータ可読な媒体からコンピュータシステム８００へとロードすることもできる。以上の例は、関連するコンピュータ可読な媒体の単なる例示であり、その他のコンピュータ可読な媒体を代わりに使用しても良い。
【００１５】
動作中、状況に応じて、ＸＭＬ文書符号化／復号化関数がサーバコンピュータ８５０及びコンピュータシステム８００のうちの一方で実行され、それにより形成されたパケット化ビットストリームがそれぞれコンピュータシステム８００又はサーバコンピュータ８５０により受信・復号化されるように通信ネットワーク８２０を介して伝送される。このように、受信の際に最初に文書全体を受信することなく、受信側が最適な時間で高速に文書を復号化できるようにしながら、ＸＭＬ文書を２つの地点間で便利且つ効率的に送受信しても良い。
【００１６】
符号化／復号化の方法は、符号化及び／又は復号化の関数又は下位関数を実行する１つ以上の集積回路などの専用のハードウェアでその一部又は全部が実現されても良い。このような専用のハードウェアは、グラフィックプロセッサ、デジタル信号プロセッサ、又は１つ以上のマイクロプロセッサ及び関連メモリを含んでも良い。
【００１７】
＜ＸＭＬの符号化及び圧縮＞
（構造とテキストとの分離）
従来より、ＸＭＬ文書は生のテキスト形式で格納・伝送されることが多い。一部のアプリケーションでは、ＸＭＬ文書は、格納又は伝送のための従来のテキスト圧縮アルゴリズムを使用して圧縮され、構文解析・処理を受ける前にＸＭＬへと復元される。
【００１８】
本開示によると、ＸＭＬ文書を符号化する別の方法は、文書のツリー階層（文書のＤＯＭ表現など）を符号化することである。符号化は幅優先方式又は深さ優先方式で実行されても良い。圧縮及び復号化をより効率的に行なうために、ＸＭＬ文書内のタグにより示されるＸＭＬ構造をＸＭＬ文書のテキストから分離し、これを符号化することができる。符号化された文書を伝送するとき、構造及びテキストを別々のストリームで送信することも、あるいは、単一のストリームへと連結することもできる。
【００１９】
図１に示すように本実施形態によると、通常、メモリから利用可能であるＸＭＬ文書１０４のツリー表現１０２は、複数のノード１１６を含み、深さ優先方式で符号化される。文書１０４及びその中に含まれるテキストの構造は、図１に示すように２つの別個のストリーム１０６及び１０８として符号化することも、あるいは、単一のストリームへと連結することもできる。構造ストリーム１０６の先頭にはコードテーブル１１０及び１１４がある。ツリー１０２の復号化されたノード１１８は、ノードのサイズを示すと共に子孫ノードの合計サイズを含むサイズフィールド（不図示）をそれぞれ有する。復号化された葉ノード１１８の一部は、これらの葉ノードをテキストストリーム１０８中の対応する内容へとリンクするリンク１１２を含む。テキストストリーム１０８中の各符号化されたストリングの先頭には、ストリングのサイズを示すサイズフィールド（不図示）がある。単一のストリームへと連結される場合、リンク１１２のルートを含むパケットが、リンク１１２により指し示されるテキストを含むパケットよりも先行すべきである。これにより、デコーダは対応するテキスト（内容）コンポーネントより前に文書１０４の構造コンポーネントを確実に受信することができる。
【００２０】
図１に示すアプローチは、コンピュータシステム８００上で実行されるソフトウェアプログラムとして実現されても良い符号化方法９００のフローチャートとして図９にも示される。方法９００は、階層表現により記述される文書の構造の少なくとも一部を送受信し、ステップ９０２からスタートする。最初にステップ９０４において、方法９００は文書１０４の階層表現（ツリー構造など）を識別する。識別は上述のようにＸＭＬタグを使用して実行されるのが好ましい。ステップ９０６において、表現は複数のデータパケットへとパケット化される。ステップ９０８において、パケットのうちの１対にまたがる少なくとも１本のリンクが作成される。このリンクは、表現の対応するコンポーネント（構造及び内容など）間の相互接続を表すように機能する。ステップ９１０において、パケットから送受信用のストリームが形成される。リンクはパケット内の階層表現を維持する。方法９００はステップ９１２において終了する。
【００２１】
一般的に、構造情報のボリュームはテキスト内容よりも格段に小さい。通常、構造はネストされ、文書インスタンス内で繰り返される。テキストから構造を分離することにより、反復パターンは圧縮アルゴリズムにより容易に識別されるようになる。圧縮アルゴリズムは、通常、固定サイズのウィンドウを介して入力ストリームを検査する。加えて、構造ストリームとテキストストリームとはかなり異なる特徴を有する。このため、構造及びテキストの各々に対しては、異なるより効率的な符号化方法が適用されても良い。
【００２２】
テキストを解釈するための文脈を提供する上で構造は重要である。エンコーダにおいて構造とテキストとを分離することにより、対応するデコーダは文書の構造をより迅速に解析することができるので、知らない又は必要でない要素（及び子孫）は無視されると共に関連する要素のみが処理される。デコーダは、更に、無関係の要素と関連付けられたテキストをバッファリングしないことを選択しても良い。デコーダが符号化された文書を元のＸＭＬへと変換するか否かは、実行される特定のアプリケーション（アプリケーションプログラムインタフェース−ＡＰＩについての以下の記述を参照）によって決まる。
【００２３】
（コードテーブル）
文書記述の要素及びその属性はＤＴＤ又はスキーマにおいて定義される。通常、要素の集合及びその関連する属性は文書インスタンスにおいて繰り返し使用される。要素名並びに属性名及び属性値には、符号化に必要なバイト数を削減するためにコードが割り当てられる。
【００２４】
通常、各アプリケーションドメインは、複数のスキーマ及び／又はＤＴＤ中で定義される別々の要素／型の集合を使用する。加えて、各スキーマ又はＤＴＤは別々の名前空間に対する定義を有しても良い。一部の要素／型が複数の種類のアプリケーションに共通な場合でも、これらの要素／型は、通常、異なるパターンにおいて使用される。具体的には、ドメインＡ及びＢの双方に共通の要素Ｘは、ドメインＡでは頻繁に使用されるが、ドメインＢでは稀にしか使用されないかもしれない。加えて、常時、既存のスキーマが更新されると共に新規のスキーマが作成される。このため、コード割当てをドメインにおける相互運用性を監視する機構に委ねるのが最も好ましい。例えば、ＭＰＥＧ−７記述はＸＭＬ文書である。ＭＰＥＧは、それ自体の記述子及び記述スキーマに対するコード空間に加えて、外部の要素及びそれが使用する型を定義しても良い。また、ＭＰＥＧはコード空間を生成する方法を定義しても良い。理想的には、この方法は、エントロピーベースである−すなわち、記述又は記述のクラスにおける記述子及び記述スキーマの出現回数に基づくべきである（コード空間の生成の節を参照）。
【００２５】
（要素と属性との分離）
ＸＭＬタグは、通常、要素名及び属性名／属性値対の集合を含む。場合によっては、要素インスタンスを使用して大きな属性の集合を指定することができる。このため、要素名を各属性から分離することにより、文書ツリーを構文解析すると共に要素をより迅速に配置することができるようになる。加えて、一部の属性又は属性名／属性値対は他のものよりも格段に高い頻度で使用される傾向がある。属性名、属性値、及び属性名／属性値対を別々のセクションへとグループ化することにより、通常、圧縮は改善される結果となる。
【００２６】
（組込みデータ型及び特殊型の値の符号化）
エンコーダは組込み（又はデフォルト）データ型の属性及び要素の値を各型に従ったより効率的な表現へと符号化するように動作する。型情報を含むスキーマが利用可能でない場合、値はストリングとして扱われる。加えて、値（例えば、１桁の整数）がストリングとしてより効率的に表される場合、エンコーダはこの整数を符号化するのではなく、ストリングとして扱うことを選択しても良い。デフォルトでは、ストリングはマルチバイト文字のストリングを符号化する標準の効率的な方法を提供するＵｎｉｖｅｒｓａｌＴｅｘｔＦｏｒｍａｔ（ＵＴＦ−８）ストリングとして符号化される。また、ＵＴＦストリングは長さ情報を含むので、適切な区切り記号を探すという問題を回避できると共に、ストリングの終わりまで容易にスキップすることができる。
【００２７】
特殊型エンコーダは特殊なデータ型に使用することができる。これらの特殊型エンコーダは後述のエンコーダＡＰＩのｓｅｔＴｙｐｅＥｎｃｏｄｅｒ（）インタフェースを使用して指定することができる。特殊型エンコーダについての情報は、構造セグメントのヘッダに格納されるのが好ましく、型エンコーダ識別子のテーブルとして格納されるのが有利である。更に、同じメカニズムを使用してデフォルト型エンコーダ（組込みデータ型用）を無効にすることができる。一部の組込みデータ型は本来デフォルトエンコーダを使用して符号化されるが、特殊エンコーダを代わりに使用しても良い。ビットストリーム内での識別が必要とされるため、ＸＭＬ文書の正確な再現のためには代替の復号化プロセスが必要になるであろう。各符号化された値の前には、その値を符号化するのに使用された型エンコーダの識別子がある。
【００２８】
このように、本開示により実現されるＸＭＬ文書エンコーダは、ＸＭＬ文書内の様々な型の構造及びテキスト用に複数の符号化形式を含んでも良い。符号化形式は組込みであっても、あるいは、デフォルトであっても良く、周知のデータ型又は頻出するデータ型のために使用される。特殊型エンコーダは任意の特殊なデータ型に対して使用されても良い。このとき、符号化プロセスで使用される特定の型エンコーダの識別がパケットのヘッダに組み込まれても良い。組み込まれることで、デコーダは符号化された文書中の符号化された型に対して使用されるべき復号化プロセスを識別することができる。必要に応じて、特定の型のエンコーダはＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＩｎｄｉｃａｔｏｒ（ＵＲＩ）を介してコンピュータネットワークからアクセスされても良い。デコーダが符号化された文書中のパケット内に出現する符号化された型に対応する復号化プロセスをアクセス又は実現できない場合、デフォルトの応答は符号化されたデータを無視し、空のデータ（空白表示など）を再現する結果となる可能性がある。別の例として、デコーダは、例えば、符号化されたデータを伴うＵＲＩを使用して接続されたネットワークから特殊型デコーダを取り出すように動作することができる。エンコーダ／デコーダ形式のＵＲＩは上述のテーブルへと組み込まれても良く、それにより、ビットストリームに含まれても良い（付録参照）。
【００２９】
このアプローチを更に拡張すると、単一のデータ型に対して複数の符号化形式を使用しても良い。例えば、テキストストリングはストリングの長さに基づいて各様に符号化されても良いが、これは、復号化プロセスの実行に要する時間と得られる圧縮のレベルとの間の妥協を表す。例えば、０から９までの文字を有するテキストストリングは符号化されず、１０から９９までの文字及び１００から９９９までの文字を有するストリングはそれぞれの（異なる）符号化形式を用いて符号化されるものとする。更に、これらの符号化形式のうちの１つ以上は特殊なデータ型に対するものであるとする。この例においてテキストストリングを符号化する際に、エンコーダは、０から９の文字に対しては符号化を行なわず、１０から９９の文字ストリングに対してはデフォルトエンコーダ、１０１以上のテキスト文字を有するストリングに対しては特殊エンコーダを使用するかもしれない。
【００３０】
図１０はＸＭＬ文書を符号化する方法１０００の一例を示し、この方法はステップ１００２からスタートする。まず、ステップ１００４において、方法１０００はＸＭＬ文書１０４を検査し、ＸＭＬ文書１０４の一部を形成する各データ型を識別する。ステップ１００６において、方法１０００は対応する特殊符号化形式が利用可能であるデータ型の第１の集合を識別するように動作する。特殊データ型を識別すると、ステップ１００８は対応する特殊符号化形式を用いて第１の集合中にデータ型を有するＸＭＬ文書の各部分を符号化する。次に、ステップ１０１０において、方法１０００は残りの部分のデータ型に対応するデフォルト符号化形式を用いてＸＭＬ文書の残りの部分の各々を符号化する。ステップ１０１２において、対応する特殊符号化形式を用いて少なくとも第１の集合中の各データ型を参照する情報から表現が形成される。ステップ１０１４において、表現はＸＭＬ文書１０４の符号化された形態として符号化された部分と関連付けられる。こうして、方法１０００はステップ１０１６で終了する。
【００３１】
（構造セグメント（又は構造ストリーム））
図２は構造セグメント（又はストリーム）１０６の種々のセクションを示す。構造セグメントはヘッダ２０２で開始され、その本体は複数のセクション２０４へと分割される。ヘッダ２０２はＸＭＬのバージョン及び符号化形式のバージョンを識別する。
【００３２】
本体中の各セクション２０４はセクションの種別を示す固有のシグネチャで開始される。このため、種々のセクションは特定の順序で配置される必要がない。しかし、以下の説明では、セクションは図２に示す順序で配置されるものと想定する。セクションシグネチャの後にはセクションのサイズを示すサイズフィールドが続く。
【００３３】
ＩＤテーブルセクション２０６により、ＩＤを伴う要素を文書階層セクション２０８に迅速に配置することができる。文書がＩＤを伴う要素を有する場合でも、符号化された文書にＩＤテーブル２０６が存在しない可能性がある。これは、ＩＤ定義を含むＤＴＤ又はスキーマが符号化の時点で利用可能でないためであろう。
【００３４】
セクション２１０は、文書型宣言及び内部（ＤＴＤ）部分集合のために確保されるのが好ましい。ＭＰＥＧ−７記述などのＸＭＬスキーマベース文書に関しては、このセクション２１０は存在しないであろう。
【００３５】
名前空間２１２、要素名２１４、属性名２１６、及び属性値２１８に対しては、コードテーブル用のセクションが存在する。エンコーダ及びデコーダの双方のために事前に定義され、ビットストリームにおいて搬送されない他のコードテーブルと区別するために、以降、これらのコードテーブルは局所コードテーブルと呼ばれる。例えば、ＭＰＥＧ−７又はＸＭＬスキーマに対しては事前に定義されたコードテーブルが存在しても良い。
【００３６】
局所コードテーブルの後には、通常、局所コードテーブル及び任意の事前に定義されたコードテーブルにおいて定義されたコードを利用する属性名／属性値対２２０のテーブルを含むセクションが続く。
【００３７】
文書階層セクション２０８は、局所コードテーブル及び事前に定義されたコードテーブルからのコードを使用するＸＭＬ文書の符号化ツリー構造である。
【００３８】
符号化のためにコードテーブル及び型エンコーダを使用する以外に、エンコーダは圧縮プログラムを使用して各セクションを圧縮することが多い。構造セグメント１０６の本体の各セクションを独立して圧縮する代わりに、構造セグメントの本体を一体として圧縮することができる。これにより、オーバーヘッドが減少し、データ量が増加するので、実際、圧縮率が向上するであろう。しかし、このような圧縮は、文書が特定の要素を含むか否かを見極めるために構造本体全体を復元させる必要がある。双方のアプローチを検査して、実際にどちらの方が良いのかを判定しても良い。しかし、セクションが小さい場合、圧縮は効果的ではない可能性があり、エンコーダはこのセクションを圧縮しないことを選択しても良い。各セクションは圧縮が適用されたか否かを知らせるための圧縮フラグを有する。圧縮が適用された場合、各セクションの始めのサイズフィールドはバイト単位でのセクションの圧縮されたサイズ（圧縮前のサイズではない）を示す。
【００３９】
場合によっては、各セクション中のデータの特徴を考慮に入れて、別々の圧縮プログラムを各セクションに対して使用することができる。使用される圧縮プログラムについての情報はヘッダ中で提供される。デフォルトでは、構造セグメント及びテキストセグメント中の全てのセクションを圧縮するのにＺＬＩＢを使用する。ＺＬＩＢアルゴリズムはヘッダ及びチェックサムを生成し、これにより、圧縮されたデータの整合性をデコーダ側で検証することができる。
【００４０】
（テキストセグメント（又はテキストストリーム））
テキストセグメント１０８はテキストセグメントシグネチャで開始され、この後には符号化されたテキストのサイズを示すサイズフィールドが続く。テキストセグメントは要素のテキストであるＵＴＦ−８ストリングのシーケンスを含む。
【００４１】
＜エンコーダモデル及びデコーダモデル＞
（エンコーダモデル）
図３は、ＸＭＬ文書１０４を格納又は伝送のためにビットストリーム３０６へと符号化するためのエンコーダ３０２を組み込むＸＭＬエンコーダモデル３００を示す。エンコーダモデル３００はコンピュータモデル８０１内で動作するソフトウェアプログラム又はサブプログラムとして実現されても良い。プログラムは、通常、ＨＤＤ８１０に格納され、プロセッサ８０５による実行時に読み出され制御される。ビットストリーム３０６は、作成されるとＩ／Ｏインタフェース８０８及びネットワーク８２０を介して伝送され、サーバコンピュータ８５０により相補的復号化・再現が行なわれても良い。また、ビットストリーム３０６は、後で再現するためにＨＤＤ８１０に格納されても、あるいは、ドライブ８１２内のＣＤ−ＲＯＭとして格納されても良い。エンコーダ３０２は、文書ツリー１０２を作成中に符号化できるように、アプリケーションプログラムインタフェース（ＡＰＩ）３０８（ＤＯＭＡＰＩなど）をサポートしても良い。コードテーブル３１２、組込みデータ型用エンコーダ３１４、及び符号化プロセスで使用されるであろうデフォルト圧縮プログラム３１６を提供するために、標準ライブラリ３１０（ＸＭＬ用）が使用される。種々のドメインに対してドメイン固有ライブラリ３１８が定義されても良い。各ドメイン固有ライブラリ３１８は、特定のドメイン用のコードテーブル３２０及び幾つかのデータ型用のエンコーダ３２２を含んでも良い。また、アプリケーションは上述のような特殊なデータ型用のアプリケーション固有エンコーダ３２６及び対応する圧縮プログラム３２８を含む固有モジュール３２４を提供することもできる。しかし、これらの型エンコーダ３２６及び圧縮プログラム３２８は、ダウンロード可能であるか、プラットフォーム独立型であるか、あるいは、デコーダ側に予め組み込まれているかのいずれかでなければならない。アプリケーションは、エンコーダ３２６に定義済のコードテーブル３３０を使用するように指示することもできる。コードテーブル３３０は、ビットストリーム３０６へと組み込むことも、あるいは、デコーダ側に予め組み込むこともできる。図３に示すエンコーダ及び圧縮プログラムの各々は、ソフトウェア（サブ）プログラムにより実現されても良く、場合によっては、専用のハードウェア（迅速な符号化用など）により実現されても良い。
【００４２】
（デコーダモデル）
図４は、ＸＭＬビットストリーム３０６を復号化してＸＭＬ文書１０４を出力するためのデコーダ４０２を含む相補ＸＭＬデコーダモデル４００を示す。デコーダは、アプリケーションが文書ツリー１０２の独自の内部モデルを構築できるようにするＡＰＩ４０８（例えば、ＳＡＸ（「ｓｉｍｐｌｅＡＰＩｆｏｒＸＭＬ」）又はＤＯＭＡＰＩ）をサポートしても良い。これにより、デコーダ４０２はＸＭＬ文書を出力する必要がなくなり、アプリケーションは再現されたＸＭＬ文書１０４を再度構文解析する必要がなくなる。いずれにしても、ＸＭＬビットストリーム３０６を復号化する際に、デコーダ４０２は標準ライブラリ４１０、任意のドメイン固有ライブラリ４１８、及び任意の予め組み込まれた又はダウンロードされたアプリケーション固有モジュール４２４（エンコーダにより使用）を使用する。図４において、デコーダモデル４００の要素は図３と同様にナンバリングされており、ナンバリングの数値には１００の差があるが、各要素は対応する同様の関数を有する。デコーダモデル４００は、例えば、コンピュータモデル８０１内で実現され、サーバコンピュータ８５０からネットワーク８２０を介して受信されたビットストリーム３０６を復号化しても良い。また、デコーダモデル４００は、例えば、ＣＤ−ＲＯＭから得られたビットストリームを復号化するように動作しても良い。エンコーダ３０２と同様に、デコーダ４０２内でソフトウェア及びハードウェアの復号化プロセスが使用されても良い。
【００４３】
多くの場合、クライアント側のデコーダ４０２はＤＴＤ又はスキーマに対して図４のＸＭＬ文書１０４を検証する必要がない。クライアント側の検証は費用がかかり非効率的である上に重複する可能性が高い。デコーダ１０４は、ＤＴＤ又はスキーマに対してサーバ側でＸＭＬ文書が検証されることを想定しても良い。同様に、下層のトランスポート及びバイナリ形式に組み込まれるチェックサムなどの任意の誤り検出メカニズムは、あらゆる伝送エラーを検出できなければならない。
【００４４】
＜要素の配置＞
ＸＭＬ要素は、ＩＤ又はＸＰａｔｈ／ＸＰｏｉｎｔｅｒフラグメントを使用して参照・配置することができる。先に説明したように、構造セグメント１０６のＩＤテーブル２０６により、ＩＤを伴う要素を文書階層セクション２０８に迅速に配置することができる。要素と関連付けられるあらゆるテキスト及び属性は、符号化された要素中のロケータを使用することで効率的に配置することができる。
【００４５】
以下に示すのは、ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＩｎｄｉｃａｔｏｒ（ＵＲＩ）へと付加することが可能なＸＰａｔｈフラグメントの例である。

これは、ｄｏｃの第２章の第３節を選択する。

これはテキスト「Ｏｖｅｒｖｉｅｗ」を含む１つ以上のタイトル子を有するコンテキストノードの章子を選択する。

これはコンテキストノードの最終章又は付録子を選択する。

これは値「ｗａｒｎｉｎｇ」を伴う型属性を有するコンテキストノードの全ての段落子を選択する。

これはＩＤ属性を有するコンテキストノードの全ての段落子を選択する。
【００４６】
ＸＰａｔｈ／ＸＰｏｉｎｔｅｒフラグメントは、ＸＭＬ文書内の所要の要素の絶対位置又は相対位置を表す位置ステップのリストから成る。通常、フラグメントは要素名のリストを含む。上述の例のように、配列内の要素の索引、属性の存在、一致属性値、及び一致テキスト内容などの追加の選択基準を指定するのに述語又は関数が使用されても良い。
【００４７】
符号化された文書階層は簡潔であるので、完全なオブジェクトツリー表現へと展開することなく構文解析（及びインスタンス生成）を行なうことができる。まず、フラグメントアドレスが符号化された形態へと変換される。このような変換プロセスの結果の１つとして、所要の要素が実際に文書中で出現したか否かを即座に判定できるようになる。符号化されたフラグメントアドレスのコンポーネントの突き合わせは、サブストリングの突き合わせよりも格段に効率的である。設計により、単純なＸＰａｔｈ／ＸＰｏｉｎｔｅｒフラグメント（最も一般的に使用される）は迅速に評価できるようになる。また、最初に文書階層を探索することにより、より複雑なフラグメントアドレスの場合、後続の評価ステップの範囲は大幅に狭められる。
【００４８】
＜ストリーミングのためのビットストリームのパケット化＞
（ＸＭＬのストリーミング）
従来より、ＸＭＬ文書は生のテキスト形式で格納・伝送されることが多い。一部のアプリケーションでは、ＸＭＬ文書は、格納又は伝送のための従来のテキスト圧縮アルゴリズムを使用して圧縮され、構文解析・処理を受ける前にＸＭＬへと復元される。圧縮によりＸＭＬ文書のサイズは大幅に減少するかもしれないが、アプリケーションは依然として構文解析・処理を実行する前にＸＭＬ文書全体を受信しなければならない。
【００４９】
ＸＭＬ文書のストリーミングは、ＸＭＬ文書の一部が十分な長さだけ受信され次第、構文解析・処理が開始されることを意味する。この機能は、低帯域幅の通信リンク及び／又は非常に制限されたリソースを伴うデバイスの場合に非常に有用である。
【００５０】
通常のＸＭＬパーサはＸＭＬ文書の整合が取れている（すなわち、一致し且つ重複しない開始タグ／終了タグ対を有する）ことを期待する。このため、パーサはＸＭＬ文書ツリーを深さ優先方式でのみ構文解析し、ＸＭＬ文書の内容がこの方式に対応するように再構成されない限り文書の一部をスキップすることができない。
【００５１】
（ビットストリームのパケット化）
前述のようにＸＭＬ文書を完全な構造セグメント１０６及び完全なテキストセグメント１０８へと符号化することによって、データのサイズが大幅に減少すると同時に、伝送エラーの検出が可能になるであろう。しかし、デコーダ４０２は依然として処理する前に大量の符号化されたデータを受信しなければならない。例えば、デコーダ４０２は文書階層の構文解析を開始する前にコードテーブル１１０の受信を完了しているであろう。同時に、デコーダ４０２はノードと関連付けられたテキストを取得するのにテキストセグメント１０８の特定のセグメントの到着を待たなければならない。デコーダ側で可能な限り早く処理を開始するには、図５に示すように、ＸＭＬ文書１０４を徐々に符号化し、符号化されたデータ５００の小さいパケット５０２を随時デコーダ４０２へと送信できるようにしなければならない。図５において、網掛けされているパケット５０４は、構造パケットを示し、斜線入りのパケット５０６はテキストパケットを示す。これらのパケットの前にはヘッダパケット５０８があり、後にはトレーラパケット５１０が続く。好適な構成では、各データパケット５０２は完全な構造セグメント１０６又は完全なテキストセグメント１０８と同じ構造を有する。また、各パケット５０２はその前に送信されたパケット５０２に従属することもあり、実現例によっては、後に送信される所定数のパケットに従属することもある。この所定数は動的に判定されても良い。
【００５２】
配信を受けながら文書を処理する必要性とは別に、エンコーダ／デコーダは、通常、固定サイズの出力／入力バッファを有する。このため、非常に短い文書を除き、エンコーダ３０２はＸＭＬ文書を複数のパケットへと徐々に符号化する必要がある。パケット５０２の各々（５０４、５０６、５０８、及び５１０を含む）の前にはパケットヘッダがある。パケットヘッダはパケットＩＤとして使用されるだけでなく、パケットに順序付けしてその欠落を検出するためのパケット番号を含む。また、パケットヘッダは、パケット５０２のサイズをバイト単位で示すサイズフィールドと、パケットが構造パケット５０４、テキストパケット５０６、ヘッダパケット５０８、トレーラパケット５１０、及び図５には示されていないが後述するコマンドパケットという名前の更なる型のパケット５０２のうちのどれであるかを示す型フィールドとを含む。
【００５３】
各構造パケット５０４に関して、組み込まれるＩＤテーブルはパケットに含まれる要素のＩＤのみを含む。そのコードテーブルは伝送されていない新規のコードのみを含む。伝送済のコードは再度割り当てられることも、再度マップされることもない。デフォルトの実現例では、新規の値をテーブルに付加し、エントリの索引（テーブルの基本索引により拡張される）をコードとして使用するだけである。これよりも若干複雑な（しかし、コード効率が高い）方法は、パケットが出力される直前に値の出現回数をカウントし、より頻繁に出現する値をより短いコードに再度マップすることである。定義済のコードテーブルが使用されるか、あるいは、再マッピングが出現回数に基づいていない場合、圧縮前に値をソートすると圧縮率が向上する可能性がある。また、コード割当てのための別のアルゴリズムを実現することもできる。しかし、一度出力されるとコードは固定されるので、他の値に再度割り当てしたり、後続のパケットに再度マップしたりすることはできない。また、定義済のコードテーブルは、本明細書で後述するエンコーダインタフェースのＵｓｅＣｏｄｅＴａｂｌｅ（）メソッドを使用することで指定することもできる。更に、このメソッドにより定義済のコードテーブルをデータと共にビットストリームへと符号化すべきか否かを指定することができる。ＸＭＬ（又はＭＰＥＧ−７のようなアプリケーションドメイン）に欠かせない複数の名前空間のコードテーブルは全てのＸＭＬ（ＭＰＥＧ−７）エンコーダ／デコーダにハードワイヤードされていることが予想されるので、ビットストリームへと符号化される必要がない。
【００５４】
ＩＤ、要素名、属性名、又は属性値が定義済の長さよりも長い場合はテキストパケット中に符号化され、実際のストリングではなくストリングロケータがテーブル中に出現することになる。
【００５５】
構造パケットの文書階層セクションはノードのシーケンスを含む。各ノードはノードの（符号化された）サイズをバイト単位で示すと共にパケット中に符号化されている子孫ノードの合計サイズを含むサイズフィールドをそれぞれ有する。ノードは要素ノード、コメントノード、テキストノード、及びノードロケータのいずれかとなる。各ノードはその型を示すノード型フィールドを有する。
【００５６】
文書階層は以下に示す項目を含んでも良い。
（ｉ）完全な文書ツリー：これは非常に短い文書の場合のみ可能である。
（ｉｉ）完全なサブツリー：サブツリーは前のパケット中に符号化される別のノードの子である。
（ｉｉｉ）不完全なサブツリー：時間的及び／又はサイズ的な制約のためにサブツリー全体を１つのパケットへと符号化できないため、サブツリーは不完全である。
【００５７】
不完全なサブツリー６０２及び６０４を有するツリー構造６２２に対して、欠落しているノード及び不完全なサブツリーの子孫を配置するために、ノードロケータが図６Ａに示すように使用される。この点に関して、前述の例を参照して説明すると、符号化が行なわれるときには文書１０４の階層ツリー表現１０２は公表されているが、送受信されるパケットの復号化のときには、通常、ツリー表現１０２の一部のみが利用可能になる。更にパケットが受信されると共に、ツリーが再現されるであろう。例えば、図６Ｂに示すデータストリームにおいて、パケット６２０（この例では、データストリーム中のパケット＃２）は文書のツリー構造６２２の一部を含み、この構造はノードＡ、Ｂ１、Ｂ２、及びＢ３を含む。しかし、この例では、パケット６２０のサイズはツリー構造６２２全体を記述し、Ｂ４及びＤ１のような他のノードを収容するには不十分である。このため、ノードロケータ６０８及び６０６は、対応する親ノード（Ｂ４及びＢ２のそれぞれ）の記述へと組み込まれ、欠落したノードのシーケンス及びそのサブツリーを含む構造パケットのパケット番号６１０及び６１２を含む。このため、図６Ｂに示すパケットのシーケンスを受信するとき、パケット（＃２）６２０の受信のときにはツリー６２２の一部を再現し、パケット（＃７）６１０の受信のときにはノードＤ１を含む枝を再現し、パケット（＃２０）６１２の受信のときにはツリーの平衡を再現することができる。
【００５８】
各要素ノードは、名前空間コード及び要素（名）コードを含むのが好ましく、要素が属性を有する場合には、属性名／属性値対テーブル中の第１の属性のバイトオフセット及び属性の数を有するのが好ましい。
【００５９】
各テキストノード又はコメントノードは、通常、実際のテキストではなく、テキストロケータを有する。テキストロケータはテキストパケットのパケット番号とテキストパケットへのバイトオフセットを指定する。
【００６０】
場合によっては、ストリングはパケットの最大サイズを越える可能性がある。このような場合、ストリングは図７に示すように、複数のテキストパケットにまたがるフラグメントとして格納される。各テキストパケット７０２は、ＵＴＦ−８符号化ストリングのリスト、ストリングロケータ、及びストリングフラグメントのうちのどれを含むかを示すフラグ７０４を有する。ストリングフラグメントの場合、次のフラグメントのパケット番号も含まれる。テキストパケットがストリングの最終（又は唯一）のフラグメントを含む場合、次のフラグメントに対するパケット番号は図７に示すように０に設定される。
【００６１】
（文書ツリーを構築するためのコマンド）
ＸＭＬ文書は、符号化又は生成（定義済のＤＴＤ又はスキーマに従って）中に受信側へのストリーミングのためにパケット化される。この場合、ＸＭＬ文書は、通常、ＤＯＭＡＰＩなどのＡＰＩを使用してリアルタイムで構築される。ＸＭＬファイルを構文解析する代わりに、エンコーダ３０２は、メモリ表現から直接ビットストリーム３０６を構築する。ＡＰＩを使用して挿入・付加されるノード及びサブツリーはデコーダ側のメモリ表現を変更するための（バイナリ）コマンドパケットとして符号化される。パケット番号によりコマンドパケットは確実に正しいシーケンスで実行されるようになる。
【００６２】
伝送されるノードは同じ文書（定義済のＤＴＤ又はスキーマに従う）の一部であり、文書は常時エンコーダ３０２とデコーダ４０２との間でオンライン状態であり同期しているので、ノードの内容に関して整合性の問題があってはならない。幾つかの提示では、ある情報は時間的な関連性しか有しない。具体的には、一部の情報は提示中のある一定の期間内でのみ関連性を有する。提示の２つの異なる時間インスタンスと関連する情報ユニット（例えば、フットボールの試合のスコア）は、それ自体が整合性に欠ける可能性がある。提示記述方式は、提示のタイミング／同期モデルを確立するのに望ましい。ＸＭＬデータを含む媒体オブジェクトのタイミングは、開始時間及び持続時間により示すことができる。このような提示エンコーダ／デコーダ対は、通常、内部に配置された上述のようなＸＭＬエンコーダ／デコーダを含むであろう。ＸＭＬデコーダではなく、提示デコーダが、開始時間属性及び持続時間属性を解釈するように動作する。提示エンコーダは、既に関連していないＸＭＬサブツリーをメモリから除去すべきか否かを決定する。ＸＭＬエンコーダ／デコーダに関する限り、整合性の問題は生じない。生成装置が常に有効な文書（フラグメント）を生成する必要がある場合、（整合性に欠ける又は無効である可能性のある）ノード又はサブツリーを除去するコマンドは必要でない。すなわち、挿入コマンド及び付加コマンドのみが必要とされる。
【００６３】
コマンドパケットは、付加又は挿入するサブツリーの（ルートの）パスとそのサブツリーを含む構造パケットのパケット番号とを含む。例えば、図６Ｂに戻って説明すると、ノードＢ４に対するロケータ６０８をパケット６２０に収容できない場合、パケット＃２とパケット＃２０との間にノードＢ４をノードＡへと有効に取り付けるコマンドパケットを挿入しなければならない。コマンドパケットはノードＢ４により定義される構造を含むパケット６１２を指し示すロケータを含むであろう。
【００６４】
（ビットストリームの定義）
ビットストリーム３０６は付録により定義されるようにＥｘｔｅｎｄｅｄＢａｃｋｕｓ−ＮａｕｒＦｏｒｍ（ＥＮＢＦ）で定義されるのが好ましい。文字は一重引用符で括られ、ストリングは二重引用符で括られる。別途記載のない限り、ＵＴＦ−８符号化におけるＵＣＳ文字及びＵＴＦストリング（長さ情報を含む）が想定される。
【００６５】
＜ＡＰＩ＞
（文書及びスキーマ用のＡＰＩ）
デコーダ４０２は常に符号化された文書を変換してＸＭＬに戻す必要はない。上述のように、デコーダ４０２はＳＡＸＡＰＩ、ＤＯＭＡＰＩ、又はその他の著作権のあるＡＰＩなどのＡＰＩをサポートし、アプリケーションが復号化された内容に直接アクセスできるようにしても良い。これにより、デコーダ４０２はＸＭＬ文書を再現・出力する必要がなくなり、アプリケーションは再現されたＸＭＬ文書を再度構文解析する必要がなくなる。
【００６６】
また、アプリケーションは、スキーマに格納された情報にアクセスしなければならない。スキーマもＸＭＬ文書であるので、同様に符号化することができる。スキーマ定義をアクセス・解釈するために既存のＳＡＸＡＰＩ又はＤＯＭＡＰＩを使用すると非常に時間がかかる。ＷａｎＥ．，ＡｎｄｅｒｓｏｎＭ．，ＬｅｎｎｏｎＡ．，ＤｅｓｃｒｉｐｔｉｏｎＯｂｊｅｃｔＭｏｄｅｌ（ＤｅｓＯＭ）．Ｄｏｃ．ＩＳＯ／ＩＥＣＪＴＣ１／ＳＣ２９／ＷＧ１１ＭＰＥＧ００／Ｍ５８１７，Ｎｏｏｒｄｗｉｊｋｅｒｈｏｕｔ，Ｍａｒｃｈ２０００に定義されるようなスキーマＡＰＩをサポートするパーサによりスキーマの定義へのアクセスがかなり容易になるであろう。
【００６７】
組込みデータ型及び特殊型の値を効率的に符号化するためには、エンコーダはスキーマから型情報を取得可能でなければならない。このため、スキーマＡＰＩはエンコーダ３０２にとっても極めて重要である。
【００６８】
＜エンコーダ用ＡＰＩ＞
以下に提案するバイナリ形式は、種々の機能及び複雑度のエンコーダの実現を考慮に入れている。この節で説明するインタフェースにより基本エンコーダを構築することができる。この基本エンコーダは、符号化方式によりサポートされるより複雑な特徴を提供するように拡張することが可能である。
【００６９】
（エンコーダインタフェース）

・最大パケットサイズをバイト単位で設定する。

・専用データの最大サイズをバイト単位で設定する。尚、パケットに含むことができる専用データの量はパケットの最大サイズにより制限される。ビットストリームのサイズを削減する目的に反するので大量の専用データは予期されていない。

・ユーザデータをヘッダパケットに書き込む。既存のデータは上書きされることになる。

・エンコーダに定義済のコードテーブル及びコードテーブルをデータと共に符号化すべきか否かを通知する。

・エンコーダに特定セクションに対して特定の圧縮プログラムを使用するように指示する。Ｓｅｃｔｉｏｎは以下の値に関する一覧である。ＳＴＲＵＣＴ＿ＢＯＤＹ＝１，ＴＥＸＴ＿ＢＯＤＹ＝２，ＩＤ＿ＴＡＢＬＥ＝３，ＮＳ＿ＳＥＣＴ＝４，ＥＬＥＭＥＮＴ＿ＳＥＣＴ＝５，ＡＴＴＲ＿ＮＡＭＥ＿ＳＥＣＴ＝６，ＡＴＴＲ＿ＶＡＬＵＥ＿ＳＥＣＴ＝７，ＡＴＴＲ＿ＰＡＩＲ＿ＳＥＣＴ＝８，ＤＯＣ＿ＨＩＥＲＡＲＣＨＹ＿ＳＥＣＴ＝９。Ｉｎｆｌａｔｅｒはｊａｖａ．ｕｔｉｌ．ｚｉｐパッケージのＩｎｆｌａｔｅｒと同じインタフェースを有する。

・出力ストリームへのバッファ中のパケットをフラッシュする。

・バッファ中のパケットの集合が出力される前に通知を受信し、アプリケーションがアプリケーション固有データをパケットへと挿入できるようにする。

・バッファ中のヘッダパケットを除く各パケットにユーザデータを書き込む。既存のユーザデータは上書きされることになる。
【００７０】
（コードテーブルインタフェース）

・コードテーブル中のエントリの数を取得する。

・コードテーブルのエントリと関連付けられた値の名前空間を取得する。

・コードテーブルのｉ番目のエントリと関連付けられた値を取得する。

・コードテーブルのｉ番目のエントリと関連付けられた型を取得する。

・コードテーブルのｉ番目のエントリと関連付けられたコードを取得する。

・コードと関連付けられた値を取得する。

・コードテーブルにより確保された最大コード値を取得する。エンコーダは上述の最大コード値を自由に使用することができる。アプリケーションにより、エンコーダは定義済のコードテーブルにより残された孔を使用するように実現されても良い。
【００７１】
（型エンコーダインタフェース）

・テキスト表現が与えられると、値をバイト配列へと符号化する。

・符号化された値を値のテキスト表現へと復号化する。
【００７２】
＜ＸＭＬデータ、特に、提示のＭＰＥＧ−７記述の符号化＞
ＭＰＥＧ−７記述（音声映像（ＡＶ）内容を記述するのに使用されるＸＭＬデータ）を含むＸＭＬデータ（のフラグメント）がストリーミングされ、ＡＶ内容と共に提示される場合、媒体オブジェクト（ＸＭＬデータを含む）のタイミング及び媒体オブジェクト間の同期が指定されなければならない。ＸＭＬと同様に、ＤＤＬ（ＸＭＬの記述定義言語）は媒体オブジェクトを提示するためのタイミング／同期モデルを定義しない。上述のように、ＳＭＩＬのようなＭＰＥＧ−７記述方式（ここでは提示記述方式と呼ぶ）は、マルチメディア提示を作成するためのタイミング／同期モデルを提供することが望ましい。
【００７３】
ＭＰＥＧ−７記述をＡＶオブジェクトと同様に扱えるようにすることが提案されている。これは、ＡＶオブジェクトのような提示で使用される各ＭＰＥＧ−７記述フラグメントが、開始時間及びその時間範囲を定義する持続時間を用いてタグ付けされることを意味する。これにより、ＭＰＥＧ−７フラグメント及びＡＶオブジェクトの双方を提示記述方式の媒体オブジェクト要素のクラスにマップし、同じタイミング／同期モデルに従わせることができる。特に、ＳＭＩＬベースの提示記述方式の場合、＜ｍｐｅｇ７＞タグのような新規の媒体オブジェクトを定義することができる。また、ＭＰＥＧ−７記述はテキストの特定の型として扱うこともできる。
【００７４】
異なる型のＭＰＥＧ−７記述を単一のストリーム又は別々のストリームで送信することが可能である。また、異なる時間範囲のサブフラグメントを有するＭＰＥＧ−７記述フラグメントを単一のデータストリーム又は別々のストリームで送信することも可能である。これが提示エンコーダの役割であり、前述のＸＭＬエンコーダ３００とは対照的である。
【００７５】
提示エンコーダは、パケットの内容が必要になる又は関連しているのがいつか、どの程度の期間かを知らせる開始時間及び持続時間を伴うＸＭＬパケットをラップする。パケットは以下の項目を含んでも良い。
（ｉ）相互に連結されて高い圧縮率を達成すると共にオーバーヘッドを最小限にする複数の短い記述フラグメント（各々が独自の時間範囲を伴う）
（ｉｉ）単一の記述フラグメント
（ｉｉｉ）長い記述フラグメントの一部
パケットが複数の記述フラグメントを含む場合、パケットの開始時間は各フラグメントの開始時間のうちの最も早い時間であり、パケットの持続時間は各フラグメントの終了時間（フラグメントの開始時間に持続時間を加えることにより計算される）のうちの最も遅い時間とパケットの開始時間との差である。
【００７６】
アプリケーションを同報通信する際に、ユーザがいつでも提示を受信できるようにするために、関連する素材が定間隔で繰り返されなければならない。ＸＭＬパケットの場合、以前に送信したパケットの一部は既に関連していない可能性があるので一部だけを再送信すれば良いが、ヘッダパケットは繰り返す必要がある。これは、アプリケーションを同報通信する場合、構造パケット、テキストパケット、及びコマンドパケットの間にヘッダパケットが散在し、伝送を既知の状態へとリセットする可能性があることを意味する。
【００７７】
（産業上の利用可能性）
上述の構成はコンピュータ産業及びデータ処理産業に適用可能であると共に、部分的に受信された情報を処理する能力を持ちつつ関連する通信リソースを効率的に使用する際にも適用可能であることが以上の説明から明らかである。
【００７８】
以上の説明は、本発明の１つ以上の実施形態を述べたにすぎず、本発明の趣旨から逸脱することなく、修正及び／又は変更を加えることができる。本実施形態は例示のためのものであり、制限するためのものではない。例えば、ＸＭＬ文書に対する説明が行なわれているが、ここで開示される手順は文書のツリー表現などの任意の階層表現に適用可能である。
【００７９】
（付録）
＜ビットストリームの定義＞
ビットストリームはＥｘｔｅｎｄｅｄＢａｃｋｕｓ−ＮａｕｒＦｏｒｍ（ＥＮＢＦ）で定義されるであろう。文字は一重引用符及び二重引用符で括られる。別途記載のない限り、ＵＴＦ−８符号化におけるＵＣＳストリング及びＵＴＦストリング（長さ情報を含む）が想定される。

注：　符号化されたＸＭＬ文書のビットストリームはパケットのシーケンスから成る。シーケンスはヘッダパケットで開始され、トレーラパケットで終了する。
【００８０】

注：　ｐａｃｋｅｔ＿ｎｕｍｂｅｒは０より大きくなければならない。

注：　ｕｎｓｉｇｎｅｄ＿ｓｈｏｒｔに関して、０〜６５５３５の範囲の符号無し整数が２バイトを使用して表される。第１バイトはこの整数の上位バイトである。

注：　ｖａｒｉａｂｌｅ＿ｌｅｎｇｔｈ＿ｎａｔｕｒａｌ＿ｎｕｍｂｅｒに関して、０〜１，０７３，７４１，８２３の範囲の自然数が４バイトで表される。第１バイトはこの数の上位バイトである。上位バイトの２つの最上位ビットは、実際、この数を表すために使用される追加のバイト数を示すのに使用される。例えば、「０１」は１つの追加のバイト又は２バイト表現を意味し、「１１」は３つの追加のバイト又は４バイト表現を意味する。

【００８１】

注：　ＵＴＦ８＿Ｓｔｒｉｎｇに関して、最初の２バイトは符号無しショートＵＴＦｌｅｎｇｔｈであり、読み込む追加のバイト数を指定する。追加のバイトはストリングのＵＴＦ−８符号化を含む。

注：　０の値は最大パケットサイズが未知であることを意味する。

注：　０の値は最大パケット数が未知であることを意味する。

注：　組込みデータ型に対する上述のリストは完全ではない。型００〜０Ｆが組込みデータ型用である。ＸＭＬエンコーダは型１０〜ＦＦをアプリケーション固有型に割り当てることができる。アプリケーションは任意のアプリケーション固有型に対して（Ｊａｖａ）型エンコーダ／デコーダを提供する役割がある。これらの型エンコーダ／デコーダは必要になる前に予め組み込まれるか、あるいは、ダウンロードされなければならない。型情報が利用できないときは、ＸＭＬテキスト及び属性値はストリングとして扱われることになる。
【００８２】

注：　現時点では、トレーラパケットはＸＭＬ文書の終わりを知らせるためにだけ使用される。トレーラパケットの本体は空である。
【００８３】

注：　上述のＥＢＮＦ規則は構造パケットの本体の種々のセクションを特定の順序で並べられるように定義するが、各セクションは固有のシグネチャにより識別されるので実際は任意の順序で並べることができる。
【００８４】

注：　ｓｅｃｔｉｏｎ＿ｓｉｚｅはシグネチャを除くセクションのサイズを格納する。

注：　圧縮フラグはテーブルが圧縮されているか否かを示す。
注：　ｂｏｏｌｅａｎに関して、１のバイト値は真を表し、０のバイト値は偽を表す。

注：　ＩＤ＿ｔａｂｌｅは圧縮されていないＩＤテーブルの構造を定義する。ＩＤテーブルは同じパケットの文書階層中に出現するノード（ノードロケータにより参照されるノードは含まない）のＩＤのみを収集する。符号化中、型情報が利用可能でない場合、エンコーダがＩＤを識別する方法が存在しないので、ＩＤが文書中に存在してもＩＤテーブルへと収集されない。

注：　ｏｆｆｓｅｔ＿ｔｏ＿ｔｈｅ＿ｄｏｃｕｍｅｎｔ＿ｈｉｅｒａｒｃｈｙは（圧縮されていない）ｄｏｃｕｍｅｎｔ＿ｈｉｅｒａｒｈｙ＿ｓｅｃｔｉｏｎへのバイトオフセットではなく、（圧縮されていない）ｄｏｃｕｍｅｎｔ＿ｈｉｅｒａｒｃｈｙ＿　ｓｅｃｔｉｏｎ中のｄｏｃｕｍｅｎｔ＿ｈｉｅｒａｒｃｈｙへのバイトオフセットである。

【００８５】
［内部部分集合セクション］

注：　内部部分集合セクションの詳細は未定である。

【００８６】

注：　ＮＳ＿ｔａｂｌｅへの索引が名前空間コードとして使用される。この索引のベースはフィールドｉｎｄｅｘ＿ｂａｓｅ中で指定される。名前空間コード０は空の名前空間のために確保されているので、名前空間テーブルのｉｎｄｅｘ＿ｂａｓｅは０にならない。

注：　ＮＳ＿ｔａｂｌｅは圧縮されていないＮＳテーブルの構造を定義する。テーブルへの索引が名前空間コードとして使用される。この索引のベースはフィールドｉｎｄｅｘ＿ｂａｓｅ中で指定される。名前空間コード０は空の名前空間のために確保されているので、名前空間テーブルのｉｎｄｅｘ＿ｂａｓｅは０にならない。

【００８７】

注：　定義済のコードがない限り、各コードテーブルへの索引がコードとして使用される。コードテーブルにより符号化に使用されるコードと実際の値との間のマッピングが可能になる。テーブルごとの索引のベースはテーブルのフィールドｉｎｄｅｘ＿ｂａｓｅ中で指定される。正のコードのみが許容されるので、ｉｎｄｅｘ＿ｂａｓｅは０の値をもたない。

注：　ｈａｓ＿ｐｒｅｄｅｆｉｎｅｄ＿ｃｏｄｅフラグはコードテーブルがｐｒｅｄｅｆｉｎｅｄ＿ｃｏｄｅ列を有するか否かを指定する。
【００８８】

注：　ｅｌｅｍｅｎｔ＿ｎａｍｅ＿ｃｏｄｅｔａｂｌｅは圧縮されていない要素名コードテーブルの構造を定義する。定義済のコードがない限り、テーブルへの索引が要素名コードとして使用される。索引のベースはフィールドｉｎｄｅｘ＿ｂａｓｅ中で指定される。コード０は確保されているので、コードテーブルのｉｎｄｅｘ＿ｂａｓｅは０にならない。

注：　エンコーダに知られている組込みデータ型及び特殊型を除く他の全ての型のテキスト内容はストリングとして符号化されることになる。

注：　空のｐｒｅｄｅｆｉｎｅｄ＿ｃｏｄｅはエントリに対して定義済のコードが存在しないことを意味するが、このような状況は発生すべきでない。定義済コードテーブルから値が欠落している場合、エンコーダはその値に対するコードを生成し、ｐｒｅｄｅｆｉｎｅｄ＿　ｃｏｄｅフィールドに格納しなければならない。

注：　要素名は、通常、テーブル中に直線状に格納される。しかし、要素名が長すぎる場合、別々のテキストパケットに格納することができる。テーブル中ではストリングロケータが代わりに使用される。

注：　ｂｙｔｅ＿ｏｆｆｓｅｔは、ストリングを見つけることができるテキストパケットの本体へのオフセットを指定する。

【００８９】

注：　ａｔｔｒｉｂｕｔｅ＿ｎａｍｅ＿ｃｏｄｅｔａｂｌｅは圧縮されていない属性名コードテーブルの構造を定義する。定義済のコードがない限り、テーブルへの索引が属性名コードとして使用される。索引のベースはフィールドｉｎｄｅｘ＿ｂａｓｅ中で指定される。コード０は確保されているので、コードテーブルのｉｎｄｅｘ＿ｂａｓｅは０にならない。

注：　属性名は、通常、テーブル中に直線状に格納される。しかし、属性名が長すぎる場合、別々のテキストパケットに格納することができる。テーブル中ではストリングロケータが代わりに使用される。
【００９０】

注：　ａｔｔｒｉｂｕｔｅ＿ｖａｌｕｅ＿ｃｏｄｅｔａｂｌｅは圧縮されていない属性値コードテーブルの構造を定義する。定義済のコードがない限り、テーブルへの索引が属性値コードとして使用される。索引のベースはフィールドｉｎｄｅｘ＿ｂａｓｅ中で指定される。コード０は確保されているので、コードテーブルのｉｎｄｅｘ＿　ｂａｓｅは０にならない。

注：　属性値は、通常、テーブル中に直線状に格納される。

注：　値は型に従って符号化される。エンコーダに知られている組込みデータ型及び特殊型を除き、値はストリングとして符号化される。
注：　有効なストリングロケータと区別するために空のＵＴＦ８−ストリングの後には＃ｘ００が続かなければならない。属性名が長すぎる場合、別々のテキストパケットに格納することができる。テーブル中ではストリングロケータが代わりに使用される。
【００９１】

注：　ａｔｔｒｉｂｕｔｅ＿ｎａｍｅ＿ｖａｌｕｅ＿ｐａｉｒ＿ｔａｂｌｅは圧縮されていない属性名／属性値対テーブルの構造を定義する。索引のベース（＞０）はフィールドｉｎｄｅｘ＿ｂａｓｅ中で指定される。

【００９２】

注：　ｓｕｂｔｒｅｅは圧縮されていないＸＭＬサブツリーの構造を定義する。

注：　ｎｏｄｅ＿ｓｉｚｅはノード及び同じパケット中に符号化されている子孫ノードのサイズを含む。

【００９３】

注：　ｎｅｘｔ＿ｐａｃｋｅｔ＿ｎｕｍｂｅｒが０の場合、テキストパケットの第１のストリング
は長いストリングの最終フラグメントである可能性がある。ｎｅｘｔ＿ｐａｃｋｅｔ＿ｎｕｍｂｅｒが０以外の場合、テキストパケット全体はストリングの単一のフラグメントを含む。

【００９４】

注：　追加するｓｕｂｔｒｅｅは特定のパケット番号と共に構造パケット中で定義され

【図面の簡単な説明】
【図１】
符号化ＸＭＬ文書を概略的に示す図である。
【図２】
構造セグメントの構成を示す図である。
【図３】
エンコーダモデルを概略的に示す図である。
【図４】
デコーダモデルを概略的に示す図である。
【図５】
ＸＭＬ文書を複数のパケットへと徐々に符号化するエンコーダを概略的に示す図である。
【図６Ａ】
ノードロケータを使用してノードを他の構造パケット中のサブツリーへとリンクする様子を概略的に示す図である。
【図６Ｂ】
各ノードロケータがサブツリーのパケットのパケット番号を含む様子を示す図である。
【図７】
各々のパケットが次のフラグメントを含むテキストパケットを指し示す複数のテキストパケット中のストリングフラグメントとして長いストリングが格納される様子を概略的に示す図である。
【図８】
上述の構成が実施されるであろうコンピュータシステムを表す概略ブロック図である。
【図９】
ＸＭＬ文書符号化操作を示すフローチャートである。
【図１０】
符号化操作において様々なデータ型を扱うことができる様子を示すフローチャートである。

Claims

階層表現により記述される文書の構造の少なくとも一部を送受信する方法であって、
前記文書の前記表現を識別するステップと、
前記表現を所定のサイズを有する複数のデータパケットへとパケット化するステップであって、１対の前記パケット間に前記表現の対応するコンポーネント間の相互接続を表す少なくとも１つのリンクを作成することを含むステップと、
前記データパケットから送受信用のストリームを形成するステップと、
を含み、
前記リンクは前記パケット内の前記表現を維持することを特徴とする方法。
前記ストリームを受信するステップと、
前記ストリームから前記パケットを復号化して前記リンクを識別するステップと、
前記ストリームの１つのパケットにパケット化されていない前記表現の部分に関して、前記リンクを使用して前記表現を再現するステップと、
を更に含むことを特徴とする請求項１に記載の方法。
前記対応するコンポーネントは、前記文書の少なくとも１つの構造コンポーネント及び１つの内容コンポーネントを含むことを特徴とする請求項１又は２に記載の方法。
階層表現により記述される文書の構造の少なくとも一部を送受信する方法であって、
前記表現の少なくとも１つの部分を識別し、前記部分を所定サイズの少なくとも１つのパケットへとパケット化するステップと、
前記表現の１つ以上の前記部分が１つの前記パケットに収まらない場合、前記１つのパケットから前記収まらない部分がパケット化されて形成される少なくとも１つの更なる前記パケットまでの少なくとも１つのリンクを定義するステップであって、前記リンクは前記パケット中の前記文書の階層構造を維持するステップと、
を含むことを特徴とする方法。
前記階層表現はツリー表現であることを特徴とする請求項１乃至４のいずれかに記載の方法。
前記文書はＸＭＬ文書であることを特徴とする請求項１乃至５のいずれかに記載の方法。
前記所定サイズは所定の最大サイズであることを特徴とする請求項１乃至６のいずれかに記載の方法。
ＸＭＬ文書の構造へのアクセスを容易にする方法であって、
前記文書の階層表現を識別するステップと、
前記表現を所定パケットサイズの複数のパケットへとパケット化するステップと、
前記パケット間にリンクを形成してパケット内で表現できない前記表現の部分を定義し、それにより、パケット化解除後の前記表現の再現を可能にするステップと、
を含むことを特徴とする方法。
ＸＭＬ文書を符号化する方法であって、
前記ＸＭＬ文書を検査してその一部を形成する各データ型を識別するステップと、
対応する特殊符号化形式が利用可能である前記データ型の第１の集合を識別するステップと、
前記対応する特殊符号化形式を用いて前記第１の集合中のデータ型を有する前記ＸＭＬ文書の各部分を第１に符号化するステップと、
前記ＸＭＬ文書の残りの部分の各々のデータ型に対応するデフォルト符号化形式を用いて前記残りの部分を第２に符号化するステップと、
前記対応する特殊符号化形式を用いて少なくとも前記第１の集合中の前記データ型の各々を参照する情報の表現を形成するステップと、
前記表現を前記ＸＭＬ文書の符号化された形態としての前記符号化された部分と関連付けるステップと、
を含むことを特徴とする方法。
前記符号化は前記ＸＭＬ文書の構造部分及び内容部分を別々に符号化し、前記表現は前記ＸＭＬ文書の前記符号化された形態のヘッダ部分において保持されることを特徴とする請求項９に記載の方法。
前記表現は、前記ヘッダ部分においてテーブルとして保持されることを特徴とする請求項１０に記載の方法。
前記別々に符号化された部分は、少なくとも１つのビットストリームのパケットを含むことを特徴とする請求項１０に記載の方法。
前記第１符号化は、前記特殊データ型及び前記対応する部分を検査し、前記部分に適用される前記符号化形式のうちの１つを判定することを含むことを特徴とする請求項９に記載の方法。
前記符号化は、前記部分のデータ型に対応する複数の前記符号化形式のうちの１つを選択し、前記選択された符号化形式を用いて前記部分を符号化することを含むことを特徴とする請求項９に記載の方法。
符号化されたＸＭＬ文書を復号化する方法であって、
前記符号化されたＸＭＬ文書を検査して前記ＸＭＬ文書の一部を形成する各データ型と関連付けられる符号化形式を識別するステップと、
前記対応するデータ型の符号化の際に使用された前記符号化形式を補足するデコーダを使用して前記部分の各々を復号化するステップと、
を含むことを特徴とする方法。
前記符号化されたＸＭＬ文書は前記ＸＭＬ文書の別々に符号化された構造部分及び内容部分を具備し、前記検査は少なくとも１つの構造部分内から前記ＸＭＬ文書の符号化された部分を前記対応する符号化形式と関連付ける表現を識別することを含むことを特徴とする請求項１５に記載の方法。
前記符号化されたＸＭＬ文書は複数のパケットとして形成され、前記表現は少なくとも１つの前記パケットのヘッダ内に形成されることを特徴とする請求項１６に記載の方法。
前記表現はテーブルを含むことを特徴とする請求項１７に記載の方法。
前記表現はＵＲＩを含むことを特徴とする請求項１６乃至１８のいずれかに記載の方法。
前記表現は、少なくとも対応する復号化形式を有する特殊データ型の集合に関連があることを特徴とする請求項１６に記載の方法。
前記符号化されたＸＭＬ文書の部分を復号化するのにデコーダを利用できない場合、前記部分を無視することを含むことを特徴とする請求項１５に記載の方法。
請求項１乃至１４のいずれかに記載の方法を使用して形成されるパケット化ビットストリーム。
階層表現により記述される文書の構造の少なくとも一部を送受信する装置であって、
前記文書の前記表現を識別する手段と、
前記表現を所定のサイズを有する複数のデータパケットへとパケット化する手段であって、前記パケット化は１対の前記パケット間に前記表現の対応するコンポーネント間の相互接続を表す少なくとも１つのリンクを作成することを含む手段と、
前記データパケットから送受信用のストリームを形成する手段とを具備し、前記リンクは前記パケット内の前記表現を維持する装置。
ＸＭＬ文書を符号化する装置であって、
前記ＸＭＬ文書を検査してその一部を形成する各データ型を識別する手段と、
対応する特殊符号化形式が利用可能である前記データ型の第１の集合を識別する手段と、
前記対応する特殊符号化形式を用いて前記第１の集合中のデータ型を有する前記ＸＭＬ文書の各部分を第１に符号化する手段と、
前記ＸＭＬ文書の残りの部分の各々のデータ型に対応するデフォルト符号化形式を用いて前記残りの部分を第２に符号化する手段と、
前記対応する特殊符号化形式を用いて少なくとも前記第１の集合中の前記データ型の各々を参照する情報の表現を形成する手段と、
前記表現を前記ＸＭＬ文書の符号化された形態としての前記符号化された部分と関連付ける手段とを含む装置。
階層表現により記述される文書の構造の少なくとも一部を送受信する手順をコンピュータに実行させるように構成されるプログラムを記録したコンピュータ可読な媒体であって、前記プログラムは、
前記文書の前記表現を識別するステップと、
前記表現を所定のサイズを有する複数のデータパケットへとパケット化するステップであって、前記パケット化は１対の前記パケット間に前記表現の対応するコンポーネント間の相互接続を表す少なくとも１つのリンクを作成することを含むステップと、
前記データパケットから送受信用のストリームを形成するステップとを具備し、前記リンクは前記パケット内の前記表現を維持するコンピュータ可読な媒体。
前記ストリームを受信するステップと、
前記ストリームから前記パケットを復号化して前記リンクを識別するステップと、
前記ストリームの１つのパケットにパケット化されていない前記表現の部分に関して、前記リンクを使用して前記表現を再現するステップとを更に含むことを特徴とする請求項２５に記載のコンピュータ可読な媒体。
前記対応するコンポーネントは、前記文書の少なくとも１つの構造コンポーネント及び１つの内容コンポーネントを含むことを特徴とする請求項２５又は２６に記載のコンピュータ可読な媒体。
階層表現により記述される文書の構造の少なくとも一部を送受信する手順をコンピュータに実行させるように構成されるプログラムを記録したコンピュータ可読な媒体であって、前記プログラムは、
前記表現の少なくとも１つの部分を識別し、前記部分を所定サイズの少なくとも１つのパケットへとパケット化するステップと、
前記表現の１つ以上の前記部分が１つの前記パケットに収まらない場合、前記１つのパケットから前記収まらない部分がパケット化されて形成される少なくとも１つの更なる前記パケットまでの少なくとも１つのリンクを定義するステップであって、前記リンクは前記パケット中の前記文書の階層構造を維持するステップとを含むコンピュータ可読な媒体。
前記階層表現はツリー表現であることを特徴とする請求項２５乃至２８のいずれかに記載のコンピュータ可読な媒体。
前記文書はＸＭＬ文書であることを特徴とする請求項２５乃至２９のいずれかに記載のコンピュータ可読な媒体。
前記所定サイズは所定の最大サイズであることを特徴とする請求項２５乃至３０のいずれかに記載のコンピュータ可読な媒体。
ＸＭＬ文書の構造へのアクセスを容易にする手順をコンピュータに実行させるように構成されるプログラムを記録したコンピュータ可読な媒体であって、前記プログラムは、
前記文書の階層表現を識別するステップと、
前記表現を所定パケットサイズの複数のパケットへとパケット化するステップと、
前記パケット間にリンクを形成してパケット内で表現できない前記表現の部分を定義し、それにより、パケット化解除後の前記表現の再現を可能にするステップとを含むコンピュータ可読な媒体。
ＸＭＬ文書を符号化する手順をコンピュータに実行させるように構成されるプログラムを記録したコンピュータ可読な媒体であって、前記プログラムは、
前記ＸＭＬ文書を検査してその一部を形成する各データ型を識別するステップと、
対応する特殊符号化形式が利用可能である前記データ型の第１の集合を識別するステップと、
前記対応する特殊符号化形式を用いて前記第１の集合中のデータ型を有する前記ＸＭＬ文書の各部分を第１に符号化するステップと、
前記ＸＭＬ文書の残りの部分の各々のデータ型に対応するデフォルト符号化形式を用いて前記残りの部分を第２に符号化するステップと、
前記対応する特殊符号化形式を用いて少なくとも前記第１の集合中の前記データ型の各々を参照する情報の表現を形成するステップと、
前記表現を前記ＸＭＬ文書の符号化された形態としての前記符号化された部分と関連付けるステップとを含むコンピュータ可読な媒体。
前記符号化は前記ＸＭＬ文書の構造部分及び内容部分を別々に符号化し、前記表現は前記ＸＭＬ文書の前記符号化された形態のヘッダ部分において保持されることを特徴とする請求項３３に記載のコンピュータ可読な媒体。
前記表現は、前記ヘッダ部分においてテーブルとして保持されることを特徴とする請求項３４に記載のコンピュータ可読な媒体。
前記別々に符号化された部分は、少なくとも１つのビットストリームのパケットを含むことを特徴とする請求項３４に記載のコンピュータ可読な媒体。
前記第１符号化は、前記特殊データ型及び前記対応する部分を検査し、前記部分に適用される前記符号化形式のうちの１つを判定することを含むことを特徴とする請求項３３に記載のコンピュータ可読な媒体。
前記符号化は、前記部分のデータ型に対応する複数の前記符号化形式のうちの１つを選択し、前記選択された符号化形式を用いて前記部分を符号化することを含むことを特徴とする請求項３３に記載のコンピュータ可読な媒体。
符号化されたＸＭＬ文書を復号化する手順をコンピュータに実行させるように構成されるプログラムを記録したコンピュータ可読な媒体であって、前記プログラムは、
前記符号化されたＸＭＬ文書を検査して前記ＸＭＬ文書の一部を形成する各データ型と関連付けられる符号化形式を識別するステップと、
前記対応するデータ型の符号化の際に使用された前記符号化形式を補足するデコーダを使用して前記部分の各々を復号化するステップとを含むコンピュータ可読な媒体。
前記符号化されたＸＭＬ文書は前記ＸＭＬ文書の別々に符号化された構造部分及び内容部分を具備し、前記検査は少なくとも１つの構造部分内から前記ＸＭＬ文書の符号化された部分を前記対応する符号化形式と関連付ける表現を識別することを含むことを特徴とする請求項３９に記載のコンピュータ可読な媒体。
前記符号化されたＸＭＬ文書は複数のパケットとして形成され、前記表現は少なくとも１つの前記パケットのヘッダ内に形成されることを特徴とする請求項４０に記載のコンピュータ可読な媒体。
前記表現はテーブルを含むことを特徴とする請求項４１に記載のコンピュータ可読な媒体。
前記表現はＵＲＩを含むことを特徴とする請求項４０乃至４２のいずれかに記載のコンピュータ可読な媒体。
前記表現は、少なくとも対応する復号化形式を有する特殊データ型の集合に関連があることを特徴とする請求項４３に記載のコンピュータ可読な媒体。
前記符号化されたＸＭＬ文書の部分を復号化するのにデコーダを利用できない場合、前記方法は前記部分を無視することを含むことを特徴とする請求項４４に記載のコンピュータ可読な媒体。
階層表現により記述される文書の構造の少なくとも一部を送受信する装置であって、
前記文書の前記表現を識別する識別部と、
前記表現を所定のサイズを有する複数のデータパケットへとパケット化するパケット化部であって、前記パケット化は１対の前記パケット間に前記表現の対応するコンポーネント間の相互接続を表す少なくとも１つのリンクを作成することを含むパケット化部と、
前記データパケットから送受信用のストリームを形成する形成部とを具備し、前記リンクは前記パケット内の前記表現を維持する装置。
ＸＭＬ文書を符号化する装置であって、
前記ＸＭＬ文書を検査してその一部を形成する各データ型を識別する検査部と、
対応する特殊符号化形式が利用可能である前記データ型の第１の集合を識別する識別部と、
前記対応する特殊符号化形式を用いて前記第１の集合中のデータ型を有する前記ＸＭＬ文書の各部分を符号化する第１符号化部と、
前記ＸＭＬ文書の残りの部分の各々のデータ型に対応するデフォルト符号化形式を用いて前記残りの部分を符号化する第２符号化部と、
前記対応する特殊符号化形式を用いて少なくとも前記第１の集合中の前記データ型の各々を参照する情報の表現を形成する形成部と、
前記表現を前記ＸＭＬ文書の符号化された形態としての前記符号化された部分と関連付ける関連付け部とを含む装置。
図面を参照して本明細書に記載したのとほぼ同様の階層表現により記述される文書を符号化する方法。
図面を参照して本明細書に記載したのとほぼ同様の階層表現を組み込むパケット化ストリームを復号化する方法。
図面を参照して本明細書に記載したのとほぼ同様の階層表現を使用して記述される文書を送受信する方法。
請求項４８乃至５０のいずれかに記載の方法を実行する装置。
請求項４８乃至５０のいずれかに記載の方法を実行するコンピュータプログラムを記録したコンピュータ可読な媒体。