JP4384247B2 - 拡張可能マークアップ言語（ｘｍｌ）のための軽量なアプリケーションプログラムインターフェース（ａｐｉ） - Google Patents

Description

本発明は、拡張可能マークアップ言語（ＸＭＬ）のための軽量なアプリケーションプログラムインターフェース（ＡＰＩ）に関する。

マークアップ言語およびそれらのマークアップ言語に関連するアプリケーションは、発展を続け、今日のコンピューティング環境において一般的になりつつある。一般に、マークアップ言語は、テキスト内に組み込まれた１組のラベルを記述し、表示または識別の目的のために、要素のグループまたは個別の要素を区別する。典型的には、ラベルは「タグ」として知られている。マークアップ言語は、データベース内のより構造化されたデータではなくテキストの連続的なストリーム内の要素を識別する。１つの特定のマークアップ言語、ＸＭＬ（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）を使用する照会の実装を対象とする。本質的に、ユーザが照会を実行することができる２つのやり方がある。１つは実際のコレクション（例えば、メモリコレクション中）上であり、もう１つはリモートコレクション上である。リモートコレクションのシナリオにおいて、照会はデリゲートによって表すのではなく、むしろ式ツリーによって表すことができる。したがって、システムは、本質的に異なるステップで照会を実行するのではなく全体の照会を使用する。

ここで図４を参照すると、ＸＭＬに関して、オブジェクトモデル１０８に関する軸の概念が示され、ナビゲーションコンポーネント２０６のメカニズムを示す。より具体的には、軸コンポーネント４０２は、ＸＭＬのノードのコレクション２０４において指定のノード３０２からその他のノード３０２へナビゲートするメカニズムを表す。ＸＭＬ構造におけるコレクション２０４は、相互に関連するノード３０２から構築された階層ツリーで表すことができることを理解されたい。したがって、軸コンポーネント４０２は、構造中をナビゲートすることを容易にすることができる方法である。例として、構造中の特定の所で、軸コンポーネント４０２は、指定のノードの親、指定のノードの子のすべてなどの識別を可能にすることができる。オブジェクトモデル１０８に関するマッピングコンポーネント（図示せず）は、ツリー中のそのようなナビゲーションおよび／または方向性を持った移動を容易にすることができる。

ノードまたはノードのコレクション（例えば、３０２）を考える場合、ユーザは、ツリー中を全検索し、その子、親など、またはその属性を識別すること望むかもしれない。ＡＰＩ２０２は、属性および要素にアクセスするための種々の軸（例えば、４０２）に対応するいくつかの新規の方法および／またはメカニズムを含む。

例えば、これらの例示的な軸の表現式は、対応する軸関数によって表すことができる。以下の例において、従来のＸＰａｔｈタイプの表現式が左側の列に列挙される。ＡＰＩ２０２の一態様に関する軸の表現式は、右側の列に列挙される。

一般に、軸関数４０２は、機能の様々なレベルを含むことができる。例えば、軸関数は、単一のアイテムに対して、またはソースコレクション上で使用することができる。それゆえ、要望に応じて、軸コンポーネント４０２は、戻り値を特定の名前を有するノードに制限することができる。したがって、ユーザは、コレクション上の検索を制限することができる。さらなる例として、ユーザは、特定のノードの子要素のすべて、または所定の名前を共有する子要素のすべてに関してコレクションに照会することができる。

その上、軸関数を、特定の型の返り値を制限するために使用することができる。このことは、値を検索するとき（例えば、文字列型または整数型の値のみを提供するとき）に特に有用である可能性がある。

結果として、本発明は、各軸（例えば、子孫、自身および子孫）に関するいくつかの多重定義を使用する。この検討にコンテキストを提供するため、以下は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) {}）
同様に、この軸は、特定の名前の要素のみをレンダーする。さらに、以下の３つの軸は上述した機能のバリエーションである。

この軸は、特有の名前を有する属性を返す。

この場合も、XElementに関して上述したように、XAttributeは同様にコレクション上に多重定義することができる。以下は本発明による多重定義の例示的態様である。

この関数は、孫およびひ孫などをレンダーする。実際上、この軸関数はノードの子のすべてを再帰的に返す。

（IEnumerable<T> Descendants<T>() where T : class {}）
これは、所定の型の子孫を取り除くことができる。

その他の軸の例は以下を含む。

図示している通り、上記は本発明による例示的な軸である。これらの軸はシングルコレクションに対して使用することができ、コレクションを返すことができることを理解されたい。

対象の発明は要素と属性の間の対称性を可能にすることを理解されたい。例えば、上述の特徴において示したように、要素および属性は、従来のＡＰＩでのように方法（例えば、属性（“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を明示的に構築する必要はない。

上で示している通り、XNameクラスは、これらの文字列を入力する。そのため、これらの名前は、これらの名前がXNameの参照を介して比較されるので、文字列としては比較されない。対象のＡＰＩ２０２は、文字列からの暗黙的な演算子を提供するので、ユーザがこのXNameを明示的に作成することは不要である。

図５は、本発明の一態様による、マークアップ言語（例えば、ＸＭＬ）のノードの構造（例えば、コレクション）中をナビゲートする方法のプロセスフロー図を図示する。説明の簡素化の目的で、例えばフローチャートの形式で本明細書に示す１または複数の方法を、一連の操作として示し説明するが、本発明によればいくつかの操作は異なる順序で、および／または本明細書に示し説明する操作とは別の操作と並行して行うことができるので、対象の発明は、その操作の順序によって限定されないことを理解し、認識されたい。例えば、当業者は、方法を、状態遷移などのような一連の相互関係のある状態またはイベントとして代替的に表すことができるであろうことを理解し、認識するであろう。さらに、図示した全ての操作が、本発明による方法を実装するために必要とされるわけではない可能性がある。

