JP2006510955A - Ｘｍｌ処理タスクの管理および実行のためのコンテキスト独立フレームワークのシステムおよび方法 - Google Patents

Abstract

ＸＭＬ処理タスクの管理および事項のためのコンテキスト独立フレームワーク・システムを提供する。ＸＭＬ処理タスクを、ここではＸＳＡエンジンと呼ぶモジュールによって、特殊目的ＸＭＬ系プログラミング言語で書かれた電子文書として用意された既定の１組の命令にしたがって実行する。命令集合は、３つのクラスの処理モジュールへの参照を収容し、その実行を制御する。３つのクラスの処理モジュールは、独立してＸＭＬ処理サブタスクを遂行し、合同して１つのＸＭＬ処理タスクを達成する。フレームワークは、いずれの特定の実行コンテキストからも切断されており、殆どあらゆる所望の用途において、標準化ＸＭＬ処理を適用できることを意味する。特殊目的プログラミング言語は、汎用プログラミング言語を用いた場合と比較して、ＸＭＬ処理タスクの開発の生産性を高め、カスタム・コードを書いて異なる形式のＸＭＬ処理サブタスクにリンクしてＸＭＬ処理タスクを遂行する必要性を低下させている。

Description

特殊目的プログラミング言語を用いた構造型データのコンテキスト独立処理を含むタスクの実行管理システム。

殆どのコンピュータ・アプリケーションは、あるタスク（複数のタスク）を遂行し、プロセスにおいてその人間のユーザのために楽な生活をもたらすように設計されている。コンピュータ・ネットワークおよびインターネットは、コンピュータ・アプリケーションによって生活を楽にする新しい機会を導入した。今日、会社または組織内におけるコンピュータは殆ど全て何らかのコンピュータ・ネットワークに接続されており、更にインターネットにも接続されているのが一般的である。

近年、拡張可能マークアップ言語（ＸＭＬ：Extensible mark-up language）が、あらゆる形式の構造化データを記述する共通の方法として出現した。ＸＭＬに対する広範な業界支援およびＸＭＬ開発の遍在により、何らかの形式のＸＭＬ対応をアプリケーションに設けるコンピュータ・アプリケーションの供給業者数が増加しつつある。ある新しいアプリケーションが提供するＸＭＬ対応の一種に、ウェブ・サービスと呼ばれるものがある。ウェブ・サービスは、ソフトウェア・コンポーネントであり、予め規定したＸＭＬインターフェースを、一般にインターネットを通じてアクセス可能な、そのデータおよびサービスに公開する(expose)。

ＸＭＬは、電子出版の分野、特に出版が依頼に応じて行われ、コンピュータ・ネットワークを通じたデータの移動を伴う場合に、頻繁に用いられている。例えば、全てのブラウザ・アプリケーションは、ある形式のＸＭＬまたはＸＭＬ関連データ・フォーマット（例えば、ＨＴＭＬ、ＸＨＴＭＬ、ＷＭＬ）を理解し、これらをその人間のユーザに提供する。他の種類の電子的表現に対する他の表現フォーマットは、ＸＭＬまたはＸＭＬ系であっても、なくてもよいが、一般にＸＭＬは出版アプリケーションには非常に適している。

電子業務は、ＸＭＬおよびインターネットが主要な役割を果たす別の分野である。電子業務は、多くの場合自動的な、電子業務トランザクションを既定の規則に応じた組織と呼び出し基準(invocation criteria)との間で行うことを伴う。ＥＤＩは、共通の非ＸＭＬ系電子業務フレームワークであるが、現在出現しつつある連続フレームワーク（例えば、ＢｉｚＴａｌｋ、ｅｂＸＭＬなど）は全て、ＸＭＬおよびインターネットに大きく頼っている。

コンピュータ・ネットワーキングの全体的な採用にも拘わらず、多くのアプリケーションは、たとえネットワーク上で他のアプリケーションと自由に通信することが効果的であっても、これを行うことができない。殆どのアプリケーションは、ネットワーク上で外部アプリケーションからデータをインポートし、外部アプリケーションにデータをエクスポートする何らかの機能を有している。しかしながら、生憎、現行のアプリケーションの殆どは、一般に、企業固有のデータ・フォーマットおよびプロトコルを必要とし、アプリケーション間の、恐らくは有益な、通信を難しくしている。これが意味するのは、アプリケーション間の自動情報交換（統合）は多くの場合非常に望ましいが、特注であることが多いミドルウェア（またはインタープリタ・ソフトウェア）によってデータを導出しプロトコル間で変換することが必要であり、そうして初めてアプリケーションが自由に通信しデータ／情報を交換できるようになるということである。

これに関連して、組織が統合統一インターフェースを１つよりも多いバック・エンド・アプリケーション(back-end application)にアクセスさせたいときに、統合化の問題が起こることが多い。このようなアプリケーションは自由に通信しない場合が多いので、単一のアプリケーションが、多くのシステムからのデータに対するビュー(view)を備えたインターフェースを提供することができない。この問題に対する唯一の解法は、ポータル・ソフトウェア・ミドルウェアを導入することであるが、このためには、必要とされるシステム全てに通信することができ、全てのデータを適宜融合かつ統一し、次いで全てのアプリケーションからのデータ／サービスに対して統合化したビューを備えた、一貫性のあるインターフェースを設ける必要がある。しかしながら、ポータル・ソフトウェアは、多くのシステムからのデータ複製に頼るという欠点を有することがときどきある。

電子出版においては、別の統合化問題も発生する。多くのアプリケーションの表現能力には限界があるので、そのインターフェースに対する人間の双方向処理を１種類のメディアのみでしか提供できない場合が多い。これが意味するのは、新たな表現の必要性が生じた場合、アプリケーションのインターフェースを拡張するためには、特注であることが多いミドルウェア・ソフトウェアの導入が必要となるということである。

また、これに関連して、多くの電子表現フォーマット（例えば、AdobeのＰＤＦ文書、ＭＳWordの文書）には、コンテンツ・データと表現データとの間に殆どまたは全く分離がないという事実の中に、別の表現の問題がある。これが意味するのは、新たな表現の必要性が生じた場合、既存の文書を新たなフォーマットに適合化することが困難または不可能であるということである。

以上の問題の一部は、組織が彼らの古いアプリケーションを新しいものと交換すれば、救済することができ、あるいは解消できることさえある。しかしながら、多くの組織は、企業アプリケーション統合(Enterprise Application Integration)を導入することによって問題を軽減しようとしてきた。これは、大抵の場合、ミドルウェアをインストールして、アプリケーションの既存のインターフェースを改良または拡張するか、あるいはアプリケーションが他のアプリケーションと通信できるようにすることによって、既存のアプリケーションの有効範囲をいくらか拡張できるようにすることを伴う。

ＸＭＬは、構造化データに頼るあらゆるアプリケーションに非常に適している。ＸＭＬの独特な特性および例外的に広い業界の対応によって、これは統合化、電子業務および出版の用途に非常に有用であることがわかっている。多くの分析者は、ＸＭＬには、アプリケーションが実際に互いに通信しあうことを可能にし、したがってそのユーザの生活を一層楽にする見込みがあることを確信している。実際には、これは、ＸＭＬが解決策に関与する場合の統合化コストの低下を意味する。少なくともＸＭＬおよびＸＭＬ関連技術が統合化、電子業務および出版ソフトウェアに今日広くそしてしかるべく理由で用いられていることは、明白である。

この分野の専門家の殆どは、ＸＬＭおよびＸＭＬ関連技術を利用することは、異種システムの統合化、電子業務および出版に用いる必要があるアプリケーションのような、ある種のアプリケーションを開発するときに意味があると確信している。しかしながら、これらのアプリケーションにおけるその使用は、殆ど標準化されていないか、またはその場限りであることが多い。現状については、ある組織は情報処理能力があってＸＭＬを利用しより良いアプリケーションを構築しているが、ある組織はそうしていないと言うことによって、記述することができると思われる。これらの殆どは、既存のＸＭＬ関連の仕様書が何をするのか彼らに指示しないと、その場限りでそれを用いるに過ぎない。ＸＭＬ処理の世界は、狭く定義されたタスクのための小さなモジュールで満たされているが、これらを一緒に統一して管理する、明確なフレームワークが欠けている。これが意味するのは、現行のＸＭＬに基づく解決策の殆どは、ある程度、その場限りのプログラミングの「切り貼り」(glue)に頼って、異なるＸＭＬ系モジュールを共にリンクしているということである。

このため、ＸＭＬ処理タスクの管理および実行のためのフレームワークの方法およびシステムを影響することが望ましい。更に、このようなフレームワークは、あらゆる特定的な実行コンテキストからも切断されており、ＸＭＬ処理の管理フレームワークに価値があると思われる全ての場合を扱うことができるように十分な柔軟性があることは重要である。

更に、このような管理フレームワークは、各々が既存のＸＭＬ処理規格または仕様によって支配されている多くの異なる形式のＸＭＬ処理タスクを共に継ぎ合わせるために汎用プログラム言語を用いる必要性を減少または解消するために、ＸＭＬ処理タスクを定義する特殊目的プログラミング言語に頼ることが好ましい。このようなＸＭＬ処理タスク用特殊目的プログラム言語によって、開発者はＸＭＬ処理タスクを定義しつつ、汎用プログラミング言語で可能なよりも遥かに生産性を向上することができる。

統合、出版、電子業務、または他の分野においてＸＭＬ処理が有効な場合に伴う問題の一部は、本発明の好適な実施形態が克服または軽減する。ＸＭＬ処理タスクの管理および実行のためのフレームワークの方法およびシステムを提供する。このフレームワークは、いずれの特定の実行コンテキストからも切断することができ、管理フレームワークを、ＸＭＬ処理を必要とするアプリケーション内であればどこにでも適用できることを意味する。

本発明は、サーバ側ＸＭＬアプリケーション、即ち、ＸＭＬ処理が重要な役割を担う、または重要な役割を担い得るあらゆるサーバ側コンピュータ・アプリケーションに関する。ＸＭＬアプリケーションは、企業アプリケーション統合、電子出版、電子業務処理のような分野においては一般的である。更に特定すれば、本発明は、処理タスクを定義する特殊目的プログラミング言語を基にしたＸＭＬ処理タスクの管理、定義、および実行のための、標準化し構造化したフレームワークのための方法およびシステムに関する。

更に、本発明の好適な一実施形態によれば、ＸＭＬ管理フレームワークは、異なるＸＭＬ処理サブタスクを互いにリンクする目的のために設計された特殊目的プログラミング言語を拠り所とし、ＸＭＬ処理の技術分野では周知の規格、方法または使用によって各サブタスクを統括する。特殊目的プログラミング言語は、ＸＭＬ処理タスクの管理のために特定的に設計されており、ＸＭＬ処理タスクの開発者が、汎用プログラミング言語で可能なよりも、生産性を高めることを可能とし、ＸＭＬ処理タスクを遂行するために異なるタイプのＸＭＬ処理サブタスクをリンクするカスタム・コードを書く必要性を軽減する。有用なアプリケーションの例は、業務メッセージの変換および配信、異種システムの統合、およびウェブ出版である。

本発明の一態様は、ＸＭＬ処理サブタスクの管理および連結のために特定して設計した特殊目的プログラミング言語で書かれた電子文書として用意された既定の１組の命令にしたがって、ＸＭＬ処理タスクを定義し実行する方法およびシステムを含む。ここで、各サブタスクは、周知のＸＭＬ関連規格、仕様または方法によって調整する。特殊目的プログラミング言語で書かれた電子文書における特定の命令集合によって定義された各ＸＭＬ処理タスクは、ここでは、ＸＭＬサービス・アクションまたは単にＸＳＡと呼ばれることが多い。ＸＳＡ−ｓを実行可能なソフトウェア・モジュールを、ＸＳＡエンジンと呼ぶ。ＸＭＬサービス・アクション電子文書をどのように作成するかを定義し、ＸＭＬ処理タスクを管理するように設計されている特殊目的プログラミング言語のフォーマットおよびシンタックスは、高精度に定義することができ、特殊目的プログラミング言語のシンタックスを、ＸＭＬに基づくマークアップに指定することが好ましい。

