JP2007510204A - 高性能な構造化データ変換用のハードウェア／ソフトウェア・パーティション - Google Patents

Abstract

本願が提供する装置は、例えば、コンピュータでアクセス可能な媒体であって、その媒体は、実行されるとスタイルシートを１つ以上のデータ構造にコンパイルする複数の命令でコード化される、コンピュータでアクセス可能な媒体と、データ構造および文書を受信するために連結されたハードウェア回路と、を備える装置である。そのハードウェア回路は、そのデータ構造を使用してスタイルシートに指定されたように文書の少なくとも一部分を変換するように構成される。

Description

本発明は、拡張マークアップ言語（ＸＭＬ）、標準汎用マークアップ言語（ＳＧＭＬ）、ハイパーテキストマークアップ言語（ＨＴＭＬ）のような構造化文書、ならびにデータベースおよび／またはファイルシステム内の非構造化データおよび文書を処理および変換する分野に関連する。

コンピュータおよびコンピュータストレージが遍在化するにしたがい、多様な組織によって維持される情報量が急激に増加している。しばしば情報は、ワードプロセッサ文書、表計算ファイル、データベース、ポータブルドキュメントフォーマット（ＰＤＦ）文書、画像文書（例、さまざまなグラフィック表示フォーマットにスキャンしたもの）、プレーンテキスト等の多くの異なる形式で保存される。さらに、文書はＳＧＭＬ、ＨＴＭＬ、ＸＭＬ等のマークアップ言語の形で保存することが可能である。

あまりにも多くの異なる形式で情報を所有することは、組織の外部のみならず、組織内での情報の共有を複雑にする。最近では、文書の内容の説明や非構造化データおよび／または文書へ構造を提供するために、ＸＭＬが標準として浮上してきている。ＸＭＬは、文書のマークアップを定義する、柔軟で拡張可能な機構を提供し、説明される情報に対するマークアップのカスタマイズを可能にする。

ＸＭＬを処理するための手段として実施される１つの機構は、拡張スタイルシート言語（ＸＳＬ）およびＸＳＬを使用して作成されたスタイルシートである。スタイルシートは、ＸＭＬ文書をＸＭＬ内で定義される１つのマークアップ定義（または「語彙」）から別の語彙へ、ＸＭＬマークアップから、別の構造化文書または非構造化文書形式（プレーンテキスト、ワードプロセッサ、表計算ソフト、データベース、ｐｄｆ、ＨＴＭＬ等）へ、または別の構造化文書あるいは非構造化文書形式からＸＭＬマークアップへ、変換するように作成することが可能である。したがって、スタイルシートは、文書構造を保存した形式から所与のユーザーが希望する形式へ変換することによって、（多くの異なる形式の）組織の情報へのアクセスを簡素化することが可能である。また、他の種類のスタイルシート（例、拡張機能としてＨＴＭＬに定義されるカスケーディングスタイルシート、すなわち、ＣＳＳ）も存在する。

一般的に、文書変換処理は、汎用コンピュータ（例、文書保存、ユーザー機等を管理するサーバー）上で実行するソフトウェアにおいて行われる。そのような書類へのアクセスの著しい滞りが発生している。

一実施形態において、実行されるとスタイルシートを１つ以上のデータ構造にコンパイルする複数の命令でコード化される、コンピュータアクセス可能媒体と、データ構造および文書を受信するように結合されたハードウェア回路とを備える装置を提供する。ハードウェア回路は、データ構造を使用してスタイルシートに指定されるように、文書の少なくとも一部を変換するように構成される。

以下の詳細な説明では、図面の簡単な説明において簡単に説明される添付の図面を参照する。

本発明に対しては、さまざまな変更および代替形態が可能であるが、その具体的な実施形態を図面中に一例として示し、本願明細書において詳述するものである。しかし、図面およびその詳細な説明は、この発明を開示される特定の形態に限定することを意図するのではなく、逆に、添付の請求請求の範囲により規定される本発明の範囲および精神の範囲内にある全ての変更、均等物および代替案をカバーすることを意図すると理解されたい。

図１は、内容変換装置１０の一実施形態のブロック図を示す。図１の実施形態において、内容変換装置１０は、ネットワークインターフェース回路１２と、プロセッサ１４Ａおよび選択的に１４Ｂのような１つ以上のプロセッサと、文書プロセッサ１６と、メモリ１８とを含むことが可能である。ネットワークインターフェース回路１２は、１つ以上のネットワーク接続を介して、１つまたは複数のネットワークへ結合される。さまざまなコンピュータシステム（図１には示さず）を、前記の１つまたは複数のネットワークに結合することも可能である。ネットワークインターフェース回路１２は、プロセッサ１４Ａおよび１４Ｂにも結合される。これらのプロセッサはメモリ１８および文書プロセッサ１６に結合され、文書プロセッサ１６はメモリ１８にも結合される。図示の実施形態において、メモリ１８は、スタイルシートコンパイラ２０、スキーマコンパイラ２２、１つ以上の記号表２４、１つ以上の解析時間の式ツリー２６、命令表３０、余白表３２、文書型定義（ＤＴＤ）表３４、式リスト表３６、テンプレートリスト表３８、および各種の文書プロセッサデータ構造３９を保存する。

内容変換装置１０は、ネットワーク接続を介して、文書に適用するスタイルシート、文書に適用するスキーマ、および／または（スタイルシート／スキーマの文書への適用の要求と共に）書類自体を受信することができる。スタイルシートを適用する要求に応答して、内容変換装置１０は、スタイルシートを文書に適用して変換済み文書を生成し、それをネットワークを通じて要求元に発信することが可能である。いくつかの実施形態において、内容変換装置１０は、要求を受信して、（例、ＸＭＬ（ＳＡＸ）または文書オブジェクトモデル（ＤＯＭ）用の単純なアプリケーションプログラミングインタフェース（ＡＰＩ）のような定義されたフォーマットに）文書を解析することも可能である。スキーマ（またはＤＴＤ）の適用の要求に応答して、内容変換装置１０は、スキーマまたはＤＴＤに従って文書を認証し、要求元への成功メッセージまたは（失敗の表示を伴う）失敗メッセージを生成することが可能である。

いくつかの実施形態において、内容変換装置１０は、ＸＰａｔｈ式を受信し、ＸＭＬデータベースへのアクセスに使用することができる。そのような実施形態において、前記式は（下記に詳述する）スタイルシートと同様にコンパイルすることが可能であり、スタイルシートを文書に適用するのと同様な様式でＸＭＬデータベースに適用することが可能である。

概して、ＸＭＬ文書は階層ツリー構造を持ち、その構造において、そのツリーのルートは文書全体を識別し、文書内の他のノードのそれぞれはルートの子孫の関係になる。さまざまな要素、属性および文書内容がツリーのノードを形成する。前記要素は、その要素が含む内容の構造を定義する。各要素は要素名を持ち、その要素は、それぞれが要素名を含む開始タグおよび終了タグを使用して内容の範囲を定める。要素はサブ要素として他の要素を持つことが可能であり、それが内容の構造をさらに定義することが可能である。加えて、要素は属性を含むことが可能であり（要素名に続いて、開始タグに含まれる）、その属性は、要素または要素の内容の構造についてさらなる情報を提供する名前／値ペアである。ＸＭＬ文書は、ＸＭＬ文書、コメント等を読み込んでアプリケーションへ渡される処理命令を含むことも可能である。ここで使用されている「文書」という用語は、内容を解釈するために使用することのできる、対応する定義済みの構造を有するあらゆる内容を指す。前記内容は、（ＸＭＬ文書、ＨＴＭＬ文書、ｐｄｆ文書、ワード処理文書、データベース等のように）高度に構造化してもよいし、またはプレーンテキスト文書のような単純なものでもよい（その構造は、例えば一連の文字であってもよい）。概して、文書の「ノード」は、構造定義（例、ＸＭＬの要素および／または属性）、および／または文書内容を含むことが可能である。ある特定の実施形態において、ノードは、要素、属性、処理命令、コメントおよびテキストを含むことが可能である。

ＸＳＬＴスタイルシートは、テンプレートのセットと考えることが可能である。各テンプレートには：（ｉ）ソース文書のツリー構造のノードを選択する式と、（ｉｉ）ソース文書の各一致するノードに対してインスタンス化される、出力文書の構造の対応する部分を特定する本体とを含むことが可能である。スタイルシートのソース文書への適用は、ソース文書の各ノードに一致するテンプレートを探す試み、および、出力文書のツリーにいて、一致するテンプレートの本体をインスタンス化すること、を含む場合がある。テンプレートの本体には、１つ以上の：（ｉ）出力文書においてインスタンス化されるリテラル内容と、（ｉｉ）出力文書にコピーされる一致するノードからの内容の選択と、および（ｉｉｉ）出力文書においてインスタンス化されるステートメントの結果と共に、評価されるステートメントと、を含むことが可能である。同時に、インスタンス化される内容および評価されるステートメントは、テンプレートと一致するノード上で行われる「アクション」と称することが可能である。テンプレートの本体には１つ以上の「テンプレート適用」ステートメントを含むことができ、それらは、１つ以上のノードを選択してスタイルシートのテンプレートを選択したノードに適用させる式を含む。よって、テンプレートは効果的にネストされる。テンプレート適用ステートメントへの一致が見つかった場合、その結果のテンプレートは、テンプレート適用ステートメントを含むテンプレートのインスタンス化の範囲内でインスタンス化される。テンプレートの本体の他のステートメントは、ノードに対して一致する式も含むことが可能である（そして、ステートメントは、一致するノード上で評価することが可能である）。ＸＳＬＴスタイルシートは、本願明細書において一実施例として用いることが可能であるが、一般的に、「スタイルシート」は、ソース文書を出力文書に変換するためのあらゆる仕様を含むことが可能である。ソース文書および出力文書は同じ言語であってもよいし（例、ソース文書および出力文書は異なるＸＭＬ語彙であってよい）、または異なって（例、ＸＭＬからｐｄｆ等）いてもよい。スタイルシートの別の例は、ＨＴＭＬおよび／またはＸＭＬ Ｑｕｅｒｙのために定義されたカスケーディングスタイルシートであってもよい。

スタイルシートで使用される式は、概して、ノード識別子および／またはノード値の間の親／子（または祖先／子孫）関係を指定するノード識別子上の演算子と共に、ノード識別子および／またはノード値を含むことが可能である。ノード識別子は、名前（例、要素名、属性名等）を含んでもよいし、またはノードを種類によって識別する式構造を含んでもよい（例、ノードテスト式が任意のノードと一致することが可能であるか、またはテキストテスト式が任意のテキストノードと一致することが可能である）。場合によっては、名前は特定の名前空間に属することができる。そのような場合、ノード識別子は名前空間に関連する名前でもよい。ＸＭＬでは、名前空間は、ユニバーサルリソース識別子（ＵＲＩ）によって識別される名前空間名と関連付けることによって、要素名および属性名を修飾する方法を提供する。したがって、ノード識別子は修飾名であってもよい（任意の名前空間接頭辞、その後にコロン、その後にその名前が続く）。本願明細書において使用される場合の名前（例、要素名、属性名等）は、修飾名を含むことが可能である。式はまた述語を含むことが可能であり、それは、ノードを一致させるための１つまたは複数の追加の条件である。述語は、コンテキストノード（以下に定義）として関連ノードによって評価される式であり、その式の結果は真（ノードが式ノードに一致する）または偽（および、ノードが式ノードと一致しない）のいずれかである。したがって、式は文書ツリーに対して一致するノードツリーとして考えることができる。ＸＳＬＴで使用される式言語であるＸＰａｔｈでは、式は、「コンテキストノード」のコンテキストに対しても評価されることが可能である（すなわち、式はコンテキストノードに相対的であることが可能で、他のノード識別子との関係だけでなく、式の中のノード識別子を、コンテキストノードの祖先、子孫、親、子として特定する）。所与の文書ノードは、その所与の文書ノードが式の評価を介して選択されれば、式を満たすことが可能である。すなわち、式の中の式ノード識別子が、所与の文書ノード名と、または、その式に指定された文書ノードとの関係と同一の所与の文書ノードとの関係を有する文書ノード名と、一致し、その式の中で使用される任意の値は、その所与の文書名に関連する、対応する値に等しい。文書ノードは、そのノードが所与の式を満たす場合、所与の式のための「一致するノード」とも呼ぶことが可能である。場合によっては、本説明の残部において、式ツリー内のノードと文書内のノードとの区別を明確にし易くすることが可能である。したがって、ノードが式ツリーの一部である場合、そのノードを「式ノード」と称することが可能であり、ノードが処理中の文書の一部である場合、そのノードを「文書ノード」と称することが可能である。

図示した実施形態において、スタイルシートの文書への適用は、以下の様式において行うことができる。スタイルシートコンパイラ２０は、プロセッサ１４Ａおよび１４Ｂのうちの１つで実行するソフトウェア（すなわち、複数の命令）を含むことが可能であり、文書プロセッサ１６で使用するために、スタイルシートを１つ以上のデータ構造およびコードにコンパイルする。文書プロセッサ１６はそのデータ構造をソース文書に適用し、出力文書を生成することが可能である。

特に、一実施形態では、スタイルシートコンパイラ２０は、（文字列比較を伴うことになる）ノード識別子よりもむしろ数字を比較することで文書プロセッサが式評価を行えるように、シリアル番号をノード識別子に割り当てることが可能である。スタイルシートコンパイラ２０は、シリアル番号に対するノード識別子のマッピングを記号表２４に保存することが可能である。加えて、スタイルシートコンパイラ２０は、スタイルシートから式を抽出し、文書プロセッサが式を一致させるために使用する式ツリーのデータ構造を生成することが可能である（例、解析時間の式ツリー２６）。さらに、スタイルシートコンパイラ２０は、一致する式のそれぞれに実行する命令（また一実施形態において、ランタイム述語の評価を実行する命令）の命令表３０を生成することが可能である。その命令表内の命令は、文書プロセッサ１６によって実行されると、式が一致した場合に実行するように定義されているアクションを実行させることが可能である。いくつかの実施形態において、命令は実行するアクションを含むことが可能である（つまり、命令とアクションの間は一対一対応とすることが可能である）。他の実施形態において、少なくともいくつかのアクションは、２つ以上の命令を実行することによって実現することができる。スタイルシートコンパイラ２０は、ソース文書内でどのように種類の余白を取り扱うのか（例、保存した、取り除いた、等）を定義する余白表３２、式リスト表３６、およびテンプレートリスト表３８を生成することも可能である。

スキーマコンパイラ２２も同様に、プロセッサ１４Ａおよび１４Ｂのうちの１つで実行される命令を含むことが可能である。スキーマコンパイラ２２は、ＤＴＤ表３４とともに、１つ以上の記号表２４（ノード識別子をシリアル番号に置き換える）を生成するためのスキーマまたはＤＴＤをコンパイルすることができる。概して、ＤＴＤまたはスキーマは、許容される文書構造および要求される文書構造の両方の定義を含むことが可能である。したがって、文書の著者は、ＤＴＤおよび／またはスキーマを使用して、有効な文書の要求されるおよび許容される構造を記述することが可能である。場合によっては、そのＤＴＤまたはスキーマが属性のデフォルト値も含んでもよい。一実施形態において、ＤＴＤ／スキーマは、文書内の実体参照を置き換えるために使用される実体宣言、有効な文書に必要な属性である所与の要素の属性、その文書の所与の要素で特定されない場合がある属性の属性デフォルト値、文書の構造の要件（例、特定のサブ要素等の必要最大／最小／特定数）、およびその文書の許容される構造の定義、などのさまざまな情報を含むことが可能である。ＤＴＤ表３４は、実体参照の置換表、必要とされる属性の表、属性デフォルト表、許容される構造を識別するスケルトンツリー（および、該当する場合は、要求される構造）を含むことが可能である。

文書プロセッサ１６は文書を解析し、解析時間の式ツリー内の式ノードに文書ノードを一致させるハードウェア回路構成を含むことが可能である。すなわち、文書を解析し、式ノードに文書ノードを一致させるハードウェア回路構成は、これらの演算をいずれのソフトウェアの命令を実行せずに行うことが可能である。そのハードウェアは、一致する文書ノードの各式に対する解析した内容および表示を保存しているさまざまなデータ構造を生成することが可能である。そのハードウェアは、次いで、命令表３０からの命令を、所与の式の各一致する文書ノード上の所与の式に実行して結果を生成し、それらを組み合わせて出力文書を作成することが可能である。一実施形態の更なる詳細を以下に示す。

上述のように、図示した実施形態において、スタイルシートコンパイラ２０およびスキーマコンパイラ２２はソフトウェアにおいて実施されており、文書プロセッサ１６は、ハードェアにおいて実施されている。いくつかの実施形態において、内容変換装置１０の遂行の極めて重要な要因は、変換要求が起こされ、文書が提供される時の文書の処理であり得る。すなわち、スタイルシートおよび／またはスキーマは、多くの場合、処理される文書の数に比べて、比較的まれにしか変更しない場合がある。所与のスタイルシートは、スタイルシートが（更新したスタイルシートまたは全く異なるスタイルシートへ）変更される前に、複数の文書（例、少なくとも約数十の文書）に適用することが可能である。スキーマおよびそれらが適用される文書も同様な関係を保つことが可能である。したがって、比較的不変である情報をスタイルシート／スキーマから（ソフトウェアを使用して）、専用のカスタムハードウェアが効率よくアクセスできるデータ構造に取り込むことによって、高性能なソリューションを提供することが可能である。加えて、ハードウェアがスタイルシート／スキーマのコンパイルを有することにより、いくつかの実施形態において、異なるスタイルシート／スキーマ言語の実施に対する柔軟性、および／またはカスタムハードウェアを変更する必要もなく、言語仕様に変更を施すための柔軟性を提供することが可能である。例えば、ＸＳＬＴ、ＸＰａｔｈ、およびＸＭＬスキーマはさらに発展させることが可能であり、これらの言語には将来新しい機能が追加される可能性がある。そのコンパイラは、これらの新しい機能に対処するように構成されることが可能である。使用されるスタイルシート／スキーマを事前に提供することが可能であり、したがって、スタイルシート／スキーマをコンパイルする時間はそれほど重要でなくなる可能性がある。しかし、他の実施形態では、スタイルシートコンパイラ２０およびスキーマコンパイラ２２の一方またはそれらの両方を、ハードウェアにおいて、またはハードウェアとソフトウェアを組み合わせたものにおいて、実施することが可能である。

ネットワークインターフェース回路１２は、ネットワーク接続上の低レベルの電気的詳細およびプロトコル詳細に対応し、受信したパケットを処理するためにプロセッサ１４Ａおよび１４Ｂに渡すことが可能である。あらゆる種類のネットワークを使用することが可能である。例えば、いくつかの実施形態において、前記ネットワーク接続は、Ｇｉｇａｂｉｔ Ｅｔｈｅｒｎｅｔ（登録商標）接続であってもよい。必要に応じて、複数の接続を提供して、所与のレベルの帯域幅を達成すること、および／またはネットワーク接続に冗長性を提供することができる。

プロセッサ１４Ａおよび１４Ｂは、あらゆる種類のプロセッサを含むことが可能である。例えば、一実施形態において、プロセッサ１４Ａおよび１４Ｂは、ＰｏｗｅｒＰＣネットワークプロセッサであってもよい。他の実施形態において、プロセッサ１４Ａおよび１４Ｂは、ＡＲＭ、Ｉｎｔｅｌ社のＩＡ−３２、ＭＩＰＳ等の、他の命令セットアーキテクチャを実施することが可能である。

プロセッサ１４Ａおよび１４Ｂ、文書プロセッサ１６、およびメモリ１８への結合には、あらゆる相互接続を使用することが可能である。さらに、プロセッサ１４Ａおよび１４Ｂは、メモリ１８へのプロセッサ１４Ａおよび１４Ｂならびに文書プロセッサ１６の接続とは別に、文書プロセッサ１６に結合することが可能である。例えば、一つの実施形態において、プロセッサ１４Ａおよび１４Ｂは、１つ以上の周辺構成要素相互接続（ＰＣＩ−Ｘ）バスを使用して、文書プロセッサ１６に結合することが可能である。

