(57)【要約】無線電話、パーソナルデジタルアシスタント（ＰＤＡ）、スマートリモートコントロール、又は、他のインターネット利用可能な処理装置は、Ｗ３Ｃ勧告ＸＦｏｒｍｓ標準の指定されたサブセットをサポートするスケーラブル電子フォーム処理エンジンを含む。前記指定されたサブセットは、所定の装置に関して、該装置の計算及びメモリ容量に基づいて選択されてもよい。有利には、本発明は、“薄い”装置が、電子フォームを、完全なＷ３Ｃ勧告ＸＦｏｒｍｓ標準の実装を必要とすることなく処理することを可能にする。
2005530269.tif 000002
【特許請求の範囲】
【請求項１】
制限された処理及びメモリ容量を有する装置において情報を処理する方法において、
拡張可能マークアップ言語（ＸＭＬ）ドキュメントを、完全なＸＦｏｒｍｓ仕様の指定されたサブセットを基礎とするＸＦｏｒｍｓエンジンを使用して処理するステップと、
前記処理するステップの結果を使用し、有効なＸＦｏｒｍｓ実例ドキュメントを形成するステップとを含むことを特徴とする方法。
【請求項２】
請求項１に記載の方法において、前記処理するステップは、前記ＸＦｏｒｍｓ実例ドキュメントを表示するステップと、書き込むステップと、有効にするステップと、提出するステップとを含むことを特徴とする方法。
【請求項３】
請求項２に記載の方法において、前記表示するステップは、前記装置に対応するユーザインタフェースコンポーネントを表示するステップを含み、前記表示されたコンポーネントは、前記実例ドキュメントに含まれる下にあるデータから分離されていることを特徴とする方法。
【請求項４】
請求項３に記載の方法において、前記ユーザインタフェースコンポーネントは、ＷＭＬユーザインタフェース、ＨＴＭＬインタフェース、音声認識をサポートするユーザインタフェース、及び、手書き認識をサポートするユーザインタフェースのうち１つであることを特徴とする方法。
【請求項５】
請求項１に記載の方法において、前記ＸＦｏｒｍｓエンジンは、完全なＸＦｏｒｍｓ
仕様の複数の異なったサブセットを、前記装置のメモリ及び処理容量の関数として実装するのに適したスケーラブルエンジンであることを特徴とする方法。
【請求項６】
請求項１に記載の方法において、前記装置は、無線電話機、パーソナルデジタルアシスタント、リモートコントロール装置、セットトップボックス、及び、ゲームコンソールから成るグループから選択されることを特徴とする方法。
【請求項７】
請求項１に記載の方法において、前記ＸＦｏｒｍｓエンジンは、勧告されたＸＰａｔｈ標準において規定されたルールの第１サブセットと、勧告されたスキーマ標準において規定されたルールの第２サブセットと、勧告されたＸＭＬ標準において規定されたルールの第３サブセットとのグループから選択された少なくとも１つから構成されることを特徴とする方法。
【請求項８】
請求項７に記載の方法において、前記ルールの第３サブセットは、以下の要素、
[1]document ::= element*
[2]element  ::= STag content ETag
[3]Stag     ::= '<'QName(Attribute)+'>'
[4]ETag     ::= '</'QName'>'
[5]content  ::= element*|Char*
[6]Attribute::= Name'=''"'Char*'"'
[7]Name     ::= NameChar*
[8]NameChar ::= Letter|Digit|'.'|'-'|'_'|':'
[9]Letter   ::= [A-Z]|[a-z]
[10]Digit   ::= '0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'|'8'|'9'
[11]Char    ::= 
Letter|Digit|'!'|'#'|'$'|'%'|'('|')'|'*'|'+'|','|'-'|'.'|'/'|':'|';'|'='|'?'|'@'|'['|'＼'|']'|'^'|'_'|'`'|'{'|'}'|'~'
[12]Qname   ::= (Name':')?Name
のうちの１つ又はそれ以上を含むことを特徴とする方法。
【請求項９】
請求項７に記載の方法において、前記ルールの第１サブセットは、以下の要素、
[1]Selector    ::= Path('|'Path)*
[2]Path        ::= '|'(Step('/'|'//'))*(Step(Number)?|'@'NameTest)
[3]Step        ::= '.'|(NameTest|'child::'NameTest)('['Digits']')?
[4]NameTest    ::= QName|'*'|NCName':''*'
[5]QName       ::= (NCName':')?NCName
[6]NCName      ::= (Letter|'_')Char
[7]Digits      ::= [0-9]+
[8]Letter      ::= [A-Z][a-z]
[9]Char        ::= 
Letter|Digit|'!'|'#'|'$'|'%'|'('|')'|'*'|'+'|','|'-'|'.'|'/'|':'|';'|'='|'?'|'@'|'['|'＼'|']'|'^'|'_'|'`'|'{'|'}'|'~'
のうちの１つ又はそれ以上を含むことを特徴とする方法。
【請求項１０】
拡張可能マークアップ言語におけるドキュメントを処理する装置において、該装置は、
完全なＸＦｏｒｍｓ仕様のサブセットの指定されたサブセットを基礎として前記ドキュメントを処理するように動作可能なＸＦｏｒｍｓエンジンを具え、
前記ＸＦｏｒｍｓエンジンによる処理の結果が使用され、有効なＸＦｏｒｍｓ実例ドキュメントを出力することを特徴とする装置。
【請求項１１】
請求項１０に記載の装置において、前記ＸＦｏｒｍｓエンジンは、縮小ＸＰａｔｈコンポーネント、軽量スキーマコンポーネント、及び、ＸＭＬパーサコンポーネントを具えることを特徴とする装置。
【請求項１２】
拡張可能マークアップ言語（ＸＭＬ）におけるドキュメントを処理する１つ又はそれ以上のソフトウェアプログラムを含む機械読み取り可能記憶媒体を具える製品において、該製品は、ＸＭＬ標準の完全なセットの指定されたサブセットをサポートするように構成された薄い処理装置における使用に適し、前記１つ又はそれ以上のソフトウェアプログラムは、実行されるとき、
拡張可能マークアップ言語（ＸＭＬ）ドキュメントを、完全なＸＦｏｒｍｓ仕様の指定されたサブセットを基礎とするＸＦｏｒｍｓエンジンを使用して処理し、
前記処理の結果を使用し、完全なＸＦｏｒｍｓ実例ドキュメントを形成することを特徴とする製品。
【請求項１３】
制限された処理及びメモリ容量を有する装置において情報を処理するシステムにおいて、該システムは、
ａ）拡張可能ベースマークアップ言語（ＸＭＬ）ベースのドキュメントを前記装置に与える少なくとも１つの送信元装置と、
ｂ）前記受信されたＸＭＬベースドキュメントを処理するように構成され、完全なＸＦｏｒｍｓ仕様の指定されたサブセットを基礎とするＸＦｏｒｍｓエンジンを含む処理装置とから成ることを特徴とするシステム。
【請求項１４】
請求項１３に記載のシステムにおいて、前記ＸＦｏｒｍｓエンジンは、ＸＰａｔｈソフトウェアコンポーネントと、軽量スキーマソフトウェアコンポーネントと、縮小ＸＭＬパーサコンポーネントとから成ることを特徴とするシステム。
【請求項１５】
請求項１３に記載のシステムは、さらに、ユーザインタフェースソフトウェアコンポーネントから成ることを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、データ処理に関する。特に、本発明は、インターネットのようなコンピュータネットワーク上で電子フォームを処理するＸＭＬベーススケーラブルフォームに関する。
【背景技術】
【０００２】
１枚の紙であろうとウェブページであろうと、フォームは、データの構造化された交換を表わす。インターネットの文脈において、フォームは、単に、ユーザがウェブサーバと相互作用できるようにする方法である。使用するフォームを選択するには多くの理由が存在する。最も簡単なフォームは、しばしば、ユーザからのフィードバックを求めるように形成される。より複雑なフォームは、ユーザが彼らの銀行口座残高をチェックし、航空券を購入し、彼らの電子メールをチェックすることを可能にする。ウェブにおいて、フォームは、探索エンジン、投票、調査、電子商取引、及び、オンラインアプリケーションに関してさえ普通になった。
【０００３】
現在、拡張可能ハイパーテキストマークアップ言語（ＸＨＴＭＬ）ベースのフォームは、ユーザの入力を取得するのに使用される。ＸＨＴＭＬフォームにより、ユーザはウェブページを訪れ、ウェブページに情報を追加し、ウェブページをウェブサーバに提出することができる。電子商取引から取ったきわめて一般的な一例は、買い物リストからアイテムを注文するためにユーザがＸＨＴＭＬフォームに書き込む場合である。
【０００４】
図１は、顧客データをサーバに送ることを可能にする典型的なＸＨＴＭＬフォームに関するＸＨＴＭＬコードを例示する。入力要素１０−１２は、ユーザからテキスト形式におけるデータを収集する。前記データは、フォーム要素（図示せず）によって、処理すべきユニフォームリソースローケイタ（ＵＲＬ）に渡されるように命令される。前記ＵＲＬは、前記データを処理する準備ができているサーバアプリケーションを指示する。図１に示されるようなウェブ上でアイテムを注文するのにＸＨＴＭＬフォームを使用することの欠点の１つは、ますます複雑な処理が、ＸＨＴＭＬフォームの制限を超えはじめていることである。電子商取引がウェブ上で成長するにつれ、データを交換するのにより複雑な方法を提供する必要がある。例えば、Ａ社はＢ社に購入注文を出したいと思うかもしれない。しかしながら、Ａ社はその交換にいくつかの条件をおきたいと思うかもしれない。共通語なしで、このプロセスは困難になり、複雑なプログラムを必要とする。データ交換の制限に加えて、今日のＸＨＴＭＬフォームに関する他の懸念が存在し、例えば、データをプレゼンテーションから分離できないことである。現在のフォーム制御は、プレゼンテーションを複雑なデータに緊密に結びつける。これは、図１におけるもののような簡単なフォームに関する重大問題を提起しないかもしれないが、複雑なフォームが大企業の電子商取引を営むのに必要な場合、負担になるかもしれない。
【０００５】
フォームは、多くのウェブサイトによってインタラクティブに使用される主要な手段を表わすウェブの重要な部分であり続けるため、ウェブアプリケーション及び電子商取引ソリューションは、より豊富な相互作用を備えたよりよいウェブフォームの需要の口火を切った。この懸念に取り組むために、ワールドワイドウェブコンソーシアム（Ｗ３Ｃ）は、ＸＦｏｒｍｓ１．０と呼ばれるウェブフォームの新たな３部分標準を導入し、これは、拡張可能マークアップ言語（ＸＭＬ）を基礎としている。ＸＦｏｒｍｓ１．０は、ＸＦｏｒｍｓプロセッサと遠隔エンティティとの間のオンライン相互作用に関する新たなプラットフォームに依存しないマークアップ言語の形成を可能にする。ＸＦｏｒｍｓは、ＸＨＴＭＬフォームに取って代わるものであり、長年にわたるＸＨＴＭＬフォームインプリメンテーション経験において学習された教訓から利益を得る。ＸＦｏｒｍｓにおける追加の詳細は、http://www.w3.org/MarkUp/Formsにおいて公開された“ＸＦｏｒｍｓ−次世代のウェブフォーム”（Ｗ３Ｃ  ５／１０／２００２）と、www.w3.org/TR/xformsにおいて公開された“ＸＦｏｒｍｓ１．０”（Ｗ３Ｃワーキングドラフト  ２００２年１月１８日）とにおいて見ることができ、これらは参照によってここに含まれる。ＸＦｏｒｍｓは、ウェブにおける次世代のフォームに相当する。ＸＦｏｒｍｓの主要な目的は、ユーザへのデータのプレゼンテーションからデータを分離し、ＸＨＴＭＬベースフォームの上述した欠点を克服することである。ＸＦｏｒｍｓは、データ及び論理からユーザインタフェースを分離することができ、論理的に、同じフォームを、コンピュータデスクトップ、パーソナルデジタルアシスタント（ＰＤＡ）又は携帯電話におけるユーザによって、彼らが十分なメモリ及び処理容量を有することを条件として、完成することを可能にする。
【０００６】
ＸＦｏｒｍｓは、より豊富でプレゼンテーションに依存しない、インタラクティブウェブ処理を扱う方法を提供する。従来のＸＨＴＭＬフォームを３つの部分、すなわち、データモデルと、実例データと、ユーザインタフェース（プレゼンテーション）とに分割することによって、ＸＦｏｒｍｓは、ＸＨＴＭＬベースフォームの上述した制限を、フォームのデータ及び論理をそのプレゼンテーションから分離することによって克服する。この方法において、フォームデータは、エンドユーザがアプリケーションとどのように相互作用するかに依存せずに規定される。これは、柔軟なプレゼンテーションオプションを可能にする。
【０００７】
図２は、ＸＦｏｒｍｓのプレゼンテーション態様の、データ及び論理からの分離を一般的に例示し、より特に、個々のモデル項目を規定する、ＸＦｏｒｍｓデータモデルと呼ばれる、単一の、装置に依存しないＸＭＬ不可視フォーム規定が、どのように、ＸＦｏｒｍｓユーザインタフェース２４、拡張可能ハイパーテキストマークアップ言語（ＸＨＴＭＬ）インタフェース２６、無線マークアップ言語（ＷＭＬ）インタフェース２７及び他の適当なインタフェース２８のような種々の標準又は適切なユーザインタフェースと動作できるかを例示する。
【０００８】
勧告されたＸＦｏｒｍｓ１．０を基礎とするＸＦｏｒｍｓエンジンは、ＸＭＬドキュメントの処理を容易にするのに貢献し、勧告されたＸＦｏｒｍｓ１．０との互換性に関して構成され、したがって、比較的大きいソフトウェアコンポーネントを必要とする。従来のＸＦｏｒｍｓエンジンのある欠点は、これらのサイズを仮定すると、これらは、特徴として制限された処理容量及びメモリを有する“薄い”装置との使用にあまり適していないことである。これのような薄い装置は、例えば、パーソナルデジタルアシスタント（ＰＤＡ）、携帯電話、セットトップボックス、又は、他のインターネット使用可能な“薄い”処理装置を含んでもよい。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
したがって、“薄い”装置との使用に適し、これらの装置の処理及びメモリ制限を克服する、Ｗ３Ｃ  ＸＦｏｒｍｓ１．０のサブセットを基礎とするＸＦｏｒｍｓエンジンに対する必要性が存在する。
【課題を解決するための手段】
【００１０】
本発明は、先行技術の上記で示した問題の１つ又はそれ以上を、“薄い”装置、すなわち、制限された処理及びメモリ制約条件を有する装置における使用に適したスケーラブルＸＦｏｒｍｓエンジンを提供することによって解決する。ここで、マイクロＸＦｏｒｍｓエンジンと呼ばれる前記スケーラブルＸＦｏｒｍｓエンジンは、ワールドワイドウェブコンソーシアム（Ｗ３Ｃ）ＸＦｏｒｍｓ１．０の指定されたサブセットを取り入れるという意味においてスケーラブルであり、前記指定されたサブセットは、前記薄い装置の処理及びメモリ制約条件に適切である。
【００１１】
本発明の一態様によれば、ＸＭＬベースの電子フォームは、制限された処理及び記憶容量を有するいわゆる“薄い”装置によって処理されるのに、前記薄い装置の制限されたメモリにおいて本発明のマイクロＸＦｏｒｍｓエンジンを組み込みことによって適するようになる。
【００１２】
本発明による電子フォームを処理する方法は、拡張可能マークアップ言語（ＸＭＬ）文書（すなわち、電子フォーム）を、完全なＸＦｏｒｍｓ１．０の指定されたサブセットを基礎とするＸＦｏｒｍｓエンジンを使用して処理するステップと、前記処理ステップの結果を使用し、有効なＸＦｏｒｍｓ実例ドキュメント（すなわち、有効にされ完成された電子フォーム）を出力するステップとを含む。
【００１３】
本発明を実現化するシステムは、１つ又はそれ以上の“薄い”装置と通信する少なくとも１つのウェブサーバ（例えば、ｅＭｅｒｃｈａｎｔ）を含み、前記薄い”装置は、メモリに前記マイクロＸＦｏｒｍｓエンジンを組み込み
、受信されたＸＭＬベースの電子フォームを処理する。
【００１４】
有利には、本発明は、特定の薄い装置のメモリ容量にスケールされた、勧告されたＸＦｏｒｍｓ１．０作業標準のサブセットを実装することによって、メモリ制限された“薄い”装置と、他の形式のメモリ制限されたインターネット利用可能な装置とが、ＸＭＬベースの電子フォームを処理することを可能にする。スケーラビリティは、前記薄い装置のメモリ及び他の制限に従い、前記薄い装置において、該薄い装置がＸＭＬベースの電子フォームを効率的な方法において処理するのに使用されることができるように実装される。本発明は、ＸＦｏｒｍｓ標準の将来のバージョンとの使用に適していることも期待される。
【発明の効果】
【００１５】
本発明のマイクロＸＦｏｒｍｓエンジンは、ＸＭＬベースである勧告されたＸＦｏｒｍｓ１．０のサブセットとして引き出されるため、ＸＭＬによって提供される能力からの利点を保持する。すなわち、前記マイクロＸＦｏｒｍｓエンジンは、電子フォーム発生のプレゼンテーション態様の、前記フォームのデータ及び論理からの分離を可能にし、したがって、データ独立を提供する。そういうものとして、前記マイクロＸＦｏｒｍｓエンジンは、データモデルがそのプレゼンテーションに束縛されないため、“薄い”装置を含む、多種多様のユーザプラットフォームにおける使用に適している。例えば、電子フォームは、ＰＣにおいて、ＨＴＭＬユーザインタフェースによって表示され、書き込まれることができ、同じフォームは、ＷＭＬユーザインタフェースを有する携帯電話、又は、音声認識又は手書き認識をサポートするインタフェースを含む薄い装置を含む、多種多様の“薄い”装置において与えられ、書き込まれることができる。どのプラットフォームが電子フォームの表示に使用されるかにかかわらず、前記マイクロＸＦｏｒｍｓエンジンは、装置独立性を提供し、これにより、下にあるＸＭＬアプリケーションが、用いられるユーザインタフェースにかかわらず、前記フォームからの有効な入力に依存することができることを確実にする。本質的に、本発明のマイクロＸＦｏｒｍｓエンジンは、下にあるＸＭＬベースのアプリケーションと、プレゼンテーション（すなわち、ユーザインタフェース）との間の分離を利用し、したがって、ＸＭＬベースのアプリケーションのサブセットを使用し、薄い装置がＸＭＬフォームを取り扱えるようにする。
【００１６】
本発明は、さらに、例として、添付した図面の参照と共に説明される。
【発明を実施するための最良の形態】
【００１７】
図３は、本発明のマイクロＸＦｏｒｍｓエンジンが実装されることができる処理装置３０の一例を示す。装置３０は、プロセッサ３２及びメモリ３４を含み、これらは、１つ又はそれ以上のシステムバスの組３５の少なくとも一部によって通信する。ディスプレイ３６及び１つ又はそれ以上の入力／出力（Ｉ／Ｏ）装置もシステムバスの組３５の少なくとも一部を使用する。処理装置３０は、インターネットプロトコル（ＩＰ）のような既知のネットワークを使用し、無線又は有線ネットワーク又はこれらの組み合わせ上の電子商取引活動を容易にするように構成された“薄い”装置を表してもよい。これらのような薄い装置は、例えば、無線電話、パーソナルデジタルアシスタント（ＰＤＡ）、ポータブルコンピュータ、スマートリモートコントロール、又は、他の形式の処理装置を含んでもよい。いわゆる薄い装置は、代表的に、制限された計算パワー及びメモリを有することを特徴とする。
【００１８】
装置３０の要素は、これらのような装置の慣例的な要素である。例えば、プロセッサ３２は、マイクロプロセッサ、中央処理ユニット（ＣＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、又は、用途特定集積回路（ＡＳＩＣ）、ならびに、これら及び他の処理装置の部分又は組み合わせを表してもよい。メモリ３４は、代表的に、電子メモリであるが、ディスクベースの光又は磁気メモリのような他の形式の記憶装置を具える又は含んでもよい。
【００１９】
ここで説明する本発明のマイクロＸＦｏｒｍｓエンジンは、全体又は一部において、装置３０の個々のメモリ３４及びプロセッサ３２要素を使用して記憶及び実行されるソフトウェアを使用して実装されてもよい。例えば、前記マイクロＸＦｏｒｍｓエンジンは、メモリ３４において記憶され、プロセッサ３２によって実行される１つ又はそれ以上のソフトウェアプログラムを使用して、少なくとも一部において実装されてもよい。これらのようなソフトウェアプログラムがメモリ３４及びプロセッサ３２のような装置要素において記憶及び実行されてもよい特定の方法は、当該技術分野においてよく理解され、したがって、ここに詳細には説明されない。
【００２０】
装置３０が、図示しない他の要素、又は、ここに説明するスケーラブルＸＦｏｒｍｓ処理機能を提供することができる要素の他の形式及び配置を含んでもよいことは、注意されるべきである。
【００２１】
図４は、本発明のマイクロＸＦｏｒｍｓエンジンが実装されることができるインターネットベースの通信システム４０の一例を示す。システム４０は、家庭４４における多数の装置とインターネット４２を経て通信するウェブサーバ４６を含む。ウェブサーバ４６は、電子商取引商人（イーマーチャント）と関係付けられてもよい。代表的に、電子商取引ウェブサーバ４６は、インターネットプロトコル（ＩＰ）のような既知の技術を使用し、ＸＭＬベースのドキュメント４９ａ−４９ｅをインターネット４２によって家庭４４における装置に伝送することにおける、ビジネス論理及び／又は座標処理をホストする。
【００２２】
この実施例における家庭４４における装置は、本発明のマイクロＸＦｏｒｍｓエンジン４５か、完全なＸＦｏｒｍｓ１．０を基礎とする先行技術のＸＦｏｒｍｓエンジン４７のいずれかを装備される。本発明の主要な目的によれば、マイクロＸＦｏｒｍｓエンジン４５は、制限された処理及び／又はメモリ容量を有する薄い装置における使用に関して構成される。より特には、家庭４４は、代表的に、以下の薄い装置、すなわち、テレビジョンセット４６−１、ビデオゲームコンソール４６−２、ＰＤＡ装置４６−３及びセットトップボックス４６−４を含んでもよく、これらの薄い装置は、個々のマイクロＸＦｏｒｍｓソフトウェアエンジン（ＸＭＬ  ＳＷ）４５−１ないし４５−５を装備される。家庭４４は、ホームネットワーク４６−８にインタフェースされるべきミュージカルジュークボックス４６−５、オーディオシステム４６−６及びＰＣ４６−７を含む非薄い装置も含んでもよい。前記非薄い装置の各々は、個々の完全なＸＦｏｒｍｓソフトウェアエンジン（ＸＭＬ  ＳＷ）４７−５ないし４７−７を装備される。さらに、１つ又はそれ以上の薄い装置４６−１ないし４６−４は、図３に示されるような方法において構成されてもよい。
【００２３】
インターネット４２によってウェブサーバ４６から家庭４４における装置に送られたＸＭＬドキュメント４９ａ−ｅは、対応するＸＦｏｒｍｓエンジン４５又は４７を使用して処理される。本発明のマイクロＸＦｏｒｍｓエンジン４５の１つの場合において、ＸＭＬドキュメント４９は、完全な勧告されたＸＦｏｒｍｓ１．０の指定されたサブセットを使用して、対応する薄い装置の計算及びメモリ容量と互換性のある方法において処理され、したがって、本発明のスケーラビリティ態様を与える
【００２４】
図４のシステム４０において示される要素の特定の配置及び構成は、単なる例としてである。他の字指令において、他の形式のウェブサーバ、ネットワーク及び装置が使用されてもよい。当業者は、特定の薄い装置に対してスケーラブルなマイクロＸＦｏｒｍｓエンジンは、これらのようなシステム要素のどんな特定の配置又は構成を必要としないことを認識するであろう。
【００２５】
図５ａは、完全なＸＭＬ１．０標準５１ａ、Ｎａｍｅｓｐａｃｅ標準５１ｂ、ＸＰａｔｈ１．０標準５１ｃ、Ｓｃｈｅｍａ１．０標準５１ｄ及び完全なＸＦｏｒｍｓ１．０  ５４ｅにおいて与えられる標準を含む標準を基礎とする多数のＸＭＬを含む慣例的なＸＦｏｒｍｓスタック５１を示す。既知であるように、このスタック構成は、他のスタック要素の上に現れるスタック要素は、下にあるスタック要素に部分において由来するというアイデアを説明的に伝える。
【００２６】
図５ｂは、図５ａのＸＭＬベース標準５１ａ−ｅに対応する多数の縮小ルールセットＸＭＬベース標準を含む縮小ＸＦｏｒｍｓスタック５３を示す。スタック５３において例示される各標準は、Ｎａｍｅｓｐａｓｅ標準５３ｂを例外として、図５ａの慣例的なＸＦｏｒｍｓスタック５１におけるその相当物の標準から得られたルールの指定されたサブセットを表す。縮小又はスケールダウンされた標準は、いわゆる薄い装置において使用される本発明のマイクロＸＦｏｒｍｓエンジンの拡張可能コードを開発するガイドラインとして使用される。
【００２７】
図５ａの慣例的な標準及び図５ｂの縮小標準は、後に説明される。以前注意されたように、図５ｂの縮小標準は、いわゆる“薄い”装置の特定の処理及び／又はメモリ制限に応じて、異なった実施例ごとに異なる。このように、マイクロＸＦｏｒｍｓエンジンは、前記装置の処理及びメモリ制限にしたがってスケーラブルである。
【００２８】
最初に図５ａのスタック５１を参照すると、完全なＸＭＬベース標準の組が示される。最も下のスタック層において開始すると、要素５１ａとしてラベル付けされた完全なＸＭＬ１．０標準が示される。ＸＭＬ１．０標準５１ａは、マークアップをドキュメントに追加する標準的な方法を規定する。完全ＸＭＬ１．０作業標準５１ａは、意味論もタグセットも規定せず、メタ言語（他のマークアップ言語を形成するのに使用される言語）を規定する。完全ＸＭＬ１．０標準５１ａは、タグ及びこれらの間の構造的関係を規定する施設を提供する。予め決められたタグセットが無いため、どんな予想された意味論もありえない。ＸＭＬドキュメントのすべての意味論は、これらを処理するアプリケーションによって規定されるか、スタイルシートによって規定される。完全ＸＭＬ１．０作業標準５１ａに関する追加の標準は、参照によってその全体によって含まれる、http://www.w3.org/TR/REC-xmlにおいて公表される“拡張可能マークアップ言語（ＸＭＬ）１．０（第２版）”においてみられる。
【００２９】
ここで、図５ｂを参照すると、縮小ＸＭＬ１．０標準５３ａとラベル付けされた、図５ａの完全ＸＭＬ１．０標準５１ａの相当物が示される。縮小ＸＭＬ１．０標準５３ａは、本発明によれば、完全ＸＭＬ１．０標準５１ａを規定する３９のルールの中から１１のルールを組み込む。これらのルールは、一実施例によれば、
[1]document ::= element*
[2]element  ::= STag content ETag
[3]Stag     ::= '<'QName(Attribute)+'>'
[4]ETag     ::= '</'QName'>'
[5]content  ::= element*|Char*
[6]Attribute::= Name'=''"'Char*'"'
[7]Name     ::= NameChar*
[8]NameChar ::= Letter|Digit|'.'|'-'|'_'|':'
[9]Letter   ::= [A-Z]|[a-z]
[10]Digit   ::= '0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'|'8'|'9'
[11]Char    ::= Letter|Digit|'!'|'#'|'$'|'%'|'('|')'|'*'|'+'|','|'-'|'.'|'/'|':'|';'|'='|'?'|'@'|'['|'＼'|']'|'^'|'_'|'`'|'{'|'}'|'~'
[12]Qname   ::= (Name':')?Name
を含む。
【００３０】
図５の縮小ＸＭＬ１．０標準５３ａを使用することは、必要でない解析、より小さいフットプリントの準備、ランタイム中のあまり必要でないメモリ、及び、エンティティ及びエンティティリファレンスの使用の回避を含む、完全ＸＭＬ１．０標準５１ａを使用することを上回る利点を提供する。
【００３１】
再び図５ａを参照すると、完全ＸＭＬネームスペース標準５１ｂが示される。ネームスペース標準５１ｂは、異なったマークアップ言語が、同じ名前を名づけられた要素及び属性を有する場合のＸＭＬにおける問題を解決するように形成された。可能性のある名前衝突の一例は、ドキュメントが本の部分を記述するのに“部分”要素を使用してもよく、他のＸＭＬドキュメントが車の部分を記述するのに“部分”要素を使用してもよい場合に生じるかもしれない。ＸＭＬネームスペース標準５１ｂは、この状況を、データモデルを拡張し、要素形式ネーム及び属性ネームがユニフォームリソース識別子（ＵＲＩ）によって制限されることができるようにし、したがって、両義性を除去することによって改善しようとする。ＵＲＩは、ローカルネームをグローバル識別子に与え、ウェブのような広範囲にわたる環境における混乱を除去する。ネームスペースにおける追加の詳細は、参照によってここに含まれる、http://www.w3.org/TR/REC-xml-namesにおいて公開される“ＸＭＬにおけるネームスペース）（Ｗ３Ｃ  １９９９年１月１４日）において見ることができる。完全なネームスペース標準５１ｂの非常に小さいフットプリントにより、本発明は、ネームスペース標準５１ｂをその全体において変更なしに組み込む（完全なネームスペース標準５３ｂを参照）。
【００３２】
再び図５ａを参照すると、完全なＸＰａｔｈ１．０標準５１ｃが示される。完全なＸＰａｔｈ１．０標準５１ｃは、ＸＭＬにおいてマークアップされた情報をある語彙から他の語彙に移す能力を可能にし与えるＸＳＬＴ及びＸＰｏｉｎｔｅｒの双方によって使用されるように設計されたＸＭＬドキュメントの部分をアドレスするＸＭＬパス言語を規定する。拡張可能ＸＰａｔｈ１．０標準５１ｃに関する追加の詳細は、その全体において参照によってここに含まれる、http://www.w3.org/TR/xpathにおいて公開される“ＸＭＬ  Ｐａｔｈ言語（ＸＰａｔｈ）バージョン１．０”（Ｗ３Ｃ勧告１９９９年１１月１６日）において見ることができる。
【００３３】
ここで図５ｂを参照すると、縮小ＸＰａｔｈ１．０標準５３ｃと呼ばれる、完全なＸＰａｔｈ１．０標準５１ｃの対応物が示される。完全なＸＰａｔｈ１．０標準５１ｃは、約３９のルールを含み、一実施例による縮小ＸＰａｔｈ１．０標準５３ｃは、完全なＸＰａｔｈ１．０標準５１ｃによって規定された完全なルールから得られたルールの以下のサブセットを組み込む。
[1]Selector    ::= Path('|'Path)*
[2]Path        ::= '|'(Step('/'|'//'))*(Step(Number)?|'@'NameTest)
[3]Step        ::= '.'|(NameTest|'child::'NameTest)('['Digits']')?
[4]NameTest    ::= QName|'*'|NCName':''*'
[5]QName       ::= (NCName':')?NCName
[6]NCName      ::= (Letter|'_')Char
[7]Digits      ::= [0-9]+
[8]Letter      ::= [A-Z][a-z]
[9]Char        ::= Letter|Digit|'!'|'#'|'$'|'%'|'('|')'|'*'|'+'|','|'-'|'.'|'/'|':'|';'|'='|'?'|'@'|'['|'＼'|']'|'^'|'_'|'`'|'{'|'}'|'~'
【００３４】
上記で規定されたルールサブセットは、一連のノードを単に見つけることを目標とする。ノードを見つけるために、以下の制限が化せられる、すなわち、（１）利用可能な軸は子供軸（child axis）のみである、（２）述語の数は０又は１のいずれかである、（３）述語が存在する場合、述語表現（すなわち、PredicateExpr）は、ノードがノーどっセット内で見つからなければならない位置を示す整数でなければならない、（４）ＸＰａｔｈ関数の不在（すなわち、数学的又はストリング操作が行われることができない）。
【００３５】
上記縮小ルールセットを組み込むことは、前記完全なルールセットを使用することを上回る利点を提供する。完全なＸＰａｔｈ１．０標準５１ｃにおける１３軸の代わりに子供軸、子孫軸及び属性軸のみを使用し、述語に関する表現又は関数の代わりに数字のみを使用することは、ＸＰａｔｈによって必要な能力のほとんどを保持しながら、ＸＰａｔｈソフトウェアフットプリントにおける大きな減少を導く。
【００３６】
再び図５ａを参照すれば、完全なＸＭＬスキーマ１．０  ５１ｄが示される。完全なＸＭＬスキーマ１．０は、２つの部分、すなわち、ＸＭＬスキーマパートＩ仕様及びＸＭＬスキーマパートＩＩ仕様を含む。ＸＭＬスキーマパートＩＩ仕様は、ＸＭＬスキーマ：データ形式と名づけられ、ＸＭＬスキーマならびに他のＸＭＬ仕様において使用されるべきデータ形式を規定する設備を規定する。
【００３７】
一般に、スキーマは、ＸＭＬドキュメントを正確さに関して有効になったマシンとなることを可能にする。すなわち、スキーマは、いったん構成されると、ＸＭＬアプリケーションがドキュメントを処理し、それが前記スキーマにおいてレイアウトされた制約の組を守るかどうかを決定する。したがって、スキーマに関する他の名前はデータモデルである。ＸＭＬスキーマは、形式規定及び要素宣言のような構成要素から成る。これらは、良好に形成された要素及び属性情報の有効性にアクセスするのに使用されることができ、さらに、これらの項目及びそれらの子孫への増加を指定することができる。完全なスキーマ１．０標準５１ｄに関する追加の詳細は、その全体において参照によってここに含まれる、http://www.w3.org/TR/xmlschema-2において公開される“ＸＭＬスキーマパート２：データ形式”（Ｗ３Ｃ勧告２００１年５月２日）において見ることができる。
【００３８】
ここで図５ｂを参照すると、縮小スキーマ１．０標準５３ｄとラベル付けされた、図５ａの完全なＸＭＬスキーマ１．０標準の対応物が示される。縮小スキーマ１．０標準５３ｄは、一実施例によれば、データ形式に関係付けられたＸＭＬスキーマパートＩＩ仕様のサブセットのみを含む。したがって、この実施例において、縮小スキーマ１．０標準５３ｄは、“整数”及び“ストリング”データ形式のみを組み込み、ＸＭＬドキュメント妥当性検証を行う。縮小スキーマ１．０標準５３ｄを使用する主な利点は、ずっとより小さいフットプリントを与えることである。この実施例において、縮小スキーマ１．０標準５３ｄにおいて含まれないデータ形式の標本は、double、float、duration、date、dateTime、time、gYearMonth、gYear、gMonth、Boolean、base65binary、hexBinary、QName、NOTATION及び任意のＵＲＩである。ある機能性は、データ形式の完全な範囲を含まないことによって犠牲になることは注意される。例えば、‘date’データ形式を組み込まないことは、領域における追加動作及び／又は減少動作を行う能力を不可能にする。しかしながら、注意されるように、フットプリントの賢明な縮小は、薄い装置が、十分な機能性を保持しながら、ＸＦｏｒｍｓをサポートすることを可能にする。再び図５ａを参照すると、スタックの上部において、完全なＸＦｏｒｍｓ１．０  ５１ｅが示される。示されたように、スタックの上部にあることによって、完全なＸＦｏｒｍｓ１．０  ５１ｅは、スタック５１において下にある標準の各々から部分において派生する。完全なＸＦｏｒｍｓ１．０  ５１ｅは、前記フォームが何を行うのかと、前記フォームをどのようにユーザに示すのかとを別々に記述する能力を与える。これは、柔軟なプレゼンテーションオプションに関して、古典的なＸＨＴＭＬフォーム制御並びにＷＭＬのような他のフォーム制御セットにてこ入れすることを可能にする。ＸＦｏｒｍｓは、ＸＦｏｒｍｓプロセッサとリモートエンティティとの間のオンライン相互作用に関する新たなプラットフォームに依存しないマークアップ言語の形成を可能にする。完全なＸＦｏｒｍｓ１．０  ５１ｅに関する追加の詳細は、上記で引用された２００２年１月１８日のＸＦｏｒｍｓ１．０ワーキングドラフトhttp://www.w3.org/TR/xformsにおいて見ることができる。ここで図５ｂを参照すると、縮小ＸＦｏｒｍｓ１．０  ５３ｅと呼ばれる、完全なＸＦｏｒｍｓ１．０  ５１ｅの対応物が示される。前記スタックの階層的構成によれば、縮小ＸＦｏｒｍｓ１．０  ５３ｅは、示された下にある標準の各々から部分において派生する。したがって、縮小ＸＦｏｒｍｓ１．０  ５３ｅは、上記実施例に関して説明したように、スタック５３において下にある縮小標準の制限を組み込む。下にある標準から組み込まれる制限に加えて、縮小ＸＦｏｒｍｓ１．０  ５３ｅは、完全なＸＦｏｒｍｓ１．０  ５１ｅからの縮小ルールセットとして得られる。前記縮小ルールセットは、静的制限、スキーマ制限、フォーム制御制限及び動作制限を含む制限された数の制限を含む。各々の制限形式は、以下のようにより詳細に説明される。
【００３９】
静的制限は、ＸＦｏｒｍｓのモデルを構成し、ＸＦｏｒｍｓの結果として生じる実例ドキュメントに課せられる制限を規定するように使用される。いくつかの静的制限の例は、type、required、minOccurs、maxOccurs、inValid、calculate、及びenumerationを含む。スキーマ制限は、前記縮小標準に組み込まれ、ＸＦｏｒｍｓモデル６５（図６）における要素の詳細を規定する。組み込まれるスキーマ制限の一例は、名前ストリングにおける文字数が１つより多くなければならない要求である。縮小ＸＦｏｒｍｓ１．０  ５３ｅ中に組み込まれた制限の第３の形式は、フォーム制御に関する。一実施例において、“入力”及び“出力”のみが、縮小ＸＦｏｒｍｓ１．０  ５３ｅ中に組み込まれる。前記縮小標準において、“入力”フォーム制御が含まれ、前記フォームのフィールドにおいてすでに書き込まれた情報が、アドレスフォームにおけるデフォルトカントリーフィールドに与えられる。縮小ＸＦｏｒｍｓ１．０  ５３ｅ中に組み込まれる最終的な制限形式は、動作に関係する。一実施例において、“submitInstance”が使用され、ＸＦｏｒｍｓのデータ実例（すなわち、ＸＦｏｒｍｓモデルの書き込まれたバージョン）が提出される。
【００４０】
縮小ＸＦｏｒｍｓ１．０  ５３ｅを使用することは、完全なＸＦｏｒｍｓ１．０  ５１ｅのより小さい実装で広い範囲のフォームをカバーする能力を有する利点を提供する。
【００４１】
電子フォームの処理
図６は、インターネットネットワーク情況において実装された本発明を示す。この例において、本発明のマイクロＸＦｏｒｍｓエンジン６１は、例えばＰＤＡ又は携帯電話であってもよい薄い装置６８のメモリに格納される。マイクロＸＦｏｒｍｓエンジン６１は、３つの構成ソフトウェアコンポーネント、縮小ＸＰａｔｈソフトウェアコンポーネント６１ａ、軽量スキーマソフトウェアコンポーネント６１ｂ及びＸＭＬパーサーソフトウェアコンポーネント６１ｃから形成されるように示されている。マイクロＸＦｏｒｍｓエンジン６１を形成するソフトウェアコンポーネント６１ａ−６１ｃの各々は、図５ｂのスタック５３において示される縮小標準の１つ又はそれ以上によって規定される制限されたルールセットにしたがう実行可能コードを表すことが注意される。
【００４２】
本発明のマイクロＸＦｏｒｍｓエンジン６１は、インターネットのようなネットワーク上で電子フォームを処理する薄い装置における使用に関して構成される。以下の説明は、薄い装置における本発明のマイクロＸＦｏｒｍｓエンジン６１を使用するインターネット上での電子フォームの処理において含まれるステップの説明的な例として与えられる。
【００４３】
続いて図６を参照すると、イーマーチャントと関係付けられてもよいウェブサーバ６２は、ＸＭＬベースの電子フォームＤＯＣ１  ６４をインターネット６３によってマイクロＸＦｏｒｍｓエンジン６１を含む薄い装置６８に送信する。薄い装置６８は、受信された電子フォームＤＯＣ１  ６４を４つの段階において処理する。電子フォームを処理するこれらの段階は、前記フォームをユーザに表示する段階と、前記表示されたフォームにユーザが書き込む段階と、前記書き込まれたフォームを有効にする段階と、前記フォームを送信元（すなわち、ウェブサーバ６２）に提出する段階とを含む。
【００４４】
電子フォームの表示
薄い装置６８におけるウェブサーバ６２からのＸＭＬドキュメントＤＯＣ１  ６４の受信に応じて、マイクロＸＦｏｒｍｓエンジン６１は、前記表示段階の第１部分においてＸＦｏｒｍｓモデル６５を作成することを課せられ、この段階の第２部分においてＸＦｏｒｍｓユーザインタフェース６６を表示する。マイクロＸＦｏｒｍｓエンジン６１は、任意のユーザインタフェース（ＵＩ）６６をＸＦｏｒｍｓモデル６５と動的に結合する汎用インタフェースを与える。マイクロＸＦｏｒｍｓエンジン６１は、ＸＭＬ技術を基礎としているため、フォーム（例えば、ＤＯＣ１  ６４）のデータ及び論理をそのプレゼンテーションから分離する。表示態様は、ユーザインタフェース６６によって制御され、データ及び論理は、ＸＦｏｒｍｓモデル６５によって制御される。この方法において、前記フォームは、エンドユーザがどのように前記フォームと相互作用するかに依存せずに規定されることができる。ユーザインタフェース６６は、薄い装置６８における軽量又は機能削除バージョンではないことが注意される。むしろ、ユーザインタフェース６６は、例えば、ＷＭＬインタフェース、音声活性化インタフェース、手書きインタフェース、手書き認識インタフェース、又はＨＴＭＬインタフェースを含む、当該技術分野において既知の、薄い装置用の多数のユーザインタフェースのうちの任意のものを表す。ＸＦｏｒｍｓは、プレゼンテーションを下にある前記フォームのデータ及び論理から分離するため、前記プレゼンテーションは、装置のＵＩが何であっても分かりやすい。このように、ユーザインタフェース６６によって制御される表示態様は、本発明に対して決定的ではなく、さらには考察されない。
【００４５】
ＸＦｏｒｍｓモデル６５は、２つのコンポーネント、データ構造コンポーネント６５ａ及びＸＦｏｒｍｓ拡張コンポーネント６５ｂを含む。データ構造コンポーネント６５ａは、本質的に、送信されたドキュメントＤＯＣ１  ６４の部分として含まれるデータから得られたデータモデルである。ＸＦｏｒｍｓ拡張コンポーネント６５ｂは、送信されたドキュメントＤＯＣ１  ６４の部分として含まれる他のデータから得られ、前記得られたデータモデルと関連して使用されるべき１つ又はそれ以上の制限及び／又はデータ依存性を含む。ＸＦｏｒｍｓモデル６５は、以下に説明されるように、マイクロＸＦｏｒｍｓエンジン６１によって、前記薄い装置（すなわち、クライアント）において与えられたデータ構成される。その後、構成されたデータ構造コンポーネント６５ａは、イーマーチャントと薄い装置との間で送信されるべきドキュメントのクラスに関する一組の制限又はルールであるスキーマに対して有効にされる。今説明されている実施例において、前記スキーマは、上記で考察されたようなＸＭＬスキーマパートＩＩ仕様のサブセットのみを含む縮小スキーマ１．０標準５３ｄである。ＸＭＬスキーマパートＩＩの前記サブセットは、ユーザが与えたデータ値が有効にされることができる様々なデータ形式である。構成されたデータ構成コンポーネントが前記スキーマに対していったん有効にされると、種々のデータ領域によって結合しなければならず、ユーザが与えた入力データから実例ドキュメント６７を構成する多数の制約を含むＸＦｏｒｍｓ拡張コンポーネント６５ｂと共にマイクロＸＦｏｒｍｓエンジン６１によって使用される。ＸＦｏｒｍｓ拡張コンポーネント６５ｂによって課せられることができる静的制限の一例は、“ジップコード”領域が５数字でなければならないことである。課せられることができる動的制限の一例は、患者が彼のジェンダーを男として指定する場合、彼は彼が妊娠していると示すことができないことである。実例ドキュメント６７は、後に説明されるように、これが送信元のサーバ（例えば、イーマーチャント）に提出されるより前に有効にされる。
【００４６】
図７は、マイクロＸＦｏｒｍｓエンジン６１のコンポーネントによって、ＸＦｏｒｍｓモデル６５を形成することに関係付けられたステップと、ＸＦｏｒｍｓ実例ドキュメント６７を形成することに関係付けられたステップとを例示する一般的な流れ図である。電子フォームを表示するプロセスは、 軽量ＳＡＸパーサ６１ｄによって理解されている受信されたＸＭＬドキュメントＤＯＣ１  ６４によって開始し、軽量ＳＡＸパーサ６１ｄは、ＸＭＬパーサ６１ｃのソフトウェアコンポーネントの１つであり、ＸＭＬパーサ６１ｃは、マイクロＸＦｏｒｍｓエンジン６１のソフトウェアコンポーネントである。“単純アプリケーションプログラミングインタフェース”又は“単純ＡＰＩ”を表わすＳＡＸは、イベントベースアーキテクチャによってＸＭＬドキュメントを理解するように設計された標準プログラミングインタフェースである。すなわち、ＳＡＸは、イベントコールバックインタフェースの１形式であり、これによって、アプリケーション開発者は、各々がＸＭＬドキュメント実例の理解中に生じるかもしれないイベントに対応する一組の“コールバック”方法又はルーチンを実装する。本質的に、ＳＡＸパーサは、ＸＭＬドキュメントにおける標準内容のすべてにおけるイベントをトリガするサポートを提供する。ＳＡＸパーサの機能は、ＸＭＬドキュメントにおいて読み、前記ＸＭＬドキュメントにおいて遭遇することに基づいてイベントをトリガすることであり、前記ドキュメントの内容においては動作しない。ＳＡＸイベントは、以下のＸＭＬドキュメント内容、すなわち、開又は閉要素タグ、ＰＣＤＡＴＡ及びＣＤＡＴＡセクション、処理命令、コメント及びエンティティ宣言に応じてトリガされる。
【００４７】
依然として図７を参照すると、軽量ＳＡＸパーサ６１ｄは、受信されたドキュメントＤＯＣ１  ６４（すなわち、電子フォーム）の理解からのＳＡＸイベント７２をトリガする。上記で一般的に説明されたように、軽量ＳＡＸパーサ６１ｄは、ＸＭＬドキュメント（例えば、ＤＯＣ１  ６４）をイベントベースで理解するインタフェースである。軽量ＳＡＸパーサ６１ｄは、図５ｂにおいて上述されたように、ネームスペース標準５３ｂの完全なルールセット及び縮小ＸＭＬ１．０標準５３ａの縮小ルールセットにしたがって構成されたソフトウェアモジュールである。ＳＡＸについてのより詳細な情報は、http://www.megginson.com/SAX/index.html及びこれに埋め込まれたリンクにおいて見ることができ、これらは参照によってここに含まれる。
【００４８】
ＸＭＬパーサ６１ｃにおいて組み込まれたイベントルータ７３（図６において分離して示していない）は、最初に、軽量ＳＡＸパーサ６１ｄによってトリガされたＳＡＸイベント７２を獲得する。イベントルータ７３の機能は、ＳＡＸイベント７２を軽量スキーマコンポーネント６１ｂ、軽量ＤＯＭ（ドキュメントオブジェクトモジュール）ハンドラ６１ｅ又は、ユーザインタフェース６６に、特定のＳＡＸイベントの内容に基づいて渡すことである。軽量スキーマコンポーネント６１ｂは、上述されたように、縮小スキーマ１．０標準５３ｄの縮小ルールセットにしたがって構成されたソフトウェアモジュールであることが注意される。さらに、軽量ＤＯＭハンドラ６１ｅは、ＸＦｏｒｍｓ実例ドキュメント６７の構築に責任を負うことも注意される。軽量ＤＯＭハンドラ６１ｅは、完全なネームスペース標準５３ｂを使用するが、実例ドキュメント６７は縮小ＸＭＬ１．０標準５３ａ及び縮小ＸＦｏｒｍｓ１．０  ５３ｅに基づくため、軽量ＤＯＭ６１ｅは、実例ドキュメント６７における各要素に関して格納される情報量を最小にする。
【００４９】
イベントルータ７３が、所定のＳＡＸイベントに対処する責任を負うエンティティを決定した後、前記イベントは適切なエンティティに渡される。ＸＦｏｒｍｓモデル６５は、軽量スキーマコンポーネント６１ｂに渡されたイベントに基づいて構築される。ＸＦｏｒｍｓ実例ドキュメント６７は、軽量ＤＯＭパーサ６１ｅに渡されたイベントに基づいて構築される。したがって、有効なＸＦｏｒｍｓドキュメントＤＯＣ１  ６４が入力として与えられた場合、前記表示ステップの終わりにおいて、ＸＦｏｒｍｓモデル６５は構成されているであろう。そうでなければ、例外がトリガされる。
【００５０】
イベントルータ７３は、また、プレゼンテーションに関して受信されたＳＡＸイベントをＵＩ６６に発送する。注意されたように、ＸＭＬベースフォームのプレゼンテーションデータは、該フォームのデータ及び論理から分離されるため、全体のプレゼンテーションは、薄い装置ＵＩ６６へ、該装置に適用可能な方法における処理及び表示のために発送される。
【００５１】
電子フォームへの書き込み
次の段階において、ユーザによって前記フォームに書き込む処理が行われる。ユーザが、表示されたＸＭＬドキュメントＤＯＣ１  ６４のＵＩ入力領域において書き込む場合、対応する要素の値も、ＸＦｏｒｍｓ実例ドキュメント６７において変化する。これは、ＸＰａｔｈ結合を経てＸＰａｔｈ表示にリンクされている各々のＵＩ入力領域の結果として生じる。ＸＰａｔｈは、ＸＭＬドキュメント（例えば、ＤＯＣ１  ６４）内のノードがどのようにアクセスされるかをアドレスする。一般に、“結合”は、実例データノードを、フォーム制御又はモデル項目制限に、ローケイタとしての結合表示を使用することによって接続する。
【００５２】
図８は、ＸＰａｔｈ結合が、どのように、ＵＩ入力領域をＸＰａｔｈ表示に結合することに関して実現されるかの説明的な一例である。この例示された例において、表示“Ｏｃｔａｖ”を含むテキストボックス８１は、ＸＰａｔｈ表示“/name/firstname”を使用して、ＸＦｏｒｍｓデータ実例８５における要素“ファーストネーム”８３に関係付けられる。ＸＰａｔｈは、ＵＩコンポーネント８１とＸＦｏｒｍｓデータ実例８５との間の結合言語である。
【００５３】
図５ｂに関して上述されたような、本発明のマイクロＸＦｏｒｍｓエンジン６１の縮小ＸＰａｔｈコンポーネント６１ａは、ＸＰａｔｈ結合動作を行い、ＸＭＬドキュメント内の対応するデータ実例ノードをフォーム制御と接続する。
【００５４】
電子フォームの有効化
フォームに書き込んでいる間の任意の時点において、有効化プロセスは開始されることができる。前記有効化プロセスは、ＸＦｏｒｍｓ実例ドキュメント６７において見つかった情報を、マイクロＸＦｏｒｍｓエンジン６１によって構成されたＸＦｏｒｍｓモデル６５に対してチェックすることからなる。
【００５５】
上記で考察されたように、メモリ制限により、軽量スキーマコンポーネント６１ｂにおけるＸＭＬスキーマパートＩＩ仕様のサブセットのみに関してサポートが与えられる。このように、マイクロＸＦｏｒｍｓエンジン６１は、ＸＦｏｒｍｓ実例ドキュメント６７の特定の要素の値が、指定されたデータ形式に関して有効であるかどうかのみをチェックする。ＸＦｏｒｍｓ実例ドキュメント６７が、以前に構成されたＸＦｏｒｍｓモデル６５に対して有効であるかどうかをチェックするために、以下のステップが続けられる。
ＤＯＭツリーをポストオーダにおいて通過する間、
前記要素がテキスト情報を含む場合、前記情報は正規化され、
１）該要素に関して、データ形式が指定されない場合、データ実例は無効である。
２）該要素に関して、データ形式が指定される場合、ＸＦｏｒｍｓ実例ドキュメントは、ＸＦｏｒｍｓモデルにおいて規定された形式制限に対してチェックされる。前記制限が満たされた場合、続く。そうでないならば、前記ＸＦｏｒｍｓ実例ドキュメントは無効である。
前記要素がどんな子供（ツリーにおけるリーフノード）も持たない場合、分類されなければならない。
分類されない場合、ＸＦｏｒｍｓ実例ドキュメントは無効である。
すべてのノードが通過されるか、えらーが生じなかった場合、ＸＦｏｒｍｓ実例ドキュメントは有効である。
【００５６】
ＸＦｏｒｍｓ実例ドキュメントをチェックするＸＦｏｒｍｓモデル５５を形成するのに、完全なＸＭＬスキーマパートＩＩ仕様のサブセットのみを与えることによって、無効ドキュメントを形成する機会が存在する。この望ましくない状況が生じる可能性は、しかしながら、ＸＭＬスキーマ仕様の制限されたサブセットのみを格納することによって薄い装置の処理及びメモリ制限に適合する能力によって相殺される。
【００５７】
提出
上記で考察されたように、ＸＦｏｒｍｓデータ実例６７は、提出の処理中にウェブサーバ６２に送り返される。どのような既知のデータ伝送プロトコルも、データ実例６７を提出するのに使用されることができる。例えば、ＨＴＴＰ及びＳＯＡＰ伝送プロトコルは、一緒に使用される。前記提出ステップは、マイクロＭＦｏｒｍｓエンジン６１の部分におけるどのような動作も含まず、さらに詳細には考察されない。
【００５８】
したがって、本発明のマイクロＭＦｏｒｍｓエンジン６１は、処理及びメモリ要求制限によって特徴付けられる薄い装置との使用に関してスケーラブルであることが示される。このように、マイクロＭＦｏｒｍｓエンジン６１は、例えば、パーソナルデジタルアシスタント（ＰＤＡ）、携帯電話、セットトップボックス、又は他のインターネット利用可能な“薄い”処理装置を含む広い範囲のプラットフォームにおける使用に適している。本発明の説明的な実施例は、ここで、添付した図面の参照と共に説明されたが、本発明は、これらの厳密な実施例に限定されず、むしろ、本発明の範囲は、添付した請求項の範囲によって規定されることが意図されることは、理解されるべきである。
【図面の簡単な説明】
【００５９】
【図１】顧客データを先行技術によるサーバに送ることを可能にするＸＨＴＭＬフォームを表示するＸＨＴＭＬコードを例示する。
【図２】先行技術の一実施例によるＸＭＬベース電子フォーム処理システムにおけるフォームのプレゼンテーションからの分離を例示する。
【図３】本発明のマイクロＸＦｏｒｍｓエンジンが実装されることができる処理装置の一例を示す。
【図４】本発明のマイクロＸＦｏｒｍｓエンジンが実装されることができるインターネットベース通信システムの一例を示す。
【図５】ａは、先行技術によって構成された、多数の完全なＸＭＬベース標準を含むＸＦｏｒｍｓスタックを示し、ｂは、本発明の原理によって構成された、多数の縮小ＸＭＬベース標準を含むＸＦｏｒｍｓスタックを示す。
【図６】インターネットワーク情況において実装された本発明のマイクロＸＦｏｒｍｓエンジンを例示する。
【図７】薄い装置における電子フォームの受信に応じたＸＦｏｒｍｓモデル形成に関係付けられたデータフローを例示するデータ流れ図である。
【図８】ＸＰａｔｈ結合が、どのようにＵＩ入力領域をＸＰａｔｈ拡張に結合する事に関して実現されるのかの説明的な例である。
【図１】
2005530269.tif 000003
【図２】
2005530269.tif 000004
【図３】
2005530269.tif 000005
【図４】
2005530269.tif 000006
2005530269.tif 000007
【図６】
2005530269.tif 000008
【図７】
2005530269.tif 000009
【図８】
2005530269.tif 000010
【国際調査報告】
2005530269.tif 000011