この方法は、外部要求によってシステムを呼び出し、特定の１組の処理命令、即ち、特殊目的プログラミング言語で書かれた特定のＸＳＡ電子文書を実行することを含む。呼び出しは、実行するＸＳＡがどれかという指示を含み、更に呼び出しの発信元および目的に関するその他の情報も含むことができる。呼び出しを受けると、ＸＳＡエンジンは、該当するＸＳＡ電子文書を突き止め、その中に定義されている命令を実行しようとし、適宜、実行した特定のＸＳＡ内にある命令に従って応答を返す。

本発明の好適な実施形態によれば、ＸＭＬ管理フレームワークおよび特殊目的プログラミング言語は、３つの異なるクラスのＸＭＬ処理モジュールを基本とし、これらが合同して、更に本発明の別の部分と共に、特定のＸＳＡで定義したＸＭＬ処理タスクを遂行する。特殊目的プログラミング言語にしたがって書かれた各ＸＳＡは、一般に、これら３つのクラスのＸＭＬ処理モジュールの各々の少なくとも１つを参照し、その機能を制御する。ＸＭＬサービス・アクションは、これら３タイプのモジュールがどのように相互作用し、一体となってＸＭＬ処理タスクを遂行するかを定義し、修正し、制御する。３タイプのモジュールを、ここでは、生成器、変換器、およびシンクと呼ぶ。殆どのＸＭＬ処理サブタスクは、正しく定義されているか、またはＸＭＬ処理の技術分野では周知であり、サブタスクの生成、サブタスクの変換／操作、またはサブタスクの配出(sink)に分類することができる。

いずれの所与のＸＭＬ処理タスクにおいても、いずれのＸＳＡによって定義されても、生成器モジュールは、ＸＭＬソース・データを生成することを担当し、変換器モジュールは、ＸＭＬソース・コンテンツを変換または操作して異なるのＸＭＬデータを形成する（処理したＸＭＬデータ）ことを担当し、最後にシンク・モジュールは処理したＸＭＬデータを解釈し、これに反応し、またはこれを配信することを担当する。生成器は、ＸＭＬソース・コンテンツを生成し、一般に、外部システムにおいて発生したデータを公開する。生成器の一例は、外部システム、例えば、ＪＤＢＣ準拠のデータベースと通信を行い、更なるＸＭＬ処理のために用意されている、ＸＭＬフォーマットで外部システムによって提供されるコンテンツまたはサービスに公開する。各生成器は、それ自体のＸＭＬシンタックスを定義し、それが通信するバック・エンド・システム（複数のバック・エンド・システム）が提供するコンテンツまたはサービスに、固有の様式で(natural way)公開する。

ＸＭＬソース・データを更に処理、解釈、または操作して、特定のＸＳＡに定義されている、要求を受けたＸＭＬ処理タスクを実行するために、１つ以上の変換器がＸＭＬコンテンツを総合的に変換、解釈、有効性判断、反応、または何らかの方法で操作して、一般に異なるの（または少なくとも検査し有効性が認められた）ＸＭＬデータが得られる。これを、ここでは、処理済ＸＭＬデータと呼ぶ。変換器は、ＸＭＬデータを入力および出力双方として有するモジュールであり、多くの変換器を直列に用いることができる。変換器の一例は、拡張可能スタイルシート言語変換（ＸＳＬＴ）で書かれた所与のスタイルシートにしたがってＸＭＬを変換する、ソフトウェア・モジュールである。その目的に応じて、各タイプの変換器が、生成器または別の変換器から受け取ったそのＸＭＬ入力データに制約を課することも、課さないこともある。また、各変換器は、処理済ＸＭＬ出力データの形式を定義する。

いずれの所与のＸＳＡで定義したＸＭＬ処理タスクの実行でも、最終部分は、シンク・モジュールを用いて行われる。シンク・モジュールは、変換器から受け取った、処理済ＸＭＬデータで何を行うかを定義する。異なるタイプのシンクが、ＸＳＡの目的に応じて、異なるタスクを実行する。共通のタスクの１つは、ＸＭＬフォーマットでないことが多い、処理済ＸＭＬデータを何らかの方法で公表(publish)し、ＸＳＡの実行を要求したクライアントに返送することである。シンクの中には、受け取ったＸＭＬデータを解釈し、例えば、何らかのアクションを実行することによって、これに反応するか否か、そしてどのように反応するか判断するものもある。シンク出力の一例は、ＨＴＭＬまたはＷＭＬのようなそのＸＭＬ入力データを出力し、別の例は、それをＰＤＦ電子文書として公表する。他のタイプのシンクには、得られたＸＭＬをインターネットを通じてＸＭＬ業務文書として配信するものもあり、更に別のシンクには、受け取ったＸＭＬ内の情報を用いて、タスクを実行するか否か判断するものもある。タスクとは、通知の目的のための電子メール送信、データベースへのデータ書き込み、または統合化の目的のための別のシステムへのＸＭＬの送信等である。

前述のように、本発明は、好ましくはＸＭＬサービス・アクション仕様にしたがって特殊目的プログラミング言語で書かれた、ＸＭＬサービス・アクション電子文書の実行システムを含む。ＸＭＬサービス・アクション仕様は、本発明の主旨におけるＸＳＡの有効なシンタックスを正確に定義する。本システムは、いずれのアプリケーション特定コンテキストからも切断され、汎用インターフェースのみを設けた、ＸＳＡエンジンを含む。本発明の好適な実施形態によれば、本システムは、ここではアダプタと呼ぶ、ソフトウェア・モジュールを拠り所として、特定のアプリケーション・コンテキストに適応する。アダプタは、ネットワーク・デバイス、ワイヤレス・デバイス、またはその他のコンピュータ・システムというような、種々のタイプの外部クライアントからの、特定のＸＳＡ−ｓの実行要求または呼び出しを受け付けることを担当する。アダプタは、外部クライアントとの通信全てを扱うことによって全てのアプリケーションまたはコンテキスト特定の通信をカプセル化し、全体的に特定のタイプの通信プロトコルに適応し、特定のＸＳＡの実行を要求することによって、その汎用インターフェースを通じてＸＳＡエンジンと双方向処理を行うソフトウェア・モジュールである。したがって、アダプタ・コンポーネントは、汎用ＸＳＡエンジンを、特定のアプリケーション・コンテキストに適応させる。ＸＳＡ実行要求毎にアダプタ・コンポーネントを通じて要求が到達すると、アダプタ・コンポーネントは、ＸＳＡが実行するコンテキストを定義する。これは、特定のＸＭＬ処理タスクに相応しいと思われる、計算アプリケーションの実世界から、ＸＳＡエンジンへのリンクを設ける。ＸＳＡエンジンが提供する汎用インターフェースを通じて、アダプタはＸＳＡエンジンに、着信した要求に関する情報を提供することができる。この着信要求は、恐らくは、ＸＭＬ系フォーマットまたはパラメータ名称−値対の形式となっている。ＸＳＡの実行が終了すると、当該特定のＸＳＡに定義されている処理の結果に基づいて、ＸＳＡエンジンを呼び出したアダプタ・コンポーネントを通じて、しかるべき応答を要求基外部クライアントに返送するのが一般的である。特定の生成器、変換器、またはシンクは、どの特定のタイプのアダプタがこれらと適合性があるかについて、制約を課する場合もある。

いずれのＸＳＡも、種々の方法で特定のタイプの生成器、変換器およびシンクを用いて、所望のＸＭＬ処理タスクを遂行することができる。ＸＳＡにおいて定義されているＸＭＬ処理は、例えば、ＸＭＬ電子文書の合併または分割によって、１つよりも多い実行のスレッドにおいて行われる場合がある。ＸＳＡエンジンは、多くの異なるタイプのソフトウェア・モジュールを拠り所として、前述の３つのクラスのＸＭＬ処理モジュールを用いて、ＸＭＬデータの柔軟で精巧な処理および流れの可能性を実現する。これらのソフトウェア・モジュールは、エラーの扱い、有効性判断、特定のＸＳＡ実行に関連するメタ・データへのアクセス、セッション制御、ユーザ管理、認証、許可、およびその他の同様の補助機能というような、補助または支援機能を設けることができる。

ＸＭＬソフトウェア・アクションは、大きく異なるアプリケーションにおいて大きく異なる計算タスクを遂行する際に用いることができる。用いるシステム・コンポーネントは、更に多くてもまたは少なくても可能であり、本発明は、前述のシステム・コンポーネントには限定されない。本発明は、必ずしも、いずれのソフトウェア・コンポーネントの存在も必要としない。これは、明確なＸＭＬ処理サブタスクの管理またはリンクのためのみに定義され、特殊目的プログラミング言語で書かれたＸＭＬサービス・アクション電子文書によって定義された、ＸＭＬ処理タスクの実行方法およびシステムについて記載する。これは、ここに記載される抽象的処理モジュールの具体的な実現例を用いて、その所望の機能を遂行する。本発明はここでは常にＸＭＬ処理タスクに関して記載されているが、本方法およびシステムは、必ずしもＸＭＬフォーマットではない、構造化データのあらゆる処理にも等しく適用することができる。実世界において有用であるために、制御するＸＭＬサービス・アクション電子文書のフォーマットおよび処理モジュールを正確に定義する、特殊目的プログラミング言語に対する指定に応じた特定のソフトウェア・モジュールおよびコンポーネントの実現例を設けなければならない。

本発明の好適な実施形態によれば、各ＸＭＬサービス・アクション電子文書は、特定のシンタックスで定義されるべき、特殊目的プログラミング言語で書かれており、ＸＭＬ系であってもなくてもよい。ＸＳＡエンジンは、ＸＳＡ電子文書を解釈し実行する役割を担う。ＸＳＡ電子文書は、動的な生成によってＸＳＡエンジンが利用でき、あるいは要求元クライアントまたはコンピュータ・システムにおけるいずれかのストレージから入手できる。本発明の主旨で書かれた仕様に従って、有効な特殊目的プログラミング言語で書かれたＸＭＬサービス・アクション電子文書を実行可能なシステムは、通常のコンピュータ・システムにおいて実施することができる。

ＸＳＡフレームワークは、いずれの特定の実行コンテキストとも切断され、標準化され、構造化された柔軟で精巧な手段を提供し、出版、業務メッセージ配信、企業アプリケーション統合、および構造化データを処理し操作することに価値があるその他の分野において、多くの問題を一層正しく簡単に解決することができる。

ＸＳＡフレームワークは、既存の技術に対して相補的である。これは、ＸＭＬ処理タスクの管理用フレームワークであって、いずれの特定のタイプの既存のＸＭＬ処理技術に対する代用ではない。例えば、これは、ＸＭＬ文書をどのように変換するのか定義せず、特定的な実施形態は、その目的のためにいずれの既存の方法でも用いることができる。ＸＭＬ処理タスクの管理に特定して設計された上位特殊目的プログラミング言語を要求し利用することによって、汎用プログラミング言語でカスタム・コードを作成し、ＸＭＬ処理サブタスクを互いに張り合わせる必要性を低下または解消さえする。ここで、各サブタスクは、周知のＸＭＬ処理規格、仕様または方法によって調整される。該当する類似物をあげるとすれば、次のようなものであろう。ＸＳＬＴエンジン、ＸＭＬ実証器(validator)、ＨＴＭＬ−ＸＭＬ変換器、ＸＭＬ直列化器、または特定のタイプのＸＭＬ処理タスクを実行するその他のあらゆるモジュールを、プログラムであると見なす。すると、ＸＳＡエンジンは、これらのプログラム間の相互動作を調整するオペレーティング・システムに似ている。ＸＳＡエンジンは、特殊目的プログラミング言語で書かれたＸＳＡ電子文書を解釈し実行することができ、ここに記載されているＸＳＡフレームワークの一般的な主旨の実現例と見なすことができ、したがって、ＸＳＡフレームワークは、オペレーティング・システム・ファミリまたは規格に類似するものと考えることができる。