場合によっては、ＤＴＤ、スキーマ、またはスタイルシートを（直接、あるいはスキーマまたはスタイルシートに対するポインタとして）文書に埋め込むことが可能であることに留意されたい。そのような場合、ＤＴＤ、スキーマ、またはスタイルシートを文書から取り出して、説明したように、別途提供されたスキーマまたはスタイルシートとして処理する。

メモリ１８は、あらゆる種類の揮発性または不揮発性メモリで構成することが可能である。例えば、メモリ１８は、１つ以上のＲＡＭ（例、ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭ等）、バッテリバックアップＲＡＭまたはフラッシュメモリのような不揮発性メモリ、ディスクまたはＣＤ−ＲＯＭ等の磁気または光学式記憶装置を含むことが可能である。メモリ１８は、別々にアクセスできる複数のメモリ（例、プロセッサ１４Ａおよび１４Ｂにのみアクセスできる１つまたは複数のパーティションおよび文書プロセッサ１６にのみアクセスできる１つまたは複数の別のパーティション）を含むことが可能である。

図１は、メモリ１８に保存されているスタイルシートコンパイラ２０およびスキーマコンパイラ２２を示す。概して、スタイルシートコンパイラ２０および／またはスキーマコンパイラ２２は、あらゆるコンピュータでアクセス可能な媒体にコード化することが可能である。一般的に言えば、コンピュータでアクセス可能な媒体は、コンピュータに命令および／またはデータを提供するために使用する間に、コンピュータがアクセスできる任意の媒体を含むことが可能である。例えば、コンピュータでアクセス可能な媒体には、ネットワークおよび／または無線リンクのような通信媒体を介して伝達される、伝送媒体、または電気的、電磁的、またはデジタル信号のような信号を介してアクセスできる媒体、に加えて、例えばディスク（固定またはリムーバブル）、ＣＤ−ＲＯＭまたはＤＶＤ−ＲＯＭ等の磁気または光学的媒体のような記憶媒体、ＲＡＭ（例、ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭ等）、ＲＯＭ、フラッシュメモリ等の揮発性または不揮発性メモリ媒体等の記憶媒体、が挙げられる。

いくつかの実施形態では、コンピュータでアクセス可能な媒体を、コンパイルを行うためにスタイルシートコンパイラ２０および／またはスキーマコンパイラ２２を実行することが可能な独立した１つまたは複数のコンピュータシステムに含めることが可能である。そのコンパイルから生じるデータ構造／コードを、（例えば、内容変換装置１０へのネットワーク接続を介して）内容変換装置１０へ通信することが可能である。

本願明細書における説明では、１つのスタイルシートを１つの文書に適用する例を挙げているが、他の例では、複数のスタイルシートの１つの文書に適用する例（必要に応じて、同時に、または連続的に）、および１つのスタイルシートを複数の文書に適用する例（必要に応じて、コンテキスト切り替えと同時に、または連続的に）が挙げられることに留意されたい。

次に、図２は、文書プロセッサ１６の一実施形態のブロック構成図を示す。図２の実施形態において、文書プロセッサ１６は、構文解析回路４０と、式プロセッサ４２と、変換エンジン４４と、出力生成器４６と、バリデータ回路４８とを含む。構文解析回路４０は、式プロセッサ４２および出力生成器４６に結合される。式プロセッサ４２は、変換エンジン４４に結合され、それが出力生成器４６に結合される。バリデータ４８は、出力生成器４６に結合される。図２のユニットは、直接互いに結合するか（例、ユニット間の信号線を使用して）、メモリ１８を介して結合するか（例、ソースユニットは、送信先ユニットと通信する情報をメモリ１８に書き込み、送信先ユニットはメモリ１８からその情報を読み込むことができる）、またはその両方によって結合することが可能である。

構文解析回路４０は、文書を受信してその文書を解析することが可能であり、式プロセッサ４２およびバリデータ回路４８に対するイベントを識別し、その解析した内容でデータ構造を生成もする。文書プロセッサ１６がスタイルシートに従って文書を変換する場合、解析された内容を変換エンジン４４に対してメモリ１８のデータ構造に保存することができる。あるいは、その文書が解析されるだけであれば、構文解析回路４０は、出力生成器４６にＳＡＸまたはＤＯＭフォーマットで出力される解析した内容を提供することが可能である。構文解析回路４０は、メモリ１８を介して、出力生成器４６に解析した内容を提供することも可能である。

式プロセッサ４２は、構文解析回路４０からイベントを受信し（文書から解析した文書ノードを識別して）、構文解析回路４０が識別する文書ノードを解析時間の式ツリーと比較する。式プロセッサ４２は、各式の一致する文書ノードのリストを変換エンジン４４に出力する。変換エンジン４４は、構文解析回路４０によって構築された、解析した内容のデータ構造および一致する文書ノードのリストを受信し、命令表３０の対応する命令を実行して出力文書のための結果を生成する。いくつかの実施形態において、それぞれの命令はその他のものから独立しており、したがって、どの順序でも実行され得る。出力生成器４６はその結果を順番に再構築し、その出力文書をメモリ１８に書き込むことが可能である（または、メモリ１８を介さずに、出力文書をプロセッサ１４Ａおよび１４Ｂに送信することが可能である）。プロセッサ１４Ａおよび１４Ｂは、ソフトウェアを実行して出力文書を読み込み、その出力文書を要求元に発信することが可能である。

またバリデータ回路４８は、構文解析回路４０が送信したイベントを受信することも可能であり、（スケルトンツリーおよびＤＴＤ表３４で表されるように）スキーマ／ＤＴＤを適用し、その文書がスキーマに示されたように有効であるかどうかを判別することが可能である。文書が有効な場合は、バリデータ回路４８は成功メッセージを生成して出力生成器４６に発信することが可能である。文書が有効でない場合は、バリデータ回路４８は（１つまたは複数の失敗の理由を表示する）失敗メッセージを生成し、その失敗メッセージを出力生成器４６に発信することが可能である。出力生成器４６は、そのメッセージをメモリ１８に保存することが可能であるきる（続いてプロセッサ１４Ａおよび１４Ｂは、そのメッセージを要求元に発信することが可能である）。

図３は、文書プロセッサ１６の一部分（具体的には、構文解析回路４０、式プロセッサ４２、および変換エンジン４４）、およびプロセッサ１４Ａを示す。図３では、内容変換装置１０の一実施形態に基づいて示した部分の間の通信をより詳細に強調している。また、プロセッサ１４Ｂは、プロセッサ１４Ａに対して説明した様式で演算することが可能である。

プロセッサ１４Ａは、内容変換装置１０が連結されている１つまたは複数のネットワークからパケットを受信することが可能である。データペイロードのパケットは、内容変換装置１０によって変換される文書を含むことが可能である。加えて、受信した他のパケットは、他の通信（例、スタイルシートまたはスキーマ、あるいは他の内容変換装置１０との通信）を含むことが可能である。プロセッサ１４Ａは、文書を再構築し、その再構築した文書を構文解析回路４０に渡すことが可能である。

構文解析回路４０は、プロセッサ１４Ａから再構築した文書を受信し、さらにメモリ１８から記号表２４、ＤＴＤ表３４、および余白表３２にアクセスする。構文解析回路４０は、文書を解析し、発見した文書ノードに関連するイベントを生成する。より詳しくは、構文解析回路４０は、文書内のノード識別子を記号表２４の対応するシリアル番号に転換し、そのシリアル番号をイベントの一部として式プロセッサ４２へ発信する。加えて、構文解析回路４０は、変換エンジン４４に対する文書の解析した内容を保存する解析した内容の表を生成する。式プロセッサ４２は構文解析器４０からイベントを受信し、（それらのシリアル番号に基づいて）識別した文書ノードを解析時間の式ツリー２６と比較する。一致する文書ノードが識別され、変換エンジン４４に送信されるテンプレートおよび式一致リストに記録される。

変換エンジン４４は、テンプレートおよび式一致リスト、ならびに解析した内容表を受信し、さらに命令表３０受信する。変換エンジン４４は任意のランタイム式を評価し、テンプレートおよび式一致リストからランタイム式を満たさない文書ノードを削除する。加えて、変換エンジン４４は、その式と一致する各文書ノードの各式に対する命令表３０からの命令を実行し、結果を出力生成器４６に出力する。

図示の実施形態において、プロセッサ１４Ａは、再構築した文書をインラインで発信することが可能であり、構文解析回路もイベントを式プロセッサ４２へインラインで発信することが可能である。すなわち、文書の一部分がプロセッサ１４Ａによって受信されて再構築されると、プロセッサ１４Ａはその文書のその部分を構文解析回路４０へ渡す。構文解析回路４０は、したがって、プロセッサ１４Ａが文書全体を受信する前に解析を始めることができる。同様に、イベントが識別されると、それらのイベントは式プロセッサ４２に渡される。一方、解析した内容表およびテンプレート／式一致リストは、メモリ１８を介して渡される（変換エンジン４４への通信上に破線の楕円で示す）。本願明細書において使用されるように、データを直接渡す場合、そのデータは「インライン」でソースから受信者に発信されるが、メモリ１８等のメモリでバッファリングされる場合にはそうではない（しかし、ソースまたは受信者は転送のためにデータを一時的にキューに入れることが可能である）。インラインで発信したデータは、メモリを介した伝送よりも待ち時間が少なくなる場合がある。

図４は、文書を変換するための方法の一実施形態のフローチャートを示す。概して、該方法は、文書変換が複数の段階を含む際に適用することが可能である。スタイルシート内の式は、それらを評価できる最も初期の段階に基づいて分類することが可能である。次いで、各段階の間に、その段階で評価できる式が評価される。したがって、各式を最も初期の可能な段階で評価でき、その後の段階で評価すべき式がほとんど残らない。

図示の実施形態において、段階には、コンパイル段階、分解段階、および変換段階が含まれ得る。コンパイル段階において、スタイルシート内の式が（例えば、本実施形態では、コンパイル時間、解析時間、またはランタイムのいずれかとして）特徴づけられる（ブロック５０）。加えて、コンパイル段階において、コンパイル時間式が評価される（ブロック５２）。解析段階の間に解析時間式が評価される（ブロック５４）。変換段階の間にランタイム式が評価される（ブロック５６）。

いくつかの実施形態において、ランタイム式は、初期に評価可能である部分（例えば解析時間）、およびランタイムの部分に分類することが可能である。初期に評価可能である部分を、評価して、ランタイムの部分に基づいて分類することが可能である。すなわち、式の解析時間部分と一致し、式のランタイムの部分に使用される１つまたは複数の同じ値を有する文書ノードを分類する。ランタイム時に、式のランタイムの部分が評価され、グループに対応する値がその式のランタイムの部分を満たしていなければ、その式は削除される。式のランタイムの部分を満たすグループだけが保持され、保持したグループ内の文書ノードに命令を実行する。

ＸＳＬＴスタイルシートを実施する一実施形態では、式が祖先／子孫参照（／／）および述語を含んでいなければ、その式はコンパイル時間となり得る。式が現在のノード、次の兄弟ノードまたは要素値を参照する述語を含んでいなければ、その式は解析時間となり得る。コンパイル時間または解析時間でない式は、ランタイム式である（例、現在のノードを参照する式、または次の兄弟または要素値を参照する述語を含む式）。現行ノードを参照しないランタイム式に関して、上述の述語を含まない部分は、解析時間で評価することが可能である。このコンテキストでは、現在のノードは、コンテキストノードとし、その式がテンプレートに一致した式である場合には、テンプレート本体内のステートメント内で参照されるノード（例、テンプレート本体内のループ構文または他の式）とすることが可能である。

どの式が解析時間対ランタイムであるかは、一つには、式プロセッサ４２のインライン性質に影響を受ける場合がある。すなわち、文書ノードは識別され、式プロセッサ４２にインラインで渡される。対照的に、式の処理がインラインでない場合、過去および今後の文書ノードを、特定のノードの処理中に検索する可能性がある。したがって、式の処理がインラインでない場合、現行ノードを参照する式に限り、処理できない場合がある。インライン処理に関して、式ツリーに一致する文書ノードは、概して、式ツリー内の式ノードと以前の文書ノードとの一致に関する情報の保持を含むことが可能である。次いで、以前の文書ノードの子または子孫が構文解析回路４０によって識別される場合、当該の子／子孫文書ノードは、式ツリー内の以前に一致した式ノードにリンクしたその式ツリー内の次のレベルと比較することが可能である。

コンパイル時間の式の評価は、「テンプレート適用選択」ステートメント内の式に適用することが可能である。上述のように、「テンプレート適用」ステートメントは、テンプレート本体のコンテキスト内のノードのセットを選択し、テンプレートをそれらのノードに適用する。「テンプレート適用選択」ステートメントは、ノードのセットを選択する式を含む。そのノードのセットは、次いでスタイルシートのテンプレートに適用される。「テンプレート適用選択」ステートメント内の式が上述の与えられたコンパイル時間の定義を満たせば、次いでコンパイラは、そのセット内のノードのテンプレート（もしあれば）のどれが一致するのかを判断する。したがって、テンプレートの一致は、当該の場合に削除することが可能である。一実施形態において、コンパイラは、テンプレート適用選択ステートメント内の式とテンプレート一致条件を含む式との代数的な一致を行うことが可能である。解析時間の式およびランタイムの式の評価は、どのノードが式を満たすかの判断を含むことが可能である。

一実施形態において、ＸＭＬスキーマによって記述されるＸＭＬ文書のコンテキスト内のＸＰａｔｈ式の代数的な一致は、下記のように行うことが可能である。以下の定義は、ＸＰａｔｈ式およびＸＭＬスキーマの代数的な一致アルゴリズムの説明に有用となり得る。ＰをＸＰａｔｈ式とし、ＳをＸＭＬスキーマとすると、Ｐに生じる各要素および属性名がＳにおいて宣言され、Ｓにおいて同じ型（要素または属性）を有する場合に限り、Ｐを定義することが可能である。ＰおよびＱを２つのＸＰａｔｈ式とすると、入力文書Ｄの各ノードがＰと同様にＱも満たすＳに基づく場合に限り、ＰをＳに対する一致Ｑと称することが可能である。「単純な」式は、「／／」演算子、および、「．」演算子を除外した式とすることが可能である。これらの定義を前提として、一実施形態の代数的な一致を、以下のように式Ｐおよび一連の１つ以上の単純な式Ｅに対して実行することが可能である。第一に、式を正規化することが可能である。「／」で始まる式は、正規形である。式Ｑが、「／」で始まっていなければ、次のように正規化される：（ｉ）Ｑがいずれかのループ内にあれば、各ループ（各選択式およびＱを／演算子で区切る）に対する選択式を有し、Ｑに最も近く、先頭に付加した式の始めとして最外ループへ進む最内ループ選択式を有するＱを先頭に付加する。（ｉｉ）Ｑが生じるテンプレートのテンプレート一致条件を有する、（ｉ）から形成される式を先頭に付加する。および（ｉｉｉ）テンプレート一致条件が「／」でない場合、（ｉ）および「／／」を有する、（ｉｉ）から形成される式を先頭に付加する。（上述のように正規化される）単純な式Ｅの場合の式ツリーは、述語を無視することを除いては、解析時間の式ツリー２６と同様に形成される。（述語に関する例外を以って）同一である式は、したがって、式ツリー内の同じパスにマップさせることが可能であり、その式ツリー内の同じリーフノードと関連する。Ｐは、その式ツリーと一致する（すなわち、Ｐの各ノード識別子または演算子は同じ位置でその式ツリーと一致する）。リーフノードが、Ｐが空になるのと同時に式ツリーに達する場合、そのリーフノードと関連する式は、Ｐと一致するＥ内の式である。これらの一致する式は、削除が可能なコンパイル時間の式とすることが可能である。

図５は、スタイルシートコンパイラ２０のフローチャートを示す一実施形態である。スタイルシートコンパイラ２０がソフトウェアに実施される実施形態において、スタイルシートコンパイラ２０は、実行すると図５に示す機能を実施する命令を含む。図５のブロックはスタイルシートコンパイラ２０の機能を示すが、フローチャートはコンパイラがリスト順にその機能を実行することを示唆するものではなく、また総じて次の機能を開始する前にスタイルシート上の１つの機能を完了させるものではないことに留意されたい。

スタイルシートコンパイラ２０は、スタイルシート内の式を識別し（ブロック６０）、その式をコンパイル時間、解析時間、またはランタイムに分類する。その式は、テンプレート一致ステートメント内、テンプレート適用ステートメント内、およびスタイルシート内のさまざまな他のステートメント内に存在することが可能である。スタイルシートコンパイラ２０は、各式の標準形を生成する（ブロック６２）。一般的に、異なる方法が論理的に等価であっても、所定の式を表すには多くの異なる方法がある。標準形は、等価式（または、等価である式の部分）を識別する処理を簡素化するために、所定の式を表す特定の方法を指定する。スタイルシートコンパイラ２０は、式のノード識別子にシリアル番号を割り当てる（ブロック６４）。

スタイルシートコンパイラ２０は、解析時間の式ツリーを構築するために、その式に共通のプレフィックスコンパクションを行うことが可能である（ブロック６６）。上述のように、式は、概して文書内のノード識別子に一致するノード識別子の階層的リストを含むことが可能である。したがって、種々の式が、共通する部分を有することが可能である（特に、階層のより高い（すなわち、ルートにより近い）式ノードは、種々の式に対して同一となり得る）。共通する部分は、したがって、式の第１の部分（その式の「プレフィックス」）に存在することが可能である。当該の式を解析時間の式ツリー内にともに圧縮することによって、共通の部分を解析時間の式ツリー内に一度に表すことが可能であり、式が異なり始めれば、残りの式はその共通の部分の子となる。したがって、文書ノードを一致させることが可能な複数の式を並行して評価することが可能であり、解析時間の式ツリーの共通部分において、差異が生じたときにツリー内を分岐することが可能である。解析時間の式ツリーは、より小さくすることが可能であり、そのような場合には、より迅速に処理することが可能である。

例えば、２つの式（シリアル番号を割り当てた後）は、／１０／１５／２０／２５、および、／１０／１５／２０／３０／３５となり得る。これらの２つの式は、共通して／１０／１５／２０／を有する。したがって、これらの２つの式は、子としてノード１５を有するノード１０と、子としてノード２０を有するノード１５とを含む共通の部分として解析時間の式ツリー内に表すことが可能である。ノード２０は、２つの子（２５および３０）を有することが可能である。ノード３０は、子としてノード３５を有することが可能である。文書ノードが解析され、式プロセッサ４２に渡されるとき、ノード２０が達するまで、式を文書ノードに対して並行して評価することが可能である。次の子文書ノードは、次いで式ノード２５または３０の１つと一致し、またはどちらにも一致し得ない。

上述のように、スタイルシートコンパイラ２０は、解析時間で評価される部分およびランタイムで評価される部分にランタイム式を分類することが可能である。解析時間の部分は、解析時間の式ツリー内に含まれることが可能である。ランタイム述語が生ずる解析時間の式ツリー内の各レベルにおいて、スタイルシートコンパイラ２０は、述語をランタイムで評価することができ、一致する文書ノードがランタイム述語を満たすかどうかによってそれらを保持または破棄することが可能となるように、一致するノードが分類される（および、ランタイム述語が使用する情報を保持することが可能である）ことを示すことが可能である。所定のランタイム式は、式内の種々のレベルにおいて１より多いランタイム述語を含むことが可能であるので、複数のレベルの分類が生ずる可能性がある。各分類レベルでは、ランタイム述語に対応する同じ値を有する文書ノードを一緒に分類する。ランタイム述語を評価されるときに、その値がランタイム述語と一致しない場合、文書ノードのそのグループ（および、そのグループの全てのサブグループ）は破棄される。その値が評価したランタイム述語と一致するグループは保持され、変換エンジン４４によって処理される。

スタイルシートコンパイラ２０は、構文解析回路４０および／または式プロセッサ４２が使用する複数のデータ構造をメモリ１８に出力することが可能である（ブロック６８）。ノード識別子をシリアル番号にマップする１つ以上の記号表２４に加えて、解析時間の式ツリーが出力され得る。例えば、一実施形態においては、独立した記号表を要素名および属性名に対して出力されることが可能である。他の実施形態においては、単一の記号表を出力されることが可能である。加えて、スタイルシートコンパイラ２０は、各テンプレートに対する一連の命令を有する命令表３０を出力することが可能であり、それを変換エンジン４４が実行してテンプレート本体がもたらされる。スタイルシート２０は、変換エンジン内で実行された場合、ランタイム述語を評価する各ランタイム述語に対する命令をさらに出力することが可能である。さらに、スタイルシートコンパイラ２０は、後述するようにテンプレートリスト表３８および式リスト表３６を出力することが可能である。

