(57)【特許請求の範囲】
【請求項１】
マークアップ言語スキーマの妥当性検査方法であって、
（ａ）コンピュータが、マークアップ言語スキーマ妥当性検査パーサを含むランタイム妥当性検査エンジンに、マークアップ言語文書をロードするステップと、
（ｂ）コンピュータが、注釈付きオートマトン・エンコーディング・フォーマットにコンパイルされたマークアップ言語スキーマ定義を、前記マークアップ言語スキーマ妥当性検査パーサにロードするステップと、
（ｃ）前記マークアップ言語スキーマ妥当性検査パーサを実行するコンピュータが、前記注釈付きオートマトン・エンコーディング・フォーマットにコンパイルされたマークアップ言語スキーマ定義を利用して、前記マークアップ言語文書の妥当性を検査するステップと
を含み、
前記妥当性を検査するステップ（ｃ）が、さらに
（ｃ１）ＸＭＬ（拡張可能なマークアップ言語）文書に対して少なくとも１つのトークンを取得するステップと、
（ｃ２）コンピュータが汎用ＸＭＬパーサを実行することによって前記少なくとも１つのトークンの低レベル妥当性検査を実施するステップと、
（ｃ３）前記トークンが要素トークンまたは属性トークンである場合、コンピュータがＸＭＬスキーマ妥当性検査パーサを実行することにより前記少なくとも１つのトークンの高レベル妥当性検査を実施するステップと
を含む、前記方法。
【請求項２】
前記マークアップ言語が、ＸＭＬを含む、請求項１に記載の方法。
【請求項３】
前記注釈付きオートマトン・エンコーディング・フォーマットにコンパイルされたマークアップ言語スキーマ定義が、少なくとも１つの要素ノードを含み、１つまたは複数の属性を、前記要素ノードと関連付けることができ、また１つまたは複数のデータ型制約を、前記要素ノードまたは前記属性と関連付けることができる、請求項１または２に記載の方法。
【請求項４】
前記注釈付きオートマトン・エンコーディング・フォーマットにコンパイルされたマークアップ言語スキーマ定義が、前記少なくとも１つの要素ノードに対して少なくとも１つの要素注釈レコードを含み、前記少なくとも１つの要素注釈レコードが、
要素内容および引数に対するスキャナＩＤと、
開始タグ・トークンと、
終了タグ・トークンと、
属性リストと、
副要素名へのポインタを含むことができる副要素候補マップと
からなる１つまたは複数のグループを含む、請求項１〜３のいずれか一項に記載の方法。
【請求項５】
前記ロードするステップ（ａ）の前に、コンピュータが実行する、
（ａ１）ＸＭＬスキーマ定義を受け取るステップと、
（ａ２）前記ＸＭＬスキーマ定義のために要素構造階層を生成し、前記階層を注釈付きツリーで表すステップと、
（ａ３）前記注釈付きツリーをエンコードし、前記注釈付きオートマトン・エンコーディング・フォーマットのＸＭＬスキーマ定義を生成するステップと、
（ａ４）前記注釈付きオートマトン・エンコーディング・フォーマットのＸＭＬスキーマ定義を直列化するステップと、
（ａ５）前記直列化された前記注釈付きオートマトン・エンコーディング・フォーマットのＸＭＬスキーマ定義を記憶するステップと
を含む、請求項１〜４のいずれか一項に記載の方法。
【請求項６】
前記妥当性を検査するステップ（ｃ）が、さらに
（ｃ４）前記汎用ＸＭＬパーサおよび前記ＸＭＬスキーマ妥当性検査パーサを実行するコンピュータによる妥当性検査が成功した場合、妥当性検査の合格を出力するステップと、
（ｃ５）前記汎用ＸＭＬパーサまたは前記ＸＭＬスキーマ妥当性検査パーサを実行するコンピュータによる妥当性検査が成功しなかった場合、妥当性検査の不合格を出力するステップと
を含む、請求項５に記載の方法。
【請求項７】
前記要素トークンが、
開始タグ名と、
終了タグ名と
からなる１つまたは複数のグループを含む、請求項５または６に記載の方法。
【請求項８】
前記属性トークンが属性名を含む、請求項５〜７のいずれか一項に記載の方法。
【請求項９】
前記要素トークンが開始タグ名であった場合、前記実施するステップ（ｃ３）が、
（ｃ３ｉ）前の注釈レコードおよび前記開始タグ名に基づいてカレントの注釈レコードを見つけるステップと、
（ｃ３ｉｉ）前記カレントの注釈レコードをスタックに追加するステップと、
（ｃ３ｉｉｉ）前記カレントの注釈レコードから前記開始タグ名に対する開始タグ・トークンを取得するステップと、
（ｃ３ｉｖ）前記開始タグ・トークンを、前記ＸＭＬスキーマ妥当性検査パーサの要素妥当性検査モジュールに入力するステップと、
（ｃ３ｖ）前記開始タグ・トークンの妥当性検査が成功したかどうか判定するステップと
を含む、請求項５〜８のいずれか一項に記載の方法。
【請求項１０】
前記属性トークンが属性名であった場合、前記実施するステップ（ｃ３）が、
（ｃ３ｉ）カレントの注釈レコードおよび前記属性名を前記ＸＭＬスキーマ妥当性検査パーサの属性妥当性検査モジュールに渡すステップと、
（ｃ３ｉｉ）前記属性名を求めて前記カレントの注釈レコードの属性リストを検索するステップであって、前記属性名が前記カレントの注釈レコード中で見つからなかった場合、前記ＸＭＬ文書の妥当性検査が失敗するステップと、
（ｃ３ｉｉｉ）前記属性名が、前記カレントの注釈レコード中で見つかった場合、前記属性トークンを取得するステップと、
（ｃ３ｉｖ）前記属性トークンの前記妥当性検査が成功したかどうか判定するステップと
を含む、請求項５〜９のいずれか一項に記載の方法。
【請求項１１】
前記要素トークンが終了タグ名であった場合、前記実施するステップ（ｃ３）が、
（ｃ３ｉ）スタックからカレントの注釈レコードを取りだすステップと、
（ｃ３ｉｉ）前記カレントの注釈レコードから終了タグ・トークンを取得するステップと、
（ｃ３ｉｉｉ）前記終了タグ・トークンを前記ＸＭＬスキーマ妥当性検査パーサの要素妥当性検査モジュールに入力するステップと、
（ｃ３ｉｖ）前記終了タグ・トークンの妥当性検査が成功したかどうか判定するステップと、
（ｃ３ｖ）前記カレントの注釈レコードのすべての属性の妥当性が検査されたかどうか、または前記カレントの注釈レコードの前記属性リストが空であるかどうか判定するステップであって、前記カレントの注釈レコードの前記属性のすべてが妥当性検査されておらず、前記カレントの注釈レコードの前記属性リストが空ではない場合、前記終了タグ・トークンの妥当性検査が成功しないステップと
を含む、請求項５〜１０のいずれか一項に記載の方法。
【請求項１２】
請求項１〜１１のいずれか一項に記載の方法をコンピュータに実行させるためのコンピュータ・プログラム。
【請求項１３】
請求項１２に記載のコンピュータ・プログラムを実装したコンピュータ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＸＭＬ（extensible mark-up language、拡張可能なマークアップ言語）スキーマに関し、より詳細には、ＸＭＬスキーマによるＸＭＬ文書の妥当性検査に関する。
【背景技術】
【０００２】
ＸＭＬ（拡張可能なマークアップ言語）スキーマは、当技術分野でよく知られている。ＸＭＬスキーマを用いると、ユーザは複雑な構造を有するＸＭＬデータ・オブジェクトを定義できるようになり、データの記憶およびデータベース中の処理においてＸＭＬフォーマットを広範囲に使用できるようになる。各ＸＭＬ文書が提供されたとき、それをデータの記憶および処理で使用する前に、そのＸＭＬスキーマ定義に対する妥当性検査を行って、それに準拠していることを保証することが必要である。
【０００３】
従来、ＸＭＬスキーマ妥当性検査には、２つの主な手法が使用される。第１の手法は、汎用スキーマ妥当性検査パーサである。その手法では、パーサは、入力としてＸＭＬスキーマ定義およびＸＭＬ文書を受け取り、そのＸＭＬ文書を構文解析してツリー・フォーマットにし、ＸＭＬスキーマ定義を構文解析してスキーマ・ツリー・フォーマットにし、次いで、ＸＭＬ文書ツリーを横断（traverse）してＸＭＬスキーマ・ツリーに対する検査を行う。多くの様々なＸＭＬスキーマに対してその同じ汎用スキーマ妥当性検査パーサが使用される。この手法は、多くの様々なＸＭＬに対して妥当性検査を行うことできる点で柔軟性があるが、通常、この手法は性能が悪い。
【０００４】
第２の手法は、特定のＸＭＬスキーマ定義に基づいてＸＭＬスキーマ妥当性検査パーサ・コードを生成するものである。そのＸＭＬスキーマ妥当性検査パーサ・コードは、実行可能なコードにコンパイルされ、その特定のＸＭＬスキーマ定義に対してＸＭＬ文書の妥当性を検査するのに使用される。この手法は、第１の手法より高速にすることができるが、数多くのＸＭＬスキーマ定義がある場合は、数多くの妥当性検査パーサがあり得ることとなり、スペースにオーバーヘッドが必要となる。各ＸＭＬスキーマ妥当性検査パーサが、単に特定の１つのＸＭＬスキーマに対してのみ妥当性検査が可能である場合もまた柔軟性がなくなる。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
したがって、ＸＭＬスキーマ妥当性検査のための改善された方法およびシステムが求められている。その改善された方法およびシステムは、スペース・オーバーヘッドをあまり必要とせずに高性能を提供する必要がある。本発明は、かかる要求に対処する。
【課題を解決するための手段】
【０００６】
ＸＭＬ（拡張可能なマークアップ言語）スキーマ妥当性検査のための方法およびシステムは、ＸＭＬスキーマ妥当性検査パーサを含むランタイム妥当性検査エンジンにＸＭＬ文書をロードすることと、ＸＭＬスキーマ定義のための注釈付きオートマトン・エンコーディング（ＡＡＥ）をＸＭＬスキーマ妥当性検査パーサにロードすることと、ＸＭＬスキーマ妥当性検査パーサが、その注釈付きオートマトン・エンコーディングを利用して、ＸＭＬスキーマ定義に対するＸＭＬ文書の妥当性を検査することとを含む。各ＸＭＬスキーマ定義は、ＸＭＬ文書が妥当性検査されるごとにコンパイルされるのではなく、ＡＡＥフォーマットに１度だけコンパイルされることになり、したがって、多くの時間が節約されるようになる。ランタイム妥当性検査エンジンのためのコードは、ＸＭＬスキーマ定義ごとに変わるのではなく固定されており、またＸＭＬスキーマ定義に応じて変化せず、したがってスペースのオーバーヘッドは最小化される。
【０００７】
妥当性検査プロセスにおける柔軟性が性能と妥協することなく提供される。
【発明を実施するための最良の形態】
【０００８】
本発明は、ＸＭＬスキーマ妥当性検査のための改善された方法およびシステムを提供する。以下の説明は、当業者が本発明を製作し使用できるように提示され、特許出願およびその要件のコンテキストで提供される。好ましい実施形態への様々な変更は、当業者には容易に明らかとなるものであり、また本明細書における包括的な原理を他の諸実施形態に適用することができる。したがって、本発明は、示した実施形態に限定されるのではなく、ここに述べる原理と特徴に適合する最も広い範囲に一致するものとする。
【０００９】
導入
本発明による改善された方法およびシステムは、ＸＭＬスキーマ定義を注釈付きオートマトン・エンコーディング（ＡＡＥ）フォーマットにコンパイルし、それをディスクまたはデータベースに記憶する。各ＸＭＬスキーマ定義は、ＡＡＥフォーマットに１度だけコンパイルされる。ＸＭＬ文書の妥当性を検査するとき、ＸＭＬ文書およびＡＡＥフォーマットの適切なＸＭＬスキーマ定義がランタイム妥当性検査エンジンにロードされる。ランタイム妥当性検査エンジンは、汎用ＸＭＬパーサおよびランタイム・スキーマ妥当性検査パーサを含む。ランタイム妥当性検査エンジンのためのコードは固定され、ＸＭＬスキーマ定義に応じて変わることはない。汎用ＸＭＬパーサが低レベルの妥当性検査を実施し、一方、ランタイム妥当性検査パーサが、ＡＡＥフォーマットのＸＭＬスキーマ定義に対してＸＭＬ文書の高レベルの妥当性検査を実施する。ランタイム妥当性検査エンジンの出力は、妥当性検査の合格（pass）または不合格（fail）である。
【００１０】
本発明の特徴をより具体的に説明するために、以下の議論と共に図１から図２１を参照されたい。
【００１１】
図１は、本発明によるＸＭＬスキーマ妥当性検査システムの好ましい実施形態を示す。システムは、ＸＭＬスキーマ・コンパイル１０２およびランタイム妥当性検査エンジン１０４の２組のロジックを含む。
【００１２】
ＸＭＬスキーマ・コンパイル１０２は、ＸＭＬスキーマ定義１０６を入力として受け取り、出力として、注釈付きオートマトン・エンコーディング（ＡＡＥ）・フォーマットの各ＸＭＬスキーマ１０８を提供する。ＡＡＥフォーマットのＸＭＬスキーマ定義１０８は、後で容易に取り出せるように、ディスク上またはデータベース１１０に記憶する。ＡＡＥフォーマットは、通常、ＬＡＬＲ（１）（Look Ahead Left to Right）パーサ生成装置から得られる構文解析テーブルのフォーマットを含むが、さらに注釈を追加したものである。注釈は、特定のＸＭＬスキーマ定義のために作成されたＸＭＬスキーマ・ツリーの要素ノードおよび属性に対する、要素ノードおよびデータ型制約のための属性である。ＸＭＬスキーマ・コンパイル１０２およびＡＡＥフォーマットはさらに、図２〜９を参照して以下で説明する。
【００１３】
ランタイム妥当性検査エンジン１０４は、ＸＭＬ文書１１２およびそれに対応するＡＡＥフォーマットのＸＭＬスキーマ定義１０８を入力として受け取り、出力として妥当性検査の合否を提供する。ランタイム妥当性検査エンジン１０４はさらに、図１０〜１４を参照して以下で説明する。
【００１４】
ＸＭＬスキーマ・コンパイル
図２は、本発明によるＸＭＬスキーマ・コンパイル１０２をより詳細に示す。ＸＭＬスキーマ・コンパイル１０２は、ＸＭＬスキーマ・コンパイラ・フロントエンド２０２およびＸＭＬスキーマ・コンパイラ・バックエンド２０４を含む。図３は、本発明によるＸＭＬスキーマ・コンパイル・プロセスの好ましい実施形態を示す流れ図である。
【００１５】
図２と図３を共に参照すると、ステップ３０２で、ＸＭＬスキーマ・コンパイラ・フロントエンド２０２が入力としてＸＭＬスキーマ定義１０６を受け取る。次いで、ステップ３０４で、ＸＭＬスキーマ・コンパイラ・フロントエンド２０２が要素構造階層を生成し、それを注釈付きツリーで示す。ツリーの節点（node）は、要素ノードであり、枝（edge）はノード間の構造的な関係である。注釈は、要素ノードおよび属性に対する、要素ノードおよびデータ型制約のための属性である。この注釈付きツリーをさらに以下で説明する。
【００１６】
次に、ステップ３０６で、ＸＭＬスキーマ・コンパイラ・バックエンド２０４は、注釈付きツリーをエンコードし、注釈付きオートマトン・エンコーディングを生成する。次いで、ステップ３０８で、注釈付きオートマトン・エンコーディングは直列化（serialized）され、ディスク上またはデータベースに記憶される。したがって、注釈付きオートマトン・エンコーディングは、ＡＡＥフォーマットのＸＭＬスキーマ定義１０８である。
【００１７】
図４〜９は、本発明によるＸＭＬスキーマ・コンパイル１０２によって実施される方法の一実施例を示す。図４は、例示的なＸＭＬスキーマ定義４００を示す。ＸＭＬスキーマ定義４００は、デフォルトのＸＭＬｎａｍｅｓｐａｃｅ（名前空間）４０２、ｎａｍｅｓｐａｃｅ宣言４０４、および登録されたターゲットｎａｍｅｓｐａｃｅ４０５を含む。セキュリティのために、ＸＭＬスキーマは登録することができ、そのＸＭＬスキーマが、登録されたＸＭＬスキーマ参照４０４によって参照される別のロケーションでアクセスされる。ＸＭＬスキーマ定義４００はまた、文書化のためのａｎｎｏｔａｔｉｏｎｓ（注釈）４０６を含む。この実施例では、ａｎｎｏｔａｔｉｏｎ４０６は、「ｘｍｌ：ｌａｎｇ＝‘ｅｎ’」という属性４１０を有する「ｄｏｃｕｍｅｎｔａｔｉｏｎ」と名付けられた要素４０８を含むものとして定義されている。
【００１８】
ＸＭＬスキーマ定義４００はさらに、ｐｅｒｓｏｎｎｅｌ（職員）４１２およびｎｏｔｅｓ（注記）４２６などのグローバル要素宣言を含む。ｐｅｒｓｏｎｎｅｌグローバル要素４１２は、複合型であり、ｅｍｐｌｏｙｅｅ（従業員）４１４と名付けられた一連の副要素を有すると宣言している。ｅｍｐｌｏｙｅｅ副要素４１４も複合型であり、意味的制約４１６を有すると宣言している。ｅｍｐｌｏｙｅｅ副要素４１４自体は、それぞれがそれ自体に構文上の制約４２０を有する副要素４１８を有すると宣言している。この実施例では、その副要素は、ｌａｓｔｎａｍｅ（姓）、ｆｉｒｓｔｎａｍｅ（名）、およびｎｏｔｅｓであり、それぞれが単純型（ｓｔｒｉｎｇ）である。そのｅｍｐｌｏｙｅｅ副要素４１４はまた、いくつかの属性４２２を有すると宣言しており、それぞれが単純型４２４であると定義されている。この実施例では、属性４２２は、ｉｎｔｅｇｅｒ型のｓｅｒｎｏ（通し番号）、ＵＳＥＲＩＤ＿ＴＹＰＥ型のｕｓｅｒｉｄ（ユーザＩＤ）、およびｓｔｒｉｎｇ型のｄｅｐａｒｔｍｅｎｔ（部門）を含む。ｉｎｔｅｇｅｒ型およびｓｔｒｉｎｇ型は、事前定義されている。ＵＳＥＲＩＤ＿ＴＹＰＥ型は事前定義されていない。その定義は、ＸＭＬスキーマ定義中の４２８に記述される。
【００１９】
ステップ３０２で、ＸＭＬスキーマ・コンパイラ・フロントエンド２０２が、入力としてそのＸＭＬスキーマ定義４００を受け取る。次いで、それはＸＭＬスキーマ定義４００に対する要素構造階層を生成し、それを図５に示す注釈付きツリー５００で表す。実線は、ツリー５００の要素ノードを接続する。破線は、要素ノードを属性の注釈に接続する。
【００２０】
例えば、実線は、ｐｅｒｓｏｎｎｅｌノード５０２をｅｍｐｌｏｙｅｅノード５０６に接続し、またｅｍｐｌｏｙｅｅノード５０６をｌａｓｔｎａｍｅ５０８、ｆｉｒｓｔｎａｍｅ５１０、およびｎｏｔｅｓ５１２ノードに接続する。ツリー５００は、ｎｏｔｅｓおよびｐｅｒｓｏｎｎｅｌがグローバル要素であり、したがって、それらはノードの第１レベルにあることを示す。ｅｍｐｌｏｙｅｅは、ｐｅｒｓｏｎｎｅｌの副要素であり、したがって、そのノードは第２レベルにあり、実線でｐｅｒｓｏｎｎｅｌノードに接続されている。ｌａｓｔｎａｍｅ、ｆｉｒｓｔｎａｍｅ、およびｎｏｔｅｓは、ｅｍｐｌｏｙｅｅの副要素であり、したがって、そのノード５０８〜５１２は第３レベルにあり、実線でｅｍｐｌｏｙｅｅノード５０６に接続されている。ｌａｓｔｎａｍｅ５０８、ｆｉｒｓｔｎａｍｅ５１０、およびｎｏｔｅｓ５０４ノードの近傍にある破線による楕円形の「ｓｔｒｉｎｇ」５１４〜５１８は、そのそれぞれが対応するノードのデータ型を示すデータ型注釈ノードである。
【００２１】
ツリー５００はさらに、ｅｍｐｌｏｙｅｅノード５０６が、ｓｅｒｎｏの４角形５２０、ｕｓｅｒｉｄの４角形５２２、およびｄｅｐａｒｔｍｅｎｔの４角形５２４によって表された属性を有するように定義されていることを示す。４角形の近傍の破線による楕円形ＵＳＥＲＩＤ＿ＴＹＰＥ５２６、Ｉｎｔｅｇｅｒ５２８、およびＳｔｒｉｎｇ５３０は、その対応する型注釈ノードである。
【００２２】
注釈付きツリー５００がＸＭＬスキーマ定義４００に対して生成された後、ステップ３０６で、ＸＭＬスキーマ・コンパイラ・バックエンド２０４は注釈付きツリー５００をエンコードし、注釈付きオートマトン・エンコーディングを生成する。その注釈付きツリー５００のエンコードにおいて、ＸＭＬスキーマ・コンパイラ・バックエンド２０４は、まず、注釈付きツリー５００の要素制約、すなわち、図６で示すように、文脈自由文法（ＣＦＧ）で実線によって指定されたツリー構造を表す。次いで、それは、図７で示すように、要素ごとに接頭部として開始タグ・トークンを付加し、かつ要素ごとに接尾部として終了タグ・トークンを付加することによりＣＦＧを拡張する。例えば、ｐｅｒｓｏｎｎｅｌ要素の場合、開始タグ・トークンＰＳおよび終了タグ・トークンＰＥが付加される。ｅｍｐｌｏｙｅｅ要素の場合は、開始タグ・トークンＥＳおよび終了タグ・トークンＥＥが付加される。開始および終了タグ・トークンは、同様に、ｌａｓｔｎａｍｅ、ｆｉｒｓｔｎａｍｅ、およびｎｏｔｅｓ要素に付加される。次いで、ＬＡＬＲ（１）パーサ生成装置アルゴリズムが構文解析テーブルまたは状態遷移テーブルを生成するために使用される。次いで、図５に示すツリーの注釈から注釈レコードを構築するために、他のアルゴリズムが使用される。例示的なＸＭＬスキーマ定義４００に対して得られた状態遷移グラフの注釈部分を図８に示す。このような注釈付きオートマトン・エンコーディングを生成することにより、ＸＭＬデータ・オブジェクトの妥当性検査は、一連の開始または終了タグが図７に示された文法に準拠しているかどうかの検査を含む。
【００２３】
図８を参照すると、例示的なＸＭＬスキーマ定義４００は、オートマトン・エンコーディング・テーブル８０１、およびグローバル要素ｎｏｔｅｓ８０２およびｐｅｒｓｏｎｎｅｌ８０３を含むグローバル要素マップを含む。図９は、例示的なＸＭＬスキーマ定義４００に対するオートマトン・エンコーディング・テーブル８０１のための状態遷移グラフを示す。簡単のために、図９は、定義４００に対する遷移枝（SHIFT edge）だけを示し、還元枝（REDUCE edge）は省略する。
【００２４】
図８に戻ると、グローバル要素マップは、ｎｏｔｅｓ要素名８０２およびｐｅｒｓｏｎｎｅｌ要素名８０３を含む。それらは、ｎｏｔｅｓ８０２およびｐｅｒｓｏｎｎｅｌ８０３要素に対して、それぞれ注釈レコード８４３および８０９へのポインタを含む。ｐｅｒｓｏｎｎｅｌ要素注釈レコード８０９は、その要素内容および引数８０４（＜ａｎｙＴｙｐｅＩＤ、ｎｕｌｌ＞）に対するスキャナＩＤ、その開始タグ・トークン８０５（ＰＳ）、その終了タグ・トークン８０６（ＰＥ）、属性リスト８０７、および副要素候補マップ８０８を含む。ｐｅｒｓｏｎｎｅｌ要素注釈レコード８０９に対する属性リスト８０７はヌル（null）である。副要素候補マップ８０８は、そのローカル要素マップへのポインタを含む。ローカル要素マップ８１０は、ｅｍｐｌｏｙｅｅ要素名を含み、それは、ｅｍｐｌｏｙｅｅ要素注釈レコード８１６へのポインタを含む。
【００２５】
ｅｍｐｌｏｙｅｅ要素注釈レコード８１６は、その要素内容および引数８１１（＜ａｎｙＴｙｐｅＩＤ、ｎｕｌｌ）に対するスキャナＩＤ、その開始タグ・トークン８１２（ＥＳ）、その終了タグ・トークン８１３（ＥＥ）、属性リスト８１４、および副要素候補マップ８１５を含む。ＸＭＬスキーマ定義４００によると、属性リスト８１４は、ｓｅｒｎｏ、ｕｓｅｒｉｄ、およびｄｅｐａｒｔｍｅｎｔの３つの属性を含む。したがって、属性リスト８１４は、ｓｅｒｎｏ属性名８１７およびその値と引数８１８（＜ｉｎｔｅｇｅｒＴｙｐｅＩＤ、ｎｕｌｌ＞）に対するスキャナＩＤ、ｕｓｅｒｉｄ属性名８１９およびその値と引数８２０（＜ａｎｙＳｉｍｐｌｅＴｙｐｅＩＤ、（ａ―ｚＡ―Ｚ）（１）（１−９ａ−ｚａ−Ｚ＞）、およびｄｅｐａｒｔｍｅｎｔ属性名８２１およびその値と引数８２２（＜ｓｔｒｉｎｇＴｙｐｅＩＤ、ｎｕｌｌ＞）へのポインタを含む。
【００２６】
ｅｍｐｌｏｙｅｅ要素注釈レコード８１６に対する副要素候補マップ８１５は、そのローカル要素マップへのポインタを含み、それは、ｅｍｐｌｏｙｅｅ要素の副要素の注釈レコードへのポインタを含む。ＸＭＬスキーマ定義４００によると、ｅｍｐｌｏｙｅｅ要素の副要素は、ｌａｓｔｎａｍｅ、ｆｉｒｓｔｎａｍｅ、およびｎｏｔｅｓ要素を含む。そしてそれぞれが、ｌａｓｔｎａｍｅ要素注釈レコード８２９、ｆｉｒｓｔｎａｍｅ要素注釈レコード８３７、およびｎｏｔｅｓ要素注釈レコード８４３を含む。
【００２７】
ｌａｓｔｎａｍｅ要素注釈レコード８２９は、その内容および引数８２４（＜ｓｔｒｉｎｇＴｙｐｅＩＤ、ｎｕｌｌ＞）に対するスキャナＩＤ、その開始タグ・トークン８２５（ＬＳ）、その終了タグ・トークン８２６（ＬＥ）、属性リスト８２７、および副要素候補マップ８２８を含む。ＸＭＬスキーマ定義４００によると、ｌａｓｔｎａｍｅ要素は、属性および副要素を有しておらず、したがって、その属性リスト８２７および副要素候補マップ８２８はヌルである。
【００２８】
ｆｉｒｓｔｎａｍｅ要素注釈レコード８３７は、その内容および引数８３２（＜ｓｔｒｉｎｇＴｙｐｅＩＤ、ｎｕｌｌ＞）に対するスキャナＩＤ、その開始タグ・トークン８３３（ＦＳ）、その終了タグ・トークン８３４（ＦＥ）、属性リスト８３５、および副要素候補マップ８３６を含む。ＸＭＬスキーマ定義４００によると、ｆｉｒｓｔｎａｍｅ要素は、属性および副要素を有しておらず、したがって、その属性リスト８３５および副要素候補マップ８３６はヌルである。
【００２９】
ｎｏｔｅｓ要素注釈レコード８４３は、その内容および引数８３８（＜ｓｔｒｉｎｇＴｙｐｅＩＤ、ｎｕｌｌ＞）に対するスキャナＩＤ、その開始タグ・トークン８３９（ＮＳ）、その終了タグ・トークン８４０（ＮＥ）、属性リスト８４１、および副要素候補マップ８４２を含む。ＸＭＬスキーマ定義４００によると、ｎｏｔｅｓ要素は、属性および副要素を有しておらず、したがって、その属性リスト８４１および副要素候補マップ８４２はヌルである。
【００３０】
注釈付きオートマトン・エンコーディング８００は、さらに以下で説明するように、ＸＭＬスキーマ定義４００に対してＸＭＬ文書の妥当性を検査するために用いられる。
【００３１】
ランタイム妥当性検査エンジン
図１０は、本発明によるランタイム妥当性検査エンジン１０４をより詳細に示す。ランタイム妥当性検査エンジン１０４は、ＸＭＬスキャナ・プール１００２、汎用ＸＭＬパーサ１００４、およびランタイム・スキーマ妥当性検査パーサ１００６を含む。ＸＭＬスキャナ・プール１００２は、汎用スキャナ１０１７、および特有の単純データ型のための他のスキャナ１０１８〜１０２０を含む。汎用スキャナ１０１７は、すべての字句トークンを走査できるが、その性能は限定されている。特有のデータ型のためのスキャナ１０１８〜１０２０は、より優れた性能を提供する。例えば、ｉｎｔｅｇｅｒ型のためのスキャナ１０１９およびｓｔｒｉｎｇ型のためのスキャナ１０２０は、ＸＭＬスキャナ・プール１００２の一部とすることができる。好ましい実施形態では、ＡｎｙＳｉｍｐｌｅＴｙｐｅスキャナ１０１８は、任意の単純データ型のための汎用スキャナとして使用される。各スキャナ１０１７〜１０２０は、一意的なスキャナＩＤ（０、１、・・・、ｎ、ｎ+１）を有する。スキャナは、入力ＸＭＬ文書１１２をトークン化するために汎用ＸＭＬパーサ１００４によってコールされる。どのスキャナをコールするかは、ＡＡＥフォーマットのＸＭＬスキーマ１０８にしたがってランタイム・スキーマ妥当性検査パーサ１００６によって決定される。
【００３２】
汎用ＸＭＬパーサ１００４は、スキャナからトークンを受け取り、基本的なＸＭＬ文法を検査する。そのトークンが要素トークン、すなわち開始タグ名または終了タグ名である場合、あるいはそのトークンが、属性トークンである場合、それらは、語彙素（lexeme）としてランタイム・スキーマ妥当性検査パーサ１００６に送られる。ランタイム・スキーマ妥当性検査パーサ１００６は、ＡＡＥフォーマットのＸＭＬスキーマ定義に対してその要素および属性の語彙素の妥当性検査を行う。したがって、ＣＦＧ（図６参照）中のスキーマ構造にしたがって、汎用ＸＭＬパーサ１００４は、低レベルの妥当性検査を実施し、一方、ランタイム・スキーマ妥当性検査パーサ１００６は、高レベルの妥当性検査を実施する。
【００３３】
ランタイム・スキーマ妥当性検査パーサ１００６は、ＸＭＬスキーマ・ローディング・モジュール１０１０を含み、それは、ＡＡＥフォーマットの適切なＸＭＬスキーマ１０８をディスクまたはデータベース１１０からロードする。ランタイム・スキーマ妥当性検査パーサ１００６はまた、実際の高レベル妥当性検査プロセスを実施するＸＭＬスキーマ妥当性検査モジュール１０１２を含む。そのモジュール１０１２は、要素の語彙素の妥当性検査のための要素妥当性検査モジュール１０１４、および属性の語彙素の妥当性検査のための属性妥当性検査モジュール１０１６を含む。
【００３４】
図１１〜１４は、本発明にしたがってランタイム妥当性検査エンジンにより実施されるランタイム妥当性検査プロセスの好ましい実施形態を示す流れ図である。まず、図１１を参照すると、ステップ１１０２で、ＸＭＬスキーマ・ローディング・モジュール１０１０がＡＡＥフォーマットのＸＭＬスキーマ１０８をロードし、汎用スキャナ１０１７をカレント・スキャナとして設定する。また、実体（entity）マネジャ１００８は、検証するためのＸＭＬ文書インスタンスによって参照されるＸＭＬ外部実体を取得する。ステップ１１０４で、ＸＭＬ文書１１２がロードされる。カレント・スキャナは、ＸＭＬ文書１１２をトークン化する。次いで、ステップ１１０６で、トークンを取得するために汎用ＸＭＬパーサ１００４は、カレント・スキャナをコールする。ステップ１１０８で、汎用ＸＭＬパーサ１００４は、トークンを返すことに成功したかどうかを検査する。トークンの走査が成功していない場合、ステップ１１１０で、その妥当性検査は「無効」であるとして返し、プロセスが終了する。ステップ１１１２で、トークンの走査が成功であり、汎用ＸＭＬパーサ１００４がそのトークンを要素または属性トークンであると判定した場合、ステップ１１１４で、トークンは、ＸＭＬスキーマ妥当性検査モジュール１０１２に語彙素として入力される。語彙素は、開始タグ名、属性名、または終了タグ名の３タイプのうちの１つであることができる。語彙素の各タイプは、ステップ１１１８、１１２０、または１１２２で、異なる方式により処理される。トークンが要素または属性トークンではない場合、ステップ１１２４で、そのトークンが、ファイルの終了（ＥＯＦ）トークン、すなわち、ＸＭＬ文書１１２の終了かどうか判定される。終了でなければ、ステップ１１０６に戻り、次のトークンのためにプロセスを繰り返す。終了の場合、ステップ１１２５で、汎用ＸＭＬパーサ１００４および要素妥当性検査モジュール１０１４が共に「受入れ（accept）」モード、すなわち、構文解析および妥当性検査が完了しているかどうか判定される。完了している場合、ＸＭＬ文書１１２の妥当性検査は成功し、ステップ１１２６で、「有効」を返す。完了していない場合は、妥当性検査が失敗し、ステップ１１２７で、「無効」を返す。
【００３５】
図１２は、本発明による開始タグ名の処理を示す流れ図である。まず、ステップ１２０２で、前の注釈レコードおよび開始タグ名に基づいて、ＸＭＬスキーマ妥当性検査モジュール１０１２は、カレントの注釈レコードを見つける。カレントの注釈レコードは、前の注釈レコードの副要素候補マップ中のカレントのタグ名前に対応したマップ・エントリによって示された注釈レコードである。ステップ１２０６で、そのカレントの注釈レコードは、スタックに追加（push）される。次いで、ステップ１２０８で、ＸＭＬスキーマ妥当性検査モジュール１０１２は、カレントの注釈レコードから開始タグ名に対応するトークンを取得し、そのトークンを要素妥当性検査モジュール１０１４に入力する。要素妥当性検査モジュール１０１４は、８０１などのＡＡＥの構文解析テーブル部分にしたがってＬＲ構文解析を行う。ステップ１２１０で、その妥当性検査が成功しなかった場合、妥当性検査は失敗し、ステップ１２１２で、「無効」を返す。ステップ１２１０で、妥当性検査が成功した場合は、ステップ１２１４で、カレントの注釈レコードに対する属性リストが空でありかつ要素内容が単純型である場合、ステップ１２１６で、カレントのスキャナＩＤが単純タイプ用のスキャナに設定される。次いで、プロセスは、図１１に示すステップ１１０６に進む。
【００３６】
図１３は、本発明による属性名の処理を示す流れ図である。まず、ＸＭＬスキーマ妥当性検査モジュール１０１２が、カレントの注釈レコードを取得し、ステップ１３０１で、カレントの注釈レコードおよび属性名を属性妥当性検査モジュール１０１６に渡す。ステップ１３０２で、属性妥当性検査モジュール１０１６が、その属性名を求めてカレントの注釈レコード中の属性リストを検索する。ステップ１３０４で、属性名がカレントの注釈レコード中で見つからなかった場合、そのＸＭＬ文書１１２の構造がＸＭＬスキーマ定義１０８に準拠しておらず、ＸＭＬ文書１１２の妥当性検査は失敗し、ステップ１３１０で、「無効」が返される。ステップ１３０４で、属性名が見つかった場合は、ステップ１３１２で、ＸＭＬスキーマ妥当性検査モジュール１０１２は、カレントのスキャナＩＤを属性値に対して単純タイプに設定する。次いで、プロセスは図１１に示すステップ１１２４に進む。
【００３７】
図１４は、本発明による終了タグ名の処理を示す流れ図である。まず、ステップ１４０２で、カレントの注釈レコードがスタックから取り出される。ＡＡＥフォーマットによると、注釈レコードの終了タグは、開始タグおよび属性の後で処理される。カレントの注釈レコードが前述の１２０２〜１２０４により設定されているので、終了タグ名のためのカレントの注釈レコードは、開始タグ名の注釈レコードとすべきである。終了タグ名は、処理すべき注釈レコードの最後のトークンであるため、その注釈レコードは、その処理でスタックから取り出される。次に、ステップ１４０４で、ＸＭＬスキーマ妥当性検査モジュール１０１２は、カレントの注釈レコードから終了タグ名のためのトークンを取得し、それを要素妥当性検査モジュール１０１４に入力する。ステップ１４０６で、妥当性検査が成功しなかった場合、その妥当性検査は失敗し、ステップ１４１０で、「無効」が返される。ステップ１４０６で、妥当性検査が成功した場合、ステップ１４０８で、ＸＭＬスキーマ妥当性検査モジュール１０１２は、カレントの注釈レコードに対するすべての属性の妥当性を検査されたか、または属性リストが空であるかどうかを判定する。そうでない場合は、ＸＭＬ文書１１２の構造がＸＭＬスキーマ定義１０８に準拠しておらず、その妥当性検査は失敗し、ステップ１４１０で、「無効」が返される。そうである場合は、図１１のステップ１１０６に戻り、次のトークンに対してプロセスを繰り返す。
【００３８】
好ましい実施形態における一意制約（uniqueness constraint）４３０について検査するために、ＸＭＬスキーマ定義４００のｅｍｐｌｏｙｅｅ要素などの場合、ｅｍｐｌｏｙｅｅのｓｅｒｎｏが前に扱われていないかどうか追跡するのにハッシュ・テーブルまたはアレイを使用することができる。
【００３９】
好ましい実施形態において参照整合性があるかどうか検査するために、ＸＭＬ文書１１２が走査されるとき、定義リストを収集することができる。次いで、その定義リストに対して参照を検査することができる。定義よりも前に参照が現れる場合は、ＸＭＬ文書１１２全体を走査する必要があり、参照は、参照整合性の検査前に記憶される。
【００４０】
妥当性検査の実施例
例えば、ＸＭＬ文書１１２に対するＸＭＬスキーマ定義が、例示的なＸＭＬスキーマ定義４００（図４）であると仮定する。図２０は、妥当性検査すべき例示的なＸＭＬ文書１６００を示す。ステップ１１０２で、ＸＭＬスキーマ・ローディング・モジュール１０１０が、ＡＡＥフォーマットのＸＭＬスキーマをロードし、汎用スキャナ１０１７をカレントのスキャナとして設定する。ステップ１１０４で、ＸＭＬ文書１６００もまたロードされる。ステップ１１０６で、汎用ＸＭＬパーサ１００４は、ｐｅｒｓｏｎｎｅｌ開始タグ名１６０２である最初のトークンを得るためにカレントのスキャナをコールする。ステップ１１０８で、トークンの走査が成功し、ステップ１１１２で、汎用ＸＭＬパーサ１００４が要素トークンであると判定し、ステップ１１１４で、それを語彙素としてＸＭＬスキーマ妥当性検査モジュール１０１２に入力する。次いで、ステップ１１１６で、ＸＭＬスキーマ妥当性検査モジュール１０１２が語彙素のタイプを判定する。その語彙素は、開始タグ名なので、図１２に示すように、プロセス・ステップ１１１８が実施される。
【００４１】
ｐｅｒｓｏｎｎｅｌ開始タグ名
ＸＭＬスキーマ定義４００のためのグラフ８００によると、ｐｅｒｓｏｎｎｅｌ開始タグ名８０３に対する前の注釈レコードがｐｅｒｓｏｎｎｅｌ要素注釈レコード８０９を指している。図１２を参照すると、ステップ１２０２で、ｐｅｒｓｏｎｎｅｌ要素注釈レコード８０９がカレントの注釈レコードであり、ステップ１２０６で、スタックに追加される。スタックの内容は、図１５に示すようになる。次いで、ステップ１２０８で、ＸＭＬスキーマ妥当性検査モジュール１０１２は、ｐｅｒｓｏｎｎｅｌ要素注釈レコード８０９からｐｅｒｓｏｎｎｅｌ開始タグ・トークン（ＰＳ）８０５を取得し、そのトークン８０５を要素妥当性検査モジュール１０１４に入力する。要素妥当性検査モジュール１０１４は、図９に示す状態遷移のために構文解析テーブルを使用するパーサである。ステップ１２１０で、妥当性検査が成功する。ステップ１２１４で、ｐｅｒｓｏｎｎｅｌ要素注釈レコード８０９のための属性リスト８０７は空（ヌル）であるが、内容は、複合型（ａｎｙＴｙｐｅＩＤ）である。したがって、妥当性検査プロセスは、図１１のステップ１１０６に戻り、次のトークンに対してプロセスを繰り返す。
【００４２】
ｅｍｐｌｏｙｅｅ開始タグ名
ステップ１１０６で、汎用ＸＭＬパーサ１００４は、次のトークンである、ｅｍｐｌｏｙｅｅ開始タグ名１６０４を取得するためにカレントのスキャナをコールする。ステップ１１０８で、トークンの走査が成功し、ステップ１１１２で、汎用ＸＭＬパーサ１００４はそれが要素トークンであると判定し、ステップ１１１４で、それを語彙素としてＸＭＬスキーマ妥当性検査モジュール１０１２に入力する。次いで、ステップ１１１６で、ＸＭＬスキーマ妥当性検査モジュール１０１２は語彙素タイプを判定する。その語彙素は開始タグ名であるので、図１２で示すように、プロセス・ステップ１１１８が実施される。
【００４３】
図１２を参照すると、ステップ１２０２で、ｐｅｒｓｏｎｎｅｌ要素注釈レコード８０９、すなわち、前の注釈レコードの副要素候補マップ８０８が、ｅｍｐｌｏｙｅｅ開始タグ名８１０を指しており、それは、ｅｍｐｌｏｙｅｅ要素注釈レコード８１６、すなわち、カレントの注釈レコードを指し、ステップ１２０６で、スタックに追加される。ここで、スタックの内容は、図１６に示すようになる。ステップ１２０８で、ＸＭＬスキーマ妥当性検査モジュール１０１２は、ｅｍｐｌｏｙｅｅ要素注釈レコード８１６からｅｍｐｌｏｙｅｅ開始タグ・トークン（ＥＳ）８１２を取得し、そのトークン８１２を要素妥当性検査モジュール１０１４に入力する。ステップ１２１０で、妥当性検査は成功する。ステップ１２１４で、ｅｍｐｌｏｙｅｅ要素注釈レコード８１６に対する属性リスト８１４は空ではないので、図１１のステップ１１０６に戻り、次のトークンに対してプロセスを繰り返す。
【００４４】
ｓｅｒｎｏ属性名
ステップ１１０６で、汎用ＸＭＬパーサは、次のトークンである、属性名ｓｅｒｎｏ１６０６のためのトークンを取得するためにカレントのスキャナをコールする。ステップ１１０８で、トークンの走査が成功し、ステップ１１１２で、汎用ＸＭＬパーサ１００４はそれが属性トークンであると判定し、ステップ１１１４で、それを語彙素としてＸＭＬスキーマ妥当性検査モジュール１０１２に入力する。次いで、ステップ１１１６で、ＸＭＬスキーマ妥当性検査モジュール１０１２は語彙素タイプを判定する。その語彙素は属性名なので、図１３で示すように、プロセス・ステップ１１２０が実施される。
【００４５】
図１３を参照すると、ステップ１３０１で、ＸＭＬスキーマ妥当性検査モジュール１０１２は、属性妥当性検査モジュール１０１６にカレントの注釈レコードおよびｓｅｒｎｏ属性名を渡す。カレントの注釈レコードは、ｅｍｐｌｏｙｅｅ要素注釈レコード８１６である。ステップ１３０２で、属性妥当性検査モジュール１０１６は、ｓｅｒｎｏ属性名８１７を求めて属性リスト８１４を検索する。ステップ１３０４で、ｓｅｒｎｏ属性名８１７が見つけられる。妥当性検査が成功し、ステップ１３１２で、ＸＭＬスキーマ妥当性検査モジュール１０１２がカレントのスキャナＩＤをｉｎｔｅｇｅｒＴｙｐｅＩＤ（ｉｎｔｅｇｅｒ型ＩＤ）に設定する。次いで、図１１のステップ１１０６に戻り、次のトークンに対してプロセスを繰り返す。ＩｎｔｅｇｅｒＴｙｐｅスキャナ１０１９は、ｓｅｒｎｏ属性名の属性値として整数「１２３４５」を走査する。カレントのスキャナが汎用スキャナにリセットされる。
【００４６】
ｕｓｅｒｉｄ属性名
ステップ１１０６で、汎用ＸＭＬパーサは、次のトークンである、属性名ｕｓｅｒｉｄ１６０８のためのトークンを取得するためにカレントのスキャナをコールする。ステップ１１０８で、トークンの走査が成功し、ステップ１１１２で、汎用ＸＭＬパーサ１００４はそれが属性トークンであると判定し、ステップ１１１４で、それを語彙素としてＸＭＬスキーマ妥当性検査モジュール１０１２に入力する。次いで、ステップ１１１６で、ＸＭＬスキーマ妥当性検査モジュール１０１２は語彙素タイプを判定する。その語彙素は属性名なので、図１３で示すように、プロセス・ステップ１１２０が実施される。
【００４７】
図１３を参照すると、ステップ１３０１で、ＸＭＬスキーマ妥当性検査モジュール１０１２は、属性妥当性検査モジュール１０１６にカレントの注釈レコードおよびｕｓｅｒｉｄ属性名８１９を渡す。カレントの注釈レコードは、ｅｍｐｌｏｙｅｅ要素注釈レコード８１６である。ステップ１３０２で、属性妥当性検査モジュール１０１６は、ｕｓｅｒｉｄ属性名８１９を求めて属性リスト８１４を検索する。ステップ１３０４で、ｕｓｅｒｉｄ属性名８１９が見つけられる。妥当性検査が成功し、ステップ１３１２で、ＸＭＬスキーマ妥当性検査モジュール１０１２がカレントのスキャナＩＤをａｎｙＳｉｍｐｌｅＴｙｐｅＩＤ（任意の単純型ＩＤ）に設定する。次いで、図１１のステップ１１０６に戻り、次のトークンに対してプロセスを繰り返す。ＡｎｙＳｉｍｐｌｅＴｙｐｅスキャナ１０１８は、ｕｓｅｒｉｄ属性名の属性値として「Ａ１ｂｃ７８Ｄ」を走査する。カレントのスキャナが汎用スキャナにリセットされる。
【００４８】
Ｄｅｐａｒｔｍｅｎｔ属性名
ステップ１１０６で、汎用ＸＭＬパーサは、次のトークンである、属性名ｄｅｐａｒｔｍｅｎｔ１６１０のためのトークンを取得するためにカレントのスキャナをコールする。ステップ１１０８で、トークンの走査が成功し、ステップ１１１２で、汎用ＸＭＬパーサ１００４はそれが属性トークンであると判定し、ステップ１１１４で、それを語彙素としてＸＭＬスキーマ妥当性検査モジュール１０１２に入力する。次いで、ステップ１１１６で、ＸＭＬスキーマ妥当性検査モジュール１０１２は語彙素タイプを判定する。その語彙素は属性名なので、図１３で示すように、プロセス・ステップ１１２０が実施される。
【００４９】
図１３を参照すると、ステップ１３０１で、ＸＭＬスキーマ妥当性検査モジュール１０１２は、属性妥当性検査モジュール１０１６にカレントの注釈レコードおよびｄｅｐａｒｔｍｅｎｔ属性名８２１を渡す。カレントの注釈レコードは、ｅｍｐｌｏｙｅｅ要素注釈レコード８１６である。ステップ１３０２で、属性妥当性検査モジュール１０１６は、ｄｅｐａｒｔｍｅｎｔ属性名８２１を求めて属性リスト８１４を検索する。ステップ１３０４で、そのｄｅｐａｒｔｍｅｎｔ属性名８２１が見つけられる。妥当性検査が成功し、ステップ１３１２で、ＸＭＬスキーマ妥当性検査モジュール１０１２がカレントのスキャナＩＤをｓｔｒｉｎｇＴｙｐｅＩＤ（ｓｔｒｉｎｇ型ＩＤ）に設定する。次いで、図１１のステップ１１０６に戻り、次のトークンに対してプロセスを繰り返す。ＳｔｒｉｎｇＴｙｐｅスキャナ１０２０は、ｄｅｐａｒｔｍｅｎｔ属性名の属性値として「ｓａｌｅｓ（営業）」を走査する。カレントのスキャナが汎用スキャナにリセットされる。
【００５０】
Ｌａｓｔｎａｍｅ開始タグ名
ステップ１１０６で、汎用ＸＭＬパーサは、次のトークンである、ｌａｓｔｎａｍｅ開始タグ名１６１２のためのトークンを取得するためにカレントのスキャナをコールする。ステップ１１０８で、トークンの走査が成功し、ステップ１１１２で、汎用ＸＭＬパーサ１００４はそれが要素トークンであると判定し、ステップ１１１４で、それを語彙素としてＸＭＬスキーマ妥当性検査モジュール１０１２に入力する。次いで、ステップ１１１６で、ＸＭＬスキーマ妥当性検査モジュール１０１２は語彙素タイプを判定する。その語彙素は開始タグ名であるので、図１２で示すように、プロセス・ステップ１１１８が実施される。
【００５１】
図１２を参照すると、ステップ１２０２で、ｅｍｐｌｏｙｅｅ要素注釈レコード８１６、すなわち、前の注釈レコードの副要素候補マップ８１５が、ｌａｓｔｎａｍｅ開始タグ名８２３を指しており、それは、ｌａｓｔｎａｍｅ要素注釈レコード８２９、すなわち、カレントの注釈レコードを指し、ステップ１２０６で、スタックに追加される。ここで、スタックの内容は図１７に示すようになる。ステップ１２０８で、ＸＭＬスキーマ妥当性検査モジュール１０１２は、ｌａｓｔｎａｍｅ要素注釈レコード８２９からｌａｓｔｎａｍｅ開始タグ・トークン（ＬＳ）８２５を取得し、そのトークン８２５を要素妥当性検査モジュール１０１４に入力する。ステップ１２１０で、妥当性検査は成功する。ステップ１２１４で、ｌａｓｔｎａｍｅ要素注釈レコード８２９のための属性リスト８２７は空であり、ｌａｓｔｎａｍｅ要素の内容は単純型（ｓｔｒｉｎｇＴｙｐｅＩＤ）なので、ステップ１２１６で、カレントのスキャナＩＤがｓｔｒｉｎｇＴｙｐｅＩＤに変更される。次いで、図１１のステップ１１０６に戻り、次のトークンに対してプロセスを繰り返す。次いで、ＳｔｒｉｎｇＴｙｐｅスキャナ１０２０がコールされて、ｌａｓｔｎａｍｅ要素に対する内容として「ホワイト」が走査される。カレントのスキャナは、汎用スキャナにリセットされる。
【００５２】
Ｌａｓｔｎａｍｅ終了タグ名
ステップ１１０６で、汎用ＸＭＬパーサは、次のトークンである、ｌａｓｔｎａｍｅ終了タグ名１６１４のためのトークンを取得するためにカレントのスキャナをコールする。ステップ１１０８で、トークンの走査が成功し、ステップ１１１２で、汎用ＸＭＬパーサ１００４はそれが要素トークンであると判定し、ステップ１１１４で、それを語彙素としてＸＭＬスキーマ妥当性検査モジュール１０１２に入力する。次いで、ステップ１１１６で、ＸＭＬスキーマ妥当性検査モジュール１０１２は語彙素タイプを判定する。その語彙素は終了タグ名であるので、図１４で示すように、プロセス・ステップ１１２２が実施される。
【００５３】
図１４を参照すると、ステップ１４０２で、ｌａｓｔｎａｍｅ要素注釈レコード８２９、すなわち、カレントの注釈レコードが、スタックから取り出される。ここで、スタックの内容は、図１６に示すようになる。ＸＭＬスキーマ妥当性検査モジュール１０１２は、ｌａｓｔｎａｍｅ要素注釈レコード８２９からｌａｓｔｎａｍｅ終了タグ・トークン（ＬＥ）８２６を取得し、ステップ１４０４で、そのトークン８２６を要素妥当性検査モジュール１０１４に入力する。ステップ１４０６で、妥当性検査は成功する。ステップ１４０８で、ｌａｓｔｎａｍｅ要素注釈レコード８２９のための属性リスト８２７は空なので、図１１のステップ１１０６に戻り、次のトークンに対してプロセスを繰り返す。
【００５４】
Ｆｉｒｓｔｎａｍｅ開始タグ名
ステップ１１０６で、汎用ＸＭＬパーサは、次のトークンである、ｆｉｒｓｔｎａｍｅ開始タグ名１６１６のためのトークンを取得するためにカレントのスキャナをコールする。ステップ１１０８で、トークンの走査が成功し、ステップ１１１２で、汎用ＸＭＬパーサ１００４はそれが要素トークンであると判定し、ステップ１１１４で、それを語彙素としてＸＭＬスキーマ妥当性検査モジュール１０１２に入力する。次いで、ステップ１１１６で、ＸＭＬスキーマ妥当性検査モジュール１０１２は語彙素タイプを判定する。その語彙素は開始タグ名であるので、図１２で示すように、プロセス・ステップ１１１８が実施される。
【００５５】
図１２を参照すると、ステップ１２０２で、ｅｍｐｌｏｙｅｅ要素注釈レコード８１６、すなわち、前の注釈レコードの副要素候補マップ８１５が、ｆｉｒｓｔｎａｍｅ開始タグ名８３０を指しており、それは、ｆｉｒｓｔｎａｍｅ要素注釈レコード８３７、すなわち、カレントの注釈レコードを指し、ステップ１２０６で、スタックに追加される。ここで、スタックの内容は、図１８に示すようになる。ステップ１２０８で、ＸＭＬスキーマ妥当性検査モジュール１０１２は、ｆｉｒｓｔｎａｍｅ要素注釈レコード８３７からｆｉｒｓｔｎａｍｅ開始タグ・トークン（ＦＳ）８３３を取得し、そのトークン８３３を要素妥当性検査モジュール１０１４に入力する。ステップ１２１０で、妥当性検査は成功する。ステップ１２１４で、ｆｉｒｓｔｎａｍｅ要素注釈レコード８３７に対する属性リスト８３５は、空でありｆｉｒｓｔｎａｍｅ要素は単純型（ｓｔｒｉｎｇＴｙｐｅＩＤ）なので、ステップ１２１６で、カレントのスキャナＩＤがｓｔｒｉｎｇＴｙｐｅＩＤに変更される。次いで、図１１のステップ１１０６に戻り、次のトークンに対してプロセスを繰り返す。次いで、ＳｔｒｉｎｇＴｙｐｅスキャナ１０２０がコールされて、ｆｉｒｓｔｎａｍｅ要素に対する内容として「ジョン」が走査される。カレントのスキャナは、汎用スキャナにリセットされる。
【００５６】
Ｆｉｒｓｔｎａｍｅ終了タグ名
ステップ１１０６で、汎用ＸＭＬパーサは、次のトークンである、ｆｉｒｓｔｎａｍｅ終了タグ名１６１８のためのトークンを取得するためにカレントのスキャナをコールする。ステップ１１０８で、トークンの走査が成功し、ステップ１１１２で、汎用ＸＭＬパーサ１００４はそれが要素トークンであると判定し、ステップ１１１４で、それを語彙素としてＸＭＬスキーマ妥当性検査モジュール１０１２に入力する。次いで、ステップ１１１６で、ＸＭＬスキーマ妥当性検査モジュール１０１２は語彙素タイプを判定する。その語彙素は終了タグ名であるので、図１４で示すように、プロセス・ステップ１１２２が実施される。
【００５７】
図１４を参照すると、ステップ１４０２で、ｆｉｒｓｔｎａｍｅ要素注釈レコード８３７、すなわち、カレントの注釈レコードが、スタックから取り出される。ここで、スタックの内容は図１６に示すようになる。ＸＭＬスキーマ妥当性検査モジュール１０１２は、ｆｉｒｓｔｎａｍｅ要素注釈レコード８３７からｆｉｒｓｔｎａｍｅ終了タグ・トークン（ＦＥ）８３４を取得し、ステップ１４０４で、そのトークン８３４を要素妥当性検査モジュール１０１４に入力する。ステップ１４０６で、妥当性検査は成功する。ステップ１４０８で、ｆｉｒｓｔｎａｍｅ要素注釈レコード８３７のための属性リスト８３５は空なので、図１１のステップ１１０６に戻り、次のトークンに対してプロセスを繰り返す。
【００５８】
Ｎｏｔｅｓ開始タグ名
ステップ１１０６で、汎用ＸＭＬパーサは、次のトークンである、ｎｏｔｅｓ開始タグ名１６２０のためのトークンを取得するためにカレントのスキャナをコールする。ステップ１１０８で、トークンの走査が成功し、ステップ１１１２で、汎用ＸＭＬパーサ１００４はそれが要素トークンであると判定し、ステップ１１１４で、それを語彙素としてＸＭＬスキーマ妥当性検査モジュール１０１２に入力する。次いで、ステップ１１１６で、ＸＭＬスキーマ妥当性検査モジュール１０１２は語彙素タイプを判定する。その語彙素は開始タグ名であるので、図１２で示すように、プロセス・ステップ１１１８が実施される。
【００５９】
図１２を参照すると、ステップ１２０２で、ｅｍｐｌｏｙｅｅ要素注釈レコード８１６、すなわち、前の注釈レコードの副要素候補マップ８１５が、ｎｏｔｅｓ開始タグ名８３１を指しており、それは、ｎｏｔｅｓ要素注釈レコード８４３、すなわち、カレントの注釈レコードを指し、ステップ１２０６で、スタックに追加される。ここで、スタックの内容は、図１９に示すようになる。ステップ１２０８で、ＸＭＬスキーマ妥当性検査モジュール１０１２は、ｎｏｔｅｓ要素注釈レコード８４３からｎｏｔｅｓ開始タグ・トークン（ＮＳ）８３９を取得し、そのトークン８３９を要素妥当性検査モジュール１０１４に入力する。ステップ１２１０で、妥当性検査は成功する。ステップ１２１４で、ｎｏｔｅｓ要素注釈レコード８４３のための属性リスト８４１は空であり、ｎｏｔｅｓ要素の内容は単純型（ｓｔｒｉｎｇＴｙｐｅＩＤ）なので、ステップ１２１６で、カレントのスキャナＩＤがｓｔｒｉｎｇＴｙｐｅＩＤに変更される。次いで、図１１のステップ１１０６に戻り、次のトークンに対してプロセスを繰り返す。ＳｔｒｉｎｇＴｙｐｅスキャナ１０２０が、ｎｏｔｅｓ要素に対する内容として「正規（regular）」を走査する。カレントのスキャナは、汎用スキャナにリセットされる。
【００６０】
Ｎｏｔｅｓ終了タグ名
ステップ１１０６で、汎用ＸＭＬパーサは、次のトークンである、ｎｏｔｅｓ終了タグ名１６２２のためのトークンを取得するためにカレントのスキャナをコールする。ステップ１１０８で、トークンの走査が成功し、ステップ１１１２で、汎用ＸＭＬパーサ１００４はそれが要素トークンであると判定し、ステップ１１１４で、それを語彙素としてＸＭＬスキーマ妥当性検査モジュール１０１２に入力する。次いで、ステップ１１１６で、ＸＭＬスキーマ妥当性検査モジュール１０１２は語彙素タイプを判定する。その語彙素は終了タグ名であるので、図１４で示すように、プロセス・ステップ１１２２が実施される。
【００６１】
図１４を参照すると、ステップ１４０２で、ｎｏｔｅｓ要素注釈レコード８４３、すなわち、カレントの注釈レコードが、スタックから取り出される。ここで、スタックの内容は図１６に示すようになる。ＸＭＬスキーマ妥当性検査モジュール１０１２は、ｎｏｔｅｓ要素注釈レコード８４３からｎｏｔｅｓ終了タグ・トークン（ＮＥ）８４０を取得し、ステップ１４０４で、そのトークン８４０を要素妥当性検査モジュール１０１４に入力する。ステップ１４０６で、妥当性検査は成功する。ステップ１４０８で、ｎｏｔｅｓ要素注釈レコード８４３のための属性リスト８４１は空なので、図１１のステップ１１０６に戻り、次のトークンに対してプロセスを繰り返す。
【００６２】
Ｅｍｐｌｏｙｅｅ終了タグ名
ステップ１１０６で、汎用ＸＭＬパーサは、次のトークンである、ｅｍｐｌｏｙｅｅ終了タグ名１６２４のためのトークンを取得するためにカレントのスキャナをコールする。ステップ１１０８で、トークンの走査が成功し、ステップ１１１２で、汎用ＸＭＬパーサ１００４はそれが要素トークンであると判定し、ステップ１１１４で、それを語彙素としてＸＭＬスキーマ妥当性検査モジュール１０１２に入力する。次いで、ステップ１１１６で、ＸＭＬスキーマ妥当性検査モジュール１０１２は語彙素タイプを判定する。その語彙素は終了タグ名であるので、図１４で示すように、プロセス・ステップ１１２２が実施される。
【００６３】
図１４を参照すると、ステップ１４０２で、ｅｍｐｌｏｙｅｅ要素注釈レコード８１６、すなわち、カレントの注釈レコードが、スタックから取り出される。ここで、スタックの内容は図１５に示すようになる。ＸＭＬスキーマ妥当性検査モジュール１０１２は、ｅｍｐｌｏｙｅｅ要素注釈レコード８１６からｅｍｐｌｏｙｅｅ終了タグ・トークン（ＥＥ）８１３を取得し、ステップ１４０４で、そのトークン８１３を要素妥当性検査モジュール１０１４に入力する。ステップ１４０６で、妥当性検査は成功する。ステップ１４０８で、ｅｍｐｌｏｙｅｅ要素注釈レコード８１６のための属性リスト８１７、８１９、および８２１はすべて、妥当性が検査されているので、図１１のステップ１１０６に戻り、次のトークンに対してプロセスを繰り返す。
【００６４】
同様な妥当性検査プロセスが、例示的なＸＭＬ文書１６００におけるｐｅｒｓｏｎｎｅｌ要素の下位にある残りのｅｍｐｌｏｙｅｅ要素に対して実施される。
【００６５】
Ｐｅｒｓｏｎｎｅｌ終了タグ名
ステップ１１０６で、汎用ＸＭＬパーサは、次のトークンである、ｐｅｒｓｏｎｎｅｌ終了タグ名１６２６のためのトークンを取得するためにカレントのスキャナをコールする。ステップ１１０８で、トークンの走査が成功し、ステップ１１１２で、汎用ＸＭＬパーサ１００４はそれが要素トークンであると判定し、ステップ１１１４で、それを語彙素としてＸＭＬスキーマ妥当性検査モジュール１０１２に入力する。次いで、ステップ１１１６で、ＸＭＬスキーマ妥当性検査モジュール１０１２は語彙素タイプを判定する。その語彙素は終了タグ名であるので、図１４で示すように、プロセス・ステップ１１２２が実施される。
【００６６】
図１４を参照すると、ステップ１４０２で、ｐｅｒｓｏｎｎｅｌ要素注釈レコード８０９、すなわち、カレントの注釈レコードが、スタックから取り出される。ＸＭＬスキーマ妥当性検査モジュール１０１２は、ｐｅｒｓｏｎｎｅｌ要素注釈レコード８０９からｐｅｒｓｏｎｎｅｌ終了タグ・トークン（ＰＥ）８０６を取得し、ステップ１４０４で、そのトークン８０６を要素妥当性検査モジュール１０１４に入力する。ステップ１４０６で、妥当性検査は成功する。ステップ１４０８で、ｐｅｒｓｏｎｎｅｌ要素注釈レコード８０９のための属性リスト８０７は空なので、図１１のステップ１１０６に戻り、次のトークンに対してプロセスを繰り返す。次いでＥＯＦトークンが返される。ステップ１１２５で、汎用ＸＭＬパーサ１００４と要素モジュール１０１４は共に「受入れ」モードにあるので、プロセスはＸＭＬ文書１６００の妥当性検査を完了する。したがって、ステップ１１２６で、「有効」が返される。
【００６７】
拡張機能
簡単なＸＭＬスキーマ定義を用いて好ましい実施形態を説明してきたが、本発明はさらに、いくつかの拡張機能をサポートすることができる。例えば、派生型を有する要素、抽象型または抽象要素あるいはその両方、および代替グループの宣言をサポートすることができる。
【００６８】
型の派生により、基本型を用いて新しい型を定義することができる。ある要素が派生型を有する型であると宣言するとき、その宣言は基本型を参照するだけであり、その基本型は抽象であり得る。ある要素を派生型の型であると宣言した場合、ＸＭＬインスタンス中でどの抽象型の派生型が使用されているかを決定するためには、ｘｓｉ：ｔｙｐｅ属性を使用する必要がある。言い換えると、要素のデータ型を単に要素の名前によって決めることができない。しかし、どの要素がその抽象型で宣言されているかは、ＸＭＬスキーマ定義がコンパイルされるときに分る。したがって、その情報は、抽象型フィールドによりグローバルおよびローカル要素マップにエンコードされる。ランタイム妥当性検査エンジン１０４が、ある要素が抽象型を用いて宣言されていることを実行時に見つけた場合、ｘｓｉ：ｔｙｐｅが見つかるまでその要素の属性の妥当性検査は延期される。
【００６９】
例えば、図２１は、ＸＭＬスキーマ定義に対する例示的な派生型定義の一部分を示す。この実施例では、ｅｍｐｌｏｙｅｅ要素に対して１つの型ではなく、ｅｍｐｌｏｙｅｅＴｙｐｅ（従業員型）、ｒｅｇｕｌａｒＥｍｐｌｏｙｅｅ（正規従業員）、ｔｅｍｐＥｍｐｌｏｙｅｅ（臨時従業員）の３つの型が定義される。ｅｍｐｌｏｙｅｅ要素の宣言は、基本型「ｅｍｐｌｏｙｅｅＴｙｐｅ」を参照する。
【００７０】
本発明によるＸＭＬスキーマ妥当性検査における派生型をサポートするために、ＸＭＬスキーマ・コンパイル１０２は、ＣＦＧにおけるｅｍｐｌｏｙｅｅ要素に対して、ＯＲ（「｜」）を以下のように使用する。
【００７１】
ｅｍｐｌｏｙｅｅ：    ｅｍｐｌｏｙｅｅＴｙｐｅ
｜  ｒｅｇｕｌａｒＥｍｐｌｏｙｅｅ
｜  ｔｅｍｐＥｍｐｌｏｙｅｅ
【００７２】
ｒｅｇｕｌａｒＥｍｐｌｏｙｅｅとｔｅｍｐＥｍｐｌｏｙｅｅの両方に対するＢＮＦは、それらが含むすべての要素を含めるように拡張される。例えば、ｒｅｇｕｌａｒＥｍｐｌｏｙｅｅは４つの要素、すなわち、ｌａｓｔｎａｍｅ、ｆｉｒｓｔｎａｍｅ、ｎｏｔｅｓ、およびｓａｌａｒｙ（給料）をすべて含むように拡張される。ＸＭＬスキーマ勧告によるＸＭＬスキーマに対する制限によると、あるＸＭＬスキーマに対して得られたＣＦＧが規則通りであるために、その先読み（look ahead）を必要としてはならない。このことは、得られたＣＦＧはＳＬＲまたはＬＡＬＲ（１）パーサ生成装置の能力範囲内にあるべきであって、さもなければＸＭＬスキーマ定義はエラーとなることを意味する。スキーマ・コンパイルの残りの部分についても同様である。
【００７３】
ランタイム妥当性検査エンジン１０４の場合、ｅｍｐｌｏｙｅｅ要素の妥当性検査は、２つの代替的な方法で達成することもできる。最初の方法では、後戻り（backtracking）機構が使用される。ランタイム妥当性検査エンジン１０４が、任意の派生型であり得る要素と出会ったとき、ｘｓｉ：ｔｙｐｅ属性に対する開始タグを走査する。それは、属性値に基づいて、ランタイム・スキーマ妥当性検査パーサ１００６のために対応する語彙素を生成する。次いで、それは、タグ名の後に、開始タグを再度走査することになる。例えば、以下の開始タグに出会った場合、
【００７４】
＜ｅｍｐｌｏｙｅｅ  ｘｓｉ：ｔｙｐｅ＝“ｒｅｇｕｌａｒＥｍｐｌｏｙｅｅ”＞
ｒｅｇｕｌａｒＥｍｐｌｏｙｅｅ語彙素は、高レベルの妥当性検査パーサに渡される。
【００７５】
第２の方法では、汎用ＸＭＬパーサ１００４が開始タグ全体をまとめて処理し、妥当性検査パーサ１００６がその内容の妥当性を検査する。汎用ＸＭＬパーサ１００４は、ｘｓｉ：ｔｙｐｅ属性の値を知っており、ランタイム・スキーマ妥当性検査パーサ１００６に対する正しいトークンを生成する。次いで、ランタイム・スキーマ妥当性検査パーサ１００６は、全体の開始タグの妥当性を検査する。
【００７６】
抽象要素および要素の代替グループの場合、同様な機構をＸＭＬスキーマ・コンパイル１０２によるスキーマ・コンパイルで適用することができる。しかし、抽象型を用いる場合と異なり、要素の型は、その要素名から知ることができる。したがって、ｘｓｉ：ｔｙｐｅ属性のために走査する必要はない。
【００７７】
本発明は、ＸＭＬスキーマに関連して述べてきているが、妥当性検査プロセスはまた、本発明の趣旨および範囲を逸脱することなく、スキーマを利用する他のタグ付きまたはマークアップあるいはその両方の言語を用いて使用可能であることが当業者なら理解されよう。
【００７８】
結論
ＸＭＬスキーマ妥当性検査のための改善された方法およびシステムが開示されている。本方法およびシステムは、ＸＭＬスキーマ定義を注釈付きオートマトン・エンコーディング（ＡＡＥ）フォーマットにコンパイルし、それを、ディスクまたはデータベースに記憶する。各ＸＭＬスキーマ定義は、ＡＡＥフォーマットに１度だけコンパイルされる。ＸＭＬ文書の妥当性が検査されるとき、ＸＭＬ文書およびＡＡＥフォーマットの適切なＸＭＬスキーマ定義がランタイム妥当性検査エンジンにロードされる。ランタイム妥当性検査エンジンは、汎用ＸＭＬパーサおよびランタイム・スキーマ妥当性検査パーサを含む。ランタイム妥当性検査エンジンに対するコードは固定され、ＸＭＬスキーマ定義に応じて変わることはない。汎用ＸＭＬパーサが低レベルの妥当性検査を実施し、一方、ランタイム・スキーマ妥当性検査パーサがＡＡＥフォーマットのＸＭＬスキーマ定義に対してＸＭＬ文書の高レベルの妥当性検査を行う。ランタイム妥当性検査エンジンの出力は、妥当性検査の合格または不合格である。
【００７９】
ＡＡＥフォーマットのＸＭＬスキーマ定義は、ＸＭＬ文書が妥当性検査されるごとにコンパイルされるのではなく、１度だけコンパイルされ記憶されるため、妥当性検査プロセスを実施するのに多くの時間が節約される。さらに、ＸＭＬスキーマ定義ごとに変わるのではなく、ランタイム妥当性検査エンジンのコードが固定されるため、多数のＸＭＬスキーマ定義がある場合であっても、スペースのオーバーヘッドが最小化される。また、妥当性検査プロセスにおける柔軟性が性能を損なうことなく提供される。
【００８０】
示した諸実施形態により本発明を説明しているが、当業者であれば、その実施形態に対して変形形態があり得ること、およびその変形形態が本発明の趣旨および範囲内にあることが容易に理解されよう。したがって、添付の特許請求の範囲の趣旨および範囲を逸脱せずに、当業者により多くの変更を加えることができる。
【図面の簡単な説明】
【００８１】
【図１】本発明によるＸＭＬスキーマ妥当性検査システムの好ましい一実施形態を示す図である。
【図２】本発明によるＸＭＬスキーマのコンパイルをより詳細に示す図である。
【図３】本発明によるＸＭＬスキーマのコンパイル・プロセスの好ましい一実施形態を示す流れ図である。
【図４】例示的なＸＭＬスキーマ定義を示す図である。
【図５】本発明による注釈付きツリーで表された、例示的なＸＭＬスキーマ定義に対する要素構造階層を示す図である。
【図６】本発明による、文脈自由文法による例示的なＸＭＬスキーマ定義の構造を示す図である。
【図７】本発明による開始タグ・トークンおよび終了タグ・トークンを有する図６の文脈自由文法の拡張を示す図である。
【図８】本発明による例示的なＸＭＬスキーマ定義に対する注釈付きオートマトン・エンコーディングの注釈部分を示す図である。
【図９】本発明による例示的なＸＭＬスキーマ定義に対するオートマトン・エンコーディング・テーブルのための状態遷移グラフを示す図である。
【図１０】本発明によるランタイム妥当性検査エンジンをより詳細に示す図である。
【図１１】本発明によるランタイム妥当性検査エンジンによって実施されるランタイム妥当性検査プロセスの好ましい実施形態を示す流れ図である。
【図１２】本発明による開始タグ名の処理を示す流れ図である。
【図１３】本発明による属性名の処理を示す流れ図である。
【図１４】本発明による終了タグ名の処理を示す流れ図である。
【図１５】本発明によるランタイム妥当性検査エンジンによって実施されるランタイム妥当性検査プロセス中のスタックの内容を示す図である。
【図１６】本発明によるランタイム妥当性検査エンジンによって実施されるランタイム妥当性検査プロセス中のスタックの内容を示す図である。
【図１７】本発明によるランタイム妥当性検査エンジンによって実施されるランタイム妥当性検査プロセス中のスタックの内容を示す図である。
【図１８】本発明によるランタイム妥当性検査エンジンによって実施されるランタイム妥当性検査プロセス中のスタックの内容を示す図である。
【図１９】本発明によるランタイム妥当性検査エンジンによって実施されるランタイム妥当性検査プロセス中のスタックの内容を示す図である。
【図２０】妥当性が検査される例示的なＸＭＬ文書を示す図である。
【図２１】ＸＭＬスキーマ定義に対する派生型の一実施例を示す図である。
【図１】
0004487290.tif 000002
【図２】
0004487290.tif 000003
【図３】
0004487290.tif 000004
【図４】
0004487290.tif 000005
【図５】
0004487290.tif 000006
【図６】
0004487290.tif 000007
【図７】
0004487290.tif 000008
【図８】
0004487290.tif 000009
【図９】
0004487290.tif 000010
【図１０】
0004487290.tif 000011
【図１１】
0004487290.tif 000012
【図１２】
0004487290.tif 000013
【図１３】
0004487290.tif 000014
【図１４】
0004487290.tif 000015
【図１５】
0004487290.tif 000016
【図１６】
0004487290.tif 000017
【図１７】
0004487290.tif 000018
【図１８】
0004487290.tif 000019
【図１９】
0004487290.tif 000020
【図２０】
0004487290.tif 000021
【図２１】
0004487290.tif 000022