(57)【要約】【課題】構造化文書の利点である可読性を保ったまま圧縮を行ない構造化文書のデータ量を削減する。また、構造化文書内に含まれるデータへアクセスする際の処理の負荷を軽減する。【解決手段】同じ文法規則に従う複数の構造化文書を圧縮することを前提とし、文法規則と構造化文書に含まれる情報をノードＩＤに関連付けて符号化する。符号化された構造化文書から文法規則で規定された情報を取り除くことで、符号化コンテンツを生成する。ノードＩＤを参照することで、符号化コンテンツに含まれるデータへ容易にアクセスすることが可能となる。高い圧縮率で構造化文書の圧縮を行なうことができる。また、データアクセスする際の処理の負荷を軽減することができる。【選択図】  図１
2004342029.tif 000002
【特許請求の範囲】
【請求項１】
情報処理システムにおいて扱われる文書構造定義言語で記述された構造化文書において、同じ文法規則に従う複数の前記構造化文書を圧縮する方法であって、前記文法規則の規定するノードに対してノードＩＤを付与し、前記文法規則の規定する前記ノードに関する情報を文法規則ＩＤ付与部によって付与された前記ノードＩＤと関連付け符号化文法規則を生成し、圧縮対象の前記構造化文書を構成する前記ノードに関する情報を前記文法規則ＩＤ付与部によって付与された前記ノードＩＤと関連付け符号化文書を生成し、前記構造化文書符号化部によって生成された符号化文書から符号化文法規則で規定されていない情報を分離し符号化コンテンツを生成することを特徴とするデータ圧縮方法。
【請求項２】
請求項１において、前記構造化文書を構成する前記ノードと前記符号化文法規則の規定する前記ノードが一対一に対応していない場合には、前記文法規則ＩＤ付与部によって付与された前記ノードＩＤを参照しながら新たに圧縮対象の前記構造化文書を構成する前記ノードに対して前記ノードＩＤを付与することを特徴とするデータ圧縮方法。
【請求項３】
請求項１または請求項２によって生成された前記符号化コンテンツから圧縮前の前記構造化文書を復元する解凍方法であって、前記符号化コンテンツと前記符号化文法規則とを結合し前記符号化文書を生成し、前記符号化文書を復号化し圧縮前の前記構造化文書を生成することを特徴とするデータ解凍方法。
【請求項４】
請求項１または請求項２によって生成された前記符号化コンテンツからバイナリデータを生成する変換方法であって、前記符号化コンテンツを前記文法規則ＩＤ付与部または前記構造化文書ＩＤ付与部によって付与された前記ノードＩＤとバイナリデータにおける変数名との関係を示したノードＩＤ対応表を用いてバイナリデータに変換することを特徴とするデータ変換方法。
【請求項５】
請求項４において、前記構造化文書のノードとバイナリデータにおける変数名との対応関係を示したノード対応表から前記ノードＩＤ対応表を生成することを特徴とするデータ変換方法。
【請求項６】
同じ文法規則に従う複数の構造化文書を圧縮する装置であって、文法規則の規定するノードに対してノードＩＤを付与する手段と、前記文法規則の規定する前記ノードに関する情報を前記文法規則ＩＤ付与部によって付与された前記ノードＩＤと関連付け符号化文法規則を生成する手段と、圧縮対象の前記構造化文書を構成する前記ノードに関する情報を前記文法規則ＩＤ付与部によって付与された前記ノードＩＤと前記関連付け符号化文書を生成する手段と、前記構造化文書符号化部によって生成された前記符号化文書から前記符号化文法規則で規定されていない情報を分離する手段とを有することを特徴とするデータ圧縮装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ＸＭＬ等の構造化文書の圧縮、解凍に係わる技術及び圧縮されたデータへのアクセスに係わる技術に関する。
【０００２】
【従来の技術】
近年、構造化文書が注目を集めており、様々なデータのフォーマットとして構造化文書が用いられている。特にＷ３Ｃ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ）が勧告しているマークアップ言語の一つであるＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）は、各種プログラムの設定ファイルなど階層構造を持ったデータのフォーマットとして使用されるほか、インターネット上のデータ交換の際の標準的なデータフォーマットとしても使用されている。
【０００３】
ＸＭＬ文書には、構造化データを容易に表現できる、テキストデータであるため可読性があるといった利点がある。しかしその一方で、ＸＭＬ文書には処理効率が悪いという欠点がある。ＸＭＬ文書は冗長な記述が多いためデータ量が大きくなる。また、ＸＭＬ文書内のデータにアクセスするには、ＸＭＬ文書の構造解析を行ない、木構造からデータを検索しなくてはならい。この処理は負荷が大きく処理に時間がかかる。
【０００４】
ＸＭＬ文書のデータ量が大きいと、通信時の通信コストや保存に必要な記憶容量が増大する。そこで、ＸＭＬ文書を圧縮しデータ量を小さくすることが考えられる。データ圧縮には様々な方法が知られているが、Ｈｕｆｆｍａｎ符号、ＬＺ７７など、あらゆる種類のデータを圧縮できるユニバーサル圧縮が広く用いられている。ＸＭＬ文書に対しても、これらのユニバーサル圧縮を適用することで高い圧縮効果が期待できる。しかし、これらの方法によって圧縮したデータはバイナリデータとなるため、ＸＭＬ文書の利点である可読性が失われてしまう。また、圧縮結果に含まれるデータにアクセスするには、解凍処理を行ない圧縮前のＸＭＬ文書に復元した上で、さらにＸＭＬ文書の構造解析、木構造の検索を行なわなければならず、ＸＭＬ文書の欠点であるデータアクセスの負荷がより増大することになる。
【０００５】
ユニバーサル圧縮を用いずとも、ＸＭＬ文書の持つ冗長性を排除することで、テキストデータのままＸＭＬ文書の圧縮を行なうことが可能である。たとえば、類似性を持つ複数のＸＭＬ文書を扱うことを前提とすると、各ＸＭＬ文書から、全てのＸＭＬ文書に共通している情報を取り除くことでデータ量を削減することが可能である。
【０００６】
特開２００２−１６３２４８（特許文献１）では、複数のＸＭＬ文書が同じ構造を持つことを前提とし、各ＸＭＬ文書を構造とコンテンツに分離する。ここで、ＸＭＬ文書の構造とは、ＸＭＬ文書に含まれる要素ノードの名前と属性ノードの名前のことをいう。また、ＸＭＬ文書のコンテンツとは、ＸＭＬ文書に含まれるテキストノードの値と属性ノードの値のことをいう。圧縮結果としては、ひとつの構造と複数のコンテンツを出力する。解凍処理の際には、構造とコンテンツとから圧縮前のＸＭＬ文書を復元するが、構造は複数のＸＭＬ文書において共通のものを使用することができるためひとつだけ用意しておけばよい。上述したように、特許文献１ではＸＭＬ文書の構造部分は複数の文書において共通でありコンテンツは個々の文書ごとに異なるものとする。特許文献１において構造とはＸＭＬ文書に含まれる要素ノードの名前と属性ノードの名前のことをいい、コンテンツとはテキストノードの値と属性ノードの値のことをいう。従って、もしテキストノードの値や属性ノードの値が圧縮対象の複数のＸＭＬ文書で共通であったとしても、これらは構造ではなくコンテンツとして扱われるため圧縮効果がない。また逆に、要素名や属性名が文書毎に異なる場合には、構造が一定でなくなるため特許文献１の方法を適用することはできない。
【０００７】
特開２００１−２１７７２０（特許文献２）では、複数のＸＭＬ文書が同じ文法規則に従うことを前提としている。ここで、文法規則とは、ＸＭＬ文書に出現するノードの名前、値、出現回数、出現順序等を規定した規則のことをいい、ＤＴＤ（Ｄｏｃｕｍｅｎｔ  Ｔｙｐｅ  Ｄｅｆｉｎｉｔｉｏｎ）などを用いて記述される。特許文献２では、複数のＸＭＬ文書が同じ文法規則に従っていれば個々のＸＭＬ文書の構造が同じである必要はない。圧縮の際には、圧縮対象のＸＭＬ文書を構造とコンテンツに分離した後、文法規則から生成したプッシュダウンオートマトンを用いて構造を番号列に符号化する。解凍処理の際は、文法規則から生成したプッシュダウンオートマトンを用いて番号列から構造部分を復号化し、コンテンツと組み合わせることで圧縮前のＸＭＬ文書を復元する。ここで、特許文献２は同じ文法規則に従うことを前提としているので、要素名や属性名が文書毎に異なっていても、それらのノードが全て文法規則で規定されていれば、この方法を適用することができる。ただし、文法規則で規定されていないノードがＸＭＬ文書に出現する場合は、この方法を適用することができない。例えば、コメントノードは通常文法規則では規定されておらず、この方法はコメントノードを含むＸＭＬ文書に対して適用することができない。また、特許文献２には、文法規則によっては圧縮効率が悪くなる、属性ノードを含むＸＭＬ文書に適用する場合は属性ノードを要素ノードに変換しなくてはならないなどといった問題点もある。
また、特許文献１、特許文献２の共通の問題点として、圧縮結果内に含まれるデータにアクセスする処理の負荷が大きいといった点が挙げられる。特許文献１、特許文献２とも、圧縮結果として出力されるコンテンツはテキストデータであるため可読性がある。しかし、コンテンツは単にテキストノードの値、属性ノードの値を連結したものであり、これだけではそれらのデータが何を意味するのかは分からない。解凍処理によってＸＭＬ文書を復元し、そのデータがＸＭＬ文書のどの部分に記述されているのかを見て初めてデータの意味を知ることができる。よって、これらの方法で圧縮を行なった場合、圧縮結果に含まれるデータにアクセスするには、事前に解凍処理によってＸＭＬ文書を復元しなくてはならず、ＸＭＬ文書の欠点のひとつであるデータアクセスの負荷は軽減されない。
【０００８】
【特許文献１】
特開２００２−１６３２４８（第４−５頁、第００１５−００２６段落）
【特許文献２】
特開２００１−２１７７２０（第４−５頁、第００１０−００２２段落）
（ヨーロッパ特許庁  ＥＰ１１２２６５５Ａ２）
【０００９】
【発明が解決しようとする課題】
本発明の目的は、上記に挙げた従来技術の問題点を解決する新しい構造化文書の圧縮方法を提供することにある。すなわち第１の目的は、圧縮効率が高く、かつ様々なＸＭＬ文書、例えば文法規則で規定されていないノードが出現するようなＸＭＬ文書、に適用可能な圧縮方法を提供することにある。また、本発明の第２の目的は、圧縮された結果内に含まれるデータへ高速にアクセスする方法を提供することにある。
【００１０】
【課題を解決するための手段】
本発明における圧縮プログラムは、文法規則ＩＤ付与部と文法規則符号化部と構造化文書ＩＤ付与部と構造化文書符号化部と分離部とを備える。文法規則ＩＤ付与部は、文法規則の規定するノードに対して各ノードを一意に識別することのできるノードＩＤを付与する。文法規則符号化部は、文法規則の規定する各ノードに関する情報を前記文法規則ＩＤ付与部によって付与されたノードＩＤと関連付け、符号化文法規則を生成する。構造化文書ＩＤ付与部は、前記文法規則ＩＤ付与部によって付与されたノードＩＤを参照しながら、圧縮対象の構造化文書を構成するノードに対して、各ノードを一意に識別することのできるノードＩＤを付与する。文法規則で規定されたノードと構造化文書を構成するノードが一対一に対応する場合には、構造化文書を構成するノードのＩＤと文法規則の規定するノードのＩＤが同一になるため、構造化文書ＩＤ付与における処理は不要である。構造化文書符号化部は、圧縮対象の構造化文書を構成する各ノードに関する情報を前記構造化文書ＩＤ付与部によって付与されたＩＤと関連付け、符号化文書を生成する。分離部は符号化文書の内容から、符号化文法規則に記述されている内容を取り除くことで符号化コンテンツを生成する。
【００１１】
符号化コンテンツは、圧縮対象の構造化文書から文法規則で規定された情報を取り除いたものであり、圧縮対象の構造化文書よりもデータ量が小さくなることが期待できる。よって、本発明をデータ通信時のデータ圧縮に用いる場合、符号化文法規則を一度だけ送信し、その後は文書毎に符号化コンテンツだけを送信すればよい。これにより通信コストを削減することができる。また、本発明をデータ保存時のデータ圧縮に用いる場合、符号化文法規則をひとつだけ保存し、その後は文書毎に符号化コンテンツだけを保存すればよい。これにより、保存に必要な記憶容量を削減することができる。
【００１２】
また、本発明の解凍プログラムは、結合部と復号化部とを備える。結合部は、符号化文法規則と符号化コンテンツを結合し符号化文書を生成する。復号化部は、符号化文書を復号化し圧縮前の構造化文書を復元する。
【００１３】
また、本発明の変換プログラムは変換部とバイナリデータ生成部とを備える。変換部は、あらかじめ用意された構造化文書のノードとバイナリデータの変数との対応関係を示したノード対応表を、上述した圧縮プログラム内の構造化文書ＩＤ付与部によって付与されたノードＩＤとバイナリデータの変数名との対応関係を示したノードＩＤ対応表に変換する。バイナリデータ生成部は、ノードＩＤ対応表と上述した圧縮プログラムによって生成される符号化コンテンツから、バイナリデータを生成する。符号化コンテンツでは、各ノードの情報がノードＩＤに関連付けられている。よって、ノードＩＤ対応表を参照することで符号化コンテンツからバイナリデータへ変換することが可能になる。この方法を用いるとことで、符号化コンテンツを圧縮前の構造化文書に復元する必要がなくなり、データアクセスの処理を軽減することができる。
【００１４】
【発明の実施の形態】
以下、図面を参照しながら本発明の実施形態を説明する。各実施形態では、圧縮対象の構造化文書としてＸＭＬ文書を用いる場合を例にとり説明する。
〔１〕第１実施形態の説明
以下では、本発明の第１実施形態について説明する。図１は本実施形態における圧縮プログラム及び解凍プログラムを、データ通信時のデータ圧縮に用いる場合のシステム全体の構成を示す図である。図１では、ネットワーク１０３を介してデータが送信側計算機１０１から受信側計算機１０２に送信される。この場合、圧縮プログラム１１５はデータの送信側計算機１０１内に置かれ、解凍プログラム１２０はデータの受信側計算機１０２内に置かれる。圧縮プログラム１１５は、文法規則ＩＤ付与部１２１と、文法規則符号化部１２２と、構造化文書ＩＤ付与部１２３と、構造化文書符号化部１２４と、分離部１２５とを備える。なお後述するように、圧縮プログラム１１５は必ずしも構造化文書ＩＤ付与部１２３を備えていなくてもよい。本実施形態における圧縮処理は、記憶装置１１４内に格納されている圧縮プログラム１１５が、メモリ１１３に読み込まれ、ＣＰＵ１１２によって実行されることにより実現される。圧縮されたデータは、送信側計算機１０１内の通信装置１１１によってネットワーク上に送信され、受信側計算機１０２内の通信装置１１６によって受信される。解凍プログラム１２０は、結合部１２６と、復号化部１２７とを備える。本実施形態における解凍処理は、記憶装置１１９内に格納されている解凍プログラム１２０が、メモリ１１８に読み込まれ、ＣＰＵ１１７によって実行されることにより実現される。
【００１５】
図２は、本実施形態における圧縮プログラム及び解凍プログラムを、データ保存時のデータ圧縮に用いる場合のシステム全体の構成を示す図である。この場合、圧縮プログラム１１５及び解凍プログラム１２０はＸＭＬ文書処理システム２０１内に置かれる。圧縮プログラム１１５によって圧縮されたデータは、データベース２１４に保存される。データベース２１４に保存されたデータは、解凍プログラム１２０によって解凍され、圧縮前のＸＭＬ文書に復元される。圧縮プログラム１１５と解凍プログラム１２０の内部構造は、図１に示したものと同じである。本実施形態における圧縮処理と解凍処理は、記憶装置２１３内に格納されている圧縮プログラム１１５と解凍プログラム１２０が、メモリ２１２に読み込まれ、ＣＰＵ２１１によって実行されることにより実現される。
【００１６】
次に、本実施形態における圧縮プログラム１１５について説明する。図３は、本実施形態における圧縮プログラム１１５の機能構成を示す図である。図４は、本実施形態における圧縮処理の手順を示す図である。圧縮プログラム１１５は、圧縮対象であるＸＭＬ文書３０２と、文法規則３０１とを入力とし、符号化文法規則３０３と符号化コンテンツ３０５を出力する。符号化文法規則３０３は、同じ文法規則に従うＸＭＬ文書圧縮時には共通のものを使用することができる。よって同じ文法規則に従うＸＭＬ文書圧縮時には、符号化文法規則３０３の出力に関する処理のステップ４０２、４０３、４０４は最初の一度だけ行なえばよく、すでに符号化文法規則３０３が存在する場合はこれらの処理を省略することができる。符号化文法規則３０３が存在しない場合、まず文法規則３０１が文法規則ＩＤ付与部１２１に入力され、文法規則３０１が規定するノードに対しＩＤが付与される（ステップ４０２）。次に、文法規則符号化部１２２において後述する符号化ルールに従い文法規則３０１が符号化され（ステップ４０３）、符号化文法規則３０３が出力される（ステップ４０４）。ステップ４０１において、すでに文法規則が存在している場合は以上の処理を省略し既存の符号化文法規則を入力し（ステップ４０５）、これを使用する。次に、圧縮対象であるＸＭＬ文書３０２が構造化文書ＩＤ付与部１２３に入力され、ＸＭＬ文書を構成するノードに対しＩＤが付与される（ステップ４０６）。後述するように文法規則３０１によって規定されるノードとＸＭＬ文書３０２を構成するノードが一対一に対応する場合は、ＩＤ付与処理のステップ４０６を省略することができる。ＩＤ付与処理のステップ４０６を省略する場合、圧縮プログラム１１５は、構造化文書ＩＤ付与部１２３を備えていなくてもよい。次に、構造化文書符号化部１２４において後述する符号化ルールに従い、ＸＭＬ文書が符号化され（ステップ４０７）、符号化文書３０４が生成される。次に、分離部１２５において符号化文書３０４からコンテンツが分離され（ステップ４０８）、符号化コンテンツ３０５が出力される（ステップ４０９）。本実施形態では、文法規則の規定するノードへのＩＤ付与（ステップ４０２）が完了した後に文法規則の符号化（ステップ４０３）を行なっているが、ＩＤ付与（ステップ４０２）の処理を行ないながら同時に文法規則の符号化（ステップ４０３）を行なってもよい。同様に、本実施形態ではＸＭＬ文書を構成するノードへのＩＤ付与（ステップ４０６）が完了した後にＸＭＬ文書の符号化（ステップ４０７）を行なっているが、ＩＤ付与の処理（ステップ４０６）を行いながら同時にＸＭＬ文書の符号化（ステップ４０７）を行なってもよい。
【００１７】
後述するように、符号化文法規則３０３と符号化コンテンツ３０５を解凍プログラム１２０に入力することで圧縮前のＸＭＬ文書３０２を復元することができる。同じ文法規則に従うＸＭＬ文書の解凍処理の際には、符号化文法規則３０３は共通のものを使用できため、本実施形態を図１に示すようなデータ通信時のデータ圧縮に用いる場合、送信側計算機１０１から受信側計算機１０２に符号化文法規則３０３を一度だけ送信し、その後は文書毎に符号化コンテンツ３０５だけを送信すればよい。符号化コンテンツ３０５は、後述するようにＸＭＬ文書３０２よりもデータ量が小さくなることが期待できる。よって本実施形態を用いることにより通信時間を短縮することができ、結果として通信コストを削減することができる。あらかじめ送信側計算機１０１と受信側計算機１０２で文法規則３０１を共有している場合は、符号化文法規則３０３を送信せずに、受信側計算機１０２内で符号化文法規則３０３を生成してもよい。また、本実施形態を図２に示すようなデータ保存時のデータ圧縮に用いる場合、符号化文法規則３０３をひとつだけ保存し、その後は文書毎に符号化コンテンツ３０５だけを保存すればよい。これにより、保存に必要な記憶容量を削減することができる。
【００１８】
以下では、図５に示すＸＭＬ文書を例に取り、本実施形態の各部における処理の詳細を説明する。図５の各行の先頭に記述してある数字は行番号を示すものであり、実際のＸＭＬ文書には含まれない。以下で示す文法規則、符号化文法規則、符号化文書、符号化コンテンツでも同様に行番号を挿入してある。また、図５に示すＸＭＬ文書では、読みやすくするために空白スペース、改行を挿入してあるが、実際のＸＭＬ文書には空白スペース、改行は含まれないものとする。
一般にＸＭＬ文書は複数のノードから構成される。ノードには様々な種類があり、例えばＷ３Ｃ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ）が勧告しているＸＭＬ文書処理のためのＡＰＩであるＤＯＭ（Ｄｏｃｕｍｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ）の構造モデルでは、Ｄｏｃｕｍｅｎｔ、Ｄｏｃｕｍｅｎｔ  Ｆｒａｇｍｅｎｔ、Ｄｏｃｕｍｅｎｔ  Ｔｙｐｅ、Ｅｎｔｉｔｙ  Ｒｅｆｅｒｅｎｃｅ、Ｅｌｅｍｅｎｔ、Ａｔｔｒ、Ｐｒｏｃｅｓｓｉｎｇ  Ｉｎｓｔｒｕｃｔｉｏｎ、Ｃｏｍｍｅｎｔ、Ｔｅｘｔ、ＣＤＡＴＡ  Ｓｅｃｔｉｏｎ、Ｅｎｔｉｔｙ、Ｎｏｔａｔｉｏｎの１２種類のノードタイプを定義している。本実施形態の説明では、代表的なノードタイプであるＥｌｅｍｅｎｔ、Ａｔｔｒ、Ｔｅｘｔ、Ｃｏｍｍｅｎｔについて扱うが、他のノードタイプについても同様の方法で処理することが可能である。以下では、ノードタイプがＥｌｅｍｅｎｔのノードを要素ノード、  Ａｔｔｒのノードを属性ノード、Ｔｅｘｔのノードをテキストノード、Ｃｏｍｍｅｎｔのノードをコメントノードと書く。
【００１９】
図６は、図５に示すＸＭＬ文書を構成する各ノードのタイプ、名前、値及び各ノード間の親子関係を示した図である。図６において、符号６０１、６０２、６０３、６０４、６０５、６０６、６０７、６０８、６０９はそれぞれひとつのノードを示しており、各ノードを示す表の１行目にはノードタイプ、２行目にはノードの名前、３行目にはノードの値が示してある。なお本発明の各実施形態では、ノードタイプを記述するのに、要素ノードは“−”、属性ノードは“＠”、テキストノードは“＃”、コメントノードは“！”といった省略記号を用いる。
【００２０】
図６において、線で結ばれたノードには親子関係があることを示す。２つのノードが線で結ばれている場合、上側に位置するノードが親ノードであり、下側に位置するノードが子ノードである。ＤＯＭの構造モデルでは属性ノードは要素ノードの子ノードに含まれないとされるが、ここでは属性ノードも要素ノードの子ノードに含めるものとする。同じ親ノードを持つノードの集合を兄弟ノードという。図６において、ノードの水平方向の位置が、兄弟ノード内におけるＸＭＬ文書での出現順を示す。すなわち兄弟ノードにおいて左側に位置するノードの方がＸＭＬ文書での出現順が先であり、右側に位置するノードの方が、出現順が後であることを示す。また、要素ノードは値を持たないものとし、テキストノード、コメントノードは名前を持たないものとする。また、ＸＭＬ文書の最上位に位置する要素ノードをルート要素という。図６において、ルート要素であるＯｒｄｅｒ要素６０１は、その子ノードとして属性ノードであるｘｍｌｎｓ属性６０２、コメントノード６０３、要素ノードであるＮａｍｅ要素６０４、要素ノードであるＩｔｅｍ要素６０５、６０６を持つ。Ｎａｍｅ要素６０４は値がＪｏｈｎであるテキストノード６０７を子要素として持つ。Ｉｔｅｍ要素６０５は値がｐｅｎであるテキストノード６０８を子要素として持ち、Ｉｔｅｍ要素６０６は値がｎｏｔｅであるテキストノード６０９を子要素として持つ。図６において、Ｏｒｄｅｒ要素６０１、Ｎａｍｅ要素６０４、Ｉｔｅｍ要素６０５、６０６を示す表の３行目に斜線が引いてあるのは、これらのノードが値を持たないことを表わす。また、コメントノード６０３、テキストノード６０７、６０８、６０９を示す表の２行目に斜線が引いてあるのは、これらのノードが名前を持たないことを表わす。
【００２１】
次に、本実施形態における文法規則３０１について説明する。本実施形態において、文法規則とはＸＭＬ文書を構成するノードのタイプ、名前、値、ノード間の親子関係を規定した規則のことをいう。以下では、文法規則３０１の記述方法としてＤＴＤを用いた場合を例にとり各実施形態の詳細を説明する。文法規則３０１は必ずしもＤＴＤを用いて記述する必要はなく、ＸＭＬ文書に出現するノードのタイプ、名前、値、ノード間の親子関係を規定していればどのような記述方法を用いてもよい。
【００２２】
以下では、文法規則３０１の例として図７に示すＤＴＤを用いて、本実施形態の各部における処理の詳細を説明する。図７に示す文法規則の１行目の符号７０１は、ＸＭＬ文書においてＯｒｄｅｒ要素が子ノードとしてＮａｍｅ要素をひとつだけ持つことを表す。符号７０２は、Ｏｒｄｅｒ要素がＮａｍｅ要素の後に子ノードとしてＴｅｌ要素を０個または１個持つことを表わす。記号“？”がこのノードの出現回数が０回または１回であることを示す。符号７０３は、Ｏｒｄｅｒ要素が、Ｔｅｌ要素が存在するならばＴｅｌ要素の後に、Ｔｅｌ要素が存在しないのならばＮａｍｅ要素の後に子ノードとしてＩｔｅｍ要素を１個以上持つことを表わす。記号“＋”がこのノードの出現回数が１回以上であることを示す。図７の２行目は、Ｎａｍｅ要素が子ノードとしてテキストノードを持つことを表わす。本文法規則では、Ｎａｍｅ要素の子ノードであるテキストノードがどのような値を持つかについては規定しておらず、任意のテキストデータを値として持つことができることを表わす。同様に、図７の３行目、４行目は、それぞれＴｅｌ要素、Ｉｔｅｍ要素が子ノードとしてテキストノードを持ち、該テキストノードは任意のテキストデータを値として持つことができる。図７の５行目は、Ｏｒｄｅｒ要素がｘｍｌｎｓ属性を持ち、ｘｍｌｎｓ属性の値が必ず固定値“ｈｔｔｐ：／／ｓａｍｐｌｅ．ｃｏｍ／ｏｒｄｅｒ”であることを表す。図５に示すＸＭＬ文書は、図７に示す文法規則従って記述されたものである。
【００２３】
図８は、図７に示す文法規則が規定している各ノードのタイプ、名前、値及び各ノード間の関係を示した図である。図８において、テキストノード８０６、８０７、８０８を示す表の３行目が空欄になっているのは、これらのノードの値が文法規則では規定されておらず、ＸＭＬ文書において任意の値を取ることができることを示している。
【００２４】
上述したように、ＸＭＬ文書は複数のノードから構成され、各ノードは、タイプ、名前、値の情報を持つ。ＸＭＬ文書を構成する各ノードの情報と、各ノードの親子関係、各ノードの出現順序がわかれば、ＸＭＬ文書を一意に特定することができる。本発明の各実施形態において、ＸＭＬ文書の構造とは、ＸＭＬ文書を構成する各ノードの情報のうち、文法規則で規定されているもののことをいう。また、ＸＭＬ文書のコンテンツとは、ＸＭＬ文書を構成する各ノードの情報のうち、文法規則で規定されていないもののことをいう。よって、図６に示した符号を用いると図５に示すＸＭＬ文書において、構造とは６０１のノードのタイプ“−”、名前“Ｏｒｄｅｒ”と、６０２のノードのタイプ“＠”、名前“ｘｍｌｎｓ”、値“ｈｔｔｐ：／／ｓａｍｐｌｅ．ｃｏｍ／ｏｒｄｅｒ”と、６０４のノードのタイプ“−”、名前“Ｎａｍｅ”と、６０５、６０６のノードのタイプ“−”、名前“Ｉｔｅｍ”と、６０７、６０８、６０９のノードのタイプ“＃”とのことをいう。また、図５に示すＸＭＬ文書においてコンテンツとは、６０３のノードのタイプ“！”、値“ｃｏｍｍｅｎｔ”と、６０７のノードの値“Ｊｏｈｎ”と、６０８のノードの値“ｐｅｎ”と、６０９のノードの値“ｎｏｔｅ”のことをいう。
【００２５】
次に、本実施形態におけるノードＩＤ付与の処理について説明する。本実施形態では、文法規則ＩＤ付与部１２１と構造化文書ＩＤ付与部１２３によって、ＩＤ付与の処理が行なわれる。本実施形態におけるノードＩＤには、ローカルＩＤとグローバルＩＤの２種類がある。以下では、ローカルＩＤのことをＬＩＤ、グローバルＩＤのことをＧＩＤと書く。ＬＩＤとは、任意のノードを兄弟ノード内から一意に識別できるような値をいう。ＧＩＤとは、ＩＤ付与の対象ノード内から任意のノードを一意に識別できるような値をいう。本実施形態では、ルート要素のＬＩＤ、ＧＩＤを共に“１”とし、その他のノードについては親ノードのＧＩＤ、区切り文字“／”、該ノードのＬＩＤを連結した値をＧＩＤとする。このような方法でＧＩＤを付与することにより、ＩＤ付与の対象ノード内のノードを一意に識別できるだけでなく、ＧＩＤによってノード間の関係を記述することも可能となる。例えば、ＧＩＤが“１”であるノードとＧＩＤが“１／３”であるノードがあった場合には、前者が後者の親ノードであることが分かる。ＩＤ付与の対象ノード内のノードを一意に識別でき、ノード間の親子関係も記述できる方法であれば、他の方法を用いてＧＩＤを付与してもよい。
【００２６】
次に、文法規則ＩＤ付与部１２１におけるＩＤ付与の処理について説明する。文法規則ＩＤ付与部１２１は、文法規則３０１が規定する各ノードに対しＬＩＤをひとつずつ付与する。すなわち、図８に示す全てのノード８０１、８０２、８０３、８０４、８０５、８０６、８０７、８０８に対してそれぞれひとつのＬＩＤを付与する。本実施形態では、ＬＩＤとして兄弟ノード内における出現順に従って１から順に数字を付与していく。兄弟ノード内で一意となる値であれば、他の方法を用いてＬＩＤを付与してもよい。Ｔｅｌ要素８０４はＸＭＬ文書に出現しない可能性もあるが、文法規則には記述されているためひとつのＬＩＤを付与する。また、Ｉｔｅｍ要素８０５はＸＭＬ文書において複数回出現する可能性があるが、文法規則３０１における記述が１回なのでひとつのＬＩＤを付与する。各ノードにＬＩＤが付与されれば、各ノードのＧＩＤも一意に決まる。図９は、文法規則ＩＤ付与部１２１によって図７に示す文法規則が規定するノードにＩＤを付与した結果を示す。図９に示した各ノードを示す表は、１行目がノードタイプを示し、２行目がノードの名前を示し、３行目がノードの値を示し、４行目がＬＩＤを示し、５行目がＧＩＤを示す。ルート要素であるＯｒｄｅｒ要素９０１は、ＬＩＤ、ＧＩＤともに“１”となる。ｘｍｌｎｓ属性９０２、Ｎａｍｅ要素９０３、Ｔｅｌ要素９０４、Ｉｔｅｍ要素９０５の４つのノードは、Ｏｒｄｅｒ要素９０１を親ノードに持つ兄弟ノードである。そこで、兄弟ノード内での出現順に従ってｘｍｌｎｓ属性に“１”、Ｎａｍｅ要素に“２”、Ｔｅｌ要素に“３”、Ｉｔｅｍ要素に“４”のＬＩＤを付与する。ＧＩＤは、親要素であるＯｒｄｅｒ要素のＧＩＤ“１”と、各ノードのＬＩＤを区切り文字“／”を用いて連結した値となる。よってＧＩＤは、ｘｍｌｎｓ属性が“１／１”、Ｎａｍｅ要素が“１／２”、Ｔｅｌ要素が“１／３”、Ｉｔｅｍ要素が“１／４”となる。Ｎａｍｅ要素９０３は子要素としてテキストノード９０６をひとつだけ持つ。よってテキストノード９０６にはＬＩＤとして“１”、ＧＩＤとして“１／２／１”を付与する。同様にして、テキストノード９０７には、ＬＩＤとして“１”、ＧＩＤとして“１／３／１”を付与し、テキストノード９０８には、ＬＩＤとして“１”、ＧＩＤとして“１／４／１”を付与する。
【００２７】
次に、本実施形態におけるノードの符号化ルールについて説明する。以下で述べる符号化ルールは、文法規則符号化部１２２、構造化文書符号化部１２４、分離部１２５で適用される。本符号化では、符号化対象のノードに含まれる全てのノードに対し、ＸＭＬ文書における出現順に従い順番に符号化を行なう。各ノードの符号化では、ノードのタイプ、名前、値をノードのＧＩＤに関連付けて記述する。本実施形態では、ノードのＧＩＤ、ノードタイプ、ノードのタイプ、区切り文字“＝”、ノードの値を連結し一行に記述することで、ひとつのノードの符号化を行なうものとする。ノード間の区切りは改行コードにより識別する。ノードのタイプ、名前、値をノードのＧＩＤに関連付けて記述するのであれば、他の方法を用いて符号化を行なってもよい。符号化された結果のデータにおいて、ノードのタイプ、名前、値の全てが記述されている必要はない。例えば、要素ノードは値を持たないため、要素ノードを符号化する場合は、ノードの値は省略する。各部における符号化処理の詳細については後述する。このように、ノードに関する情報を省略して記述することを認めることで、後述するようにＸＭＬ文書を文法規則とコンテンツに分離することが可能になる。また、以下では圧縮効率を高めるため、ノードの値を省略する場合は区切り文字“＝”も一緒に省略するものとする。ノードの値を省略する場合は、区切り文字“＝”を省略してもノードの各情報の区切りが曖昧になることはない。
【００２８】
以下では、文法規則符号化部１２２における符号化処理について説明する。文法規則符号化部１２２は、文法規則３０１が規定するノードの情報に対して、上述した符号化ルールを用いて符号化を行なう。符号化の際に用いるＧＩＤは、文法規則ＩＤ付与部１２１によって付与された値を用いる。図１０は、文法規則符号化部１２２によって図７に示す文法規則を符号化した結果である。図１０の１行目は、ＧＩＤが“１”であるノードが要素ノードであり、このノードの名前がＯｒｄｅｒであることを表す。ＧＩＤが“１”であることから、このノードがルート要素であることが分かる。要素ノードは値を持たないため、“＝”記号及びノードの値は省略してある。図１０の２行目は、ＧＩＤが“１／１”であるノードが属性ノードであり、このノードの名前が“ｘｍｌｎｓ”であり値が“ｈｔｔｐ：／／ｓａｍｐｌｅ．ｃｏｍ／ｏｒｄｅｒ”であることを表す。図１０の３行目は、ＧＩＤが“１／２”であるノードが要素ノードであり、ノードの名前が“Ｎａｍｅ”であることを表す。要素ノードは値を持たないため、“＝”記号及びノードの値は省略してある。図１０の４行目は、ＧＩＤが“１／２／１”であるノードがテキストノードであることを表わす。テキストノードは名前を持たないため、ノードの名前は省略してある。また、図７に示す文法規則では、このテキストノードの値については規定してないため、ノードの値及び区切り文字の“＝”は省略してある。同様に、図１０の５行目は、ＧＩＤが１／３“であるノードが要素ノードであり、ノードの名前が“Ｔｅｌ”であることを表し、図１０の６行目はＧＩＤが“１／３／１”であるノードがテキストノードであることを表わす。図１０の７行目は、ＧＩＤが“１／４”であるノードが要素ノードであり、ノードの名前が“Ｉｔｅｍ”であることを表し、図１０の８行目はＧＩＤが“１／４／１”であるノードがテキストノードであることを表わす。
【００２９】
次に、構造化文書ＩＤ付与部１２３におけるノードＩＤ付与の処理について説明する。構造化文書ＩＤ付与部１２３は、ＸＭＬ文書３０２を構成する全てのノードに対して上述したＬＩＤを付与する。すなわち、図６に示す全てのノード６０１、６０２、６０３、６０４、６０５、６０６、６０７、６０８、６０９に対してＬＩＤを付与する。図１１は、構造化文書ＩＤ付与部におけるＬＩＤ付与の手順を示した図である。各ノードにＬＩＤを付与する際は、まずＩＤ付与の対象ノードが文法規則ＩＤ付与部１２１によってすでにＬＩＤが付与されているかが判断される（ステップ１１０２）。対象ノードについて文法規則３０１で何も規定されていない場合は、文法規則ＩＤ付与部１２１によってＩＤは付与されていない。この場合、構造化文書ＩＤ付与部１２３が兄弟ノード内における一意性が保たれるようなＬＩＤを新たに付与する（ステップ１１０３）。ここでは、文法規則ＩＤ付与部１２１及び構造化文書ＩＤ付与部１２３によって、まだ兄弟ノード内のＬＩＤとして付与されていない数字であり、かつ一番小さい数字を該ノードのＬＩＤとして付与するものとする。ＬＩＤの一意性が保たれる方法であれば、他の方法によってＬＩＤを付与してもよい。ＩＤ付与の対象ノードに対して、文法規則ＩＤ付与部１２１がすでにＬＩＤを付与している場合、構造化文書ＩＤ付与部１２３は文法規則ＩＤ付与部１２１によって付与されたＬＩＤを使って対象ノードにＬＩＤを付与する。ただし、ＸＭＬ文書３０２内の複数のノードが、文法規則３０１のひとつの記述に対応している可能性がある。よって、文法規則ＩＤ付与部１２１によって付与されたＬＩＤをそのまま対象ノードのＬＩＤとしてしまうと、兄弟ノード内におけるＬＩＤの一意性が失われてしまう可能性がある。そこで、ステップ１１０２において、対象ノードに対して文法規則ＩＤ付与部１２１がすでにＬＩＤを付与している場合、そのＬＩＤが構造化文書ＩＤ付与部１２３によって兄弟ノード内の他のノードにすでに付与されていないかが判断される（ステップ１１０４）。ステップ１１０４において、文法規則ＩＤ付与部１２１によって付与されたＬＩＤが、兄弟ノード内の他のノードに付与されていない場合、文法規則ＩＤ付与部１２１によって付与されたＬＩＤをそのまま対象ノードのＬＩＤとして付与する（ステップ１１０５）。ステップ１１０４において、文法規則ＩＤ付与部１２１によって付与されたＬＩＤが、兄弟ノード内の他のノードにすでに付与されている場合は、兄弟ノード内でのＬＩＤの一意性を保つため、文法規則ＩＤ付与部１２１によって付与されたＬＩＤに枝番を振ったものを対象ノードのＬＩＤとする（ステップ１１０６）。ここでは、文法規則ＩＤ付与部１２１によって付与されたＬＩＤの後に区切り文字“＿”を付け、その後に枝番として１から順に数字を付けるものとする。ＬＩＤの一意性が保たれ、文法規則ＩＤ付与部１２１によって付与されたＧＩＤとの対応が分かる方法であれば、他の方法を用いてＬＩＤを付与してもよい。上述した方法を用いて、ＸＭＬ文書３０２を構成する全てのノードに対してＬＩＤを付与する。各ノードのＧＩＤは、ＬＩＤから容易に計算することができる。文法規則３０１で規定されたノードと、ＸＭＬ文書３０２を構成するノードが一対一に対応する場合、すなわち文法規則３０１で規定された各ノードがＸＭＬ文書３０２において必ず一回ずつ出現し、かつ文法規則３０１に記述されていないノードがＸＭＬ文書３０２に出現しない場合は、構造化文書ＩＤ付与部１２３によって付与されるＩＤは、文法規則ＩＤ付与部１２１で付与されるＩＤと同じものになる。よって、このような場合は構造化文書ＩＤ付与部１２３によるＩＤ付与の処理を省略してもよい。
【００３０】
図１２は、構造化文書ＩＤ付与部１２３によって図５に示すＸＭＬ文書を構成するノードに対しＩＤを付与した結果を示す。構造化文書ＩＤ付与部１２３は、ＸＭＬ文書３０２を読み込み、出現順に従ってＸＭＬ文書を構成する各ノードにＩＤを付与する。図５に示すＸＭＬ文書では、最初にＯｒｄｅｒ要素が出現する。そこで、Ｏｒｄｅｒ要素が図１０に示す符号化文法規則で規定されているかが判断される（ステップ１１０２）。図５に示すＸＭＬ文書において、Ｏｒｄｅｒ要素はルート要素であることから、ＧＩＤには記号“／”が含まれないことがわかる。そこで、図１０に示す符号化文法規則から、ＧＩＤに記号“／”が含まれず、ノードのタイプが“−”であり、名前が“Ｏｒｄｅｒ”であるノードの記述を探す。図１０に示す符号化文法規則において、以上の条件を満たすノードの記述として、１行目の“１−Ｏｒｄｅｒ”がある。よって、Ｏｒｄｅｒ要素は文法規則ＩＤ付与部１２１によって、ＧＩＤ“１”、ＬＩＤ“１”が付与されたことがわかる。次に、Ｏｒｄｅｒ要素の兄弟ノードにおいてＬＩＤ“１”がすでに付与されていないかが判断される（ステップ１１０４）。Ｏｒｄｅｒ要素の兄弟ノードにおいて、ＬＩＤ“１”はまだ付与されていないため、ＬＩＤ“１”をそのままＯｒｄｅｒ要素のＬＩＤとして付与する（ステップ１１０５）。Ｏｒｄｅｒ要素のＧＩＤは“１”になる。図５のＸＭＬ文書では、Ｏｒｄｅｒ要素の次にｘｍｌｎｓ属性が出現する。ｘｍｌｎｓ属性は、Ｏｒｄｅｒ要素の子ノードであることから、ＧＩＤが“１／ｎ”となることがわかる。ここで、記号“ｎ”は任意の数字を表わす。そこで、図１０の符号化文法規則から、ＧＩＤが“１／ｎ”であり、ノードタイプが“＠”であり、名前が“ｘｍｌｎｓ”であるノードの記述を探す。図１０に示す符号化文法規則において、以上の条件を満たすノードの記述として、２行目の“１／１＠ｘｍｌｎｓ＝ｈｔｔｐ：／／ｓａｍｐｌｅ．ｃｏｍ／ｏｒｄｅｒ”がある。よって、ｘｍｌｎｓ属性は文法規則ＩＤ付与部１２１によって、ＧＩＤ“１／１”、ＬＩＤ“１”が付与されたことがわかる。ｘｍｌｎｓ属性の兄弟ノードにおいて、ＬＩＤ“１”はまだ付与されていないため、ＬＩＤ“１”をそのままｘｍｌｎｓ属性のＬＩＤとして付与する（ステップ１１０５）。ｘｍｌｎｓ属性のＧＩＤは“１／１”になる。図５のＸＭＬ文書では、次にコメントノードが出現する。このコメントノードは、Ｏｒｄｅｒ要素の子ノードであることから、ＧＩＤが“１／ｎ”となることがわかる。しかし、図１０の符号化文法規則には、ＧＩＤが“１／ｎ”であり、ノードタイプが“！”であるノードは存在しない。よって、該ノードは文法規則ＩＤ付与部１２１によってノードＩＤが付与されていないことがわかる。そこで、構造化文書ＩＤ付与部１２３は新たにＬＩＤとして“５”、ＧＩＤとして“１／５”を付与する（ステップ１１０３）。同様にして、図６に示した符号を用いると、６０４のノードにＬＩＤ“２”、ＧＩＤ“１／２”を、６０７のノードにＬＩＤ“１”、ＧＩＤ“１／２／１”を、６０５のノードにＬＩＤ“４”、ＧＩＤ“１／４”を、６０８のノードにＬＩＤ“１”、ＧＩＤ“１／４／１”を付与する。  符号６０６のＩ���ｅｍ要素については、ＧＩＤが“１／ｎ”であり、ノードの名前が“Ｉｔｅｍ”であることから、文法規則ＩＤ付与部１２１によって、ＧＩＤ“１／４”、ＬＩＤ“４”が付与されたことがわかる。しかし、ＬＩＤ“４”はすでに兄弟ノードである６０５のノードに付与してしまっているため、枝番を付けたＬＩＤ“４＿１”を６０６のノードのＬＩＤとして付与する。６０６のノードのＧＩＤは“１／４＿１”となる。６０９のノードにはＬＩＤ“１”、ＧＩＤ“１／４＿１／１”を付与する。
【００３１】
次に、構造化文書符号化部１２４におけるＸＭＬ文書の符号化の処理について説明する。構造化文書符号化部１２４は、圧縮対象ＸＭＬ文書３０２を構成する全てのノードに対し、上述した符号化ルールを用いて符号化を行ない、符号化文書３０４を出力する。符号化の際に用いるＧＩＤは、構造化文書ＩＤ付与部１２３によって付与されたＧＩＤを用いる。ただし、構造化文書ＩＤ付与部１２３におけるＩＤ付与処理を省略した場合は、文法規則ＩＤ付与化部１２１よって付与されたＧＩＤを用いる。図１３は、構造化文書符号化部１２４によって図５に示すＸＭＬ文書を符号化した結果である。図１３の３行目は、ＧＩＤが“１／５”であるノードがコメントノードであり、その値が“ｃｏｍｍｅｎｔ”であることを示す。コメントノードは名前を持たないため、ノードの名前は省略しノードタイプを表わす“！”記号の直後に“＝”記号及びノートの値が記述してある。
【００３２】
符号化文書３０４には、ＸＭＬ文書３０２を構成する全てのノードについて、そのタイプ、種類、名前が記述されている。また、ＧＩＤの値を参照することで、これらのノードの親子関係を決めることができる。また、各ノードの符号化は、ＸＭＬ文書での出現順に従って行なわれているため、ＸＭＬ文書での出現順は符号化文書での出現順と同じになる。よって、構造化文書符号化部１２４における符号化の際に、符号化対象であるＸＭＬ文書３０２の情報は損失しておらず、符号化前のＸＭＬ文書３０２と符号化文書３０４は一対一に対応する。よって、符号化文書３０４から圧縮前のＸＭＬ文書３０２を復元することが可能である。
【００３３】
次に、分離部１２５における分離処理について説明する。分離部１２５では、符号化文書３０４と符号化文法規則３０３を入力とし、符号化文書３０４に記述されているノードの情報から、符号化文法規則３０３に記述されているノードの情報を取り除くことで符号化コンテンツ３０５を生成する。分離部１２５は、符号化文書３０４に記述されている各ノードに対し、出現順に分離処理行なう。図１４は、各ノードに対する分離処理の手順を示した図である。各ノードの分離処理では、まず符号化文法規則３０３に、分離対象のノードと同じＧＩＤを持つノードの記述があるかどうかが判断される（ステップ１４０１）。この際、分離対象のノードのＧＩＤに枝番が付いている場合は、枝番を取り除いた値を用いて、符号化文法規則３０３に記述があるかどうかが判断される。符号化文法規則３０３に何も記述されていない場合、符号化文書３０４に記述された該ノードに関する情報はすべてコンテンツであることがわかる。よって符号文書に記述された内容を何も省略せず、そのまま符号化コンテンツ３０５に出力する（ステップ１４０２）。ステップ１４０１において、このノードの情報が符号化文法規則３０３に記述されている場合、符号化文法規則３０３に記述されている情報が構造であり、符号化文法規則３０３に記述されていない情報がコンテンツである。出力する符号化コンテンツには、構造に含まれる情報を省略して記述する（ステップ１４０４）。コンテンツに、処理対象のノードのタイプ、値、コンテンツのいずれも含まれない場合でも、ＸＭＬ文書内に対象ノードが存在することを示すため、ＧＩＤは省略せずに符号化コンテンツに出力する（ステップ１４０６）。また、本実施形態では圧縮効率を高めるため、コンテンツに、処理対象のノードのタイプ、値、コンテンツのいずれも含まれず、かつ対象ノードが子ノードを持つ場合に限り、ＧＩＤを省略し、符号化コンテンツには何も出力しない（ステップ１４０７）。これは、対象ノードが子ノードを持つ場合、そのノードの存在は自明であるためである。この処理は任意であり、行なわなくてもよい。
【００３４】
図１５は、図１３に示す符号化文書から図１０に示す符号化文法規則に記述されている情報を取り除くことで生成した符号化コンテンツである。図１３の１行目は、ＧＩＤが“１”であるノードが要素ノードであり、名前が“Ｏｒｄｅｒ”であることを表わす。これらの情報は、図１０の符号化文法規則の１行目にも記述されている。よって、このノードが要素ノードであることを表わす“−”記号と、名前を表わす“Ｏｒｄｅｒ”の文字を省略する。また、Ｏｒｄｅｒ要素は子ノードを持つためＧＩＤの記述も省略する。よって、Ｏｒｄｅｒ要素に関する情報は符号化コンテンツ３０５には記述しない（ステップ１４０７）。図１３の２行目は、ＧＩＤが“１／１”であるノードが要素ノードであり、名前が“ｘｍｌｍｓ”で値が“ｈｔｔｐ：／／ｓａｍｐｌｅ．ｃｏｍ／ｏｒｄｅｒ”であることを表わす。これらの情報は、図１０の符号化文法規則の２行目にも記述されている。よって、該ノードが属性ノードであることを表わす“＠”記号、名前が“ｘｍｌｎｓ”、値を表わす“ｈｔｔｐ：／／ｓａｍｐｌｅ．ｃｏｍ”を省略する。ｘｍｌｎｓ属性は子ノードを持たないため、ＧＩＤを省略することはできない。よって符号化コンテンツには、ｘｍｌｎｓ属性が存在することを示すためＧＩＤ“１／１”のみを記述する（ステップ１４０６）。図１３の３行目に示したコメントノードに関する情報は、図１０の符号化文法規則には記述されていない。よって図１３の３行目に記述された情報“１／５！＝ｃｏｍｍｅｎｔ”は何も省略せずに、そのまま符号化コンテンツ１５１５に記述する（ステップ１４０２）。以下同様にして、図１３の各行について図１０の符号化文法規則に記述されている情報を取り除いていく。
【００３５】
このようにして生成された符号化コンテンツ３０５は、後述する解凍プログラム１２０に入力することで圧縮前のＸＭＬ文書に復元することができるが、解凍処理の際には符号化文法規則３０３が必要になる。受信側計算機１０２内または構造化文書処理システム２０１内に複数の符号化文法規則３０３が存在する場合には、復号化対象の符号化コンテンツ３０５が、どの符号化文法規則３０３を用いて生成されたものかを明示する必要がある。本実施形態では、符号化文法規則３０３にＩＤを付与し、符号化コンテンツには符号化文法規則への参照情報としてこのＩＤを追加する。図２５は、図１０に示す符号化文法規則にＩＤを付与した例を示す図である。ここでは、図１０に示す符号化文法規則に対してＩＤ“００１”を付与するものとする。図２５の１行目に記述された“ｉｄ＝００１”が、この符号化文法規則のＩＤが“００１”であることを示す。図２６は、図１５に示す符号化コンテンツに、符号化文法規則への参照情報を追加した例を示す図である。図２５の１行目に記述された“ｒｅｆ＝００１”が、この符号化コンテンツの生成の際に使用した符号化文法規則が、ＩＤが“００１”の符号化文法規則であることを示す。符号化コンテンツが、どの符号化文書を使用して生成されたものであるかが分かる方法であれば、他の方法を用いて符号化コンテンツと符号化文法規則の対応関係を示してもよい。本実施形態を図１に示すデータ通信時のデータ圧縮に用いる場合、送信側計算機１０１から受信側計算機１０２には、図２５に示す符号化文法規則と図２６に示す符号化コンテンツを送信する。また、本実施形態を図２に示すようなデータ保存時のデータ圧縮に用いる場合、図２５に示す符号化文法規則と図２６に示す符号化コンテンツを保存する。
【００３６】
次に、本実施形態における解凍プログラム１２０について説明する。図１６は、本実施形態における解凍プログラム１２０の機能構成を示す図である。図１７は、本実施形態における解凍処理の手順を示した図である。解凍プログラム１２０は、圧縮プログラム１１５によって出力された符号化文法規則３０３と符号化コンテンツ３０５を入力とし、ＸＭＬ文書１６０２を出力する。解凍プログラム１２０によって出力されるＸＭＬ文書１６０２は、圧縮前のＸＭＬ文書３０２と同じ内容になる。解凍処理の際には、まず符号化文法規則３０３と符号化コンテンツ３０５が結合部１２６に入力され、符号化文書１６０１が生成される（ステップ１７０１）。符号化文書１６０１は、圧縮プログラム１１５内の構造化文書符号化部１２４によって出力されたものと同じ内容になる。次に、復号化部１２７において符号化文書１６０１の復号化が行なわれ（ステップ１７０２）、ＸＭＬ文書１６０２が出力される（ステップ１７０３）。
【００３７】
以下では、図１５に示す符号化コンテンツと図１０に示す符号化文法規則を結合する場合を例にとり、本実施形態の結合部１２６における結合処理の詳細を説明する。上述したように、受信側計算機１０２内またはＸＭＬ文書処理システム２０１内に複数の符号化文法規則３０３が存在する場合には、符号化コンテンツ３０５には符号化文法規則３０３への参照情報が含まれている。これにより符号化コンテンツ３０５がどの符号化文法規則３０３を用いて生成されたものかがわかる。結合部１２６は、復号化対象の符号化コンテンツ３０５と、その符号化コンテンツを生成する際に使用した符号化文書３０３を読み込む。図１８は、結合部１２６における結合処理の手順を示す図である。結合部１２６は、図１５に示す符号化コンテンツを読み込み、１行目から順に結合処理を行なう。結合部１２６はまず、図１５の１行目を読み込む。図１５の１行目は、ＧＩＤが“１／１”のノードに関する記述だが、ＧＩＤが“１／１”のノードが存在するためには、その親ノードであるＧＩＤが“１”のノードが存在しなくてはならない。ＧＩＤが“１”のノードはまだ符号化文書１６０１に出力していないため、ＧＩＤが“１／１”のノードをスタックに積み、先にＧＩＤが“１”のノードの結合処理を行なう（ステップ１８０３）。ＧＩＤが“１”のノードに関する情報は、図１０の１行目に“１−Ｏｒｄｅｒ”と記述されており（ステップ１８０４）、図１５には何も記述されていないため、符号化文書には“１−Ｏｒｄｅｒ”の値を記述する（ステップ１８０５）。続いて、ＧＩＤが“１／１”のノードがスタックに積まれているため、ＧＩＤが“１／１”のノードの結合処理を行なう（ステップ１８０７）。ＧＩＤが“１／１”のノードに関する情報は、図１０の符号化文法規則の２行目に“１／１＠ｘｍｌｎｓ＝ｈｔｔｐ：／／ｓａｍｐｌｅ．ｃｏｍ／ｏｒｄｅｒ”と記述されており（ステップ１８０４）、符号化文書にはこの値を記述する（ステップ１８０５）。スタックに積まれたノードがなくなったため、結合部１２６は次に図１５の２行目を読み込む。図１５の２行目はＧＩＤが“１／５”のノードに関する記述である。ＧＩＤ“１／５”のノードの親ノードであるＧＩＤ“１”のノードについては、すでに符号化文書１６０１に出力済みであるため、ＧＩＤ“１／５”のノードの結合処理を行なう（ステップ１８０１）。ＧＩＤが“１／５”のノードに関する情報は、図１０の符号化文法規則には記述されていないため（ステップ１８０４）、符号化コンテンツに記述された“１／５！＝ｃｏｍｍｅｎｔ”をそのまま符号化文書に記述する（ステップ１８０５）。同様にして、結合部１２６は符号化コンテンツ３０５の各行に記述されたノードに対してノードに対して結合処理を行なう。図１５の３行目は、ＧＩＤが“１／２／１”のノードの情報を表わすが、このノードが存在するためには、ＧＩＤが“１／２”であるノードが存在しなくてはならない。ＧＩＤが“１／２”のノードに関する情報は、図１０の符号化文法規則の３行目に“１／２−Ｎａｍｅ”と記述されており、符号化文書にはこの値を記述する。続いて、ＧＩＤが“１／２／１”のノードに関する情報を符号化文書に記述する。ＧＩＤが“１／２／１”のノードに関する情報は、図１５の３行目の“１／２／１＝Ｊｏｈｎ”と図１０の４行目の“１／２／１＃”とがある。前者はこのノードの値が“Ｊｏｈｎ”であることを表わし、後者はこのノードがテキストノードであることを表わす。符号化文書には、これらの情報を足し合わせ、ＧＩＤが“１／２／１”のノードがテキストノードであり、値が“Ｊｏｈｎ”であることを表わす“１／２／１＃＝Ｊｏｈｎ”という値を記述する。同様にして、ＧＩＤが“１／４”のノードに関する情報として“１／４−Ｉｔｅｍ”を、“１／４／１”のノードに関する情報として“１／４／１＃＝ｐｅｎ”を符号化文書に記述する。ＧＩＤが“１／４＿１”のノードは、図１０の符号化文法規則では枝番のついていないＧＩＤが“１／４”のノードとして記述されている。よって、ＧＩＤが“１／４＿１”のノードに関する情報として、“１／４＿１−Ｉｔｅｍ”を、“１／４＿１／１”に関する情報として“１／４＿１／１＃ｎｏｔｅ”を符号化文書に記述する。このようにして生成した符号化文書は、圧縮プログラム１１５の構造化文書符号化部１２４によって生成された符号化文書３０４と同じ内容になる。
【００３８】
次に、復号化部１２７について説明する。復号化部１２７は、符号化文書１６０１を入力とし、ＸＭＬ文書１６０２を出力する。上述したように、結合部１２６から出力される符号化文書１６０２は、圧縮プログラム１１５の構造化文書符号化部１２４によって出力される符号化文書３０４と同じ内容であり、圧縮前のＸＭＬ文書３０２と一対一に対応している。よって、符号化文書１３１１からＸＭＬ文書１６０２への復号化は、曖昧さなく行なうことができる。以下では、図１３に示す符号化文書から圧縮前のＸＭＬ文書を復元する場合を例に取り、復号化部１２７における復号処理の詳細を説明する。復号化部１２７は、図１３に示す符号化文書の各行に記述されたノードの情報を１行目から順に読み込み、ＸＭＬ文書１６０２を生成する。復号化部１２７は、まず図１３の一行目の“１−Ｏｒｄｅｒ”を読み込む。“１−Ｏｒｄｅｒ”という記述から、このノードがルート要素であり、名前が“Ｏｒｄｅｒ”であることがわかる。よって、メモリ上に“＜Ｏｒｄｅｒ＞＜／Ｏｒｄｅｒ＞”というデータを生成する。復号化部１２７は、次に図１３の２行目の“１／１＠ｘｍｌｎｓ＝ｈｔｔｐ：／／ｓａｍｐｌｅ．ｃｏｍ／ｏｒｄｅｒ”を読み込む。“１／１＠ｘｍｌｎｓ＝ｈｔｔｐ：／／ｓａｍｐｌｅ．ｃｏｍ／ｏｒｄｅｒ”という記述から、このノードが図１３の１行目に記述されたＯｒｄｅｒ要素の子ノードである属性ノードであり、名前が“ｘｍｌｎｓ”で、値が“ｈｔｔｐ：／／ｓａｍｐｌｅ．ｃｏｍ／ｏｒｄｅｒ”であることがわかる。よって、メモリ上のデータをｘｍｌ属性が追加されたデータ“＜Ｏｒｄｅｒ  ｘｍｌｎｓ＝“ｈｔｔｐ：／／ｓａｍｐｌｅ．ｃｏｍ．／ｏｒｄｅｒ”＞＜／Ｏｒｄｅｒ＞”に更新する。同様にして、図１３に示す符号化文書の全ての行について復号化を行なう。このようにして復号化を行なうことで、図５に示す圧縮前のＸＭＬ文書と同じ内容のＸＭＬ文書を復元することができる。
【００３９】
次に、本実施形態による圧縮の効果について説明する。図５に示すＸＭＬ文書から空白スペースと改行を取り除いた場合のデータ量は、１１４バイトである。一方、図２５に示す符号化文法規則のデータ量は９５バイトであり、図２６に示す符号化コンテンツのデータ量は５８バイトである。図５に示すＸＭＬ文書と同程度のデータ量を持ち内容の異なる１０個のＸＭＬ文書を、ネットワークを介して送信する場合について考える。図５の例から、送信するＸＭＬ文書の平均データ量が１１４バイトで、符号化文法規則のデータ量が９５バイトで、符号化コンテンツの平均データ量が５８バイトである仮定する。圧縮を行なわない場合、平均１１４バイトのＸＭＬ文書を１０個送信するため、総データ量は約１１４０バイトになる。一方、本実施形態により圧縮を行なった場合、９５バイトの符号化文法規則を１個と、平均５８バイトの符号化コンテンツを１０個送信すればよく、総データ量は、約６７５バイトとなる。よって圧縮を行なわない場合に比べ約５９％にデータ量が削減できることが分かる。
〔２〕第２実施形態の説明
ＸＭＬは標準化された技術であり、近年、システム間のデータ通信の際のフォーマットとしてＸＭＬを使うことが増えている。データ通信の際のフォーマットとしてＸＭＬを用いる場合、通常受信側計算機では、受信したＸＭＬ文書内のデータにアクセスするためＸＭＬ文書の構造解析を行ない、ＸＭＬ文書の木構造から必要なデータを検索し、受信側計算機に固有のバイナリデータに変換する。本実施形態は、ＸＭＬ文書ではなく、第１実施形態で述べた符号化文法規則３０３と符号化コンテンツ３０５を受信した際の、符号化コンテンツからバイナリデータへの変換方法に関するものである。
【００４０】
以下では、本発明の第２実施形態について説明する。図１９は、本実施形態のシステム全体の構成を示した図である。図１９において、送信側計算機１０１は、第１実施形態で説明したものと同じである。本実施形態における受信側計算機１９０１の記憶装置１９１４内には、符号化コンテンツから受信側計算機１９０１に固有のバイナリデータへの変換を行なう変換プログラム１９２１が置かれる。圧縮されたデータは、送信側計算機１０１によってネットワーク上に送信され、受信側計算機１９０１内の通信装置１９１１によって受信される。変換プログラム１９２１は、対応表変換部１９３１とバイナリデータ生成部１９３２とを備える。後述するように、変換プログラム１９２１は、必ずしも対応表変換部１９３１を備えていなくてもよい。本実施形態における変換処理は、記憶装置１９１４内に格納されている変換プログラム１９２１が、メモリ１９１３に読み込まれ、ＣＰＵ１９１２によって実行されることにより実現される。
【００４１】
図２０は、本実施形態における変換プログラム１９２１の機能構成を示した図である。図２１は、変換プログラム１９２１における変換処理の手順を示した図である。ノードＩＤ対応表が存在しない場合、まずノード対応表２００１と符号化文法規則３０３が対応表変換部１９３１に入力され、ノード対応表２００１がノードＩＤ対応表２００２へと変換される（ステップ２１０２）。ノード対応表２００１は、ＸＭＬ文書のどのノードの値がバイナリデータ２００３のどの変数に格納されるかを示した表であり、あらかじめ受信側計算機１９０１内に用意しておく。受信側計算機１９０１内に複数の符号化文法規則３０３が存在する場合、ノード対応表２００１は、対応する符号化文法規則３０３への参照情報を含めるものとする。ノードＩＤ対応表２００２は、圧縮前のＸＭＬ文書が同じ文法規則に従っている場合共通のものを使用することができる。よってノードＩＤ対応表２００１からノードＩＤ対応表２００２への変換処理ステップ２１０２は、最初の一度だけ行なえばよく、すでにノードＩＤ対応表２００２が存在する場合はこの処理を省略することができる。また、対応表変換部１９３１によってノードＩＤ対応表２００２に変換するのではなく、あらかじめノードＩＤ対応表２００２を用意しておいてもよい。この場合、変換プログラム１９２１は対応表変換部１９３１を備えていなくてもよい。ステップ２１０１においてすでにノードＩＤ対応表が存在する場合、ステップ２１０２の処理を省略し既存のノードＩＤ対応表２００２を入力し（ステップ２１０３）、これを使用する。次に、符号化コンテンツ３０５とノードＩＤ対応表２００２がバイナリデータ生成部１９３２へ入力され、バイナリデータ２００３が出力される。
【００４２】
次に、本実施形態における対応表変換部１９３１について説明する。以下では、図１０に示す符号化文法規則と、図１５に示す符号化コンテンツが変換プログラム１９２１に入力される場合を例にとり変換処理の詳細を説明する。以下では、図２２に示すノード対応表を例に取り説明する。図２２の符号２２０１は、このノード対応表が、ＩＤが“００１”である符号化文法規則に対応するものであることを示す。図２２の１列目では、Ｗ３Ｃが勧告するＸＭＬ上のノードの位置を特定する記述言語であるＸＰａｔｈを用いてＸＭＬ文書のノードを指定している。ノード対応表は、ＸＭＬ文書のノードとバイナリデータの変数との対応関係を示していれば、別の方法を用いて記述してもよい。対応表変換部１９３１は、図１０に示す符号化文法規則を参照しながら、図２２に示すノード対応表を図２３に示すノードＩＤ対応表に変換する。図２２の１行目は、ルート要素であるＯｒｄｅｒ要素の子ノードであるＮａｍｅ要素の、さらに子ノードであるテキストノードの値が、バイナリデータ２００３において“ＣｕｓｔｏｍｅｒＮａｍｅ”という変数に格納されることを示す。図１０に示す符号化文法規則から、ルート要素であるＯｒｄｅｒ要素の子ノードであるＮａｍｅ要素の、さらに子ノードであるテキストノードのＧＩＤは“１／２／１”であることがわかる。よって、図２３に示すノードＩＤ対応表の１行目には、ＧＩＤ“１／２／１”と変数“ＣｕｓｔｏｍｅｒＮａｍｅ”が対応していることを記述する。図２２の２行目は、ルート要素であるＯｒｄｅｒ要素の子ノードであるＩｔｅｍ要素の、さらに子ノードであるテキストノードの値が、バイナリデータ２００３において“ＯｒｄｅｒＩｔｅｍ［］”という変数に格納されることを示す。ここで“［］”記号はＯｒｄｅｒＩｔｅｍ変数が配列であることを表わす。“／Ｏｒｄｅｒ／Ｉｔｅｍ／ｔｅｘｔ（）”によって表わされるノードは、ＸＭＬ文書において複数回出現する可能性があり、このノードの値はＸＭＬ文書での出現順に従って配列“ＯｒｄｅｒＩｔｅｍ［］”の要素に順に格納される。図１０に示す符号化文法規則から、ルート要素であるＯｒｄｅｒ要素の子ノードであるＩｔｅｍ要素の、さらに子ノードであるテキストノードのＧＩＤは“１／４／１”であることがわかる。よって、ノードＩＤ対応表の１行目には、ＧＩＤ“１／４／１”と変数“ＯｒｄｅｒＩｔｅｍ［］”が対応していることを記述する。生成したノードＩＤ対応表には、どの符号化文法規則から生成されたものであるか分かるように参照情報を付け加えておく。
【００４３】
次に、バイナリデータ生成部１９３２について説明する。バイナリデータ生成部１９３２は、符号化コンテンツ３０５とノードＩＤ対応表２００２を入力とし、バイナリデータ２００３を出力する。符号化コンテンツ３０５には対応する符号化文法規則３０３への参照情報が含まれる。バイナリデータ生成部１９３２は、受信した符号化コンテンツと、その符号化コンテンツと対応する符号化文法規則から生成されたノードＩＤ対応表を読み込む。以下では、図１５に示す符号化コンテンツと図２３に示すノードＩＤ対応表を入力とした場合を例にバイナリデータ生成処理の詳細を説明する。図２４は、メモリ１９１３におけるバイナリデータの様子を示した図である。図２３に示すノードＩＤ対応表の１行目から、ＧＩＤが“１／２／１”のノードの値がバイナリデータ２００３において変数“ＣｕｓｔｏｍｅｒＮａｍｅ”に格納されることがわかる。図１５に示す符号化コンテンツでは、３行目にＧＩＤが“１／２／１”であるノードの情報が記述されている。符号化コンテンツ３０５において、各ノードのＧＩＤは各行の先頭に記述されている。よって、符号化コンテンツから該当するノードの情報を検索する処理は簡単に行なうことができる。図１５の３行目には、ＧＩＤが“１／２／１”のノードの値が“Ｊｏｈｎ”であることが記述されている。よって、図２４に示すようにバイナリデータの変数“ＣｕｓｔｏｍｅｒＮａｍｅ”に“Ｊｏｈｎ”を格納する。また、図２３に示すノードＩＤ対応表の２行目から、ＧＩＤが“１／４／１”のノードの値がバイナリデータ２００３において変数“ＯｒｄｅｒＩｔｅｍ［］”に格納されることがわかる。図１５に示す符号化コンテンツでは、４行目にＧＩＤが“１／４／１”であるノードの値が“ｐｅｎ”であることが記述されている。変数“ＯｒｄｅｒＩｔｅｍ［］”は配列であり、まだひとつも値が格納されていない。よって、図２４に示すように配列“ＯｒｄｅｒＩｔｅｍ［］”の最初の要素である“ＯｒｄｅｒＩｔｅｍ［０］”に“ｐｅｎ”を格納する。また、５行目にＧＩＤが“１／４＿１／１”であるノードの情報が記述されているが、符号化コンテンツにおけるＧＩＤ“１／４＿１／１”は、符号化文法規則におけるＧＩＤ“１／４／１”に対応する。よって、配列“ＯｒｄｅｒＩｔｅｍ［］”の最初の要素“ＯｒｄｅｒＩｔｅｍ［０］”にはすでに、“Ｊｏｈｎ”の値が格納されているため、次の要素である“ＯｒｄｅｒＩｔｅｍ［１］”に“ｎｏｔｅ”を格納する。
【００４４】
このように、本実施形態の変換プログラム１９２１を用いることで、符号化コンテンツ３０５から圧縮前のＸＭＬ文書を復元することなしに、受信側計算機に固有のバイナリデータに変換することが可能である。この方法を用いることで、受信側計算機１９０１において、圧縮前のＸＭＬ文書への解凍処理、ＸＭＬ文書の構造解析処理を行なう必要がなくなり、データ受信時の処理の負荷を大幅に削減することができる。
【００４５】
【発明の効果】
以上に述べたように、本発明の圧縮プログラムを用いることで、ＸＭＬ文書からコンテンツのみを符号化された形で取り出すことができる。これにより、ＸＭＬ文書の情報を損失することなくデータ量を削減することができる。本発明の符号化では、ノードのタイプ、名前、値の情報をノードのＩＤと関連付けて記述するため、ノードＩＤを参照することで符号化されたデータを容易に分離、結合することが可能である。これにより、ノードの値がＸＭＬ文書の構造に含まれる場合、文法規則で記述されていないノードがＸＭＬ文書に出現する場合など、従来の技術では対応が困難であった場合に対しても、本発明の圧縮プログラムを適用することができる。
【００４６】
また、符号化コンテンツに含まれるデータをノードＩＤと関連付けて記述していることにより、圧縮前のＸＭＬ文書に復元せずに、符号化コンテンツからバイナリデータへ変換することが可能になる。これにより、データアクセスの処理を軽減することができる。
【図面の簡単な説明】
【図１】本発明の第１実施形態をデータ通信時のデータ圧縮に用いた場合のシステム全体の構成を示す図である。
【図２】本発明の第１実施形態をデータ保存時のデータ圧縮に用いた場合のシステム全体の構成を示す図である。
【図３】圧縮プログラムの機能構成を示す図である。
【図４】圧縮処理の手順を示すフローチャートである。
【図５】圧縮対象のＸＭＬ文書の例を示す図である。
【図６】図５に示すＸＭＬ文書を構成するノードに関する情報を示す図である。
【図７】圧縮対象のＸＭＬ文書が従う文法規則の例を示す図である。
【図８】図７に示す文法規則が規定するノードに関する情報を示す図である。
【図９】図７に示す文法規則の規定するノードに対してＩＤを付与した結果を示す図である。
【図１０】符号化文法規則の例を示す図である。
【図１１】ＸＭＬ文書を構成するノードに対してＩＤを付与する処理の手順を示すフローチャートである。
【図１２】図５に示すＸＭＬ文書を構成するノードに対してＩＤを付与した結果を示す図である。
【図１３】符号化文書の例を示す図である。
【図１４】符号化文書から符号化コンテンツを分離する処理の手順を示すフローチャートである。
【図１５】符号化コンテンツの例を示す図である。
【図１６】圧縮プログラムの機能構成を示す図である。
【図１７】解凍処理の手順を示すフローチャートである。
【図１８】符号化文法規則と符号化コンテンツを結合する処理の手順を示すフローチャートである。
【図１９】本発明の第２実施形態のシステム全体の構成を示す図である。
【図２０】変換プログラムの機能構成を示す図である。
【図２１】変換処理の手順を示すフローチャートである。
【図２２】ノード対応表の例を示す図である。
【図２３】ノードＩＤ対応表の例を示す図である。
【図２４】メモリ内のバイナリデータに値が格納される様子を示した図である。
【図２５】符号化文法規則にＩＤを付与した例を示す図である。
【図２６】符号化コンテンツに符号化文法規則への参照情報を追加した例を示す図である。
【符号の説明】
１０１・・・・・送信側計算機、
１０２・・・・・受信側計算機、
１０３・・・・・ネットワーク、
１１１・・・・・通信装置、
１１２・・・・・ＣＰＵ、
１１３・・・・・メモリ、
１１４・・・・・記憶装置、
１１５・・・・・圧縮プログラム、
１１６・・・・・通信装置、
１１７・・・・・ＣＰＵ、
１１８・・・・・メモリ、
１１９・・・・・記憶装置、
１２０・・・・・解凍プログラム、
１２１・・・・・文法規則ＩＤ付与部、
１２２・・・・・文法規則符号化部、
１２３・・・・・構造化文書ＩＤ付与部、
１２４・・・・・構造化文書符号化部、
１２５・・・・・分離部、
１２６・・・・・結合部、
１２７・・・・・復号化部、
２０１・・・・・ＸＭＬ文書処理システム、
２１１・・・・・ＣＰＵ、
２１２・・・・・メモリ、
２１３・・・・・記憶装置、
２１４・・・・・データベース、
３０１・・・・・文法規則、
３０２・・・・・ＸＭＬ文書、
３０３・・・・・符号化文法規則、
３０４・・・・・符号化文書、
３０５・・・・・符号化コンテンツ、
４０１〜４０９・・・圧縮処理ステップ
６０１・・・・・Ｏｒｄｅｒ要素ノード、
６０２・・・・・ｘｍｌｎｓ属性ノード、
６０３・・・・・コメントノード、
６０４・・・・・Ｎａｍｅ要素ノード、
６０５、６０６・・・Ｉｔｅｍ要素ノード、
６０７、６０８、６０９・・・テキストノード、
８０１・・・・・Ｏｒｄｅｒ要素ノード、
８０２・・・・・ｘｍｌｎｓ属性ノード、
８０３・・・・・Ｎａｍｅ要素ノード、
８０４・・・・・Ｔｅｌ要素ノード、
８０５・・・・・Ｉｔｅｍ要素ノード、
８０６、８０７、８０８・・・テキストノード、
９０１・・・・・Ｏｒｄｅｒ要素ノード、
９０２・・・・・ｘｍｌｎｓ属性ノード、
９０３・・・・・Ｎａｍｅ要素ノード、
９０４・・・・・Ｔｅｌ要素ノード、
９０５・・・・・Ｉｔｅｍ要素ノード、
９０６、９０７、９０８・・・テキストノード、
１１０１〜１１０７・・・ＩＤ付与処理ステップ、
１２０１・・・・・Ｏｒｄｅｒ要素ノード、
１２０２・・・・・ｘｍｌｎｓ属性ノード、
１２０３・・・・・コメントノード、
１２０４・・・・・Ｎａｍｅ要素ノード、
１２０５・・・・・Ｔｅｌ要素ノード、
１２０６・・・・・Ｉｔｅｍ要素ノード、
１２０７、１２０８、１２０９・・・テキストノード、
１４０１〜１４０７・・・分離処理ステップ、
１６０１・・・・符号化文書、
１６０２・・・・ＸＭＬ文書、
１７０１〜１７０３・・・解凍処理ステップ、
１８０１〜１８０８・・・結合処理ステップ、
１９０１・・・・受信側計算機、
１９１１・・・・通信装置、
１９１２・・・・ＣＰＵ、
１９１３・・・・メモリ、
１９１４・・・・記憶装置、
１９２１・・・・変換プログラム、
１９３１・・・・対応表変換部、
１９３２・・・・バイナリデータ生成部、
２００１・・・・ノード対応表、
２００２・・・・ノードＩＤ対応表、
２００３・・・・バイナリデータ、
２１０１〜２１０４・・・変換処理ステップ、
２２０１・・・・符号。
【図１】
2004342029.tif 000003
【図２】
2004342029.tif 000004
【図３】
2004342029.tif 000005
【図４】
2004342029.tif 000006
【図５】
2004342029.tif 000007
【図６】
2004342029.tif 000008
【図７】
2004342029.tif 000009
【図８】
2004342029.tif 000010
【図９】
2004342029.tif 000011
【図１０】
2004342029.tif 000012
【図１１】
2004342029.tif 000013
【図１２】
2004342029.tif 000014
【図１３】
2004342029.tif 000015
【図１４】
2004342029.tif 000016
【図１５】
2004342029.tif 000017
【図１６】
2004342029.tif 000018
【図１７】
2004342029.tif 000019
【図１８】
2004342029.tif 000020
【図１９】
2004342029.tif 000021
【図２０】
2004342029.tif 000022
【図２１】
2004342029.tif 000023
【図２２】
2004342029.tif 000024
【図２３】
2004342029.tif 000025
【図２４】
2004342029.tif 000026
【図２５】
2004342029.tif 000027
【図２６】
2004342029.tif 000028