いくつかの実施形態において、所定のスタイルシートは、１つ以上の他のスタイルシートを含むこと、および／または１つ以上の他のスタイルシートをインポートすることを含み得る。含まれたスタイルシートは、その含まれたスタイルシートが含めるスタイルシートに物理的に移動されるかのように処理される（例、Ｃ言語における＃ｉｎｃｌｕｄｅステートメントの処理と同様）。すなわち、含まれたスタイルシートの本体は、本質的にｉｎｃｌｕｄｅステートメントを含めるスタイルシート内で置き換えることが可能である。含まれたスタイルシートと含めるスタイルシート（例、大域的な変数宣言）との間に競合がある場合、含めるスタイルシート内の定義が使用される。ＸＳＬＴスタイルシートにおいて、含まれたスタイルシートは、含めるスタイルシート内のｘｓｌ：ｉｎｃｌｕｄｅ要素に記述することが可能である。一方で、インポートしたスタイルシートは、含めるスタイルシート内のステートメントが明示的に参照されることが可能な独立したスタイルシートとして処理される。明示的な参照は、例えば、テンプレート一致ステートメント内で生じ得る（インポートしたスタイルシートからのテンプレートを使用する場合）。明示的な参照が、インポートするスタイルシートの他の場所である場合、インポートするスタイルシート内の一致するテンプレートは、インポートしたスタイルシート内の一致するテンプレートに優先する。複数のスタイルシートおよび１つの一致するテンプレートが、１つより多いインポートしたスタイルシートに生じる場合、インポートするスタイルシート内にインポートしたスタイルシートをリストする順序は、どの一致するテンプレートが選択されるのかを制御する（例、一致を有する最初にリストされ、インポートしたスタイルシートを使用する）。ＸＳＬＴスタイルシートにおいて、インポートしたスタイルシートは、ｘｓｌ：ｉｍｐｏｒｔ要素内に記述することが可能である。

「メイン」（インポートする、または含める）スタイルシートおよび各インポートしたまたは含まれたスタイルシートは、スタイルシートコンパイラ２０によって独立してコンパイルすることが可能である。含まれたスタイルシートの場合、メインスタイルシートに対するデータ構造および含まれたスタイルシートは、式プロセッサ４２が使用する一連のデータ構造にマージすることができる。インポートしたスタイルシートの場合、データ構造は独立して残すことが可能であり、式プロセッサ４２は並行してデータ構造を文書に適用することが可能である。このような実施形態は、一致する式における競合が、上述の競合解消を実施する競合解消ロジックによって処理することが可能であることを除いて、式プロセッサ４２の実施形態と同様とすることが可能である。

いくつかの実施態様において、スタイルシートは、スタイルシートを適用する文書以外の１つ以上の文書を参照するステートメントを含むことが可能である。そのスタイルシートは、参照される文書を処理するために更なるステートメント含むことが可能である。一実施においては、スタイルシートコンパイラ２０は、無条件でどの参照される文書を使用したのかを識別することが可能である（すなわち、スタイルシートをいずれかの文書に適用する各場合において、その参照される文書を使用することが可能である）。内容変換装置１０は、入力文書の処理が始まるときに、無条件で参照される文書を取り込むことが可能であり、その無条件で参照される文書は、スタイルシートで参照される順序で解析することが可能である。変換エンジン４４が参照される文書を使用する命令を実行するためのものであり、参照される文書の解析がまだ始まっていない場合、変換エンジン４４は、別のタスクにコンテキストを切り替えることが可能である。条件つきで参照される文書の解析がまだ始まっていない場合、変換エンジン４４は、別のタスクにコンテキストを切り替えることが可能である。条件つきで参照される文書に対して、内容変換装置１０は、その文書を使用する命令を実行しようとする変換エンジン４４に応えて、その文書を取り込むことが可能であり、その文書は、無条件で参照される文書に対して上述のようなときに解析される。他の実施においては、内容変換装置１０は、そのスタイルシートが入力文書に使用されるか、または参照される文書を使用する命令を実行しようとする変換エンジン４４に応えて、その文書を取り込むことが可能である場合、スタイルシートに対応する全ての参照される文書を取り込むことが可能である。

図６は、スキーマコンパイラ２２の一実施形態を示すフローチャートである。スキーマコンパイラ２２をソフトウェアに実施する実施形態において、スキーマコンパイラ２２は、実行されると、図６に示す機能を実施する命令を含む。図６のブロックはスキーマコンパイラ２２の機能を示すが、フローチャートはコンパイラがリスト順にその機能を実行することを示唆するものではなく、また総じて次の機能を開始する前にスタイルシート上の１つの機能を完了させるものではないことに留意されたい。

スタイルシートコンパイラ２０と同様に、スキーマコンパイラ２２はスキーマ（またはＤＴＤ）のノード識別子にシリアル番号を割り当てることが可能である（ブロック７０）。スタイルシートコンパイラ２０によって所定のノード識別子に割り当てられるシリアル番号は、スキーマコンパイラによって割り当てられるシリアル番号と異なることがある。

スキーマコンパイラ２２は、構文解析回路４０が使用するための複数の表を生成することが可能である。例えば、実体参照は文書に含むことが可能であり、スキーマ／ＤＴＤは実体値を定義することが可能である。ＤＴＤ実体参照表は、実体参照を相当値にマップするために作成することが可能である。加えて、スキーマ／ＤＴＤは、属性を含むことが可能な所与の要素がその属性を含まない場合、属性のためのデフォルト値を指定することが可能である。ＤＴＤのデフォルトの属性リストは、属性およびデフォルトを記録するために作成することが可能である。加えて、許容され、要求される文書構造を識別するスケルトンツリーは、文書が（スキーマ／ＤＴＤにおいて定義したように）有効であるかどうかを決定するバリデータが使用するために作成することが可能である。スキーマコンパイラ２２は、メモリ１８に、記号表、ＤＴＤ表、およびスケルトンツリーを出力する（ブロック７２）。

図７は、構文解析回路４０の一実施形態のための、構文解析回路４０、入力データ構造、および出力データ構造を示す。図示の実施形態において、構文解析回路４０が使用する入力データ構造は、ＤＴＤ実体参照表３４ＡおよびＤＴＤ属性リスト３４Ｂ（ＤＴＤ表３４の一部であってよい）、余白表３２、および記号表２４を含むことが可能である。構文解析器４０は、動的記号表３９Ａ（文書プロセッサ構造３９の一部）および一連の解析した内容表３９Ｂ（文書プロセッサ構造３９の一部）を作成および使用することが可能である。より詳しくは、図示した実施形態において、解析した内容表３９Ｂは、スケルトン表８０、要素インデックス表８２、要素名／値表８４、属性インデックス表８６、属性名／値表８８、属性リスト９０、処理命令／コメント（ＰＩ／Ｃ）表９２、ＰＩインデックス表９４、および要素目次（ＴＯＣ）９６を含むことが可能である。解析した内容表３９Ｂは、変換エンジン４４における文書変換に使用することが可能である。いくつかの実施形態において、構文解析回路４０は、解析のみの要求に対するＳＡＸまたはＤＯＭフォーマットでの解析した内容を出力するように構成することも可能である。

構文解析回路４０は、プロセッサ１４Ａ（図７には示さず）から受信したままの状態で文書を解析して、解析した内容表３９Ｂを生成するように構成することが可能である。概して、解析した内容表３９Ｂは、情報をさまざまなノードにリンクさせるポインタとともに、さまざまな種類の文書内容に対する表を含むことができる。図７に示す解析した内容表３９Ｂに関する詳細を下記に示す。加えて、構文解析回路４０は、（ｉ）文書内の各コードに対するプレオーダーおよびポストオーダー数を生成すること、（ｉｉ）ＤＴＤ／スキーマからの実体参照を実体値に置き換えること、（ｉｉｉ）所定の実体参照（ＸＭＬ仕様にて説明したように）を対応する文字に置き換えること、（ｉｖ）ＤＴＤ／スキーマからのデフォルト属性および／または属性値を追加すること、（ｖ）ＣＤＡＴＡセクションを文字に置き換えること、（ｖｉ）スタイルシートが命令するように余白を取り除くか保存し、余白を正規化すること、および（ｖｉｉ）埋め込まれたＤＴＤ／スタイルシートまたはＤＴＤ／スタイルシートに対する埋め込まれた参照を識別することが可能である。

実体参照を実体値に置き換えるために、構文解析器４０は、ＤＴＤ実体参照表３４Ａを使用することができる。文書が実体参照を受ける場合、構文解析回路４０は、ＤＴＤ実体参照表３４Ａ内の実体参照を検索すること、およびＤＴＤ実体参照表３４Ａからの対応する実体値を読み込むことが可能である。実体値は、その文書に対して構文解析回路４０が出力する解析した内容に、実体参照を置き換える。一実施態様において、ＤＴＤ実体参照表３４Ａは、各エントリがハッシュした実体参照（例、周期的な冗長性コード（ＣＲＣ）−１６ ｈａｓｈ）を格納する、複数のエントリを有する最初のセクションと、実体値を含む文字列が格納されるＤＴＤ実体参照表３４Ａの第２のセクションへのポインタとを含むことが可能である。構文解析回路４０は、文書内に検出される実体参照をハッシュすること、およびそのハッシュをＤＴＤ実体参照表３４Ａの最初のセクションのハッシュ値と比較して、その一致する実体値を第２のセクションに置くことが可能である。

文書にデフォルト属性または属性値を追加するために、構文解析回路４０は、ＤＴＤ属性リスト３４Ｂを使用することが可能である。ＤＴＤ属性リスト３４Ｂは、さまざまな要素名のためのデフォルト属性および／または属性値を含むことが可能であり、構文解析回路４０は、その要素に任意のデフォルト属性または属性値が含まれているかどうかを決定するために、文書内の要素開始タグに検出される要素名を検索することが可能である。デフォルトが含まれている場合、構文解析器４０は、要素クローズが検出されるまで、要素開始タグ内に含まれる属性を追跡することが可能である。ＤＴＤ属性リスト３４Ｂ内の属性および／または属性値が要素に含まれていない場合、構文解析回路４０は、ＤＴＤ属性リスト３４Ｂからの属性／属性値を挿入することが可能である。一実施形態において、ＤＴＤ属性リスト３４Ｂは、ハッシュされた要素名（例、ＣＲＣ−１６ ｈａｓｈ）を含む最初のセクションと、ＤＴＤ属性リスト３４Ｂの第２のセクションへのポインタとを有することが可能である。第２のセクションは、ハッシュされた属性名（例、ＣＲＣ−１６ ｈａｓｈ）と、デフォルトの属性名／値が文字列として格納されるＤＴＤ属性リスト３４Ｂの第３のセクションへのポインタとを含むことが可能である。構文解析回路４０は、要素名をハッシュすること、そのハッシュを最初のセクション内のそのハッシュを検索すること、および第１の部分に一致が見つかった場合に、ハッシュされた属性名および第２のセクションからのポインタを読み取ることが可能である。各属性名が検出されると、構文解析回路４０は、その属性名をハッシュして、それらをＤＴＤ属性リスト３４Ｂからのハッシュした属性名と比較することが可能である。要素クローズが検出された場合、文書内で構文解析回路４０が検出しなかった任意のハッシュされた属性名は、デフォルトが必要な属性とすることが可能であり、そのデフォルトは、ＤＴＤ属性リスト３４Ｂの第３のセクションから読み込み、解析した内容表３９Ｂに挿入することが可能である。

余白表３２は、どの要素名がスタイルシートに指定されているように取り除かれる余白を有することになるのかを示すことが可能である。一実施形態においては、余白が取り除かれる各要素名をハッシュすることが可能であり、（例、ＣＲＣ−１６ ｈａｓｈアルゴリズム）、ハッシュ値は表に格納される。構文解析回路４０が文書内の要素名を検出する場合、構文解析回路４０は、その要素名をハッシュし、余白表３２内でそれを検索することが可能である。一致が見つかった場合、構文解析回路４０は、その要素から余白を取り除くことが可能である。それ以外ならば、構文解析回路４０は、要素内に余白を保存することができる。

上述のように、記号表２４は、ノード識別子をスタイルシートコンパイラによって割り当てられるシリアル番号にマップすることが可能である。構文解析回路４０は、記号表２４を使用して文書内の要素または属性名（名前空間を使用する場合、名前空間プレフィックスによって修飾される）を式プロセッサ４２に渡すためにシリアル番号に変換することが可能である。しかし、その文書がスタイルシート内に表されない要素または属性を含む可能性がある。そのような場合、構文解析回路４０は、シリアル番号を割り当てて、動的記号表３９Ａにそのシリアル番号を格納することが可能である。図８のフローチャートは、文書内の要素または属性を検出する場合の構文解析回路４０の動作の一実施形態を示す。

構文解析回路４０は、ノード識別子（例、選択的に名前空間プレフィックスを前置した要素／属性名）に対するコンパイラの記号表２４をスキャンすることが可能である（ブロック１００）。エントリが見つかった場合（判断ブロック１０２、「ｙｅｓ」レグ）、構文解析回路４０は、シリアル番号をコンパイラの記号表２４から読み込むことが可能である（ブロック１０４）。エントリが見つからなかった場合（判断ブロック１０２、「ｎｏ」レグ）、構文解析回路４０は、ノード識別子に対する動的記号表３９Ａをスキャンすることが可能である（ブロック１０６）。エントリが見つかった場合（判断ブロック１０８、「ｙｅｓ」レグ）、構文解析回路４０は、シリアル番号を動的記号表から読み込むことが可能である（ブロック１１０）。エントリが見つからなかった場合（判断ブロック１０８、「ｎｏ」レグ）、構文解析回路４０は、一意のシリアル番号（コンパイラの記号表２４にも動的記号表３９Ａにもすでに記録されていないシリアル番号）を生成することが可能であり、生成したシリアル番号およびノード識別子によって動的記号表３９Ａを更新することが可能である（ブロック１１２）。任意の場合においても、構文解析回路４０は、イベント内のシリアル番号を式プロセッサ４２に発信することが可能である（ブロック１１４）。

要素は、しばしば同じ名前（例、同じサブ要素または属性の複数のインスタンス）を有する複数の子（要素または属性）を有することに留意されたい。したがって、ノード識別子が入力時に検出された場合、次のノード識別子が同一となる（または、ノード識別子が、検出された次のいくつかの名前の範囲内で繰り返される）可能性がある。いくつかの実施形態において、構文解析回路４２は、１つ以上の直前に検出した名前および対応するシリアル番号を保持することが可能であり、記号表２４および動的記号表３９Ａを検索する前に新しく検出されたノード識別子とこれらの名前とを比較することが可能である。

いくつかの実施形態においては、コンパイラの記号表２４に一致しないノードを最適化することが可能である。コンパイラがシリアル番号をスタイルシート内の各ノード識別子に割り当てるため、コンパイラの記号表２４に一致しないノードは、解析時間の式ツリー３６内のどのノードとも一致しないことがわかる。構文解析回路４０は、シリアル番号がコンパイラの記号表２４からのもの、または動的記号表３９Ａからのものであるかどうかのイベント内の表示を含むことが可能である。シリアル番号がコンパイラの記号表２４からのものではない場合、式プロセッサ４２は、イベントを解析時間の式ツリー３６と比較することができない。式プロセッサ４２は、他の目的（例、一部のイベント型に対して、任意の「／」式ノードの子が以降のイベントと一致しない）のための注記を行うことが可能である。

一実施形態において、構文解析回路４０が生成し、シリアル番号（および一部の実施形態におけるプレオーダー番号）とともに式プロセッサ４２に発信することが可能である複数のイベントが存在し得る。要素開始タグが検出された場合には、要素開始イベントを生成することが可能であり、シリアル番号をその要素名に対応するシリアル番号とすることが可能である。要素終了タグが検出された場合には、要素終了イベントを生成することが可能であり、シリアル番号をその要素名に対応するシリアル番号とすることが可能である。要素開始タグ内に属性名が検出された場合には、属性名イベントを生成することが可能であり、シリアル番号をその属性名のシリアル番号とすることが可能である。要素開始タグの終了が検出された場合には、要素クローズイベントを生成することが可能であり、シリアル番号をその要素のシリアル番号とすることが可能である。式プロセッサ４２のための所望のスタイルシート／文書コンテキストを確立するために、構成イベントも生成することが可能である。

一実施形態において、記号表２４は、個々の文字のツリーとして配置することが可能である。表内の各エントリは、文字、リーフノード表示、レベル表示の終了、および、そのエントリがノード識別子の最後の文字である場合に、そのエントリの第１の子またはそのシリアル番号のいずれかを含むことが可能である。表の最上部から開始し、１つまたは複数の名前のそれぞれの一意の第１の文字がエントリに提供され、そのエントリが非リーフノードとして示され、その名前の次の文字を格納する第１のエントリにポインタが設定される。そのポインタでの一連のエントリへのグループ化は、第１の子（第３の文字）等へのポインタとともに第１の文字を有する名前の各一意の第２の文字である。所定の名前の終わりの文字に達したとき、リーフノード表示は、エントリがリーフであり、ポインタフィールドがシリアル番号であることを示す。レベル内の最後の一意の文字に達すると、一連の終わりがレベル表示の終わりによって示される。同様に、（名前の第１の文字に対する）エントリの第１のレベルの終了は、レベル表示の終了を使用して記録することが可能である。したがって、記号表２４のスキャンは、文字単位でツリーを下って、検出した名前と記号表２４との比較を含むことが可能である。

一実施形態において、動的記号表３９Ａは、わずかに異なって編成することが可能である。名前は、その名前内の第１の文字に基づいて「ビン（ｂｉｎ）」に格納される。名前の可能な第１の文字のそれぞれは、動的記号表３９Ａへのオフセットとして使用することが可能である。これらのオフセットの各エントリは、ビンポインタ、および、「ビン内の最後のエントリ」ポインタを含むことが可能である。ビンポインタは、名前の残り（すなわち、名前の終わりまでの文字２）、シリアルＩＤ、および次のビンエントリへのポインタ（すなわち、そのビンエントリをリンクされたリストとすることが可能）を含む文字列である。検出された名前は、ビンエントリ内の文字列と比較することが可能で、一致が検出された場合、シリアルＩＤを使用することが可能である。それ以外ならば、次のビンエントリを読み込むために、次のビンエントリに対するポインタを使用する。一致を検出せずにビンの終わりに達した場合は、次いで新しいエントリをビン内の名前に追加する（また、シリアル番号を割り当てる）。１つの特定の実施形態において、各ビンエントリは、複数の文字（例、２）を格納するように構成された１つ以上のサブエントリ、および全ての文字が有効であること、または文字列の終わりを複数の文字内に置くこと、のいずれかを定義する１つのコードを含むことが可能である。「ビン内の最後のエントリ」のポインタは、ビン内の最後のエントリを示すことが可能であり、新しいエントリが加えられたときに次のビンポインタを更新するために使用することが可能である。

解析した内容表３９Ｂを一実施形態に対して以下に詳細に説明する。構文解析回路４０は、文書の構造／内容を識別し、検出した構造／内容に基づいてさまざまなデータ構造に対する文書内容を解析した内容表３９Ｂに書き込む。例えば、構文解析回路４０は、要素名／値表８４内で検出された要素名（および、対応する要素値／テキストノード）を格納することが可能であり、属性名／値表８８内で検出された属性名（および、相当値）を文字列として格納することが可能である。対応するインデックス表８２および８６は、対応する文字列の始めに対するポインタを表８４および８８にそれぞれ格納することが可能である。インデックス表８２および８６は、それぞれ要素（図７のＥＳ／Ｎ）または属性（図７のＡＳ／Ｎ）のシリアル番号を使用してアドレス指定が行われる。