５０２において、ナビゲーション表現式が受け取られる。上述のように、ナビゲーション表現式は、コレクション内の１または複数の所望のターゲット（例えば、値）を識別する軸ステートメントであってよい。例えば、ナビゲーション表現式は特定のノードの親を要求することができる。

ナビゲーション表現式（例えば、軸）は、５０４において分析することができる。本質的に異なる例において、ナビゲーション表現式は特定のノードの親、親の親、兄弟などを要求することができる。したがって、コンテキストノードを、５０６において識別することができる。このコンテキストノードは、ナビゲーション表現式の開始点を定義することができる。さらに、ナビゲーションの方向を、５０８において決定することができる。

ナビゲーション表現式を満たすノードを、５１０において識別することができる。５１２において、さらなるノードが存在するかどうかの判定をすることができる。さらなるノードが構造（例えば、ツリー）内に存在する場合、プロセスは５１０に戻ることができ、その結果、１または複数のさらなるノードを識別する。さらなるノードが存在しない場合、停止ブロックが到達される。

ここで図６を参照すると、本発明のさらに別の態様によるシステム６００が示される。より具体的には、図６は、ＸＭＬの文脈自由なフラグメント、ノード、またはノードのコレクションの構築を容易にするシステム６００を示す。従来、ＸＭＬのＡＰＩは構造において命令型である。言い換えると、ＸＭＬのノードは、構造化されたコマンドおよび特定のシーケンスのコマンドを介して構築される。例として、命令型のコマンドのシーケンスは、ノードを定義することから始まり、１つの子、別の子などを追加することによって継続する。

対象のＡＰＩコンポーネント２０２は、コマンド（例えば、表現式）を受領する受け取りコンポーネント２１２を使用することができる。構築コンポーネント２０８は、オブジェクトモデル１０８とともに、表現式をＸＭＬフラグメントまたはコレクション２０４に変換することができる。

図７は、システム６００の代替的なブロック図を図示する。図示する通り、構築コンポーネント２０８は、表現式指向言語コンポーネント７０２を受け取ることができる。したがって、構築コンポーネント２０８は、オブジェクトモデルコンポーネント１０８に基づいて、表現式指向言語コンポーネント７０２をノードのマークアップ言語コレクション７０４に変換するために使用することができる。図示する通り、マークアップ言語コレクション７０４は、１からＰまでの文脈自由ノードコンポーネントを含むことができ、ここでＰは整数である。１からＰまでの文脈自由ノードコンポーネントは、個々にまたは集合的に文脈自由ノードコンポーネント７０６として参照され得ることを理解されたい。

照会の作業を容易にするために、対象の発明は、表現式指向のメカニズム（例えば、表現式指向言語コンポーネント７０２）を使用してＸＭＬのノード（例えば、構築コンポーネント２０８）を構築する。命令型ステートメントを使用して１または複数のＸＭＬコレクションを作成するのではなく、対象の発明はノードを作成する新規の表現式指向の方法を利用する。認識されるように、標準的なシステムおよび方法においては、ＸＭＬのノードは、ドキュメント中心である。言い換えると、標準的なＸＭＬのノードは、ドキュメントのコンテキスト内にのみ存在する。これらの従来のノードは、独立して存在することができない。そのことと対称的に、対象のＡＰＩ２０２は、ドキュメントから独立して存在することができる文脈自由なノードを生成する。

文脈自由ノードコンポーネント７０６の新規の特徴は、これらの文脈自由ノードコンポーネント７０６を独立して作成することができ、その他のノードの子として使用することができることである。したがって、従来のシステムと対称的に、および対象のＡＰＩ２０２に基づくと、文脈自由ノードコンポーネント７０６は、本質的にドキュメントのコンテキスト内に存在する必要はない。

操作において、ノードが作成されるとき、そのノードは、親を持たない。ノードは新たに作成されるので、その作成されるノードは任意の他のノードの子として存在しない。本発明の新規の特徴は、ノードが別のノードの子として指定されるとき、またはそこで照会が子として含まれるべきノードを返す場合に、ノードが既に親を持っていると構築コンポーネント２０８がノードを自動的に複製することができることである。これらのノードは１つの親のみを有することができることを理解されたい。したがって、異なるノードがノードの親として選択される場合、ノードは自動的に複製され、それによって親子関係が許される。対称的に、標準的なＡＰＩは、ユーザに明示的にノードを複製することを要求する。

システム６００の構築コンポーネント２０８は、ノードに対して親が存在するかどうかを判定するために自動的にチェックを行うことができる。存在する場合、構築コンポーネント２０８は自動的に複製を行い、新しい親、すなわち複製の親を指定することができる。この複製の結果は、新規の文脈自由なノードの構築である。

親を持つノードが新しいノードの構築のために用いられるとき、それらの親を持つノードは新しく構築されるノードの構造を維持するために自動的に複製され得る。しかし、ノードは、親を持っている必要はなく、特に、ノードはドキュメントから独立して存在することができる。以下の例は、本発明にコンテキストを与えるために提供するものであり、したがって、本開示を限定することはいっさい意図していない。

上記の例は、以下の構造をレンダーする。