本発明の特定的な一好適実施形態では、本方法およびシステムは、ワイヤレス・デバイスに、当該デバイスが理解することができるフォーマットの電子文書内の情報を要求することを可能にするために用いられる。デバイスとの通信が可能な適したアダプタ（例えば、ＨＴＴＰアダプタ）を通じて、特定のＸＳＡを呼び出してＸＳＡエンジン内で実行することができる。このＸＳＡ内に定義されているＸＭＬ処理タスクは、バック・エンド・システムからデータを検索し、特定のタイプの生成器を用いてそれをＸＭＬフォーマットに変換し、変換器を用いて、それを要求元デバイスに適したフォーマットに変換し、最後にシンクがそれをアダプタを通じてデバイスに配信することができる。

例えば、本発明の好適な実施形態によれば、ワイヤレス・デバイスから、ハイパーテキスト転送プロトコル（ＨＴＴＰ）準拠のブラウザ・ソフトウェアを用いて特定のＵＲＬに誘導することによって、現在の天候に関する情報を要求することができる。ＸＳＡエンジンは、天候データ源から得た情報からどのように所望の応答を派生するか定義する、特定のＸＳＡ電子文書にアクセスし、それを要求元のデバイスにＨＴＴＰアダプタを通じて配信することができる。この要求は、ＨＴＴＰを通じて要求元クライアントと通信することができるＨＴＴＰアダプタが受信する。次いで、アダプタはＸＳＡエンジンを呼び出し、要求された特定のＸＳＡの実行を開始する。このＸＳＡは、天候データベースに接続することができる、特定のタイプの生成器への参照を収容している。ＸＳＡ内にある命令は、生成器に天候データを検索するように命令し、次いでこれをＸＭＬソース・データに変換する。ＸＳＡは、更に、１つ以上の特定のタイプの変換器（例えば、ＸＳＬＴを用いてＸＭＬを変換する変換器）への参照、およびこれに対する命令も収容することができ、ＸＭＬソース・データを変換して、要求元デバイスにおけるブラウザによる表示に適したワイヤレス・マークアップ言語（ＷＭＬ）フォーマットのＸＭＬ電子文書を形成することができる。最後に、ＸＳＡは、ＷＭＬ電子文書を要求元デバイスにＨＴＴＰアダプタ・モジュールを通じて配信することができる、特定のタイプのシンクへの参照、およびこれに対する命令も収容している。問題の特定のＸＳＡ電子文書は、特殊目的プログラミング言語で書かれており、ＸＳＡプログラミング言語仕様において正確に定義することができる。しかしながら、本発明は、ＨＴＴＰ通信、ワイヤレス・デバイス、あるいはデータベースに限定されるのではない。その他のデータ、プロトコル、ネットワーク・デバイス、または外部システムも用いることができる。

本発明の好適な実施形態の前述のおよびその他の特徴および利点は、添付図面と関連付けて本発明の実施形態の詳細な説明を検討することにより、当業者には一層容易に理解されよう。

本発明の先に引用した利点およびその他の利点が得られる態様を一層深く理解するために、添付の図面を参照しながら本発明の更に詳細な説明を行う。更に、本発明の具合的な実施形態の説明も、添付図面を参照しながら例示する。これらの図面は本発明の典型的な実施形態のみを図示し、したがってその範囲を限定するとは見なさないことを理解した上で、本発明を説明するために添付図面を用い、本発明を行い用いる現時点において最良と理解される態様について、例示の目的のためにのみ、更に詳しく説明する。

ここに記載する実施形態は、それで全てであることも、本発明を開示した形態そのものに限定することも意図してはいない。逆に、説明に選択した実施形態は、当業者がその教示を利用できるように記載されている。最も留意すべきは、ここではＸＭＬ処理に頻繁に言及するが、本発明はＸＭＬ処理にもＸＭＬサービス側アプリケーションにも限定される訳ではなく、あらゆる構造化データに等しく適用可能であることである。

以下の論述は、本発明を実施可能な、相応しい計算環境の端的かつ総合的な説明を行うことを意図している。本発明は、パーソナル・コンピュータによって実行する、プログラム・モジュールのような、コンピュータ実行命令に関して一般的に説明するが、そうしなければならないという訳ではない。一般に、プログラム・モジュールは、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含み、特定のタスクを実行したり、あるいは特定の抽象的データ形式を実装する。更に、当業者には認められようが、本発明は、ハンドヘルド・デバイス、多重プロセッサ・システム、マイクロプロセッサを用いたまたはプログラム可能な消費者用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレーム・コンピュータなどを含む、その他のコンピュータ・システム構成でも実施可能である。また、本発明は、通信ネットワークを通じて連結したリモート処理デバイスによってタスクを実行する、分散型計算環境においても実施可能である。分散計算環境では、プログラム・モジュールは、ローカルおよびリモート・メモリ記憶デバイス双方に配置することもできる。

ここで用いる場合、「ソフトウェア・モジュール」または「モジュール」という用語は、コンピュータ・プログラム内において特定的な論理機能を実行すると別個に認められるあらゆる実行可能命令の集合を意味することとする。

図１は、ＸＭＬ処理システム１０の基本コンポーネントを示すブロック図である。ＸＭＬ処理システム１０は、概略的に、汎用インターフェースを備えたＸＳＡエンジン１６と、外部クライアントにＸＳＡエンジン１６と双方向処理を行わせる１つ以上のアダプタ・モジュール１２とを含む。ＸＳＡエンジン１６は、ＸＭＬ処理タスクの管理のために設計された特殊目的プログラミング言語を用いて、ＸＳＡ電子文書１８にエンコードされている命令を実行することができる。ＸＳＡエンジン１６は、汎用インターフェースを提供するだけであるので、ＸＳＡエンジン１６の呼び出しは、アダプタ・コンポーネント１２を通じて行われ、これによって、一方では１つまたは複数のタイプの外部クライアント４０と、そして他方ではＸＳＡエンジン１６と通信することができる。外部クライアント３０からの各呼び出しまたは要求は、アダプタ・モジュール１２がどのＸＳＡ電子文書１８を実行するのか判定するために用いることができる情報またはデータを収容していなければならない。要求または呼び出しを受信すると、アダプタ・モジュール１２は、ＸＳＡエンジンに、要求の発信元および目的に関する情報を提供することができる。この情報は、ＸＳＡエンジンにはアクセス可能であり、ここではコンテキスト・モジュール１４で代表する。ＸＳＡエンジン１６は、コンテキスト・モジュール１４を利用して、ＸＭＬ処理タスクの管理のために特定的に設計された、特殊目的の明確な上位プログラミング言語で書かれた、要求ＸＳＡ電子文書１８に定義されているＸＭＬ処理タスクを初期化し、実行する。このような特殊目的の上位プログラム言語を有することは、具体的なＸＭＬ処理タスクの作成が、汎用プログラミング言語で可能なよりも簡単にそして迅速に行えることを意味する。ＸＭＬ処理タスクにしか適用できないが、このようなタスクの作成は、特殊目的プログラミング言語を用いれば、遥かに速くそして簡単に行うことができる。また、恐らくはグラフィカル・ユーザ・インターフェースを用い、しかも直接カスタム・コードを書く必要性を完全に排除して、開発者に上位インターフェースを通じて具体的なＸＳＡ文書を作成させる、ソフトウェア・プログラムを作成することもできる。開発者のこのような上位インターフェースとの双方向処理は、恐らくグラフィック・コンポーネントを利用して、テキストを用いたコードを書くことを全く必要とせずに、具体的なＸＳＡを生成することを可能にする場合もある。

本発明は、ＸＭＬ処理タスクを３つのクラスのＸＭＬ処理ステップまたはサブタスク、ＸＭＬ生成、ＸＭＬ変換、およびＸＭＬ配信／反応に分割する。これは、各ＸＳＡ電子文書１８が一般に３つのクラスのＸＭＬ処理モジュールの具体的な実現例に対する引用(reference)を含んでおり、各クラスがこれらのサブタスクの１つに対応するという事実に反映されている。ＸＭＬ生成器モジュール２０は、外部バック・エンド・システム４０に接続し、そのコンテンツ、サービスおよび／または業務ロジックを、ＸＭＬ変換器モジュール２２による更なる処理のために利用可能なＸＭＬデータとして公開する役割を担っている。このステップは、多くの場合、外部システムへの接続と、外部システムのネーティブ・データ構造のＸＭＬフォーマットへのマッピングの定義という双方を伴う。ＸＭＬ変換器モジュール２２は、ＸＭＬ生成器２０から受け取ったＸＭＬデータを、異なるＸＭＬフォーマットに変換する。ＸＳＡ電子文書１８は、ＸＭＬデータの順次処理のために、１つよりも多いＸＭＬ変換器を順次定義することができる（以下で更に詳しく説明する）。ＸＭＬシンク・モジュール２４は、ＸＭＬ変換器モジュール２２から受けたＸＭＬデータに反応するか、またはこれらを配信する。これら３つの抽象的ＸＭＬ処理モジュール・タイプの各々は、アダプタ・モジュール１２が提供し、ここではダイナミックＸＳＡコンテキスト・モジュール１４によって表されるメタ情報にアクセスすることができる。ＸＳＡコンテキスト・モジュール１４内のメタ情報は、特定のＸＳＡの実行が開始する前にアダプタ・モジュール１２によって提供され、ＸＳＡの実行の間中存続する。これは、実行に関与する全てのモジュールにアクセス可能である。コンテキスト・モジュール１４が表すメタ情報は、ＸＳＡが実行するコンテキストを定義する。３つの抽象的ＸＭＬ処理モジュールの各々は、受動リソース・レポジトリ２６にもアクセスすることができる。受動リソース・レポジトリ２６には、電子フォーマットの種々のリソースが、記憶媒体内に格納されている。ＸＳＡ電子文書は、１つ以上のＸＭＬ生成器モジュール、０個以上のＸＭＬ変換器モジュール、および１つ以上のＸＭＬシンク・モジュールを定義し制御することができる。

図２は、具体的な生成器、変換器およびシンクを参照し、特定目的の上位プログラミング言語で指定され、ＸＭＬ処理タスクの管理のために設計された、これらの相互動作を管理することによって、ＸＳＡ電子文書がどのようにして１つの個別ＸＭＬ処理タスクを定義するかを示す。

図３は、ＸＳＡ電子文書を実行しているときのＸＭＬ処理タスクの実行を示すブロック図である。また、この図は、生成器からシンクまでにおいて、その間に０回以上の変換を受ける、ＸＭＬデータの流れを示す。