処理命令／コメント（ＰＩ／Ｃ）表９２は、処理命令およびコメントに対応する文字列を格納する。コメントは、要素ＴＯＣ ９６に格納したポインタによって置かれる文字列として格納することが可能である。処理命令は：処理命令の目標部分（拡張した名前）、および処理命令の値部分（文書からの処理命令の残り）の２つのストリング値を含むことが可能である。処理命令の目標および処理命令値は、エントリからの一組のポインタによってＰＩインデックス表９４内に置くことが可能であり、要素ＴＯＣ ９６からのポインタによってインデックスが付けられる。ＰＩインデックス表９４のエントリは、一組のポインタおよび処理命令に割り当てられるシリアル番号を含むことが可能である。

構文解析回路４０は、各要素に対する属性リスト９０を文書内に生成することも可能である。属性リスト９０は、属性名／値表８８内の（もしあれば）属性名および属性値に対するポインタによって、その要素に対応する（シリアル番号による）属性のリストとすることが可能である。加えて、構文解析回路４０は、各要素のための要素ＴＯＣ ９６を生成することが可能である。要素ＴＯＣ ９６は、対応する要素（例、子要素、テキストノード、コメントノード、および処理命令ノード）の子ノードを識別する。要素ＴＯＣ ９６内の各エントリは、ノード位置（子要素の位置をノード内の他の子要素と比較して識別する）、ノード型（子ノードを要素、テキスト、コメントまたは処理命令として識別する）、および（コメント、処理命令、またはテキストノードのための）ノード内容ポインタまたは（要素ノードのための）子のプレオーダー番号のいずれか、を含むことが可能である。ノード内容ポインタは、コメントノードのためのＰＩ／Ｃ表９２へのポインタ、処理命令ノードのためのＰＩインデックス表９４へのポインタ、またはテキストノードのための要素名／値表８４へのポインタである。一実施形態において、要素ＴＯＣ ９６をエントリのリンクされたリストとすることが可能であり、したがって、各エントリはリスト内の次のエントリに対するポインタをさらに含むことが可能である。

スケルトン表８０は、文書内の各要素ノードに対するエントリを含むことが可能であり、その要素ノードのプレオーダー番号によってインデックスを付けることが可能である。図示の実施態様では、スケルトン表の任意のエントリは、親ノードプレオーダー番号（ＰＰＲＥＯ）と、要素ノードに対する直前の兄弟のプレオーダー番号（ＩＰＳＰＲＥＯ）と、要素ノードの子孫であるサブツリー内の最後のプレオーダー番号も含むことが可能な要素ノードのポストオーダー番号（ＰＳＴＯ）と、要素シリアル番号（ＥＳ／Ｎ）と、要素ノードのための属性リスト９０に対する属性リストポインタ（ＡＬＰ）と、要素ノードのための要素ＴＯＣ ９６に対する目次ポインタ（ＴＯＣＰ）と、（もしあれば）要素ノードに対する一致するテンプレートをリストしたテンプレートリスト表３８内のエントリを示すテンプレートリストポインタ（ＴＬＰ）とを含む。

上述の種々のデータ構造は文字列を含むことに留意されたい。一実施形態において、文字列長（例、文字数）は、その文字列の最初の「文字」として格納することが可能であり、構文解析回路４０は、何文字を読み込むのかを決定するために、その文字列を使用することが可能である。

上述の例の構文解析回路４０およびその出力データ構造は、ＸＭＬ文書に使用することが可能である。一実施形態において、構文解析回路４０は、ＸＭＬ文書を解析するように設計されたハードウェア回路構成を含む。いくつかの実施形態においては、構文解析回路４０は、リレーショナルデータベース構造（例えばＳＱＬ、Ｏｒａｃｌｅ等）を解析するように設計されたハードウェア回路構成も含むことが可能である。構文解析回路４０は、図７に示す構造と類似の解析したリレーショナルデータベース構造を出力することが可能であり、したがって、式プロセッサ４２および変換エンジン４４は、その入力がＸＭＬなのかリレーショナルデータベースなのかを知る必要がない。

いくつかの実施態様において、構文解析回路４０は、他の種類の文書を解析するようにプログラム可能である。構文解析回路４０は、１つ以上の入力型記述子によってプログラム可能になり得る。入力型記述子は、例えば、文書内に構造区切りを記述すること、文書が事実上階層的か、または平板状かを示すこと、階層的な文書が構造の各レベルに対して明示的な終わりを有するかどうかを示すこと、構造の終わりが明示的でない場合、どのようにその終わりを検出すべきかを定義すること、もしあれば、所定の構造的なユニット内に内部構造を定義すること、が可能である。

いくつかの実施形態では、構文解析回路４０へのフィルタ処理した文書を生成するために、ＣＰＵ １４Ａおよび１４Ｂが提供する文書をフィルタ処理する、プレ構文解析回路も含むことが可能である。すなわち、構文解析回路４０は、フィルタを通過した文書の一部だけを受信し、構文解析回路４０は、その受信した部分を解析する文書全体として処理することが可能である。プレ構文解析器は、例えば、比較的大きな文書が提供されても、その文書のサブセットだけが対象となる場合に使用することが可能である。プレ構文解析器は、文書を任意の所望の形態にフィルタ処理するようにプログラム可能である（例えば、文書の始めから所定の数の文字をスキップして、複数の文字またはその文書の終わりまで取り込むように；文書内容を取り込む前に特定の要素まで、または複数の要素までフィルタ処理するように；および／または、取り込む文書の一部を識別する、より複雑な式（例、ＸＰａｔｈ式）などにプログラム可能である）。プレ構文解析器は、スタイルシートが文書内容を破棄するなどの影響を有する場合に、スタイルシートコンパイラ２０によってユーザーがプログラムすることが可能である。

図９は、式プロセッサ４２の一実施形態のための、式プロセッサ４２、入力データ構造、および出力データ構造を示すブロック図である。図示の実施形態では、式プロセッサ４２が使用する入力データ構造は、解析時間の式ツリー２６、式リスト表３６、およびテンプレートリスト表３８を含む。式プロセッサ４２は、複数の文書プロセッサ構造３９（特に、／スタック３９Ｃ、／／スタック３９Ｄ、ポインタ（Ｐｔｒ）スタック３９Ｅ、および属性（Ａｔｔｒ）スタック３９Ｆ）を生成および使用することも可能である。式プロセッサ４２は、変換エンジン４４にテンプレート／式一致リスト３９Ｇを出力することが可能である。

概して、式プロセッサ４２は、構文解析回路４０からイベントを受信し、その中に識別される文書ノードを解析時間の式ツリー２６内の式ノードに一致させる。文書ノードは、それらがインラインで解析されるように受信される。したがって、任意の所定の時点で、以前に受信した文書ノードは、解析時間の式ツリーの一致した部分を有することが可能であるが、（式全体が構文解析回路４０によって提供される一連の文書ノードに一致した）そのツリーのリーフはまだ達していない。式プロセッサ４２は、以前の文書ノードに一致させて、事実上、次の文書ノードと比較することが可能な解析時間の式ツリー２６内の位置を保持している、解析時間の式ツリー２６の一部を格納するために、スタック３９Ｃ乃至３９Ｆを使用することが可能である。

図示した実施形態は、ＸＰａｔｈ式に使用することが可能であり、ノード間の演算子は、親／子演算子（「／」）および子孫／祖先演算子（「／／」）を含むことが可能である。したがって、所定の式ノードは、１つ以上の／子、および、１つ以上の／／子を有することが可能である。所定の式ノードが、／子を有し、文書ノードに一致する場合、所定の式ノードを／スタック３９Ｃにプッシュすることが可能である。同様に、所定の式ノードが、／／子を有し、文書ノードに一致する場合、所定の式ノードを／／スタック３９Ｄにプッシュすることが可能である。文書ノードが属性である場合、その属性は、Ａｔｔｒスタック３９Ｆに格納することが可能である。いくつかの実施形態において、スタックポインタのトップは、イベントを処理する前にそのスタックの状態を回復できるように、そのイベントの処理の開始時に保存される。Ｐｔｒスタック３９Ｅは、ポインタを保存するために使用することが可能である。

ランタイム部分を有する式が式プロセッサ４２において部分的に評価される実施態様において、そのランタイム部分に関する情報は、ランタイム評価を実行し、式のランタイム部分を満たさない一致リスト３９Ｇ内の文書ノードを破棄することが可能であるように、一致リスト３９Ｇに保持することが可能である。したがって、一致リスト３９Ｇは、ランタイム評価を有する式の各部分で分類することが可能である。ランタイム部分が使用する同じ値を有する各文書ノードは、所与のグループ内に含むことが可能である。

図９に示すように、一致リスト３９Ｇは、式のためのノードセットを形成する階層的アレイの一群の文書ノードを含むことが可能である。解析時間の式ツリー内の各式にはそのような構造が存在し得る（すなわち、図９に示す構造は、１つの式に対応することが可能である）。主グループ（例、図９のＰＧ０およびＰＧ１）は、解析時間の式ツリー内のトップレベルのノードに対応することが可能であり、トップレベルのノードを一致させ、それ自身がノードセットのメンバーであるか、またはそのノードセットのメンバーである子孫を有する、各異なる文書ノードに対する異なる主グループが存在し得る。各サブグループレベルは、ランタイム評価（例えば、一実施態様にけるランタイム述語）に対応することが可能である。ランタイム述語に使用する値は、ポインタとともに次のレベルのグループ（または、ノードリスト自身）に保持することが可能である。式に対する一致が生じた場合、ノードは、サブグループレベルのその値に基づいてグループ内に配置される。すなわち、所与のレベルで、ノードは、その値がサブグループと一致するサブグループか、またはそのノードに対して作成される新しいサブグループに含まれる。図の例では、サブグループの第１のレベル（第１のランタイム述語に対応する）は、主グループ０（ＰＧ０）からのサブグループ０および１（ＳＧ０およびＳＧ１）を含む。同様に、主グループ１（ＰＧ１）は、第１のランタイム述語に対応するサブグループＳＧＭおよびＳＧＭ＋１を含む。第２のランタイム述語は、サブグループＳＧＯのサブグループとしてＳＧＮおよびＳＧＮ＋１を含む、第２のレベルのサブグループに対応する。この例では、式内に２つのランタイム述語があり、したがって、サブグループＳＧＭおよびＳＧＭ＋１は、それぞれ潜在的に一致する文書ノードのリスト（図示の例では、ノードＮ０、Ｎ１、およびＮ２）を示す。一実施態様において、文書ノードは、構文解析器４０によって割り当てられるそれらのプレオーダー番号によって一致リスト３９Ｇ内に表すことが可能である。

階層構造を使用することで、変換エンジン４４は、主グループを選択し、第１のランタイム述語を評価し、その第１のランタイム述語を主グループの各サブグループと比較（第１のランタイム述語を満たさないあらゆるサブグループを破棄）することが可能である。変換エンジン４４は、第２のランタイム述語を評価し、第２のランタイム述語を、破棄されていない第１のレベルのサブグループのそれぞれのサブグループと比較し、第２のランタイム述語などを満たさないサブグループを破棄することが可能である。各ランタイム述語を評価した後に構造内に残ったノードは、対応する式を満たすノードセットである。変換エンジン４４は、式に対応する命令表３０内の命令を検索し、それらの命令をノードセット内のそれぞれのノードに実行することが可能である。

一実施態様において、解析時間の式ツリー２６内の第１の式が第２の式の接尾辞である場合（すなわち、第２の式は、第１の式に含まれない接頭辞を含むが、第１の式全体は、第２の式の終わりと同じである）、独立した一致リスト３９Ｇは、第１の式に対して作成され得ない。その代わりに、第２の式に対する一致リスト３９Ｇが作成され、第１の式のトップレベルのノードのグループを含む。第１の式に対応するポインタは、第２の式に対して一致リスト３９Ｇ内の第１の式のトップレベルのノードのグループを示し得る。

一実施態様において、所与の式と一致するノードは、対応するテンプレート本体によってそれら自身を操作することが可能であるか、またはそのノードの値（例、属性値または要素の内容）を操作することが可能である。スタイルシートコンパイラ２０は、解析時間の式ツリー２６内の各リーフノードに対して、ノードまたはノードの値が必要であるかどうかを示すように構成することが可能である。いくつかの実施態様において、式プロセッサ４２は、各ノードに対して、そのノードが一致するテンプレートのリストを出力することが可能である。

式リスト表３６は、スタイルシート内に含まれる式のリストとすることが可能である。スタイルシートコンパイラは、式に式番号を割り当て、その式番号を式リストに保存することが可能である。解析時間の式ツリー内のポインタは、式リスト内のエントリを示すことが可能である。各エントリは、式番号およびグループ化が必要な式ツリーのレベルを示すグループ署名を保存することが可能である。例えば、一実施態様において、グループ署名は、ゼロはそのレベルにグループ化がないことを示し、１はグループ化を示す、式ツリーの各レベルに対するビットを含むことが可能である。いくつかの実施態様では、複数の式が所与のリーフノードに対応することが可能である。例えば、別の式との一致により削除されるコンパイル時間式は、どちらの式もリーフノードと一致することになり得る。加えて、所与のスタイルシートは、複数の場所に等価式を有することが可能である。このような実施態様では、一致する式番号のリストは、式リスト表３６の連続したエントリに保存され、そのエントリは、所与のリーフノードに対する最後の一致する式を識別することが可能な最後の式表示を含むことが可能である。一致する式が１つだけである場合、式ポインタによって示される第１のエントリ内の最後の式表示は、最後のエントリを示す状態におけるその最後のエントリ表示を有することが可能である。

テンプレートリスト表３８は、同様に、所与のリーフノードに対する複数の一致テンプレートを許可するために、テンプレート番号および最後のテンプレート表示を有するエントリを含むことが可能である。解析時間の式ツリー３６内のリーフノードは、同様に、１つ以上の一致するテンプレートのためのテンプレートリスト表に対するポインタを含むことが可能である。テンプレートリスト表３８は、テンプレート型フィールド（例、インポートしたか否か、テンプレートがモード番号を有するか否か、およびテンプレートが１つ以上のランタイム述語を有するか否か）と、モード番号、インポートされる型に対してインポートしたテンプレートからのスタイルシートを識別するインポート識別子と、テンプレートに対して実行される命令を識別する命令表３０へのテンプレート本体の命令ポインタと、１つ以上のランタイム述語を評価するために実行される命令を識別する命令表３０への述語ポインタとを、さらに含むことが可能である。

図１０は、解析時間の式ツリー２６のデータ構造の一実施態様のブロック図を示す。
図示の実施態様では、解析時間の式ツリーは、エントリ１２０のような複数のエントリを有し、各エントリが式ツリー内の式ノードに対応する、表を含むことが可能である。各式ノードは、本実施態様において、次の最大３つの異なる種類のゼロ以上の子を有することが可能である：（１）／子、文書ツリー内のノードの子である、（２）／／子、文書ツリー、文書ツリー内のノードの子孫（直接の子か、または１つ以上のノードのツリーを間接的に介する）である、または（３）属性の子（要素ノードの属性）である。加えて、所与の式ノードは、トップレベルのノードであっても、トップレベルのノード以外であってもよい。一実施態様において、解析時間の式ツリー２６は、「フォレスト」という複数のツリーを含むことが可能であり、それぞれがルートを有する。トップレベルのノードは、ツリーのうちの１つのルートであり、そのツリーはトップレベルのノードで始まる１つ以上の式を表すことが可能である。トップレベルのノードは、エントリ１２０に関して下記に詳細を説明するように、次のレベルでのノードを示すことによって、解析時間の式ツリーのデータ構造の最上位でグループ化することが可能である。

エントリ１２０のフィールドを次に説明する。エントリ１２０は、トップレベルの式ノードに使用されるトップレベルの型（ＴＬＴ）フィールドを含む。トップレベルの型は、相対的、絶対的、または祖先としてコード化することが可能である。相対的なトップレベルのノードは、文書ツリー内のコンテキストノードに関連して評価される１つ以上の式を開始する式ノードであるが、絶対的なトップレベルのノードは、文書ツリーのルートノードから評価される１つ以上の式を開始する式ノードである（すなわち、１つまたは複数の式は、／で始まり、後ろにトップレベルのノード識別子が続く）。祖先のトップレベルのノードは、コンテキストノードの祖先を参照する式の始めである（すなわち、１つまたは複数の式は、／／で始まり、後ろにトップレベルのノード識別子が続く）。

エントリ１２０は、式ノードのシリアル番号を保存するシリアル番号（Ｓ／Ｎ）フィールドを含む。Ｓ／Ｎフィールドは、エントリ１２０に保存した式ノード上の一致（等しいシリアル番号）または不一致を検出するために、構文解析回路４０によって発信されるイベント内に識別される文書ノードのシリアル番号と比較する。エントリ１２０は、エントリ１２０に保存した式ノードがリーフノードであるかどうか（すなわち、式の終わりに達したかどうか）を識別するリーフノード（ＬＮ）フィールドをさらに含む。リーフノード上の一致によって、リーフノードに対応する各式／テンプレートのための一致リスト３９Ｇ内に記録される文書ノードが生じる。ＬＮフィールドは、例えば、設定時には、式ノードがリーフノードであることを示すビットとし、クリア時には、式ノードがリーフノードではないことを示すビットとすることが可能である。他の実施態様は、ビットの設定およびクリアの意味を逆にするか、または他のコード化を使用することが可能である。

パス型のフィールドは、エントリ１２０内に保存された式ノードからパスリンクの種類を識別することが可能である（例、／、／／、またはその両方）。例えば、パス型のフィールドは、各型に対するビットを含むことが可能であり、そのパスの型がこのノードから生じることを示すように設定すること、およびそのパスの型が生じないことを示すようにクリアすることが可能である。他の実施態様は、ビットの設定およびクリアの意味を逆にするか、または他のコード化を使用することが可能である。パス型のフィールドは、「Ｐｔｒ／」、および、「Ｐｔｒ／／」フィールドを認証することが可能である。Ｐｔｒ／フィールドは、式ノードの第１の／子に対するポインタを保存することが可能である（および、／子のそれぞれは、Ｐｔｒ／ポインタによって示されるエントリから始まる解析時間の式ツリーのデータ構造の連続したエントリに分類することが可能である）。同様に、Ｐｔｒ／／フィールドは、式ノードの第１の／／子に対するポインタを保存することが可能である（および、／／子のそれぞれは、Ｐｔｒ／／ポインタによって示されるエントリから始まる、解析時間の式ツリーのデータ構造の連続したエントリに分類することが可能である）。Ｐｔｒ Ａｔｔｒフィールドは、解析時間の式ツリー内の第１の属性ノードへのポインタを保存することが可能である（および、属性のそれぞれは、Ｐｔｒ Ａｔｔｒポインタによって示されるエントリから始まる、解析時間の式ツリーのデータ構造の連続したエントリに分類することが可能である）。

ＥＯＬフィールドは、エントリ１２０が現在のツリーレベルの終わりである式ノードを保存するかどうかの表示を保存する。例えば、レベルの終わりを示す解析時間の式ツリーのデータ構造のトップから第１のエントリからの第１のエントリは最後のトップレベルのノードを示すことが可能である。各ポインタ（例、Ｐｔｒ／、Ｐｔｒ／／、またはＰｔｒ Ａｔｔｒ）から始まる、エントリは、レベルの終わりを示すＥＯＬフィールドを有するエントリが達成されるまで、ポインタを含むエントリの子である。ＥＯＬフィールドは、例えば、設定時には、式ノードがレベルの終わりであることを示すビットとし、クリア時には、式ノードがレベルの終わりではないことを示すビットとすることが可能である。他の実施態様は、ビットの設定およびクリアの意味を逆にするか、または他のコード化を使用することが可能である。

エントリ１２０は、式リスト表３６内のエントリを示す式リストポインタを保存する式リストポインタ（ＸＬＰ）フィールドと、上述のように、テンプレートリスト表３８内のエントリを示すテンプレートリストポインタを保存するテンプレートリストポインタ（ＴＬＰ）フィールドとをさらに含む。ＸＬＰおよびＴＬＰフィールドは、リーフノードに対して有効とすることが可能である。

述語には、本実施態様の解析時間で評価可能となり得るものがあり、述語型（ＰｒＴＰ）フィールドおよび述語データ（ＰｒＤＴ）フィールドを当該の述語を表すために使用することが可能である。例えば、述語タイプフィールドは、評価可能な述語、位置述語、または属性名述語を示さないようにコード化することが可能である。述語データフィールドは、式（例、位置述語のための位置番号、または属性名述語に対する属性名のための属性名またはシリアル番号）から述語データを保存することが可能である。