以下は、ＡＰＩ２０２の一態様に基づいて最終的に作成することができるＸＭＬフラグメントの検討である。前の例が示すように、ＸＭＬフラグメントおよびドキュメントは、ステートメントのシーケンスを介した命令型の手段の代わりに、関数型のまたは表現式ベースの手段で構築される。例えば、以下の階層的なＸＭＬ要素は、以下に図示するように表現式指向の手段を利用して作成することができる。

上記ＸＭＬフラグメントは、本発明のＡＰＩ２０２を対応するサブコンポーネント（例えば、構築コンポーネント２０８、オブジェクトモデル１０８）とともに用いることによって作成することができる。操作において、結果として得られる要素の構造とアイソモアフィックの単一のネストされた表現式を、記述することができる。例えば以下である。

標準的なＡＰＩを使用して上記ＸＭＬフラグメントを作成することはあまりにも煩雑である。標準的なＸＭＬ ＤＯＭなどの既存のＡＰＩを使用する場合、ユーザは、初めにコンテナードキュメントを組み込む必要がある。次に、要素および属性は、そのドキュメントのコンテキスト内で命令的に作成される必要がある。さらに、ユーザは、これらのノードをその他のノードの子として命令的に割り当てる必要がある。以下は、標準的なＡＰＩによるこのプロセスの一例である。

ユーザが照会の結果として新しいＸＭＬフラグメントを返すことを望む場合、そのフラグメントがいつも特定のドキュメントのコンテキスト内にあるわけではないので、この標準的な方法は照会において用いることができないことが認識されるであろう。その一方、（対象のＡＰＩ２０２に基づいて説明したように）文脈自由な構造を作成する能力は、ＸＭＬフラグメントの直接的な照会を容易にする。照会することに関するＡＰＩ２０２の態様は、ユーザが表現式として独自のものを作成することができるという事実に依拠する。

図８は、表現式指向のステートメントをＸＭＬフラグメントに変換する方法を図示する。８０２において、表現式指向のステートメントが受け取られる。例えば、受け取りコンポーネントを使用し、構築コンポーネントからの表現式指向のステートメントを受領することができる。受け取られたステートメントは、８０４において変換され得る。図7を参照して説明したように、構築コンポーネントを使用し、ステートメントを変換することができる。８０６において、作成されるノードが親を持つべきかどうかの判定がされ得る。親を持つべきでない場合、８０８において、ＸＭＬフラグメントを変換された表現式から作成することができる。

８０６において、作成されるべきノードが親を持つべきと判定される場合、ノードは、８１０において複製することができる。したがって、８１２において、親を割り当てることができる。図８の方法は、作成される各ノードに対して使用できることを認識されたい。

ここで図９を参照すると、本発明の一態様による、ノードを修正することを容易にするシステム９００が示される。一般に、システム９００は、マークアップ言語コレクション２０４とインターフェースを取ることを容易にするＡＰＩコンポーネント２０２を含むことができる。マークアップ言語コレクション２０４は、文脈自由なおよび／またはドキュメント中心のノードを有する複数のＸＭＬのノードを含むことができることを認識されたい。

ＡＰＩコンポーネント２０２は、オペレータコンポーネント９０２を有する修正コンポーネント２１０を含むことができる。オペレータコンポーネント９０２は、ノード自体、ノードの親、ノードの子などを取り扱うことを容易にすることができる。以下は、ノードの親を更新する（例えば、取り扱う）ステートメントの例示的なリストである。さらに、カレントノード自体を更新することの例が、その後に含まれる。

親に対する更新
（void AddAfterThis(object content) {}）
このステートメントは新しい兄弟をノードに追加する。より具体的には、ステートメントは、親ノード内で当該ノードの後に専用化されたノードを追加することを容易にする。

その他の例は以下の通りである。

自身に対する更新

構築コンポーネント２０８の機能に加えて、修正コンポーネント２１０は、オペレータコンポーネント９０２とともに、ユーザが同じ場所の更新を実行することを可能にする。言い換えると、修正コンポーネント２１０は、関数型の構築に加えてドキュメントに対する命令型の修正を可能にする。

ここで図１０を参照すると、アプリケーションとマークアップ言語コンポーネント（例えば、ＸＭＬ）のインターフェースを取るように操作可能なコンピュータのブロック図が示されている。対象の発明の種々の態様にさらなる状況を与えるために、図１０および以下の検討は、その環境において本発明の種々の態様を実装することができる好適なコンピューティング環境１０００の簡潔で包括的な説明を提供するように意図される。１または複数のコンピュータ上で実行されることができるコンピュータが実行可能な命令との概括的な関連で本発明が上述されたが、当業者は本発明がその他のプログラムモジュールと組み合わせて、および／またはハードウェアおよびソフトウェアの組合せとして実装されることもできることを認識するであろう。

一般に、プログラムモジュールは、特定のタスクを実行するか、または特定の抽象データ型を実装するルーチン、プログラム、コンポーネント、データ構造などを含む。さらに、当業者は、本発明の方法がシングルプロセッサまたはマルチプロセッサコンピュータシステム、ミニコンピュータ、メインフレームコンピュータ、さらにはパーソナルコンピュータ、ハンドヘルドコンピューティングデバイス、マイクロプロセッサベースのまたはプログラム可能な家庭用電化製品などを含む、それらの構成のそれぞれが１または複数の関連するデバイスに操作可能に結合されることができるその他のコンピュータシステム構成を用いて実施することができることを認識するであろう。