図４は、本発明によるＸＭＬ処理システムにおけるＸＳＡの実行を開始し完了する一連のイベントを示すフロー・チャートである。外部クライアントからの呼び出し即ち要求が行われる（１）。要求は情報を収容しており、これを用いれば、どのＸＳＡ電子文書を実行すべきか判定することができる。更に、情報は他のコンテキストに左右される情報も収容することができる。全要求情報は、暗示的であれ直接であれ、要求プロパティ（２）と呼ぶこともある。特定のアダプタ・モジュールは、要求元クライアントとの通信が可能であり、要求を受け取り、しかるべきコンテキストに左右される情報にアクセスすることができる場合、ＸＳＡエンジンにＸＳＡコンテキスト・モジュール（４）を供給することによって、ＸＳＡ実行（３）のコンテキストを定義する。アダプタ・モジュールは、ＸＳＡエンジン・モジュール内において特定のＸＳＡの実行を開始する。ＸＳＡエンジンは、ＸＳＡコンテキスト・モジュール内の情報を用いて、特殊目的プログラミング言語で書かれた、要求されたＸＳＡ電子文書（５）の実行の準備を行う。要求されたＸＳＡに定義されている具体的なタイプの生成器が、所与のＸＳＡ（６）における命令にしたがってＸＭＬソース・コンテンツを生成する。その際、一般に、ある外部バック・エンド・システムと通信し、取得したデータをＸＭＬに変換する。その結果は、処理が行われる前のＸＭＬソース・データ（７）である。次に、０個以上のＸＭＬ変換器（８）が、要求されたＸＳＡ内の命令にしたがって、ＸＭＬソース・データを変換し、その結果異なる形式のＸＭＬデータ（９）が得られる。最後に、ＸＭＬシンク・モジュールが何らかの方法でＸＭＬコンテンツを配信するか、またはこれに反応する（１１）ことによって、ＸＭＬ処理タスクを終了する。このステップは、処理したＸＭＬデータの解釈を伴っても、伴わなくてもよい。一般に、ある種の応答が、ＸＭＬシンク（１２）が完了したタスクの結果として、アダプタ・モジュールを通じて、要求元のクライアントに戻される。

図５は、ＸＭＬサービス・アクション・モデルによって定義した、生成器の役割および典型的な構造を示すブロック図である。この図は、一般に、生成器がまず外部システムに接続し、次いでＸＭＬフォーマットで外部システムからのデータを公開するという二重のタスクに直面していることを示す。

図６は、ＸＭＬサービス・アクション・モデルによって定義した変換器の役割を示すブロック図である。この図は、いずれの数の変換器でも順次適用してもよく、そして各１つが入力および出力双方としてＸＭＬデータを有することを示す。

図７は、ＸＭＬサービス・アクション・モデルによって定義したシンクの役割を示すブロック図である。一般に、シンクは、ＸＭＬ入力データを何らかの外部データ・フォーマットに変換して要求元のクライアントに配信または公表するか、あるいは処理したＸＭＬ入力にしたがって何らかの方法で解釈または反応するかのいずれかである。反応は、シンクの目的次第でいずれでもよく、必ずしも要求元クライアントへの応答を伴う必要は全くない。

本発明の好適な一実施形態は、プレゼンテーション・システムであり、相容れない表現の要求がある多くの異なるタイプのネットワーク・クライアント、例えば、多くの異なるタイプの移動デバイスへの、バック・エンド・システム内に常駐するデータの公表を容易にする。このプレゼンテーション・システムは、例えば、ＨＴＴＰプロトコルを通じて、クライアントと通信可能なアダプタ・モジュールを含む。また、プレゼンテーション・システムは、バック・エンド・システム（複数のバック・エンド・システム）と通信し、バック・エンド・システムのデータをＸＭＬフォーマットで公開することができる、特定のタイプの生成器モジュールも備えている。また、このプレゼンテーション・システムは、汎用ソースＸＭＬデータをバック・エンド・システムから、ネットワーク・クライアント・デバイスの各々における表示に適した多くの異なるフォーマットに変換することができる、特定のタイプの変換器モジュールも内蔵している。また、このシステムは、個別製作したコンテンツを要求元クライアント・デバイスに、要求を送ったアダプタを通じて返送することができるシンクも内蔵している。また、このシステムは、特殊目的プログラミング言語で書かれた特定のＸＳＡ電子文書も収容しており、ＸＭＬデータの処理を管理し、どのクライアントがコンテンツの要求を行ったかに応じて、該当する生成器、変換器、およびシンクが必ず用いられるようにする。プレゼンテーション・システムは、本質的に、ＸＳＡフレームワークのため拡張可能であり、生のコンテンツ・データのプレゼンテーション情報からの完全な分離を促進する。新たなバック・エンド・システム、新たなクライアント、または新たな通信プロトコルに対応するにも、単に新たな生成器、変換器またはアダプタを追加するだけで済む。

本発明の別の実施形態は、メッセージング・システムであり、一般には安全な方法で一方の外部システムから他方へインターネットを通じて、ｅｂＸＭＬまたはＢｉｚＴａｌｋのような標準化された業務メッセージング・プロトコルを用いて、業務メッセージを配信する。このシステムは、当該プロトコルを用いて通信することができるアダプタ・モジュールを必要とする。また、このシステムは、通信システムからＸＭＬフォーマットのデータを抽出することができる特定のタイプの生成器モジュールも内蔵している。更に、これは、システム・データを配信に向けた業務メッセージに変えることができる種々の変換器も内蔵することができる。また、このシステムは、該当するアダプタ・モジュールを通じてメッセージをその宛先に配信することができる特定のシンク・モジュールも内蔵している。また、このシステムは、異なる規格の業務メッセージ間で翻訳が可能な特定のタイプの変換器も内蔵することができる。最後に、このシステムは、特殊目的プログラミング言語で書かれ、ＸＭＬ処理を管理および制御する、特定のＸＳＡ電子文書と、これらの文書を実行する要求があったときに、それを行うことができるＸＳＡエンジンとを内蔵している。

本発明の更に別の実施形態は、異質な発信源と宛先のアプリケーションとの間でデータを統合化することができる統合システムである。この種の統合システムは、ＸＳＡエンジン、特殊目的プログラミング言語で書かれた特定のＸＳＡ電子文書、発信元および宛先アプリケーション間で通信することができる特定のアダプタ・モジュール、発信元および宛先アプリケーションのネーティブ・データ構造をＸＭＬフォーマットに変換することができる特定の発生器、ソース・アプリケーションから入力されるＸＭＬを宛先アプリケーションへの配信に適したＸＭＬフォーマットに変換することができる特定の変換器、および最後に、処理（変換）したＸＭＬデータを宛先アプリケーションに配信することができるシンク・コンポーネントを備えている。

以下に、本発明の更に別の好適な実施形態を詳細に説明する。以後、これを実施形態Ａと呼ぶことにする。実施形態Ａは、ＸＭＬサービス・アクション電子文書に可能な１つのフォーマットを高精度に定義する特殊目的プログラミング言語の仕様であり、そのセマンティックス(semantics)を説明し、更に実施形態Ａによって定義された仕様にしたがって書かれたＸＳＡエンジンの実現例によって、それがどのように解釈されるかについて説明する。実施形態Ａは、ＸＭＬ処理タスクの管理のために設計された、特殊目的プログラミング言語のＸＭＬサービス・アクション仕様の一例として記述することができ、当業者であれば、これを利用して、通常のコンピュータ・システムにおいて本発明の具体的な実現例を作成することができる。実施形態Ａは、前述の他の実施形態全てについても、正確に述べたフレームワークとして用いることもできる。

実施形態Ａによれば、ＸＳＡ電子文書は、文書形式定義（ＤＴＤ）に従うＸＭＬフォーマットに基づいて、特殊目的プログラミング言語で書かれている。ＸＭＬ電子文書は、有効はＸＳＡ文書を構成し、ここではＸＳＡ定義と呼ぶこともある。

以下に、実施形態Ａの記述に用いられる用語の定義を示す。
ＸＳＡ実行エンジン：実施形態Ａのために定義されたＸＳＡ定義を実行することができるソフトウェア実現例。

ＸＳＡ定義：実行する各ＸＳＡはＸＭＬ文書として指定される。文書の場所や形態は、実施形態Ａの仕様には全く制約されず、記憶媒体から読み取ったり、実行時に機械で生成したり、あるいはその他のいずれの方法でも取得することができる。実施形態Ａについて定義されたＸＳＡの１つのインスタンスを記述するＸＭＬ文書を、ＸＳＡ定義と呼ぶ。

ＸＭＬ動作：各ＸＳＡ定義は、多数のＸＭＬ動作で構成されている。ＸＭＬ動作とは、ＸＳＡにおける実行の単位であり、これらはＸＳＡ定義に定義されているように順次実行される。

ＸＳＡコンポーネント：ＸＭＬ動作において用いられるコンポーネントをＸＳＡコンポーネントと呼ぶ。ＸＳＡコンポーネントの例には、生成器、変換器およびシンクのような、実行パイプラインのブロックが含まれる。

ＸＳＡコンポーネントは常にＸＳＡ定義内において参照されるが、使用する実際のコンポーネントは、ＸＳＡ定義の外側で定義され、使用するコンポーネントのプログラミング言語、実現例、および構成において完全な自由を実施者に与える。

生成器：生成器は、何らかの特定的な方法でＸＭＬデータを生成するコンポーネントである。生成器がＸＭＬを作成するために用いる方法は、用いられる生成器コンポーネントの実現例によって異なる。

変換器：変換器は、ある特定の方法でＸＭＬデータを変換するコンポーネントである。ＸＭＬに変換する際に用いる方法は、用いられる変換器コンポーネントの実現例によって異なる。

シンク：シンクは、処理後のＸＭＬデータを配信するコンポーネントである。配信は、ＸＭＬデータを内部形式でメモリに保持することから、何らかの外部フォーマットにそれをシリアル化し、データベースに格納することまでのいずれでも含むことができる。

パイプライン：パイプラインは、生成器、一連の変換器、およびシンクを組み合わせて、一連の実行を形成する。ＸＭＬデータは、生成器から変換器を介してシンクまで流れる。

条件付き動作：条件付き動作を用いて、どのパイプラインを実行するかを判断し、実行の流れを制御することができる。
ＸＳＡコンテキスト：各ＸＳＡ実行は、コンテキストにおいて行われ、名称のある数個のスコープを通じて、１組の名称のある変数へのアクセスを与える。

スコープ：ＸＳＡコンテキストは、名称のある全ての変数をスコープに格納する。スコープは、要求、セッション、クライアント、ユーザ、およびアプリケーションである。各スコープは、本明細書において後に実施形態Ａについて定義するような意味を有する。

変数：変数という用語は、ＸＳＡコンテキストに格納される名称−値対に対して用いられる。変数は、名称および値を有し、あるスコープに属する。
以下に、実施形態Ａによる、ＸＭＬ動作を定義する際に用いられる、ＸＳＡ定義の基本的シンタックス・エレメントの説明を行う。

実施形態Ａのこの仕様にしたがって書かれる各ＸＳＡ定義は、DOCTYPE宣言を含み、公表識別子を"-//Dimon//DTD XSA 1.1//EN"に設定しなければならない。このＤＴＤは次の通りである。

［表１］
<!--
実施形態ＡのＸＭＬサービス・アクション仕様
Namespace=http://www.dimon.is/namespaces/xsa
このＤＴＤモジュールは、このPUBLIC識別子、
PUBLIC "-//Dimon//DTD XSA 1.1//EN"
およびこのカノニカル・システム識別子によって識別する。
SYSTEM"http://www.dimon.is/dtds/xsa/1.1/xsa/dtd"
システム識別子は変化する場合がある。DOCTYPE宣言は次のように示すことができる。
<!DOCTYPE xsa PUBLIC "-..Dimon//DTD XSA 1.1//EN""xsa.dtd">
Review:DRAFT
-->

<!--サーバ内のどこかで定義し構成したコンポーネントのＩＤを参照-->
<!ENTITY % refid"refid CDATA #required">

<!--所与の範囲における名称のある変数の仕様-->
<!ENTITY % variablespec"
scope (request||session|client|user|application) #required
name CDATA #required">

<!--アクションの一般的サブパーツ-->
<!ENTITY % XML Operation "(pipeline|setvariable|removevariable|lif|operation)">

<!--あらゆる値の指定子。out-param-valueは特殊な場合であり、out-paramの下位としてのみ用いることができる。その他はvaluespecがコンテンツ・モデル内であればどこでも用いることができる-->
<!ENTITY % valuespec "(null|literal|getvariable|mapping|out-param-value)">