図１１は、典型的な式ツリー１２２のブロック図、および式ツリー１２２に対応する解析時間の式ツリーエントリ１２０Ａ乃至１２０Ｅの対応部分を示す。式ツリー１２２は、シリアル番号１０を有する式ノード１２４Ａを含み、式ノード１２４Ａは、２つの／子ノード１２４Ｂおよび１２４Ｃ（シリアル番号１５および２０）と、１つの／／子ノード１２４０（シリアル番号２５）と、属性の子１２４Ｅ（シリアル番号３０）とを有する。したがって、式ツリー１２２は、１０／１５、１０／２０、１０／／２５、および、１０／ａｔｔｒｉｂｕｔｅ：：３０という式を表す（ノード１２４Ａが相対的なトップレベルのノードであると仮定）。

エントリ１２０Ａ乃至１２０Ｅは、解析時間の式ツリーエントリのＳ／Ｎ、ＬＮ、ＥＯＬ、Ｐｔｒ／、Ｐｔｒ／／、およびＰｔｒ Ａｔｔｒフィールドを示す。エントリ１２０Ａは、ノード１２４Ａに対応するので、シリアル番号１０を含む。ノード１２４Ａはリーフノードではないので、ＬＮフィールドはエントリ１２０Ａにおいてゼロである。この例に関して、ノード１２４Ａはツリー１２２内のそのレベルでの唯一のノードであるので、ＥＯＬフィールドは１となる。エントリ１２０ＡのＰｔｒ／フィールドは、エントリ１２０Ｂ（第１の／子）を示す。エントリ１２０ＡのＰｔｒ／／フィールドは、エントリ１２０Ｄを示し、エントリ１２０ＡのＰｔｒ Ａｔｔｒフィールドは、エントリ１２０Ｅを示す。

エントリ１２０Ｂは、Ｓ／Ｎフィールド内に１５を含み、ノード１２４Ｂが式ツリー１２２のリーフノードであるので、ＬＮフィールドは１となる。しかし、このレベルには別の／子があるので、ＥＯＬフィールドはゼロとなる。エントリ１２０ＢのＰｔｒ／、Ｐｔｒ／／、およびＰｔｒ Ａｔｔｒフィールドは、これがリーフノードであるので、ヌルである。エントリ１２０Ｃは、Ｓ／Ｎフィールド内に２０を含み、ノード１２４Ｃが式ツリー１２２のリーフノードであるので、ＬＮフィールドは１となる。このレベルではノード１２４Ｃが最後の／子であるので、ＥＯＬフィールドも１となる。また、エントリ１２０Ｃがリーフノードであるので、エントリ１２０ＣのＰｔｒ／、Ｐｔｒ／／、およびＰｔｒ Ａｔｔｒフィールドはヌルとなる。

エントリ１２０Ｄは、Ｓ／Ｎフィールド内に２５を含み、ノード１２４Ｄが式ツリー１２２のリーフノードであるので、ＬＮフィールドは１となる。このレベルではノード１２４Ｄが最後の／／子であるので、ＥＯＬフィールドも１となる。エントリ１２０Ｄがリーフノードであるので、エントリ１２０ＤのＰｔｒ／、Ｐｔｒ／／、およびＰｔｒ Ａｔｔｒフィールドはヌルとなる。

エントリ１２０Ｅは、Ｓ／Ｎフィールド内に２５を含み、ノード１２４Ｅが式ツリー１２２のリーフノードであるので、ＬＮフィールドは１となる。このレベルではノード１２４Ｅが最後の属性の子であるので、ＥＯＬフィールドは１となる。エントリ１２０Ｅがリーフノードであるので、エントリ１２０ＥのＰｔｒ／、Ｐｔｒ／／、およびＰｔｒ Ａｔｔｒフィールドはヌルとなる。

図１２Ａおよび１２Ｂ、１３、１４Ａおよび１４Ｂ、ならびに１５は、構文解析回路４０が生成し得る各々のイベントのための式プロセッサ４２の一実施態様の演算を示すフローチャートである。各イベントは、検出された文書ノードのシリアル番号（および、いくつかの実施態様では、文書ノードのプレオーダー番号）を含むことが可能である。式プロセッサ４２は、ハードウェア内に実装することが可能であるので、そのフローチャートは、種々のブロックをハードウェア内で並行して、または必要に応じてハードウェア内でパイプライン化して実行することが可能であっても、ハードウェアの演算を表すことが可能である。フローチャートは、概して一致する文書ノードおよび式ノードを参照することが可能である。上述のように、このような一致は、文書ノードおよび式ノードの一致するシリアル番号を含むことが可能である。さらに、そのフローチャートは、一致リストに出力するノードを参照することが可能である。上述のように、ノードは、いくつかの実施態様では、プレオーダー番号によって一致リスト内に表すことが可能である。

図１２Ａおよび１２Ｂは、要素開始イベントに応えた、式プロセッサ４２の一実施態様の演算を示す。要素開始イベントは、文書内の要素開始タグの検出に応えて発信することが可能である。

式プロセッサ４２は、／スタック３９Ｃに保存することが可能なあらゆる属性式ノードをポップすることが可能であり、ポインタスタック３９Ｅへの／スタックポインタをプッシュすることが可能である（ブロック１３０）。新しい要素が始まっているので、あらゆる属性式ノード上の／スタックは一致されず、したがって、必要とされない。要素開始イベントによって識別された要素（図１２Ａおよび１２Ｂの記述では、より簡潔に要素と称する）が文書のルートノードである場合、更なる処理は行われない（判断ブロック１３２、「ｙｅｓ」レグ）。ルートノードは、解析時間の式ツリー２６内のノードのいずれにも一致することができず、あらゆるトップレベルのノードをルートの子に一致することが可能である。要素がルートノードではないが（判断ブロック１３２、「ｎｏ」レグ）、その要素の親がルートノードである場合（判断ブロック１３４、「ｙｅｓ」レグ）、式プロセッサ４２は、ルートノードの子に対する絶対的なトップレベルのノードに対してであっても一致が検出され得るので、解析時間の式ツリー２６内の各トップレベルの式ノードを検査することが可能である（ブロック１３６）。一方で、要素ノードの親要素がルートノードである場合（判断ブロック１３４、「ｎｏ」レグ）、式プロセッサ４２は、ルートノードの子ではないノードに対する絶対的なトップレベルのノードに対して一致が検出されないので、解析時間の式ツリー２６内の各相対的なトップレベルの式ノードを検査することが可能である（ブロック１３８）。

トップレベルのノードのいずれかに対して一致が検出されない場合（判断ブロック１４０、「ｎｏ」レグ）、フローチャートは、図１２の参照Ａを継続する。一致が検出され（判断ブロック１４０、「ｙｅｓ」レグ）、かつ式ノードがリーフノードである場合（判断ブロック１４２、「ｙｅｓ」レグ）、解析時間の式ツリー２６の式ノードのエントリ内のＸＬＰおよびＴＬＰポインタによって示される１つもしくは複数の式および／または１つもしくは複数のテンプレートに対応する一致リストに、要素ノードが出力される（ブロック１４４）。一致した式ノードが、リーフノードでない場合（判断ブロック１４２、「ｎｏ」レグ）、式プロセッサ４２は、一致した式ノードが／または／／のいずれかの子を有するかどうかを判断し（それぞれ、判断ブロック１４６および１４８）、一致した式ノードが／または／／のいずれかの子を有する場合（それぞれ、判断ブロック１５０および１５２）、それぞれ／スタック３９Ｃおよび／または／／スタック３９Ｄ上の一致した式をプッシュする。加えて、／スタック３９Ｃおよび／／スタック３９Ｄは、（解析時間の式ツリーエントリ内のＰｒＴＰおよびＰｒＤＴフィールドを経て示される）解析時間述語の一致の管理に使用する評価フィールドを含むことが可能である。（ＰｒＴＰフィールドによって示されるような）解析時間述語がある場合、評価フィールドを０に設定することが可能である。それ以外ならば、評価フィールドを２に設定することが可能である。フローチャートは、図１２Ｂの参照Ａを継続する。

図１２Ｂの参照Ａで、フローチャートは、そのフローチャートを介したパスが、この要素に対する／スタック３９Ｃの第１の検査であるか否かによって別々に演算する（判断ブロック１５４）。これが、この要素に対する／スタック３９Ｃの第１の検査である場合（判断ブロック１５４、「ｙｅｓ」レグ）、式プロセッサ４２は、その要素の親が／スタック３９Ｃで一致するかどうかを判断する（判断ブロック１５６）。要素の親が／スタック３９Ｃで一致する場合（判断ブロック１５６、「ｙｅｓ」レグ）、次いで一致した式ノードの／子のうちの１つをその要素に一致することが可能である。式プロセッサ４２は、一致した式ノードの第１の／子を、一致した式ノードの解析時間の式ツリーエントリ内のＰｔｒ／が示すように取り込むことが可能であり（ブロック１５８）、／子上に一致が検出されるかどうかを判断するために（および、一致が検出された場合に図１２Ａのブロック１４２乃至１５２に示すように処理するために）図１２Ａの参照Ｂに戻ることが可能である。要素の親が／スタックで一致しない場合（判断ブロック１５６、「ｎｏ」レグ）、式プロセッサ４２は、／／スタック３９Ｄを検査することが可能である（ブロック１６０）。同様に、このパスが、この要素に対する第１の検査でなく（判断ブロック１５４、「ｎｏ」レグ）、かつ最後の／子が、／スタック内の一致した式ノードから取り込まれている場合（判断ブロック１６２、「ｙｅｓ」レグ）、式プロセッサ４２は、／／スタック３９Ｄを検査することが可能である（ブロック１６０）。このパスが、この要素に対する第１の検査でなく（判断ブロック１５４、「ｎｏ」レグ）、かつ最後の／子が、／スタック内の一致した式ノードから取り込まれていない場合（判断ブロック１６２、「Ｎｏ」レグ）、式プロセッサ４２は、／スタック内の一致した式ノードの次の／子を取り込むことが可能であり、そのフローチャートは、その要素に対する一致が検出されるかどうかを判断するために、図１２Ａの参照Ｂを継続することが可能である。したがって、ブロック１５４乃至１６４の演算（および、図１２Ａ内のブロック１４０乃至１５２への回帰）を介して、要素の親に一致する式ノードの各／子は、その要素によって一致を検索することが可能である。

いくつかの実施態様において、ある要素の親要素を式プロセッサ４２で保持することが可能である（例、式プロセッサ４２は、その要素に対して要素開始イベントは生じているが要素終了イベントは生じていない、多くの要素を保持することが可能である）。この代わりに、他の実施態様では、親要素を構文解析回路４０で保持し、要素開始イベント内に含むことが可能である。

本実施態様において、／／スタック３９Ｄの検索は、／スタック３９Ｃの検索とは幾分異なる処理を伴うことがある。ノードは、／／スタック３９Ｄ上のあらゆる式ノードの／／子に一致することが可能である（これは、／／演算子が式ノードのいずれの子孫を選択し、スタック３９Ｄ上のエントリが、要素開始イベント内で識別される要素の親または祖先である以前の要素と一致させているためである）。したがって、図１２Ｂのフローチャートは、／／スタック３９Ｄ上の各有効なエントリの／／子の検索を示す。

／／スタック３９Ｄが、有効なエントリ（または、それ以上有効なエントリ）を持たない場合（判断ブロック１６６「ｎｏ」レグ）、／／スタックの処理を終了し、要素開始イベントの処理も終了する。／／スタック３９Ｄが有効なエントリを有する場合（判断ブロック１６６「ｙｅｓ」レグ）、式プロセッサ４２は、エントリ内のＰｔｒ／／が示すように、そのエントリの第１の／／子を取り込む（ブロック１６８）。式プロセッサ４２は、一致が検出されるかどうかを判断するために、／／子を比較する（判断ブロック１７０）。一致が検出され（判断ブロック１７０「ｙｅｓ」レグ）、かつ／／子ノードがリーフノードである場合（判断ブロック１７２「ｙｅｓ」レグ）、ブロック１４４と同様に、その要素が一致リストに出力される（ブロック１７４）。ブロック１４６乃至１５２と同様に、／／子ノードがリーフノードではなく、かつ一致が検出された場合、式プロセッサ４２は、／／子ノードが／または／／子自身のいずれかを有するどうかを判断し（それぞれ、判断ブロック１７６および１７８）、／／子ノードが／または／／子のいずれかを有する場合（それぞれ、ブロック１８０および１８２）、それぞれ／スタック３９Ｃおよび／または／／スタック３９Ｄ上の／／子ノードをプッシュする。加えて、／スタック３９Ｃまたは／／スタック３９Ｄ内の評価フィールドは、ブロック１４６乃至１５２に関して上述のように設定することが可能である。

現在の／／スタックの最後の子が処理されていない場合（判断ブロック１８４「ｎｏ」レグ）、式プロセッサ４２は、現在の／／スタックエントリの次の／／子を取り込み（ブロック１８６）、フローチャートは次の／／子に対する判断ブロック１７０を継続する。最後の子が処理された場合（判断ブロック１８４、「ｙｅｓ」レグ）、式プロセッサ４２は、／／スタック３９Ｄ内の次のエントリに進み（ブロック１８８）、フローチャートは次の／／スタックエントリに対する判断ブロック１６６を継続する。

図１３は、要素終了イベントに応えた、式プロセッサ４２の一実施態様の演算を示す。要素終了イベントは、文書内の要素終了タグの検出に応えて、構文解析回路４０によって発信することが可能である。

要素終了イベントが、文書のルートノードに対するものである場合（判断ブロック１９０、「ｙｅｓ」レグ）、その文書は完了している（ブロック１９２）。式プロセッサ４２は、スタック３９Ｃ乃至３９Ｆをクリアすることが可能である。要素終了イベントが、文書のルートノードに対するものでない場合（判断ブロック１９０、「ｎｏ」レグ）、式プロセッサ４２は、終了要素に対応する／および／／スタックエントリをポップすることが可能である（ブロック１９４）。要素はクローズされているので、要素の全ての子はすでに解析されている。したがって、その要素に対応する／および／／スタックエントリ内のいずれのエントリ（すなわち、その要素のシリアル番号を有するエントリ）も、引き続き検出されるノードと一致させることができない。

図１４Ａおよび１４Ｂは、属性名イベントに応えた、式プロセッサ４２の一実施態様の演算を示す。属性名イベントは、文書の要素開始タグ内での属性名の検出に応えて、構文解析回路４０によって発信することが可能である。属性名は、そのシリアル番号で表すことが可能である。

式プロセッサ４２は、Ａｔｔｒスタック３９Ｆに、属性名（すなわち、そのシリアル番号）をプッシュすることができる。Ａｔｔｒスタック３９Ｆは、要素クローズコマンド処理（図１５）のための属性名を蓄積する。属性の親ノードがルートノードである場合（判断ブロック２０２、「ｙｅｓ」レグ）、（ルートノードは属性を持たないので）実行する更なる処理はない。一方で、属性の親ノードがルートノードでない場合（判断ブロック２０２、「ｎｏ」レグ）、式プロセッサ４２は継続する。

式プロセッサ４２は、属性名に対する一致（また、シリアル番号による一致）のための相対的なトップレベルの式ノードのそれぞれを検査することが可能である（ブロック２０４）。所与の相対的なトップレベルの式ノードとの一致がない場合（判断ブロック２０６、「ｎｏ」レグ）、トップレベルの式ノードが空になる（判断ブロック２０８、「ｎｏ」レグ）まで、処理は、次の相対的なトップレベルの式ノードを継続する。トップレベルの式ノードが空になると（判断ブロック２０８、「ｙｅｓ」レグ）、処理は図１４Ｂの参照Ｃを継続する。

一致が検出され（判断ブロック２０６、「ｙｅｓ」レグ）、かつノードがリーフノードである場合（判断ブロック２１０、「ｙｅｓ」レグ）、属性ノードが一致リスト３９Ｇに出力される（ブロック２１０）。式プロセッサ４２は、一致した式ノードが／または／／のいずれかの子を有するかどうかを判断し（それぞれ、判断ブロック２１２および２１４）、一致した式ノードが／または／／のいずれかの子を有する場合（それぞれ、判断ブロック２１６および２１８）、それぞれ／スタック３９Ｃおよび／または／／スタック３９Ｄ上の一致した式をプッシュする。

図１４Ｂの参照Ｃを継続し、式プロセッサ４２は、／スタック３９Ｃおよび／／スタック３９Ｄ内の属性名の親ノードの一致に対する検査を行う（判断ブロック２２０）。一致が検出されない場合（判断ブロック２２０、「ｎｏ」レグ）、属性名イベントの処理を終了する。一致が検出された場合、式プロセッサ４２は、その一致する式ノードが属性名述語（または、一実施態様における予約したコード化）を有するかどうかを判断するために一致する式ノードの式ツリーのＰｒＴＰフィールドを検査する。一致する式ノードが属性名述語を有し、かつ評価フィールドの最下位ビットがクリアである場合（すなわち、評価フィールドが、０か２のいずれかである場合）（判断ブロック２２２、「ｙｅｓ」レグ）、式プロセッサ４２は、その属性名を一致する式ノードの式ツリーエントリのＰｒＤＴフィールドを比較する。属性が一致しない場合（判断ブロック２２４、「ｎｏ」レグ）、式プロセッサ４２は、もしあれば、／スタック３９Ｃおよび／／スタック３９Ｄ内の次の一致するノードを継続する。一実施態様において、属性が一致する場合（判断ブロック２２４、「ｙｅｓ」レグ）、式プロセッサ４２は、ＰｒＴＰフィールドが予約したコード化を有するかどうかを検査する（判断ブロック２２６）。他の実施態様では、判断ブロック２２６を削除することが可能である。ＰｒＴＰフィールドが予約したコード化を有する場合（判断ブロック２２６、「ｙｅｓ」レグ）、式プロセッサ４２は、／スタック３９Ｃおよび／／スタック３９Ｄ内の一致するノードに対する評価フィールドのうちの１つのビットを設定することが可能である（ブロック２２８）。ＰｒＴＰフィールドが予約したコード化を持たない場合（判断ブロック２２６、「ｎｏ」レグ）、式プロセッサ４２は、評価フィールドを３に設定することが可能である（ブロック２３０）。いずれの場合も、属性名イベントの処理を終了することが可能である。一部の実施態様において、式プロセッサ４２が属性値の一致を試みる場合、予約したコード化を使用することが可能である。他の実施態様では当該の一致を行わない場合があり、そのような実施態様ではブロック２２６および２２８を削除することが可能である。

判断ブロック２２２、「ｎｏ」レグが先行する場合、式プロセッサ４２は、ＰｒＴＰフィールドが解析時間述語がないこと、または１つの位置述語がないことを示すかどうかを判断する（判断ブロック２３２）。すなわち、式プロセッサ４２は、ＰｒＴＰフィールドが属性名を示すか否かを判断する。ＰｒＴＰフィールドが、無しまたは位置にコード化されない場合（判断ブロック２３２、「ｎｏ」レグ）、式プロセッサ４２は、次の一致する／または／／スタックに移動するか、またはそれ以上一致するエントリがなければ（それぞれ、判断ブロック２３４、「ｙｅｓ」および「ｎｏ」レグ）処理を終了する。ＰｒＴＰフィールドが、無しまたは位置にコード化される場合、式プロセッサ４２は、式ノードが属性の子を有するかどうかを判断する（判断ブロック２３６）。式ノードが属性の子を持たない場合（判断ブロック２３６、「ｎｏ」レグ）、式プロセッサ４２は、式プロセッサ４２は、次の一致する／または／／スタックに移動するか、またはそれ以上一致するエントリがなければ（それぞれ、判断ブロック２３４、「ｙｅｓ」および「ｎｏ」レグ）処理を終了する。式ノードが属性の子を有する場合（判断ブロック２３６、「ｙｅｓ」レグ）、式プロセッサ４２は、属性の子を取り込み（ブロック２３８）、その属性の子を属性名（シリアル番号）と比較する。属性の子が属性名と一致し（判断ブロック２４０、「ｙｅｓ」レグ）、かつ属性の子ノードがリーフノードである場合（判断ブロック２４２、「ｙｅｓ」レグ）、式プロセッサ４２は、属性名ノードを一致リスト３９Ｇに出力する。属性の一致が検出されるか否かに関わらず、更なる属性の子ノードがある場合（すなわち、属性の子ノードのＥＯＬ表示は、レベルの終わりを示さない場合）、次いで式プロセッサ４２は、属性の子を取り込み（ブロック２３８）、ブロック２４０乃至２４４を継続する（判断ブロック２４６、「ｙｅｓ」レグ）。それ以外ならば（判断ブロック２４６、「ｎｏ」レグ）、式プロセッサ４２は、次の一致する／または／／スタックに移動するか、またはそれ以上一致するエントリがなければ（それぞれ、判断ブロック２３４、「ｙｅｓ」および「ｎｏ」レグ）処理を終了する。