本発明の示された態様は、通信ネットワークを通してリンクされたリモートの処理装置によって特定のタスクが実行される分散コンピューティング環境において実施することもできる。分散コンピューティング環境において、プログラムモジュールは、ローカルのメモリ記憶装置およびリモートのメモリ記憶装置の両方に配置することができる。

通常、コンピュータは様々なコンピュータ読取可能媒体を含む。コンピュータ読取可能媒体は、コンピュータによってアクセスすることができ、揮発性および不揮発性両方の媒体、リムーバブルおよび非リムーバブル媒体を含む任意の入手可能な媒体であってよい。限定ではなく例として、コンピュータ読取可能媒体は、コンピュータ記憶媒体および通信媒体を備えることができる。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を記憶するための任意の方法または技術で実装された揮発性および不揮発性両方のリムーバブルおよび非リムーバブル媒体を含む。コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、またはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタルバーサタイルディスク（ＤＶＤ）、またはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、またはその他の磁気記憶装置、または所望の情報を記憶するために用いることができ、コンピュータによってアクセスすることができる任意のその他の媒体を含むがこれらに限定されない。

通常、通信媒体は、キャリアウェーブなどの変調されたデータ信号またはその他のトランスポートメカニズムにコンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータを包含し、任意の情報配信媒体を含む。用語「変調されたデータ信号」は、その信号の特徴のうちの１つまたは複数を、信号中に情報をエンコードするようなやり方で設定または変更した信号を意味する。限定ではなく例として、通信媒体は、有線ネットワークまたは直接有線接続などの有線媒体、および音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体を含む。上記の媒体のうちの任意のものの組合せもコンピュータ読取可能媒体の範囲に含まれるべきである。

再び図１０を参照すると、本発明の種々の態様を実装するための例示的な環境１０００はコンピュータ１００２を含み、当該コンピュータ１００２は処理ユニット１００４、システムメモリ１００６、およびシステムバス１００８を含む。システムバス１００８は、システムメモリ１００６を含むがこれに限定されないシステムコンポーネントを処理ユニット１００４に結合する。処理ユニット１００４は、様々な市販のプロセッサのいずれかであってよい。デュアルマイクロプロセッサおよびその他のマルチプロセッサアーキテクチャが処理ユニット１００４として使用することもできる。

システムバス１００８は、各種の市販のバスアーキテクチャのうちのいずれかを使用した（メモリコントローラを備えるか、または備えない）メモリバス、周辺バス、およびローカルバスとさらに相互接続することができるいくつかの種類のバス構造のうちのいずれかであってよい。システムメモリ１００６は、読み出し専用メモリ（ＲＯＭ）１０１０およびランダムアクセスメモリ（ＲＡＭ）１０１２を含む。起動時などにコンピュータ１００２内の要素間で情報を転送することに役立つ基礎的なルーチンを含む基本入出力システム（ＢＩＯＳ）は、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭなどの不揮発性メモリ１０１０に格納される。ＲＡＭ１０１２は、キャッシュデータのためのスタティックＲＡＭなどの高速なＲＡＭも含むことができる。

コンピュータ１００２は、好適なシャーシ（図示せず）の拡張した使用のために構成される内蔵ハードディスクドライブ（ＨＤＤ）１０１４（例えば、ＥＩＤＥ、ＳＡＴＡ）と、（例えば、リムーバブルディスケット１０１８から読み出すか、またはリムーバブルディスケット１０１８に書き込むための）磁気フロッピー（登録商標）ディスクドライブ（ＦＤＤ）１０１６と、（例えば、ＣＤ−ＲＯＭディスク１０２２を読み出すか、またはＤＶＤなどのその他の大容量光媒体から読み出すか、またはＤＶＤなどのその他の大容量光媒体に書き込むための）光ディスクドライブ１０２０とをさらに含む。ハードディスクドライブ１０１４、磁気ディスクドライブ１０１６、および光ディスクドライブ１０２０は、それぞれハードディスクドライブインターフェース１０２４、磁気ディスクドライブインターフェース１０２６、および光学ドライブインタ―フェース１０２８によってシステムバス１００８に接続することができる。外付け型のドライブの実装のためのインターフェース１０２４は、ユニバーサルシリアルバス（ＵＳＢ）およびＩＥＥＥ１３９４インターフェース技術のうちの少なくとも１つまたは両方を含む。その他の外付けドライブ接続技術は対象の発明の意図の範囲内である。

これらのドライブおよびこれらのドライブの関連するコンピュータ読取可能媒体は、データ、データ構造、コンピュータが実行可能な命令などの不揮発性の記憶を提供する。コンピュータ１００２に関して、ドライブおよび媒体は、好適なデジタルフォーマットの任意のデータの記憶に順応する。上述のコンピュータ読取可能媒体の説明はＨＤＤ、リムーバブル磁気ディスク、およびＣＤまたはＤＶＤなどのリムーバブル光媒体に言及したが、ＺＩＰドライブ、磁気カセット、フラッシュメモリカード、カートリッジなどのコンピュータによって読み取り可能なその他の種類の媒体も例示的な操作環境において使用することができること、および、さらに任意のそのような媒体が本発明の方法を実行するためのコンピュータが実行可能な命令を含むことができることを当業者は認識すべきである。

オペレーティングシステム１０３０、１または複数のアプリケーションプログラム１０３２、その他のプログラムモジュール１０３４、およびプログラムデータ１０３６を含むいくつかのプログラムモジュールは、ドライブおよびＲＡＭ１０１２に記憶することができる。オペレーティングシステム、アプリケーション、モジュール、および／またはデータのうちのすべてまたは一部はＲＡＭ１０１２にキャッシュすることもできる。本発明は種々の市販のオペレーティングシステムまたはオペレーティングシステムの組合せを用いて実装できることを認識されたい。