<!--条件の一括表現-->
<!ENTITY % anycondition “(and|or|not|isdefined|isoftype|equlas|condition)”>

<!-入力／出力パラメータ割り当ての一括表現a
<!ENTITY %inoutparam "(out-param|in-param)">

<!--あらゆるアクション仕様のルート・エレメント-->
<!ELEMENT xsa (support*,errordef*,(%XMLOperation;)+)>
<!ATTLIST xsa
version CDATA #required
xmin CDATA 'http://www.dimon.is/namespaces/xsa'
>

<!-- 所与のアダプタに対する対応を示す。対応エレメントが現れない場合、いずれのアダプタでも、このＸＳＡを呼び出すことができると想定することができる
-->
<!ELEMENT supports EMPTY>
<!ATTLIST supports
adaptername CDATA #required
>

<!-- エラー、およびこのエラーの場合に呼び出すＸＳＡを定義する。
このコンテンツは、英語の記述的エラー・メッセージとすることができる。
名称属性はエラーの名称であり、呼び出しはこのエラーの場合に呼び出すＸＳＡへの参照を与えなければならない。
-->
<!ELEMENT errodef #PCDATA>
<!ATTLIST errordef
name CDATA #required
invokes CDATA #required
>

<!--ＸＭＬパイプラインを実行する動作を表す。
生成器、変換器、およびシンクはネスト状エレメントによって指定する-->
<!ELEMENT pipeline ((generator|raiseerror), (transformer||raiseerror)*, (sink|raiseerror))>

<!--スコープにおいて変数を設定する動作を表す。
内容は設定する値を指定する-->
<!ELEMENT setvariable (%valuespec;)>
<!ATTLIST setvariable
%variablespec;
failonerror (true|false) "true"
>

<!--スコープにおいて変数を除去する動作を表す-->
<!ELEMENT removevariable EMPTY>
<!ATTLIST removevariable
%variablespec;
failonerror (true|false) "true"
>

<!--条件を評価することによって２つの動作リスト間で選択を行った後、その１つにおける各動作を実行する動作を表す-->
<!ELEMENT if (%anycondition;,then,else?)>

<!--条件を評価して真になったときに実行するＸＭＬ動作のコンテナ-->
<!ELEMENT then ((%XML Operation;)*)>

<!--条件を評価して真になったときに実行するＸＭＬ動作のコンテナ-->
<!ELEMENT else ((%XML Operation;)*)>

<!--ＳＡＸチェーンを開始する生成器のインスタンス化を表す。
いずれかの場所で構成された生成器ファクトリを参照し、それを呼び出すためのパラメータを指定する-->
<!ELEMENT generator ((%inoutparam;)*)>
<!ATTLIST generator
%refid;
>

<!--ＳＡＸチェーンの一部としての変換器のインスタンス化を表す。
いずれかの場所で構成された変換器ファクトリを参照し、それを呼び出すためのパラメータを指定する-->
<!ELEMENT transformer ((%inoutparam;)*)>
<!ATTLIST transformer
%refid;
>

<!--ＳＡＸチェーンを終了するシンクのインスタンス化を表す。
いずれかの場所で構成されたシンク・ファクトリを参照し、それを呼び出すためのパラメータを指定する-->
<!ELEMENT sink ((%inoutparam;)*)>
<!ATTLIST sink
%refid;
>

<!-- ＸＰａｔｈを評価して真になった場合、エラーを出す。
エラー属性は、出すエラーの名称を収容していなければならず、検査属性は評価するＸＰａｔｈを収容していなければならない-->
<!ELEMENT raiseerror EMPTY>
<!ATTLIST raiseerror
error CDATA #required
test CDATA #required
>

<!--所与の変数の値を得ることを表す-->
<!ELEMENT getvariable EMPTY>
<!ATTLIST getvariable
%variablespec;
>

<!--どこかで定義された条件を参照する
ネストされたin-paramエレメントによって割り当てられた入力パラメータを取る場合もある-->
<!ELEMENT condition (in-param*)>
<!ATTLIST condition
%refid;
>

<!--ＡＮＤ条件、全てのネストされた条件が真となる場合にのみ、真となる-->
<!ELEMENT and ((%anycondition;)+)>

<!--包含的ＯＲ条件、ネストされた条件の１つが真となる場合にのみ、真となる-->
<!ELEMENT or ((%anycondition;)+)>

<!--否定条件、ネストされた条件の否定を出す-->
<!ELEMENT not ((%anycondition;))>

<!-- is-defined条件、全てのネストされた値（あらゆるオブジェクト）がヌルでないか否かを出す。
ネストされた値がない縮退の場合に真を出す-->
<!ELEMENT isdefined ((%valuespec;)*)>

<!-- is-of-type 条件、最初のネストされた値（いずれかのオブジェクト）が２番目のネストされた値（ストリング）によって命名されたクラスのものであるか否かを出す。いずれかがヌルの場合偽を出す-->
<!ELEMENT isoftype ((%valuespec;),(%valuespec;))>

<--等価条件、最初のネストされた値が、イコール・メソッドによって判定された、その他の各々と等しいか否かを出す。全てがヌルの場合真を出す。一部がヌルであり、一部がそうでない場合、偽を出す。
ネストされた値が１つのみの縮退の場合に真を出す
-->
<!ELEMENNT equals ((%valuespec;)+)>

<!--名称付入力パラメータに値を割り当てることを表す-->
<!ELEMENT in-param(%valuespec;)>
<!ATTLIST in-param
name CDATA #required
>

<!--１つ以上の入力パラメータを取り込み、結果値を出すマッピングを表す。入力パラメータは、ネストされたin-paramによって与えられる-->
<!ELEMENT mapping (in-param*)>
<!ATTLIST mapping
%refid;
>

<!--出力パラメータを変数に割り当てることを表す-->
<!ELEMENT out-param (setvariable)>
<!ATTLIST out-param
name CDATA #required
>

<!-- out-paramエレメントの子孫として用いられるときに、出力パラメータの値を表す。それ以外の場合にはいずれも違法-->
<!ELLEMENT out-param-value EMPTY>

<!-- ヌル（duh）の値を表す-->
<!ELEMENT null EMPTY>