図１５は、要素クローズイベントに応えた、式プロセッサ４２の一実施態様の演算を示す。要素クローズイベントは、要素開始タグの検出に応えて構文解析回路４０によって発信することが可能である（したがって、その要素の全ての属性が、この要素に対する文書内に発見される）。要素クローズイベントに応えて、式プロセッサ４２は、／スタック３９Ｃ内のあらゆる一致するノードの属性の子に対して構文解析回路４０が以前に識別した属性名を検査する。

クローズする要素の親ノードがルートノードである場合（判断ブロック２５０、「ｙｅｓ」レグ）、更なる処理は行われない。クローズする要素の親ノードがルートノードでない場合（判断ブロック２５０、「ｎｏ」レグ）、式プロセッサは、属性名を示すＰｒＴＰフィールドを有するエントリのための／スタック３９Ｃを検査する。一致するエントリが見つからない場合（判断ブロック２５４、「ｎｏ」レグ）、処理を終了する。一致するエントリが見つかり（判断ブロック２５４、「ｙｅｓ」レグ）、かつその一致するエントリの評価フィールドが３でない場合（判断ブロック２５６、「ｎｏ」レグ）も、処理を終了する。一致するエントリが見つかり（判断ブロック２５４、「ｙｅｓ」レグ）、かつその一致するエントリの評価フィールドが３である場合（判断ブロック２５６、「ｙｅｓ」レグ）、ブロック２５８で処理を継続する。

式プロセッサ４２は、一致する式ノードの属性の子を取り込む（ブロック２５８）。加えて、式プロセッサ４２は、属性スタック３９Ｆのための属性名を取り込む（ブロック２６０）。式プロセッサ４２は、その属性名を比較する。一致が検出された場合（判断ブロック２６２、「ｙｅｓ」レグ）、属性ノードが一致リスト３９Ｇに出力される（ブロック２６４）。いずれの場合も、属性スタック３９Ｆの終わりに達してない場合（判断ブロック２６６、「ｎｏ」レグ）、属性スタック３９Ｆ内の次の属性に対してブロック２６０で処理を継続する。属性スタック３９Ｆの終わりに達していて（判断ブロック２６６、「ｙｅｓ」レグ）、かつ一致する式ノードの最後の属性の子が処理されていない場合（判断ブロック２６８、「ｎｏ」レグ）、一致する式ノードの次の属性に対してブロック２５３で処理を継続する。属性スタック３９Ｆの終わりに達していて（判断ブロック２６６、「ｙｅｓ」レグ）、かつ一致する式ノードの最後の属性の子が処理されている場合（判断ブロック２６８、「ｙｅｓ」レグ）、要素クローズイベントの処理を終了する。

図１２Ａおよび１２Ｂ、１３、１４Ａおよび１４Ｂ、および１５の上記説明における種々の点において、フローチャートは一致リスト３９Ｇへのノードの出力を参照することに留意されたい。ノードを出力する演算は、解析時間の式ツリー２６内の一致するリーフノードに対応する式／テンプレートの１つまたは複数のノードセット構造へのノードの挿入を含むことが可能である。ノードを出力する演算は、解析時間の式ツリー２６のリーフノード内のテンプレートリストポインタが示すように、テンプレート番号（またはリスト）を有する構文解析回路４０が生成するスケルトンツリーの更新をさらに含むことが可能である。

上述の種々の点において、式ノードは、／スタック３９Ｃまたは／／スタック３９Ｄ上にプッシュされるとみなされることに留意されたい。スタック３９Ｃおよびスタック３９Ｄへの式ノードのプッシュは、スタック（または、式の一致に使用される式ツリーエントリの一部）へのノードの式ツリーエントリ１２０のプッシュを含むことが可能である。必要に応じて、更なる情報をエントリ内に含むことが可能である（例、評価フィールドのような一致の進行を示す種々のステータス変数）。

図１６は、文書に対する解析した内容表３９Ｂおよび一致リスト３９Ｇの受信に応えた変換エンジン４４の一実施態様の演算を示すフローチャートを示す。変換エンジン４４は、ハードウェア内に実装することが可能であるので、そのフローチャートは、種々のブロックをハードウェア内で並行して、または必要に応じてハードウェア内でパイプライン化して実行することが可能であるが、ハードウェアの演算を表すことが可能である。

各式に関して、変換エンジン４４は、式のあらゆるランタイム部分を評価することが可能である（例、一実施例では、ランタイム述語、ブロック２７０）。例えば、一実施態様において、テンプレートリスト表３８内のポインタは、ランタイム述語を評価するために変換エンジン４４が実行する、命令表３０内の命令を示すことが可能である。他の実施態様では、ランタイム述語は、他の形態（例、解析時間の式ツリー２６と同様のランタイム式ツリー）で識別することが可能である。ランタイム述語の評価に応えて、変換エンジン４４は、ランタイム式を満たすノードセット構造からグループを選択することが可能である（ブロック２７２）。変換エンジン４４は、式（例、テンプレートリスト表３８内のテンプレート本体のポインタによって命令をおくことが可能である）に対応する命令表３０からの命令を実行することが可能である。その命令は、選択したグループ内のそれぞれのノード上で実行することが可能であり（ブロック２７４）、その結果を出力生成器４６に出力することが可能である（ブロック２７６）。

一実施態様において、変換エンジン４４は、スタイルシートコンパイラ２０が生成する命令を実行するように設計された、複数のハードウェアプロセッサを含むことが可能である。すなわち、プロセッサの命令セットを定義することが可能で、スタイルシートコンパイラ２０は命令セット内に命令を生成することが可能である。いくつかの実施態様において、その命令セットは、ＸＳＬＴ言語への拡張機能に適応するように設計される。変換エンジン４４は、例えば、特定のノード上で実行する命令をプロセッサのうちの１つに送ることが可能であり、結果を生成するためにそのノード上でその命令を実行することが可能である。

一実施態様において、ランタイム述語を評価するために実行する命令は、類似した述語（例、共通の接頭辞部分を有する述語）を同時に評価し、その述語を評価するためのノードの取り込みを最小限に抑えるように命令を出すことが可能である。例えば、一致するノードの後に続くノードに基づく述語は、互いにグループ化し、同時に評価することが可能である。

場合によっては、スタイルシート内の変数および／またはパラメータは、式を使用して宣言することが可能であり、その後の命令は、その変数／パラメータを使用することが可能である。変数／パラメータを定義する式は、解析時間の式ツリー２６内に含むことが可能なので、その式を式プロセッサ４２によって評価する（または、その式がランタイム述語を含む場合は、部分的に評価する）ことが可能である。ランタイム述語は、他のランタイム述語と同様に評価されることが可能である。いくつかの実施態様において、スタイルシートコンパイラ２０は、変数／パラメータを評価する前に、変換エンジン４４によって命令が試みられる可能性を減じるために、その変数／パラメータを使用する命令のかなり前にその変数／パラメータを評価するための命令の指示を試みることが可能である。変換エンジン４４は、例えば、変数／パラメータを使用し、変数／パラメータを評価する前に試みられる命令をおくことが可能な待ちキューを含むことが可能であり、その命令は、変数／パラメータが評価されるまで、やり直し、および待ちキュー内への置き換えが可能である。他の実施態様では、スタイルシートコンパイラ２０は、種々の変数／パラメータに依存する命令を明示的に識別することが可能であり、変換エンジン４４は、各命令の実行を試みる前に、当該の依存関係を検査することが可能である。さらに他の実施態様では、スタイルシートコンパイラ２０は、その依存関係が満たされる前に所与の命令が実行されないようにするために、その命令を再配置することが可能である。例えば、スタイルシートコンパイラ２０は、その命令の位相的にソートしたデータの依存関係グラフを構成することが可能であり、所与のレベルで各命令にグループ番号を割り当てることが可能である。変換エンジン４４は、以前のグループの全ての命令が実行のために選択されるまで、実行のための所与のグループ番号を有する所与の命令を選択することができない場合もある。

上述の種々のデータ構造への（および、種々のデータ構造内の）ポインタは、（示されるデータのアドレスを単独で指定する）全ポインタとするか、または必要に応じて、示されるデータを含む構造の基底アドレスからのオフセットとすることが可能である。

（式プロセッサ、更なる実施態様）
次に、式プロセッサ４２の別の実施態様を、図１７乃至２４Ｂに関して説明する。本実施態様は、幾分異なる解析時間の式ツリー構造を使用することが可能であり、更なる式を処理することが可能である。他の実施態様では、他のマークアップ言語を用いることが可能であるが、本実施例ではＸＭＬのノード構造を使用する。図１７乃至２４Ｂに示される実施態様は、あらゆるノード（例、要素、属性、処理命令、コメント、テキスト等）に適合することが可能であり、文書オーダーに見られるノードを使用して評価することが可能な述語を含む。フローチャートは、概して一致する文書ノードおよび式ノードを参照することが可能である。上述のように、当該の一致は、文書ノードと式ノードとの一致するシリアル番号を含むことが可能である。さらに、フローチャートは、一致リストに出力するノードを参照することが可能である。上述のように、一部の実施態様では、プレオーダー番号によってノードを一致リスト内に表すことが可能である。

図１７は、解析時間の式ツリー２６の別の実施態様を示すブロック図であり、エントリ３００を含む。エントリ３００は、図内のスペースの理由から図１７において２行で示す。エントリ３００は、解析時間の式ツリー２６内の１つの式ノードに対応することが可能であるので、各式ノードに対するエントリ３００に類似したエントリが存在し得る。

エントリ３００は、トップレベルの型（ＴＬＴ）フィールドと、シリアル番号（Ｓ／Ｎ）フィールドと、リーフノード（ＬＮ）フィールドと、レベルの終わり（ＥＯＬ）フィールドと、式リストポインタ（ＸＬＰ）フィールドと、テンプレートリストポインタ（ＴＬＰ）フィールドと、述語型（ＰｒＴＰ）フィールドと、図１０に示すエントリ１２０に類似した述語データ（ＰｒＤＴ）フィールドとを含む。加えて、エントリ３００は、ノード型（ＮＴ）フィールドと、子記述子（ＣＤ）フィールドと、Ｐｔｒ／フィールドと、Ｐｔｒ／／フィールドと、Ｐｔｒ／Ａｔｔｒフィールドと、Ｐｔｒ／／Ａｔｔｒフィールドと、Ｐｔｒ／ＰＩフィールドと、Ｐｔｒ／／ＰＩフィールドとを含むことが可能である。図１７に示されるフィールドの順序は、メモリ内のフィールドの順序に対応していない場合があることに留意されたい。むしろ、エントリ３００のフィールドは、単に解析時間の式ツリーエントリの一実施態様の内容を説明するように示されたものである。

エントリ３００に対応する式ノードは、さまざまな子の式ノードを有することが可能である。エントリ３００のＣＤフィールドは、その式ノードが、どの型の子の式ノードを有するかの表示を保存することが可能である。例えば、図１８は、ＣＤフィールドのコード化の一実施態様を示している表３０２を含む。図１８に示す実施態様において、ＣＤフィールドは、各子ノードの型およびその型の／または／／子のためのビットを含むことが可能である。例えば、図示した実施態様には６つの子ノード（要素、属性、テキスト、コメント、処理命令（ＰＩ）、および定数を有する処理命令（ＰＩ−ｌｉｔｅｒａｌ））がある。各型は、式ノードの／子または／／子のいずれかとすることが可能なので、本実施態様では、ＣＤフィールドは１２ビットより成る。対応するビットが設定されると、次いで式ノードは、所与の型（および、／または／／）の少なくとも１つの子式ノードを有する。例えば、式ノードが少なくとも１つの／子要素ノードを有する場合、ＣＤフィールドのビット１１を設定することが可能である。式ノードが少なくとも１つの／／子要素ノードを含む場合、ＣＤフィールドのビット１０を設定することが可能である。他の実施態様は、ビットの設定およびクリア状態の意味を逆にするか、またはいずれの所望のコード化を使用することが可能である。ＣＤフィールドは、所与の式ノードが、式の一致処理の一部として、所与の型の子を有するかどうかを判断するために使用することが可能である。

ＮＴフィールドは、エントリ３００に対応する式ノードの型を識別するノード型を保存することが可能である。例えば、図１８は、ＮＴフィールドのための例示的なコード化を示す表３０４を含む。例示した実施態様において、ＮＴフィールドは、３ビットのコード化を含むことが可能であり、その二進値を表３０４の左欄に示す。右欄は、本実施態様のための種々のノード型（例、要素、属性、テキスト、コメント、ＰＩ、ノード、およびターゲットを有するＰＩ）をリストしたものである。他の実施態様は、いずれの他のコード化を使用することが可能であり、示される型のあらゆるサブセットまたはスーパーセットをサポートすることが可能である。

図示の実施態様では、エントリ３００は、子ノードエントリに対して解析時間の式ツリー２６内に６のポインタを含むことが可能である。Ｐｔｒ／Ａｔｔｒポインタは、式ノードの／子である属性ノードを示すことが可能である。／属性の子ノードは、Ｐｔｒ／Ａｔｔｒポインタによって示されるエントリから始まる解析時間の式ツリー２６内にグループ化することが可能である。Ｐｔｒ／／Ａｔｔｒポインタは、式ノードの／／子である属性ノードを示すことが可能である。／／属性の子ノードは、Ｐｔｒ／／Ａｔｔｒポインタによって示されるエントリから始まる解析時間の式ツリー２６内にグループ化することが可能である。Ｐｔｒ／ＰＩポインタは、式ノードの／子であるＰＩノードを示すことが可能である。／ＰＩの子ノードは、Ｐｔｒ／ＰＩポインタによって示されるエントリから始まる解析時間の式ツリー２６内にグループ化することが可能である。Ｐｔｒ／／ＰＩポインタは、式ノードの／／子である属性ノードを示すことが可能である。／／ＰＩの子ノードは、Ｐｔｒ／／ＰＩポインタによって示されるエントリから始まる解析時間の式ツリー２６内にグループ化することが可能である。式ノードの他の／子ノード（すなわち、属性またはＰＩノードでない）は、（式ノードの／子に対する）Ｐｔｒ／ポインタおよび（式ノードの／／子に対する）Ｐｔｒ／／ポインタで、解析時間の式ツリー２６内にグループ化される。

図示した実施態様は、属性の子、処理命令の子、および残りの子を置くために独立した一連のポインタを提供するが、他の実施態様では、異なる一連のポインタを実装することが可能である。例えば、一実施態様は、一連のポインタ、すなわち、全ての／子および全ての／／子をそれぞれ置くための／ポインタおよび／／ポインタ、を１つだけ含むことが可能である。他の実施態様は、各ノード型に対して／および／／ポインタを実装するか、または必要に応じて他の形態のポインタでノードをグループ化することが可能である。

ＰｒＴＰフィールドは、本実施態様では、図１８の表３０６に示すように、コード化を有することが可能である。本実施態様において、述語型には、述語なし（または、より詳しくは、解析時間の評価可能な述語なし）、位置述語、要素の子の述語、属性名述語、名前述語を有するＰＩノードテスト、ノードテスト述語、コメントノードテスト述語、ＰＩノードテスト述語、およびテキストノード述語が挙げられる。ノードテスト述語は、式ノードの子または子孫として（いずれの型の）ノードがあることをシンプルにテストすることが可能である。コメントノードテスト、ＰＩノードテスト（名前なし）、およびテキストノードテスト述語は、所与の型のノードの存在をテストすることが可能である。名前によるＰＩノードテストは、名前を有するＰＩターゲットを伴うＰＩノードの存在をテストすることが可能である。他の実施態様は、いずれの他のコード化を使用することが可能であり、示される述語型のあらゆるサブセットまたはスーパーセットをサポートすることが可能である。

いくつかの実施態様において、式リスト表３６およびテンプレートリスト表３８は、図９に関する上述のものと同様の構造を有することが可能である。加えて、一実施態様では、各テンプレートリスト表のエントリは、（該当する場合）どの子ノードがそのテンプレートリスト表のエントリに対応するテンプレート一致式内で参照されるのかを識別するノードＩＤを含むことが可能である。例えば、テンプレートリスト表３８は、所与の１つまたは複数の式に一致する最後の要素に基づいて構成することが可能である（すなわち、その表は、式がその要素の非要素の子を含んでいても、その要素と一致する、最後の要素のための式のリストを含むことが可能である）。属性、テキスト、コメント、またはその要素ノードのための式リスト内の一部の式に含むことが可能な処理命令の子ノードを、ノードＩＤで識別することが可能である。ノードＩＤは、子ノードの型を識別することが可能である。加えて、属性および処理命令に関して、ノードＩＤは、ノード内の他の属性および処理命令のそれぞれに関する位置を識別することが可能である。ゼロのノードＩＤは、対応する式のための要素ノードの子がないことを示すことが可能である。

本実施態様では、構文解析回路４０は、式プロセッサ４２のための次のようなイベントを生成することができる：トップレベルの要素開始イベント、要素開始イベント、要素終了イベント、属性名イベント、テキストイベント、コメントイベント、処理命令イベント、および構成イベント。構成イベントは、式プロセッサ４２のための所望のスタイルシート／文書コンテキストを確立するために生成することが可能である。

トップレベルの要素開始イベントは、ルートの子である要素の開始を識別することが可能である。ルート以外の他の要素の子である要素の開始は、要素開始イベントによって識別される。例えば、ＸＭＬを用いた実施態様において、要素開始イベントは、要素開始タグを検出したことを示すことが可能である。各イベントは、要素のシリアル番号を含むことが可能である。いくつかの実施態様において、イベントは、要素および／または要素のプレオーダー番号の子の位置を含むことも可能である。これらのイベントによって、式プロセッサ４２は、解析時間の式ツリー２６内の式への要素の一致を試みることが可能となる。

要素終了イベントは、（例えば、ＸＭＬを用いた実施態様において要素終了タグが検出されている）要素の終わりの検出に応えて生成することが可能である。式プロセッサ４２は、その要素終了イベントに応えた要素によって一致したあらゆる式の分岐を消去することが可能である。

属性名イベントは、属性名の検出に応えて生成することが可能である。属性名イベントは、属性名のシリアル番号を含むことが可能であり、いくつかの実施態様では、要素が対応する属性のプレオーダー番号を含むことが可能である。式プロセッサ４２は、属性名イベントに応えて式ツリー内の式への属性名の一致を試みることが可能である。

テキストイベントは、文書内のテキストの検出に応えて生成することが可能である。テキストイベントは、対応する要素のプレオーダー番号を含むことが可能であり、式プロセッサ４２に、テキストノードテストまたはテキスト式ノードの一致のための式ツリー内の式を検査させることが可能である。同様に、コメントイベントは、文書内のコメントノードの検出に応えて生成することが可能である。コメントイベントは、対応する要素のプレオーダー番号を含むことが可能であり、式プロセッサ４２に、コメントノードテストまたはコメント式ノードの一致のための式ツリー内の式を検査させることが可能である。

処理命令イベントは、処理命令の検出に応えて生成することが可能である。処理命令イベントは、処理命令のシリアル番号を含むことが可能であり、いくつかの実施態様では、対応する要素のプレオーダー番号を含むことが可能である。式プロセッサ４２は、定数の有無にかかわらず、処理命令ノードテストへの、または処理命令の式ノードへの処理命令の一致を試みることが可能である。