ユーザは、１または複数の有線／無線入力デバイス、例えばキーボード１０３８、およびマウス１０４０などのポインティングデバイスを通じてコンピュータ１００２にコマンドおよび情報を入力することができる。その他の入力デバイス（図示せず）は、マイクロホン、ＩＲリモコン、ジョイスティック、ゲームパッド、スタイラスペン、タッチスクリーンなどを含むことができる。これらのおよびその他の入力デバイスは、システムバス１００８に結合される入力デバイスインターフェース１０４２を通じて処理ユニット１００４に接続されることが多いが、パラレルポート、ＩＥＥＥ１３９４シリアルポート、ゲームポート、ＵＳＢポート、ＩＲインターフェースなどのその他のインターフェースによって接続することができる。

モニタ１０４４またはその他の種類のディスプレイデバイスも、ビデオアダプタ１０４６などのインターフェースを介してシステムバス１００８に接続される。モニタ１０４４に加えて、一般にコンピュータは、スピーカ、プリンタなどのその他の周辺出力デバイス（図示せず）を含む。

コンピュータ１００２は、１または複数のリモートコンピュータ１０４８などの１または複数のリモートコンピュータへの有線および／または無線通信を介した論理接続を使用するネットワーク化された環境で操作することができる。１または複数のリモートコンピュータ１０４８は、ワークステーション、サーバコンピュータ、ルータ、パーソナルコンピュータ、ポータブルコンピュータ、マイクロプロセッサベースの娯楽用の家庭用電化製品、ピアデバイス、またはその他の普通のネットワークノードであってよく、一般にコンピュータ１００２に関連して説明した要素の多くまたはすべてを含むが、簡潔にする目的でメモリ／記憶装置１０５０のみを示す。表した論理接続は、ローカルエリアネットワーク（ＬＡＮ）１０５２および／またはより大きなネットワーク、例えばワイドエリアネットワーク（ＷＡＮ）１０５４への有線／無線の接続を含む。そのようなＬＡＮおよびＷＡＮネットワークキング環境はオフィスおよび会社において普通であり、イントラネットなどの企業規模のコンピュータネットワークを容易にし、それらのネットワークのすべてはグローバルな通信ネットワーク、例えばインターネットに接続することができる。

ＬＡＮネットワーキング環境において使用されるとき、コンピュータ１００２は、有線および／または無線通信ネットワークインターフェースまたはアダプタ１０５６を通じてローカルネットワーク１０５２に接続される。アダプタ１０５６はＬＡＮ１０５２への有線または無線通信を容易にすることができ、そのＬＡＮ１０５２は無線アダプタ１０５６と通信するためにそのＬＡＮ１０５２上に配置された無線アクセスポイントも含むことができる。

ＷＡＮネットワーキング環境において使用されるとき、コンピュータ１００２は、モデム１０５８を含むことができるか、またはＷＡＮ１０５４上の通信サーバに接続されるか、またはインターネットを経由するなど、ＷＡＮ１０５４を介して通信を確立するためのその他の手段を有する。内蔵かまたは外付けであることができ、有線または無線デバイスであることができるモデム１０５８は、シリアルポートインターフェース１０４２を介してシステムバス１００８に接続される。ネットワーク化された環境において、コンピュータ１００２に関連して表されたプログラムモジュール、またはそのモジュールの一部は、リモートのメモリ／記憶装置１０５０に記憶することができる。示したネットワーク接続は例示的であり、コンピュータ間で通信リンクを確立するその他の手段を使用することができることが認識されるであろう。

コンピュータ１００２は、無線通信において操作可能に配置された任意の無線デバイスまたはエンティティ、例えば、プリンタ、スキャナ、デスクトップおよび／またはポータブルコンピュータ、携帯情報端末、通信衛星、無線で検出可能なタグに関連する任意の設備または場所（例えば、キオスク、新聞雑誌の売店、休憩室）、および電話と通信するように操作可能である。これは、少なくともＷｉ−ＦｉおよびＢｌｕｅｔｏｏｔｈ（商標）無線技術を含む。したがって、通信は、標準的なネットワークと同様に既定の構造であるか、または単純に少なくとも２つのデバイスの間の臨時の通信であることができる。

Ｗｉ−Ｆｉ、すなわちワイヤレスフィデリティは、家のカウチ、ホテルの部屋のベッド、または仕事中に会議室から配線なしにインターネットに接続できるようにする。Ｗｉ−Ｆｉは、そのようなデバイス、例えばコンピュータが屋内でも屋外でも、すなわち基地局の範囲内のどこででもデータを送受信できるようにする、携帯電話に使用される無線技術と同様の無線技術である。Ｗｉ−Ｆｉネットワークは、ＩＥＥＥ８０２．１１（ａ、ｂ、ｇなど）と呼ばれる無線技術を使用して、安全で、信頼でき、高速な無線接続性を提供する。Ｗｉ−Ｆｉネットワークは、コンピュータを互いに、インターネットに、および（ＩＥＥＥ８０２．３またはイーサネット（登録商標）を使用する）有線ネットワークに接続するために使用することができる。Ｗｉ−Ｆｉネットワークは、例えば、未認可の２．４および５ＧＨｚ無線帯域において１１Ｍｂｐｓ（８０２．１１ａ）または５４Ｍｂｐｓ（８０２．１１ｂ）のデータ転送速度で、または両方の帯域（デュアルバンド）を含む製品を用いて操作し、したがってネットワークは多くのオフィスで使用される１０ＢａｓｅＴ有線イーサネット（登録商標）と同様の実効性能を提供することができる。