<!-- 文字で指定された値を表す-->
<!ELEMENT literal (#PCDATA)>

<!-- 所与のパーザ・クラスによって構成されるカスタムＸＭＬ動作を表す。パーザ・クラスは、ＸＳＡパーザ・クラスローダ内になければならず、デフォルトのコンストラクタを有していなければならない。
このエレメントは任意のＸＭＬを収容している場合がある。ＸＭＬが別個の名称空間にあるか（このＤＴＤとの障害を避けるため）、またはこのＤＴＤを解析の時点で実行しないかのいずれかが必要である。
-->
<!ELEMENT operation EMPTY>
<!ATTLIST operation
parserClass CDATA #required
>

DOCTYPE宣言の一例は、次の通りである。

［表２］
<!DOCTYPE xsa
PUBLIC "-//Dimon//DTD XSA 1.1//EN"
"http://www.dimon.is/dtds/xsa/1.1/xsa/dtd">

ＸＳＡ定義のルート・エレメントは<xsa>である。ＸＳＡが実施形態Ａのこの仕様にしたがって書かれたのであれば、これは、１．１の値を有するバージョン属性を収容していなければならない。空のルート・エレメントの一例は、次のようにすることができる。

［表３］
<xsa version="1.1" xmlns="http://www.dimon.is/namespaces/xsa">
</xsa>

ルートの内側では、ＸＳＡ定義は、以下で論ずるように、いずれの数のエレメントでも収容する。これらのエレメントの殆どは、ＸＭＬ動作に対応する。ＸＭＬ動作のタイプについては、後に以下で更に詳しく論ずるが、以下のリストは、本発明の実施形態Ａによるルート・エレメントの内側で許される各タイプのＸＭＬエレメントについて端的に記述する。

パイプライン：パイプラインは、<pipeline>エレメントによって定義される。パイプラインは、生成器、変換器およびシンクを組み合わせ、ＸＭＬデータを処理するために基本的エレメントを用いる。

変数：<setvariable>および<removevariable>エレメントによって操作され、<getvariable>エレメントによってアクセスされる。変数は、制御情報を外部のＸＳＡ実行に受け渡し、そしてＸＳＡ実行から受け取り、更に内部においてＸＳＡのコンポーネント間で受け渡す手段である。

変数は、ＸＳＡコンテンツの一部である。これについては、以下で詳しく論ずる。
条件：条件は、<if>エレメントによって定義される。これらは、どのＸＭＬ動作を実行し、どのＸＭＬ動作を実行しないか制御する際に用いることができる。

カスタム動作：カスタム動作は、<operation>エレメントによって定義される。これらは、いずれのカスタムＸＭＬ動作を行うときにでも用いることができる。
各ＸＭＬ動作のシンタックスについては、以下で論ずる。実施形態Ａの仕様によるＸＳＡ定義の一例は、次のようにすることができる。

［表４］
<?xml version='1.0'?>
<!DOCTYPE xsa
PUBLIC "-..Dimon..DTD XSA 1.1//EN"
"http://www.dimon.is/dtds/xsa/1.1/xsa.dtd">
<xsa version="1.1" xmlns="http://www.dimon.is/namespaces/xsa">
<setvariable scope="request" name="http.response.Content-Type">
<literal>text/plain</literal>
</setvariable>
<pipeline>
<generator refid="index"/>
<transformer refid="resourcetrax">
<in-param name="xsl">
<literal>index.xsl</literal>
</in-param>
</transformer>
<sink refid="clipsersink">
<in-param name="outputStream">
<getvariable scope="request" name="http.responsestream"/>
</in-param>
</sink>
</pipeline>
</xsa>

実施形態Ａにおいて記述された特殊目的プログラミング言語の仕様によれば、ＸＳＡ定義は線形の順序で実行される。これが意味するのは、各ＸＭＬ動作を完全に評価した後に、リスト中の次のＸＭＬ動作を評価するということである。実現例は、この順序付けに従わなければならない。何故なら、変数の設定は、実行の順序に左右される可能性があるからである。

以下に、実施形態Ａの実行コンテキストの記述を示す。
ＸＳＡは、ＸＳＡ定義内に定義されている処理を活性化するために実行する。ＸＳＡを実行する毎に、ＸＳＡコンテキストにアクセスする。ＸＳＡコンテキストは、スコープ内に定義されている１組の変数を公開する。この仕様では、特定の変数名を定義しないが、全ての変数は、次の名称付スコープの１つに属さなければならない。

実施形態Ａのこの仕様は、変数のスコープとは無関係に、特定の変数へのリード／ライト・アクセスを定義しない。実施形態の中には、必要に応じてある変数へのアクセスを制限してこの要件を満たそうとする場合もあり、一例を示せば、ユーザ・スコープ内の変数にはリード・アクセスを許すが、ライト・アクセスは許さないというものであろう。設定した制限に違反した場合、エラーを発生しなければならず、以下で説明するエラー処理を、それに応じて呼び出さなければならない。どんなエラーが生じたかは、実現例の詳細である。

ＸＳＡコンテキストに変数を設定するには、その変数への書き込みが実現例によって許される限り、その変数に以前にあった値を上書きしなければならない（いずれかの値が存在している場合）。以下のスコープが、実施形態Ａのこの実施形態において定義されている。これらのスコープのランタイム環境へのマッピングは、この実施形態Ａの仕様による実現例次第である。実施するマッピングは、以下に与える記述に従わなければならない。

要求：要求スコープは、現ＸＳＡの実行後も存続している必要があるが、それ以上存続する必要はない。これは、ＸＳＡの呼び出し側(invoker)が初期化したデータを収容し、ＸＳＡの実行によって、このスコープに定義されている変数を変更することができる。全ての実現例は、要求スコープに対応していなければならない。

セッション：セッション・スコープは、同じセッションが用いられている限り、複数の要求の間は存続している必要がある。「セッション」の定義は、実現例に委ねられるが、自明な例は、ＸＳＡモデルを用いたウェブ・サーバの場合におけるＨＴＴＰセッションである。セッション・スコープに対応するのはオプションである。

クライアント：クライアント・スコープは、直接的または間接的にＸＳＡを呼び出したクライアントに適用されるデータのために用いられる。クライアントの定義は、実現例に委ねられるが、一例は、ＸＳＡモデルを用いたウェブ・ページを呼び出すブラウザである。クライアント・スコープに対応するのはオプションである。

ユーザ：ユーザ・スコープは、直接的または間接的にＸＳＡを呼び出したユーザ・アイデンティティ（通例、人）に関連するデータのために用いられる。ユーザの観念は、実施形態Ａのこの仕様の多くの実現例には適用できない場合もあるので、ユーザ・スコープに対応するのはオプションである。ある実現例がユーザ識別に対応しても、ユーザ・スコープはオプションである。

アプリケーション：アプリケーション・スコープは、ＸＳＡが実行しているアプリケーションに関連するデータのために用いられる。アプリケーションの定義は、ＸＳＡ仕様の実現例に委ねられる。アプリケーション・スコープに対応するのはオプションである。

本発明の実施形態Ａの仕様は、複数の変数のスコープが一体となってＸＳＡコンテキストと呼ばれるものを形成することを述べている。ＸＳＡコンテキストは、ＸＳＡの実行前に初期化すると有用であるが、望ましいのであれば、ＸＳＡ実行の間に再度使用することもできる。その場合、実現例は、ＸＳＡコンテキストがいつ、そしてどのような場合に再度使用されているか明確に定義し、潜在的なセキュリティ・ホール(security hole)を回避しなければならない。

以下に、本発明の実施形態Ａのパイプラインについての概念を詳細に説明する。
パイプラインは、一連のＸＭＬ生成器、変換器、およびシンクを定義する。パイプライン・エレメントは、ＸＳＡ定義のＸＭＬ動作である。

パイプラインは、<pipeline>エレメントによって定義される。これは、エレメントを順序付けたリストを収容しており、リストは、必須の生成器から始まり、続いていずれかの数の変換器、そして必須のシンクで終了する。

データ・フローは、生成器において始まり、処理すべきＸＭＬ文書（複数の文書）を作成し、変換器を通過して、ＸＭＬデータの構造およびコンテンツを修正し、最後にシンクにて終了し、指定された形態のデータを配信するかまたはこれに反応する。

パイプラインの種々の部分間を流れるデータは、ＸＭＬ形式となっている。この実現例は、このデータをいずれの特定の形式で保持することも必要ではなく、ＳＡＸおよびＤＯＭのような共通ＡＰＩを用いることもできる。コンポーネント間を流れるデータに加えて、入力および出力パラメータもコンポーネント毎に用いることができる。これらのパラメータの評価順序には、この仕様では制約がない。これは、パイプラインにおける前方のコンポーネントからの出力パラメータは、パイプラインにおける後方のコンポーネントへの入力には利用できない場合もあることを意味する。唯一の制約は、パイプラインは、ＸＳＡにおける次のＸＭＬ動作を実行する前に、そのパラメータ評価および実行を完了しなければならないことである。以下に、パイプラインにおいて用いられるＸＳＡコンポーネント・タイプを説明する。まず、全コンポーネント・タイプに共通な属性の説明から開始する。

ＸＳＡコンポーネントは、パイプライン実行中におけるある形態の作業を実行するために、パイプライン内において用いられる。ＸＳＡコンポーネントは、外部で定義され、ＸＳＡ定義から引用される。ＸＳＡコンポーネントを定義するために用いられる方法、ＸＳＡコンポーネントを引用するために用いられる指名方法、およびＸＳＡコンポーネントによって実施されるインターフェースは、実施形態Ａのこの仕様では扱われない、実現例の詳細である。

用いるコンポーネント・インスタンスの名称は、ＸＳＡコンポーネントのrefid属性において与えられる。この参照は、常に、使用中のプログラミング言語によって定義されるのと同じオブジェクト・インスタンスを引用しなければならず、何らかの方法でオブジェクトが変更された場合、これを引用している全てのＸＳＡ定義もそれに応じて更新しなければならない。

外部から引用されることに加えて、ＸＳＡコンポーネントは、１つ以上の共通能力(ability)、即ち、入力および出力パラメータを共有する。
各ＸＳＡコンポーネントは、いずれの数の名称付入力および出力パラメータでも定義することができる。ＸＳＡ定義の中では、入力パラメータは<in-param>エレメントと共に与えられ、出力パラメータは、<out-param>エレメントと共に与えられる。
<in-param>エレメントのフォーマットは次の通りである。

［表５］
<in-param name="xsl">
<!-- Value specification -->
</in-param>

<out-param>エレメントのフォーマットは次の通りである。

［表６］
<out-param name="xsl">
<setvariable ...>
...
</setvariable>
</out-param>

各入力および出力パラメータの名称は、コンポーネントの実現例によって定義される。

以下に、本発明の実施形態Ａについて指定した生成器コンポーネントを説明する。
生成器は、パイプラインにおいて処理するＸＭＬデータを作成するために用いられるＸＳＡコンポーネントである。どのように生成器がＸＭＬを作成するかは、実現例毎に様々であり、その例には、ＸＭＬをファイルから読み出し、それをネットワークを通じて取り込み、データベースにアクセスしデータをＸＭＬに変換することが含まれる。生成器の出力は、常にＸＭＬの実現例の内部表現において正しく形成されている必要がある。ＸＳＡ実行エンジンは、この要件を各生成器に強制するが、そうしなくてもよい。

生成器は常にパイプラインの先頭において定義され、全てのパイプラインにおいて必要である。<generator>エレメントは、パイプラインにおいて生成器を定義するために用いられる。全てのＸＳＡコンポーネントと同様、生成器は、名称付入力および出力パラメータに対応する。<generator>エレメントの形式は、次の通りである。

［表７］
<generator refid="mygen">
<in-param name="myinparam">
...
</in-param>
...
<out-param name="myoutparam">
...
</out-param>
...
</generator>

以下に、本発明の実施形態Ａにおいて指定した、変換器コンポーネントについて説明する。

変換器は、データをあるＸＭＬ形式から別の形式に変換する際に用いられるＸＳＡコンポーネントである。変換器がどのようにＸＭＬを処理するかは、実現例毎に様々であり、その例には、ＸＳＬＴを用いる、カスタム・コード化変更(custom coded modification)をテキスト・ノードに適用する、ソートする、有効性を判断する等が含まれる。変換器の出力は、常にＸＭＬの実現例の内部表現において正しく形成されていることが要求され、その入力も、生成器または別の変換器のいずれから来るのであり、これら双方は正しく形成されたＸＭＬを生成することが要求されているので、正しく形成されている。ＸＳＡ実行エンジンは、この要件を各変換器に強制するが、そうしなくてもよい。変換器は、パイプライン定義の中では必要でない。変換器が現れるときは、常に生成器の後ろで、シンクの前に現れる。<transformer>エレメントは、パイプラインにおいて変換器を定義する際に用いられる。全てのＸＳＡコンポーネントと同様、変換器は名称付入力および出力に対応する。<transformer>エレメントの形式は次の通りである。

［表８］
<transformer refid="mytran">
<in-param name="myinparam">
...
</in-param>
...
<out-param name="myoutparam">
...
</out-param>
...
</transformer>

以下に、本発明の実施形態Ａにおいて指定されているシンク・コンポーネントについて説明する。

シンクは、パイプラインにおいて実行した処理から得られたＸＭＬデータの内部表現を扱うために用いられるＸＳＡコンポーネントである。シンクがＸＭＬで何を行うかは、実現例毎に様々であり、その例には、ＸＭＬをファイルに書き込む、それをＨＴＭＬとしてウェブ・ブラウザに送る、またはそれからＰＤＦを生成することが含まれる。生成器または変換器は常にシンクへの入力を生成するので、これは正しく形成される。シンクからの出力には何の制限も設定されない。

シンクは、常に、パイプラインの終端において定義され、全てのパイプラインにおいて必要とされる。<sink>エレメントは、パイプラインにおいてシンクを定義する際に用いられる。全てのＸＳＡコンポーネントと同様、シンクは名称付入力および出力パラメータに対応する。<sink>エレメントの形式は次の通りである。

［表９］
<sink refid="mysink">
<in-param name="myinparam">
...
</in-param>
...
<out-param name="myoutparam">
...
</out-param>
...
</sink>

以下に、本発明の実施形態ＡのＸＳＡ仕様による変数および値の仕様について説明する。

ＸＳＡにおける変数動作は、常にＸＳＡコンテキストにおける変数に適用される。
ＸＳＡ定義のルート・レベル上および条件内では、変数を設定し除去することができる。変数を設定するには、<setvariable>エレメントを用い、変数を除去するには、<removevariable>エレメントを用いる。failonerror属性は、エラーが発生した場合に、動作を中止するか否かを定義し、デフォルトでは真になっている。
以下に、本発明の実施形態Ａの仕様による<setvariable>エレメントのフォーマットを示す。

［表１０］
<setvariable scope="request" name="var" failonerror="true">
<!--値の指定-->
</setvariable>

以下に、本発明の実施形態Ａの仕様による<removevariable>エレメントのフォーマットを示す。

［表１１］
<removevariable scope="request" name="var" failonerror="true"/>

スコープ属性が必要であり、要求、セッション、クライアント、ユーザ、またはアプリケーションの内いずれか１つに設定しなければならない。

名称属性が必要であり、指定されたスコープ内における変数の名称を指定する。
<null>、<literal>、<getvariable>、<mapping>、および<out-param-value>エレメントを用いて、異なる値指定を定義することができる。これらについて以下で順に説明する。特定のＸＳＡコンテキストでは、値の指定によってある値を求め、<setvariable>動作への入力として用いる。

<null>値指定は、Ｊａｖａプログラミング言語では常にヌルの参照(null reference)を求め、または他の言語とのからみ(binding)ではその同等値を求める。このエレメントには、コンテンツも属性もない。変数をヌルに設定すると、変数を全く設定しないのと同じ効果がある。<literal>値指定は、当該値に用いられる文字データを定義する。これは、ＸＳＡコンテキストには関係なく、<literal>エレメントに収容されているテキストを求める。コンポーネントは、これを数値、日付、またはその他の単純な形式に変換することができるが、このような形式変更(typing)は、ＸＳＡ仕様および実現例の範囲外のことである。<literal>エレメントの例は、次の通りである。

［表１２］
<literal>これは文字値である</literal>

<getvariable>変数指定は、所与のスコープにおいて所与の名称を有する変数の値を求める。スコープおよび名称は属性として与えられる。<getvariable>にはコンテンツが許されていない。<getvariable>エレメントの例は、次の通りである。

［表１３］
<getvariable scope="request" name="var"/>

スコープおよび名称属性が必要であり、スコープ属性は、要求、セッション、クライアント、ユーザ、またはアプリケーションの内いずれか１つに設定しなければならない。

<mapping>値指定は、実施形態ＡのＸＳＡ仕様によって定義されないカスタム値指定を参照する際に用いられる。これは、先に定義したように、ＸＳＡコンポーネントと同様の入力パラメータを有することができるが、出力パラメータを有することはできない。<mapping>エレメントの例は、次の通りである。

［表１４］
<mapping refd="mymapping">
<in-param name="myparam">
<literal>literalValue</literal>
</in-param>
</mapping>

<out-param-value>値指定は、<out-param>エレメントの子孫としてのみ用いることができ、<out-param>エレメントは、パイプラインにおけるＸＳＡコンポーネントにおいて用いられ、先に定義した。<out-param>エレメントの内側にある場合、<out-param-value>が出力パラメータの値を収容し、例えば、出力パラメータの値を格納するために、他の動作の入力として用いることができる。<out-param>エレメントのコンテキストにおける<out-param-value>エレメントの例は、次の通りである。

［表１５］
<out-param name="out">
<setvariable scope="request" name="var">
<out-param-value/>
</setvariable>
</out-param>

以下に、本発明の実施形態Ａの仕様によって定義した、条件付き動作について説明する。

条件付き動作は、どのＸＭＬ動作を実行するか制御する際に用いることができる。これらは、実行すべき異なるパイプライン間で選択することを意図している。
全ての条件は、ルート<if>エレメント内で与えられる。条件付き動作は、ブール論理エレメントであり、真であると、<then>エレメント内に収容されているＸＭＬ動作が実行される。ブール・エレメントの評価で偽となった場合、オプションの<else>エレメントが、その場合に実行するＸＭＬ動作を収容することができる。尚、<if>自体はＸＭＬ動作エレメントであるので、条件付き動作をネストできることを注記しておく。
<if>ＸＭＬ動作のフォーマットは、次の通りである。

［表１６］
<if>
<!--ブール論理エレメント、and、or、not、isdefined、isoftype、equals、conditionのいずれか -->
<then>
...
</then>
<else>
...
</else>
</if>

以下に、本発明の実施形態Ａの仕様による<if>エレメント内で用いられるように定義した種々のブール論理エレメントについて説明する。

<and>エレメントは、ＡＮＤブール論理演算子を定義する。<and>エレメントの内容は、１つ以上のブール論理エレメントである。
<or>エレメントは、ＯＲブール論理演算子を定義する。<or>エレメントの内容は、１つ以上のブール論理エレメントである。

<not>エレメントは、ＮＯＴブール論理演算子を定義する。<not>エレメントの内容は、別のブール論理エレメントである。
<isdefined>エレメントは、先に定義したように、０個以上の値指定を収容し、実現例言語結合(implementation language binding)によって定義されているように、全ての値が非ヌルの場合、真となる。値指定が全く含まれていない場合、<isdefined>エレメントは真となる。

<isoftype>エレメントは、先に定義したように、２つの値指定を収容しなければならず、最初の値が２番目の値によって指定されたタイプである場合、真となる。ここで、「タイプ」の意味は、実現例言語結合によって定義されている。いずれの値もヌルである場合、このエレメントは偽となる。

<equals>エレメントは、先に定義したように１つ以上の値指定を収容し、実現例言語結合によって定義されているように、全ての値が「等しい」ときにのみ、真となる。
全ての値がヌルである場合、<equals>エレメントは真となる。一部がヌルであるが全てではない場合、偽となる。１つの値指定のみが指定されている場合、<equals>は真となる（値がヌルであっても）。

<condition>エレメントは、カスタム条件を定義する際に用いられる。これは、出力パラメータに対応していないことを除いて、先に定義したように、ＸＳＡコンポーネントと同じ定義を有する。ブール結果がどのように評価されるかは、カスタム条件の実現例によって異なる。以下に、本発明の実施形態Ａによるエラー・ハンドリング仕様について説明する。

エラー・ハンドリングは、エレメントＡによるＸＳＡを用いる場合には二重となる。最初に、エラー定義があり、エラーを定義し、当該エラーの場合に何をすべきか定義する際に用いることができる。第２に、エラーは、パイプライン実行中いつでも発生する可能性がある。

名称付エラーの意味は、実施形態Ａのこの仕様では、指定されていない。即ち、この仕様では、規定のエラーは与えられていない。
実施形態Ａのこの仕様による各実現例は、汎用フォールバック・エラー機構(generic fall-back error mechanism)を有する必要があり、これは、ＸＳＡ定義に対して定義したエラーの中で一致が得られない場合に、エラー・ハンドリングに対処する。この仕様は、このエラー・ハンドリングがどのように作用するか、またエラーの場合に何をすべきかについて定義していない。

エラーは、名称によって定義され、各ＸＳＡ指定は、ある名称付エラーが発生した場合、何をするか指定することができる。エラーは、いずれのＸＭＬ動作の前にでも、ＸＳＡ定義のルートにおいて定義する。エラー定義において用いられる名称は、ツリー構造に従わなければならず、ドット（．）キャラクタが、各ツリー・レベルにおいて名称を分離する。各レベルにおいて、全ての英数字ＡＳＣＩＩキャラクタが許されている。正しいエラー名称の一例に、something.error.specificをあげることができる。この構造は、エラーが呼び出されたときに、どのエラー定義を用いるべきか選択するために用いられる。

<errordef>エレメントは、エラーを定義する際に用いられる。名称属性は、エラーの名称を収容し、呼び出し属性は、ＸＳＡ定義への参照を与え、エラーが発生した場合に呼び出すようにしなければならない。<errodef>エレメントの内容は、人が読むことのできるエラーの説明を収容することができ、ログへの印刷のように、デバッグのためにのみ用いられる。<errordef>エレメントの形式は、次の通りである。

［表１７］
<errordef name="some.error.name" invokes="erroHandling.xsa"/>

パイプライン実行中のいつでも、XPath条件をチェックすることができる。XPath条件が真（XPath仕様によって定義されているように）となった場合、エラー定義を探索して、最も近い一致を求める。

照合機構は、ドットによって、エラー名称をトークン化する。例えば、エラーsomething.errorspecifcをsomething、errorおよびspecificにトークン化する。最も一致度が高く同じ順序のトークンを含むエラー定義を用いる。この同じ例では、エラー定義がerrors something.bogus、something.errorおよびsomething.error.morespecificに対して存在する場合、something.errorエラー定義から引用したＸＳＡ定義を呼び出す。何故なら、something.error.morespecificは一致でないからである。
<raiseerror>エレメントの形式は、次の通りである。

［表１８］
<raiseerror test="/some/xpath/to/test" error ="some.error.name"/>

与えられたＸＰａｔｈは、フォーマット$scope:variable-nameを用いて、ＸＰａｔｈパラメータ全体を通じて全てのスコープ変数(scoped variable)にアクセスできなければならない。

一実現例では、それ自体のエラー名称を自由に定義でき、ＸＳＡ定義はＸＳＡエンジンにおいて実行エラーを扱うことが可能となる。一例は、数個のリソースが失われて、エラーが発生する可能性があり、ＸＳＡ定義がその場合に何をすべきか定義できるという場合であろう。この実現例は、エラー・コードを公表しなければならず、エラーを保存(reserve)しなくてもよい。即ち、ＸＳＡ定義では全てのエラーを無視することができる。

また、エラーの原因となったＸＳＡ定義に用いられていたのと同じＸＳＡコンテンツを用いてエラー・ハンドリングＸＳＡ定義を実行しなければならない実現例もある。
以下に、本発明の実施形態Ａの仕様によるカスタム動作について説明する。

<operation>エレメントは、カスタムＸＭＬ動作を参照する際に用いることができる。定義されている唯一の構成は、ParseClass属性であり、用いるパーザに名称を付けてカスタムＸＭＬ動作の内容を解析する際に用いなければならない。この名称をパーザの実現例にマップする方法、およびパーザが実現しなければならないプログラミング・レベルのインターフェースは、各ＸＳＡ実現例に特定的である。

<operation>エレメントの内容は、用いられるパーザが利用できなければならず、パーザはこれを用いて動作を定義することができる。エレメントの内容は、ＸＳＡ名称空間とは別個の名称空間に入力し、現在および今後起こり得る競合を回避するようにするとよい。

以下に、本発明の実施形態Ａの仕様によるＸＳＡ実行について説明する。
ＸＳＡ実行エンジンは、１つのＸＳＡコンテキスト内において常にＸＳＡ定義を実行していなければならない。ＸＳＡコンテンツを作成しＸＳＡを実行する全体を、アダプタと呼ぶ。アダプタの一例は、ＨＴＴＰアダプタであり、ＨＴＴＰ要求を取り込み、ＸＳＡ定義を選択し、ＨＴＴＰ要求内にある情報に基づいてそのコンテキストを作成し、次いでＸＳＡ定義を実行する。

アダプタの名称には規則や登録は要求されない。これは、各ＸＳＡの実現例に特定的と考えられる。しかし、実現例は、アダプタ名称を定義できるので、ＸＳＡ定義は、アダプタが有意にＸＳＡを実行することができる情報を埋め込むことができる。１つの属性adapternameを有する<supports>エレメントを用いると、これが行える。いずれのＸＭＬ動作の前でも、ＸＳＡ定義の開始には、あらゆる数の<supports>エレメントを置くことができる。<supports>エレメントが出てこない場合、ＸＳＡ実現例は、いずれのアダプタでもＸＳＡを呼び出すことができると想定しなければならない。

<supports>リストの一例を提示し、以下に示す。この例は、ＸＳＡ定義がアダプタＨＴＴＰおよびＦＴＰにおいてのみ実行してもよいことを示す。FILEという名称のアダプタは、ＸＳＡ実現例によって、このＸＳＡを実行することを禁止しなければならない。

［表１９］
<xsa>
<supports adaptername="HTTP"/>
<supports adaptername="FTP"/>
...
</xsa>

前述の実施形態Ａの詳細な説明を用いれば、当業者であれば、Ｊａｖａプログラミング言語のような、プログラミング言語への結合を形成することができる。本発明の実施形態Ａによって定義した詳細なＸＳＡ仕様に基づいた、有効なＸＭＬサービス・アクション文書の一例を以下に示す。これは、実施形態Ａによって定義したＸＳＡ仕様の特徴全てを示す訳ではない。

［表２０］
<?xml version='1.0'?>
<!DOCTYPE xsa
PUBLIC "-//Dimon//DTD XSA 1.1//EN"
"http://www.dimon.is/dtds/xsa/1.1/xsa.dtd">
<xsa version="1.1" xmlns="http://www.dimon.is/namespaces/xsa">
<supports adaptername="HTTP"/>
<if>
<isdefined>
<getvariable scope="request" name="http.get.param"/>
</isdefined>
<then>
<pipeline>
<generator refid="index"/>
<transformer refid="resourcetrax">
<in-param name="xsl">
<literal>index.xsl</literal>
</in-param>
</transformer>
<sink refid="clipsersink">
<in-param name="outStream">
<getvariable scope="request" name="http.responsetream"/>
</in-param>
</sink>
</pipeline>
</then>
<else>
<pipeline>
<generator refid="alt"/>
<transformer refid="alttrax">
<in-param name="xsl">
<literal>alt.xsl</literal>
</in-param>
</transformer>
<sink refid="clipsersink">
<in-param name="outputStream">
<getvariable scope="request" name="http.responsestream"/>
</in-param>
</sink>
</pipeline>
</else>
</if>
<xsa>

これで、本発明の実施形態Ａによって定義された、特殊目的プログラミング言語の詳細なＸＳＡ仕様の説明を終了する。

以上、本発明について、例示の実施形態を有するものとして説明したが、この特許出願は、その一般的原理を用いてあらゆる変形、仕様、または改造をも包含することを意図している。更に、この特許出願は、これが属する技術分野内における公知のまたは慣習的な実施に該当するような、本開示からの逸脱も包含することを意図している。本発明の精神および範囲は、添付した特許請求の範囲の用語によってのみ限定されるものとする。

図１は、本発明に適した動作環境を提供する汎用システムの一例のブロック図である。 図２は、ＸＭＬ処理タスクの管理のために特定的に設計した、特殊目的プログラミング言語で書いたＸＭＬサービス・アクションによって制御される主な形式のモジュールを示すブロック図である。 図３は、特殊目的プログラミング言語で書かれた、ＸＭＬサービス・アクションによって規定されたＸＭＬ処理タスクの実行を示すブロック図である。 図４は、ＸＭＬサービス・アクションの実行のフローを示すフロー図である。 図５は、ＸＭＬサービス・アクション・モデルによって定義された生成器の役割および典型的な構造を示すブロック図である。 図６は、ＸＭＬサービス・アクション・モデルによって定義された変換器の役割を示すブロック図である。 図７は、ＸＭＬサービス・アクション・モデルによって定義されたシンクの役割を示すブロック図である。

Claims (25)

1. 構造化データのコンテキスト独立処理を含むタスクの実行のための管理システムであって、
   −外部クライアントから要求を受ける手段と、
   −コンテキスト独立エンジンと、
   −前記外部クライアントと前記コンテキスト独立エンジンとの間で通信を行い、前記コンテキスト独立エンジンを特定のアプリケーション・コンテキストに適応させる少なくとも１つのアダプタ・モジュールと、
   −コンピュータ・ネットワーク上に常駐する少なくとも１つのバック・エンド・システムに接続され、前記少なくとも１つのバック・エンド・システム・データを、更なる処理のために準備ができている構造化データとして公開するように構成された少なくとも１つの生成器モジュールと、
   −前記少なくとも１つの変換器に接続され、前記処理した構造化データを受け、該処理した構造化データに応じての解釈および反応と、前記アダプタ・モジュールを通じての前記要求元の外部クライアントへの前記処理した構造化データの返送と、の一方または双方を行うように構成された、少なくとも１つのシンク・モジュールと、
   を備えており、
   前記外部クライアントと前記コンテキスト独立エンジンとの間の通信は、あらゆる構造化データの処理を管理するために設計された、特殊目的プログラミング言語で書かれた電子文書に定義されている既定の１組の命令にしたがって、前記構造化データの処理を実行するため、少なくとも１つの生成器モジュールと少なくとも１つのシンク・モジュールとを選択する手段を備えている、管理システム。
2. 請求項１記載の管理システムにおいて、前記少なくとも１つの生成器モジュールに接続され、前記構造化データを前記少なくとも１つの生成器から受け取って、処理した構造化データに変換するように構成された、１つまたは数個の変換器モジュールを備えている、管理システム。
3. 請求項１記載の管理システムにおいて、前記コンテキスト独立エンジンは、前記特殊目的プログラミング言語で書かれた前記電子文書を読み取って解釈し、それによって前記管理システム内における実行を制御する、管理システム。
4. 請求項１から３のいずれかに記載の管理システムにおいて、前記構造化データの処理を、拡張可能マークアップ言語（ＸＭＬ）フォーマットで実行する、管理システム。
5. 請求項１から４のいずれかに記載の管理システムにおいて、前記アダプタ・モジュールは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）によって受けた要求を受け、該要求に応答可能である、管理システム。
6. 請求項１から５のいずれかに記載の管理システムにおいて、前記アダプタ・モジュールは、ショート・メッセージ・サービス（ＳＭＳ）によって受けた要求を受け、該要求に応答可能である、管理システム。
7. 請求項１から６のいずれかに記載の管理システムにおいて、前記アダプタ・モジュールは、マルチメディア・メッセージ・サービス（ＭＭＳ）によって受けた要求を受け、該要求に応答可能である、管理システム。
8. 請求項１から７のいずれかに記載の管理システムにおいて、前記アダプタ・モジュールは、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）によって受けた要求を受け、該要求に応答可能である、管理システム。
9. 請求項１から８のいずれかに記載の管理システムにおいて、前記変換器モジュールは、拡張可能スタイルシート言語変換（ＸＳＬＴ：Stylesheet Language Transformations）を用いてＸＭＬデータを変換可能である、管理システム。
10. 請求項１から９のいずれかに記載の管理システムにおいて、前記少なくとも１つの生成器モジュールは、以下のバック・エンド・システム
    −あらゆるＯＤＢＣまたはＪＤＢＣ準拠データベース、
    −前記管理システムを実行中のコンピュータ上のファイル・システム、
    −ハイパーテキスト転送プロトコル（ＨＴＴＰ）を用いて通信可能なあらゆるデータ源、
    −シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）を用いて通信可能なあらゆるデータ源、
    −マイクロソフトＥｘｃｈａｎｇｅＴＭ個人情報管理（ＰＩＭ）システム、
    −ロータスＤｏｍｉｎｏＴＭ個人情報管理（ＰＩＭ）システム、
    −軽量ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）によるあらゆるディレクトリ・サービス、
    −シンプル・メール転送プロトコル（ＳＭＴＰ）、ポスト・オフィス・プロトコル（ＰＯＰ／ＰＯＰ３）またはインターネット・メッセージ・アクセス・プロトコル（ＩＭＡＰ）によるあらゆる電子メール・システム、
    の少なくとも１つと通信し、それらのネーティブ・データ・フォーマットをＸＭＬフォーマットに変換するように構成されている、管理システム。
11. 請求項１から１０のいずれかに記載の管理システムにおいて、該システムはプレゼンテーション・システムであり、
    −少なくとも１つのネットワーク・クライアントから、バック・エンド・システム内に常駐するコンテンツに対する要求を受ける少なくとも１つのアダプタ・モジュールと、
    −少なくとも１つのステップで、ＸＭＬソース・コンテンツを、前記少なくとも１つのクライアントに適したマークアップに変換する変換器モジュールであって、
    −前記ＸＭＬソース・コンテンツをクライアントには独立したマークアップに変換し、
    −前記クライアント独立マークアップを、前記コンテンツを要求した特定のタイプのクライアントに適したバージョンに適応させること、
    を含む前記の変換器モジュールと、
    −前記マークアップを前記クライアントに配信するシンク・モジュールと、
    を備えている、管理システム。
12. 請求項１から１１のいずれかに記載の管理システムにおいて、前記少なくとも１つのクライアントからの要求のフォーマットは、以下のフォーマット
    −移植可能文書フォーマット（ＰＤＦ）、
    −クライアント特定ハイパーテキスト・マークアップ言語（ＨＴＭＬ）、
    −クライアント特定ワイヤレス・マークアップ言語（ＷＭＬ）、
    −ショート・メッセージ・サービス（ＳＭＳ）、
    −マルチメディア・メッセージ・サービス（ＭＭＳ）、および
    −コンパクトＨＴＭＬ（ｃＨＴＭＬ）、
    −ｘＨＴＭＬ、
    の内の１つである、管理システム。
13. 請求項１から１２のいずれかに記載の管理システムにおいて、該システムはメッセージング・システムであり、
    −標準化電子業務プロトコルを通じて外部システムと通信するように構成された少なくとも１つのアダプタ・モジュールと、
    −発信元および宛先システムから業務データを抽出し、それをＸＭＬとして公開するように構成された少なくとも１つの生成器モジュールと、
    −関連するＸＭＬ業務ソース・データを業務メッセージに変換するように構成された少なくとも１つの変換器モジュールと、
    −前記業務メッセージを配信するように構成された少なくとも１つのシンク・モジュールと、
    を備えている、管理システム。
14. 請求項１から１３のいずれかに記載の管理システムにおいて、前記標準化業務プロトコルは、電子業務ＸＭＬ（ｅｂＸＭＬ）である、管理システム。
15. 請求項１から１４のいずれかに記載の管理システムにおいて、該システムは統合システムであり、
    −外部クライアントからの呼び出しなしで、ＸＭＬ処理タスクの実行を開始する手段と、
    −異種の発信元および宛先システム間でのデータ同期手段であって、
    ・少なくとも１つの生成器モジュールが前記発信元システムからデータを抽出し、それをＸＭＬソース・データに変換し、
    ・少なくとも１つの変換器モジュールが、前記ＸＭＬソース・データを、前記宛先システムへの配信に適合するＸＭＬフォーマットに変換し、
    ・少なくと１つのシンク・モジュールが、前記処理したＸＭＬを前記宛先システムに配信する手段を有する、
    前記のデータ同期手段と、
    −業務プロセス管理および実行のための手段であって、業務プロセスの個々の各タスクを定義し、単一のＸＭＬ処理タスクとして実行する、手段と、
    −実行中の業務プロセスのステータスに関する情報と共に、ハイパーテキスト・ファイル集合をワールド・ワイド・ウェブ上に公表する手段と、
    を備えている、管理システム。
16. 請求項１から１５のいずれかに記載の管理システムにおいて、前記外部クライアントからの要求は情報またはデータを収容し、これを前記アダプタ・モジュールが使用して、どの電子文書を実行するか判断する、管理システム。
17. 複数のネットワーク・デバイスを備えたネットワークにおいて、構造化データ処理タスクを管理し実行する方法であって、
    −外部クライアントから、命令集合によって定義された、既定のコンテキスト依存構造化データ処理タスクの実行要求を受けるステップであって、前記構造化データ処理タスクの各々を、あらゆる構造化データの処理の管理用に設計した特殊目的上位プログラミング言語を用いて、命令集合にエンコードするステップと、
    −前記命令集合を解釈して有効性を判断し、前記命令集合と、前記外部クライアントからの要求において発見した情報とに基づいて、コンテキスト依存実行環境を設定するステップと、
    −前記コンテキスト依存構造化データ処理タスクを実行するステップであって、該実行が、
    ・前記ネットワーク上のバック・エンド・システムに接続し、ネーティブ・バック・エンド・システム・データを構造化ソース・データに変換するステップと、オプションとして、
    ・前記ソース構造化データを、処理した構造化データに変換するステップと、
    ・前記処理した構造化データへの反応と、何らかの方法での前記要求元クライアントへの前記処理した構造化データの返送と、の一方または双方を行うステップと、
    を含む、ステップと、
    を備えている、方法。
18. 請求項１７記載の方法において、前記構造化データの処理は、拡張可能マークアップ言語（ＸＭＬ）フォーマットで実行する、方法。
19. 請求項１７または１８記載の方法において、前記要求は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）によって受信する、方法。
20. 請求項１７から１９までのいずれかに記載の方法において、前記要求は、ショート・メッセージ・サービス（ＳＭＳ）によって受ける、方法。
21. 請求項１７から２０までのいずれかに記載の方法において、前記要求は、マルチメディア・メッセージ・サービス（ＭＭＳ）によって受ける、方法。
22. 請求項１７から２１までのいずれかに記載の方法において、前記要求は、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）によって受ける、方法。
23. 請求項１７から２２までのいずれかに記載の方法において、前記ＸＭＬデータは、拡張可能スタイルシート言語変換（ＸＳＬＴ）を使用して変換する、方法。
24. 請求項１７から２３までのいずれかに記載の方法において、前記ソース構造化データを、処理した構造化データに変換することは、以下のバック・エンド・システム
    −ＯＤＢＣまたはＪＤＢＣ準拠データベース、
    −前記管理システムを実行中のコンピュータ上のファイル・システム、
    −ハイパーテキスト転送プロトコル（ＨＴＴＰ）を通して通信可能なあらゆるデータ源、
    −シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）を通して通信可能なあらゆるデータ源、
    −マイクロソフトＥｘｃｈａｎｇｅＴＭ個人情報管理（ＰＩＭ）システム、
    −ロータスＤｏｍｉｎｏＴＭ個人情報管理（ＰＩＭ）システム、
    −軽量ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）によるあらゆるディレクトリ・サービス、
    −シンプル・メール転送プロトコル（ＳＭＴＰ）、ポスト・オフィス・プロトコル（ＰＯＰ／ＰＯＰ３）またはインターネット・メッセージ・アクセス・プロトコル（ＩＭＡＰ）によるあらゆる電子メール・システム、
    の内少なくとも１つに対応するフォーマットから、ＸＭＬフォーマットへの変換を含む、方法。
25. 請求項１７から２４までのいずれかに記載の方法を、中央演算装置に実行させる命令を格納したコンピュータ読み取り可能媒体。

Images