図１９Ａ−図１９Ｂは、（要素開始およびトップレベルの要素開始イベントの両方を含む）要素開始イベントに応えて、図１７に示す解析時間の式ツリー２６を使用した、式プロセッサ４２の一実施態様の演算を示すフローチャートを示す。概して、処理には、要素が／スタック３９Ｃおよび／／スタック３９Ｄ上の式ノードの述語を満たすか、または要素が当該の式ノードの要素の子であるかどうかの検査とともに、要素との一致のための相対的なトップレベルの式ノード（および、イベントがトップレベルの要素開始イベントである場合の非相対的トップレベルの式ノード）の検査を含むことが可能である。

式プロセッサ４２は、／および／／スタックポインタをポインタスタック３９Ｅにプッシュすることが可能である（ブロック３１０）。より詳しくは、図示した実施態様において、ポインタスタック３９Ｅは、それぞれ／スタックポインタおよび／／スタックポインタのための、／Ｐｔｒスタックおよび／／Ｐｔｒスタックを含むことが可能である。この代わりに、他の実施態様では、両ポインタを同じスタック上にプッシュすることが可能である。ポインタは、／スタック３９Ｃおよび／／スタック３９Ｄの状態を要素の検出前の状態に回復する（別の要素の、終了する要素の前に一致するような式への一致を可能にする）ために、対応する要素終了イベントが終了したときに、続いてポップさせることが可能である。要素開始イベントが識別する要素は、図１９Ａ−１９Ｂの記述では、より簡潔に要素と称する。トップレベルの要素開始イベントを受信したかどうか（判断ブロック３１２）に基づいて、式プロセッサ４２は、各トップレベルの式ノード（例、絶対的および祖先のトップレベルの式ノードを含む）を検査する（ブロック３１６）か、または一致のための解析時間の式ツリーの各相対的なトップレベルの式ノードを検査する（ブロック３１４）ことが可能である。すなわち、そのイベントがトップレベルの要素開始イベントである場合（判断ブロック３１２、「ｙｅｓ」レグ）、式プロセッサ４２は、ルートノードの子のための絶対的なトップレベルのノードに対してであっても一致を検出することが可能であるので、解析時間の式ツリー２６内の各トップレベルの式ノードを検査することが可能である（ブロック３１６）。一方で、そのイベントがトップレベルの要素開始イベントでない場合（判断ブロック３１２、「ｎｏ」レグ）、式プロセッサ４２は、絶対的なトップレベルのノードに対して一致を検出しない可能性があるので、解析時間の式ツリー２６内の各相対的なトップレベルの式ノードを検査することが可能である（ブロック３１４）。

トップレベルのノードのいずれかに対して一致が検出されない場合（判断ブロック３１８、「ｎｏ」レグ）、フローチャートは、図１９Ｂの参照Ｄを継続する。一致が検出され（判断ブロック３１８、「ｙｅｓ」レグ）、かつ式ノードがリーフノードである場合（判断ブロック３２０、「ｙｅｓ」レグ）、解析時間の式ツリー２６の式ノードのエントリ内のＸＬＰおよびＴＬＰポインタによって示される１つまたは複数の式および／または１つまたは複数のテンプレートに対応する一致リストに、要素ノードが出力される（ブロック３２２）。式プロセッサ４２は、一致した式ノードが／または／／子のいずれかを有するかどうかを判断し（それぞれ、判断ブロック３２４および３２６）、一致した式ノードが／または／／子のいずれかを有する場合（それぞれ、判断ブロック３２８および３３０）、それぞれ／スタック３９Ｃおよび／または／／スタック３９Ｄ上の一致した式をプッシュする。式プロセッサ４２は、例えば、／または／／子があるかどうかを検出するために、解析時間の式ツリー２６内の式ノードのエントリのＣＤフィールドを使用することが可能である。加えて、／スタック３９Ｃおよび／／スタック３９Ｄは、（解析時間の式ツリーエントリ３００内のＰｒＴＰおよびＰｒＤＴフィールドを経て示される）解析時間述語の一致の管理に使用する評価フィールドを含むことが可能である。（ゼロではないＰｒＴＰフィールドによって示されるような）解析時間述語がある場合、評価フィールドを０に設定することが可能である。それ以外ならば、評価フィールドを１に設定することが可能である。フローチャートは、図１９Ｂの参照Ｄを継続する。

図１９Ｂの参照Ｄで、／および／／スタックは、要素が（／または／／スタックエントリのうちの１つに保存される）以前に一致した式ノードの子または述語に一致するかどうかを検索される。／および／／スタックが空である場合（判断ブロック３３２、「ｙｅｓ」レグ）、この要素に対する一致は終了する。それ以外ならば（判断ブロック３３２、「ｎｏ」レグ）、スタックエントリが選択される。エントリ内の評価フィールドが１に設定される場合、選択したスタックエントリ内の対応する式ノードは、述語を持たないか、またはその述語が以前に解析した文書ノードによって満たされる。したがって（判断ブロック３３４、「ｅｖａｌ＝１」レグ）、式プロセッサは、要素が要素の子のいずれかに一致するかどうかを判断するために、選択したスタックエントリ内の式ノードのあらゆる要素の子を検査することが可能である。／要素の子も、／／要素の子も、考慮することが可能である。より詳しくは、式ノードが（例えば、解析時間の式ツリーエントリ３００のＣＤフィールド内に示されるように）要素の子を持たない場合（判断ブロック３３６、「ｎｏ」レグ）、その要素に対する一致処理は終了する。この代わりに、式プロセッサ４２は、処理のために次のスタックのエントリへ進むことが可能である（ブロック３６２）。式ノードが要素の子を有する場合（判断ブロック３３６、「ｙｅｓ」レグ）、式プロセッサ４２は、式ノードの第１の要素の子を取り込む（ブロック３３８）。例えば、エントリのＰｔｒ／またはＰｔｒ／／ポインタは、（子の式ツリーエントリ内のＮＴ型のフィールドとともに）要素の子を置くために使用することが可能である。子要素ノードが要素と一致し（判断ブロック３４０、「ｙｅｓ」レグ）、かつ子要素ノードがリーフノードである場合（判断ブロック３４２、「ｙｅｓ」レグ）、そのノードが一致リストに出力される（ブロック３４４）。加えて、一致した子要素ノードがそれぞれ／または／／子を有する場合（判断ブロック３４６および３４８）、その一致した子要素ノードをそれぞれ／スタック３９Ｃまたは／／スタック３９Ｄにプッシュし（ブロック３５０および３５２）、評価フィールドは、上述のように、ブロック３２４乃至３３０に関して初期化される。子要素ノードが要素と一致するか否かに関わらず、式プロセッサ４２は、最後の要素の子が処理されたかどうかを判断する（判断ブロック３５４）。一致しなければ、次の子要素ノードを取り込み（ブロック３３８）、同様に処理する。子要素ノードが現在のスタックエントリの最後の要素の子である場合（判断ブロック３５４、「ｙｅｓ」レグ）、式プロセッサ４２は、次のスタックエントリに進み（ブロック３６２）、要素子および述語の両方を処理することが可能である。

選択したスタックエントリのＰｒＴＰフィールドが４であるか、または要素の子である場合、要素は、その選択したスタックエントリ内の式ノードの述語を満たすことが可能である。したがって（判断ブロック３３４、「ＰｒＴＰ＝４」レグ）、式プロセッサ４２は、要素のシリアル番号を選択したスタックエントリのＰｒＤＴフィールドと比較することが可能である（ブロック３５６）。要素がＰｒＤＴフィールドに一致する場合（判断ブロック３５８、「ｙｅｓ」レグ）、その要素は述語を満たし、式プロセッサ４２は、選択したスタックエントリの評価フィールドを１に設定する（ブロック３６０）。いずれの場合も、式プロセッサ４２は、次のスタックエントリに進むことが可能である（ブロック３６２）。

所与のスタックエントリは、ゼロの評価フィールドおよび４ではないＰｒＴＰフィールドを有することが可能であることに留意されたい。そのような場合、式プロセッサ４２は、次のスタックエントリに進むことが可能である（ブロック３６２）。

図２０は、要素終了イベントに応えて、図１７に示す解析時間の式ツリー２６を使用した、式プロセッサ４２の一実施態様の演算を示すフローチャートを示す。

要素終了イベントが文書のルートノードに対するものである場合（判断ブロック３７０、「ｙｅｓ」レグ）、その文書は完了している（ブロック３７２）。式プロセッサ４２は、スタック３９Ｃ−３９Ｆをクリアすることが可能である。要素終了イベントが、文書のルートノードに対するものでない場合（判断ブロック３７０、「ｎｏ」レグ）、式プロセッサ４２は、Ｐｔｒスタック３９Ｅからの／および／／スタックポインタをポップすることが可能である（ブロック３７４）。要素は終わっているので、要素の全ての子はすでに解析されている。したがって、その要素に対応する／および／／スタックエントリ内のいずれのエントリ（すなわち、その要素のシリアル番号を有するエントリ）も、引き続き検出されるノードと一致させることができない。事実上、要素に対する要素開始イベントが検出されたときにプッシュされた／および／／スタックポインタの回復は、終了要素に対応する／スタック３９Ｃおよび／／スタック３９Ｄ上にエントリをポップさせ、それらの状態をその要素を処理する前の状態に回復させる（その状態は、次の検出した要素を処理するための適切な状態であり得る）。

図２１Ａ−２１Ｂは、属性名イベントに応えて、図１７に示す解析時間の式ツリー２６を使用した、式プロセッサ４２の一実施態様の演算を示すフローチャートを示す。属性名イベントによって識別される属性は、図２１Ａ−２１Ｂの記述において「属性」と称する場合がある。概して、処理には、属性が／スタック３９Ｃおよび／／スタック３９Ｄ上の式ノードの述語を満たすか、または属性が当該の式ノードの属性の子であるかどうかの検査とともに、属性との一致のための相対的なトップレベルの式ノードの検査を含むことが可能である。

属性の親ノードがルートノードである場合（判断ブロック３８２、「ｙｅｓ」レグ）、（ルートノードは属性を持たないので）実行する更なる処理はない。一方で、属性の親ノードがルートノードでない場合（判断ブロック３８２、「ｎｏ」レグ）、式プロセッサ４２は継続する。

式プロセッサ４２は、属性に対する一致のための相対的なトップレベルの式ノードのそれぞれを検査することが可能である（ブロック３８４）。所与の相対的なトップレベルの式ノードとの一致があり（判断ブロック３８６、「ｙｅｓ」レグ）、かつノードがリーフノードである場合（判断ブロック３８８、「ｙｅｓ」レグ）、属性ノードが一致リスト３９Ｇに出力される（ブロック３９０）。一致の有無に関わらず、トップレベルの式ノードが空になる（判断ブロック３９２、「ｎｏ」レグ）まで、次の相対的なトップレベルの式ノードによって処理を継続することが可能である。トップレベルの式ノードが空になると（判断ブロック３９２、「ｙｅｓ」レグ）、処理は図２１Ｂの参照Ｅを継続する。

図２１Ｂの参照Ｅから継続し、／および／／スタックは、属性が（／または／／スタックエントリのうちの１つに保存される）以前に一致した式ノードの子または述語に一致するかどうかを検索される。／および／／スタックが空である場合（判断ブロック３９４、「ｙｅｓ」レグ）、この属性に対する一致は終了する。それ以外ならば（判断ブロック３９４、「ｎｏ」レグ）、スタックエントリが選択される。エントリ内の評価フィールドが１に設定される場合、選択したスタックエントリ内の対応する式ノードは、述語を持たないか、またはその述語が以前に解析した文書ノードによって満たされる。したがって（判断ブロック３３４、「ｅｖａｌ＝１」レグ）、式プロセッサ４２は、属性が属性の子のいずれかに一致するかどうかを判断するために、選択したスタックエントリ内の式ノードのあらゆる属性の子を検査することが可能である。／属性の子も、／／属性の子も、考慮することが可能である。より詳しくは、選択したスタックエントリ内の式ノードが（例えば、解析時間の式ツリーエントリ３００のＣＤフィールドに示されるように）属性の子を持たない場合（判断ブロック３９８、「ｎｏ」レグ）、式プロセッサ４２は、スタック内の最後の式ノードが処理されたかどうかを判断することが可能である（判断ブロック４００）。その場合（判断ブロック４００、「ｙｅｓ」レグ）、属性に対する処理は終了する。それ以外ならば（判断ブロック４００、「ｎｏ」レグ）、式プロセッサ４２は、処理のために次のスタックエントリ（ブロック４１０）に進むことが可能である。選択したスタックエントリ内の式ノードが属性の子を有する場合（判断ブロック３９８、「ｙｅｓ」レグ）、式プロセッサ４２は、そのエントリの最初の属性の子を取り込む（ブロック４０２）。例えば、エントリのＰｔｒ／ＡｔｔｒまたはＰｔｒ／／Ａｔｔｒポインタは、属性の子を置くために使用することが可能である。子属性ノードが属性に一致する場合（ブロック４０４、「ｙｅｓ」レグ）、そのノードが一致リストに出力される（ブロック４０６）。子属性ノードが属性と一致するか否かに関わらず、式プロセッサ４２は、最後の属性の子が処理されたかどうかを判断する（判断ブロック４０８）。そうでない場合には、次の属性の子ノードが取り込まれ（ブロック４０２）、同様に処理される。子属性ノードが選択したスタックエントリ内の式ノードの最後の属性の子である場合（判断ブロック４０８、「ｙｅｓ」レグ）、式プロセッサ４２は、最後の式ノードが処理されたかどうかを判断することが可能であり（判断ブロック４００）、次のスタックエントリに進むか（ブロック４１０）、またはその結果、処理を終了することが可能である。

選択したスタックエントリのＰｒＴＰフィールドが５であるか、または属性名である場合、属性は、その選択したスタックエントリ内の式ノードの述語を満たすことが可能である。したがって（判断ブロック３９６、「ＰｒＴＰ＝５」レグ）、式プロセッサ４２は、属性のシリアル番号を選択したスタックエントリのＰｒＤＴフィールドと比較することが可能である（ブロック４１２）。属性がＰｒＤＴフィールドに一致する場合（判断ブロック４１４、「ｙｅｓ」レグ）、その属性は述語を満たし、式プロセッサ４２は、選択したスタックエントリの評価フィールドを１に設定する（ブロック４１６）。いずれの場合も、式プロセッサ４２は、次のスタックエントリに進むことが可能である（ブロック４１０）。式プロセッサ４２は、必要に応じて、進む前に残りの式ノードがあるかどうかを判断することが可能である（判断ブロック４００）。

所与のスタックエントリは、ゼロの評価フィールドおよび５ではないＰｒＴＰフィールドを有することが可能であることに留意されたい。そのような場合、式プロセッサ４２は、次のスタックエントリに進むことが可能である（ブロック４１０）。

図２２Ａ−２２Ｂは、テキストイベントに応えて、図１７に示す解析時間の式ツリー２６を使用した、式プロセッサ４２の一実施態様の演算を示すフローチャートを示す。テキストイベントによって識別されるテキストノードは、図２２Ａ−２２Ｂの記述において、より簡潔に「テキストノード」と称する場合がある。概して、処理には、テキストノードが／スタック３９Ｃおよび／／スタック３９Ｄ上の式ノードの述語を満たすか、またはテキストノードが当該の式ノードのテキストの子であるかどうかの検査とともに、テキストノードとの一致のための相対的なトップレベルの式ノードの検査を含むことが可能である。

テキストノードの親ノードがルートノードである場合（判断ブロック４２０、「ｙｅｓ」レグ）、実行する更なる処理はない。一方で、テキストノードの親ノードがルートノードでない場合（判断ブロック４２０、「ｎｏ」レグ）、式プロセッサ４２は継続する。

式プロセッサ４２は、テキストノードに対する一致のための相対的なトップレベルの式ノードのそれぞれを検査することが可能である（ブロック４２２）。所与の相対的なトップレベルの式ノードとの一致がある場合（判断ブロック４２４、「ｙｅｓ」レグ）、テキストノードが一致リスト３９Ｇに出力される（ブロック４２６）。一致の有無に関わらず、トップレベルの式ノードが空になる（判断ブロック４２８、「ｎｏ」レグ）まで、次の相対的なトップレベルの式ノードによって処理を継続することが可能である。トップレベルの式ノードが空になると（判断ブロック４２８、「ｙｅｓ」レグ）、処理は図２２Ｂの参照Ｆを継続する。

図２２Ｂの参照Ｆから継続し、／および／／スタックは、テキストノードが（／または／／スタックエントリのうちの１つに保存される）以前に一致した式ノードの子または述語に一致するかどうかを確認するために検索される。／および／／スタックが空である場合（判断ブロック４３０、「ｙｅｓ」レグ）、このテキストノードに対する一致は終了する。それ以外ならば（判断ブロック４３０、「ｎｏ」レグ）、スタックエントリが選択される。エントリ内の評価フィールドが１に設定される場合、選択したスタックエントリ内の対応する式ノードは、述語を持たないか、またはその述語が以前に解析した文書ノードによって満たされる。したがって（判断ブロック４３２、「ｅｖａｌ＝１」レグ）、式プロセッサ４２は、テキストノードがテキストの子のいずれかに一致するかどうかを判断するために、選択したスタックエントリ内の式ノードのあらゆるテキストの子を検査することが可能である。より詳しくは、式ノードが（例えば、解析時間の式ツリーエントリ３００のＣＤフィールドに示されるように）テキストの子を持たない場合（判断ブロック４３４、「ｎｏ」レグ）、式プロセッサ４２は、スタック内の最後の式ノードが処理されたかどうかを判断することが可能である（判断ブロック４４６）。その場合（判断ブロック４４６、「ｙｅｓ」レグ）、テキストノードに対する処理は終了する。それ以外ならば（判断ブロック４４６、「ｎｏ」レグ）、式プロセッサ４２は、処理のために次のスタックエントリ（ブロック４４８）に進むことが可能である。式ノードがテキストの子を有する場合（判断ブロック４３４、「ｙｅｓ」レグ）、式プロセッサ４２は、その式ノードの最初のテキストの子を取り込む（ブロック４３６）。例えば、エントリのＰｔｒ／またはＰｔｒ／／ポインタは、（各子ノード内のＮＴフィールドとともに）テキストの子を置くために使用することが可能である。子テキストノードがテキストノードに一致する場合（ブロック４３８、「ｙｅｓ」レグ）、そのノードが一致リストに出力される（ブロック４４０）。子テキストノードがテキストノードと一致するか否かに関わらず、式プロセッサ４２は、最後のテキストの子が処理されたかどうかを判断する（判断ブロック４４２）。そうでない場合には、次のテキストの子ノードが取り込まれ（ブロック４３６）、同様に処理される。子テキストノードが選択したスタックエントリ内の式ノードの最後のテキストの子である場合（判断ブロック４４２、「ｙｅｓ」レグ）、式プロセッサ４２は、最後の式ノードが処理されたかどうかを判断することが可能であり（判断ブロック４４６）、次のスタックエントリに進むか（ブロック４４８）、またはその結果、処理を終了することが可能である。

選択したスタックエントリのＰｒＴＰフィールドが８（ノードテスト）であるか、またはＢ（テキストノードテスト）である場合、テキストノードは、その選択したスタックエントリ内の式ノードの述語を満たす（判断ブロック４３２、「ＰｒＴＰ＝８またはＢ」レグ）。したがって、式プロセッサ４２は、選択したスタックエントリの評価フィールドを１に設定する（ブロック４４４）。式プロセッサ４２は、次のスタックエントリに進むことが可能である（ブロック４４８）。式プロセッサ４２は、必要に応じて、進む前に残りの式ノードがあるかどうかを判断することが可能である（判断ブロック４４６）。

所与のスタックエントリは、ゼロの評価フィールドおよび８またはＢではないＰｒＴＰフィールドを有することが可能であることに留意されたい。そのような場合、式プロセッサ４２は、次のスタックエントリに進むことが可能である（ブロック４４８）。

図２３Ａ−２３Ｂは、コメントイベントに応えて、図１７に示す解析時間の式ツリー２６を使用した、式プロセッサ４２の一実施態様の演算を示すフローチャートを示す。コメントイベントによって識別されるコメントノードは、図２３Ａ−２３Ｂの記述においてより簡潔に「コメントノード」と称する場合がある。概して、処理には、コメントノードが／スタック３９Ｃおよび／／スタック３９Ｄ上の式ノードの述語を満たすか、またはコメントノードが当該の式ノードのコメントの子であるかどうかの検査とともに、コメントノードとの一致のための相対的なトップレベルの式ノードの検査を含むことが可能である。