ここで図１１を参照すると、対象のＡＰＩの態様による例示的なコンピューティング環境１１００の概略ブロック図が示されている。システム１１００は、１または複数のクライアント１１０２を含む。１または複数のクライアント１１０２は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）であってよい。１または複数のクライアント１１０２は、例えば、本発明を使用することによって、１または複数のクッキーおよび／または関連するコンテキスト情報を蓄えることができる。

システム１１００は、１または複数のサーバ１１０４も含む。１または複数のサーバ１１０４もまた、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）であってよい。サーバ１１０４は、例えば、本発明を使用することによって変換を実行するためのスレッドを蓄えることができる。クライアント１１０２とサーバ１１０４の間の１つの可能な通信は、２つ以上のコンピュータプロセス間で送信されるように適合されたデータパケットの形態であることができる。データパケットは、例えば、クッキーおよび／または関連するコンテキスト情報を含むことができる。システム１１００は、１または複数のクライアント１１０２と１または複数のサーバ１１０４の間の通信を容易にするために使用することができる通信フレームワーク１１０６（例えば、インターネットなどのグローバルな通信ネットワーク）を含む。

通信は、（光ファイバを含む）有線および／または無線技術を介して容易にすることができる。１または複数のクライアント１１０２は、１または複数のクライアント１１０２に対してローカルの情報（例えば、１または複数のクッキーおよび／または関連するコンテキスト情報）を記憶するために使用することができる１または複数のクライアントデータストア１１０８に操作可能に接続される。同様に、１または複数のサーバ１１０４は、サーバ１１０４に対してローカルの情報を記憶するために使用することができる１または複数のサーバデータストア１１１０に操作可能に接続される。

上述された内容は本発明の例を含む。言うまでもなく、対象の発明を説明する目的でコンポーネントまたは方法の考えられるあらゆる組合せを説明することは不可能であるが、当業者は本発明の多くのさらなる組合せおよび変更が可能であることを認識するであろう。したがって、本発明は、添付の特許請求の範囲の概念および範囲内にあるすべてのそのような改変形態、修正形態、および変形形態を包含するように意図される。さらに、用語「含む（includes）」が発明を実施するための最良の形態、または特許請求の範囲のいずれかで使用される限りにおいて、かかる用語は、請求項で移行語として使用される場合に「備える（comprising）」が解釈されるように、用語「備える（comprising）」と同様にして包括的であるように意図される。

本発明の一態様による、アプリケーションとマークアップ言語コンポーネントの間のインターフェースを取るオブジェクトモデルを容易にするシステムを示す図である。 ＡＰＩ（Application Program Interface）の一態様による、ナビゲーションコンポーネント、構築コンポーネント、および修正コンポーネントを有するＡＰＩのブロック図である。 本発明の一態様による、ナビゲーションコンポーネントおよび受け取りコンポーネントを有するＡＰＩシステムのブロック図である。 本発明の一態様による、軸コンポーネント、ソートコンポーネント、および名前空間コンポーネントを有するナビゲーションコンポーネントを示す図である。 本発明の一態様による、マークアップ言語コンポーネント内をナビゲートすることを容易にする手順の例示的なフローチャートである。 本発明の一態様による、構築コンポーネントおよび受け取りコンポーネントを有するＡＰＩシステムのブロック図である。 本発明の一態様による、表現式指向のステートメントを使用し、文脈自由なノードを構築するシステムを示す図である。 一態様による、文脈自由な（例えば、ノード中心の）ノードを構築することを容易にする手順の例示的なフローチャートである。 本発明の一態様による、修正コンポーネントおよびオペレータコンポーネントを有するＡＰＩシステムのブロック図である。 開示されたアーキテクチャを実行するように操作可能なコンピュータのブロック図である。 対象の発明による例示的なコンピューティング環境の概略ブロック図である。

Claims (14)

1. アプリケーションと拡張可能マークアップ言語（ＸＭＬ）データとのインタラクションを促進するためのシステムであって、
   構築されるＸＭＬデータを格納するためのメモリと、
   複数のＸＭＬノードの型を定義するオブジェクトモデルを識別するための手段と、
   前記アプリケーションとインターフェースし、前記アプリケーションから、前記オブジェクトモデルのフォーマットと整合性のある単一のネストされた式で記述されている表現式フォーマットのＸＭＬ文書を受け取るための手段と、
   前記オブジェクトモデルにしたがって、前記受け取ったＸＭＬ文書から、文脈自由な要素ノードで構成される少なくとも１つのＸＭＬフラグメントを含むＸＭＬデータを、当該システムの前記メモリ上に構築するための手段と、
   ノード間の関係を表す軸を使用して、前記ＸＭＬデータ内の複数の要素ノードの間をナビゲートするための手段と
   を備え、
   前記構築するための手段が、
   前記受け取ったＸＭＬ文書に記述されている単一のネストされた式を、前記オブジェクトモデルにしたがって変換することによって、前記ＸＭＬ文書とは独立の文脈自由な要素ノードで構成される少なくとも１つのＸＭＬフラグメントを生成して、当該少なくとも１つのＸＭＬフラグメントを含むＸＭＬデータを構築することと、
   前記ナビゲートするための手段が、前記アプリケーションから受け取った前記ＸＭＬ文書において、特定の要素ノードに関する照会または修正が記述されている場合に、
   前記ＸＭＬデータ内の前記複数の要素ノードの間をナビゲートして、当該複数の要素ノードから、照会または修正の基準とするコンテキストノードとなる前記特定の要素ノードを識別することと、
   前記ＸＭＬ文書において前記特定の要素ノードとの関係を表す軸によって示され、かつ前記特定の要素ノードに関連する要素ノードまたは前記特定の要素ノードの属性のいずれかである、照会または修正を行なうべき前記ＸＭＬデータ内の要素ノードまたは属性を識別することと
   により、アプリケーションとＸＭＬデータとのインタラクションを促進することを特徴とするシステム。
