(57)【要約】  軽量なＡＰＩ（Application Program Interface）を介したマークアップ言語の操作、例えばＸＭＬ（eXtensible Markup Language）照会に対するサポートを利用するアーキテクチャ。ＡＰＩは、ＸＭＬを本来サポートしない言語におけるＸＭＬの値の構築を簡単にすることができるオブジェクトモデル（１０８）を定義する。この革新は、照会言語が、一方でコレクションに対する汎用的操作（例えば、関数のマッピング、フィルタリング、ソート、および／または射影）に織り込まれ、他方でこれらのコレクションの要素に対する１組のドメイン特有の操作（例えば、ナビゲーション、構築、および修正）に織り込まれることを可能にすることができる。ＡＰＩは、ノードを中心とする（例えば、文脈自由な）ＸＭＬデータの作成をサポートすることができる。したがって、ノードは、ドキュメントのコンテキスト内で構築される必要がない。態様は、従来のインターフェースメカニズム（例えば、ＤＯＭ）に関連して使用される命令型ステートメント指向の形式のインターフェースではなく表現式指向のインターフェースメカニズムを可能にすることができる。
2009503679.tif 000002
【特許請求の範囲】
【請求項１】
拡張可能マークアップ言語（ＸＭＬ）データとのインタラクションを容易にするアプリケーションプログラムインターフェース（ＡＰＩ）であって、
複数のＸＭＬのノードの型を区別するオブジェクトモデルコンポーネントと、
アプリケーションとインターフェースを取り、前記オブジェクトモデルと整合性のある表現式指向のフォーマットのデータを受領する受け取りコンポーネントと、
前記受領されたデータに少なくとも一部基づいて前記ＸＭＬデータの構築、照会、および修正の少なくとも１を容易にするアクションコンポーネントと
を備えることを特徴とするＡＰＩ。
【請求項２】
前記複数のＸＭＬのノードの型は、
名前空間統一資源識別子（ＵＲＩ）およびローカル名から成る１または複数の汎用的な名前を表す型、XNameと、
１または複数の属性を表す型、XAttributeと、
１または複数のＸＭＬの子ノード型のための抽象ベースクラスを表す型、XNodeと、
１または複数のＸＭＬのコメントを表す型、XCommentと、
１または複数のＸＭＬの処理命令を表す型、XProcessingInstructionと、
１または複数のＸＭＬ宣言を表す型、XDeclarationと、
ＸＭＬのドキュメント型の宣言を表す型、XDocumentTypeと、
文字データのためのベースクラスを表す抽象型、XCharacterNodeと、
１または複数のＸＭＬのCDataセクションを表す抽象型、XCDataと、
子を有する１または複数のノードを表す抽象型、XContainerと、
１または複数のＸＭＬの要素を表す型、XElementと、
完全なＸＭＬドキュメントを表す型、XDocumentと
のうちの少なくとも１を含むことを特徴とする請求項１に記載のシステム。
【請求項３】
前記アクションコンポーネントは、前記受領されたデータに少なくとも一部基づいてＸＭＬフラグメントを生成する構築コンポーネントを含むことを特徴とする請求項１に記載のシステム。
【請求項４】
前記生成されるＸＭＬフラグメントは、文脈自由なノードを含むことを特徴とする請求項１に記載のシステム。
【請求項５】
前記アクションコンポーネントは、親と、要素と、属性と、子孫と、自身および子孫と、祖先と、自身および祖先とのうちの少なくとも１を含む軸を表示することを特徴とする請求項１に記載のシステム。
【請求項６】
ドキュメントの順序によって照会結果のデータセットを明示的にソートするソートコンポーネントをさらに備えることを特徴とする請求項５に記載のシステム。
【請求項７】
前記軸は、単一のアイテムおよびソースコレクションのうちの一方に対して作業し、前記軸は、戻り値を特定の名前および特定の型のうちの少なくとも１つを有するノードに制限することを容易にすることを特徴とする請求項５に記載のシステム。
【請求項８】
前記アクションコンポーネントは、前記表現式指向のフォーマットで受け取られる前記データに少なくとも一部基づいて前記ＸＭＬデータの変更を容易にする修正コンポーネントを含むことを特徴とする請求項１に記載のシステム。
【請求項９】
前記修正コンポーネントは、ノードに対するアクションを識別するオペレータコンポーネントを含むことを特徴とする請求項８に記載のシステム。
【請求項１０】
前記アクションは、
受け取りノードに関する親に対する更新であって、前記親にアイテムを追加することと、前記親にアイテムのコレクションを追加することと、受け取りノードの親から前記受け取りノードを削除することとのうちの少なくとも１を含む更新と、
前記受け取りノードおよび受け取りノードのコレクションのうちの少なくとも一方に対する更新であって、前記受け取りノードにアイテムを追加することと、前記受け取りノードに子のコレクションを追加することと、前記受け取りノードの子を削除することと、前記受け取りノードの前記子を単一のアイテムで置き換えることと、前記受け取りノードの前記子をアイテムのコレクションで置き換えることと、属性を追加することと、属性を削除することと、指定された子ノードのコンテンツを置き換えることと、前記受け取りノードの属性を置き換えることとのうちの少なくとも１を含む更新と
のうちの少なくとも１であることを特徴とする請求項９に記載のシステム。
【請求項１１】
請求項１に記載のシステムを実行するためのコンピュータ実行可能命令をその媒体上に格納させたことを特徴とするコンピュータ読取可能媒体。
【請求項１２】
アプリケーションとＸＭＬデータとのインターフェースを取る方法であって、
複数のＸＭＬのノードの型を区別するオブジェクトモデルを確立するステップと、
前記オブジェクトモデルと整合性のある表現式指向のステートメントを受け取るステップであって、前記表現式指向のステートメントは要素および属性を同じやり方でアドレス指定するステップと、
前記受け取られた表現式指向のステートメントに少なくとも一部基づいて前記ＸＭＬデータを取り扱うステップと
を備えることを特徴とする方法。
【請求項１３】
取り扱うステップは、前記ＸＭＬデータの構築、照会、および修正のうちの少なくとも１を含むことを特徴とする請求項１２に記載の方法。
【請求項１４】
ＸＭＬフラグメントは、文脈自由なノードから構築されることを特徴とする請求項１３に記載の方法。
【請求項１５】
前記複数のＸＭＬのノードの型は、
名前空間統一資源識別子（ＵＲＩ）およびローカル名から成る１または複数の汎用的な名前を表す型、XNameと、
１または複数の属性を表す型、XAttributeと、
１または複数のＸＭＬの子ノード型のための抽象ベースクラスを表す型、XNodeと、
１または複数のＸＭＬのコメントを表す型、XCommentと、
１または複数のＸＭＬの処理命令を表す型、XProcessingInstructionと、
１または複数のＸＭＬ宣言を表す型、XDeclarationと、
ＸＭＬのドキュメント型宣言を表す型、XDocumentTypeと、
文字データのためのベースクラスを表す抽象型、XCharacterNodeと、
１または複数のＸＭＬのCDataセクションを表す抽象型、XCDataと、
子を有する１または複数のノードを表す抽象型、XContainerと、
１または複数のＸＭＬの要素を表す型、XElementと、
完全なＸＭＬドキュメントを表す型、XDocumentと
のうちの少なくとも１つを含むことを特徴とする請求項１２に記載の方法。
【請求項１６】
親と、要素と、属性と、子孫と、自身および子孫と、祖先と、自身および祖先の少なくとも１を含む軸を表示するステップをさらに備えることを特徴とする請求項１２に記載の方法。
【請求項１７】
ドキュメントの順序によって照会結果のデータセットを明示的にソートするステップをさらに備えることを特徴とする請求項１２に記載のシステム。
【請求項１８】
請求項１２に記載の方法を実行するためのコンピュータ実行可能命令をその媒体上に格納させたことを特徴とするコンピュータ読取可能媒体。
【請求項１９】
アプリケーションとＸＭＬデータの間のインタラクションを容易にするシステムであって、
複数のＸＭＬのノードの型を区別するオブジェクトモデルを識別するための手段と、
前記マークアップ言語コンポーネントに対するアクションを容易にするために前記オブジェクトモデルに少なくとも一部基づいた表現式指向のステートメントを使用するための手段であって、前記アクションは前記ＸＭＬデータを構築すること、照会すること、および修正することのうちの少なくとも１つを含む手段と
を備えることを特徴とするシステム。
【請求項２０】
前記複数のＸＭＬのノードの型は、
名前空間統一資源識別子（ＵＲＩ）およびローカル名から成る１または複数の汎用的な名前を表す型、XNameと、
１または複数の属性を表す型、XAttributeと、
１または複数のＸＭＬの子ノード型のための抽象ベースクラスを表す型、XNodeと、
１または複数のＸＭＬのコメントを表す型、XCommentと、
１または複数のＸＭＬの処理命令を表す型、XProcessingInstructionと、
１または複数のＸＭＬ宣言を表す型、XDeclarationと、
ＸＭＬのドキュメント型宣言を表す型、XDocumentTypeと、
文字データのためのベースクラスを表す抽象型、XCharacterNodeと、
１または複数のＸＭＬのCDataセクションを表す抽象型、XCDataと、
子を有する１または複数のノードを表す抽象型、XContainerと、
１または複数のＸＭＬの要素を表す型、XElementと、
完全なＸＭＬドキュメントを表す型、XDocumentと
のうちの少なくとも１つを含むことを特徴とする請求項１９に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、拡張可能マークアップ言語（ＸＭＬ）のための軽量なアプリケーションプログラムインターフェース（ＡＰＩ）に関する。
【背景技術】
【０００２】
マークアップ言語およびそれらのマークアップ言語に関連するアプリケーションは、発展を続け、今日のコンピューティング環境において一般的になりつつある。一般に、マークアップ言語は、テキスト内に組み込まれた１組のラベルを記述し、表示または識別の目的のために、要素のグループまたは個別の要素を区別する。典型的には、ラベルは「タグ」として知られている。マークアップ言語は、データベース内のより構造化されたデータではなくテキストの連続的なストリーム内の要素を識別する。１つの特定のマークアップ言語、ＸＭＬ（eXtensible Markup Language）は、テキストストリームをデータベースレコードと同等のものに変換することができる。
【０００３】
今日、ＸＭＬはデータを記述するためのオープンスタンダードとして知られている。多くの場合、ＸＭＬは、ウェブページおよび／または企業間のドキュメントに関するデータ要素を定義するために使用される。ＸＭＬはＨＴＭＬ（Hypertext Markup Language）とタグの構造が類似している。しかし、ＨＴＭＬは要素がどのように表示されるべきかを定義する一方、ＸＭＬは要素の論理的な内容を定義する。
【０００４】
したがって、定義済みのタグを使用するＨＴＭＬとは反対に、ＸＭＬはページの開発者がタグを定義することを可能にする。したがって、実質的に任意のデータアイテムは、ＸＭＬを使用して定義することができる。結果として、フラグメントのＸＭＬドキュメントはデータベースレコードと同様に機能することができる。この結果、データベース機能を、ＸＭＬフラグメント上で使用することができる。
【０００５】
例として、企業は、ＸＭＬを使用して製品、顧客、および未払いの不足額などのアイテムを定義することができる。それゆえ、これらのアイテムを定義するためにＸＭＬを使用することによってフラグメントのＸＭＬドキュメントが構造化され、データベースレコードによく似た機能を果たすことができる。データ（例えば、ＸＭＬ）を識別するためのこの一般的な方法は、企業間取引をサポートし、電子データ交換（ＥＤＩ）取引のための一般的な形式になっている。
【０００６】
ＸＭＬタグは、コンテンツの型と、要素および属性の名前とを識別するＸＭＬスキーマにおいて定義される。コーディングエラーに寛大で、ある程度自由なコーディング形式を使用することが知られているＨＴＭＬと異なり、標準的なＸＭＬページは「適格」である必要がある。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ＸＭＬはレコードをデータベースのフォーマットと同様のフォーマットに編成するので、最近の開発は、ＸＭＬフラグメントに対する照会を行うこと、およびＸＭＬフラグメント中をナビゲートすることを対象としてきた。この結果、多くの特有の言語は、情報を取得することを達成するために作成されてきた。しかしながら、これらの特有の言語は、従来の厳密にプログラムされたフラグメント上で動作するために命令型のメカニズムを必要とする。
【課題を解決するための手段】
【０００８】
以下に、本発明のいくつかの態様の基本的な理解を提供するための本発明の簡潔な概要を述べる。この概要は、本発明の広範囲に渡る概観ではない。この概要は、本発明の重要な／決定的な要素を識別するように、または本発明の範囲を明示するように意図するものではない。その唯一の目的は、後述するより詳細な説明に対する前置きとして、本発明のいくつかの概念を簡潔な形態で述べることである。
【０００９】
本明細書において開示され、請求される本発明は、その発明の一態様において、軽量なＡＰＩ（Application Program Interface）を介したＸＭＬ（eXtensible Markup Language）照会に対するサポートを利用するシステムおよび方法を備える。これらの利用技術は、本明細書において説明するＸＭＬの構造に加えてデータモデルの照会を可能にする。別の態様において、利用技術は、本来ＸＭＬをサポートしない言語におけるＸＭＬの値の構築を簡単にすることもできる。
【００１０】
説明する革新的な態様は、照会言語が一方でコレクション（collections）に対する汎用的操作に織り込まれ、他方でこれらのコレクションの要素に対する１組のドメイン特有の操作に織り込まれることを可能にする。任意のコレクションに対して特に有用な汎用的照会操作の例は、コレクション上で関数をマッピング（例えば、射影）すること、コレクションから要素をフィルタリングすること、コレクションをパーティションにグルーピングすること、コレクションをソートすること、およびコレクションを値に変えるためのコレクション上での集約操作である。ＸＭＬドメインにおけるドメイン特有の操作（例えば、アクション）の例としては、子、属性、子孫、兄弟などを選択することなどの様々な「軸（axis）」機能、新しいＸＭＬのノードを作成するための要素の構築、およびノードの修正を含む。
【００１１】
ＸＭＬドメイン特有の操作に関して、汎用言語によって使用されるＸＭＬをナビゲートし、構築するための標準的なＡＰＩは、ＸＭＬ中心の言語によって提供される、ＸＰａｔｈの軸と表現式指向の要素および属性の構築との規則性と比べると大変命令的で非常に複雑で不規則である。さらに、従来のＡＰＩ（例えば、ＤＯＭ（document object model））はまた、メモリの占有スペースの観点からすると非常に重い。
【００１２】
これらのことに基づいて、本発明の態様は、マークアップ言語コンテンツ（例えばＸＭＬ）の取り扱い（例えば、構築、照会、修正）を容易にし、基礎となるアプリケーションおよび／またはホスト言語によって提供される１または複数の汎用的な照会インフラストラクチャとインターフェースを取ることができる軽量で合理的なＡＰＩを開示する。より具体的には、対象のＡＰＩの一態様は、ドキュメントを中心とするものと対照的にノードを中心とする（例えば、文脈自由な）ＸＭＬの作成をサポートすることができる。言い換えると、ノードは、ルートドキュメントのコンテキストの中で構築される必要がない。そのうえ、態様は、従来のインターフェースメカニズム（例えば、ＤＯＭ）とともに使用される命令型ステートメント指向形式のインターフェースと対照的に表現式指向のインターフェースメカニズムを可能にすることができる。
【００１３】
対象の発明の別の態様において、要素および属性の両方が同様のやり方でアクセスされる。言い換えると、一態様において、同じ軸を、ＸＭＬドキュメントおよび／またはフラグメントを用いて属性にアクセスするために使用することができるのと同様に、要素にアクセスするために使用することができる。そのうえ、その他の態様は、テキストノードおよび属性のコレクションの固有の識別性を持たないメカニズムを使用する。
【００１４】
前述のまたは関連する目的の達成のために、本発明の所定の例示的な態様を、以下の説明および添付の図面と関連して本明細書において述べる。しかし、これらの態様は、その手法で本発明の原理を使用することができる様々な手法のうちのほんの数例だけを示しており、対象の発明はすべてのそのような態様とそれらの同等のものとを含むように意図している。本発明のその他の利点および新規の特徴は、図面ともに検討するときに本発明の以下の詳細な説明から明らかになるであろう。
【発明を実施するための最良の形態】
【００１５】
ここから、本発明は図面を参照して説明する。ここでは、図面全体を通じて同様の要素を示すために同様の参照番号を使用する。以下の説明において、説明の目的で、対象の発明の完全な理解をもたらすために多くの特有の詳細を示す。しかし、本発明がこれらの特有の詳細なしに実施され得ることは明らかであろう。その他の場合、本発明を説明することを容易にするために、よく知られた構造およびデバイスをブロック図の形態で示す。
【００１６】
本出願において使用される用語「コンポーネント」および「システム」は、ハードウェア、ハードウェアおよびソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれかである、コンピュータに関連するエンティティを指すように意図される。例えば、コンポーネントは、プロセッサ上で実行されるプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および／またはコンピュータであってよいが、これらに限定されない。説明として、サーバ上で実行されるアプリケーションおよび当該サーバの両方がコンポーネントであってよい。１または複数のコンポーネントは実行プロセスおよび／またはスレッド内に存在することができ、１のコンポーネントは１つのコンピュータ上に配置することができ、および／または２つ以上のコンピュータの間に分散することができる。
【００１７】
本明細書において使用される用語「推論する」または「推論」は、一般に、イベントおよび／またはデータを介して収集される１組の観測結果からシステム、環境、および／またはユーザの状態を導き出すまたは推論するプロセスを指す。推論は、特有のコンテキストまたはアクションを識別するために使用することができるか、または例えば状態上の確率分布を生成することができる。推論は、確率的、すなわち、データおよびイベントの検討に基づいた対象の状態上の確率分布の計算であることができる。推論は、より高レベルのイベントを１組のイベントおよび／またはデータから構成するために使用される技術も示すことができる。そのような推論は、１組の観察されたイベントおよび／またはストアされたイベントデータ、当該イベントが時間的にかなり近接して相互に関連付けられるか否か、および当該イベントおよびデータが１つのイベントソースおよびデータソースから来るのか、それとも複数のイベントソースおよびデータソースから来るのかにより、新しいイベントまたはアクションの構築をもたらす。
【００１８】
マークアップ言語（例えば、ＸＭＬ（eXtensible Markup Language））プログラミングのランドスケープを変える新しいプログラミング言語の根底にある基本的な原理を注意深く分析することにより、対象の発明は軽量なＡＰＩを介したマークアップ言語データ（例えば、ＸＭＬ）照会に対するサポートを利用する。これらの利用技術は、本明細書において説明されるＸＭＬの構造に加え、データモデルの照会を可能にする。利用技術はまた、本来はＸＭＬをサポートしない言語におけるＸＭＬの値の構築を簡単にすることもできる。本明細書において記述する態様はＸＭＬの実装を対象とするが、本明細書において開示される新規の概念および機能はその他のマークアップ言語環境において適用できることを理解し、認識されたい。したがって、これらの追加的な実装は、本開示および本開示に添付された特許請求の範囲の一部であると見なされるべきである。
【００１９】
説明される革新的な態様は、XQueryおよびＳＱＬを含む照会言語が一方でコレクションに対する汎用的操作に織り込まれ、他方でこれらのコレクションの要素に対する１組のドメイン特有の操作に織り込まれることを可能にすることができる。任意のコレクションに対して特に有用な汎用的照会操作の例は、コレクション上で関数をマッピング（例えば、射影）すること、コレクションから要素をフィルタリングすること、コレクションをパーティションにグルーピングすること、コレクションをソートすること、およびコレクションを値に変えるためのコレクション上での集約操作である。ＸＭＬドメインにおけるドメイン特有の操作（例えば、アクション）の例としては、子、属性、子孫、兄弟などを選択することなどの種々の「軸」機能、新しいＸＭＬのノードを作成するための要素の構築、およびノードの修正を含む。
【００２０】
データベース研究者は、コレクションに対するこれらの汎用的な操作が構文、モノイド（monoids）、またはモナド（monads）の概念のすべてのインスタンスであることを長い間発見してきた。それゆえ、これらの操作は多くの代数的プロパティを満たし、内包の形態で構文的利点を可能にする。例として、XQueryブランド（XQuery-brand）の環境におけるＦＬＯＷＲ表現式は、内包の形態であり、ＸＭＬのノードのコレクション上の操作にいっさい関連付けられていない。むしろ、ＦＬＯＷＲ表現式は、オブジェクトのコレクションまたは関連する行のテーブル上で複雑な照会を表現するのに有用である可能性がある。
【００２１】
ＸＭＬを照会するための特有の言語を作成するのではなく、プログラマが「コレクション」の広い概念を使用する任意の形式のデータを照会することを可能にする、モナドに基づく照会機能によって汎用言語を拡張することができる。このドキュメントにおいて示すメカニズム（例えば、ＡＰＩ）は、これらの照会メカニズムをサポートするパターンおよび言語構造を可能にする。
【００２２】
ＸＭＬドメイン特有の操作に関して、汎用言語によって使用されるＸＭＬをナビゲートし、構築するための標準的なＡＰＩは、ＸＭＬ中心の言語によって提供される、ＸＰａｔｈの軸と表現式指向の要素および属性の構築との規則性とを比べると大変命令的で、非常に複雑および不規則である。さらに、従来のＡＰＩ（例えば、ＤＯＭ（ドキュメントオブジェクトモデル））はまた、非常に重い。
【００２３】
これらのことに基づいて、本発明の態様は、基礎となるアプリケーションおよび／またはホスト言語によって提供される１または複数の汎用的な照会インフラストラクチャとインターフェースを取ることができる、ＸＭＬを取り扱う（例えば、構築、照会、修正）ための軽量で合理的で簡単なＡＰＩを開示する。具体的には、対象の発明は、ドキュメントを中心とすることと対照的にノードを中心とする（例えば、文脈自由な）ＸＭＬの作成をサポートすることができる。さらに、態様は、従来のインターフェースメカニズム（例えば、ＤＯＭ）の命令型ステートメント指向の形式と対照的に表現式指向のインターフェースメカニズムを可能にすることができる。
【００２４】
最初に図１を参照すると、アプリケーション、例えばホスト言語とマークアップ言語との間のインタラクションを容易にするシステム１００が示されている。一般に、システム１００は、アプリケーションがマークアップ言語コンポーネント１０４とインターフェースを取り、通信することを可能にするＡＰＩ（Application Program Interface）１０２を含むことができる。例として、ＡＰＩ１０２は、照会コンポーネントなどのアプリケーションがマークアップ言語のコレクション（例えば、マークアップ言語コンポーネント１０４）内をナビゲートし、それによってそのコレクション内の所望のノードを識別することを容易にすることを可能にする。認識されるように、ＡＰＩは、実行のために必要なサブルーチンへのリンケージを提供するアプリケーション（例えば、照会コンポーネント）に、関数呼び出しを記述することによって実装することができる。したがって、ＡＰＩは、操作を実行するためにいくかのプログラムモジュールまたはＡＰＩアクションコンポーネント１０６がコンピュータ内で利用可能であること、またはタスクを実行するためにそのプログラムモジュールまたはＡＰＩアクションコンポーネント１０６が既存のプログラムにリンクされることを暗黙に示すことができる。
【００２５】
上述の例において、ＡＰＩ１０２は１からＭまでのＡＰＩアクションコンポーネントを使用することができ、ここでＭは整数である。図示する通り、１からＭまでのＡＰＩアクションコンポーネントは、集合的にまたは個々にＡＰＩアクションコンポーネント１０６として参照することができる。さらに、図１はＡＰＩ１０２に統合されたＡＰＩアクションコンポーネント１０６を示すが、ＡＰＩアクションコンポーネント１０６のうちのすべてまたは一部は、図示されたコンポーネントから離れて配置できることを理解し、認識されたい。
【００２６】
さらに、ＡＰＩ１０２はオブジェクトモデル１０８を含むことができる。オブジェクトモデル１０８は、マークアップ言語コンポーネント１０４特有のノード型を定義することができる。言い換えると、オブジェクトモデル１０８は、アプリケーション（ホスト言語）からマークアップ言語コンポーネント１０４へのマッピングを容易にすることができる。ＡＰＩアクションコンポーネント１０６を参照して上で示したように、オブジェクトモデル１０８は、ＡＰＩコンポーネント１０２のローカルに、またはＡＰＩコンポーネント１０２から離れて配置することができる。
【００２７】
ＡＰＩオブジェクトモデル１０８の構造は、以下のノード型および／または汎用クラスを含むことができる。特有のネーミング規則を以下に示すが、本明細書において説明する本発明の新規の機能および本明細書に添付の特許請求の範囲の範囲を逸脱することなく任意のネーミング規約を使用することができることを認識されたい。例示的なオブジェクトモデルの各ノード型を、以下でより詳細に説明する。
【００２８】
（Class XName）
このクラス、XNameは、名前空間URI（uniform resource identifier）およびローカル名から成る汎用名を表す。本発明によれば、要素および属性が同じやり方で扱われるので、このクラスは、要素および属性の両方の名前を表すために使用することができる。システムは、暗黙的に文字列をこれらの名前に変換することができる。したがって、ユーザはXNameを明示的に構築しない。むしろ、ユーザは、文字列の名前とＡＰＩ１０２とを参照して文字列をXNameに変換することができる。
【００２９】
（class XAttribute）
このクラス、XAttributeは、属性を表すために使用することができる。例えば、XAttributeクラスは、類型化されたやり方で属性の値を取得するために使用することができる。属性はＸＭＬのノードとは別であることを認識されたい。
【００３０】
（abstract class XNode）
このクラスは、様々なＸＭＬのノード型のための抽象ベースクラスとして使用することができる。
【００３１】
（class XComment : XNode）
このクラスは、ドキュメント中のコメントを表すノードから継承することができる。言い換えると、ドキュメント中にコメントが存在する場合、当該コメントはXCommentノードによって表すことができる。例えば、このクラスは、<!--this is a comment-->などのＸＭＬコメントを表すノードから継承することができる。
【００３２】
（class XProcessingInstruction : XNode）
一例において、このノードは、<? ?>などのＸＭＬの処理命令を表すために使用することができる。
【００３３】
（class XDeclaration : XNode）
上記ノードは、<?xml version= "1.0" encoding= "UTF-8" ?>などのＸＭＬ宣言を表すことができる。
【００３４】
（class XDocumentType : XNode）
このノードは、<!DOCTYPE greeting SYSTEM "hello.dtd">などのＸＭＬのドキュメント型宣言を表すために使用することができる。
【００３５】
（abstract class XCharacterNode : XNode）
（class XCData : XCharacterNode）
これは、ＸＭＬのCDataセクション<![CDATA[this is a CDATA section ]]>を表す例示的ノードである。
【００３６】
（abstract class XContainer : XNode）
これは、子を有するノードのための抽象ベースクラスである。
【００３７】
（class XElement : XContainer）
これは、XNodeから派生される抽象ベースクラスXContainerを有するノードである。上述のように、XContainerは子を有するノードのすべてを表すことを理解されたい。例えば、コメント、処理命令などは１つの子またはコンテンツのみを有する。その一方で、XElementおよびXDocumentクラスは、この例においてXContainerと呼ばれるこの抽象ベースクラスをサポートする、さらに下層の子を持つことができる。一例においてこのノードは、<Customer Name="Joe">...</Customer>などのＸＭＬの要素を表すことができる。
【００３８】
（class XDocument : XContainer）
例示的なオブジェクトモデルの検討の結論として、このノード、XDocumentは、完全なＸＭＬドキュメントを表すことができる。
【００３９】
図２を参照すると、一態様による代替システム２００のブロック図が示されている。一般に、システム２００は、ＡＰＩコンポーネント２０２およびマークアップ言語コンポーネント２０４を含む。ＡＰＩコンポーネント２０２は、オブジェクトモデル１０８、ナビゲーションコンポーネント２０６、構築コンポーネント２０８、修正コンポーネント２１０、および受け取りコンポーネント２１２を含むことができる。これらのアクションコンポーネント（２０６、２０８、２１０）のそれぞれは、オブジェクトモデル１０８を使用してマークアップ言語コレクション２０４に対する操作を容易にすることができる。これらのコンポーネント（２０６、２０８、２１０）のそれぞれは、以下の図に関してより詳細に検討される。
【００４０】
ここで図３に目を向けると、一態様において、システム３００は、汎用的な照会演算子がマークアップ言語コレクション２０４（例えば、ＸＭＬフラグメントおよび／またはノードのコレクション）からの結果データを（例えば、ナビゲーションコンポーネント２０６を介して）ナビゲートし、取り出すことができるようにするＡＰＩ２０２を含むことができる。図示する通り、マークアップ言語コレクション２０４は、１からＮまでのノードコンポーネントを含むことができ、ここでＮは整数である。１からＮまでのノードコンポーネントは、個々にまたは集合的にノードコンポーネント３０２として参照することができることを認識されたい。例示において、ローカルのノードのコレクション（例えば、３０２）に対して照会を使用することができる。さらに、コレクション２０４の概念は、（例えば、異なるマシン／場所から）離れて配置されるノード３０２も含むことができることを理解されたい。このシナリオにおいて、１または複数の照会メカニズム（例えば、ナビゲーションコンポーネント２０６）は、照会基準に基づいて関連ノードの識別を容易にすることができる。
【００４１】
その他の態様は、デリゲートを使用することの代わりに式ツリー（expression trees）を使用する照会の実装を対象とする。本質的に、ユーザが照会を実行することができる２つのやり方がある。１つは実際のコレクション（例えば、メモリコレクション中）上であり、もう１つはリモートコレクション上である。リモートコレクションのシナリオにおいて、照会はデリゲートによって表すのではなく、むしろ式ツリーによって表すことができる。したがって、システムは、本質的に異なるステップで照会を実行するのではなく全体の照会を使用する。
【００４２】
ここで図４を参照すると、ＸＭＬに関して、オブジェクトモデル１０８に関する軸の概念が示され、ナビゲーションコンポーネント２０６のメカニズムを示す。より具体的には、軸コンポーネント４０２は、ＸＭＬのノードのコレクション２０４において指定のノード３０２からその他のノード３０２へナビゲートするメカニズムを表す。ＸＭＬ構造におけるコレクション２０４は、相互に関連するノード３０２から構築された階層ツリーで表すことができることを理解されたい。したがって、軸コンポーネント４０２は、構造中をナビゲートすることを容易にすることができる方法である。例として、構造中の特定の所で、軸コンポーネント４０２は、指定のノードの親、指定のノードの子のすべてなどの識別を可能にすることができる。オブジェクトモデル１０８に関するマッピングコンポーネント（図示せず）は、ツリー中のそのようなナビゲーションおよび／または方向性を持った移動を容易にすることができる。
【００４３】
ノードまたはノードのコレクション（例えば、３０２）を考える場合、ユーザは、ツリー中を全検索し、その子、親など、またはその属性を識別すること望むかもしれない。ＡＰＩ２０２は、属性および要素にアクセスするための種々の軸（例えば、４０２）に対応するいくつかの新規の方法および／またはメカニズムを含む。
【００４４】
例えば、これらの例示的な軸の表現式は、対応する軸関数によって表すことができる。以下の例において、従来のＸＰａｔｈタイプの表現式が左側の列に列挙される。ＡＰＩ２０２の一態様に関する軸の表現式は、右側の列に列挙される。
【００４５】
【表１】
2009503679.tif 000003
【００４６】
一般に、軸関数４０２は、機能の様々なレベルを含むことができる。例えば、軸関数は、単一のアイテムに対して、またはソースコレクション上で使用することができる。それゆえ、要望に応じて、軸コンポーネント４０２は、戻り値を特定の名前を有するノードに制限することができる。したがって、ユーザは、コレクション上の検索を制限することができる。さらなる例として、ユーザは、特定のノードの子要素のすべて、または所定の名前を共有する子要素のすべてに関してコレクションに照会することができる。
【００４７】
その上、軸関数を、特定の型の返り値を制限するために使用することができる。このことは、値を検索するとき（例えば、文字列型または整数型の値のみを提供するとき）に特に有用である可能性がある。
【００４８】
結果として、本発明は、各軸（例えば、子孫、自身および子孫）に関するいくつかの多重定義を使用する。この検討にコンテキストを提供するため、以下はXElementクラスに対するすべての軸の例示的なリストである。このリストはいっさい限定として意図されたものでないことを認識されたい。さらに、本発明に基づいて、その他のノードに対してその他の軸関数が存在し、本開示および本開示に添付された特許請求の範囲の範囲に含まれるべきであることが認識されるであろう。
【００４９】
（public XContainer Parent {}）
この関数はノードの親を返す。これはXContainerに対して操作し、ここでは、オブジェクトモデル１０８に関して上述したように、すべてのXContainerは子を有する。
【００５０】
（public IEnumerable<object> Content() {}）
あるノードを考える場合、ユーザはノードの親を照会することができ、その親のコンテンツを要求するためにこの関数を使用することによって、システムはその親の子（例えば、コンテンツ（例えば、値））のすべてをレンダーするだろう。本発明の新規の特徴は、何らかの文字列のコンテンツと何らかの要素のコンテンツとがある場合にこの混ざり合ったコンテンツが返されることである。
【００５１】
（public IEnumerable<T> Content<T>() where T : class {}）
上記は、ユーザが所定の型のコンテンツを照会することができる例示的な多重定義である。
【００５２】
（XElement Element(XName name) {}）
この軸は特定の名前を有する要素を返す。操作において、この軸は指定された名前を有する最初の要素を返す。
【００５３】
次の５つの軸はIEnumerableの戻りの型を有する。
【００５４】
（IEnumerable<XElement> Elements() {}）
この軸は、特有の要素に直接含まれる子要素のすべてのレンダリングをもたらす。
【００５５】
（IEnumerable<XElement> Element(XName name) {}）
同様に、この軸は、特定の名前の要素のみをレンダーする。さらに、以下の３つの軸は上述した機能のバリエーションである。
【００５６】
【表２】
2009503679.tif 000004
【００５７】
この軸は、特有の名前を有する属性を返す。
【００５８】
この場合も、XElementに関して上述したように、XAttributeは同様にコレクション上に多重定義することができる。以下は本発明による多重定義の例示的態様である。
【００５９】
【表３】
2009503679.tif 000005
【００６０】
この関数は、孫およびひ孫などをレンダーする。実際上、この軸関数はノードの子のすべてを再帰的に返す。
【００６１】
（IEnumerable<T> Descendants<T>() where T : class {}）
これは、所定の型の子孫を取り除くことができる。
【００６２】
その他の軸の例は以下を含む。
【００６３】
【表４】
2009503679.tif 000006
【００６４】
図示している通り、上記は本発明による例示的な軸である。これらの軸はシングルコレクションに対して使用することができ、コレクションを返すことができることを理解されたい。
【００６５】
対象の発明は要素と属性の間の対称性を可能にすることを理解されたい。例えば、上述の特徴において示したように、要素および属性は、従来のＡＰＩでのように方法（例えば、属性（“foo”））およびインデクサ［“bar”］（例えば、大括弧）を使用することの代わりに同じ手法で選択される。しかし、本明細書において説明されるＡＰＩ２０２によれば、ユーザは、要素および／または属性の両方に同じやり方でアクセスすることができる。言い換えると、唯一の相違は、使用されるメソッドの対称性を維持しながら異なる軸が利用されることである。
【００６６】
操作において、ユーザは（例えば、ナビゲーションコンポーネント２０６を介して）要素を照会することができ、次に、システムは要素のコレクションを返すことができる。続いて、態様は、ユーザが返された要素のコレクションの属性のすべてを照会することを可能にする。この新規の機能はユ―ザがコレクションに関して軸をチェーニング（chain）することを可能にすることを理解されたい。
【００６７】
ＸＭＬに照会すると、照会はノードのコレクション（またはコレクションのサブセット）を返すことができることが認識されるであろう。従来、レンダーされたノードのコレクションの順序はドキュメントの順序に保たれる。例えば、照会結果においてあるノードが別のノードの前に来る場合、ドキュメント自体において当該ノードが後続の結果ノードよりも前に来ると解釈することができる。このノードは次のノードの前に見られることになる。言い換えると、照会の結果としてノードが返される順序は元のドキュメント自体と同じ順序である。
【００６８】
いくつかの照会（例えば、子孫の照会）はドキュメントの順序を乱す可能性がある。例えば、XQueryブランドの環境において、セマンティクスが、照会の後に結果をドキュメントの順序に自動的にソートすることを容易にする。認識されるように、ドキュメントの順序でのソートは非常に高価である。対象のＡＰＩ２０２の態様はドキュメントの順序での自動的なソートをせず、その結果、照会を組み合わせることができる。さらに、ナビゲーションコンポーネント２０６は、要望通りにドキュメントの順序で明示的にソートすることを容易にするソートコンポーネント４０４を含むことができる。
【００６９】
このソート機能をセマンティクスに組み込むのではなく、態様は、所定の照会がドキュメントの順序を乱すことを容易にし、その後要望通りに明示的にソートすることを可能にする。態様がドキュメントの順序を保たないことは本発明の新規の特徴である。さらに、ドキュメントの順序は、明示的ソート（例えば、ソートコンポーネント４０４）を介してもたらすことができる。ドキュメントの順序での効率的なソートを容易にするノードに情報をエンコードする多数のメソッドおよびメカニズムが認識されるであろう。これらのメソッドおよびメカニズムは当業者によって理解されることができ、本明細書および本明細書に添付された特許請求の範囲の範囲内であると見なされるべきである。
【００７０】
上述のように、対象のＡＰＩ２０２は、テキストノードおよび／または属性のコレクションの特有の識別性を考慮しない。標準ＤＯＭなどの標準的なシステムは、本明細書に述べた本発明によって表示されるデータモデルよりもより細かい細分度で情報アイテムを識別するXML Infosetデータモデルを表示する。結果として、対象の発明のデータモデルは、特に作業セットに関して、より効率的な実装を可能にすることができる。
【００７１】
例えば、対象の革新的な態様は、テキストノードではなく通常の文字列を使用する。さらに、近接する文字列は、自動的にマージされ、それによって効率が向上する。言い換えると、本発明は、従来のＤＯＭのように別個の属性コレクション（AttributeCollection）を表示しない。むしろ、本発明の態様によれば、各要素は、属性の（循環的に）リンクされたリストを直接維持する。
【００７２】
標準的なシステムは非常に詳細なオブジェクトモデルを有するので、標準的なシステムは多くの異なるノードを区別する。さらに、全てのノードが個々の名前空間コレクションを有する。
【００７３】
さらに、標準的なシステムにおいては、属性のコレクションが識別性を有する。言い換えると、ノードの属性のコレクション自体が、区別することができる何らかのものを有する。それらはテキストノードも区別することができる。したがって、混ざり合ったコンテンツにおいて、テキストの部分はそれら自体が別個のノードである。それとは反対に、対象の発明によれば、混ざり合ったコンテンツのテキストの部分は単なる普通の文字列である。それらの混ざり合ったコンテンツのテキストの部分は、特有の識別性と、親ポインタおよび名前空間ノードなどの付属するプロパティとを有する特有のテキストノードではない。
【００７４】
対象の発明は、従来のシステムよりも粗い情報セットのビューを使用し、それによってノードのより少ないプロパティを識別する。ノード間の区別を必要とする以前のシステムと異なり、対象の発明は、テキストノードを区別する必要がない。そのため、１または複数の対象のシステムは、従来のシステムよりも少ないメモリ占有スペースと、より効率的な実装とを有することができることが理解されるであろう。
【００７５】
すべての要素および属性は、名前を有する。具体的には、ＸＭＬにおいては、左大括弧の後に名前がある。したがって、従来、ユーザがドキュメント内を検索したい場合、要素および／または属性に対する名前を、準備する必要があっただろう。例えば、ユーザが、特定のドキュメントの作成者のすべてを取得するために照会することができる。これは、ドキュメント内の作成者要素のすべてを返しただろう。要素名または属性名を文字列として比較することは、特に非効率的で高価である可能性があることが理解されるであろう。これは、文字列を比較するときに、相違する文字が見つけられるまで文字列の文字のすべてを全検索する必要があるため非常にコストがかかる。
【００７６】
名前が長い場合、相違が文字列の最後にあるかもしれないので、それは特に高価である可能性がある。これを考慮して、名前を文字列として格納するのではなく、本明細書において説明するＡＰＩ２０２は、XNameと呼ばれる型として文字列を格納することができる。これは文字列ハッシュとして参照されることが多いことが理解されるであろう。説明するＡＰＩ２０２に対してこのハッシュ技術を使用することにより、ポインタを、文字列の代わりに比較することができる。したがって、新しい要素名が作成される度に、システムは文字列を格納（キャッシュ）し、新しいXNameに対するポインタを返すことができる。したがって、２つの名前が同じXNameによって表される場合、それらは同じポインタを使用する。
【００７７】
問題は、名前空間コンポーネント４０６内のテーブルが大きくなる可能性があることである。本発明の態様は、増大（例えば、速度、サイズ）をモニタすることができ、および／または任意の定義された基準に基づいて名前テーブルをパージすることができる。以下の例において「クリアネームキャッシュ（ClearNameCache）」機能が示される。そのため、システムが再び比較を行うときに、システムは、名前がもはや存在しないことを発見し、それゆえ名前を再び書き込むだろう。このモニタリングおよびパージ機能は、名前空間４０６に対応する名前テーブルの明示的な制御を提供する。さらに、システムは、増大および対応する統計をモニタすることができ、それによって、テーブルが速く増大し過ぎるときなどにイベントを生成することができる。
【００７８】
ＸＭＬにおける名前は、２つの部分、すなわち、要素（例えば、ブック、作成者）のようなローカル名と、名前空間プレフィックスから成ることができる。この２つの部分からなるネーミング規則は、同じドキュメント内に競合する名前を有する複数の要素が存在することができるので、特に有用である。したがって、ＡＰＩ２０２の態様は、これらの名前を、それをプレフィックスと組み合わせることによって一意的な文字列を有する名前空間４０６にすることができる。
【００７９】
したがって、ＡＰＩ２０２は、取り込まれた名前空間プレフィックスおよびそれに付加されるローカル名を有することにより、これらの十分に修飾された名前または汎用名を表すことができる。全ての名前は、名前空間ＵＲＩとローカル名から成ることができる。
【００８０】
ＡＰＩ２０２は、新規のシステムおよび／または方法を使用し、ＸＭＬの名前および名前空間を適用する。上述のように、一例において、XNameクラスは、ローカル要素名またはローカル属性名「part」と名前空間URI「http:///www.cars.com/xml」から成る「{http:///www.cars.com/xml}part」の形式の汎用名または拡張名を表すことができる。
【００８１】
XNameクラスは、文字列を入力することと、およびオブジェクトの参照を比較することとによってＸＭＬの名前の効率的な比較を可能にすることができる。文字列からXNameへの暗黙的な変換を提供することによって、ユーザは、XNameを明示的に構築する必要はない。
【００８２】
【表５】
2009503679.tif 000007
【００８３】
上で示している通り、XNameクラスは、これらの文字列を入力する。そのため、これらの名前は、これらの名前がXNameの参照を介して比較されるので、文字列としては比較されない。対象のＡＰＩ２０２は、文字列からの暗黙的な演算子を提供するので、ユーザがこのXNameを明示的に作成することは不要である。
【００８４】
図５は、本発明の一態様による、マークアップ言語（例えば、ＸＭＬ）のノードの構造（例えば、コレクション）中をナビゲートする方法のプロセスフロー図を図示する。説明の簡素化の目的で、例えばフローチャートの形式で本明細書に示す１または複数の方法を、一連の操作として示し説明するが、本発明によればいくつかの操作は異なる順序で、および／または本明細書に示し説明する操作とは別の操作と並行して行うことができるので、対象の発明は、その操作の順序によって限定されないことを理解し、認識されたい。例えば、当業者は、方法を、状態遷移などのような一連の相互関係のある状態またはイベントとして代替的に表すことができるであろうことを理解し、認識するであろう。さらに、図示した全ての操作が、本発明による方法を実装するために必要とされるわけではない可能性がある。
【００８５】
５０２において、ナビゲーション表現式が受け取られる。上述のように、ナビゲーション表現式は、コレクション内の１または複数の所望のターゲット（例えば、値）を識別する軸ステートメントであってよい。例えば、ナビゲーション表現式は特定のノードの親を要求することができる。
【００８６】
ナビゲーション表現式（例えば、軸）は、５０４において分析することができる。本質的に異なる例において、ナビゲーション表現式は特定のノードの親、親の親、兄弟などを要求することができる。したがって、コンテキストノードを、５０６において識別することができる。このコンテキストノードは、ナビゲーション表現式の開始点を定義することができる。さらに、ナビゲーションの方向を、５０８において決定することができる。
【００８７】
ナビゲーション表現式を満たすノードを、５１０において識別することができる。５１２において、さらなるノードが存在するかどうかの判定をすることができる。さらなるノードが構造（例えば、ツリー）内に存在する場合、プロセスは５１０に戻ることができ、その結果、１または複数のさらなるノードを識別する。さらなるノードが存在しない場合、停止ブロックが到達される。
【００８８】
ここで図６を参照すると、本発明のさらに別の態様によるシステム６００が示される。より具体的には、図６は、ＸＭＬの文脈自由なフラグメント、ノード、またはノードのコレクションの構築を容易にするシステム６００を示す。従来、ＸＭＬのＡＰＩは構造において命令型である。言い換えると、ＸＭＬのノードは、構造化されたコマンドおよび特定のシーケンスのコマンドを介して構築される。例として、命令型のコマンドのシーケンスは、ノードを定義することから始まり、１つの子、別の子などを追加することによって継続する。
【００８９】
対象のＡＰＩコンポーネント２０２は、コマンド（例えば、表現式）を受領する受け取りコンポーネント２１２を使用することができる。構築コンポーネント２０８は、オブジェクトモデル１０８とともに、表現式をＸＭＬフラグメントまたはコレクション２０４に変換することができる。
【００９０】
図７は、システム６００の代替的なブロック図を図示する。図示する通り、構築コンポーネント２０８は、表現式指向言語コンポーネント７０２を受け取ることができる。したがって、構築コンポーネント２０８は、オブジェクトモデルコンポーネント１０８に基づいて、表現式指向言語コンポーネント７０２をノードのマークアップ言語コレクション７０４に変換するために使用することができる。図示する通り、マークアップ言語コレクション７０４は、１からＰまでの文脈自由ノードコンポーネントを含むことができ、ここでＰは整数である。１からＰまでの文脈自由ノードコンポーネントは、個々にまたは集合的に文脈自由ノードコンポーネント７０６として参照され得ることを理解されたい。
【００９１】
照会の作業を容易にするために、対象の発明は、表現式指向のメカニズム（例えば、表現式指向言語コンポーネント７０２）を使用してＸＭＬのノード（例えば、構築コンポーネント２０８）を構築する。命令型ステートメントを使用して１または複数のＸＭＬコレクションを作成するのではなく、対象の発明はノードを作成する新規の表現式指向の方法を利用する。認識されるように、標準的なシステムおよび方法においては、ＸＭＬのノードは、ドキュメント中心である。言い換えると、標準的なＸＭＬのノードは、ドキュメントのコンテキスト内にのみ存在する。これらの従来のノードは、独立して存在することができない。そのことと対称的に、対象のＡＰＩ２０２は、ドキュメントから独立して存在することができる文脈自由なノードを生成する。
【００９２】
文脈自由ノードコンポーネント７０６の新規の特徴は、これらの文脈自由ノードコンポーネント７０６を独立して作成することができ、その他のノードの子として使用することができることである。したがって、従来のシステムと対称的に、および対象のＡＰＩ２０２に基づくと、文脈自由ノードコンポーネント７０６は、本質的にドキュメントのコンテキスト内に存在する必要はない。
【００９３】
操作において、ノードが作成されるとき、そのノードは、親を持たない。ノードは新たに作成されるので、その作成されるノードは任意の他のノードの子として存在しない。本発明の新規の特徴は、ノードが別のノードの子として指定されるとき、またはそこで照会が子として含まれるべきノードを返す場合に、ノードが既に親を持っていると構築コンポーネント２０８がノードを自動的に複製することができることである。これらのノードは１つの親のみを有することができることを理解されたい。したがって、異なるノードがノードの親として選択される場合、ノードは自動的に複製され、それによって親子関係が許される。対称的に、標準的なＡＰＩは、ユーザに明示的にノードを複製することを要求する。
【００９４】
システム６００の構築コンポーネント２０８は、ノードに対して親が存在するかどうかを判定するために自動的にチェックを行うことができる。存在する場合、構築コンポーネント２０８は自動的に複製を行い、新しい親、すなわち複製の親を指定することができる。この複製の結果は、新規の文脈自由なノードの構築である。
【００９５】
親を持つノードが新しいノードの構築のために用いられるとき、それらの親を持つノードは新しく構築されるノードの構造を維持するために自動的に複製され得る。しかし、ノードは、親を持っている必要はなく、特に、ノードはドキュメントから独立して存在することができる。以下の例は、本発明にコンテキストを与えるために提供するものであり、したがって、本開示を限定することはいっさい意図していない。
【００９６】
【表６】
2009503679.tif 000008
【００９７】
上記の例は、以下の構造をレンダーする。
【００９８】
【表７】
2009503679.tif 000009
【００９９】
以下は、ＡＰＩ２０２の一態様に基づいて最終的に作成することができるＸＭＬフラグメントの検討である。前の例が示すように、ＸＭＬフラグメントおよびドキュメントは、ステートメントのシーケンスを介した命令型の手段の代わりに、関数型のまたは表現式ベースの手段で構築される。例えば、以下の階層的なＸＭＬ要素は、以下に図示するように表現式指向の手段を利用して作成することができる。
【０１００】
【表８】
2009503679.tif 000010
【０１０１】
上記ＸＭＬフラグメントは、本発明のＡＰＩ２０２を対応するサブコンポーネント（例えば、構築コンポーネント２０８、オブジェクトモデル１０８）とともに用いることによって作成することができる。操作において、結果として得られる要素の構造とアイソモアフィックの単一のネストされた表現式を、記述することができる。例えば以下である。
【０１０２】
【表９】
2009503679.tif 000011
【０１０３】
標準的なＡＰＩを使用して上記ＸＭＬフラグメントを作成することはあまりにも煩雑である。標準的なＸＭＬ  ＤＯＭなどの既存のＡＰＩを使用する場合、ユーザは、初めにコンテナードキュメントを組み込む必要がある。次に、要素および属性は、そのドキュメントのコンテキスト内で命令的に作成される必要がある。さらに、ユーザは、これらのノードをその他のノードの子として命令的に割り当てる必要がある。以下は、標準的なＡＰＩによるこのプロセスの一例である。
【０１０４】
【表１０】
2009503679.tif 000012
【０１０５】
ユーザが照会の結果として新しいＸＭＬフラグメントを返すことを望む場合、そのフラグメントがいつも特定のドキュメントのコンテキスト内にあるわけではないので、この標準的な方法は照会において用いることができないことが認識されるであろう。その一方、（対象のＡＰＩ２０２に基づいて説明したように）文脈自由な構造を作成する能力は、ＸＭＬフラグメントの直接的な照会を容易にする。照会することに関するＡＰＩ２０２の態様は、ユーザが表現式として独自のものを作成することができるという事実に依拠する。
【０１０６】
図８は、表現式指向のステートメントをＸＭＬフラグメントに変換する方法を図示する。８０２において、表現式指向のステートメントが受け取られる。例えば、受け取りコンポーネントを使用し、構築コンポーネントからの表現式指向のステートメントを受領することができる。受け取られたステートメントは、８０４において変換され得る。図7を参照して説明したように、構築コンポーネントを使用し、ステートメントを変換することができる。８０６において、作成されるノードが親を持つべきかどうかの判定がされ得る。親を持つべきでない場合、８０８において、ＸＭＬフラグメントを変換された表現式から作成することができる。
【０１０７】
８０６において、作成されるべきノードが親を持つべきと判定される場合、ノードは、８１０において複製することができる。したがって、８１２において、親を割り当てることができる。図８の方法は、作成される各ノードに対して使用できることを認識されたい。
【０１０８】
ここで図９を参照すると、本発明の一態様による、ノードを修正することを容易にするシステム９００が示される。一般に、システム９００は、マークアップ言語コレクション２０４とインターフェースを取ることを容易にするＡＰＩコンポーネント２０２を含むことができる。マークアップ言語コレクション２０４は、文脈自由なおよび／またはドキュメント中心のノードを有する複数のＸＭＬのノードを含むことができることを認識されたい。
【０１０９】
ＡＰＩコンポーネント２０２は、オペレータコンポーネント９０２を有する修正コンポーネント２１０を含むことができる。オペレータコンポーネント９０２は、ノード自体、ノードの親、ノードの子などを取り扱うことを容易にすることができる。以下は、ノードの親を更新する（例えば、取り扱う）ステートメントの例示的なリストである。さらに、カレントノード自体を更新することの例が、その後に含まれる。
【０１１０】
親に対する更新
（void AddAfterThis(object content) {}）
このステートメントは新しい兄弟をノードに追加する。より具体的には、ステートメントは、親ノード内で当該ノードの後に専用化されたノードを追加することを容易にする。
【０１１１】
その他の例は以下の通りである。
【０１１２】
【表１１】
2009503679.tif 000013
【０１１３】
自身に対する更新
【０１１４】
【表１２】
2009503679.tif 000014
【０１１５】
構築コンポーネント２０８の機能に加えて、修正コンポーネント２１０は、オペレータコンポーネント９０２とともに、ユーザが同じ場所の更新を実行することを可能にする。言い換えると、修正コンポーネント２１０は、関数型の構築に加えてドキュメントに対する命令型の修正を可能にする。
【０１１６】
ここで図１０を参照すると、アプリケーションとマークアップ言語コンポーネント（例えば、ＸＭＬ）のインターフェースを取るように操作可能なコンピュータのブロック図が示されている。対象の発明の種々の態様にさらなる状況を与えるために、図１０および以下の検討は、その環境において本発明の種々の態様を実装することができる好適なコンピューティング環境１０００の簡潔で包括的な説明を提供するように意図される。１または複数のコンピュータ上で実行されることができるコンピュータが実行可能な命令との概括的な関連で本発明が上述されたが、当業者は本発明がその他のプログラムモジュールと組み合わせて、および／またはハードウェアおよびソフトウェアの組合せとして実装されることもできることを認識するであろう。
【０１１７】
一般に、プログラムモジュールは、特定のタスクを実行するか、または特定の抽象データ型を実装するルーチン、プログラム、コンポーネント、データ構造などを含む。さらに、当業者は、本発明の方法がシングルプロセッサまたはマルチプロセッサコンピュータシステム、ミニコンピュータ、メインフレームコンピュータ、さらにはパーソナルコンピュータ、ハンドヘルドコンピューティングデバイス、マイクロプロセッサベースのまたはプログラム可能な家庭用電化製品などを含む、それらの構成のそれぞれが１または複数の関連するデバイスに操作可能に結合されることができるその他のコンピュータシステム構成を用いて実施することができることを認識するであろう。
【０１１８】
本発明の示された態様は、通信ネットワークを通してリンクされたリモートの処理装置によって特定のタスクが実行される分散コンピューティング環境において実施することもできる。分散コンピューティング環境において、プログラムモジュールは、ローカルのメモリ記憶装置およびリモートのメモリ記憶装置の両方に配置することができる。
【０１１９】
通常、コンピュータは様々なコンピュータ読取可能媒体を含む。コンピュータ読取可能媒体は、コンピュータによってアクセスすることができ、揮発性および不揮発性両方の媒体、リムーバブルおよび非リムーバブル媒体を含む任意の入手可能な媒体であってよい。限定ではなく例として、コンピュータ読取可能媒体は、コンピュータ記憶媒体および通信媒体を備えることができる。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を記憶するための任意の方法または技術で実装された揮発性および不揮発性両方のリムーバブルおよび非リムーバブル媒体を含む。コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、またはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタルバーサタイルディスク（ＤＶＤ）、またはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、またはその他の磁気記憶装置、または所望の情報を記憶するために用いることができ、コンピュータによってアクセスすることができる任意のその他の媒体を含むがこれらに限定されない。
【０１２０】
通常、通信媒体は、キャリアウェーブなどの変調されたデータ信号またはその他のトランスポートメカニズムにコンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータを包含し、任意の情報配信媒体を含む。用語「変調されたデータ信号」は、その信号の特徴のうちの１つまたは複数を、信号中に情報をエンコードするようなやり方で設定または変更した信号を意味する。限定ではなく例として、通信媒体は、有線ネットワークまたは直接有線接続などの有線媒体、および音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体を含む。上記の媒体のうちの任意のものの組合せもコンピュータ読取可能媒体の範囲に含まれるべきである。
【０１２１】
再び図１０を参照すると、本発明の種々の態様を実装するための例示的な環境１０００はコンピュータ１００２を含み、当該コンピュータ１００２は処理ユニット１００４、システムメモリ１００６、およびシステムバス１００８を含む。システムバス１００８は、システムメモリ１００６を含むがこれに限定されないシステムコンポーネントを処理ユニット１００４に結合する。処理ユニット１００４は、様々な市販のプロセッサのいずれかであってよい。デュアルマイクロプロセッサおよびその他のマルチプロセッサアーキテクチャが処理ユニット１００４として使用することもできる。
【０１２２】
システムバス１００８は、各種の市販のバスアーキテクチャのうちのいずれかを使用した（メモリコントローラを備えるか、または備えない）メモリバス、周辺バス、およびローカルバスとさらに相互接続することができるいくつかの種類のバス構造のうちのいずれかであってよい。システムメモリ１００６は、読み出し専用メモリ（ＲＯＭ）１０１０およびランダムアクセスメモリ（ＲＡＭ）１０１２を含む。起動時などにコンピュータ１００２内の要素間で情報を転送することに役立つ基礎的なルーチンを含む基本入出力システム（ＢＩＯＳ）は、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭなどの不揮発性メモリ１０１０に格納される。ＲＡＭ１０１２は、キャッシュデータのためのスタティックＲＡＭなどの高速なＲＡＭも含むことができる。
【０１２３】
コンピュータ１００２は、好適なシャーシ（図示せず）の拡張した使用のために構成される内蔵ハードディスクドライブ（ＨＤＤ）１０１４（例えば、ＥＩＤＥ、ＳＡＴＡ）と、（例えば、リムーバブルディスケット１０１８から読み出すか、またはリムーバブルディスケット１０１８に書き込むための）磁気フロッピー（登録商標）ディスクドライブ（ＦＤＤ）１０１６と、（例えば、ＣＤ−ＲＯＭディスク１０２２を読み出すか、またはＤＶＤなどのその他の大容量光媒体から読み出すか、またはＤＶＤなどのその他の大容量光媒体に書き込むための）光ディスクドライブ１０２０とをさらに含む。ハードディスクドライブ１０１４、磁気ディスクドライブ１０１６、および光ディスクドライブ１０２０は、それぞれハードディスクドライブインターフェース１０２４、磁気ディスクドライブインターフェース１０２６、および光学ドライブインタ―フェース１０２８によってシステムバス１００８に接続することができる。外付け型のドライブの実装のためのインターフェース１０２４は、ユニバーサルシリアルバス（ＵＳＢ）およびＩＥＥＥ１３９４インターフェース技術のうちの少なくとも１つまたは両方を含む。その他の外付けドライブ接続技術は対象の発明の意図の範囲内である。
【０１２４】
これらのドライブおよびこれらのドライブの関連するコンピュータ読取可能媒体は、データ、データ構造、コンピュータが実行可能な命令などの不揮発性の記憶を提供する。コンピュータ１００２に関して、ドライブおよび媒体は、好適なデジタルフォーマットの任意のデータの記憶に順応する。上述のコンピュータ読取可能媒体の説明はＨＤＤ、リムーバブル磁気ディスク、およびＣＤまたはＤＶＤなどのリムーバブル光媒体に言及したが、ＺＩＰドライブ、磁気カセット、フラッシュメモリカード、カートリッジなどのコンピュータによって読み取り可能なその他の種類の媒体も例示的な操作環境において使用することができること、および、さらに任意のそのような媒体が本発明の方法を実行するためのコンピュータが実行可能な命令を含むことができることを当業者は認識すべきである。
【０１２５】
オペレーティングシステム１０３０、１または複数のアプリケーションプログラム１０３２、その他のプログラムモジュール１０３４、およびプログラムデータ１０３６を含むいくつかのプログラムモジュールは、ドライブおよびＲＡＭ１０１２に記憶することができる。オペレーティングシステム、アプリケーション、モジュール、および／またはデータのうちのすべてまたは一部はＲＡＭ１０１２にキャッシュすることもできる。本発明は種々の市販のオペレーティングシステムまたはオペレーティングシステムの組合せを用いて実装できることを認識されたい。
【０１２６】
ユーザは、１または複数の有線／無線入力デバイス、例えばキーボード１０３８、およびマウス１０４０などのポインティングデバイスを通じてコンピュータ１００２にコマンドおよび情報を入力することができる。その他の入力デバイス（図示せず）は、マイクロホン、ＩＲリモコン、ジョイスティック、ゲームパッド、スタイラスペン、タッチスクリーンなどを含むことができる。これらのおよびその他の入力デバイスは、システムバス１００８に結合される入力デバイスインターフェース１０４２を通じて処理ユニット１００４に接続されることが多いが、パラレルポート、ＩＥＥＥ１３９４シリアルポート、ゲームポート、ＵＳＢポート、ＩＲインターフェースなどのその他のインターフェースによって接続することができる。
【０１２７】
モニタ１０４４またはその他の種類のディスプレイデバイスも、ビデオアダプタ１０４６などのインターフェースを介してシステムバス１００８に接続される。モニタ１０４４に加えて、一般にコンピュータは、スピーカ、プリンタなどのその他の周辺出力デバイス（図示せず）を含む。
【０１２８】
コンピュータ１００２は、１または複数のリモートコンピュータ１０４８などの１または複数のリモートコンピュータへの有線および／または無線通信を介した論理接続を使用するネットワーク化された環境で操作することができる。１または複数のリモートコンピュータ１０４８は、ワークステーション、サーバコンピュータ、ルータ、パーソナルコンピュータ、ポータブルコンピュータ、マイクロプロセッサベースの娯楽用の家庭用電化製品、ピアデバイス、またはその他の普通のネットワークノードであってよく、一般にコンピュータ１００２に関連して説明した要素の多くまたはすべてを含むが、簡潔にする目的でメモリ／記憶装置１０５０のみを示す。表した論理接続は、ローカルエリアネットワーク（ＬＡＮ）１０５２および／またはより大きなネットワーク、例えばワイドエリアネットワーク（ＷＡＮ）１０５４への有線／無線の接続を含む。そのようなＬＡＮおよびＷＡＮネットワークキング環境はオフィスおよび会社において普通であり、イントラネットなどの企業規模のコンピュータネットワークを容易にし、それらのネットワークのすべてはグローバルな通信ネットワーク、例えばインターネットに接続することができる。
【０１２９】
ＬＡＮネットワーキング環境において使用されるとき、コンピュータ１００２は、有線および／または無線通信ネットワークインターフェースまたはアダプタ１０５６を通じてローカルネットワーク１０５２に接続される。アダプタ１０５６はＬＡＮ１０５２への有線または無線通信を容易にすることができ、そのＬＡＮ１０５２は無線アダプタ１０５６と通信するためにそのＬＡＮ１０５２上に配置された無線アクセスポイントも含むことができる。
【０１３０】
ＷＡＮネットワーキング環境において使用されるとき、コンピュータ１００２は、モデム１０５８を含むことができるか、またはＷＡＮ１０５４上の通信サーバに接続されるか、またはインターネットを経由するなど、ＷＡＮ１０５４を介して通信を確立するためのその他の手段を有する。内蔵かまたは外付けであることができ、有線または無線デバイスであることができるモデム１０５８は、シリアルポートインターフェース１０４２を介してシステムバス１００８に接続される。ネットワーク化された環境において、コンピュータ１００２に関連して表されたプログラムモジュール、またはそのモジュールの一部は、リモートのメモリ／記憶装置１０５０に記憶することができる。示したネットワーク接続は例示的であり、コンピュータ間で通信リンクを確立するその他の手段を使用することができることが認識されるであろう。
【０１３１】
コンピュータ１００２は、無線通信において操作可能に配置された任意の無線デバイスまたはエンティティ、例えば、プリンタ、スキャナ、デスクトップおよび／またはポータブルコンピュータ、携帯情報端末、通信衛星、無線で検出可能なタグに関連する任意の設備または場所（例えば、キオスク、新聞雑誌の売店、休憩室）、および電話と通信するように操作可能である。これは、少なくともＷｉ−ＦｉおよびＢｌｕｅｔｏｏｔｈ（商標）無線技術を含む。したがって、通信は、標準的なネットワークと同様に既定の構造であるか、または単純に少なくとも２つのデバイスの間の臨時の通信であることができる。
【０１３２】
Ｗｉ−Ｆｉ、すなわちワイヤレスフィデリティは、家のカウチ、ホテルの部屋のベッド、または仕事中に会議室から配線なしにインターネットに接続できるようにする。Ｗｉ−Ｆｉは、そのようなデバイス、例えばコンピュータが屋内でも屋外でも、すなわち基地局の範囲内のどこででもデータを送受信できるようにする、携帯電話に使用される無線技術と同様の無線技術である。Ｗｉ−Ｆｉネットワークは、ＩＥＥＥ８０２．１１（ａ、ｂ、ｇなど）と呼ばれる無線技術を使用して、安全で、信頼でき、高速な無線接続性を提供する。Ｗｉ−Ｆｉネットワークは、コンピュータを互いに、インターネットに、および（ＩＥＥＥ８０２．３またはイーサネット（登録商標）を使用する）有線ネットワークに接続するために使用することができる。Ｗｉ−Ｆｉネットワークは、例えば、未認可の２．４および５ＧＨｚ無線帯域において１１Ｍｂｐｓ（８０２．１１ａ）または５４Ｍｂｐｓ（８０２．１１ｂ）のデータ転送速度で、または両方の帯域（デュアルバンド）を含む製品を用いて操作し、したがってネットワークは多くのオフィスで使用される１０ＢａｓｅＴ有線イーサネット（登録商標）と同様の実効性能を提供することができる。
【０１３３】
ここで図１１を参照すると、対象のＡＰＩの態様による例示的なコンピューティング環境１１００の概略ブロック図が示されている。システム１１００は、１または複数のクライアント１１０２を含む。１または複数のクライアント１１０２は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）であってよい。１または複数のクライアント１１０２は、例えば、本発明を使用することによって、１または複数のクッキーおよび／または関連するコンテキスト情報を蓄えることができる。
【０１３４】
システム１１００は、１または複数のサーバ１１０４も含む。１または複数のサーバ１１０４もまた、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）であってよい。サーバ１１０４は、例えば、本発明を使用することによって変換を実行するためのスレッドを蓄えることができる。クライアント１１０２とサーバ１１０４の間の１つの可能な通信は、２つ以上のコンピュータプロセス間で送信されるように適合されたデータパケットの形態であることができる。データパケットは、例えば、クッキーおよび／または関連するコンテキスト情報を含むことができる。システム１１００は、１または複数のクライアント１１０２と１または複数のサーバ１１０４の間の通信を容易にするために使用することができる通信フレームワーク１１０６（例えば、インターネットなどのグローバルな通信ネットワーク）を含む。
【０１３５】
通信は、（光ファイバを含む）有線および／または無線技術を介して容易にすることができる。１または複数のクライアント１１０２は、１または複数のクライアント１１０２に対してローカルの情報（例えば、１または複数のクッキーおよび／または関連するコンテキスト情報）を記憶するために使用することができる１または複数のクライアントデータストア１１０８に操作可能に接続される。同様に、１または複数のサーバ１１０４は、サーバ１１０４に対してローカルの情報を記憶するために使用することができる１または複数のサーバデータストア１１１０に操作可能に接続される。
【０１３６】
上述された内容は本発明の例を含む。言うまでもなく、対象の発明を説明する目的でコンポーネントまたは方法の考えられるあらゆる組合せを説明することは不可能であるが、当業者は本発明の多くのさらなる組合せおよび変更が可能であることを認識するであろう。したがって、本発明は、添付の特許請求の範囲の概念および範囲内にあるすべてのそのような改変形態、修正形態、および変形形態を包含するように意図される。さらに、用語「含む（includes）」が発明を実施するための最良の形態、または特許請求の範囲のいずれかで使用される限りにおいて、かかる用語は、請求項で移行語として使用される場合に「備える（comprising）」が解釈されるように、用語「備える（comprising）」と同様にして包括的であるように意図される。
【図面の簡単な説明】
【０１３７】
【図１】本発明の一態様による、アプリケーションとマークアップ言語コンポーネントの間のインターフェースを取るオブジェクトモデルを容易にするシステムを示す図である。
【図２】ＡＰＩ（Application Program Interface）の一態様による、ナビゲーションコンポーネント、構築コンポーネント、および修正コンポーネントを有するＡＰＩのブロック図である。
【図３】本発明の一態様による、ナビゲーションコンポーネントおよび受け取りコンポーネントを有するＡＰＩシステムのブロック図である。
【図４】本発明の一態様による、軸コンポーネント、ソートコンポーネント、および名前空間コンポーネントを有するナビゲーションコンポーネントを示す図である。
【図５】本発明の一態様による、マークアップ言語コンポーネント内をナビゲートすることを容易にする手順の例示的なフローチャートである。
【図６】本発明の一態様による、構築コンポーネントおよび受け取りコンポーネントを有するＡＰＩシステムのブロック図である。
【図７】本発明の一態様による、表現式指向のステートメントを使用し、文脈自由なノードを構築するシステムを示す図である。
【図８】一態様による、文脈自由な（例えば、ノード中心の）ノードを構築することを容易にする手順の例示的なフローチャートである。
【図９】本発明の一態様による、修正コンポーネントおよびオペレータコンポーネントを有するＡＰＩシステムのブロック図である。
【図１０】開示されたアーキテクチャを実行するように操作可能なコンピュータのブロック図である。
【図１１】対象の発明による例示的なコンピューティング環境の概略ブロック図である。
【図１】
2009503679.tif 000015
【図２】
2009503679.tif 000016
【図３】
2009503679.tif 000017
【図４】
2009503679.tif 000018
【図５】
2009503679.tif 000019
【図６】
2009503679.tif 000020
【図７】
2009503679.tif 000021
【図８】
2009503679.tif 000022
【図９】
2009503679.tif 000023
【図１０】
2009503679.tif 000024
【図１１】
2009503679.tif 000025
【手続補正書】
【提出日】平成20年10月3日(2008.10.3)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
拡張可能マークアップ言語（ＸＭＬ）データとのインタラクションを容易にするアプリケーションプログラムインターフェース（ＡＰＩ）システムであって、
前記インタラクションと関連するデータを格納するメモリと、
簡略化された非イベントストリームベースのＤＯＭアプローチを使用し、且つ複数のＸＭＬのノードの型を区別する、オブジェクトモデルコンポーネントと、
アプリケーションとインターフェースを取り、前記オブジェクトモデルと整合性があり且つ要素と属性を同じ手法で選択する表現式指向のフォーマットのデータを受け取る、受け取りコンポーネントと、
前記受け取られたデータを使用して前記ＸＭＬデータの構築、照会、および修正を容易にするアクションコンポーネントであって、ドキュメントコンテキストから独立している少なくとも１つのＸＭＬフラグメントを前記受け取られたデータの少なくとも一部に基づいて生成し、前記生成されたＸＭＬフラグメントの構造とアイソモアフィックな単一のネストされた表現式を使用する構築コンポーネントを含む、アクションコンポーネントと
を備えることを特徴とするＡＰＩシステム。
【請求項２】
前記複数のＸＭＬのノードの型は、
名前空間統一資源識別子（ＵＲＩ）およびローカル名から成る１または複数の汎用的な名前を表す型、XNameと、
１または複数の属性を表す型、XAttributeと、
１または複数のＸＭＬの子ノード型のための抽象ベースクラスを表す型、XNodeと、
１または複数のＸＭＬのコメントを表す型、XCommentと、
１または複数のＸＭＬの処理命令を表す型、XProcessingInstructionと、
１または複数のＸＭＬ宣言を表す型、XDeclarationと、
ＸＭＬのドキュメント型の宣言を表す型、XDocumentTypeと、
文字データのためのベースクラスを表す抽象型、XCharacterNodeと、
１または複数のＸＭＬのCDataセクションを表す抽象型、XCDataと、
子を有する１または複数のノードを表す抽象型、XContainerと、
前記XContainerが１または複数のＸＭＬの要素を表す型、XElementと、
完全なＸＭＬドキュメントを表す型、XDocumentと
のうちの少なくとも１を含むことを特徴とする請求項１に記載のシステム。
【請求項３】
前記アクションコンポーネントは、親と、要素と、属性と、子孫と、自身および子孫と、祖先と、自身および祖先とのうちの少なくとも１を含む軸を表示することを特徴とする請求項１に記載のシステム。
【請求項４】
ドキュメントの順序によって照会結果のデータセットを明示的にソートするソートコンポーネントをさらに備えることを特徴とする請求項３に記載のシステム。
【請求項５】
前記軸は、単一のアイテムおよびソースコレクションのうちの一方に対して作業し、前記軸は、戻り値を特定の名前および特定の型のうちの少なくとも１つを有するノードに制限することを容易にすることを特徴とする請求項３に記載のシステム。
【請求項６】
前記アクションコンポーネントは、前記表現式指向のフォーマットで受け取られる前記データの少なくとも一部に基づいて前記ＸＭＬデータの変更を容易にする修正コンポーネントを含むことを特徴とする請求項１に記載のシステム。
【請求項７】
前記修正コンポーネントは、ノードに対するアクションを識別するオペレータコンポーネントを含むことを特徴とする請求項６に記載のシステム。
【請求項８】
前記アクションは、
受け取りノードに関する親に対する更新であって、前記親にアイテムを追加することと、前記親にアイテムのコレクションを追加することと、受け取りノードの親から前記受け取りノードを削除することとのうちの少なくとも１を含む更新と、
前記受け取りノードおよび受け取りノードのコレクションのうちの少なくとも一方に対する更新であって、前記受け取りノードにアイテムを追加することと、前記受け取りノードに子のコレクションを追加することと、前記受け取りノードの子を削除することと、前記受け取りノードの前記子を単一のアイテムで置き換えることと、前記受け取りノードの前記子をアイテムのコレクションで置き換えることと、属性を追加することと、属性を削除することと、指定された子ノードのコンテンツを置き換えることと、前記受け取りノードの属性を置き換えることとのうちの少なくとも１を含む更新と
のうちの少なくとも１であることを特徴とする請求項７に記載のシステム。
【請求項９】
アプリケーションとＸＭＬデータとのインターフェースを取る方法であって、
簡略化された非イベントストリームベースのＤＯＭアプローチを使用し、且つ複数のＸＭＬのノードの型を区別する、オブジェクトモデルを確立するステップと、
前記オブジェクトモデルと整合性があり且つ要素および属性を同じ手法で選択する、表現式指向のステートメントを受け取るステップと、
前記受け取られた表現式指向のステートメントの少なくとも一部に基づいてＸＭＬデータを構築し、照会し、修正するステップであって、前記ＸＭＬデータが、ドキュメントコンテキストと独立であり、構築される前記ＸＭＬフラグメントの構造とアイソモアフィックな単一のネストされた表現式を有する前記受け取られた表現式指向のステートメントを使用することによって生成される、少なくとも１つのノード中心のＸＭＬフラグメントを含むステップと
を備えることを特徴とする方法。
【請求項１０】
前記ＸＭＬデータを構築するステップは、少なくとも１つのＸＭＬフラグメントを生成するステップを含むことを特徴とする請求項９に記載の方法。
【請求項１１】
前記複数のＸＭＬのノードの型は、
名前空間統一資源識別子（ＵＲＩ）およびローカル名から成る１または複数の汎用的な名前を表す型、XNameと、
１または複数の属性を表す型、XAttributeと、
１または複数のＸＭＬの子ノード型のための抽象ベースクラスを表す型、XNodeと、
１または複数のＸＭＬのコメントを表す型、XCommentと、
１または複数のＸＭＬの処理命令を表す型、XProcessingInstructionと、
１または複数のＸＭＬ宣言を表す型、XDeclarationと、
ＸＭＬのドキュメント型宣言を表す型、XDocumentTypeと、
文字データのためのベースクラスを表す抽象型、XCharacterNodeと、
１または複数のＸＭＬのCDataセクションを表す抽象型、XCDataと、
子を有する１または複数のノードを表す抽象型、XContainerと、
前記XContainerが１または複数のＸＭＬの要素を表す型、XElementと、
完全なＸＭＬドキュメントを表す型、XDocumentと
のうちの少なくとも１つを含むことを特徴とする請求項９に記載の方法。
【請求項１２】
親と、要素と、属性と、子孫と、自身および子孫と、祖先と、自身および祖先の少なくとも１を含む軸を表示するステップをさらに備えることを特徴とする請求項９に記載の方法。
【請求項１３】
ドキュメントの順序によって照会結果のデータセットを明示的にソートするステップをさらに備えることを特徴とする請求項９に記載のシステム。
【請求項１４】
請求項９に記載の方法を実行するためのコンピュータ実行可能命令を格納していることを特徴とするコンピュータ読取可能な記録媒体。
【請求項１５】
アプリケーションとＸＭＬデータの間のインタラクションを容易にするシステムであって、
前記インタラクションに関連するデータを格納する手段と、
簡略化された非イベントストリームベースのＤＯＭアプローチを使用し、且つ複数のＸＭＬのノードの型を区別する、オブジェクトモデルを識別する手段と、
マークアップ言語コンポーネントに対するアクションを容易にするために、前記オブジェクトモデルの少なくとも一部に基づいて、要素と属性を同じ手法で選択する表現式指向のステートメントを使用する手段であって、前記アクションは、コンテナドキュメントと独立であり且つ構築されるべき前記ＸＭＬフラグメントの構造とアイソモアフィックな単一のネストされた表現式を有する受信した表現式指向のステートメントを使用することによって生成される、１つまたは複数のノード中心ＸＭＬフラグメントを備えるＸＭＬデータを構築することを含む、手段と、
前記表現式指向のステートメントを使用することによって前記ＸＭＬデータを照会する手段と、
現式指向のステートメントを使用することによって前記ＸＭＬデータを修正する手段と
を備えることを特徴とするシステム。
【請求項１６】
前記複数のＸＭＬのノードの型は、
名前空間統一資源識別子（ＵＲＩ）およびローカル名から成る１または複数の汎用的な名前を表す型、XNameと、
１または複数の属性を表す型、XAttributeと、
１または複数のＸＭＬの子ノード型のための抽象ベースクラスを表す型、XNodeと、
１または複数のＸＭＬのコメントを表す型、XCommentと、
１または複数のＸＭＬの処理命令を表す型、XProcessingInstructionと、
１または複数のＸＭＬ宣言を表す型、XDeclarationと、
ＸＭＬのドキュメント型宣言を表す型、XDocumentTypeと、
文字データのためのベースクラスを表す抽象型、XCharacterNodeと、
１または複数のＸＭＬのCDataセクションを表す抽象型、XCDataと、
子を有する１または複数のノードを表す抽象型、XContainerと、
前記XContainerが１または複数のＸＭＬの要素を表す型、XElementと、
完全なＸＭＬドキュメントを表す型、XDocumentと
のうちの少なくとも１つを含むことを特徴とする請求項１５に記載のシステム。
【国際調査報告】
2009503679.tif 000026
2009503679.tif 000027