コメントノードの親ノードがルートノードである場合（判断ブロック４５０、「ｙｅｓ」レグ）、実行する更なる処理はない。一方で、コメントノードの親ノードがルートノードでない場合（判断ブロック４５０、「ｎｏ」レグ）、式プロセッサ４２は継続する。

式プロセッサ４２は、コメントノードに対する一致のための相対的なトップレベルの式ノードのそれぞれを検査することが可能である（ブロック４５２）。所与の相対的なトップレベルの式ノードとの一致がある場合（判断ブロック４５４、「ｙｅｓ」レグ）、コメントノードが一致リスト３９Ｇに出力される（ブロック４５６）。一致の有無に関わらず、トップレベルの式ノードが空になる（判断ブロック４５８、「ｎｏ」レグ）まで、次の相対的なトップレベルの式ノードによって処理を継続することが可能である。トップレベルの式ノードが空になると（判断ブロック４５８、「ｙｅｓ」レグ）、処理は図２３Ｂの参照Ｇを継続する。

図２３Ｂの参照Ｇから継続し、／および／／スタックは、コメントノードが（／または／／スタックエントリのうちの１つに保存される）以前に一致した式ノードの子または述語に一致するかどうかを確認するために検索される。／および／／スタックが空である場合（判断ブロック４６０、「ｙｅｓ」レグ）、このコメントノードに対する一致は終了する。それ以外ならば（判断ブロック４６０、「ｎｏ」レグ）、スタックエントリが選択される。エントリ内の評価フィールドが１に設定される場合、選択したスタックエントリ内の対応する式ノードは、述語を持たないか、またはその述語が以前に解析した文書ノードによって満たされる。したがって（判断ブロック４６２、「ｅｖａｌ＝１」レグ）、式プロセッサ４２は、コメントノードがコメントの子のいずれかに一致するかどうかを判断するために、選択したスタックエントリ内の式ノードのあらゆるコメントの子を検査することが可能である。より詳しくは、式ノードが（例えば、解析時間の式ツリーエントリ３００のＣＤフィールドに示されるように）コメントの子を持たない場合（判断ブロック４６４、「ｎｏ」レグ）、式プロセッサ４２は、スタック内の最後の式ノードが処理されたかどうかを判断することが可能である（判断ブロック４７６）。その場合（判断ブロック４７６、「ｙｅｓ」レグ）、コメントノードに対する処理は終了する。それ以外ならば（判断ブロック４７６、「ｎｏ」レグ）、式プロセッサ４２は、処理のために次のスタックエントリ（ブロック４７８）に進むことが可能である。式ノードがコメントの子を有する場合（判断ブロック４６４、「ｙｅｓ」レグ）、式プロセッサ４２は、その式ノードの最初のコメントの子を取り込む（ブロック４５６）。例えば、エントリのＰｔｒ／またはＰｔｒ／／ポインタは、（各子ノード内のＮＴフィールドとともに）コメントの子を置くために使用することが可能である。子コメントノードがコメントノードに一致する場合（ブロック４６８、「ｙｅｓ」レグ）、そのノードが一致リストに出力される（ブロック４７０）。子コメントノードがコメントノードと一致するか否かに関わらず、式プロセッサ４２は、最後のコメントの子が処理されたかどうかを判断する（判断ブロック４７２）。そうでない場合には、次のコメントの子ノードが取り込まれ（ブロック４６６）、同様に処理される。子コメントノードが選択したスタックエントリ内の式ノードの最後のコメントの子である場合（判断ブロック４７２、「ｙｅｓ」レグ）、式プロセッサ４２は、最後の式ノードが処理されたかどうかを判断することが可能であり（判断ブロック４７６）、次のスタックエントリに進むか（ブロック４７８）、またはその結果、処理を終了することが可能である。

選択したスタックエントリのＰｒＴＰフィールドが８（ノードテスト）であるか、または９（コメントノードテスト）である場合、コメントノードは、その選択したスタックエントリ内の式ノードの述語を満たす（判断ブロック４６２、「ＰｒＴＰ＝８または９」レグ）。したがって、式プロセッサ４２は、選択したスタックエントリの評価フィールドを１に設定する（ブロック４７４）。式プロセッサ４２は、次のスタックエントリに進むことが可能である（ブロック４７８）。式プロセッサ４２は、必要に応じて、進む前に残りの式ノードがあるかどうかを判断することが可能である（判断ブロック４７６）。

所与のスタックエントリは、ゼロの評価フィールドおよび８または９ではないＰｒＴＰフィールドを有することが可能であることに留意されたい。そのような場合、式プロセッサ４２は、次のスタックエントリに進むことが可能である（ブロック４７８）。

図２４Ａ−２４Ｂは、処理命令イベントに応えて、図１７に示す解析時間の式ツリー２６を使用した、式プロセッサ４２の一実施態様の演算を示すフローチャートを示す。処理命令イベントにおいて識別される処理命令ノードは、図２４Ａ−２４Ｂの記述においてより簡潔に「処理命令ノード」または「ＰＩノード」と称する場合がある。概して、処理には、ＰＩノードが／スタック３９Ｃおよび／／スタック３９Ｄ上の式ノードの述語を満たすか、またはＰＩノードが当該の式ノードのＰＩの子であるかどうかの検査とともに、ＰＩノードとの一致のための相対的なトップレベルの式ノードの検査を含むことが可能である。

ＰＩノードの親ノードがルートノードである場合（判断ブロック４８０、「ｙｅｓ」レグ）、実行する更なる処理はない。一方で、ＰＩノードの親ノードがルートノードでない場合（判断ブロック４８０、「ｎｏ」レグ）、式プロセッサ４２は継続する。

式プロセッサ４２は、ＰＩノードに対する一致のための相対的なトップレベルの式ノードのそれぞれを検査することが可能である（ブロック４８２）。所与の相対的なトップレベルの式ノードとの一致がある場合（判断ブロック４８４、「ｙｅｓ」レグ）、ＰＩノードが一致リスト３９Ｇに出力される（ブロック４８６）。一致の有無に関わらず、トップレベルの式ノードが空になる（判断ブロック４８８、「ｎｏ」レグ）まで、次の相対的なトップレベルの式ノードによって処理を継続することが可能である。トップレベルの式ノードが空になると（判断ブロック４８８、「ｙｅｓ」レグ）、処理は図２４Ｂの参照Ｈを継続する。

図２４Ｂの参照Ｈから継続し、／および／／スタックは、ＰＩノードが（／または／／スタックエントリのうちの１つに保存される）以前に一致した式ノードの子または述語に一致するかどうかを確認するために検索される。／および／／スタックが空である場合（判断ブロック４９０、「ｙｅｓ」レグ）、このＰＩノードに対する一致は終了する。それ以外ならば（判断ブロック４９０、「ｎｏ」レグ）、スタックエントリが選択される。エントリ内の評価フィールドが１に設定される場合、選択したスタックエントリ内の対応する式ノードは、述語を持たないか、またはその述語が以前に解析した文書ノードによって満たされる。したがって（判断ブロック４９２、「ｅｖａｌ＝１」レグ）、式プロセッサ４２は、ＰＩノードがＰＩの子のいずれかに一致するかどうかを判断するために、選択したスタックエントリ内の式ノードのあらゆるＰＩの子を検査することが可能である。より詳しくは、選択したエントリ内の式ノードが（例えば、解析時間の式ツリーエントリ３００のＣＤフィールドに示されるように）ＰＩの子を持たない場合（判断ブロック４９４、「ｎｏ」レグ）、式プロセッサ４２は、スタック内の最後の式ノードが処理されたかどうかを判断することが可能である（判断ブロック５１２）。その場合（判断ブロック５１２、「ｙｅｓ」レグ）、ＰＩノードに対する処理は終了する。それ以外ならば（判断ブロック５１２、「ｎｏ」レグ）、式プロセッサ４２は、処理のために次のスタックエントリ（ブロック５１４）に進むことが可能である。選択したエントリ内の式ノードがＰＩの子を有する場合（判断ブロック４９４、「ｙｅｓ」レグ）、式プロセッサ４２は、その式ノードの最初のＰＩの子を取り込む（ブロック４９６）。例えば、エントリのＰｔｒ／ＰＩまたはＰｔｒ／／ＰＩポインタは、ＰＩの子を置くために使用することが可能である。子ＰＩノードがＰＩノードに一致する場合（ブロック４９８、「ｙｅｓ」レグ）、そのノードが一致リストに出力される（ブロック５００）。子ＰＩノードがＰＩノードと一致するか否かに関わらず、式プロセッサ４２は、最後のＰＩの子が処理されたかどうかを判断する（判断ブロック５０２）。そうでない場合には、次のＰＩの子ノードが取り込まれ（ブロック４９６）、同様に処理される。子ＰＩノードが選択したスタックエントリ内の式ノードの最後のＰＩの子である場合（判断ブロック５０２、「ｙｅｓ」レグ）、式プロセッサ４２は、最後の式ノードが処理されたかどうかを判断することが可能であり（判断ブロック５１２）、次のスタックエントリに進むか（ブロック５１４）、またはその結果、処理を終了することが可能である。

選択したスタックエントリのＰｒＴＰフィールドが８（ノードテスト）であるか、またはＡ（ＰＩノードテスト）である場合、ＰＩノードは、その選択したスタックエントリ内の式ノードの述語を満たす。したがって、式プロセッサ４２は、選択したスタックエントリの評価フィールドを１に設定する（ブロック５１０）。式プロセッサ４２は、次のスタックエントリに進むことが可能である（ブロック５１４）。式プロセッサ４２は、必要に応じて、進む前に残りの式ノードがあるかどうかを判断することが可能である（判断ブロック５１２）。

選択したスタックエントリのＰｒＴＰフィールドが６（名前を有するＰＩノードテスト）である場合、ＰＩノードは、ＰＩノードのＰＩｔａｒｇｅｔがＰｒＤＴフィールドに一致する場合に述語を満たす。式プロセッサ４２は、ＰＩＴａｒｇｅｔをＰｒＤＴフィールドと比較する（ブロック５０６）。一致が検出された場合（判断ブロック５０８、「ｙｅｓ」レグ）、式プロセッサ４２は、選択したエントリの評価フィールドを１に設定する（ブロック５１０）。式プロセッサ４２は、次のスタックエントリに進むことが可能である（ブロック５１４）。式プロセッサ４２は、必要に応じて、進む前に残りの式ノードがあるかどうかを判断することが可能である（判断ブロック５１２）。

所与のスタックエントリは、ゼロの評価フィールドおよび６、８またはＡではないＰｒＴＰフィールドを有することが可能であることに留意されたい。そのような場合、式プロセッサ４２は、次のスタックエントリに進むことが可能である（ブロック５１４）。

いくつかの実施態様では、式プロセッサ４２をパイプライン化することが可能であることに留意されたい。例えば、その後のパイプライン段階でノードの比較が生じることがあり、次いでそれらのノードを取り込む（および、述語を有するノードに対して評価フィールドを比較する）。このような実施態様では、／および／／スタックエントリは、評価フィールドに対する潜在的変化がパイプライン内にある場合に設定され得る、インプログレスビット（ｉｎ−ｐｒｏｇｒｅｓｓ ｂｉｔ）を含むことが可能である。設定されると、インプログレスビットは、以降のエベントが比較が行われる前に評価フィールドを読み込まないように、そのエントリがビジーであることを示すことが可能である。

上述の種々の点において、式ノードは、／スタック３９Ｃまたは／／スタック３９Ｄ上にプッシュされるとみなされることに留意されたい。スタック３９Ｃ−スタック３９Ｄへの式ノードのプッシュは、スタック（または、式の一致に使用される式ツリーエントリの一部）へのノードの式ツリーエントリ３００のプッシュを含むことが可能である。必要に応じて、更なる情報をエントリ内に含むことが可能である（例、評価フィールドのような一致の進行を示す種々のステータス変数）。

上述の説明が完全に理解されると、数多くのバリエーションおよび変更は当業者にとって明らかになるであろう。以下の請求項が全ての当該のバリエーションおよび変更を包含すると解釈されることを意図するものである。

内容変換装置の一実施形態のブロック図である。 図１に示す文書プロセッサの一実施形態のブロック図である。 図２に示す文書プロセッサおよび図１に示すプロセッサの一部分を表す、一実施形態のブロック図であり、それらの間の通信およびそれらへの入力を示す。 スタイルシートのコンパイルおよび式評価方法の一実施形態を示すフローチャートである。 スタイルシートコンパイラの一実施形態の演算を示すフローチャートである。 スキーマコンパイラの一実施形態の演算を示すフローチャートである。 図２および図３に示す構文解析器の一実施形態のための入力データ構造および出力データ構造の一実施形態を示すブロック図である。 シリアル番号をノード識別子へ割り当てるための、図７に示す構文解析器の一実施形態の演算を示すフローチャートである。 図２および３に示す式プロセッサの一実施形態のための、入力データ構造および出力データ構造の一実施形態を示すブロック図である。 図２および９に示す解析時間の式ツリーの一実施形態における構成ブロック図である。 式ツリーおよびそれに対応する解析時間の式ツリーエントリの一部分の例である。 要素開始イベントに応答する式プロセッサの一実施形態の演算を示すフローチャートである。 要素開始イベントに応答する式プロセッサの一実施形態の演算を示すフローチャートである。 要素終了イベントに応答する式プロセッサの一実施形態の演算を示すフローチャートである。 属性名イベントに応答する式プロセッサの一実施形態の演算を示すフローチャートである。 属性名イベントに応答する式プロセッサの一実施形態の演算を示すフローチャートである。 要素クローズイベントに応答する式プロセッサの一実施形態の演算を示すフローチャートである。 変換エンジンの一実施形態の演算を示すフローチャートである。 図２および９に示す解析時間の式ツリーの別の実施形態におけるブロック図である。 図１７に示す特定のフィールドのための例示的なコード化を示す表のセットである。 要素開始イベントに応答する式プロセッサの一実施形態の演算を示すフローチャートである。 要素開始イベントに応答する式プロセッサの一実施形態の演算を示すフローチャートである。 要素終了イベントに応答する式プロセッサの一実施形態の演算を示すフローチャートである。 属性名イベントに応答する式プロセッサの一実施形態の演算を示すフローチャートである。 属性名イベントに応答する式プロセッサの一実施形態の演算を示すフローチャートである。 テキストイベントに応答する式プロセッサの一実施形態の演算を示すフローチャートである。 テキストイベントに応答する式プロセッサの一実施形態の演算を示すフローチャートである。 コメントイベントに応答する式プロセッサの一実施形態の演算を示すフローチャートである。 コメントイベントに応答する式プロセッサの一実施形態の演算を示すフローチャートである。 処理命令イベントに応答する式プロセッサの一実施形態の演算を示すフローチャートである。 処理命令イベントに応答する式プロセッサの一実施形態の演算を示すフローチャートである。

Claims (24)

1. 実行されるとスタイルシートを１つ以上のデータ構造にコンパイルする複数の命令でコード化される、コンピュータでアクセス可能な媒体と、
   該データ構造および文書を受信するために連結されたハードウェア回路と
   を備える装置であって、該ハードウェア回路は、該データ構造を使用して該スタイルシートにおいて指定されたように該文書の少なくとも一部を変換するように構成される、装置。
2. 実行されると、前記複数の命令が、前記スタイルシート内の各ノード識別子にシリアル番号を割り当て、前記データ構造が、該シリアル番号に該ノード識別子をマップする１つ以上の記号表を含む、請求項１に記載の装置。
3. 前記ハードウェア回路が、前記文書を解析するように構成された構文解析器を備え、該構文解析器が、該文書内の該ノード識別子を検出するように構成され、前記１つ以上の記号表を使用して、該ノード識別子を該シリアル番号に変換するように構成される、請求項２に記載の装置。
4. 前記記号表に存在しない前記文書内での第１のノード識別子の検出に応えて、前記構文解析器が、第１のシリアル番号を該第１のノード識別子に割り当てるように構成される、請求項３に記載の装置。
5. 前記構文解析器が、前記第１のノード識別子と、前記第１のシリアル番号とを前記構文解析が生成した第２の１つ以上の記号表に保存するように構成される、請求項４に記載の装置。
6. 前記データ構造が、前記スタイルシート内の式を表す１つ以上の式ツリーを含み、前記ハードウェア回路が、該式ツリー内に表される該式を前記文書に適用して該式を満たす該文書内のノードを識別するように構成される、請求項１に記載の装置。
7. 前記スタイルシートに指定されるような所与の式を満たす前記ノードに、１つ以上のアクションを実行するように構成される変換エンジンをさらに含む、請求項６に記載の装置。
8. 前記アクションを適用すると、少なくともいくつかの式の一部分が評価可能であり、前記ハードウェア回路が、該部分に基づいて前記式の残りを満たすノードをグループ化するように構成される、請求項７に記載の装置。
9. ２つ以上の式が共通部分を有する場合、該２つ以上の式が、該共通部分に対応する前記式ツリー内のノードを共有する、請求項６に記載の装置。
10. 前記コンピュータでアクセス可能な媒体が、実行されるとスキーマを第２の１つ以上のデータ構造にコンパイルする第２の複数の命令をさらに含む、請求項１に記載の装置。
11. 前記第２のデータ構造が、有効な文書構造を識別するスケルトン表を含む、請求項１０に記載の装置。
12. 前記第２のデータ構造が、デフォルト属性値を識別する１つ以上の表を含む、請求項１０に記載の装置。
13. 前記第２のデータ構造が、要素の所要の属性を識別する１つ以上の表を含む、請求項１０に記載の装置。
14. スタイルシートを１つ以上のデータ構造へコンパイルするステップと、
    ハードウェア回路へと該データ構造および文書を受信するステップと、
    該データ構造を使用して、該ハードウェア回路が該スタイルシート内に指定されたように該文書の変換の少なくとも一部を行うステップと
    を包含する、方法。
15. シリアル番号を前記スタイルシート内の各ノード識別子へ割り当てるステップをさらに包含し、前記データ構造が、該シリアル番号に該ノード識別子をマップする１つ以上の記号表を含む、請求項１４に記載の方法。
16. 前記ハードウェア回路が前記文書を解析して該文書内の前記ノード識別子を検出するステップと、
    該ハードウェア回路が前記１つ以上の記号表を使用して該ノード識別子を該シリアル番号に変換するステップとをさらに包含する、請求項１５に記載の方法。
17. 前記ハードウェア回路が前記記号表にない前記文書の第１のノード識別子を検出するステップと、
    該ハードウェア回路が第１のシリアル番号を該第１のノード識別子に割り当てるステップと、
    該ハードウェア回路が該第１のノード識別子および前記第１のシリアル番号を、該ハードウェア回路が生成した第２の１つ以上の記号表に保存するステップと
    をさらに包含する、請求項１６に記載の方法。
18. 前記データ構造が、前記スタイルシート内の式を表す１つ以上の式ツリーを含み、前記ハードウェア回路が該式ツリー内に表される該式を該文書に適用して該式を満たす該文書内のノードを識別するステップをさらに包含する、請求項１１に記載の方法。
19. 前記スタイルシートに指定されるような所与の式を満たす前記ノードへ、１つ以上のアクションを実行するステップをさらに包含する、請求項１８に記載の方法。
20. 前記アクションを適用すると、少なくともいくつかの式の一部分が評価可能であり、前記ハードウェア回路が該部分に基づいて該式の残りを満たすノードをグループ化するステップをさらに包含する、請求項１９に記載の方法。
21. スキーマを第２の１つ以上のデータ構造へコンパイルするステップをさらに包含する、請求項１４に記載の方法。
22. 前記第２のデータ構造が、有効な文書構造を識別するスケルトン表を含む、請求項２１に記載の方法。
23. 前記第２のデータ構造が、デフォルト属性値を識別する１つ以上の表を含む、請求項２２に記載の方法。
24. 前記第２のデータ構造が、要素の所要の属性を識別する１つ以上の表を含む、請求項２２に記載の方法。

Images