2. 前記オブジェクトモデルで定義された前記複数のＸＭＬのノードの型は、
   名前空間統一資源識別子（ＵＲＩ）およびローカル名から成る１または複数の汎用的な名前を表す型、XNameと、
   １または複数の属性を表す型、XAttributeと、
   １または複数のＸＭＬの子ノード型のための抽象ベースクラスを表す型、XNodeと、
   １または複数のＸＭＬのコメントを表す型、XCommentと、
   １または複数のＸＭＬの処理命令を表す型、XProcessingInstructionと、
   １または複数のＸＭＬ宣言を表す型、XDeclarationと、
   ＸＭＬのドキュメント型の宣言を表す型、XDocumentTypeと、
   文字データのためのベースクラスを表す抽象型、XCharacterNodeと、
   １または複数のＸＭＬのCDataセクションを表す抽象型、XCDataと、
   子を有する１または複数のノードを表す抽象型、XContainerと、
   前記XContainerが１または複数のＸＭＬの要素を表す型、XElementと、
   完全なＸＭＬドキュメントを表す型、XDocumentと
   のうちの少なくとも１つを含むことを特徴とする請求項１に記載のシステム。
3. 前記軸は、前記特定の要素ノードの子、子孫、親、祖先、兄弟、自身、自身と子孫、自身と祖先、または前記特定の要素ノードの属性、のうちの少なくとも１つを表すことを特徴とする請求項１に記載のシステム。
4. ドキュメントの順序によって照会結果のデータセットを明示的にソートするための手段をさらに備えることを特徴とする請求項１に記載のシステム。
5. 前記ナビゲートするための手段は、前記軸を使用することによって、照会または修正の戻り値を、特定の名前および特定の型のうちの少なくとも１つを有する要素ノードに制限することを特徴とする請求項３に記載のシステム。
6. 前記受け取ったＸＭＬ文書に基づいて前記ＸＭＬデータを変更するための手段をさらに含むことを特徴とする請求項１に記載のシステム。
7. 前記変更するための手段は、前記受け取ったＸＭＬ文書に基づいて、前記ＸＭＬデータ内の特定の要素ノードに対するアクションを識別するための手段をさらに含み、
   前記変更するための手段は、前記識別されたアクションを前記ＸＭＬデータ内の特定の要素ノードに行なうことによって、前記ＸＭＬデータを変更することを特徴とする請求項６に記載のシステム。
8. 前記アクションは、
   特定の要素ノードの親に対する更新であって、前記親にアイテムを追加することと、前記親にアイテムのコレクションを追加することと、前記親から当該受け取りノードを削除することとのうちの少なくとも１つを含む更新と、
   前記特定の要素ノードおよび特定の要素ノードのコレクションのうちの少なくとも一方に対する更新であって、前記特定の要素ノードにアイテムを追加することと、前記特定の要素ノードに子のコレクションを追加することと、前記特定の要素ノードの子を削除することと、前記特定の要素ノードの前記子を単一のアイテムで置き換えることと、前記特定の要素ノードの前記子をアイテムのコレクションで置き換えることと、属性を追加することと、属性を削除することと、指定された子ノードのコンテンツを置き換えることと、前記特定の要素ノードの属性を置き換えることとのうちの少なくとも１つを含む更新と
   のうちの少なくとも１つであることを特徴とする請求項７に記載のシステム。
9. プロセッサ、メモリ、およびディスプレイを含むコンピュータによって実施される、アプリケーションとＸＭＬデータとのインターフェースを取る方法であって、前記コンピュータが、
   ＤＯＭを使用し、複数のＸＭＬノードの型を定義するオブジェクトモデルを確立するステップと、
   前記アプリケーションとインターフェースして、前記オブジェクトモデルのフォーマットと整合性のある単一のネストされた式で記述されている表現式フォーマットのＸＭＬ文書を前記アプリケーションから受け取るステップと、
   前記受け取ったＸＭＬ文書に記述されている単一のネストされた式を、前記オブジェクトモデルにしたがって変換することによって、前記ＸＭＬ文書とは独立の文脈自由な要素ノードで構成される少なくとも１つのＸＭＬフラグメントを生成して、当該少なくとも１つのＸＭＬフラグメントを含むＸＭＬデータを、当該コンピュータの前記メモリ上に構築するステップと、
   前記受け取ったＸＭＬ文書において、特定の要素ノードに関する照会または修正が記述されている場合、
   前記ＸＭＬデータ内の前記複数の要素ノードをナビゲートして、当該複数の要素ノードから、照会または修正の基準とするコンテキストノードとなる前記特定の要素ノードを識別するステップと、
   前記特定の要素ノードに関連するノード、または前記特定の要素ノードの属性のうちの少なくとも１つであり、前記ＸＭＬ文書において前記特定の要素ノードとの関係を表す軸によって示されている、照会または修正を行なうべき前記ＸＭＬデータ内の要素ノードまたは属性を、同じ手法で識別するステップと、
   前記メモリ上に構築されている前記ＸＭＬデータ内の前記識別された要素ノードまたは属性に対して、照会または修正を行うステップと
   を含む各ステップを実行することを特徴とする方法。
10. 前記オブジェクトモデルで定義された前記複数のＸＭＬのノードの型は、
    名前空間統一資源識別子（ＵＲＩ）およびローカル名から成る１または複数の汎用的な名前を表す型、XNameと、
    １または複数の属性を表す型、XAttributeと、
    １または複数のＸＭＬの子ノード型のための抽象ベースクラスを表す型、XNodeと、
    １または複数のＸＭＬのコメントを表す型、XCommentと、
    １または複数のＸＭＬの処理命令を表す型、XProcessingInstructionと、
    １または複数のＸＭＬ宣言を表す型、XDeclarationと、
    ＸＭＬのドキュメント型宣言を表す型、XDocumentTypeと、
    文字データのためのベースクラスを表す抽象型、XCharacterNodeと、
    １または複数のＸＭＬのCDataセクションを表す抽象型、XCDataと、
    子を有する１または複数のノードを表す抽象型、XContainerと、
    前記XContainerが１または複数のＸＭＬの要素を表す型、XElementと、
    完全なＸＭＬドキュメントを表す型、XDocumentと
    のうちの少なくとも１つを含むことを特徴とする請求項９に記載の方法。
11. 前記軸は、前記特定の要素ノードの子、子孫、親、祖先、兄弟、自身、自身と子孫、自身と祖先、または前記特定の要素ノードの属性、のうちの少なくとも１つを表すことを特徴とする請求項９に記載の方法。
12. 前記コンピュータが、ドキュメントの順序によって照会結果のデータセットを明示的にソートするステップをさらに備えることを特徴とする請求項９に記載の方法。
13. アプリケーションと拡張可能マークアップ言語（ＸＭＬ）データとのインタラクションを促進するためのシステムであって、
    構築されるＸＭＬデータを格納するためのメモリと、
    複数のＸＭＬノードの型を定義するオブジェクトモデルを識別するための手段と、
    前記アプリケーションとインターフェースし、前記アプリケーションから、前記オブジェクトモデルのフォーマットと整合性のある単一のネストされた式で記述されている表現式フォーマットのＸＭＬ文書を受け取るための手段と、
    前記受け取ったＸＭＬ文書を前記オブジェクトモデルにしたがって変換することによって、当該システムの前記メモリ上に、少なくとも１つのＸＭＬフラグメントを含むＸＭＬデータを構築するための手段と、
    ノード間の関係を表す軸を使用して、前記ＸＭＬデータ内の複数のノード間をナビゲートするための手段と
    を備え、
    前記構築するための手段は、
    前記受け取ったＸＭＬ文書に記述されている単一のネストされた式を、前記オブジェクトモデルにしたがって変換することによって、前記ＸＭＬ文書と独立の文脈自由なノードで構成される少なくとも１つのＸＭＬフラグメントを生成して、当該少なくとも１つのＸＭＬフラグメントを含むＸＭＬデータを構築し、
    前記少なくとも１つのフラグメントは、
    前記ＸＭＬ文書に記述されている前記単一のネストされた式に含まれる複数のノードのそれぞれが、親ノードを有するか否かを判定し、
    前記ノードが、親ノードを有する場合には、当該ノードを複製し、当該複製されたノードに対して新たな親ノードを指定して、文脈自由なノードを作成する
    ことによって生成され、
    前記ナビゲートするための手段は、前記アプリケーションから受け取った前記ＸＭＬ文書において、特定の要素ノードに関する照会または修正が記述されている場合、
    前記ＸＭＬデータ内の前記複数の要素ノードをナビゲートして、当該複数の要素ノードから、照会または修正の基準とするコンテキストノードとなる前記特定の要素ノードを識別し、
    前記特定の要素ノードに関連する要素ノード、または前記特定の要素ノードの属性のうちの少なくとも１つであり、前記ＸＭＬ文書において前記特定の要素ノードとの関係を表す軸によって示されている、照会または修正を行なうべき前記ＸＭＬデータ内の要素ノードまたは属性を識別する
    ことにより、アプリケーションとＸＭＬデータとのインタラクションを促進することを特徴とするシステム。
14. 前記オブジェクトモデルで定義された前記複数のＸＭＬのノードの型は、
    名前空間統一資源識別子（ＵＲＩ）およびローカル名から成る１または複数の汎用的な名前を表す型、XNameと、
    １または複数の属性を表す型、XAttributeと、
    １または複数のＸＭＬの子ノード型のための抽象ベースクラスを表す型、XNodeと、
    １または複数のＸＭＬのコメントを表す型、XCommentと、
    １または複数のＸＭＬの処理命令を表す型、XProcessingInstructionと、
    １または複数のＸＭＬ宣言を表す型、XDeclarationと、
    ＸＭＬのドキュメント型宣言を表す型、XDocumentTypeと、
    文字データのためのベースクラスを表す抽象型、XCharacterNodeと、
    １または複数のＸＭＬのCDataセクションを表す抽象型、XCDataと、
    子を有する１または複数のノードを表す抽象型、XContainerと、
    前記XContainerが１または複数のＸＭＬの要素を表す型、XElementと、
    完全なＸＭＬドキュメントを表す型、XDocumentと
    のうちの少なくとも１つを含むことを特徴とする請求項１３に記載のシステム。

Images