JP5168791B2 - アクセプタンス状態の表示システム及び方法 - Google Patents

アクセプタンス状態の表示システム及び方法 Download PDF

Info

Publication number
JP5168791B2
JP5168791B2 JP2006034541A JP2006034541A JP5168791B2 JP 5168791 B2 JP5168791 B2 JP 5168791B2 JP 2006034541 A JP2006034541 A JP 2006034541A JP 2006034541 A JP2006034541 A JP 2006034541A JP 5168791 B2 JP5168791 B2 JP 5168791B2
Authority
JP
Japan
Prior art keywords
node
document
data
delimiter
entry
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2006034541A
Other languages
English (en)
Other versions
JP2006221657A (ja
Inventor
卓己 上谷
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of JP2006221657A publication Critical patent/JP2006221657A/ja
Application granted granted Critical
Publication of JP5168791B2 publication Critical patent/JP5168791B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/20—Natural language analysis
    • G06F40/205—Parsing
    • G06F40/226—Validation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/12—Use of codes for handling textual entities
    • G06F40/14—Tree-structured documents
    • G06F40/143—Markup, e.g. Standard Generalized Markup Language [SGML] or Document Type Definition [DTD]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Computational Linguistics (AREA)
  • General Health & Medical Sciences (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Document Processing Apparatus (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明は、データ処理システムに関し、特に、マークアップ言語文書の符号化と復号に関する。
近年、eXtensible Markup Language（XML）その他のデータ記述マークアップ言語の登場と発達により、これらの言語の柔軟性と拡張性を利用する多数のアプリケーションが開発されている。拡張可能データ記述言語の利点を利用するシステムが発達しており、そのシステムには、例えば、電子商取引ネットワーク、移動通信装置、個人用データ処理装置、データベースシステム等が含まれている。これらの言語を利用するために開発されたシステムは、多くの場合、処理能力と記憶容量に限界があるので、限られたメモリ及び計算資源を用いてマークアップ言語を処理する方法を用いている。
本発明によると、データ処理システムと関連づけられた不利益と問題点が大幅に軽減され、または無くなる。特に、マークアップ言語データ構造の受付状態を示すシステムと方法が提供される。
本発明の一実施形態によると、マークアップ言語文書を分析する方法は、マークアップ言語文書において、第１のノードタイプの第１のデータノードの始まりを検知するステップと、前記第１のノードタイプと関連づけられた、前記第１のノードタイプの定義された内容を指示する第１のデータ定義を特定するステップと、前記第１のデータノードと関連づけられた第１のエントリーをデータ構造に加えるステップと、前記マークアップ言語文書から前記第１のデータノードの内容を読み出すステップと、前記第１のデータ定義と、前記第１のデータノードから読み出した前記内容とに基づき、前記第１のデータノードの状態を決定するステップと、グラフィカルユーザインターフェイス（ＧＵＩ）上に前記第１のデータノードの前記状態を表示するステップと、を有する。
本発明の他の実施形態によると、マークアップ言語文書を分析するシステムは、マークアップ言語文書を格納するメモリと、プロセッサから受け取った情報に基づいて１つ以上のデータノードの状態を表示するグラフィカルユーザインターフェイス（ＧＵＩ）と、プロセッサとを有する。前記プロセッサは、マークアップ言語文書において、第１のノードタイプの第１のデータノードの始まりを検知し、前記第１のノードタイプと関連づけられた、前記第１のノードタイプの定義された内容を指示する第１のデータ定義を特定し、前記第１のデータノードと関連づけられた第１のエントリーをデータ構造に加え、前記マークアップ言語文書から前記第１のデータノードの内容を読み出し、前記第１のデータ定義と、前記第１のデータノードから読み出した前記内容とに基づき、前記第１のデータノードの状態を決定し、前記ＧＵＩ上に前記第１のデータノードの前記状態を表示する。
本発明の実施形態による技術的利点には、マークアップ言語に含まれるノードの完全性を判断するローバストな方法と、標準的ではないマークアップ言語を処理する柔軟性が改善されることが含まれる。この他、一部の実施形態の技術的利点には、データノードの完全性に関する情報を表示する効果的な方法が含まれる。本発明の他の技術的利点は、添付した図面を参照して詳細な説明を読めば当業者には容易に明らかになるであろう。さらにまた、具体的な利点を上に記載したが、実施形態によっては、これらの利点を全て含むものもあれば、一部だけ含むものもあり、まったく含まないものもある。
図１は、XMLデータ文書を生成、送信、及び処理できるデータ処理システム１０を示す。データ処理システム１０は、生成アプリケーション２０ａ、２０ｂ、ジェネリックエンコーダ３０、スペシフィックエンコーダ３５、スキーマコンパイラ４０、文書デコーダ５０、受信アプリケーション６０を含む。生成アプリケーション２０がデータ文書７０を生成し、受信アプリケーション６０への送信のためにジェネリックエンコーダ３０またはスペシフィックエンコーダ３５がそのデータ文書７０を符号化する。一部の実施形態において、データ処理システム１０は、コンパイルされたスキーマ８５と符号化・処理方法を用いて生成アプリケーション２０と受信アプリケーション６０の間で交換される情報を削減する。結果として、一部の実施形態において、データ処理システム１０は、データ文書７０に含まれた情報の利用に必要なメモリ及び処理資源を削減することができる。
生成アプリケーション２０ａは、XML言語その他のテキストベースのマークアップ言語、プロトコル、または標準規格に従って構造化されフォーマットされたデータを含むデータ文書７０を生成する。以下の説明では、XML言語に従ったデータ文書を利用するように構成されたデータ処理システム１０に焦点をあてるが、データ処理システム１０及び／またはそのデータ処理システム１０の個別のコンポーネントは、XML、ハイパーテキストマークアップ言語（HTML）、汎用マークアップ言語（SGML）を含む（しかし、これらに限定はされない）適当なマークアップ言語のデータ文書７０を処理するように構成されている。生成アプリケーション２０ｂは結合前データ文書７８を生成する。この結合前データ文書７８は、データ文書７０に含まれるデータ構造を含むが、スキーマに結合されている。これについては、以下により詳しく説明する。結合前データ文書７８は、例えば、区切られる構造の名前またはタイプを特定するXMLスタイルのテキストデリミタではなく、数値デリミタを利用する。この説明では、生成アプリケーション２０は、データ文書を読み出すためにデータ処理システム１０のメモリ１００にアクセスすることにより、またはデータ処理システム１０の他のコンポーネントからデータ文書７０を読み出すことにより、または自分自身でデータ文書７０を生成することにより、データ文書を「生成」する。一例として、生成アプリケーション２０は、ユーザ入力に基づきXML購入要求を形成し、それを受信アプリケーション６０に送信するウェブブラウザを表す。他の例として、生成アプリケーション２０は、データ文書７０にコンタクト情報を保存し、携帯電話やパーソナルデジタルアシスタント（PDA）にデータ文書７０を送信して受信アプリケーション６０で利用させるデスクトップコンピュータ上の住所録アプリケーションを表す。
一部の実施形態において、生成アプリケーション２０は、プロセッサその他の好適な電子計算デバイス上で実行されるソフトウェアプロセスを表す。この説明及び請求項においては、「プロセッサ」とは、汎用コンピュータ、専用マイクロプロセッサ、その他の電子情報を生成、処理、及び／または通信可能な処理デバイスを表す。プロセッサ１１０の例としては、特定用途集積回路（ASIC）、フィールドプログラマブルゲートアレイ（FPGA）、デジタル信号プロセッサ（DSP）、その他の好適な専用または汎用プロセッサがある。
しかし、一般的に、生成アプリケーション２０は、上述の機能を提供する適当なソフトウェア及び／またはハードウェアを表し、及び／または含んでいる。また、図１は生成アプリケーション２０ａと２０ｂを両方とも含むデータ処理システム１０の実施形態を示しているが、データ処理システム１０は生成アプリケーション２０ａと２０ｂのいずれかを含んでもよいし、両方を含んでもよい。さらにまた、一部の実施形態において、１つのデータ処理システム１０の１つの構成要素が必要に応じてデータ文書７０と結合前データ文書７８の両方を生成でき、生成アプリケーション２０ａと２０ｂの両方を表していてもよい。
受信アプリケーション６０は、文書デコーダ５０またはデータ処理システム１０の他のコンポーネントからデータ文書７０を受信し、そのデータ文書７０を用いてタスクまたは動作を実行する。データ処理システム１０は、生成アプリケーション２０と受信アプリケーション６０を接続するネットワークその他の好適な接続コンポーネントを含む。一例として、受信アプリケーション６０は、データ文書７０に含まれる顧客オーダーを処理する、データ処理システム１０中のネットワークされたコンピュータ上で実行されているアプリケーションを表す。他の例として、受信アプリケーション６０は、データ文書７０として移動通信装置にアップロードされたコンタクト情報にアクセスすることができるその移動通信装置上で実行されているアプリケーションを表す。また、一実施形態において、生成アプリケーション２０と受信アプリケーション６０は、動作の異なるフェーズにある、または異なるタスクを実行している同一のアプリケーション、同一のプロセス、または同一のコンポーネントグループを表している。例えば、生成アプリケーション２０は、１つのアプリケーションがデータ文書７０を生成してメモリ１００に格納しているところを表し、受信アプリケーション６０は、そのアプリケーションがデータ文書７０をそのメモリ１００から読み出しているところを表している。一般的に、受信アプリケーション６０は、上述の機能を提供する適当なソフトウェア及び／またはハードウェアの集まりを表し、または含んでいる。一部の実施形態において、受信アプリケーション６０は、コンピュータプロセッサ上で実行されているソフトウェアプロセスを表す。
スキーマコンパイラ４０は、コンパイルされていないスキーマ８０をコンパイルして、コンパイルされたスキーマ８５を作る。一実施形態において、スキーマコンパイラ４０は、コンパイルされたスキーマを生成する。コンパイルされたスキーマは、プリミティブデータの少なくとも１つの配列である。スキーマコンパイラ４０は、コンパイルされたスキーマ８５をデータ処理システム１０のジェネリックエンコーダ３０その他のコンポーネントに供給する。スキーマコンパイラ４０は、ジェネリックエンコーダ３０のコンポーネント、モジュール、その他適当な部分であってもよいし、ジェネリックエンコーダ３０とは物理的に、及び／または論理的に異なるコンポーネントであってもよい。一部の実施形態において、スキーマコンパイラ４０は、コンピュータプロセッサ上で実行されているソフトウェアプロセスである。
ジェネリックエンコーダ３０は、データ文書７０を指定されたデータの定義と結合して、データ文書７０を符号化して、符号化文書７２ａを作る。より具体的には、一部の実施形態において、ジェネリックエンコーダ３０は、生成アプリケーション２０からデータ文書７０を受け取り、スキーマコンパイラ４０からコンパイルされたスキーマ８５を受け取る。ジェネリックエンコーダ３０は、データ文書７０中の１つ以上のデータノード９０をコンパイルされたスキーマ８５中の定義と結合し、結合したデータノードを符号化して符号化文書７２ａを作成する。ジェネリックエンコーダ３０は、上述の機能を提供するのに好適なハードウェア及び／またはソフトウェアを表しているか、または含んでいる。さらにまた、ジェネリックエンコーダ３０は、生成アプリケーション２０または受信アプリケーション６０の一部を表していてもよく、または生成アプリケーション２０または受信アプリケーション６０のいずれとも物理的及び／または論理的に異なるコンポーネントを表していてもよい。一部の実施形態においては、ジェネリックエンコーダ３０は、コンピュータプロセッサ上で実行されているソフトウェアプロセスを表している。
スペシフィックエンコーダ３５は、結合前文書７８を符号化して、符号化文書７２ｂを生成する。より具体的には、一部の実施形態において、生成アプリケーション２０がすでにコンパイルされたスキーマ８５中の定義に結合したデータ文書を受け取る。
このような実施形態において、スペシフィックエンコーダ３５は、結合にはかかわらずに、生成アプリケーション２０から受け取った結合前文書７８を符号化する。スペシフィックエンコーダ３５は、上述の機能を提供する好適なハードウェア及び／またはソフトウェアであればいかなるものを表しても、または含んでもよい。さらにまた、スペシフィックエンコーダ３５は、生成アプリケーション２０または受信アプリケーション６０のコンポーネント、モジュール、またはその他の部分を表していてもよく、またはとは物理的及び／または論理的に異なるコンポーネントを表していてもよい。図１及び以下の説明では、例示を目的として、データ処理システム１０はジェネリックエンコーダ３０とスペシフィックエンコーダを両方とも含むものとするが、実施形態に応じて、データ処理システム１０はジェネリックエンコーダ３０とスペシフィックエンコーダ３５のいずれか一方または両方を含んでいてもよい。一部の実施形態において、スペシフィックエンコーダ３５は、コンピュータプロセッサ上で実行されているソフトウェアプロセスを表す。
文書デコーダ５０は、受信アプリケーション６０による使用のために符号化文書７２を受け取り復号する。特に、文書デコーダ５０は、符号化文書７２から復号文書７４を生成するために、コンパイルされたスキーマ８５を参照する。復号文書７４は、データ文書７０のデータノード９０、またはそのデータノード９０に含まれる情報と実質的に等価な情報を含むその他のマークアップ言語データ構成を含む。一部の実施形態において、復号文書７４は、下のデータ文書７０と同一であってもよい。一部の実施形態において、文書エンコーダ５０は、コンピュータプロセッサ上で実行されているソフトウェアプロセスを表す。
メモリ１００は、データ文書７０、符号化文書７２、復号文書７４、及び／または動作中のデータ処理システム１０のエレメントにより使用される値とパラメータを格納する。メモリ１００は、データを格納するのに好適な揮発性または不揮発性の、ローカルまたはリモートのデバイスならいかなるものでもよく、例えば、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、磁気記憶装置、光記憶装置、その他の好適なデータ記憶装置である。以下の説明において、「メモリ１００」という用語は、データ処理システム１０中のメモリデバイス、データ処理システム１０に結合したメモリデバイス、またはデータ処理システム１０またはそのエレメントがアクセス可能なメモリデバイスを指す。このように、この説明においては、同じ「メモリ１００」であっても、データ処理システム１０の実施形態の構成と内容に応じて、必ずしも物理的に同じデバイスをさしているとは限らない。
図１は、一定数のプロセッサ１１０を含むデータ処理システム１０の一実施形態を示しているが、データ処理システム１０に含まれるプロセッサ１１０の数はいくつであっても好適な数であればよい。また、図１は、別々のプロセッサ１１０上で実行されている生成アプリケーション２０、ジェネリックエンコーダ３０、スペシフィックエンコーダ３５、スキーマコンパイラ４０、文書デコーダ５０、及び、受信アプリケーション６０を含むデータ処理システム１０を示しているが、これらのエレメントのうち２つ以上が同じプロセッサ１１０上で実行されてもよい。結果として、これらのエレメントは、１つ以上のプロセッサ１１０において一括または分散して実行される。
動作中、スキーマコンパイラ４０は未コンパイルスキーマ８０を受信するか、またはその未コンパイルスキーマ８０にアクセスする。スキーマコンパイラ４０は、未コンパイルスキーマ８０を生成し、データ処理システム１０の他のコンポーネントから未コンパイルスキーマ８０を受信し、スキーマコンパイラ４０に結合したメモリ１００から未コンパイルスキーマ８０を読み出し、またはその他の好適な方法で未コンパイルスキーマ８０を取得する。未コンパイルスキーマ８０は、１つ以上の定義ノードを含む。定義ノードは、データ処理システム１０に内で定義された、または認識された、もしくはデータ処理システム１０によりサポートされた、データノード９０の内容、構造、好適な発生回数、及び／またはその他の好適な特徴（以下、集合的に「定義内容」と呼ぶ）を定義している。一実施形態において、データ処理システム１０はＸＭＬ文書７０を処理するように構成され、未コンパイルスキーマ８０はＸＭＬスキーマを含む文書を表す。しかし、未コンパイルスキーマ８０は、データ処理システム１０によりサポートされたマークアップ言語に基づく好適な形式のデータ定義を含む。
スキーマコンパイラ４０は、未コンパイルスキーマ８０をコンパイルして、コンパイル済みスキーマ８５を作成する。未コンパイルスキーマ８０をコンパイルする際、スキーマコンパイラ４０は、未コンパイルスキーマ８０に含まれている冗長な、または不必要な情報を減少または削除することにより、未コンパイルスキーマ８０のサイズを小さくしてもよい。スキーマコンパイラ４０は、未コンパイルスキーマ８０、スキーマコンパイラ４０、及びデータ処理システム１０の特徴と構成に基づき、未コンパイルスキーマ８０をさらに処理するステップを追加的に実行することもできる。図２Ａは、データ処理システム１０の一実施形態において使用されるコンパイル済みスキーマ８５の内容を示す。以下、詳しく説明する。スキーマコンパイラ４０は、コンパイル済みスキーマ８５を作成するために未コンパイルスキーマ８０をコンパイルした後、ジェネリックエンコーダ３０にコンパイル済みスキーマ８５を送信または供給する。一部の実施形態において、スキーマコンパイラ４０は、コンパイル済みスキーマ８５をジェネリックエンコーダ３０に供給するが、それはジェネリックエンコーダ３０とスキーマコンパイラ４０が共にアクセス可能なメモリ１００にコンパイル済みスキーマ８５を保存することにより行う。
適当な時に、ジェネリックエンコーダ３０は、生成アプリケーション２０から１つ以上のデータ文書７０を受け取る。ジェネリックエンコーダ３０は、コンパイル済みスキーマ８５を用いて、データノード９０をコンパイル済みスキーマ８５に結合し、結合データノード９０を符号化して符号化文書７２を作成する。ジェネリックエンコーダ３０は、データノード９０を結合する時、データ文書７０中の各データノード９０に対して、そのデータノードのノードタイプに基づいて、コンパイル済みスキーマ８５中の定義ノード２１０を特定する。ジェネリックエンコーダ３０は、定義ノード２１０中の情報を考慮して冗長であるか、または不必要である情報をこれらのデータノード９０から減少または削除する。このプロセスは、以下、図３に示した一実施形態を参照してより詳しく説明する。
ジェネリックエンコーダ３０は、データ文書７０を符号化する時、データ文書７０に含まれるデータを削除、再構成、代替、再フォーマット、または修正して、データ文書７０のサイズを小さくし、及び／またはデータ文書７０の処理に必要な計算を減少させる。例えば、ジェネリックエンコーダ３０は、一実施形態において、符号化文書７２を生成する際、データ文書７０中で使用されるデリミタの数を減らし、テキストエレメントを情報交換用米国標準コード（ＡＳＣＩＩ）からユニコード・トランスフォーメーション・フォーマット（ＵＴＦ−８）に変換する。ジェネリックエンコーダ３０の動作は、図４Ａないし図４Ｃを参照してより詳しく説明する。
スペシフィックエンコーダ３５は、生成アプリケーション２０により生成された情報も符号化する。より具体的に、スペシフィックエンコーダ３５は、生成アプリケーション２０により生成された結合前文書７８を符号化する。結合前文書７８は、生成アプリケーション２０により生成されてすでにコンパイル済みスキーマ８５と結合されたデータノード９０と実質的に等価な情報を含む１つ以上の（図５に示した）結合済みデータノード５００を含む。スペシフィックエンコーダ３５は、一実施形態において、符号化文書７２を生成する際、結合前文書７８中で使用されるデリミタの数を減らし、テキストエレメントを情報交換用米国標準コード（ＡＳＣＩＩ）からユニコード・トランスフォーメーション・フォーマット（ＵＴＦ−８）に変換する。スペシフィックエンコーダ３５の動作は、図５Ａないし図５Ｃを参照してより詳しく説明する。
文書デコーダ５０は、ジェネリックエンコーダ３０及び／またはスペシフィックエンコーダ３５から符号化文書７２を受け取り、符号化文書７２を復号して復号文書７４を作成する。符号化文書７２を復号する際、文書デコーダ５０は、データ文書７０を再構成、代替、再フォーマット、または再配置して、符号化文書７２を受信アプリケーション６０が使用できる形式に変換する。一例として、文書デコーダ５０は、結合データノード９０を元のデータノード９０またはその元のデータノード９０に含まれる情報と同様な情報を含む他の形式のデータノードに変換する。一実施形態において、文書デコーダ５０は、結合データノード９０をＸＭＬ言語データ構造を表す復号データノード９０に変換する。文書デコーダ５０の動作は、図５を参照してより詳しく説明する。
符号化文書７２を復号した後、文書デコーダ５０は、データ文書７０を受信アプリケーション６０に送信する。受信アプリケーション６０は、その受信アプリケーション６０とデータ処理システム１０の構成と特徴に基づき、好適なやり方で復号文書７４を使用する。例えば、一実施形態において、受信アプリケーション６０は、移動通信装置の電話帳アプリケーションを表し、復号文書７４の復号データノード９０として受信したコンタクト情報を表示することができる。
一部の実施形態において、データ処理システム１０は、データ処理システム１０のコンポーネント間で送信される情報量を減らし、データ文書７０の処理に必要な計算資源を減らすので、メモリ資源、処理資源、パワー資源などが限られていても動作可能である。さらにまた、データ処理システム１０のコンポーネントにより実行される動作では必要な計算量が減らされるので、動作が速くなり効率的になるという利益がある。また、データ処理システム１０は、そのコンポーネントを接続するネットワークその他の接続エレメントを含み、上述の方法はトラフィックを減少させるという利益も提供するものである。
図２Ａは、データ処理システム１０の一実施形態により利用される未コンパイルスキーマ８０の一部の内容を示している。未コンパイルスキーマ８０は、データ処理システム１０により認識、サポート、または理解されたデータノード９０の１つ以上のタイプの定義ノード２１０を含んでいる。一実施形態において、データ処理システム１０はＸＭＬデータ文書を利用し、このような実施形態においては、未コンパイルスキーマ８０がＸＭＬスキーマ構造を用いてこれらのデータノードを定義する。図示した実施形態において、未コンパイルスキーマ８０は、複数の定義ノード２１０を含む。各定義ノード２１０は、データ処理システム１０によりサポートされたデータノード９０のタイプを定義する。データノード９０は、図４Ａを参照してより詳細に説明する。
定義ノード２１０は、関連するデータノード９０の内容、フォーマット、及び／またはその他の特徴を定義するのに好適なスキーマ定義またはその他のデータ定義を表す。また、未コンパイルスキーマ８０は、１つ以上の異なるタイプの定義ノード２１０を含み、各定義ノード２１０はデータ処理システム１０のコンポーネントによりそれぞれの方法で処理される。より詳細は以下に説明する。例えば、一実施形態において、データ処理システムは、ＸＭＬスキーマ標準規格に基づくスキーマタイプを含む未コンパイルスキーマ８０を利用する。スキーマタイプには、例えば、スキーマ、エレメント、属性、名前空間、シンプルタイプ、コンプレックスタイプ、パーティクル、グループ、ワイルドカード、属性ユースノード等が含まれるが、これに限定されない。
定義ノード２１０は、関連する定義ノード２１０の構造に応じて他の定義ノードを含んでもよい。この説明の目的において、一定義ノード２１０に含まれる定義ノード２１０は、その一定義ノード２１０の「子」と考えられ、その一定義ノード２１０はその含まれる定義ノード２１０の「親」と考えられる。例えば、図示した未コンパイルスキーマ８０において、定義ノード２１０ｂは、定義ノード２１０ｃと２１０ｄに含まれ、定義ノード２１０ｄは、定義ノード２１０ｅ、２１０ｆ、２１０ｇ、及び２１０ｈを含む。このように、定義ノード２１０ｃと２１０ｄは定義ノード２１０ｂの子ノードである。同様に、定義ノード２１０ｅ、２１０ｆ、２１０ｇ、及び２１０ｈは、定義ノード２１０ｄの子ノードである。
図２Ｂは、スキーマコンパイラ４０の一部の実施形態により利用される方法により未コンパイルスキーマ８０をコンパイルする際のスキーマコンパイラ４０の動作を示す。上述の通り、スキーマコンパイラ４０は、データ処理システム１０の他のコンポーネントから未コンパイルスキーマ８０を受信し、メモリ１００から未コンパイルスキーマ８０を読み出し、独立して未コンパイルスキーマ８０を生成し、またはその他の好適な方法で未コンパイルスキーマ８０を取得する。スキーマコンパイラ４０は、データ処理システム１０によりサポートされたデータ定義を格納するのに必要なメモリ空間量を減らしつつ、未コンパイルスキーマ８０をコンパイルする。
より具体的に、スキーマコンパイラ４０は、未コンパイルスキーマ８０を取得して、その未コンパイルスキーマ８０の解析を開始する。図示した実施形態において、スキーマコンパイラ４０は、未コンパイルスキーマ８０中の各定義ノード２１０に対して、ノードアレイ２５０と名前アレイ２６０を生成する。ノードアレイ２５０と名前アレイ２６０は、それぞれ好適な形式のデータ構造を表し、例えば、アレイ、レコード、スタック、オブジェクト、またはその他の好適なデータ構造を含む。ノードアレイ２５０は、未コンパイルスキーマ８０で定義された定義ノード２１０の階層関係を表す、ノードエントリー２５２として格納された情報を含む。各ノードエントリー２５２は、そのノードエントリー２５２と関連づけられた定義ノード２１０の子と、その定義ノードのその他の特性とを特定するまた、各ノードエントリー２５２は、同じ定義ノード２１０と関連づけられた名前アレイ２６０中の名前エントリー２６２への参照２４４を含む。参照２４４は、ポインター、リンク、その他の形式の参照を表す。
ノードエントリー２５２は、定義されたノード９０の内容、構造、フォーマット、及び／またはその他の特徴を記述する好適なその他の情報を含んでもよい。例えば、一実施形態において、ノードエントリー２５２は、最小発生値２８０及び最大発生値２８２等の情報を含む。図示した実施形態において、最小発生値２８０と最大発生値２８２は、それぞれ関連するノード９０が親のインスタンス内に現れるべき最小回数と最大回数を表し、関連する定義ノード２１０と関連づけられたＸＭＬスキーマエレメントのminOccursおよびmaxOccursからスキーマコンパイラ４０により生成される。例えば、パーティクルエントリー２５４ｘの最小発生値２８０と最大発生値２８２は、コンパイル済みスキーマ８５による「書籍」エレメントにおいて「書名」エレメントが最低１回かつ最高１回現れるべきことを示している。
名前アレイ２６０は、その定義ノード２１０のテキスト名を特定する各定義ノード２１０の名前エントリー２６２を含む。一実施形態において、名前エントリー２６２は、定義ノード２１０のテキスト名を指示するテキスト識別子２６４を含む。一実施形態において、名前エントリー２６２は、その名前エントリー２６２と関連づけられたノードエントリー２５２への逆参照も含む。一般的に、名前エントリー２６２は、適当な追加的情報を含んでもよい。
スキーマコンパイラ４０は、未コンパイルスキーマ８０を解析する際、そのスキーマコンパイラ４０により特定された未コンパイルスキーマ８０中の各追加的定義ノード２１０に対してノードアレイ２５０中に新しいノードアレイ２５２を生成する。定義ノードのタイプに応じて、スキーマコンパイラ４０は、新しい名前エントリー２６２を名前アレイ２６０に追加する。スキーマコンパイラ４０は、この他のステップや動作を適宜実行して、未コンパイルスキーマ８０をコンパイルする。
例えば、図示して実施形態において、ＸＭＬスキーマ定義を利用して、スキーマコンパイラ４０は未コンパイルスキーマ８０の各スキーマノードに対してノードエントリー２５２を生成する。図２Ａの定義ノード２１０ａと２１０ｃ等のグループノードに対して、スキーマコンパイラ４０は、ノードアレイ２５０中に、「グループエントリー２５６」と呼ばれる、一タイプのノードエントリー２５２を生成する。グループエントリー２５６は、関連するグループ定義ノード２１０のグループタイプを指定するグループ識別子２７２と、グループ定義ノード２１０の各子に対するパーティクルエントリー２７４を含む１つ以上のデリゲーションテーブル２７０とを含む。各パーティクルエントリー２７４は、１つのエレメントまたは関連するグループの子である他のグループと関連づけられたエントリーへの参照２４４を含む。例えば、図２Ａの未コンパイルスキーマ８０をコンパイルする際、スキーマコンパイラ４０は、定義ノード２１０ｃに対して状態デリゲーションテーブル２７０を生成する。その状態デリゲーションテーブル２７０は、定義ノード２１０ｆ−ｇを含む、定義ノード２１０ｃの子のノードエントリー２５２へのポインターを含む。グループエントリー２５６は、スキーマコンパイラ４０の構成と特徴に基づき、さらに別の情報を含んでもよい。例えば、一実施形態において、グループエントリー２５６は、関連づけられた状態デリゲーションテーブル２７０のサイズを指定するグループエントリー２５６にサイズ値２５８を含める。
上述の通り、グループエントリー２５６は、１つ以上の状態デリゲーションテーブル２７０を含んでいる。一実施形態において、スキーマコンパイラ４０がすべてのグループノード、または「選択された」グループノード（例えば定義ノード２１０ｇ）のグループエントリーを生成する時、スキーマコンパイラ４０はその定義ノード２１０に対して単一の状態デリゲーションテーブル２７０を生成する。スキーマコンパイラ４０は、未コンパイルスキーマ８０中の「シーケンス」グループノードに来たとき、「シーケンス」グループの各子定義ノード２１０の状態デリゲーションテーブル２７０を生成する。このように、未コンパイルスキーマ８０をコンパイルする際、スキーマコンパイラ４０は、子定義ノード２１０ｆ−ｋのそれぞれについて１つずつ、定義ノード２１０ｄの４つの別々な状態デリゲーションテーブル２７０を生成する。このような状況において、各状態デリゲーションテーブル２７０は、関連する「シーケンス」グループ定義ノード２１０を解析する各ステップにつづく、残りの子定義ノード２１０への参照を含む。
例えば、エレメント「Ａ」、エレメント「Ｂ」、及びエレメント「Ｃ」を含むと定義された「シーケンス」グループ定義ノード２１０について、スキーマコンパイラ４０は、エレメント「Ａ」、エレメント「Ｂ」、及びエレメント「Ｃ」への別々の参照２４４を有する第１の状態デリゲーションテーブル２７０と、エレメント「Ｂ」及びエレメント「Ｃ」への参照２４４を有する第２の状態デリゲーションテーブル２７０と、エレメント「Ｃ」への参照２４４を有する第３の状態デリゲーションテーブル２７０を生成する。対照的に、スキーマコンパイラ４０のこの実施形態においては、同じエレメントを含むとして定義された「全」グループ定義ノード２１０は、各エレメント「Ａ」、エレメント「Ｂ」、及びエレメント「Ｃ」への別々の参照２４４を有する単一の状態デリゲーションテーブル２７０だけを有する。
エレメントノード、属性ノード、インスタンス化するときに定義ノード２１０ｈや２１０ｑなどのサブスタンスを含むＸＭＬオブジェクトを定義するその他の形式の非グループノードに対して、スキーマコンパイラ４０は、ノードアレイ２５０中に、「サブスタンスエントリー２５４」と呼ばれる、一タイプのノードエントリー２５２を生成する。サブスタンスエントリー２５４は、関連するエレメントノードと関連づけられた名前エントリー２６２への参照２４４を含む。サブスタンスエントリー２５４と関連づけられた定義ノード２１０についてが子定義ノード２１０を含む場合、サブスタンスエントリー２５４は、その子定義ノード２１０と関連づけられたサブスタンスエントリー２５４またはグループエントリー２５６への参照２４４を含む。サブスタンスエントリー２５４は、スキーマコンパイラ４０の構成と特徴に基づき、さらに別の情報を含んでもよい。例えば、サブスタンスエントリー２５４は、そのサブスタンスエントリー２５４の「エレメント」、「属性」、または「ワイルドカード」等のノードタイプを指定するサブスタンス識別子を含んでもよい。
スキーマコンパイラ４０は、未コンパイルスキーマ８０を解析するに従って、各定義ノード２１０のノードエントリー２５２を生成し、親定義ノード２１０の子のノードエントリーへの適当な参照２４４を有する、その定義ノード２１０の各子のノードエントリー２５２を生成しながら、未コンパイルスキーマ８０の階層構造を調べていく。スキーマコンパイラ４０は、適宜、ノードエントリー２５２の名前アレイ２６０に名前エントリー２６２も生成する。スキーマコンパイラ４０は、未コンパイルスキーマ８０の解析が終わると、またはその他の適当な時に、コンパイル済みスキーマ８５を表すファイルにノードアレイ２５０と名前アレイ２６０を両方とも書き込む。また、スキーマコンパイラ４０は、コンパイル済みスキーマ８５を、ジェネリックエンコーダ３０がデータ文書７０の符号化で利用できるようにするが、これについては図４Ａないし図４Ｃを参照してより詳しく説明する。
一部の実施形態において、スキーマコンパイラ４０は、各定義ノード２１０のために保持されている情報量を減少させることにより、未コンパイルスキーマ８０よりも小さいが未コンパイルスキーマ８０と同等の情報を提供するコンパイル済みスキーマ８５を生成する。さらにまた、コンパイル済みスキーマ８５の構造により、コンパイル済みスキーマ８５の個別のエレメントへのアクセスが非常に柔軟かつ単純になる。結果として、スキーマコンパイラ４０と上述のコンパイル済みスキーマ８５の生成方法は、データ処理システム１０に複数の動作上の利益を与える。
図３は、コンパイル済みスキーマ８５のノードエントリー２５２に順次アクセスする方法を示す図である。そのコンパイル済みスキーマ８５は、データ処理システム１０の実施形態の処理コンポーネント３００により使用される。コンパイル済みスキーマ８５のノードエントリー２５０のエレメントに、階層的にではなく順次アクセスすることにより、複数のコンパイル済みスキーマ８５を連結するなどの動作をより効率的に実行することができる。特に、階層的にノードエントリー２５２にアクセスするには、そのノードエントリー２５２と関連づけられた各子ノードエントリー２５２にアクセスするためにそのノードエントリー２５２に少なくとも２回アクセスする必要がある。結果として、順次アクセスとすれば、一定の動作を実行するために必要な時間と計算ステップを減らすことができる。
処理コンポーネント３００は、スキーマコンパイラ４０、ジェネリックエンコーダ３０などを表し、または、データ処理システム１０のその他のコンポーネント（図１に示していないコンポーネントや上述していないコンポーネントも含む）であってコンパイル済みスキーマ８５を処理、管理、または利用するコンポーネントを表す。一例として、処理コンポーネント３００は、データ処理システム１０上のコンパイル済みスキーマ８５を管理する、データ処理システム１０のデータ管理モジュールを表してもよい。他の例として、以下により詳しく説明するように、ジェネリックエンコーダ３０の一部の実施形態は、コンパイル済みスキーマ８５を利用して、符号化の際、データ文書７０のデータノード９０を定義ノード２１０に結合する。このように、処理コンポーネント３００は、複数のコンパイル済みスキーマ８５を連結する上記の方法を使用するスキーマコンパイラ４０の一実施形態を表す。一般的に、処理コンポーネント３００は、上記の機能を好適に提供するハードウェア及び／またはソフトウェアの集まりを表し、コンパイル済みスキーマ８５を用いる動作を実行する際、上記の方法を用いてコンパイル済みスキーマ８５中の情報にアクセスする。
処理コンポーネント３００は、動作中、コンパイル済みスキーマ８５を受け取り、読み出し、または生成する。処理コンポーネント３００は、矢印３７２ａで示したように、コンパイル済みスキーマ８５のノードアレイ２５０のノードエントリー２５２にアクセスする。アクセスされるノードエントリー２５２は、ノードアレイ２５０中の最初のノードエントリー２５２、コンパイル済みスキーマ８５の１つのエレメントと関連づけられたノードエントリー２５２、またはコンパイル済みスキーマ８５のその他のノードエントリー２５２である。例示を目的として、この説明では、処理コンポーネント３００がノードアレイ２５０中の最初のノードエントリー２５２（以下、「第１のノードエントリー２５２ａ」と呼ぶ）にアクセスすると仮定する。処理コンポーネント３００は、コンパイル済みスキーマ８５の最初のラインを読むことにより、他のコンポーネント、アプリケーションから取得したインデックスまたはポインターを用いることにより、または、他の適当な方法により、第１のノードエントリー２５２ａにアクセスする。処理コンポーネント３００は、ノードアレイ２５０の第１のノードエントリー２５２ａにアクセスすると、データ処理システム１０の一部の実施形態において、コンパイル済みスキーマ８５の特徴を用いて後続のノードエントリー２５２に順次アクセスする。より具体的に、処理コンポーネント３００は、その定義ノード２１０のノードタイプと関連づけられたサイズ値に基づき、ノードエントリー２５２のサイズを決定する。処理コンポーネント３００は、その定義ノード２１０のサイズを用いてノードアレイ２５０中の次の定義ノード２１０にアクセスする。
例えば、図示した実施形態において、処理コンポーネント３００はメモリ１００にサイズテーブル３１０を保持する。サイズテーブル３１０は、各ノードタイプ３２０と関連づけられた１つ以上のサイズ値を指定する。処理コンポーネント３００は、ノードエントリー２５２のノードタイプ３２０を決定した後、このサイズテーブル３１０にアクセスして、そのノードエントリー２５２のサイズを決定する。図３には好適なサイズ値をサイズテーブル３１０に保持する処理コンポーネント３００の実施形態を示したが、処理コンポーネント３００は好適なものであればいかなる仕方でサイズ値を保持してもよい。また、処理コンポーネント３００は、動作中にデータ処理システム１０の他のコンポーネントからサイズ値を受け取ってもよいし、必要なサイズ値を決定してもよい。一般的に、処理コンポーネント３００は、サイズ値をいかなる好適なやり方でも保持、受け取り、生成、または取得することができる。
ＸＭＬをサポートするデータ処理システム１０の一実施形態において、コンパイル済みスキーマ８５のノードアレイ２５０は、以下のノードと関連づけられたノードエントリー２５２を含んでもよい：未コンパイルスキーマ８０中のスキーマノード、エレメントノード、属性ノード、名前空間ノード、シンプルタイプノード、コンプレックスタイプノード、パーティクルノード、グループノード、ワイルドカードノード、及び属性使用ノード。また、ノードアレイ２５０は、各グループ定義ノード２１０に対して、そのグループ定義ノード２１０と関連づけられた状態デリゲーションテーブル２７０を表す１つ以上のノードエントリー２５２を含む。上述の通り、ノードエントリー２５２のサイズは、少なくとも部分的には、そのノードエントリー２５２と関連づけられた定義ノード２１０のタイプに基づく。
より具体的に、データ処理システム１０の図示した実施形態において、エレメントノード、属性ノード、コンプレックスタイプノード、パーティクルノード、属性使用ノードと関連づけられたノードエントリー２５２は関連づけられた定義ノード２１０のタイプに基づいて決められたサイズを有する。例えば、エレメントノードと関連づけられたノードエントリー２５２は８バイトの固定サイズを有する。処理コンポーネント３００は、固定サイズノードエントリー２５２と関連づけられたノードタイプを判断して、そのノードタイプの固定サイズ値３５０を指定する記憶された情報にアクセスすることにより、固定サイズノードエントリー２５２のサイズを決定する。 例えば、図示した実施形態において、処理コンポーネント３００はメモリ１００にサイズテーブル３１０を保持する。サイズテーブル３１０は、各ノードタイプ３２０と関連づけられた１つ以上のサイズ値を指定する。処理コンポーネント３００は、ノードエントリー２５２のノードタイプ３２０を決定した後、このサイズテーブル３１０にアクセスして、そのノードエントリー２５２のサイズを決定する。しかし、一般的に、処理コンポーネント３００またはその他のデータ処理システム１０は、固定サイズノードタイプ３２０のサイズを何らかの好適な形式で示す固定サイズ値２５０を何らかの適当な方法により保持する。
また、データ処理システム１０のこの実施形態において、スキーマノード、名前空間ノード、シンプルタイプノード、グループノード、及びワイルドカードノードと関連づけられたノードエントリー２５２は可変サイズを有する。可変サイズは、そのノードタイプ３５０と関連づけられた固定部分と、可変サイズノードエントリー２５２のコンテントにより決まる可変部分との両方に基づく。特に、可変サイズは、そのノードタイプ３５０と関連づけられたベースサイズ値３６０と１つ以上のコンテント依存値の和である。各コンテント依存値は、そのノードタイプ３５０のコンテントのタイプのコンテントサイズ値３６２と、可変サイズノードエントリー２５２と関連づけられた定義ノード２１０が有するコンテントの量との積を表す。コンテントは、その定義ノード２１０の子定義ノード２１０、または関連づけられたノードエントリー２５２のサイズに影響するその他の適当なコンテントを表す。
例えば、この実施形態において、名前空間ノードと関連づけられたノードエントリー２５２は、以下のサイズ値を有する：ベースサイズ値３６０、関連づけられた名前空間定義ノード２１０中に定義された各エレメントに対する第１のコンテントサイズ値３６２、関連づけられた名前空間定義ノード２１０中に定義された各属性に対する第２のコンテントサイズ値３６２、及び関連づけられた名前空間定義ノード２１０中に定義された各タイプに対する第３のコンテントサイズ値。このように、ベースサイズ値３６０を８バイトと仮定し、第１のコンテントサイズ値３６２を１バイトと仮定し、第２のコンテントサイズ値３６２を１バイトと仮定し、第３のコンテントサイズ値３６２を２バイトと仮定した場合、５つのエレメント、１５の属性、及び４つのタイプが定義された名前空間定義ノード２１０と関連づけられたノードエントリー２５２のコンテントサイズ値は、次のようになる：
コンテントサイズ値=(1*5)+(1*15)+(2*4)=28バイト。
さらにまた、名前空間値のベースサイズ値３６０が１０バイトの場合、この例の名前空間の可変サイズは28+10=38バイトとなる。このように、未コンパイルスキーマ８０により形成された名前空間定義ノード２１０と関連づけられた、５つのエレメント、１５の属性、４つのタイプが定義されたノードエントリー２５２のサイズは、３８バイトである。
結果として、１つのノードエントリー２５２が可変サイズノードエントリー２５２であるとの判断に応じて、処理コンポーネント３００は、サイズテーブル３１０またはデータ処理システム１０中のその他の適当な情報にアクセスすることにより、そのノードエントリー２５２のサイズを決定し、その関連づけられた定義ノード２１０のノードタイプのベースサイズ値３６０と１つ以上のコンテントサイズ値３６２を決定する。処理コンポーネント３００は、ノードエントリー２５２に含まれる１つ以上のタイプのコンテントの量を決定する。コンテント量を決定した後、処理コンポーネント３００は、１つのタイプのコンテントの量にそのタイプのコンテントのコンテントサイズ値を乗じることにより、１つ以上のコンテント依存サイズ値を決定する。処理コンポーネント３００は、ノードエントリー２５２に含まれる各コンテントタイプについてベースサイズ値３６０とコンテント依存サイズ値を加えることにより、可変サイズノードエントリー２５２のサイズを計算する。
また、データ処理システム１０の一実施形態において、グループエントリー２５４等のグループノードと関連づけられたノードエントリー２５２は、上述のように、ノードアレイ２５０中の１つ以上の状態デリゲーションテーブル２７０を参照する。データ処理システム１０の一実施形態において、状態デリゲーションテーブル２７０は、ノードアレイ中の関連づけられた状態デリゲーションテーブル２７０のサイズを指示する明示的サイズ値２９０を含む。このように、その状態デリゲーションテーブル２７０に記憶された明示的サイズ値２９０にアクセスすることにより、ノードアレイ２５０中の状態デリゲーションテーブル２７０のサイズを決定することができる。
第１のノードエントリー２５２ａのサイズを決定した後、処理コンポーネント３００は、ノードアレイ２５０中の第１のノードエントリー２５２ａの直後のノードエントリー２５２ｂと関連づけられたインデックス３７０ｂを計算する。特に、処理コンポーネントは、ノードアレイ２５０中の次のノードエントリー２５２ｂを見つけるためのインデックス３７０ｂとして第１のノードエントリー２５２ａのサイズを使用するか、または第１のノードエントリー２５２ａのインデックス３７０ａに第１のノードエントリー２５２ａのサイズを加えて、次のノードエントリー２５２ｂのインデックス３７０ｂを決定する。処理コンポーネント３００は、矢印３７２ｂで示したように、次のノードエントリー２５２ｂにアクセスする。処理コンポーネント３００は、上記のプロセスを繰り返し、次のノードエントリー２５２ｃ−ｄのサイズを決定し、次のノードエントリー２５２ｂに続くノードエントリー２５２ｃ−ｄのインデックス３７０ｃ−ｄを計算し、矢印３７２ｃ−ｄに示したようにノードエントリー２５２ｃ−ｄにアクセスする。結果として、処理コンポーネント３００は、この方法を用いて、ノードアレイ２５０の各ノードエントリー２５２に順次アクセスすることができ、ノードアレイ２５０内の各ノードエントリー２５２または選択されたノードエントリー２５２に操作を加える。例えば、コンパイル済みスキーマ８５が新しい記憶場所に移された場合、処理コンポーネント３００は、ノードアレイ２５０の各ノードエントリー２５２中のポインターを修正して、コンパイル済みスキーマ８５の新しい記憶場所を反映させる。
このように、処理コンポーネント３００は、上記の方法により、データ処理システム１０の一部の実施形態中のノードエントリー２５２に順次アクセスすることができる。処理エレメント３００は、順次アクセスにより、未コンパイルスキーマ８０に階層的にアクセスする場合と比べて速く、関連づけられた未コンパイルスキーマ８０の各定義ノード２１０へのアクセスを含むような一定の動作を実行することができる。結果として、順次アクセスにより処理コンポーネント３００の動作速度が速くなる。
さらにまた、ノードエントリー２５２に順次アクセスすることにより、処理コンポーネント３００は問題のノードエントリー２５２の各子にアクセスするので、ノードエントリー２５２に２回以上アクセスすることになる。これにより、処理コンポーネント３００がノードエントリー２５２に操作を繰り返し実行すると望ましくない結果となる。このように、順次アクセスにより、処理コンポーネント３００がノードエントリー２５２にすでにアクセスしたかどうかを決定する必要が無くなるので、タスクの計算上の複雑さが軽減される。
図４Ａは、データ処理システム１０の一実施形態により利用されるデータ文書７０の内容を示している。データ文書７０は複数のデータノード９０を含む。データノード９０は、マークアップ言語データオブジェクト、エレメント、その他の構造を表す。図示した実施形態において、データノード９０はＸＭＬ構造を表す。データノード９０はその他のデータノード９０を含んでもよい。例示を目的として、データノード９０ａは、データノード９０ｄ−ｆを含み、一方、データノード９０ｂはデータノード９０ｇ−ｋを含む。上で留意したように、図４Ａないし４Ｃは、ＸＭＬデータ文書７０を使用するデータ処理システム１０の一実施形態に焦点を絞っているが、処理システム１０の実施形態はいかなる好適なマークアップ言語により構造化されたデータ文書７０を使用するものであってもよい。
データノード９０には、テキスト開始デリミタ４１０が含まれる、またはテキスト開始デリミタ４１０が先行する。さらにまた、データノード９０には、テキスト終了デリミタ４２０が含まれる、またはテキスト開始デリミタ４２０が後に続く。テキスト開始デリミタ４１０とテキスト終了デリミタ４２０は、それぞれ、データノード９０の始めまたは終わりを示すテキストである。テキスト開始デリミタ４１０とテキスト終了デリミタ４２０は、これらのデリミタが区切るデータノード９０の一部を表し、データノード９０の内容とは完全に区別されたテキストを表す。一実施形態において、テキスト開始デリミタ４１０とテキスト終了デリミタ４２０は、それぞれＸＭＬの開始及び終了タグを表す。
また、テキスト開始デリミタ４１０及び／またはテキスト終了デリミタ４２０は、関連づけられたデータノード９０のノードタイプを指示する。一実施形態において、テキスト開始デリミタ４１０とテキスト終了デリミタ４２０は、関連づけられたデータノード９０のノードタイプを指示するテキスト識別子２６４を含む。ジェネリックエンコーダ３０は、データノード９０のテキスト識別子２６４を用いて、データノード９０と関連づけられたノードエントリー２５２をノードアレイ２５０中に特定する。詳細は図４Ｂを参照して説明する。
図４Ｂは、一実施形態によるジェネリックエンコーダ３０の動作と内容を示す図である。データ処理システム１０の実施形態において、結合アプリケーション３９０とともにジェネリックエンコーダ３０を使用して、コンパイル済みスキーマ８５に基づきデータ文書７０を符号化して、データ文書７０により保持される情報量を減らす。特に、ＸＭＬその他のマークアップ言語を利用して、人間が読んで意味が分かるデータ文書７０を生成するので、受信アプリケーション６０の観点からは余分な情報が含まれていることが多い。このように、ジェネリックエンコーダ３０は、標準ＸＭＬ文書を受け取り、このＸＭＬ文書中のデータノード９０を指定されたＸＭＬスキーマに結合し、各データノード９０のために保持される情報量を減らす。上で述べたように、データ文書７０に格納される情報量を減らすことにより、受信アプリケーション６０をサポートするのに必要な記憶容量、及び／またはデータ文書７０にアクセス、記憶、及び／または処理するための時間量を減らす。
ジェネリックエンコーダ３０は、データ文書７０を受け取り、このデータ文書中のデータノード９０を符号化する。そのプロセスにおいて、ジェネリックエンコーダ３０は、結合アプリケーション３９０を用いて、コンパイル済みスキーマ８５のノードを結合する。図１を参照して説明したように、ジェネリックエンコーダ３０は、データ処理システム１０内の物理的コンポーネントを表すか、データ処理システム１０で実行されているソフトウェアを表すか、またはその他の好適なソフトウェア及び／またはハードウェアの集まりを含む計算資源または処理資源を表す。
結合アプリケーション３９０は、スキーマコンパイラ４０、メモリ１００、またはデータ処理システム１０の他の適当なエレメントからコンパイル済みスキーマ８５を受け取り、ジェネリックエンコーダ３０及び／またはデータ処理システム１０の他のエレメントから受け取った結合要求に応じて、そのコンパイル済みスキーマ８５と関連づけられたデータ文書７０のデータノード９０を結合する。結合アプリケーション３９０は、データ処理システム１０内の物理的コンポーネント、データ処理システム１０上で実行されているソフトウェアプロセス、及び／またはその他の計算または処理資源を表す。データ処理システム１０の実施形態において、結合アプリケーション３９０はバーチャルマシンを有し、このバーチャルマシンは、データ処理システム１０の他のエレメントとインターラクションする１つ以上のアプリケーションプログラミングインターフェイス（ＡＰＩ）をサポートする。ジェネリックエンコーダ３０及び／またはデータ処理システム１０の他のエレメントは、これらのＡＰＩを用いて、結合要求を結合アプリケーション３９０に送り、結合応答を結合アプリケーション３９０から受け取る。詳細は以下に説明する。また、結合アプリケーション３９０とジェネリックエンコーダ３０は、図示したように、物理的に離散的なコンポーネントまたは別個のソフトウェアプロセスを表し、または上述の両方のエレメントの機能を提供する単一のコンポーネントまたはプロセスを表す。
ジェネリックエンコーダ３０は、動作中、生成アプリケーション２０からデータ文書７０を受け取るか、またはデータ文書７０にアクセスする。ジェネリックエンコーダ３０はデータ文書７０を解析する。ジェネリックエンコーダ３０がデータ文書７０を分析を進めていくと、テキスト開始デリミタ４１０とテキスト終了デリミタ４２０が現れる。テキスト開始デリミタ４１０とテキスト終了デリミタ４２０は、データ文書７０に含まれる個別のデータノード９０の始めと終わりをそれぞれ表している。ジェネリックエンコーダ３０は、データノード９０の始めを検知すると、そのデータノード９０を特定した結合要求を結合アプリケーション３９０に送る。結合要求は、テキスト開始デリミタ４１０に含まれる、ＸＭＬタグ等のテキスト識別子２６４によりデータノード９０を特定する。一実施形態において、ジェネリックエンコーダ３０は、結合アプリケーション３９０にサポートされた一組のＪａｖａ(登録商標)メソッドstartElement()とstartAttribute()を用いて結合要求を実行する。これらのメソッドは、パラメータとしてＸＭＬエレメントとアトリビュートを表すデータノード９０のテキスト識別子２６４を受け取り、コンパイル済みスキーマ８５中のそのテキスト識別子２６４と関連づけられた定義ノード２１０の数値識別子４５０を返す。例えば、図３Ａに示したデータ文書７０を用いて、ジェネリックエンコーダ３０は、図４Ａのデータノード９０ｂのテキスト開始デリミタ「<TITLE>」に遭遇すると、startElement()メソッドを次のように呼び出してデータノード９０ｂを結合する：
startElement(“TITLE”)
このメソッドの呼び出しと関連づけられた結合要求を受け取ると、結合アプリケーション３９０は、コンパイル済みスキーマ８５のノードアレイ２５０にアクセスしてそのテキスト識別子２６４と関連づけられたノードエントリー２５２を特定する。より具体的には、結合アプリケーション３９０は、階層的または順次に、ノードアレイ２５０と名前アレイ２６０にアクセスして、テキスト識別子２６４とマッチするストリングを含む名前エントリー２６２（「マッチした名前エントリー」）を探す。マッチした名前エントリーは、それに関連づけられたノードエントリー２５２（「マッチしたノードエントリー」）を特定する情報を含む。例えば、一部の実施形態において、各名前エントリー２６２は、その名前エントリー２６２と関連づけられたノードエントリー２５２（図４Ｂの矢印２７２で示す）を特定するポインターを含む。上記の実施形態において、結合アプリケーション３９０は、テキスト識別子２６４をマッチした名前エントリーとマッチすることにより、マッチング名前エントリー２６２を決定し、マッチした名前エントリーに含まれたポインターに従ってマッチしたノードエントリーを特定してもよい。
マッチしたノードエントリー２５２に含まれる情報に基づいて、結合アプリケーション３９０は、そのマッチしたノードエントリー２５２と関連づけられた数値識別子４５０を特定する。一部の実施形態において、ノードエントリー２５２は数値識別子フィールドを含み、数値識別子４５０はマッチしたノードエントリー２５２の数値識別子フィールドの値を表す。結合アプリケーションは、ジェネリックエンコーダ３０に数値識別子を返す。例えば、ノード９０ｂのテキスト識別子２６４（この場合「TITLE」）に対する結合要求の受け取りに応じて、結合アプリケーション３９０は、そのテキスト識別子と関連づけられた数値識別子４５０（この場合「４０」）を指定する応答を送る。
ジェネリックエンコーダ３０は、テキスト識別子２６４をそのデータノード９０と関連づけられた数値識別子４５０と置換する符号化ノード４６０を生成する。ジェネリックエンコーダ３０は、データノード９０の内容の分析を係属し、データノード９０を特定から分析した情報を符号化ノード４６０に加える。ジェネリックエンコーダ３０は、データノード９０の子ノードの始めを示すテキスト開始デリミタ４１０を分析した場合、上記のプロセスをこの子ノードにも繰り返す。
また、一部の実施形態において、ノードアレイ中のノードエントリー２５２は、そのノードエントリー２５２の子と関連づけられた他のノードエントリー２５２があれば、それを特定する。上記の実施形態において、結合アプリケーション３９０は、ジェネリックエンコーダ３０により完了された分析に関する状態情報を保持する。特に、結合アプリケーション３９０は、現在分析されているデータノード９０と関連づけられたノードエントリー２５２を特定する情報を保持する。上記の実施形態において、結合アプリケーション３９０は、後続の結合要求のテキスト識別子２６４とノードアレイ２５０中のノードエントリー２５２とのマッチを試みるとき、テキスト識別子２６４が現在処理されているデータノードの子と関連づけられていると仮定して、その前にマッチされたノードエントリー２５２の子と関連づけられたノードエントリー２５２のみとテキスト識別子２６４をマッチするよう試みる。
さらにまた、ジェネリックエンコーダ３０は、データノード９０ｂの終わりまたはデータノード９０ｂの子ノードを特定するテキスト終了デリミタ４２０を分析するとき、テキスト終了デリミタ４２０に含まれたＸＭＬタグ等のテキスト識別子２６４によりデータノード９０を特定する他の結合要求を送ることにより、データノード９０ｂの結合を完了する。一実施形態において、ジェネリックエンコーダ３０は、結合アプリケーション３９０にサポートされた他のＪａｖａ（登録商標）メソッドendElement()を用いて結合要求を実行する。これらのメソッドは、パラメータとしてＸＭＬエレメントとアトリビュートを表すデータノード９０のテキスト識別子２６４を受け取り、コンパイル済みスキーマ８５中のそのテキスト識別子２６４と関連づけられた定義ノード２１０の数値識別子４５０を返す。例えば、図３Ａに示したデータ文書７０を用いて、ジェネリックエンコーダ３０は、図４Ａのデータノード９０ｂのテキスト終了デリミタ「<TITLE>」に遭遇すると、endElement()メソッドを次のように呼び出してデータノード９０ｂの結合を終了する：
endElement(“TITLE”)
結合アプリケーション３９０は、startElementメソッドを用いて生成した結合要求を参照して上で説明したのと同様の方法を用いて、結合要求に含まれたテキスト識別子２６４をノードアレイ２５０中のノードエントリーーとマッチさせることを試みる。一部の実施形態において、結合アプリケーション３９０は、ジェネリックエンコーダ３０により実行された分析と関連づけられた状態情報を保持する。上記の実施形態において、結合アプリケーション３９０は、endElement()メソッドを用いて結合要求を受け取ったとき、startElement()の最も最近の呼び出しの結果として受け取ったノードエントリー２５２とのみその結合要求のテキスト識別子２６４をマッチするよう試みる。上述のように、結合アプリケーション３９０は、endElement()をマッチしたノードエントリーとマッチさせた後、マッチしたノードエントリーに格納された通知識別子４５０を返す。あるいは、結合アプリケーション３９０が状態情報を保持するデータ処理システム１０の一部の実施形態において、ジェネリックエンコーダ３０は、現在処理されているデータノード９０の範囲を正確に示すためだけにendElement()を用いてもよい。上記の実施形態において、結合アプリケーション３９０は、状態情報を更新して、endElement()の呼び出しに応じてジェネリックエンコーダ３０が現在処理されているデータノード９０の終わりに到達したことを示し、デフォルト値を返すか、まったく値をかえさない。
ジェネリックエンコーダ３０は、データ文書７０を分析する際、データノード９０を符号化するための追加的ステップを実行する。例えば、一部の実施形態において、ジェネリックエンコーダ３０はデータ文書７０に含まれたデリミタ数を減らす。ジェネリックエンコーダ３０は、データ文書７０のフォーマットに関する一定の仮定をして、標準ＸＭＬフォーマットにある内在的冗長性を利用することにより、符号化文書７２のサイズをさらに減らしてもよい。一部の実施形態において、ジェネリックエンコーダ３０は、結合アプリケーション３９０から数値識別子４５０を受け取った後、関連するデータノード９０の情報から符号化ノード４６０を生成する。データノード９０から符号化ノード４６０を生成する際、ジェネリックエンコーダ３０は、データノード９０の始めを示しているテキスト開始デリミタを数値デリミタ４７０で置き換える。符号化モジュール４５０は、数値デリミタ４７０と関連づけられたデリミタタイプ、データノード９０と関連づけられた数値識別子４５０、及び／または所定のデリミタ値に基づき、数値デリミタ４７０の値を決定する。一実施形態において、スペシフィックエンコーダ３５は、所定のデリミタ値を取得するためにメモリ１００に格納されたデリミタ値テーブル６１０にアクセスする。デリミタ値テーブル６１０は、スペシフィックエンコーダ３５が数値デリミタ４７０を生成するために使用する複数のデリミタ値を含む。図示した実施形態において、これらのデリミタ値はベースデリミタ値６２０、デリミタリミット値６３０、オフセット値６４０、及びテキストデリミタ値６６０を含む。
ジェネリックエンコーダ３０がどのように符号化ノード４６０中のデリミタの数を減らすかの例として、ジェネリックエンコーダ３０は、符号化ノード４６０中の不要な終了デリミタを削除する。ＸＭＬその他のマークアップ言語は、ＸＭＬアトリビュートやその他の簡単な内容のエレメントの終わり等に、そのデータノード９０の内容に基づいて、関連づけられたデータノード９０の終わりが仮定できるような状況にある終了デリミタを含む。より具体的に、ジェネリックエンコーダ３０は、データノード９０のノードタイプに基づき、データノード９０の終わりを示す数値デリミタ４７０を含むかどうか判断する。例えば、ＸＭＬアトリビュートまたはシンプルコンテントエレメントと関連づけられた符号化ノード４６０は終了デリミタを含まない場合がある。ジェネリックエンコーダ３０は、データノード９０のノードタイプに基づき、符号化ノード４６０の終わりを示すデリミタを含めると決定すると、ジェネリックエンコーダ３０は、ベースデリミタ６２０と等しい第２の数値デリミタ４７０（例えば、この実施例では−１２）を含める
ジェネリックエンコーダ３０は、データ文書７０中の隣接する終了デリミタも結合する。例えば、図４Ａに示したデータノード９０とそのデータノード９０の最後の子ノードの間の終了デリミタや、テキスト開始デリミタ４１０とテキスト終了デリミタ４２０の間の終了デリミタを結合する。より具体的に、ジェネリックエンコーダ３０は、ベースデリミタ値６２０から数値デリミタ４７０に連結すべき第１のデリミタを超える別の各テキスト終了デリミタ４２０に対して１ずつデクリメントしたのと等しい関連する数値デリミタ４７０を用いて、複数のテキスト終了デリミタ４２０に対して単一の数量デリミタ４７０を生成する。このように、ジェネリックエンコーダ３０は、２つの隣接した終了デリミタを結合するとき、２つのテキスト終了デリミタ４２０を単一の数量デリミタ４７０で置き換える。この場合、（−１２−１）、または−１３である。結果として、符号化ノード４６０の数量デリミタ４７０の値は、この数量デリミタ４７０が複数の符号化ノード４６０の終わりを示すことを反映している。
また、ジェネリックエンコーダ３０は、テキスト終了デリミタ４２０とそれに隣接するテキスト開始デリミタ４１０と（例えばテキスト終了デリミタ４２０ｃとテキスト開始デリミタ４１０ｄ）を結合する。より具体的には、ジェネリックエンコーダ２０は、１つの符号化ノード４６０の終わりと次の符号化ノード４６０の始めの両方を示す符号化文書７２の数量デリミタ４７０を生成することにより、テキスト終了デリミタ４２０とそれに隣接するテキスト開始デリミタ４１０とを連結する。一実施形態において、上記の数値デリミタ４７０に使用される値は、次の符号化ノード４６０の数値識別子４５０とオフセット値６４０との和である。
一実施形態において、このオフセット値６４０がデータ処理システム１０の１つ以上のコンポーネントにより認識される最小の整数値であるように、ジェネリックエンコーダ３０が構成される。図示した実施形態において、このオフセット値は2-31である。このように、この例では、ジェネリックエンコーダ３０は、テキスト終了デリミタ４２０ｃとテキスト開始デリミタ４１０ｄをデータノード９０の数値識別子４５０とオフセット値の和である135+2-31で置き換える。
デリミタを減らすのに加えて、ジェネリックエンコーダ３０は、符号化文書７２のサイズを小さくしたり、その他の適当な理由のために、他の好適なやり方でデータノードを符号化する。一実施形態において、ジェネリックエンコーダ３０は、全てのテキストデータノード９０を８ビットＵＴＦ−８バイトシーケンス等のバイトシーケンス４９０に変換する。一般的に、ジェネリックエンコーダ３０は、データノード９０に適当な追加的符号化ステップを実行して、符号化ノード４６０を生成する。符号化を完了した後、ジェネリックエンコーダ３０は、符号化ノード４６０を含む１つ以上の符号化文書７２を生成する。さらにまた、一実施形態において、データ文書７０は、タグとテキストエレメントで構成されたＸＭＬエレメントを含むＸＭＬ文書である。結果として、上記の実施形態において、符号化文書７２は、数値デリミタ４７０により区切られた一連のＵＴＦ−８バイトシーケンスを表す。ジェネリックエンコーダ３０は、符号化文書７２を文書デコーダ５０に送り、両方のコンポーネントからアクセス可能なメモリ１００に符号化文書７２を格納するか、その他の適当なやり方で、文書デコーダ５０が使用できるように符号化文書７２を作る。
ジェネリックエンコーダ３０は、テキスト識別子２６４を数値識別子４２０で置き換えて、デリミタを削除することにより、データ文書７０に格納されている冗長な情報の量を選らす。結果として、ジェネリックエンコーダ３０は、データ文書７０のサイズをさらに減らすことができ、記憶容量を節約できるというメリットがある。また、ジェネリックエンコーダ３０は、一部の実施形態において、データ文書７０を符号化する追加的符号化ステップを実行する。
図４Ｃは、図４Ａに示したデータ文書７０から符号化モジュール３８２の実施形態により生成された符号化文書７２を示す図である。図示したように、符号化文書７２は、ＵＴＦ−８バイトシーケンスとしてフォーマットされた複数のテキストストリングを区切る一連の１０進数値デリミタ４７０を含む。また、複数の１０進数値デリミタ４７０と複数のバイトシーケンスは、コンマで互いに区切られている。しかし、一般的に、数値デリミタ４７０とバイトシーケンス４９０は、コンマや改行により区切られてもよいし、その他の好適な方法であればどんな方法でもよい。あるいは、符号化文書７２は、要求に応じて他のコンポーネントに出力される値のストリングを表してもよく、符号化文書７２は値の間にセパレータを含んでいなくてもよい。
この符号化文書７２を生成する符号化モジュール３８２の実施形態は、終了デリミタ値−１２を使用すると仮定する。さらにまた、符号化モジュール３８２は、符号化モジュール３８２が認識できる最も小さい数値である２−３１を関連するデータノード９０と関連づけられた数値識別子４５０に加えることにより、隣接するテキスト終了デリミタ４２０とテキスト開始デリミタ４１０を置き換える中間数値デリミタ４７０を形成すると仮定する。図４Ｃで使用したように、ＵＴＦ（ｘｘｘ）という表示は、アスキー文字列「ｘｘｘ」をＵＴＦ−８フォーマットに変換することにより生成されたバイトシーケンスを表すことを意図している。
図５Ａ−５Ｂは、一実施形態によるスペシフィックエンコーダ３５の動作と内容を示す図である。一部の実施形態において、スペシフィックエンコーダ３５は、データ文書７０を符号化する代替的または補助的方法をサポートする。生成アプリケーション２０は、スペシフィックエンコーダ３５とともに動作しているとき、１つ以上の結合前文書７８を生成するように構成されている。結合前文書７８の例は図５Ａに示されている。スペシフィックエンコーダ３５は、結合前文書７８を符号化し、例えば、文書デコーダにより復号させるため、それをリモートコンポーネントに送る。
図５Ａは、生成アプリケーション２０ｂにより生成された結合前文書７８の例を示す。特に、生成アプリケーション２０ｂは、結合前ノード５００に含まれる結合前文書７８を生成する。結合前ノード５００は、生成アプリケーション２０ａにより生成されたデータ文書７０のデータノード９０に含まれているデータと同様のデータを含むが、しかし、生成アプリケーション２０ｂは、文書デコーダ５０もコンパイル済みスキーマ８５にアクセスする結果として冗長であるかまたは不必要となる情報を省略する。結果として、スペシフィックエンコーダ３５は、ジェネリックエンコーダ３０がデータ文書７０を符号化するよりも速く、結合前文書７８を符号化することができる。しかし、生成アプリケーション２０はコンパイル済みスキーマ８５に限定されているので、スペシフィックエンコーダ３５はジェネリックエンコーダ３０よりもローバストでないかも知れない。
図５Ｂは、スペシフィックエンコーダ３５が結合前文書７８を符号化する際の、スペシフィックエンコーダ３５の一実施形態の動作を示す図である。図１を参照して上で説明したように、スペシフィックエンコーダ３５は、生成アプリケーション２０から結合前文書７８を受け取るか、または結合前文書７８にアクセスする。結合前文書７８は、生成アプリケーション２０がこれらのノードを生成するときにコンパイル済みスキーマ８５に結合される結合前ノード５００を含む。生成アプリケーション２０と文書デコーダ５０はコンパイル済みスキーマ８５にアクセスできるので、生成アプリケーション２０は、コンパイル済みスキーマ８５により提供される情報を考慮して冗長または不必要な結合前ノード５００及び／または結合前文書７８から一部の情報を省略することができる。一実施例において、生成アプリケーション２０は、データノード９０に同様のやり方で結合前ノード５００を生成するが、各結合前ノード５００に対してテキスト識別子ではなく、数値識別子４２０を用いる。上記の実施形態において、文書デコーダ５０またはデータ処理システム１０の他のコンポーネントは、数値識別子４２０を解決して結合前ノード５００のノードタイプを決定し、コンパイル済みスキーマ８５からその結合前ノード５００に関するより多くの情報を取得する。生成アプリケーション２０も、上述のデリミタ削減方法及び／または結合前ノード５００または結合前文書７８のサイズを減らす用に設計されたその他の方法を使用してもよい。
結合前文書７８を生成した後、生成アプリケーション２０は、その結合前文書７８をスペシフィックエンコーダ３５に送るか、または供給する。スペシフィックエンコーダ３５は、結合前文書７８を符号化して、符号化文書７２ｂを生成する。一実施形態において、スペシフィックエンコーダ３５は、ジェネリックエンコーダ３０がノード６００を結合した後、ジェネリックエンコーダ３０について上で説明したのと同様に結合前文書７８を符号化する。例えば、スペシフィックエンコーダ３５は、ジェネリックエンコーダ３０について上で説明したのと同様に、デリミタ低減及び／またはＵＴＦ−８変換を実行する。一部の実施形態において、符号化文書７２ｂは、スペシフィックエンコーダ３５により生成された符号化文書７２ａと同様か、または同一である。より具体的には、一部の実施形態において、符号化文書７２ａは、図示したように、数値デリミタ４７０により区切られた一連のバイトシーケンスを含む。結合前文書７８の符号化の後、ジェネリックエンコーダ３０は、符号化ノード４６０を含む１つ以上の符号化文書７２を生成する。スペシフィックエンコーダ３５は、符号化文書７２ｂを文書デコーダ５０に送り、両方のコンポーネントからアクセス可能なメモリ１００に符号化文書７２ｂを格納するか、その他の適当なやり方で、文書デコーダ５０が使用できるように符号化文書７２ｂを作る。
生成アプリケーション２０は、上述の状況では、コンパイル済みスキーマ８５に関する情報を有しており、コンパイル済みスキーマ８５により提供された情報（例えば、データノード９０の名前のテキスト識別子２６４）の複製を制限することができるので、スペシフィックエンコーダ３５は、ジェネリックエンコーダ３０がデータノード９０を結合し符号化するよりも速く結合前文書７８を符号化できる。結果として、生成アプリケーション２０とスペシフィックエンコーダ３５の実施形態は、さらに速度というメリットを提供する。また、結合前文書７８が含む情報はデータ文書７０よりも少ないので、好適に構成された生成アプリケーション２０とともにスペシフィックエンコーダ３５を使用することにより、生成アプリケーション２０から出て行くトラフィックが減少する。
図６は、一実施形態による文書デコーダ５０の動作と内容を示す図である。図６は、一実施形態による文書デコーダ５０の動作を示す図である。文書デコーダ５０は、符号化文書７２を受け取り、コンパイル済みスキーマ８５を用いて、符号化文書７２に含まれた符号化ノード４６０を復号する。文書デコーダ５０は、受信アプリケーション５０に復号したデータノード９０を送る。文書デコーダ５０は、復号中にコンパイル済みスキーマ８５に含まれるデータ定義２１０を使用するように構成されているので、一部の実施形態において、文書デコーダ５０は、データ文書７０とほぼ同じ情報を提供するがサイズは小さい符号化文書７２の使用を容易にする。また、文書デコーダ５０は、上述のように、デリミタ低減方法を用いて符号化された符号化文書７２を復号するように構成されているので、文書デコーダ５０は、よりコンパクトな符号化文書７２の使用を容易にする。
文書デコーダ５０は、動作中に、スペシフィックエンコーダ３５またはジェネリックエンコーダ３０（ここでは、一般名称として「文書エンコーダ６００」と呼ぶ）の一方または両方から符号化文書７２を受け取る。上述の通り、符号化文書７２は、値のストリーム、１つ以上のファイル、またはその他好適な構造のデータであればどんなものでもよい。結果として、符号化文書７２は、図４Ｃに示したように、数値デリミタ４７０により区切られた一連のＵＴＦ−８バイトシーケンスを表す。以下の説明は、このタイプの符号化文書７２に関する文書デコーダ５０の動作に焦点を絞るが、文書デコーダ５０は、好適な仕方で符号化された符号化文書７２に関する上述の方法を使用するように構成されている。
さらにまた、文書デコーダ５０は、ネットワークまたは文書処理システム１０のその他の接続エレメントを介して文書エンコーダ６００から符号化文書７２を受け取る。さらにまた、文書デコーダ５０は、符号化文書７２を文書エンコーダ６００から直接受け取るか、または１つ以上の仲介コンポーネントを通して受け取る。文書デコーダ５０は、文書エンコーダ６００と文書デコーダ５０の両方によりアクセス可能なメモリ１００から符号化文書７２を読み出すことにより符号化文書７２を受け取る。一般的に、文書デコーダ５０は、データ処理システム１０の文書エンコーダ６００またはその他のコンポーネントから符号化文書７２を受け取るか、または取得する。
文書デコーダ５０は符号化文書７２の分析を開始する。上述の通り、符号化文書７２は、数値デリミタ４７０により区切られた符号化ノード４６０を含む。このように、符号化文書７２を分析しつつ、文書デコーダは符号化文書７２から数値デリミタ４７０を読み出す。文書デコーダ５０は、数値デリミタ４７０を１つ以上の所定のデリミタ値と比較して、数値デリミタ４７０が１つ以上の符号化ノードの始めまたは終わりを示すかどうか決定する。データ文書７０は、この決定に基づき、受信アプリケーション５０への送信のためにマークアップデータオブジェクトを再構成し、または、例えば、そのデータノード９０の属性その他の内容を文書デコーダ５０のＡＰＩを通して受信アプリケーション５０に利用可能とすることにより、データノード９０の内容を記述する情報を受信アプリケーション５０に提供する。図示した実施形態において、文書デコーダ５０は、その符号化ノード４６０の復号を終わるまで、符号化ノード４６０から復号したデータをメモリ１００中の復号スタック６７０に格納する。文書デコーダ５０は、受信アプリケーション５０にそのデータから生成した復号データノード９０を送る。
例えば、文書デコーダ５０は、分析の際に数値デリミタ４７０に遭遇するたびに、その数値デリミタ４７０を１つ以上の所定値と比較することにより、その数値デリミタ４７０のデリミタタイプを決定する。一実施形態において、文書デコーダ５０は、デリミタ値テーブル６１０にアクセスすることにより所定値を取得する。デリミタ値テーブル６１０は、文書デコーダ５０が読み出した数値デリミタ４７０のデリミタタイプを決定するために使用する複数のデリミタ値を含んでいる。図示した実施形態において、これらのデリミタ値はベースデリミタ値６２０、デリミタリミット値６３０、逆オフセット値６５０、及びテキストデリミタ値６６０を含む。
文書デコーダ５０は、最初に、数値デリミタ４７０が単一符号化ノード４６０の終了デリミタであるかどうか決定する。文書デコーダ５０は、数値デリミタ４７０をベースデリミタ値６２０と比較することにより、数値デリミタ４７０が終了デリミタを表すかどうか決定する。文書デコーダ５０は、図６に示したように、デリミタ値テーブル６１０にアクセスすることにより、ベースデリミタ値を取得するか、またはその他の適当な仕方でベースデリミタ値６２０を取得する。一実施形態において、文書エンコーダ６００は、ベースデリミタ値６２０と等しい所定の数値デリミタ４７０を有する単一のデータノード９０の終わりである全ての終了デリミタを符号化するように構成されている。一実施形態において、ベースデリミタ値６２０は「−１２」である。このように、数値デリミタ４７０がベースデリミタ値６２０と等しい場合、文書デコーダ５０は、数値デリミタ４７０が単一の符号化ノード４６０の終わりを表すと判断する。文書デコーダ５０は、その構成に基づいて、適当な仕方でこの判断を使用する。例えば、一実施形態において、文書デコーダ５０は、現在復号している符号化ノード４６０の復号データをデータノード９０のスタックに加える。文書デコーダ５０は、数値デリミタ４７０が単一の符号化ノード４６０の終わりを表すとの判断の結果として、スタックの一番上から現在のデータノードをポップし、このデータノード９０を受信アプリケーション５０に送る。文書デコーダ５０は、その後、符号化文書７２の残りを分析する。
関連する数値デリミタ４７０が単一ノードの終了デリミタを表さない場合、文書デコーダ５０は、その数値デリミタ４７０が２つ以上のネストされた符号化ノードの終わりを示す終了デリミタであるかどうか判断する。一実施形態において、文書エンコーダ６００は、複数のネストされたデータノード９０の終わりを示す隣接するテキストデリミタを連結し、符号化文書７２ではその隣接するテキストデリミタを連結されたデリミタにより置き換えるように構成されている。この連結されたデリミタは、ベースデリミタ値６２０を隣接する終了デリミタにより終わる第１のデリミタ以降の各データノード９０について１回ずつデクリメントした値である。さらにまた、文書エンコーダ６００は、一定の最大数の隣接する終了デリミタのみを連結するように構成されてもよい。このように、ネストされた終了デリミタの符号化においては、文書エンコーダ６００は、一定の最大回数のみベースデリミタ値６２０をデクリメントして、隣接する終了デリミタを表す。結果として、文書デコーダ５０は、一実施形態において、数値デリミタ４７０がベースデリミタ値６２０より小さいが、しかしデリミタリミット値６３０以上であると判断することにより、数値デリミタ４７０が複数のネストされた終了デリミタを表すと決定する。デリミタリミット値６３０は、ベースデリミタ値６２０から文書エンコーダ６００が連結するように構成されているネストされたデリミタの最大数を引いた値である。
例えば、一実施形態において、文書エンコーダ６００は、ネストされたデリミタを最大１０個まで連結するように構成される。結果として、デリミタリミット値６２０は「−２２」である。このように、上記の実施形態において、文書デコーダ５０は、数値デリミタ４７０が「−１２」より小さいが「−２２」以上であると判断することにより、その数値デリミタ４７０が複数のネストされた符号化ノード４６０の終わりを示す連結されたデリミタであると判断する。
文書デコーダ５０は、数値デリミタ４７０が複数の符号化ノード４６０の終わりを示すと判断した場合、この判断を適当な仕方で利用することができる。例えば、一実施形態において、文書デコーダ５０は、スタックの一番上から現在データノードをポップして、このデータノードを受信アプリケーション５０に送る。文書デコーダ５０は、数値デリミタ４７０をインクリメントし、数値デリミタ４７０をベースデリミタ値６２０と再度比較する。文書デコーダ５０は、数値デリミタ４７０がベースデリミタ値６２０と等しくなるまでこのプロセスを繰り返す。文書デコーダ５０は、その後、符号化文書７２の残りを分析する。
文書デコーダ５０は、数値デリミタ４７０が１つ以上の符号化ノード４６０の終わりを表さないと判断した場合、数値デリミタ４７０が第１の符号化ノード４６０の終わりと第２の隣接する符号化ノード４６０の始めを表すかどうか判断する。一実施形態において、文書エンコーダ６００は、符号化文書７２において隣接する終了デリミタと開始デリミタを１つの中間デリミタで置き換えることにより、第１のデータノード９０の始めと第２の隣接するデータノード９０の終わりをそれぞれ示す隣接する終了デリミタと開始デリミタを符号化するように構成されている。一実施形態において、その中間デリミタに使用される値は、第２のノードの数値識別子とオフセット値６４０との和である。
上述の実施形態において、このオフセット値６４０は、文書デコーダ５０により認識される最も小さい整数値である。上述の実施形態において、文書デコーダ５０は、２の補数計算を使用するように構成され、最も小さな整数値を正数に加えることにより、絶対値が比較的大きい負の整数になる。このように、文書デコーダ５０は、一実施形態において、数値デリミタ４７０がデリミタリミット値６３０より小さいかどうか判断することにより、数値デリミタ４７０が第１の符号化ノード４６０の終わりとそれに隣接する符号化ノード４６０の始めを示す連結デリミタを表すと判断する。
文書デコーダ５０は、数値デリミタ４７０が第１の符号化ノード４６０の終わりと第２の隣接する符号化ノード４６０の始めを示すと判断した場合、この判断を適当な仕方で利用することができる。例えば、一実施形態において、文書デコーダ５０は、スタックの一番上から現在のデータノード９０をポップして、このデータノードを受信アプリケーション５０に送る。文書デコーダ５０は、逆オフセット値６５０を数値デリミタ４７０に加えることにより、新しいデータノード９０の数値デリミタ４７０を計算する。一実施形態において、この逆オフセット値６５０は、文書デコーダ５０により認識される最大の整数値である。図示した実施形態において、この逆オフセット値６５０は231である。逆オフセット値６５０を数値デリミタ４７０に加えることにより、文書デコーダ５０は、第２の符号化ノード４６０と関連づけられた元の数値デリミタ４７０を回復することができる。文書デコーダ５０は、コンパイル済みスキーマ８５中で、元の数値デリミタ４７０と関連づけられた定義ノード２１０を特定する。文書デコーダ５０は、新しいデータノード９０を復号スタック６７０の一番上にプッシュする。文書デコーダ５０は、他の数値デリミタ４７０を読むとき、上述のプロセスを繰り返して符号化文書７２の分析を続ける。
文書デコーダ５０は、数値デリミタ４７０がベースデリミタ値６２０より大きいと判断した場合、その数値デリミタ４７０がミックスコンテントデータノード９０の符号化テキストの始めを示すかどうか判断する。一実施形態において、文書エンコーダ６００は、ミックスコンテントデータノード９０のテキストの始めをテキストデリミタ値６６０と等しいデリミタで示すように構成されている。図示した実施形態において、テキストデリミタ値６６０は「−１」である。このように、上述の実施形態において、文書デコーダ５０は、数値デリミタ４７０がテキストデリミタ値６６０と等しいと判断することにより、その数値デリミタ４７０がミックスコンテントデータノード９０のテキストの始めを示すと判断する。
文書デコーダ５０は、数値デリミタ４７０が符号化テキストの始めを示すと判断した場合、この判断を適当な仕方で利用することができる。一実施形態において、文書デコーダ５０は、符号化文書７２からのデータの読み出しと、このデータの文字への復号を開始する。例えば、文書デコーダ５０は、ＵＴＦ−８バイトシーケンスを読み出し、このバイトシーケンスをＡＳＣＩＩテキスト文字に復号する。文書デコーダ５０は、これらの文字を受信アプリケーション５０に送り、文書デコーダ５０が現在復号しているデータノード９０の復号スタック６７０にその文字を格納する。文書デコーダ５０は、このテキストアイテムと関連づけられた全てのデータを読み出したと判断すると、数値デリミタ４７０の分析に戻る。一実施形態において、文書デコーダ５０は、全てゼロのバイトシーケンスを検知することにより、このオブジェクトの全てのテキストを読み出したと判断する。テキストアイテムの全ての文字を読み出した後、文書デコーダ５０は数値デリミタ４７０の分析に戻る。
また、文書デコーダ５０は、数値デリミタ４７０がベースデリミタ値６２０より大きいが、テキストデリミタ値６６０と等しくないと判断した場合、数値デリミタ４７０が前の符号化ノード４６０の直後ではない符号化ノード４６０の始めを示す開始デリミタを示すと判断する。一実施形態において、文書エンコーダ６００は、図４Ｂを参照して説明したように、開始デリミタを関連するデータノード９０と関連づけられた数値デリミタ４７０と置き換えることにより、終了デリミタの直後には続かない開始デリミタを符号化するように構成されているこのように、一実施形態において、文書デコーダ５０は、数値デリミタ４７０がベースデリミタ値６２０より大きいがテキストデリミタ値６６０とは等しくない場合、その数値デリミタ４７０が符号化ノード４６０の初めを表すと判断する。
文書デコーダ５０は、数値デリミタ４７０が符号化ノード４６０の始めを示すと判断した場合、この判断を適当な仕方で利用することができる。一実施形態において、文書デコーダ５０は、コンパイル済みスキーマ８５のノードアレイ２５０の数値デリミタ４７０と関連づけられたノードエントリー２５２を特定する。データ文書７０は、特定されたノードアレイ２５０中の参照２４４に基づき識別されたノードエントリー２５２と関連づけられた名前アレイ２６０の名前エントリー２６２を特定する。
さらにまた、文書デコーダ５０は、符号化ノード４６０がシンプルノードタイプのデータノード９０を表すと、特定されたノードエントリー２５２に基づき判断した場合、符号化ノード４６０のノードタイプと関連づけられたテキスト名６７２等の名前エントリー２６２からの情報を含む新しいデータ構造６９０を生成する。データ構造６９０は、オブジェクト、レコード、ストリング、アレイ、その他の好適なデータの集まりを表す。
文書デコーダ５０は、そのデータ構造６９０を受信アプリケーションに送り、後で使用するために格納する。 文書デコーダ５０は、符号化ノード４６０がコンプレックスノードタイプのデータノード９０を表すと、特定されたノードエントリー２５２に基づき判断した場合、符号化ノード４６０のノードタイプと関連づけられたテキスト名６７２等の名前エントリー２６２からの情報を含むデータ構造６９０を生成し、そのデータ構造６９０を復号スタック６７０にプッシュする。 文書デコーダ５０は符号化文書７２の分析に戻る。
文書デコーダ５０は、上述の比較を繰り返して符号化文書７２の終わりに到達するまで、符号化文書７２の分析を続ける。また、データ文書７０は、上述の通り、符号化文書７２の復号の前、または後に、追加的前処理または後処理のステップを実行してもよい。さらにまた、文書デコーダ５０は、符号化文書７２の特徴と文書デコーダ５０の構成に基づき、上述の処理の際に追加的ステップを適宜含めてもよい。文書デコーダ５０は、一旦符号化文書７２の分析を完了すると、データ文書７０をメモリ１００のデータノード９０に格納し、そのデータノード９０を受信アプリケーション５０に送り、文書デコーダ５０が符号化文書７２の復号を完了したことを受信アプリケーションに通知し、及び／またはデータ処理システム１０の構成に基づいてその他の適当なステップを実行する。あるいは、文書デコーダ５０が復号の際データノード９０を受信アプリケーション５０に送っている場合、文書デコーダ５０は受信アプリケーション５０には何も通知せずに終了してもよい。
図７Ａと７Ｂは、図６に示した実施形態による、文書デコーダ５０の動作を詳しく示すフローチャートである。ステップ１１００において、文書デコーダ５０は符号化文書７２の分析を開始する。ステップ１１１０において、符号化文書７２を分析しつつ、文書デコーダ５０は符号化文書７２から最初の数値デリミタ４７０を読み出す。ステップ１１２０において、文書デコーダ５０は、最初の数値デリミタ４７０と関連づけられたコンパイル済みスキーマ８５中の定義ノード２１０を特定する。ステップ１１３０において、文書デコーダ５０は、新しいデータ構造６９０を復号スタック６７０に生成する。文書デコーダ５０は、特定された定義ノード２１０と関連づけられたテキスト識別子２６４をデータ構造６９０に格納する。ステップ１１４０において、文書デコーダ５０は、符号化文書７２中の最初の数値デリミタ４７０に続くデータの分析を続け、このデータを符号化フォーマットから復号フォーマットに変換する。例えば、文書デコーダ５０は、そのデータをＵＴＦ−８バイトシーケンスからＡＳＣＩＩ文字に変換する。ステップ１１５０において、文書デコーダ５０は、この復号データの一部または全部をデータ構造６９０の一番上に格納する。
ステップ１１６０において、文書デコーダ５０は、符号化文書７２から第２の数値デリミタ４７０を読み出す。文書デコーダ５０は、第２の数値デリミタ４７０が１つ以上の符号化ノード４６０の終わりを示すかどうか判断する。より具体的には、文書デコーダ５０は、ステップ１１７０において、第２の数値デリミタ４７０がベースデリミタ値６２０と等しいかどうか判断する。第２の数値デリミタ４７０がベースデリミタ値６２０と等しい場合、第２の数値デリミタ４７０は単一の符号化ノード４６０の終わりを表す。このように、第２の数値デリミタ４７０がベースデリミタ値６２０と等しいとの判断に応じて、文書デコーダ５０は、符号化文書７２からのデータを復号スタック６７０中の最上部のデータ構造６９０への格納を停止するか、及び／またはステップ１１８０において復号スタック６７０から最上部のデータ構造６９０をポップする。文書デコーダ５０は、ステップ１１９０において、この最上部のデータ構造６９０を受信アプリケーション５０に送る。完成したデータ構造６９０は、マークアップ言語データ構造または他の好適な方法で構成された情報を表す。この時点で、文書デコーダ５０は符号化ノード４６０の内容の分析をもはやしていないので、文書デコーダ５０は符号化文書７２の終わりに到達したことになる。
このように、ステップ１２００において、文書デコーダ５０は、符号化文書７２の終わりまで分析したかどうか判断する。文書デコーダ５０は、ファイルの終わりを示す文字を分析することにより、符号化文書７２には分析すべきデータがもはやないことを検知することにより、またはその他の好適な方法により、符号化文書７２の終わりに到達したと判断してもよい。文書デコーダ５０は、文書デコーダ５０が符号化文書７２の終わりに到達したと判断した場合、ステップ１４００において復号を終了する。文書デコーダ５０は、符号化文書７２の終わりに到達したと判断しなかった場合、ステップ１１００に戻り、符号化文書７２の分析を続ける。
第２の数値デリミタ４７０がベースデリミタ値６２０と等しくない場合、文書デコーダ５０は、ステップ１２１０において、第２の数値デリミタ４７０がベースデリミタ値６２０より小さいが、デリミタリミット値６３０より大きいかどうか判断する。第２の数値デリミタ４７０はベースデリミタ値６２０より小さく、デリミタリミット値６３０より大きい場合、第２の数値デリミタ４７０は複数の符号化ノード４６０の終わりを示す。このように、第２の数値デリミタ４７０がベースデリミタ値６２０より小さいが、デリミタリミット値６３０より大きいとの判断に応じて、文書デコーダ５０は、符号化文書７２からのデータの復号スタック６７０中の最上部のデータ構造６９０への格納を停止するか、及び／またはステップ１２２０において復号スタック６７０から最上部のデータ構造６９０をポップする。文書デコーダ５０は、ステップ１２３０において、構造６９０を受信アプリケーション５０に送る。また、文書デコーダ５０は、ステップ１２４０において、第２の数値デリミタ４７０をインクリメントする。文書デコーダ５０はステップ１１７０に戻る。
第２の数値デリミタ４７０がベースデリミタ値６２０より小さくない場合、文書デコーダ５０は、ステップ１２５０において、第２の数値デリミタ４７０がテキストデリミタ値６６０と等しいかどうか判断する。第２の数値デリミタ４７０がテキストデリミタ値６６０と等しい場合、第２の数値デリミタ４７０はテキストエレメントの始めを表す。第２の数値デリミタ４７０がテキストデリミタ値６６０と等しいとの判断に応じて、文書デコーダ５０は、ステップ１２６０において復号スタック６７０上に新しいデータストラクチャ６９０を生成する。ステップ１２７０において、文書デコーダ５０は、符号化文書７２中の第２の数値デリミタ４７０に続くデータの分析を続け、このデータを符号化フォーマットから復号フォーマットに変換する。ステップ１２８０において、文書デコーダ５０は、この復号データの一部または全部をデータ構造６９０に格納する。文書デコーダ５０は、ステップ１２９０において、符号化テキストエレメントの終わりに到達したと判断するまで、符号化テキストエレメントからのデータの分析を続ける。文書デコーダ５０は、符号化テキストエレメントに指示されたサイズを使用することにより、符号化テキストの終わりを示す所定の文字または文字パターンを検知することにより、またはその他の好適な方法により、符号化テキストエレメントの終わりに到達したことを判断する。符号化テキストエレメントの終わりを検知した後に、文書デコーダ５０は、符号化文書７２からのデータを復号スタック６７０中の最上部のデータ構造６９０への格納を停止するか、及び／またはステップ１３００において復号スタック６７０から最上部のデータ構造６９０をポップする。文書デコーダ５０は、ステップ１３１０において、データ構造６９０を受信アプリケーション５０に送る。文書デコーダ５０は、ステップ１１３０に戻り、符号化文書７２の分析を続ける。
第２の数値デリミタ４７０がベースデリミタ値６２０とデリミタリミット値６３０の両方より小さい場合、第２の数値デリミタ４７０は、第１の符号化ノード４６０の終わりと第２の符号化ノード４６０の始めを示す。結果として、文書デコーダ５０は、符号化文書７２からのデータを復号スタック６７０中の最上部のデータ構造６９０への格納を停止するか、及び／またはステップ１３２０において復号スタック６７０から最上部のデータ構造６９０をポップする。文書デコーダ５０は、ステップ１３３０において、この最上部のデータ構造６９０を受信アプリケーション５０に送る。
また、上記の場合、第２の数値デリミタ４７０は、第２の符号化ノード４６０と関連づけられた数値識別子４５０の和を表す。文書デコーダ５０の図示した実施形態は２の補数計算を使用するので、文書デコーダ５０は逆オフセット値６５０を第２の数値デリミタ４７０に加えることにより数値識別子４５０を取得することができる。このように、ステップ１３４０において、文書デコーダ５０は逆オフセット値６５０を第２の数値デリミタ４７０に加えて数値識別子４５０を取得する。文書デコーダ５０は、ステップ１３５０において、この数値識別子４５０と関連づけられたコンパイル済みスキーマ８５の定義ノード２１０を特定する。ステップ１３６０において、文書デコーダ５０は、新しいデータ構造６９０を復号スタック６７０に生成する。文書デコーダ５０は、特定された定義ノード２１０からのテキスト識別子２６４をデータ構造６９０に格納する。ステップ１３７０において、文書デコーダ５０は、符号化文書７２中の第２の数値デリミタ４７０に続くデータの分析を続け、このデータを符号化フォーマットから復号フォーマットに変換する。ステップ１３８０において、文書デコーダ５０は、この復号データの一部または全部をデータ構造６９０に格納する。文書デコーダ５０はステップ１１６０に戻る。
図７Ａ−７Ｂのフローチャートには必ずしも示していないが、文書デコーダ５０は、適当な時に、符号化文書７２からのデータを分析しながら、好適な基準に基づき、符号化文書７２の終わりに到達したと判断する。例えば、文書デコーダ５０は、復号スタック６７０上の最下部のデータ構造６９０の終了デリミタを検知する。あるいは、文書デコーダ５０は、符号化文書７２の終わりを示す、所定の文字または文字パターンを検知してもよい。しかし、一般的に、文書デコーダ５０は、いかなる方法で符号化文書７２の終わりに到達したことを判断してもよい。ステップ１４００における符号化文書７２の終わりに到達したという判断の際、文書デコーダ５０は、復号スタック６７０から残りのデータ構造６９０を削除し、そのデータストラクチャ６９０を受信アプリケーション５０に送り、及び／または符号化文書７２の復号を完了する適当なステップを実行する。文書デコーダ５０は、ステップ１４００において復号を完了する。
図８Ａ−８Ｅは、文書デコーダ５０の実施形態によりサポートされた別の復号方法を示す図である。文書デコーダ５０は、一定の状況下、コンパイル済みスキーマ８５に結合されていない受信アプリケーション６０用データ文書を受け取る。結果として、一部の実施形態において、文書デコーダ５０は、１つのスキーマまたはその他のデータ定義形式に従って構成され、コンパイル済みスキーマ８５には結合されていないノード（未結合ノード７０２と呼ぶ）の階層を含む未結合文書７００を復号するように構成されている。文書状態スタック７１０を用いて、文書デコーダ５０は、未結合文書７００中のノード（未結合ノード７０２と呼ぶ）の階層ツリー内における文書デコーダ５０の現在位置をトラックすることができる。結果として、一部の実施形態において、文書デコーダ５０は、受信アプリケーション６０により使用される文書の復号において大きな柔軟性を提供する。
図８Ａは、文書デコーダ５０の実施形態が復号可能である未結合文書７００ｘの一例を示す図である。また、図８Ａには、この例における未結合文書７００ｘで使用される構成を規定する未コンパイルスキーマ８０も示す。また、例示を目的として、図８Ａには、未結合文書７００ｘとして同じＸＭＬ構成を含むが、従来のＸＭＬ規則に従ってフォーマットされたデータ文書７０ｘの一例が含まれている。
未結合文書７００は、一般的に、データ処理システム１０のデータ定義（未コンパイルスキーマ８０など）により定義されたデータノード９０を記述する文書を表す。ひとつの例として、未結合文書７００は、符号化されていない標準ＸＭＬデータ文書を表す。未結合文書７００は、未結合ノード７０２の階層がその未結合文書のデリミタに基づいて特定されるようにはマークアップ言語によりフォーマット及び／または区切られていない構造化データ文書も表す。例えば、文書デコーダ５０は、一部の実施形態において、図８Ａに示した未結合文書７００ｘ等のデータノード９０を含むコンマ区切りフォーマット（ＣＳＶ）ファイルとしてフォーマットされた未結合文書７００を受け取る。また、図８Ａには、未結合文書７００ｘで使用される構成を定義する未コンパイルスキーマ８０ｘと、未結合文書７００ｘの情報がどのようにＸＭＬで構成されるかを示すデータ文書７０ｘとが示されている。
上記の例において、未結合文書７００ｘは、エレメントインスタンスを表す複数の未結合ノード７０２を含む。また、図８Ａでは参照符号を付していないが、未結合文書７００ｘは、グループノード及び／またはその他のタイプの未結合ノードを表す複数の未結合ノードを含む。例えば、未結合文書７００ｘは、エレメントＤ、エレメントＥ、及びエレメントＦのインスタンスにより形成されたグループノードを含み、このインスタンスは集合的に未結合文書７００ｘのエレメントＣの第１のインスタンスとなる。
図８Ａは、未結合ノード７０２が記号と改行の組み合わせにより区切られた、文書デコーダ５０の実施形態で使用する未結合文書７００ｘの一例を示すが、文書デコーダ５０は、別の実施形態において、適当な文字、記号、空白、及び／またはその他のコンテントにより区切られた未結合文書７００を使用することもできる。一般的に、未結合ノード７０２は適当な区切り方法により区切られてもよく、文書デコーダ５０は未コンパイルスキーマ８０中の情報またはその他の情報源からの情報をを使用して、未結合文書７００と関連づけられた区切り方法を決定してもよい。この例において、例えば、エレメントＢのインスタンスにおいては、未結合ノード７０２ａは黙示的に新しいラインで開始して、新しいラインで終了する。エレメントＣのインスタンスでは、例えば、未結合ノード７０２ｂ−ｄも新しいラインで始まり、新しいラインで終わる。エレメントＤのインスタンスでは、例えば、未結合ノード７０２ｅと７０２ｊは、「＋」で始まり、「，」で終わる。エレメントＥのインスタンスでは、例えば、未結合ノード７０２ｆと７０２ｈは、「：」で始まり、「：」で終わる。エレメントＦのインスタンスでは、例えば、未結合ノード７０２ｇ、７０２ｊ、７０２ｋは、「＋」で始まり、「：」で終わる。
図８Ｂは、未結合文書７００の復号における文書デコーダ５０の動作を示す図である。特に、図８Ｂは、図８Ａにも示したコンパイル済みスキーマ８５に含まれた情報に基づいて、図８Ａに示された未結合文書７００ｘを復号する文書デコーダ５０の動作を示す。図８Ａを参照して説明したように、図８Ｂは、１つのタイプの未結合文書７００を復号する際の文書デコーダ５０の動作を示すが、文書デコーダ５０は、未コンパイルスキーマ８０及び／またはその他の適当な情報源からの情報に基づいていかなる好適なタイプの未結合文書７００も復号するように構成されている。文書デコーダ５０に加えて、図８Ｂは、グラフィカルユーザインターフェイス（ＧＵＩ）９００と文書データスタック７１０とを含む。
ＧＵＩ９００は、以下により詳しく説明するように、未結合文書７００の復号と関連づけられた情報を表示するために、文書デコーダ５０により使用される。ＧＵＩ９００は、文書デコーダ５０により送られた情報に基づき、視覚的表示を生成することができる好適なユーザインターフェイスであればどんなものでもよい。ＧＵＩ９００は、ハードウェア及び／またはソフトウェアの好適な組み合わせを含む。図示した実施形態において、ＧＵＩ９００は、コンピュータモニター９１０に情報を出力することができる、プロセッサ上で実行されたソフトウェアプロセスを表す。上記の実施形態において、文書デコーダ５０は、ＧＵＩ９００が未結合文書７００ｘの復号と関連づけられた更新された状態情報を受け取るために通信する仮想マシンを表す。
文書状態スタック７１０は、データ処理システム１０のメモリ１００に格納されたデータ構造を表す。図８Ｂに示したように、文書デコーダ５０は文書状態スタック７１０にアクセスする。未結合文書７００の分析の際、文書状態スタック７１０は、文書復号の現在の状態を追跡するために、文書デコーダ５０のための適当な情報を含む状態エントリー７２０を保持する。文書状態スタック７１０は、「スタック」として説明したが、文書状態スタック７１０は、以下に説明するように、状態エントリー７２０を格納するのに好適なデータ構造であればどんな形式でもよい。一実施形態において、文書状態スタック７１０は、先入れ後出し（ＦＩＬＯ）スタックである。
文書デコーダ５０は、動作中、データ処理システム１０のリモートコンポーネントから未結合文書７００ｘを受け取るか、他の適当な方法で未結合文書７００ｘを取得する。上述のように、未結合文書７００ｘは、記号または改行で区切られた一連のテキスト値を含む。文書デコーダ５０は、未コンパイルスキーマ８０を用いて、ＸＭＬまたはその他の受信アプリケーション６０によりサポートされたデータ文書に則したデータ文書７０に未結合文書７００ｘを変換する。
より具体的に、未結合文書７００ｘを取得した後、文書デコーダ５０は、その未結合文書７００ｘの分析を開始する。未結合文書７００ｘと関連づけられた区切り方法に基づき、文書デコーダ５０は未結合文書７００ｘの第１のデータノードの始めを特定する。例えば、文書デコーダ５０は、第１のラインの第１の文字が未結合文書７００ｘの第１の未結合ノード７０２の始まりを示すと判断してもよいし、第１の改行文字の後の第１の文字が未結合文書７００ｘの第１の未結合ノード７０２の始まりを示すと判断してもよいし、特定のデリミタに続く第１の文字が未結合文書７００ｘの第１の未結合ノード７０２の始まりを示すと判断してもよい。一般的に、文書デコーダ５０は、未結合文書７００のフォーマットに応じて、好適な方法で未結合文書７００中の第１のデータノードの始まりを特定する。図示した実施形態において、文書デコーダ５０は、未結合文書７００ｘの第１の未結合ノード７０２ａの始めとして第１のラインの第１の文字を特定する。未結合文書７００ｘの第１の未結合ノード７０２ａの始めを特定した結果として、文書デコーダ５０は、第１のステートエントリー７２０ａを文書状態スタック７１０に加える。例示した実施形態において、文書状態スタック７１０はＦＩＬＯスタックを表し、文書デコーダ５０は、文書状態スタック７１０の一端（ここでは「トップ」と呼ぶ）に第１の状態エントリー７２０ａをプッシュする。
特に、文書デコーダ５０が未結合ノード７０２のために生成する状態エントリー７２０の内容はそのノードのノードタイプに依存する。文書デコーダ５０は、未結合文書７００ｘと関連づけられた未コンパイルスキーマ８０に基づき、関連ノード７０２のノードタイプを決定する。一部の実施形態において、文書デコーダ５０は、関連ノード７０２のノードタイプに基づいて、エレメント状態エントリー７２０、グループ状態エントリー７２０、及び／またはその他のタイプの状態エントリーを生成する。関連未結合ノード７０２がエレメントノード７０２を表す場合、文書デコーダ５０は、文書状態スタックのエレメント状態エントリー７２０を生成する。エレメント状態エントリー７２０は、関連ノード７０２と関連づけられたテキスト識別子７２２と、関連ノード７０２の内容が完全に分析されたかどうかを示すパーティクルカウント７２４を含む。
関連未結合ノード７０２がグループノード７０２を表す場合、文書デコーダ５０は、文書状態スタック７１０のグループ状態エントリー７２０を生成する。グループ状態エントリー７２０は、適格であり発生として数えられる前にそのグループのインスタンスが有さねばならない子の数を示す、最小発生値７２６と、最大発生値７２８とを含む。さらにまた、関連グループノード７０２が複数タイプの子ノードを含む場合、グループ状態エントリー７２０は、そのグループノード７０２の子ノードの各タイプと関連づけられた最小発生値７２６と最大発生値７２８を含む。さらにまた、文書デコーダ５０は、未結合文書７００ｘに他の未結合ノード７０２の始めを特定した場合、特定された未結合ノード７０２は複数のネストされたグループノード中の第１のエレメントを表し、ネストされたグループノードごとに、複数のグループ状態エントリー７２０を文書状態スタック７１０に加える。
文書状態スタック７１０に状態エントリー７２０をプッシュした後、文書デコーダ５０は、未結合文書７００ｘの分析を続ける。文書デコーダ５０は、他の未結合ノード７０２の始まりを示す他の開始デリミタまたは他の好適な情報を特定すると、他のエレメント状態エントリー７２０を文書状態スタック７１０に加える。図示した実施形態において、文書デコーダ５０は、他の状態エントリー７２０を文書状態スタック７１０のトップにプッシュすることにより、他の状態エントリーを加える。
文書デコーダ５０は、現在の未結合ノード７０２の終わりを示す終了デリミタまたは他の好適な情報を特定すると、最上部の状態エントリー７２０を文書状態スタック７１０から削除する。例示した実施形態において、文書デコーダ５０は、文書状態スタック７１０のトップから状態エントリー７２０をポップすることにより、文書状態スタック７１０から状態エントリー７２０を削除する。結果として、文書デコーダ５０は、文書状態スタック７１０に状態エントリー７２０を加えることにより、または文書状態スタック７１０から状態エントリーを削除することにより、文書分析の現在の状態をトラックする。
文書デコーダ５０は、未結合ノード７０２の終了デリミタが分析されたと判断した結果、他のいかなる適当な動作を実行してもよい。例えば、文書デコーダ５０は、未結合ノードと関連づけられた分析データをＸＭＬフォーマットのファイルに書き込んでもよい。結果として、文書デコーダ５０は、未結合文書７００ｘの復号の結果として、図８Ａに示したデータ文書７０ｘと同様のデータ文書を出力する。
また、一部の実施形態において、文書デコーダ５０は、関連した未結合ノード７０２及び／またはその未結合ノード７０２の子と関連づけられたパーティクルカウント７２４、最小発生値７２６、最大発生値７２８、及び／または発生カウント７３０を使用して、その未結合ノード７０２の受付状態を決定する。受付状態は、文書デコーダ５０がその未結合ノード７０２の分析を完了したかどうか、及び／またはその未結合ノード７０２が関連マークアップ言語の適格なオブジェクトを表しているかどうかを示す。
例えば、上述したように、文書デコーダ５０は、グループを含む未結合ノード７０２の始めを分析するとき、グループ状態エントリー７２０を加える。グループ状態エントリー７２０は、適格であると見なされる前にそのグループのインスタンスが持たなければならない子を記述する最小発生値７２６と最大発生地７２８、及びそのインスタンスに対して分析された子の現在の数を示す発生カウント７３０を含む。図示した例において、エレメントＢのインスタンスに含まれる「選択」グループ（未結合ノード７０２ａ等）は、エレメントＣの少なくとも１つの子インスタンスを含む必要があり、エレメントＣのインスタンスを３つより多く含まない。このように、文書デコーダ５０は、未結合文書７００ｘを分析する際にエレメントＢのインスタンスに遭遇した時、最小発生値７２６「１」と最大発生値７２８「３」を含むグループ状態エントリー７２２ａを生成する。
そして、文書デコーダ５０は、この「選択」グループの子ノード７０２を分析しながら、そのグループの他の子に遭遇するたびに、発生カウント７３０をインクリメントする。文書デコーダ５０は、発生カウント７３０と、そのグループと関連づけられた最小発生値７２６及び／または最大発生値７２８に基づき、そのグループの受付状態を決定する。例えば、一実施形態において、文書デコーダ５０は、１つのグループ未結合ノード７０２の３つの可能な受付状態の１つを決定する。１つのグループ状態エントリー７２２の発生カウント７３０がそのグループ状態エントリー７２２の最小発生値７２６より小さい場合、文書デコーダ５０は、そのグループ状態エントリー７２２と関連づけられたグループノードについて受付状態が「IS_NOT_DONE」であると決定する。関連発生カウント７３０が最小発生値７２６以上である場合、文書デコーダ５０は、受付状態を「ACCEPTED」と決定する。これは、文書デコーダ５０は、そのグループノードを適格であると見なすのに十分な数の子を発見したが、そのグループノードは受付可能なもっと多い子を含んでいるかも知れないことを意味する。発生カウント７３０が最大発生値７２８と等しい場合、文書デコーダ５０は、そのグループノードが別の子は含むことができなく、適格であることを示す受付状態「IS_DONE」を決定する。文書デコーダ５０は、受付状態フィールド７３６として、関連するグループ状態エントリー７２２にこの受付状態を追加格納する。
文書デコーダ５０は、文書状態スタック７１０の最上部の状態エントリー７２０の受付状態が「IS_DONE」であると判断すると、文書状態スタック７１０からその最上部の状態エントリー７２０を削除する。また、文書デコーダ５０は、分析の際、文書状態スタック７１０の最上部の状態エントリー７２０と関連づけられたデータノードの終了デリミタに到達し、最上部の状態エントリーが「ACCEPTED」の受付状態を現在有する場合、その状態エントリーと関連づけられた未結合ノード７０２は完了したと判断し、その最上部の状態エントリーを文書状態スタック７１０から削除する。さらにまた、一部の実施形態において、文書デコーダ５０は、受付状態と分析結果の組み合わせが予期しないものである場合、警告またはエラー訂正動作を開始する。例えば、文書デコーダ５０は、グループ未結合ノード７０２の受付状態が「IS_DONE」となったと判断し、そのグループ未結合ノード７０２の他の子を分析した場合、問題の未結合ノード７０２は不適格であることを示す警告を生成する。
上述のように、図８Ｂは、文書デコーダ５０がノード７０２ｇの開始デリミタ「＋」を分析した直後の文書状態スタック７１０の内容を示している。文書デコーダ５０は、エレメントＣのインスタンスについて可能な子の各タイプの最大数（エレメントＤ、Ｅ、及びＦについて１つずつ）を検知したので、ノード７０２ｂにより表されるエレメントＣのインスタンスと関連づけられたグループノードはこれ以上の子を含んではならないと判断し、グループ状態エントリー２２０ｄの受付状態は「IS_DONE」になる。対照的に、文書デコーダ５０は、ノード７０２Ａにより表されるエレメントＢのインスタンス内にエレメント「Ｃ」の１つのインスタンスだけを検知している。この合計はグループ状態エントリー２２０ｂの最小発生値７２６以上であるが、グループ状態エントリー２２０ｂの最大発生値７２８より小さい。このように、文書デコーダ５０がエレメントＢのインスタンスに十分な数の子を検知しても、そのインスタンスが未コンパイルスキーマ８０ｘの規定にしたがってより多くの子を保持してもよい。結果として、受付状態は「ACCEPTED」となる。
また、文書デコーダ５０は、未結合ノード７０２ａと７０２ｂと関連づけられたエレメントＢとＣのインスタンスの内容を分析したので、これら２つのエレメント状態エントリー７２０のパーティクルカウント７２４は「１」である。文書デコーダ５０は、既存のコンテントパーティクルを分析を続けるが、他にはコンテントパーティクルはないので、これらのエレメント状態エントリーの受付状態は「IS_DONE」である。対照的に、文書デコーダ５０は、未結合ノード７０２ｇの開始デリミタのみを分析し、ノード７０２ｇの内容は分析していない。結果として、図８Ｂに示したように、関連づけられたエレメント状態エントリー７２０のパーティクルカウントは、「０」であり、受付状態は「IS_NOT_DONE」である。
一部の実施形態において、文書状態スタック７１０を更新するのに加え、文書デコーダ５０は、状態エントリー７２０または７２２、及び／またはそれと関連づけられたノード７０２の受付状態と関連づけられた情報をＧＵＩに表示する。一部の実施形態において、文書デコーダ５０は、文書状態スタック７１０に現在及び／または前に格納された格状態エントリー７２０の状態インジケータ７４０を生成して、これらの状態インジケータ７４０をＧＵＩ９００に送り、ＧＵＩ９００上に表示することにより、状態エントリーの受付状態を示す。文書デコーダ５０は、個々の状態エントリー７２０の状態が変化するに従って、ＧＵＩ９００に表示された状態インジケータを更新または置き換える。
さらにまた、文書デコーダ５０は、状態インジケータ７４０を用いて、適当な方法で、関連づけられた状態エントリー７２０の受付状態を示す。例えば、一部の実施形態において、文書デコーダ５０は、その状態エントリーの色の状態インジケータ７４０を生成することにより、状態エントリーの受付状態を示す。文書デコーダ５０は、関連づけられた状態インジケータ７４０の色を変化させることにより、または、異なる色の新しい状態インジケータ７４０を生成することにより、その状態エントリーの受付状態の変化を示してもよい。図８Ｂは、データ処理システム１０の一実施形態を示し、文書デコーダ５０は、「IS_NOT_DONE」の受付状態を赤い状態インジケータ７４０で示し（図８Ｂにおいて、状態エントリー７２０ｅと関連づけられた影付けされた状態インジケータ７４０ｅにより示す）、「ACCEPTED」の受付状態を黄色の状態インジケータ７４０で示し（図８Ｂにおいて、状態エントリー７２０ｂと関連づけられたクロスハッチされた状態インジケータ７４０ｂにより示す）、「IS_DONE」の受付状態を緑色の状態インジケータ７４０で示す（図８Ｂにおいて、状態エントリー７２０ａ、７２０ｃ、７２０ｄと関連づけられた影付けされていない状態インジケータ７４０ａ、７４０ｃ、７４０ｄにより示す）。
また、一部の実施形態において、文書デコーダ５０は、１つ以上の未結合ノード７０２の受付状態を使用して、それらの未結合ノード７０の親ノードの「有効受付」を判断する。有効受付は、文書デコーダ５０が１つの未結合ノード７０２の受け付けられた子ノードの適当な組み合わせを分析したかどうかを示し、文書デコーダ５０は、その子ノードの受付状態に基づき、１つの未結合ノード７０２の有効受付を判断する。結果として、文書デコーダ５０は、未結合ノードの有効受付を用いて、ノードとその全ての子の完全性を示す。一方、一実施形態において、１つのノードの受付状態は、文書デコーダ５０がそのノードの子のインスタンスの始めを検知した結果として変化するが、有効受付は、文書デコーダ５０がそのノードの子を完全に検知した結果として変化する。このように、１つのノードの有効受付は、そのノードの下の階層レベルの完全性を反映し、有効受付は、すべてのノードの受付状態より正確なインジケータとなる。
例えば、図８Ａの未結合文書７００ｘを参照して、文書デコーダ５０は、未結合ノード７０２ａの必要な子ノードの完全性に基づき、未結合ノード７０２ａであるエレメントＢのインスタンスの有効受付を判断する。例えば、図８Ａに示したように、未コンパイルスキーマ８０ｘは、エレメントＢのインスタンスは、エレメントＣの最低２つのインスタンスとエレメントＣの最大３つのインスタンスを有し、文書デコーダ５０は子の受付状態に基づいてエレメントＢのインスタンスの有効受付を決定する。一部の実施形態において、文書デコーダ５０は、有効受付、または有効受付を記述する情報を関連する状態エントリー７２０の有効受付フィールド（図示せず）に格納する。文書デコーダ５０は、文書状態スタック７１０から状態エントリー７２０を削除する際、有効受付フィールドを更新する。また、文書デコーダ５０は、未結合文書７００の復号の際、適当な方法で有効受付を使用する。一例として、文書デコーダ５０は、受付状態に関して上で説明したように、各未結合ノード７０２の有効受付をユーザにＧＵＩ９００上で表示してもよい。
さらにまた、この説明では、未結合文書７００の復号における受付状態の使用に焦点を絞ったが、文書デコーダ５０、またはデータ処理システム１０のその他のアプリケーションやコンポーネントは上述の方法を使用して、他のタイプの文書を復号する際にその完全性を判断することもできる。さらにまた、データ処理システム１０の他のアプリケーションやコンポーネントが処理しているノードを受付状態とするために、データ文書７０の処理の際に上記の方法を使用してもよい。例えば、データ処理システム１０の一実施形態において、生成アプリケーション２０は、データ文書７０を検証中にこれらの方法を用い、ＧＵＩ９００に、これらのノード７０２の受付状態を判断するために上述の方法に基づいてこれらのデータ文書７０のノードが適格であるかどうか反映してもよい。
上述の説明は、例示を目的として、文書デコーダ５０が受付状態または有効受付を決定する上述の方法を使用する実施形態に焦点を絞ったが、別の実施形態において、データ処理システム１０のいかなるエレメントがこれらの方法を使用してもよい。さらにまた、いかなるエレメントがＧＵＩ９００とインターラクトして、ＧＵＩ９００に受付状態と有効受付に関する情報を提供してもよい。データ処理システム１０の一部の実施形態において、結合モジュール３９０として機能する仮想マシンは、上記の方法をサポートし、図４Ｂを参照して説明した結合機能を提供するのに加えて、ＧＵＩ９００に受付状態と有効受付情報を提供してもよい。
結果として、受付状態と有効受付の両方を用いて、データ処理システム１０のエレメントに有用な情報を提供でき、及び／または復号または動作のその他の段階で使用することができる。また、一部の実施形態において、受付状態と有効受付は、非標準ＸＭＬ区切りを用いる文書の処理を容易にする。結果として、上述の方法は、動作上のメリットを提供する。
本発明をいくつかの実施形態を使って説明したが、当業者には無数の変更、変形、変換、修正等が可能であり、本発明は、添付した請求項の範囲に入るこれらの変更、変形、変換、修正等も含むものである。
なお、本開示に当たり、以下の付記を記す。
（付記１）
マークアップ言語文書を分析する方法であって、
マークアップ言語文書において、第１のノードタイプの第１のデータノードの始まりを検知するステップと、
前記第１のノードタイプと関連づけられた、前記第１のノードタイプの定義された内容を指示する第１のデータ定義を特定するステップと、
前記第１のデータノードと関連づけられた第１のエントリーをデータ構造に加えるステップと、
前記マークアップ言語文書から前記第１のデータノードの内容を読み出すステップと、
前記第１のデータ定義と、前記第１のデータノードから読み出した前記内容とに基づき、前記第１のデータノードの状態を決定するステップと、
グラフィカルユーザインターフェイス（ＧＵＩ）上に前記第１のデータノードの前記状態を表示するステップと、
を有することを特徴とする方法。
（付記２）
付記１に記載の方法であって、
前記第１のデータノードの前記状態を決定するステップは、前記第１のデータノードの受付状態を決定するステップを有し、
前記受付状態は、前記第１のデータ定義の前記定義された内容の１つ以上が前記第１のデータノードから読み出されたかどうかを示し、
前記状態を表示するステップは、前記第１のデータノードの受付状態をＧＵＩに表示するステップを有することを特徴とする方法。
（付記３）
付記１に記載の方法であって、さらに、
前記第１のデータノードの追加的内容を前記マークアップ言語文書を読み出すステップと、
前記第１のデータ定義と前記追加的内容とに基づいて前記第１のデータノードの更新後の状態を決定するステップと、
前記第１のデータノードの前記更新後の状態を前記ＧＵＩに表示するステップと、
を有することを特徴とする方法。
（付記４）
付記３に記載の方法であって、
前記更新後の状態を表示するステップは、前記第１のデータノードの前記状態を示すテキストと関連づけられた色を前記ＧＵＩ上で変化させるステップを有することを特徴とする方法。
（付記５）
付記１に記載の方法であって、前記第１のデータノードの内容を読み出すステップは、
前記第１のデータノード内の、前記第１のデータノードの子ノードである第２のデータノードの始めを特定するステップと、
前記第１のデータノードの子ノードと関連づけられた発生回数カウントをインクリメントするステップと、
前記第２のデータノードの内容を前記マークアップ言語文書から読み出すステップと、を有し、
前記第１のデータノードの前記状態を決定するステップは、前記発生回数カウントに基づき前記第１のデータノードの前記状態を決定するステップを有することを特徴とする方法。
（付記６）
付記５に記載の方法であって、前記第２のデータノードは第２のノードタイプを有し、
前記方法は、さらに、
前記第２のノードタイプと関連づけられた、前記第１のノードタイプの定義された内容を指定する第２のデータ定義を特定するステップと、
前記第２のデータノードの内容を前記マークアップ言語文書から読み出すステップと、
前記第２のデータ定義に基づき前記第２のデータノードの受付状態であって、前記第１のデータ定義の前記定義された内容の１つ以上が前記第１のデータノードから読み出されたかどうかを示す前記受付状態を決定するステップと、
を有し、
前記第１のデータノードの前記状態を決定するステップは、前記第１のデータノードの１つ以上の子ノードの前記受付状態に基づき前記第１のデータノードの効果的受付を決定するステップを有することを特徴とする方法。
（付記７）
付記６に記載の方法であって、さらに、
前記第１のデータノードと前記第２のデータノードの一方の追加的内容を前記マークアップ言語文書から読み出すステップと、
前記第１のデータ定義と前記追加的内容に基づき前記第１のデータノードの更新後の効果的受付を決定するステップと、
前記第１のデータノードの前記更新後の効果的受付を前記ＧＵＩ上に表示するステップと、
を有することを特徴とする方法。
（付記８）
付記７に記載の方法であって、
前記更新後の効果的受付を表示するステップは、前記効果的受付を示すテキストと関連づけられた色を前記ＧＵＩ上で変化させるステップを有することを特徴とする方法。
（付記９）
媒体中に符号化された、マークアップ言語文書を分析するロジックであって、実行された時、
マークアップ言語文書において、第１のノードタイプの第１のデータノードの始まりを検知し、
前記第１のノードタイプと関連づけられた、前記第１のノードタイプの定義された内容を指示する第１のデータ定義を特定し、
前記第１のデータノードと関連づけられた第１のエントリーをデータ構造に加え、
前記マークアップ言語文書から前記第１のデータノードの内容を読み出し、
前記第１のデータ定義と、前記第１のデータノードから読み出した前記内容とに基づき、前記第１のデータノードの状態を決定し、
グラフィカルユーザインターフェイス（ＧＵＩ）上に前記第１のデータノードの前記状態を表示することを特徴とするロジック。
（付記１０）
付記９に記載のロジックであって、
前記ロジックは、前記第１のデータノードの受付状態を決定することにより、前記第１のデータノードの前記状態を決定するように動作可能であり、
前記受付状態は、前記第１のデータ定義の前記定義された内容の１つ以上が前記第１のデータノードから読み出されたかどうかを示し、
前記ロジックは前記第１のデータノードの受付状態をＧＵＩに表示することにより、前記第１のデータノードの前記受付状態を表示することを特徴とするロジック。
（付記１１）
付記９に記載のロジックであって、前記ロジックは、さらに
前記第１のデータノードの追加的内容を前記マークアップ言語文書を読み出し、
前記第１のデータ定義と前記追加的内容とに基づいて前記第１のデータノードの更新後の状態を決定し、
前記第１のデータノードの前記更新後の状態を前記ＧＵＩに表示することを特徴とするロジック。
（付記１２）
付記１１に記載のロジックであって、前記ロジックは、前記第１のデータノードの前記状態を示すテキストと関連づけられた色を前記ＧＵＩ上で変化させることにより、前記更新後の状態を表示するように動作可能であることを特徴とするロジック。
（付記１３）
付記９に記載のロジックであって、前記ロジックは、
前記第１のデータノード内の第２のデータノードの始めを特定し、前記第２のデータノードは前記第１のデータノードの子ノードであり、
前記第１のデータノードの子ノードと関連づけられた発生回数カウントをインクリメントし、
前記第２のデータノードの内容を前記マークアップ言語文書から読み出すことにより、前記第１のデータノードの内容を読み出し、
前記第１のデータノードの前記状態の決定は、前記発生回数カウントに基づき前記第１のデータノードの前記状態の決定を含む、
ことを特徴とするロジック。
（付記１４）
付記１３に記載のロジックであって、前記第２のデータノードは第２のノードタイプを有し、
前記ロジックは、さらに、
前記第２のノードタイプと関連づけられた、前記第１のノードタイプの定義された内容を指定する第２のデータ定義を特定し、
前記第２のデータノードの内容を前記マークアップ言語文書から読み出し、
前記第２のデータ定義に基づき前記第２のデータノードの受付状態であって、
前記第１のデータ定義の前記定義された内容の１つ以上が前記第１のデータノードから読み出されたかどうかを示す前記受付状態を決定し、
前記第１のデータノードの前記状態の決定、前記第１のデータノードの１つ以上の子ノードの前記受付状態に基づき前記第１のデータノードの効果的受付の決定を含むことを特徴とするロジック。
（付記１５）
付記１４に記載のロジックであって、前記ロジックは、さらに、
前記第１のデータノードと前記第２のデータノードの一方の追加的内容を前記マークアップ言語文書から読み出し、
前記第１のデータ定義と前記追加的内容に基づき前記第１のデータノードの更新後の効果的受付を決定し、
前記第１のデータノードの前記更新後の効果的受付を前記ＧＵＩ上に表示することを特徴とするロジック。
（付記１６）
付記１５に記載のロジックであって、前記ロジックは、
前記効果的受付を示すテキストと関連づけられた色を前記ＧＵＩ上で変化させることにより前記更新後の効果的受付を表示するように動作することを特徴とするロジック。
（付記１７）
マークアップ言語文書を分析するシステムであって、
マークアップ言語文書を格納するメモリと、
プロセッサから受け取った情報に基づいて１つ以上のデータノードの状態を表示するグラフィカルユーザインターフェイス（ＧＵＩ）と、
プロセッサであって、
マークアップ言語文書において、第１のノードタイプの第１のデータノードの始まりを検知し、
前記第１のノードタイプと関連づけられた、前記第１のノードタイプの定義された内容を指示する第１のデータ定義を特定し、
前記第１のデータノードと関連づけられた第１のエントリーをデータ構造に加え、
前記マークアップ言語文書から前記第１のデータノードの内容を読み出し、
前記第１のデータ定義と、前記第１のデータノードから読み出した前記内容とに基づき、前記第１のデータノードの状態を決定し、
前記ＧＵＩ上に前記第１のデータノードの前記状態を表示するプロセッサと、
を有することを特徴とするシステム。
（付記１８）
付記１７に記載のシステムであって、
前記プロセッサは、前記第１のデータノードの受付状態を決定することにより、前記第１のデータノードの前記状態を決定し、
前記受付状態は、前記第１のデータ定義の前記定義された内容の１つ以上が前記第１のデータノードから読み出されたかどうかを示し、
前記プロセッサは、前記第１のデータノードの受付状態を前記ＧＵＩに表示することにより、前記状態を表示することを特徴とするシステム。
（付記１９）
付記１７に記載の方法であって、前記プロセッサは、さらに
前記第１のデータノードの追加的内容を前記マークアップ言語文書を読み出し、
前記第１のデータ定義と前記追加的内容とに基づいて前記第１のデータノードの更新後の状態を決定し、
前記第１のデータノードの前記更新後の状態を前記ＧＵＩに表示することを特徴とするシステム。
（付記２０）
付記１９に記載のシステムであって、前記プロセッサは、前記第１のデータノードの前記状態を示すテキストと関連づけられた色を前記ＧＵＩ上で変化させることにより、前記更新後の状態を表示することを特徴とするシステム。
（付記２１）
付記１７に記載のシステムであって、前記プロセッサは、
前記第１のデータノード内の、前記第１のデータノードの子ノードである第２のデータノードの始めを特定し、
前記第１のデータノードの子ノードと関連づけられた発生回数カウントをインクリメントし、
前記第２のデータノードの内容を前記マークアップ言語文書から読み出すことにより前記第１のデータノードの内容を読み出し、
前記第１のデータノードの前記状態の決定は、前記発生回数カウントに基づき前記第１のデータノードの前記状態の決定を含む、ことを特徴とするシステム。
（付記２２）
付記２１に記載のシステムであって、
前記第２のデータノードは第２のノードタイプを有し、
前記プロセッサは、
前記第２のノードタイプと関連づけられた、前記第１のノードタイプの定義された内容を指定する第２のデータ定義を特定し、
前記第２のデータノードの内容を前記マークアップ言語文書から読み出し、
前記第２のデータ定義に基づき前記第２のデータノードの受付状態であって、前記第１のデータ定義の前記定義された内容の１つ以上が前記第１のデータノードから読み出されたかどうかを示す受付状態を決定し、
前記第１のデータノードの前記状態の決定は、前記第１のデータノードの１つ以上の子ノードの前記受付状態に基づき前記第１のデータノードの効果的受付の決定を含むことを特徴とするシステム。
（付記２３）
付記２２に記載のシステムであって、前記プロセッサは、さらに
前記第１のデータノードと前記第２のデータノードの一方の追加的内容を前記マークアップ言語文書から読み出し、
前記第１のデータ定義と前記追加的内容に基づき前記第１のデータノードの更新後の効果的受付を決定し、
前記第１のデータノードの前記更新後の効果的受付を前記ＧＵＩ上に表示することを特徴とするシステム。
（付記２４）
付記２３に記載のシステムであって、
前記プロセッサは、前記効果的受付を示すテキストと関連づけられた色を前記ＧＵＩ上で変化させることにより、前記更新後の効果的受付を表示することを特徴とするシステム。
本発明の一実施形態による、データ処理システムの動作を示す図である。 一実施形態による、スキーマコンパイラの動作を示す図である。 一実施形態による、スキーマコンパイラの動作を示す図である。 コンパイルされたスキーマに順次アクセスしている処理コンポーネントの動作を示す図である。 一実施形態による、ジェネリックエンコーダの動作を示す図である。 一実施形態による、ジェネリックエンコーダの動作を示す図である。 一実施形態による、ジェネリックエンコーダの動作を示す図である。 一実施形態による、スペシフィックエンコーダの動作を示す図である。 一実施形態による、文書デコーダの動作を示す図である。 一実施形態による、文書デコーダの動作を詳細に示すフローチャートである。 一実施形態による、文書デコーダの動作を詳細に示すフローチャートである。 結合前文書の符号化における文書デコーダの動作を示す図である。 結合前文書の符号化における文書デコーダの動作を示す図である。
符号の説明
１０ データ処理システム
２０ａ、２０ｂ 生成アプリケーション
３０ ジェネリックエンコーダ
３５ スペシフィックエンコーダ
４０ スキーマコンパイラ
５０ 文書デコーダ
６０ 受信アプリケーション
７０ データ文書
７６ 結合前文書
８０ 未コンパイルスキーマ
８５ コンパイル済みスキーマ

Claims (2)

  1. １以上のデータノードを含むマークアップ言語文書を分析する方法であって、
    コンピュータに、
    マークアップ言語文書からデータノードを読み出し、
    読み出した該データノードがグループノードである場合に、前記グループノード内で出現する子ノードの発生カウントをインクリメントし、
    前記子ノードの発生カウント値と前記出現した子ノードの分析状態、または前記子ノードの発生カウント値と前記グループノードに関連付けられた最大発生値および最小発生値との比較結果、に応じて、前記グループノードの受付状態を決定し、
    決定した前記グループノードの前記受付状態を表示する、
    ことを特徴とする分析方法。
  2. １以上のデータノードを含むマークアップ言語文書を分析するコンピュータプログラムであって、
    コンピュータに、
    マークアップ言語文書からデータノードを読み出す段階と、
    読み出した該データノードがグループノードである場合に、前記グループノード内で出現する子ノードの発生カウントをインクリメントする段階と、
    前記子ノードの発生カウント値と前記出現した子ノードの分析状態、または前記子ノードの発生カウント値と前記グループノードに関連付けられた最大発生値および最小発生値との比較結果、に応じて、前記グループノードの受付状態を決定する段階と、
    決定した前記グループノードの前記受付状態を表示する段階と、
    を実行させることを特徴とするコンピュータプログラム。
JP2006034541A 2005-02-11 2006-02-10 アクセプタンス状態の表示システム及び方法 Expired - Fee Related JP5168791B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/056,441 US8996991B2 (en) 2005-02-11 2005-02-11 System and method for displaying an acceptance status
US11/056,441 2005-02-11

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2012213045A Division JP5789236B2 (ja) 2005-02-11 2012-09-26 構造化文書分析方法、構造化文書分析プログラム、および構造化文書分析システム

Publications (2)

Publication Number Publication Date
JP2006221657A JP2006221657A (ja) 2006-08-24
JP5168791B2 true JP5168791B2 (ja) 2013-03-27

Family

ID=36817066

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2006034541A Expired - Fee Related JP5168791B2 (ja) 2005-02-11 2006-02-10 アクセプタンス状態の表示システム及び方法
JP2012213045A Expired - Fee Related JP5789236B2 (ja) 2005-02-11 2012-09-26 構造化文書分析方法、構造化文書分析プログラム、および構造化文書分析システム

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2012213045A Expired - Fee Related JP5789236B2 (ja) 2005-02-11 2012-09-26 構造化文書分析方法、構造化文書分析プログラム、および構造化文書分析システム

Country Status (2)

Country Link
US (1) US8996991B2 (ja)
JP (2) JP5168791B2 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7689903B2 (en) * 2005-03-22 2010-03-30 International Business Machines Corporation Unified markup language processing
US8102857B2 (en) * 2007-02-02 2012-01-24 Motorola Solutions, Inc. System and method for processing data and control messages in a communication system
US20130091266A1 (en) 2011-10-05 2013-04-11 Ajit Bhave System for organizing and fast searching of massive amounts of data
US9128912B2 (en) * 2012-07-20 2015-09-08 Fujitsu Limited Efficient XML interchange schema document encoding
US11301219B2 (en) * 2015-05-22 2022-04-12 Paypal, Inc. Hosted sensitive data form fields for compliance with security standards

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6041324A (en) * 1997-11-17 2000-03-21 International Business Machines Corporation System and method for identifying valid portion of computer resource identifier
US6643662B1 (en) * 2000-09-21 2003-11-04 International Business Machines Corporation Split bi-directional stack in a linear memory array
JP4072284B2 (ja) 1999-04-13 2008-04-09 キヤノン株式会社 データ処理方法及び装置及び記憶媒体
JP2001075958A (ja) * 1999-09-03 2001-03-23 Mitsubishi Electric Corp 構造化文書処理装置及び構造化文書処理方法
US6912538B2 (en) 2000-10-20 2005-06-28 Kevin Stapel System and method for dynamic generation of structured documents
US6763500B2 (en) 2000-12-01 2004-07-13 Microsoft Corporation Real-time-on-demand dynamic document generation
US7117504B2 (en) * 2001-07-10 2006-10-03 Microsoft Corporation Application program interface that enables communication for a network software platform
US7287229B2 (en) * 2002-04-03 2007-10-23 Hewlett-Packard Development Company, L.P. Template-driven process system
KR100472458B1 (ko) 2002-06-26 2005-03-10 삼성전자주식회사 외부 ｘｍｌ유효성 검증 장치를 이용하는 ｘｍｌ파싱 장치및 방법
US7373595B2 (en) 2002-06-27 2008-05-13 Microsoft Corporation System and method for validating an XML document and reporting schema violations
US20040027326A1 (en) * 2002-08-06 2004-02-12 Grace Hays System for and method of developing a common user interface for mobile applications
US7493603B2 (en) * 2002-10-15 2009-02-17 International Business Machines Corporation Annotated automaton encoding of XML schema for high performance schema validation
JP3832830B2 (ja) * 2003-04-25 2006-10-11 インターナショナル・ビジネス・マシーンズ・コーポレーション ＸＰａｔｈ評価方法、これを用いたＸＰａｔｈ評価装置及び情報処理装置
JP2005018672A (ja) 2003-06-30 2005-01-20 Hitachi Ltd 構造化文書の圧縮方法
EP1646942B1 (en) 2003-07-11 2012-12-26 Google, Inc. Xml validation processing
US20050060317A1 (en) 2003-09-12 2005-03-17 Lott Christopher Martin Method and system for the specification of interface definitions and business rules and automatic generation of message validation and transformation software
US7596748B2 (en) 2003-09-12 2009-09-29 International Business Machines Corporation Method for validating a document conforming to a first schema with respect to a second schema
US20050138542A1 (en) * 2003-12-18 2005-06-23 Roe Bryan Y. Efficient small footprint XML parsing
US8621340B2 (en) * 2004-12-20 2013-12-31 Microsoft Corporation Block properties and calculated columns in a spreadsheet application

Also Published As

Publication number Publication date
US20060184874A1 (en) 2006-08-17
JP2013008395A (ja) 2013-01-10
US8996991B2 (en) 2015-03-31
JP2006221657A (ja) 2006-08-24
JP5789236B2 (ja) 2015-10-07

Similar Documents

Publication Publication Date Title
JP4997777B2 (ja) デリミタを減少させる方法及びシステム
JP5044942B2 (ja) 文書分析において受付状態を決定するシステム及び方法
JP5377818B2 (ja) コンパイル済みスキーマに順次アクセスする方法とシステム
JP5044943B2 (ja) データ文書の高速符号化方法及びシステム
US6825781B2 (en) Method and system for compressing structured descriptions of documents
US7526490B2 (en) Method of and system for providing positional based object to XML mapping
US7296226B2 (en) XML-based multi-format business services design pattern
US7844956B2 (en) Object-oriented processing of markup
US20030018661A1 (en) XML smart mapping system and method
US20040015890A1 (en) System and method for adapting files for backward compatibility
US20030115548A1 (en) Generating class library to represent messages described in a structured language schema
US20080208830A1 (en) Automated transformation of structured and unstructured content
WO2003091903A1 (en) System and method for processing of xml documents represented as an event stream
JP5789236B2 (ja) 構造化文書分析方法、構造化文書分析プログラム、および構造化文書分析システム
JP4776389B2 (ja) 符号化文書復号方法及びシステム
JP2006221655A (ja) スキーマをコンパイルする方法とシステム
US20080208876A1 (en) Method of and System for Providing Random Access to a Document
CN116451651A (zh) 一种字符数据转码方法、装置、设备及存储介质
JP2004342029A (ja) 構造化文書圧縮方法及び装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20081022

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110325

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110405

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110606

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20111213

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120213

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20120626

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120926

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20121003

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20121204

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20121217

R150 Certificate of patent or registration of utility model

Ref document number: 5168791

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees