JPH11514769A

JPH11514769A - 埋め込み形ウェブサーバ

Info

Publication number: JPH11514769A
Application number: JP10508187A
Authority: JP
Inventors: アグラナット，イーアン・ディー; ジュースティ，ケネス・エイ; ローレンス，スコット・ディー
Original assignee: アグラナット・システムス・インコーポレーテッド
Priority date: 1996-08-08
Filing date: 1997-08-08
Publication date: 1999-12-14
Also published as: EP0853788A1; US5973696A; WO1998006033A1

Abstract

(57)【要約】埋め込み形グラフィカルユーザインターフェースは、ワールドワイドウェブ通信およびディスプレイ・パラダイムを用いる。開発環境は、ＨＴＭＬコンパイラを備え、コンパイラは、ＨＴＭＬに対する多数の固有の拡張を認識し処理する。ＨＴＭＬコンパイラは、グラフィカルユーザインターフェースが適用されるアプリケーションのソースコード言語で出力を発生する。対応のランタイム環境は、コンパイルしたＨＴＭＬドキュメントをブラウザにサーブするサーバを備える。

Description

【発明の詳細な説明】埋め込み形ウェブサーバ著作権通知本特許の開示に添付したテーブルは、著作権保護を受けるものである。著作権者は、特許・商標庁のファイルまたは記録に示される特許文献または特許開示の第三者によるファクシミリ複製には異議を唱えないが、それ以外の場合は著作権によるあらゆる保護を留保するものである。テーブルテーブルＡは、Ａgranat Ｓystems，Ｉnc.のＥmＷeb^TM製品の機能的仕様であり、テーブルＢは、このＥmＷeb^TM製品が使用するコンテンツのアーカイブを表すデータ構造を定義するヘッダファイルのＣプログラミング言語におけるソースコードリストである。上記テーブルは、以下に詳述するフィーチャを組み込んだ本発明の特定の実施例の１例を示すために提供する。関連出願に対する相互参照米国特許法第35条119条(e)により主張する優先権は、現在係属中の、“ＥＸＴＥＮＤＥＤＬＡＮＧＵＡＧＥＣＯＭＰＩＬＥＲＡＮＤＲＵＮＴＩＭＥＳＥＲＶＥＲ”と題し、1996年８月８日に出願した、本発明者の仮米国特許出願番号 08/023,373に基づく。この本発明者の仮米国特許出願は、言及により本開示に含めるものとする。１．発明の分野本発明は、グラフィカルユーザインターフェース、即ち、情報をテキスト形態およびグラフィカル形態の両方で提示することができるユーザインターフェースに関する。さらに詳細には、本発明は、ソフトウェアおよびハードウェアのアプリケーション、デバイスおよびワールドワイドウェブ・クライアント／サーバ通信モデルを使用する機器を制御、管理、コンフィギュレーション、診断およびモニタするのに使用するＧＵＩに関する。さらに、詳細には、本発明は、ワールドワイドウェブ・クライアント／サーバ通信モデルに基づいてそのようなＧＵＩを開発し使用するための改良した方法および装置に関する。２．関連技術多くの近代の通信、娯楽、その他の電子デバイスは、ローカルまたはリモートの制御、管理、コンフィギュレーション、モニタおよび診断の改良を要求し、またそれから利益を受けることができた。そのようなデバイスについて、特にデバイスに対し書かかれたソフトウェア・アプリケーションプラグラムにより制御されるのが普通である。このようなデバイスの設計は、任意のハードウェアと、このアプリケーションをサポートするのに必要な動作環境ソフトウェアとを含んでおり、そしてそのアプリケーションは、そのときには、デバイス内に埋め込まれるため、埋め込み形アプリケーションと呼ばれている。埋め込み形アプリケーションプログラムは、一般には、ここではネイティブ・アプリケーションプログラム言語と呼ぶＣ，Ｃ＋＋等の高級プログラム言語で書かれている。また、特定の用途に適したその他の言語も、用いることができる。アプリケーションプログラムは、ユーザとは、一般にはこのアプリケーションと同じ高級言語で書かれたユーザインターフェースを介して通信する。ネイティブ・アプリケーションプログラム言語におけるアプリケーションの表現は、アプリケーションプログラム・ソースコードとして参照する。プロセッサで実行することができるそれに対応した表現は、実行可能イメージとして参照する。高級言語で書かれたアプリケーションが実行できるようになるまでに、それは、コンパイルしリンクして、そのアプリケーション・ソースコードを実行可能なイメージに変形しなければならない。コンパイラは、入力としてアプリケーション・ソースコードを含むファイルを受け取り、そして出力としてオブジェクトコードと呼ぶフォーマットのファイルを発生する。最後に、１つ以上のオブジェクトコード・ファイルをリンクさせて、その実行可能なイメージを形成する。リンクすることは、オブジェクトモジュールが、アドレス、シンボルまたは機能がどこか他のサイトで定義された関数のようなそのオブジェクトモジュールの外部に行う参照を解決する。ソースコードもまた、データをメモリに記憶できる配列を定義することができ、これは、便宜上シンボリカリーと呼ばれている。このような定義された配列は、データ構造と呼ぶが、その理由は、これらがメモリ内におけるデータの物理的配列、即ちデータが組織される構造を表すからである。最も一般的には、遠隔制御、管理、コンフィギュレーション、モニタおよび診断のアプリケーションは、このアプリケーションソフトウェアと統合しそしてデバイスに埋め込んだ固有の所有権を主張できるユーザインターフェースを用いている。頻繁に、これらのユーザインターフェースは、テキスト形態だけの情報を提示しまた受け取る。さらに、これらは、ポータブルではなく、一般に特有のプラットフォーム、即ちハードウェアとソフトウェアとの組み合わせの上で動作するよう設計されている。制御、管理、コンフィギュレーションおよび診断を希望するデバイスは、メモリおよび長期記憶スペースのような、限定されたランタイム・リソースしか利用可能なものとして有していない。所有権を主張できるンターフェースは、たびたび、データの提示、データ獲得、およびポータビリティに関してそのような制限を伴って設計されているが、その理由は、それらフィーチャを提供するのにかかる開発コストのためであり、またユーザインターフェースのサイズおよびランタイム・リソース要求を最小に維持するためである。各ユーザインターフェースは、オペレーティング・システム、アプリケーションおよびハードウェアのプラットフォーム(この上でそれらの動作が実行される)に対し独特なだけでなく、特定の遠隔制御、管理、コンフィギュレーション、モニタ、および診断の機能に独特である傾向があり、かなりの時間および／またはその他のリソースが開発にかかることになる。グラフィックス処理およびポータビリティは、ほとんどのアプリケーションについては高価な贅沢だと考えられている。しかし、制御、管理、コンフィギュレーション、モニタおよび診断を必要とする利用可能な製品の領域が広がるにつれ、インターフェースのグラフィカルな提示およびプラットフォームからプラットフォームへのインターフェースのポータビリティのような上記の如き以前の贅沢は、贅沢の範疇から必要なものの範疇に移った。グラフィカルに提示された情報は、テキストで提示されたものよりもより迅速にしかも容易に理解される、ということは周知である。様々なプラットフォームが提示する一貫したユーザインターフェースは、各々のプラットフォームが提示する固有の所有権を主張できるユーザインターフェースよりも理解しやすく、使いやすい、ということも周知である。したがって、ランタイム・リソース要求低いポータブルなＧＵＩが非常に望ましい。インターネット（コンピュータシステム間の通信のための１つの極めてポピュラーなパブリック・ネットワーク）のますますの普及と拡大、ワールドワイドウェブ通信およびプレゼンテーション・モデルの開発により、新たな情報通信パラダイムが現れてきた。ワールドワイドウェブおよびこれと同様の企業内ＬＡＮのようなプライベート・アーキテクチャは、相互接続されたドキュメント・オブジェクトの“ウェブ” を提供している。ワールドワイドウェブ上では、それらのドキュメント・オブジェクトは、グローバルなインターネット上の様々なサイトに配置されている。このワールドワイドウェブは、“Ｔhe Ｗorld-Ｗide Ｗeb”，by Ｔ.Ｂerners-Ｌe e，Ｒ.Ｃailliau，Ａ．Ｌouotonen，Ｈ.Ｆ.Ｎielsen and Ａ．Ｓecret，Ｃommum ications of the ＡＣＭ，37(8),pp.76-82，Ａugust 1994、並びに、“Ｗorld Ｗ ide Ｗeb: Ｔhe Ｉnformation Ｕniverse”by Ｂerners-Ｌeet，Ｔ.，et al.，i n Ｅlectronic Ｎetworking: Ｒesearch，Ａpplications and Ｐolicy，Ｖol.1 ，Ｎo.2，Ｍeckler，Ｗestport，Ｃonn.，Ｓpring 1992にも記載されている。インターネット上では、ワールドワイドウェブは、ドキュメント(即ちコンテンツ) 、クライアントソフトウェア（即ちブラウザ）およびサーバソフトウェア（即ちサーバ）の集合体であり、これらは協働して、ユーザに情報を提示しまたユーザから情報を受ける。ワールドワイドウェブはまた、コンテンツを通して種々のデータベースおよびサービスに対しユーザを接続するのに使用される。しかし、以下で述べることを除いて、ワールドワイドウェブは、主として、サーバを介してブラウザに利用可能なコンテンツ・ドキュメントに含まれたスタティック情報に基づいている。そのような制限は、デバイスまたはアプリケーションが発生したダイナミック情報を提示しなければならないＧＵＩとしては、ワールドワイドウェブ・パラダイムを役に立たなくしてしまう。ワールドワイドウェブ通信パラダイムは、在来のクライアント−サーバ・モデルに基づいている。コンテンツは、サーバがアクセス可能なドキュメント内に保持されている。クライアントは、相互接続システムを介してドキュメントを要求でき、そしてこのドキュメントは、次に、その相互接続システムを介してクライアントへサーブされる。そのクライアントソフトウェアは、必要なら、サーブされたドキュメントのコンテンツを解釈する責任を負う。 “ウェブ”内のドキュメントオブジェクト・タイプ間では、ドキュメントおよびスクリプトである。ワールドワイドウェブ内のドキュメントは、ブラウザまたはブラウザの拡張には知られた非限定のフォーマットにおける、テキスト、イメージ、サウンドまたは提示されるべきその他の情報を含むことができる。ブラウザがサーバからのドキュメントを要求したときに得られるプレゼンテーションあるいはそのときに実行されるその他のアクションは、ドキュメントに含まれたテキストにより通常決定される。そのドキュメントは、ハイパーテキストマークアップ言語（ＨＴＭＬ）で書かれている。ＨＴＭＬは、“ＨyperＴext Ｍarkup Ｌ anguage Ｓpecification-2.0”，by Ｔ.Ｂerners-Ｌee and Ｄ.Ｃonnolly，ＲＦＣ1866，proposed standard，Ｎovember 1995,並びに、“Ｗorld Ｗide Ｗeb ＆ＨＴＭＬ”by Ｄouglas Ｃ.ＭcＡrthur，in Ｄr．Ｄobbs Ｊournal，Ｄecember 1994,pp.18-20,22,24,26,86に記載されている。そのように記憶されるＨＴＭＬドキュメントは、一般的にはスタティックである。即ち、コンテンツは、ドキュメントが手で変更されるとき以外は、時間で変化することはない。スクリプトは、実行されたときに、ＨＴＭＬドキュメントを発生できるプログラムである。ＨＴＭＬは、マークアップ言語と呼ばれるコンピュータ言語ファミリの内の１つである。マークアップ言語は、デバイスと独立の方法でテキスト・ドキュメントを表示、印刷等する方法を記述するコンピュータ言語である。この記述は、テキスト型タグの形態を取り、ドキュメントテキストに対して適用すべきフォーマットまたはそれに対し取るべきその他のアクションを示す。タグは、通常、マークアップ言語において定義された意味をもつ独特の文字ストリングである。これらタグについては、以下に詳述する。ＨＴＭＬは、ワールドワイドウェブに使用されているが、それは、ハイパーテキスト・ドキュメントを書くために設計されているためである。その正式な定義は、ＨＴＭＬドキュメントが、特定のドキュメントタイプ定義（ＤＴＤ: Ｄocum ent Ｔype Ｄefinition）に従う標準汎用マークアップ言語（ＳＧＭＬ: Ｓtanda rd Ｇenerlized Ｍarkup Ｌanguage）のドキュメントである。１つのＨＴＭＬドキュメントは、階層的な１組のマークアップ・エレメントを含み、これにおいて、ほとんどのエレメントは、開始タグと、これに続くコンテンツと、そして終了タグとを有する。コンテンツは、テキストと、ネストしたマークアップ・エレメントとの組み合わせである。タグは、かぎ括弧(‘＜’と‘＞’)で囲み、ドキュメントがどのように構成され、ドキュメントをどのように表示し、またハイパーテキストリンクの宛先およびラベルも示す。タイトル、ヘッダ、ボールドおよびイタリックのようなテキスト属性、リスト、節バウンダリ、他のドキュメントまたは同じドキュメントの他の部分へのリンク、インラインのグラフィックイメージおよびその他の多くのフィーチャのような、マークアップ・エレメントのためのタグが存在する。ここで、ＨＴＭＬの例を数行示すことにする。Ｓome words are<Ｂ>bold</Ｂ>，others are<Ｉ>italic</Ｉ>．Ｈere we start a new paragraph.<Ｐ>Ｈere's a link to the<ＡＨＲＥＦ="http://www.agranat.com">Ａgranat Ｓystems，Ｉnc.</Ａ>ho me page．このサンプル・ドキュメントは、"ＨＲＥＦ="によって与えられるように、別のドキュメントへのリンクを含んでいるため、ハイパーテキスト・ドキュメントである。また、ハイパーテキスト・ドキュメントは、同じドキュメント内の別の箇所へのリンクを有することもある。リンクされたドキュメントは、一般に、インターネット上のどこかの場所で見つけることができる。ユーザがウェブブラウザと呼ぶクライアント・プログラム（後に説明する）を用いてそのドキュメントを見ているときには、リンクは、強調された語または句として表示される。例えば、ウェブブラウザを用いると、上のサンプル・ドキュメントは、ユーザのスタリーン上では次のように表示される。Ｓome words are bold，others are italic．Ｈere we start a new paragraph ．Ｈere's a link to Ａgranat Ｓystems，Ｉnc. home page．このウェブブラウザでは、例えば、強調された領域の上をマウスを用いてクリックすることにより、そのリンクを選択することができる。リンクを選択すると、関連付けられたドキュメントが表示される。したがって、強調されているＡgr anat Ｓystems，Inc.というテキストの上をクリックすると、そのホームページが表示されることになる。ブラウザを用いてイメージ、ビデオ、サウンドなどをサーバから直接に要求することもできるが、サーバがブラウザにサーブする情報のプレゼンテーションを制御するＨＴＭＬドキュメントを要求されるのが、より通常である。しかし、後で述べる例外を除き、ＨＴＭＬファイルのコンテンツはスタティックなものである。すなわち、ブラウザは、ドキュメントがサーブされる時点では、コンテンツの受動的なスナップショットを提示できるだけである。ダイナミックな情報、すなわち、アプリケーションまたはデバイスが生成する情報を提示するため、またＨＴＭＬが生成したフォームに挿入されたユーザ・データからその情報を取得するためには、従来のワールドワイドウェブサーバは、以下で説明するコモン・ゲートウェイ・インターフェース（ＣＧＩ）などの“生の”インターフェースを使用している。ＨＴＭＬは、アプリケーションまたはデバイスが生成するダイナミックな情報を提示するメカニズムは、ＣＧＩなどの生のインターフェースを介するもの以外は、備えていない。アプリケーションまたはデバイスが用いるためにユーザからデータを取得することに関しては、標準的なＨＴＭＬは、ブラウザにインタラクティブなフォームをサーブする便利なメカニズムを実現する１組のタグを提供しているが、そしてこれは、テキスト・フィールド、チェック・ボックスおよびプルダウン・メニューを完備するものではあるが、提示されたフォームを処理するには、ＣＧＩを用いなければならない。フォームの処理は、遠隔制御、管理、コンフィギュレーション、モニタおよび診断のアプリケーションにとって重要である。その理由は、フォームの処理が、ワールドワイドウェブ通信モデルを用いてユーザ入力にしたがってアプリケーションを構成する便利な方法だからである。しかし、ＣＧＩを用いてのフォーム処理は極端に複雑であり、以下で分かるように、アプリケーションの設計者は、不慣れなインターフェースを学習した上で実現することが必要となる。したがって、ＣＧＩは、新たなＧＵＩの可能性を急速に開発しそのプロトタイプ化をするための適切なインターフェースとは言えない。更に、開発者は、そのユーザ・インターフェースと共に完全なアプリケーションを開発するためには、ネイティブ・アプリケーション・ソースコード言語（例えば、Ｃや、Ｃ＋＋など）、ＨＴＭＬおよびＣＧＩをマスタしなければならない。スタティックコンテンツとダイナミックコンテンツとに対するワールドワイドウェブ通信パラダイムのモデルは、図１４と図１５とにそれぞれ示している。図１４に示しているように、ブラウザ１４０１は、サーバ１４０３に接続１４０２を行い、サーバ１４０３は、スタティックコンテンツ１４０５を、記憶装置１４０７からブラウザ１４０１に与える。図１５に示すダイナミックコンテンツの場合には、サーバ１４０３は、ブラウザ１４０１との接続１４０２の制御をＣＧＩ１５０３を介してアプリケーション１５０１に送る。アプリケーション１５０１は、ブラウザ１４０１との接続１４０２を維持しなければならないし、ダイナミックコンテンツを含んでいた要求のサービスが完了すると制御をサーバ１４０３に戻さなければならない。更に、ダイナミックコンテンツを含む要求をサービスする間は、アプリケーション１５０１が、ブラウザ１４０１との接続１４０２を維持し、サーバ／ブラウザ・トランスポート・プロトコルにおけるヘッダを生成し、スタティックおよびダイナミックなコンテンツ・エレメントを全て生成し、ユーザによって戻される任意のフォーム・データをパージングすることなどを含む、サーバ１４０３が通常実行する機能を担当することになる。ＣＧＩ１５０３またはその他の生のインターフェースを使用すると、アプリケーション設計者がこの仕事の全てを行うことが強制されるので、フォームが提示されているアプリケーション１５０１は、必然的に複雑になる。ダイナミックコンテンツをブラウザに提供するために、ワールドワイドウェブは、何らかのサーバ側のスクリプト言語に加え、Ｊａｖａやそれ以外のクライアント側のスクリプト言語をも含むように発展してきている。しかし、これらの言語は、ブラウザ１４０１またはサーバ１４０３の中に備えられたインタープリタによって解釈されるので、そのように生成される情報の提示をスローダウンさせる。クライアント側のスクリプトの場合には、スクリプトは、アプリケーションやアプリケーションに特有の情報への直接的なアクセスを全く有さない。したがって、クライアント側のスクリプトを用いてアプリケーションに特有の情報を生成または受信するためには、ＣＧＩ１５０３またはそれ以外の生のインターフェースを依然として用いなければならない。サーバ側のスクリプトの場合には、サーバ１４０３は、コンテンツを、それが供給されるのと同時にパージングして、解釈すべきスクリプトを探さなければならない。スクリプトが有するアプリケーションへのアクセスは、アプリケーション設計者が設計したアプリケーション・ソフトウェア・インターフェースによってではなく、スクリプト言語の定義によって制限される。サーバ側のスクリプトは、実行可能なプログラムまたはファイルに記憶された１組のコマンドであり、これは、サーバ・プログラムによって走らせることにより、ウェブブラウザに戻すＨＴＭＬドキュメントを発生することができる。典型的なスクリプト・アクションには、ファイル、データベースまたはデバイスから情報を得るためにライブラリ・ルーチンを走らせたり、別のマシンから情報を得る要求を開始したり、選択されたハイパーテキスト・リンクに対応するドキュメントを検索したりすることが含まれる。スクリプトは、例えば、エンド・ユーザがウェブブラウザにおいて特定のハイパーテキスト・リンクを選択したりまたはＨＴＭＬフォーム要求を提出したりするときに、ウェブサーバ上で走らせることができる。スクリプトは、通常は、Ｂasic、Ｐractical Ｅxtraction and Ｒepo rt Ｌanguagc(Ｐerl)、Ｔool Ｃontrol Ｌanguage(Ｔcl)、またはＵＮＩＸオペレーティング・システムのシェル言語の１つなどの解釈された言語で書かれているが、Ｃ言語などのプログラミング言語で書いた後に、実行可能なプログラムにコンパイルすることもできる。Ｔｃｌでのプログラミングについては、Ｊohn Ｋ．Ｏusterhout，"Ｔcl and the Ｔk Ｔoolkit"，Ａddison-Ｗesley，Ｒeading，ＭＡ，ＵＳＡ，1994にその詳細が記載されており、Ｐｅｒｌに関しては、Ｌarry Ｗall and Ｒandal Ｌ．Ｓchwartz，"Ｐrogramming Ｐerl"，Ｏ'Ｒeilly ＆Ａ ssociates，Ｉnc.，Ｓebastopol，ＣＡ，ＵＳＡ，1992に詳細が記載されている。ウェブにおけるドキュメント・オブジェクトは、それぞれが、ユニバーサル・リソース識別子（ＵＲＩ）と呼ぶ識別子を有している。これらの識別子については、Ｔ．Ｂerners-Ｌee，“Ｕniversal Ｒesource Ｉdentifier in Ｗorld Ｗid e Ｗeb: ＡＵnifying Ｓyntax for the Ｅxpression of Ｎames and Ａddresse s of Ｏbjects on the Ｎetwork as used in the Ｗorld-Ｗide-Ｗeb,”ＲＦＣ 1630，ＣＥＲＮ，Ｊune 1994およびＴ．Ｂerners-Ｌee，Ｌ．Ｍasinter，and Ｍ．ＭcＣahill,“Ｕniform Ｒesource Ｌocator(ＵＲＬ),”ＲＦＣ 1738，ＣＥＲＮ，Ｘerox ＰＡＲＣ，Ｕniversity of Ｍinnesota，Ｄecember 1994に詳細が記載されている。ＵＲＩによって、インターネット上の任意のオブジェクトを、既に述べたＨＴＭＬドキュメント内のリンクなどのネームまたはアドレスによって参照することが可能になる。ＵＲＩには、２つのタイプがある。すなわち、ユニバーサル・リソース・ネーム（ＵＲＮ）と、ユニフォーム・リソース・ロケータ（ＵＲＬ）とである。ＵＲＮは、与えられたネーム空間内でネームによってオブジェクトを参照する。インターネットのコミュニティは、ＵＲＮのシンタクスおよび用法をまだ完全には定義していない。ＵＲＬは、ネットワーク・プロトコルを用いてアクセス・アルゴリズムを定義することにより、オブジェクトを参照する。ＵＲＬの例は、“http: //www.agranat.com”である。ＵＲＬは、“scheme: scheme_specific_components”というシンタクスを有しており、 schemeは、（ＨＴＭＬ、ＦＴＰまたはＧＯＰＨＥＲなどの）アクセス・プロトコルを識別する。ＨＴＭＬのschemeに対しては、ＵＲＬは、"http://host:port/ path?search"のフォームを有しているが、ただし、hostは、そのプロトコルをサポートするマシンのインターネット・ドメインネームであり、portは、（デフォルトと異なる場合には）適切なサーバの送信制御プロトコル（ＴＣＰ）ポートの数であり、pathは、オブジェクトのスキームに特有のＩＤであり、searchは、オブジェクトのコンテンツを照会するオプショナルなパラメータである。ＵＲＬは、また、ワールドワイドウェブだけではなく、プライベートなコンピュータシステムやネットワーク上のウェブサーバおよびブラウザによっても用いられる。ネットワーク・ユーザにドキュメントを利用可能にすることを望んでいるサイト、すなわち、ネットワークに接続されたコンピュータを有する組織は、“ウェブ・サイト”と呼び、そのドキュメントへのアクセスを与えるために、“ウェブサーバ”プログラムを走らせなければならない。ウェブサーバ・プログラムは、ネットワーク上のコンピュータがワールドワイドウェブまたはプライベートなウェブのそれ以外の部分にドキュメントを利用可能とさせることができるコンピュータ・プログラムである。ドキュメントは、多くの場合が、ＨＴＭＬ言語でのハイパーテキスト・ドキュメントであるが、他のタイプのドキュメントであってもよいし、イメージ、オーディオおよびビデオ情報であってもよい。ウェブサーバによって管理される情報は、サーバ上に記憶されている、または、ウェブサーバ上のスクリプトによってダイナミックに生成されるハイパーテキスト・ドキュメントを含む。ウェブサーバのソフトウェア・パッケージには、Ｃonseil Ｅuropeen pourla Ｒecherche Ｎucleaire(ＣＥＲＮ，the Ｅuropean Ｌaboratory for Ｐ article Ｐhysics)のサーバや、Ｎational Ｃenter for Ｓupercomputing Ａppl ication(ＮＣＳＡ)のサーバなど、複数が存在する。ウェブサーバは、複数の異なるプラットフォームに対して実現されており、ＵＮＩＸオペレーティング・システムを走らせるＳun Ｓparc 11 ワークステーＷindows^TMオペレーティング環境を走らせるインテル社製ペンティアム・プロセッサを備えたパーソナル・コンピュータが含まれる。ウェブサーバはまた、コモン・ゲートウェイ・インターフェース(ＣＧＩ:Ｃom mon Ｇateway Ｉnterface)と呼ぶ、外部プログラムを走らせる標準的なインターフェースを有する。ＣＧＩに関しては、Ｌincoln Ｄ.Ｓtein,“Ｈow to Ｓet Ｕ p Ａnd Ｍaintain ＡＷeb Ｓite”,Ａddison-Ｗesley，Ａugust，1995に、より詳細な記載がある。ゲートウェイとは、入力される情報の要求を処理し、適切なドキュメントを返すまたはドキュメントをダイナミカルに生成するプログラムである。例えば、ゲートウェイは、質問を受け取り、ＳＱＬデータベースの中で回答を探し、サーバがその結果をクライアントに送ることができるように応答をＨＴＭＬのページに翻訳する。ゲートウェイ・プログラムは、ＣまたはＰｅｒｌまたはＴｃｌなどのスクリプト言語、ＵＮＩＸオペレーティング・システムのシェル言語などで書かれている。ＣＧＩ標準は、スクリプトまたはアプリケーションが入力およびパラメータをどのように受け取るかを特定し、任意の出力がどのようにフォーマットされサーバに返却されるかを特定する。ネットワーク上のあるウェブ・サイトで入手可能なドキュメントにアクセスすることを望んでいるユーザ（典型的には、ウェブサーバが用いているマシンとは異なるマシンを用いている）は、“ウェブブラウザ”と呼ぶクライアント・プログラムを走らせなければならない。ブラウザ・プログラムによって、ユーザがウェブサーバからドキュメントを検索し表示することが可能になる。普及しているウェブブラウザをいくつか挙げると、カリフォルニア州マウンテン・ビューのネットスケープ・コミュニケーション社によるＮvigatorブラウザ、ＮＣＳＡによるＭosaicブラウザ、テキサス州オースチンのマイクロエレクトロニクス・アンド・コンピュータ・テクノロジ社によるＷin Ｗebブラウザ、ワシントン州レドモンドング環境を走らせるインテル社製のペンティアム・プロセッサを備えたパーソナル・コンピュータやアップル社製のマッキントッシュ・パーソナル・コンピュータを含む多くのプラットフォームに対して存在している。ウェブサーバおよびウェブブラウザは、ハイパーテキスト・トランスファー・プロトコル（ＨＴＴＰ）のメッセージ・プロトコルおよび背後の送信プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）のインターネットのデータ転送プロトコルを用いて、通信を行う。ＨＴＴＰは、Ｔ．Ｂerners-Ｌee，Ｒ.Ｔ.Ｆi elding，Ｈ.Ｆrystyk Ｎielsenによる.“Ｈypertext Ｔransfer Ｐrotocol−ＨＴＴＰ／1.0”(Ｉnternet Ｄraft Ｄocument，1995年10月14日)に開示されており、これは、現在標準的なプロセスとして用いられている。この開示においては、最新のバージョンが、ＲＦＣＺ０６８に示されており、このＲＦＣＺ０６８は、ＨＴＴＰ／1.1のドラフト規定である。ＨＴＴＰにおいて、ウェブブラウザは、ウェブサーバとの接続を確立し、そして、ＨＴＴＰ要求メッセージを該サーバに送信する。ＨＴＴＰ要求メッセージに応答して、ウェブサーバは認証チェックを行い、要求された動作（アクション）を実行し、かつ、該要求された動作によって生じたＨＴＭＬドキュメントを含んでいるＨＴＴＰ応答メッセージまたはエラー・メッセージを返送する。返送されたＨＴＭＬドキュメントは、ウェブサーバに単に格納されているファイルであるか、または、ＨＴＴＰ要求メッセージに応答して呼び出されたスクリプトを用いてダイナミックに生成されるものである。例えば、ドキュメントを受け取るために、ウェブブラウザは、ＨＴＴＰ要求メッセージを指定のウェブサーバに送信し、そのＵＲＬによってドキュメントを要求する。次に、ウェブサーバは、そのドキュメントを検索し、該ドキュメントをＨＴＴＰ応答メッセージに含ませて、ウェブブラウザに返送する。ドキュメントがハイパーテキスト・リンクを有している場合は、ユーザは、検索して表示すべき新しいドキュメントを要求するため、リンクを再度選択する。他の例においては、データベースのサーチを要求するためのフォームにユーザが書き入れると、ウェブブラウザは、ウェブサーバに対して、サーチすべきデータベースのネーム、サーチ・パラメータ、およびサーチ・スクリプトのＵＲＬを含んでいるＨＴＴＰ要求メッセージを送信する。ウェブサーバは、サーチ・パラメータに関連するプログラムすなわちスクリプトを呼び出す。プログラムは、パラメータを調査し、データベース・インターフェースに対して質問を送ることにより、質問に対する応答を試みる。プログラムは、質問の応答結果を受け取ると、ウェブブラウザに返送すべきＨＴＭＬドキュメントを構築し、ＨＴＴＰ応答メッセージ中に該ドキュメントを含ませて、ウェブブラウザに送信する。ＨＴＴＰ中の要求メッセージは、サーバによって実行されるべき動作のタイプを示す“メソッドネーム”、ウェブサーバにおけるターゲット・オブジェクト( ドキュメントまたはスクリプトのいずれか)を示すＵＲＬ、および他の制御情報を含んでいる。応答メッセージは、状態ライン、サーバ情報、および可能なデータ・コンテンツを含んでいる。Ｍultipurpose Ｉnternet Ｍail Ｅxtensions（ＭＩＭＥ）は、ネットワーク上で転送されるメッセージのコンテンツを記述するための標準的な方法である。ＨＴＴＰ要求メッセージおよびＨＴＴＰ応答メッセージは、メッセージのフォーマットを示すためにＭＩＭＥラインを用いている。ＭＩＭＥは、“ＭＩＭＥ（Ｍultipulpose Ｉnternet Ｍail Ｅxtensions）”;Ｍ echanisms for Ｓpecifying and Ｄescribing the Ｆormat of Ｉnternet Ｍess age Ｂodies，Ｉnternet ＲＦＣ1341（1992年７月）に詳細に記載されている。ＨＴＴＰ／1.1プロトコルに規定されている要求メソッドは、ＧＥＴ,ＰＯＳＴ, ＰＵＴ,ＨＥＡＤ,ＤＥＬＥＴＥ,ＬＩＮＫ,およびＵＮＬＮＫを含んでいる。ＰＵＴ,ＤＥＬＥＴＥ,ＬＩＮＫ,およびＵＮＬＩＮＫは、殆ど共通には用いられない。ＨＴＴＰ／1.1プロトコルの最終バージョンにおいて規定されるよう意図されている要求メソッドは、ＧＥＴ,ＰＯＳＴ,ＰＵＴ,ＨＥＡＤ,ＤＥＬＥＴＥ,ＯＰＴＩＯＮ,およびＴＲＡＣＥを含んでいる。ＤＥＬＥＴＥ,ＰＵＴ,ＯＰＴＩＯＮ,およびＴＲＡＣＥは、殆ど共通には用いられない。全てのメソッドは、上記したＨＴＴＰ／1.0およびＨＴＴＰ／1.1仕様に詳細に記載されている。最後に、在来のワールドワイドウェブ技術を用いているデバイスまたはアプリケーションは、サーバへのアクセスを有する必要がある。在来のサーバは、比較的大きくかつリソースが豊富（リソース・リッチ）なコンピュータシステムで動作する大きなソフトウェア・パッケージである。これらのコンピュータシステムは、処理速度およびパワー、長期間記憶容量、短期間記憶容量、およびオペレーティング・システム・ファシリティにおいて、リソース・リッチである在来のサーバは、これらリソースの長所、例えば、どのようにコンテンツ・ソース・ドキュメントを記憶するかについての長所を採用している。コンテンツへの高速、便利なアクセスに関しては、バルキーＡＳＣＩＩテキスト・ファイルのディレクトリ・ツリーに、従来は記憶される。したがって、従来のワールドワイドウェブ技術は、比較的小さな安価でリソースが豊富ではない(リソース・プワー)デバイスまたはアプリケーションにおいて、ＧＵＩを実行するために用いることはできない。ＨＴＴＰプロトコルを用いてコンピュータ・ネットワーク上で通信を行うウェブサーバおよびウェブブラウザの組み合わせは、本明細書においては、ワールドワイド通信パラダイムと呼ぶ。発明の摘要したがって、本発明の目的は、アプリケーション、デバイスおよび機器に埋め込んだ遠隔制御機能、管理機能、コンフィギュレーション機能、モニタ機能、診断機能と共に使用するための改良したグラフィカルユーザインターフェースを提供することである。本発明の１つの面により提供するのは、ダイナミックエレメントを有するグラフィカルユーザインターフェースを提供する方法である。この方法は、マークアップ言語で書かれた少なくとも１つのテキスト・ドキュメント内に前記グラフィカルユーザインターフェースのエレメントを定めること、により開始する。次に、この方法は、前記ドキュメント内のあるロケーションに、アプリケーション・ソースコードの１つのセグメントを含むコード・タグを含めること、を定める。次に、前記テキスト・ドキュメントは、前記マークアップ言語を解釈するクライアントに対しサーブし、そして前記ロケーションに遭遇したときに、前記クライアントに対し、前記アプリケーション・ソースコード・セグメントが表す１つの命令シーケンスを実行した結果から得た１つの文字シーケンスをサーブする。コード・タグの１実施例であってこれらの使用を例示するものについて、以下で詳細に説明する。本発明の別の面によれば、ダイナミックエレメントを有するグラフィカルユーザインターフェースを提供する別の方法がある。この方法もまた、マークアップ言語で書かれた少なくとも１つのテキスト・ドキュメント内に前記グラフィカルユーザインターフェースのエレメントを定める。前記ドキュメント内には、プロトタイプ・タグが識別したストリングを含める。前記テキスト・ドキュメントは、プロトタイプ化(prototyping)クライアントに対しサーブし、このクライアントは、前記マークアップ言語を解釈するが、前記プロトタイプ・タグを認識せずまた表示しないが、前記ストリングを表示する。プロトタイプ・タグの１実施例であってそれらの使用を例示するものについては、以下で詳細に説明する。本発明のさらに別の面によれば、ダイナミックエレメントを有するグラフィカルユーザインターフェースを提供するさらに別の方法がある。前記グラフィカルユーザインターフェースのエレメントは、マークアップ言語で書かれた少なくとも１つのテキスト・ドキュメント内で定める。前記ドキュメント内のあるロケーションには、アプリケーション・ソースコードの１つのセグメントを含むコード・タグを含める。また、前記ドキュメント内には、プロトタイプ・タグが識別したストリングを含める。前記テキスト・ドキュメントは、コンテンツ・ソースにコンパイルし、そして前記コンテンツ・ソースは、続いて、前記テキスト・ドキュメントのレプリカにデコンパイルする。前記テキスト・ドキュメントの前記レプリカは、前記マークアップ言語を解釈するクライアントにサーブし、そして前記レプリカ内の前記ロケーションに遭遇したときに、前記クライアントに対し、前記アプリケーション・ソースコード・セグメントを実行することにより発生された結果から得た１つの文字ストリームをサーブする。本発明のさらに別の面は、媒体に記録したソフトウェア製品である。このソフトウェア製品は、マークアップ言語のドキュメントをネイティブ・アプリケーションプログラミング言語のデータ構造にコンパイルできるマークアップ言語コンパイラを含み、該コンパイラは、前記ネイティブ・アプリケーションプログラミング言語のコンパイラによるコンパイルのためのファイルでセーブされるべきアプリケーション・ソースコードの１つのセグメントとして、含まれるテキストを指定する１つ以上のコード・タグを認識する。本発明の別の面は、データのエントリのため表示されたフォームを有するグラフィカルユーザインターフェースを提供する方法である。この方法のステップは、マークアップ言語で書かれた少なくとも１つのテキスト・ドキュメント内に前記グラフィカルユーザインターフェースのエレメントを定めるステップと、前記ドキュメント内で、ユーザから要求されまたネイティブ・アプリケーションプログラミング言語で書かれたアプリケーションが使用するデータアイテムをネーミングするステップと、および前記テキスト・ドキュメントを、前記ネーミングしたデータアイテムに関し前記ネイティブ・アプリケーションプログラミング言語でのデータ構造定義を含むコンテンツ・ソースにコンパイルするステップと、を含む。本発明の別の面は、アプリケーション用のグラフィカルユーザインターフェースを開発するためのコンピュータをベースとする装置において実施でき、そして該装置は、マークアップ言語で書かれたドキュメントを操作することができるエディタと、前記マークアップ言語で書かれたドキュメントを表示することができるビューアとを備える。前記装置はさらに、ネイティブ・アプリケーション・ソースコード言語のソースコード・フラグメントを含むコード・タグを認識するマークアップ言語コンパイラを含み、前記コード・タグは、他の場合には前記マークアップ言語の１部分ではなく、また前記コンパイラは、前記ソースコード・フラグメントのコピーを含む前記ドキュメントの前記ネイティブ・アプリケーション・ソースコード言語での表現を出力として発生する。本発明の別の面によれば、アプリケーション用のグラフィカルユーザインターフェースを開発しプロトタイプ化する方法がある。この方法は、ＨＴＭＬファイルにアクセスするステップと、前記ＨＴＭＬの各部分をカプセル化して、その中にソースコードを入れるステップと、カプセル化した部分をもつ前記ＨＴＭＬからソース・モジュールを発生するステップと、サーバ用のソースコードを発生するステップと、前記アプリケーションをクロスコンパイルしリンクするステップであって、これにより前記ソースコード・モジュールと前記サーバとは実行可能なオブジェクトコードを発生する、前記のステップと、を含む。本発明は、この別の面によれば、コンピュータ読み取り可能媒体に固定したデータ構造とすることができ、該データ構造は、互いに通信するクライアントおよびサーバを含むコンピュータシステムにおいて使用するためのものである。前記データ構造は、前記アプリケーションに関連した実行可能なコード、サーバ・コード、アプリケーション・コードを含むカプセル化した各部分をもつ、クロスコンパイルし、記憶し、リンクしたＨＴＭＬファイルを含み、これにおいて、前記実行可能なコードは、前記ＨＴＭＬファイルをサーブしたときに走らせ、これにより、前記アプリケーションに関連したリアルタイム・ダイナミック・データを提供する。図面の簡単な説明図において、同様な要素は同様な参照番号で示す。図１は、開発システムに関する本発明の１つの面のブロック図である。図２は、埋め込み形システムに関する本発明の１つの面のブロック図である。図３は、ＥＭＷＥＢ_ＳＴＲＩＮＧタグの使用を示すＨＴＭＬテキスト・フラグメントである。図４は、ＥＭＷＥＢ_ＳＴＲＩＮＧタグの別の使用を示す別のＨＴＭＬテキスト・フラグメントである。図５は、ＥＭＷＥＢ_ＩＮＣＬＵＤＥタグの使用を示すＨＴＭＬテキスト・フラグメントである。図６は、ＥＭＷＥＢ_ＩＮＣＬＵＤＥタグの別の使用を示す別のＨＴＭＬテキスト・フラグメントである。図７は、ＥＭＷＥＢ_ＳＴＲＩＮＧタグに関連したＥＭＷＥＢ_ＩＴＥＲＡＴＥ属性の使用を示すＨＴＭＬテキスト・フラグメントである。図８は、ＥＭＷＥＢ_ＩＮＣＬＵＤＥタグに関連したＥＭＷＥＢ_ＩＴＥＲＡＴＥ属性の使用を示すＨＴＭＬテキスト・フラグメントである。図９は、フォーム用のＨＴＭＬソースコードと生成されたフォーム出力との間の関係を示す、フォーム処理の一例である。図１０は、data.datアーカイブ・ファイルのヘッダを規定するデータ構造のブロック図である。図１１は、ダイナミックコンテンツ処理を示す、埋め込み形システムの状態図である。図１２は、フォーム処理を示す、埋め込み形システムの状態図である。図１３は、サスペンド／レジューム処理を示す、埋め込み形システムの状態図である。図１４は、サーバとクライアントとの間のスタティック・コンテンツの従来例のワールドワイドウェブ通信を示すブロック図である。図１５は、サーバとクライアントとの間のダイナミックコンテンツの従来例のワールドワイドウェブ通信を示すブロック図である。詳細な説明本発明は、参照する図面に関連して以下の詳細な説明を読めば、より十分に理解できる。本発明の種々の面の実施例について説明する。まず、アプリケーション開発とグラフィカルユーザインターフェース開発が密接にリンクされているが、これらがアプリケーションおよびＧＵＩの在来の開発と比較して低いレベルの複雑さしか要求しない開発環境について、説明する。第２に、アプリケーション、サーバ、およびＧＵＩが緊密に結合され、コンパクトでフレキシブルなオペレーティング環境について、説明する。この記述するシステムにおいては、ポータビリティをもち、低いランタイム要求、およびユニバーサル・フロントエンドすなわちユーザとの接続点としてユーザが利用可能な多種のシステムの任意のものを用いているＧＵＩは、ユーザがすでに親しんでいるソフトウェアである。開発環境図１は、本発明の１つの面による環境を示している。この環境の全てのものを示しているわけではないが、図示しているものは、以下の説明で述べる。一般的に、アプリケーション開発環境は、ソースコード・エディタ、コンパイラ１０１、リンカ、およびアプリケーションをテストしデバッグするランタイム環境を含んでいる。本発明による開発環境は、開発者がアプリケーションの開発に有効であると見出す在来の開発環境のコンポーネントを含んでいる。埋め込み形アプリケーションの場合、すなわち、デバイスまたはより大きなアプリケーションに含まれているアプリケーションの場合には、ランタイム環境は、そのアプリケーションが埋め込まれているデバイスまたはアプリケーション、またはシミュレーション、またはそのエミュレーションを含んでいる。コンパイラ１０１は、ソースコード・エディタを用いて生成されるかあるいは他のソースからのソースコード１０３を用い、そしてこれは、後で、リンクされて、実行可能なイメージを形成する。上記した在来のエレメントに加えて、本発明による開発環境の実施例は、ＨＴＭＬコンパイラ１０７を含み、そしてこのコンパイラの出力１０９は、開発下のアプリケーションのソースコード言語にある。さらに、開発環境は、ＨＴＭＬエディタ、クライアント・ソフトウエアすなわちブラウザと通信するためのＨＴＴＰ互換サーバ、およびＨＴＴＰ互換ブラウザを含むことができる。ＨＴＭＬエディタは、アプリケーション用のＧＵＩの外観および使い勝手を定めるＨＴＭＬドキュメントを生成し編集するのに使用する。ＨＴＭＬの知識を最小限だけ必要とするか、または全く必要としないで、このタスクを実行するため使用するＨＴＭＬエディタは、ＨＴＭＬドキュメントに非標準のタグのエントリを可能にするものであることが好ましい。以下に更に詳細に説明するように、サーバおよびブラウザは、プロトタイプＧＵＩをテストするために用い、このテストは、アプリケーションと完全に統合する前、またはアプリケーションが存在しないときに実行する。ブラウザは、サーバとの接続できる能力が必要であり、この接続は、例えば、図１４に関連して図示し上述したように、ＴＣＰ／ＩＰ等の在来の接続プロトコルを用いて行う。当業者には明らかなように、その他のプロトコルまたは直接接続も使用可能である。ブラウザとサーバはインターネット等のネットワークを介して接続できるが、必ずしもそのようにする必要はない。例えば、サーバおよびクライアントは、１つのコンピュータシステム上で走らせそして互いに接続することもできる。アプリケーションの開発は、実質的にソフトウェア開発者に公知の従来の方法で進行する。アプリケーションの開発は、当該アプリケーションとの間でデータの通信を行うソフトウェア・インターフェースの設計を含んでいるはずである。しかし、このソフトウェア・インターフェースは、ＧＵＩではない。むしろ、そのインターフェースは、他のソフトウェアがアプリケーションといかに通信するかを定めるだけである。例えば、インターフェースは、他のソフトウェアがこのアプリケーションと通信するのに使用することができるファンクション・コールとグローバル・シンボルとの集合体である。アプリケーションは、Ｃ、Ｃ＋＋等の高級言語で書かれねばならない。アプリケーションの試験は、このアプリケーションをコンパイルし、アプリケーションのフィーチャを働かせながら、アプリケーションをソフトウェア・インターフェースを介して情報を提供または受信するプロトタイプ・コードとリンクすることによって、行うことができる。一方、アプリケーションのためのＧＵＩは、以下のように設計される。ＧＵＩの外観および使い勝手は、ＨＴＭＬエディタ、サーバおよびブラウザを使って、少なくとも１つのＨＴＭＬドキュメントを含む１組のコンテンツ・ソース・ドキュメント１１１（これもＧＵＩの外観および使い勝手を定める）を作ることにより、開発する。ＧＵＩ開発のこの面は従来通りであり、開発者がワールドワイドウェブ・サイトを開発しているかのように進行する。１つ以上のＨＴＭＬドキュメント内の、アプリケーションから得たデータが表示されるべきロケーションにおいては、著者は、特別のタグ（これについては後述する）を含め、これにより、ＨＴＭＬドキュメントは、アプリケーションソフトウェア・インターフェースを用いて所要のデータをアプリケーションから得ることができる。コンテンツ・ソース・ドキュメント１１１は、従来通り、１つ以上のディレクトリ・ツリー１１３の形態で蓄積する。次に、ＧＵＩを定義する内容を含むこのディレクトリ・ツリー１１３は、ＨＴＭＬコンパイラ１０７を用いてコンパイルすることにより、ディレクトリ・ツリー内のコンテンツ・ソース・ドキュメントを表すアプリケーション・ソースコード言語を生成する。ディレクトリ・ツリー１１３内のコンテンツ・ソース・ドキュメント１１１から生成したソースコード・エレメント１０９、ＨＴＴＰ互換サーバ（図示せず）およびアプリケーション・ソースコード１０３は、オブジェクトコード１０５へコンパイルしそしてリンクして、実行可能イメージを形成する。サーバには、完成した実行可能イメージ中へリンクするように準備したオブジェクトコード・ライブラリの形態で供給する。こうして形成した実行可能イメージは、ワールドワイドウェブ・コンテンツ開発のための良く知られたツールを用いて定義したグラフィカルユーザーインターフェースを、在来のアプリケーション開発ツールを用いて定義した制御その他の機能と統合する。上記の統合をうまく実行するために、本発明の記述実施例のＨＴＭＬコンパイラ１０７、すなわちＥmＷeb^TMコンパイラ１０７は、ＨＴＭＬへの特別な多数の拡張を認識する。ＥmＷeb^TMコンパイラ１０７が実現するこのＨＴＭＬ拡張は、本発明の特徴を具体化するものであり、テーブルＡのセクション3.2に詳細に記述している。本発明の理解を助けるために、これらの拡張のうちのいくつかをここで簡単に説明する。ＥＭＷＥＢ_ＳＴＲＩＮＧタグは、ＨＴＭＬドキュメント内のソースコードのフラグメントをカプセル化するのに用いるＨＴＭＬの拡張である。このソースコードは、ドキュメントをブラウザ（通常は他のシステム上で動作している）に対してサーブして、ＥＭＷＥＢ_ＳＴＲＩＮＧタグのロケーションに到達したときに、アプリケーションに埋め込まれたシステムが実行する。このソースコードは、文字ストリングを返し、これは、ＥＭＷＥＢ_ＳＴＲＩＮＧタグのロケーションにおいてドキュメント内にあるように挿入される。ＥＭＷＥＢ_ＳＴＲＩＮＧタグの使用例は、図３および図４に示す。図３の例において、ＥＭＷＥＢ_ＳＴＲＩＮＧタグ３０１は、“Ｃ＝”を用いて、含まれたソースコードの終了３０５を定めるのに用いるバウンダリ文字３０３を定義する。バウンダリ文字定義の直後に、３つのファックス状態の内の１つを表すストリングへポインタを戻すＣコードのフラグメント３０７がある。埋め込み形アプリケーションによってサーブされると、この例のＨＴＭＬは、テキスト“ＮetＦax Ｓtate:”を生成し、この後には、シンボルＧlobalＦaxＳtateの値に依存して、“Ｓending”，“Ｒeceiving”または“Ｉdle”が続く。図４の例は、属性ＥＭＷＥＢ_ＴＹＰＥ４０１が定義するタイプを持つタイプ化されたデータを出力するためのＥＭＷＥＢ_ＳＴＲＩＮＧの使用を示している。ＥmＷeb^TMコンパイラ１０７は、この属性４０１を用いてソースコード出力ルーチンを生成し、そしてこのソースコード出力ルーチンは、戻されたアドレス４０３に見出されるタイプ化されたデータを、ドキュメントの適正なロケーションでサーブするためのストリングへ変換する。同様の機能は、ＨＴＭＬ拡張であるＥＭＷＥＢ_ＩＮＣＬＵＤＥタグによって行う。このタグを用いると、情報の複数のページまたはウィンドウに共通のヘッダやフッタ等のＧＵＩの標準部分は、一度記憶する必要があるだけである。ヘッダおよびフッタのファイルへの参照は、ＥＭＷＥＢ_ＩＮＣＬＵＤＥタグを使って行い、このＥＭＷＥＢ_ＩＮＣＬＵＤＥタグは、このタグが置かれている各ＨＴＭＬコンテンツ・ドキュメント内のロケーションにおいて、そのファイルを挿入する。本発明の記述実施例においては、ＥＭＷＥＢ_ＩＮＣＬＵＤＥタグのコンテンツは、コンテンツのローカル・ディレクトリ・ツリー内の相対的または絶対的パスネームへ還元しなければならない。これは、ワールドワイドウェブ通信パラダイムにリソースがどのように置かれるかに関するユニバーサル・リソース・ロケータ（ＵＲＬ）を指定することによって、あるいは、こうしたローカルＵＲＬを表すストリングを戻すソースコードを含めることによって行うことができる。絶対的ローカルＵＲＬは、“/path/filename”の形式を取る。ここで、“/p ass”は、ディレクトリ・ツリーの根元からファイルが位置するディレクトリへの完全なパスである。相対的ＵＲＬは、現在の、すなわち、ベースのドキュメントが位置するディレクトリに相対的なファイルのロケーションを定義し、そして “path/filename”の形式を取る。記述実施例は、ＥＭＷＥＢ_ＩＮＣＬＩＤＥタグのローカルＵＲＬへの還元を必要とするが、本発明はこれに限定されるものではない。代替の実施例においては、ローカルおよび外部のＵＲＬが許容でき、またその他の限定を課してもよい。ＥＭＷＥＢ _ＩＮＣＬＩＤＥタグの例は、図５および図６に示す。図５の例においては、ＥＭＷＥＢ_ＩＮＣＬＩＤＥタグのＣＯＭＰＯＮＥＮＴ属性５０１は、単にローカルＵＲＬ５０３を定義するだけである。図６の一層念入りな例においては、定義された条件６０５においてローカルＵＲＬ６０３を生成するソースコードのフラグメント６０１は、ローカルＵＲＬをランタイムにおいて生成するのに使用する。ＥＭＷＥＢ_ＳＴＲＩＮＧタグまたはＥＭＷＥＢ_ＩＮＣＬＩＤＥタグが戻す結果は、含めたソースコードへの反復するコールを用いて反復的に作り上げることもできる。これは、ＨＴＭＬへの更に別の拡張であるＥＭＷＥＢ_ＩＴＥＲＡＴＥ属性を用いて行う。ＥＭＷＥＢ_ＩＴＥＲＡＴＥの使用例は、図７および図８に示す。図７は、ＥＭＷＥＢ_ＳＴＲＩＮＧタグ７０３と関連して用いるＥＭＷＥＢ_ＩＴＥＲＡＴＥ属性７０１の例を示している。コードのフラグメント７０５は、ＮＵＬＬが戻されるまで反復して実行する。かくて、このＨＴＭＬは、Ｃソースコードのフラグメントを反復して実行し、システム内の全部のトレイのトレイ・ステータスを表示する。同様に、図８においては、ＥＭＷＥＢ_ＩＮＣＬＵＤＥ８０１およびＥＭＷＥＢ_ＩＴＥＲＡＴＥ８０３を用いて、他のＵＲＬ８０５からのコンテンツが表示されるべきフィーチャのテーブルを作る。テーブルが完全であると、ＮＵＬＬを戻し８０７、反復を終了する。上述のＨＴＭＬへの拡張により、ＨＴＭＬ内のソースコードのカプセル化ができるので、カプセル化したソースコードに所要のグローバル定義、ヘッダ・ファイル、外部デクラレーション等を提供するメカニズムも、ＥＭＷＥＢ_ＨＥＡＤタグの形式で提供する。ＥＭＷＥＢ_ＨＥＡＤタグは、ＥmＷeb^TMコンパイラ１０７のソースコード出力に挿入されるべきソースコード・コンポーネントを、定義された機能の外部で指定する。ＥＭＷＥＢ_ＨＥＡＤタグは、ＨＴＭＬファイル・ヘッダ内に現れるのが好ましいが、しかしどこに現れるようにしてもよい。ＥＭＷＥＢ_ＨＥＡＤタグにが生成するコードは、ＨＴＭＬコンテンツ・ソース・ドキュメント内で定義される任意の機能またはその他のコードの前に置く。上記の通り、ＧＵＩを構成するＨＴＭＬドキュメントをプレビューするために、ＧＵＩは、従来のサーバおよびブラウザ（図１４）を用いてプロトタイプ化できる。したがって、使用の間にはダイナミックコンテンツが現れるがコンパイル済みのドキュメントには現れないロケーションにおいてページをプレビューするためのスタティックコンテンツを提供することは、有用である。例えば、そうでない場合にはＥＭＷＥＢ_ＳＴＲＩＮＧタグのメカニズムを用いて提供されるコンテンツのプロトタイプ値を含むことは、有用である。したがって、ＥmＷeb^TM コンパイラが認識するＨＴＭＬへの別の拡張は、図３に示す通り、ＥＭＷＥＢ_ ＰＲＯＴＯ開始３０９および終了３１１のタグである。ＥmＷeb^TMコンパイラは、ドキュメントをコンパイルするとき、これらのタグおよびそれらの間の全部を除去するが、直接にまたは従来のサーバによってＨＴＭＬドキュメントを調べる従来のブラウザでは、それらタグは無視され、それらのタグの間のテキストは正常に解釈される。従来のブラウザは特別のシンタクス、例えば“＜”、“＞”で囲まれることに起因してタグを認識するが、ブラウザが定義を持たないタグを無視して表示しないように設計されている。こうして、全部のＥmＷeb^TMコンパイラのＨＴＭＬ拡張は、従来のブラウザではスキップする。かくて、図３の例においては、プロトタイプ・ページは“ＮetＦax Ｓtate:Ｓending”を表示する。図４はＥＭＷＥＢ_ＰＲＯＴＯタグの同様の使用を示している。ここで、図９を参照しながら、ＥmＷeb^TMコンパイラによるＨＴＭＬフォームの取り扱いについて説明する。図９に示す通り、ＨＴＭＬフォームは実質上従来通りに定義する。このフォームで使用するネームは、ＥmＷeb^TMコンパイラが生成する出力ソースコード内で使用するシンボルネームを構成する際に使用する。したがって、ネームはソースコード言語での有効なシンボルネームでなければならない。フォーム定義のそれぞれのエレメントは、ＥmＷeb^TMコンパイラによって、当該フォームに対して定義された対応のデータ構造へ変換する。フォームデータは、データ構造内のアイテムの値を変えることによって、アプリケーション内へおよびアプリケーション外へ移動させる。図９の例に目を転じて、図示のＨＴＭＬフォームの定義とその対応のデータ構造との間の関係について説明する。ＦＯＲＭタグ内のＥＭＷＥＢ_ＮＡＭＥ属性を用いて、フォームに固有のネームを与える。フォームネームは、容易な参照および固有性のために、構造ネームの一部分となる。また、フォームネームは、フォームをサーブするときまたはフォームを提示するときにコールされる機能に関する機能ネームを生成するのにも用いる。生成された構造は、それ自体、２つの構造から成っている。第１の構造は、フォームのそれぞれのダイナミックエレメントの値を保持する。第２の構造は、対応する値のコンテンツのステータスを示すステータス・フラグを保持する。かくて、図９の例においては、sysＮame ＩＮＰＵＴおよびＬogging ＳＥＬＥＣＴio nに対する値およびステータスを保持する構造が作られる。sysＮameの値は文字ストリングであるが、Ｌoggingは列挙されたタイプである。また、２つの関数プロトタイプも生成する。これらの関数によって実行すべき動作は、開発者が定義しなければならない。Ｓerve関数は、フォームをサーブするときにコールし、そして例えばデフォルト値を供給するの使うことができる。Ｓubmit関数は、フォームを提出するときにコールして、例えば、データ構造内の値を更新する。現在、ＥmＷeb^TMコンパイラは、ＴＥＸＴ、ＰＡＳＳＷＯＲＤ、ＣＨＥＣＫＢＯＸ、ＲＡＤＩＯ、ＩＭＡＧＥ、ＨＩＤＤＥＮ、ＳＵＢＭＩＴ、ＲＥＳＥＴ、ＳＥＬＥＣＴおよびＯＰＴＩＯＮの入力フィールドをサポートする。詳細な説明については、テーブルＡのセクション3.2.5を参照されたい。更に、ＥmＷeb^TMコンパイラは、ＴＥＸＴ入力フィールド・データの“タイプ化(typing)”をサポートする。すなわち、ＥＭＷＥＢ_ＴＹＰＥ属性は、種々の整数、ドット状のＩＰアドレス（例えば、000.000.000.000のフォームのアドレス）、種々の他のアドレス・フォーマット等を含むように、ＴＥＸＴ入力フィールドを定義するのに使用する。ＥＭＷＥＢ_ＴＹＰＥの値のＣ言語タイプへのマッピングは、テーブルＡのセクション3.2.5.3で形成している。ＥmＷeb^TMコンパイラについて、汎用アプリケーション・ソースコード言語の用語で説明した。ＥmＷeb^TMコンパイラの現在の商用の実施例は、Ｃまたはそのスーパーセット、即ちＣ＋＋を汎用アプリケーション・ソースコード言語と仮定している。しかしながら、説明した機能は、特定のアプリケーションの目的に便利な任意の汎用アプリケーション・ソースコード言語に一般化できる。しかしながら、上述のＥmＷeb^TMコンパイラおよびＨＴＭＬ拡張が、どのようにしてＨＴＭＬで定義したＧＵＩとアプリケーション・ソースコードで定義したアプリケーションとを統合するかをより完全に理解するために、一般性を失わずに、汎用アプリケーション・ソースコード言語をＣまたはそのスーパーセットと仮定する。ＥmＷeb^TMコンパイラは、コンテンツ・アーカイブの固定的なデータを含むdat a.datファイルと、ＥＭＷＥＢ_ＳＴＲＩＮＧタグ、ＥＭＷＥＢ_ＩＮＣＬＵＤＥタグおよびＥＭＷＥＢ_ＨＥＡＤタグ内に定義された部分を含むアーカイブの生成されたソースコード部分とＥmＷeb^TMコンパイラによって生成された他のソースコードとを含むcode.cファイルと、並びに、フォームの処理に用いるＣ関数の定義を含むproto.hファイルおよびstub.cファイルとを含む、１組の出力ファイルを生成する。これらのファイルの構造は、図１０のデータストラクチャと関連して説明する。コンテンツ・アーカイブファイルdata.datは、図１０に示されたヘッダ・ストラクチャを有する。このデータストラクチャには、オフセットテーブル即ちアーカイブの他の部分へのポインタであるアーカイブヘッダ１００１を介してアクセスする。例えば、圧縮されたドキュメントを含む、アーカイブに対する圧縮辞書１００３へのポインタ１００１ａがある。ドキュメントヘッダ１００５、１００７および１００９のリンクしたリストへのポインタ１００１ｂもある。各ドキュメントヘッダ１００５、１００７および１００９は、オフセットテーブル即ちドキュメントの種々のコンポーネントへのポインタである。例えば、ドキュメントヘッダは、そのドキュメントが関連するＵＲＬ１０１１へのポインタ１００５ａを含む。多目的インターネットメール拡張（ＭＩＭＥ: Ｍultipurpose Ｉnterne t Ｍail Ｅxtensions）タイプのドキュメントを与えるフイールド１０１３へのポインタ１００５ｂもある。各々後述するヘッダノード１０１５およびドキュメントノード１０１７へのポインタ１００５ｃおよび１００５ｄもある。最後に、ドキュメントのスタティック部分を表現する圧縮あるいは非圧縮のスタティックデータ１０１９のブロックへのポインタ１００５ｅがある。スタティックデータは、ＥmＷeb^TMタグ、即ち上述しテーブルＡに詳細を定義したＨＴＭＬの拡張のどれも含まない。ドキュメント内で用いられたＥmＷeb^TM タグに関する情報は、むしろドキュメントノード・ストラクチャ内に現れる。ドキュメント内で用いル各ＥmＷeb^TMタグは、そのドキュメントのドキュメントノード・ストラクチャ内で、以下のように表す。非圧縮データブロックまたは圧縮データブロックの非圧縮のコピー内のＥmＷeb^TMタグのロケーションは、非圧縮データに関連してオフセット１０１７ａによって表す。タグのタイプは、タイプフラグ１０１７ｂによって表す。ノードには、表すタグに関連する任意の属性を表すフラグを含ませることができる。例えば、ＥＭＷＥＢ_ＳＴＲＩＮＧタイプのタグに対するノードは、ＥＭＷＥＢ_ＩＴＥＲＡＴＥ属性を表すフラグを含むことができる。最後に、ノードは、インデックス１０１７ｃを含む。フォームエレメントを定義するノード内においては、そのインデックスは、ドキュメント内のエレメントとフォームを一意に識別するフォーム番号とエレメント番号を保持する。ＥＭＷＥＢ_ＳＴＲＩＮＧタグを定義するノード内では、インデックスは、そのポイントで実行されるべきソースコードのインスタンスへの参照である。そのため、インデックスは、Ｃの“スイッチ”ステートメントの語句として評価でき、この場合、“スイッチ”ステートメントの各制御されるステートメントは、１つのＥＭＷＥＢ_ＳＴＲＩＮＧインスタンスからの１つのソースコード・フラグメントである。また代替的には、インデックスは、プライベート関数としてカプセル化したＥＭＷＥＢ_ＳＴＲＩＮＧタグからのソースコード・フラグメントテーブル内へのポインタまたはインデックスとすることができる。以上で定義したデータ構造は、ダイナミックコンテンツを含むドキュメントをサーブするときに制御を転送する便利な方法を提供する。ドキュメントが要求されると、ドキュメントノードのリストを獲得し、ＨＴＭＬソースドキュメント内に定義されていたコード・セグメントへ制御をどのポイントで転送すべきかを決定する。そしてそのドキュメントのスタティックエレメントを定義するデータブロックを用いて、各ドキュメントノードに遭遇するまで、ドキュメントをサーブする。各ドキュメントに遭遇すると、制御を適当なコード・セグメントへ転送する。コード・セグメントが実行を完了した後、後続のスタティックコンテンツを、次のドキュメントノードのオフセットに遭遇するまでサーブする。ヘッダノードは、コンテンツ言語（例えば英語、ドイツ語等）、クッキー制御、キャッシュ制御または、ドキュメントの固有のバージョン番号を与えるｅタグ、例えばドキュメントに対して計算した３０ビットのＣＲＣ値のような、そうでない場合には扱われないドキュメントのメタ情報の記憶を可能にする。全てのドキュメントがこの情報を必要とするとは限らないので、この情報を各ドキュメントのヘッダに置かねばならないのを避けることによって、アーカイブの空間を著しく節約することができる。したがって、ヘッダノードは、この情報を用いるドキュメントに対してのみ記憶するだけでよい。本発明のＥmＷeb^TMコンパイラの実施例が用いるコンテンツのアーカイブを表すデータ構造は、テーブルＢに含まれたＣのソースコードによって定義する。ランタイム環境ランタイム環境とサーバに関する本発明の種々の面は、セクション４のテーブルＡに詳細に定義したＥmＷeb^TMサーバにおいて実現している。ＨＴＴＰを実装した在来のブラウザに対して、ＥmＷeb^TMサーバは在来のように振る舞う。しかしながら、図２に示すように、ＥmＷeb^TMサーバは、アプリケーションと完全に統合しており、したがってそれが埋め込まれたアプリケーションおよびデバイスに関する情報に対するアクセスを有している。ダイナミックコンテンツの表示に関するＥmＷeb^TMサーバの動作は、図１１に関連して説明する。図１１に示した動作を始める前に、１つ以上のアーカイブをサーバがロードする。各アーカイブがロードされたとき、ドキュメントがＵＲＬを用いて容易に位置を見つけられるように、サーバは、アーカイブヘッダ・データ構造を用いてハッシュテーブルを生成する。まず、ブラウザが、ＨＴＴＰを用いて、指定したＵＲＬにあるドキュメントを要求する１１０１。ＥmＷeb^TMサーバは、その要求に対し、在来の方法で肯定応答する１１０３。そして、ＥmＷeb^TMサーバは、アーカイブヘッダのハッシュテーブルを用いて、要求されたドキュメントの位置を見つけ、そしてそのドキュメントからスタティックデータをサーブし始める１１０５。例えばＥＭＷＥＢ_ＳＴＲＩＮＧタグの表示で表されるドキュメントノードに遭遇すると、サーバは、制御をＥＭＷＥＢ_ＳＴＲＩＮＧタグ１１０７内に含められたアプリケーションのコード・フラグメント１１０７ａに渡す。このコード・フラグメントが実行を終了し、なんらかのダイナミックデータ１１０９を返すと、ＥmＷeb^TMサーバは、ブラウザにそのダイナミックデータをサーブする１１１１。そして、ＥmＷeb^TMサーバは、ドキュメント内に残っているスタティックデータのサーブを続ける１１１３。このプロセスは、全てのダイナミックエレメントを含む、全てのドキュメントをサーブするまで継続する。フォームのランタイムのサービングおよび提示について、図１２に関連して説明する。図１２の概観は、フォームのサービスと提示が、ダイナミックコンテンツのサービングに対するものと同様の線に沿って進むことを示している。まずブラウザは、ＨＴＴＰを用いてＵＲＬを要求する１２０１。要求されたＵＲＬのコンテンツのサービス中にフォームに遭遇すると、フォームのサービスとＨＴＭＬ定義のデフォルト値が正常に始まる。次に、ＥmＷeb^TMサーバは、アプリケーション・コードをコール１２０３して関数を実行させ１２０３ａ、そしてこれは、代替のデフォルト値をフォームを満たすべきものと置換するようにもできる。次に、サーブするドキュメントは、そのアプリケーションソフトウェアによって修正されたスタティックＨＴＭＬが定義するデフォルト値を含むようにされる１２０７。後に、ユーザがフォームを提示するとき、ブラウザは、ＨＴＴＰを用いてＵＲＬのＰＯＳＴを実行する１２０９。フォームデータがＥmＷeb^TMサーバにより関数へのコール１２１１によってアプリケーションに戻され１２１１、そしてその関数は、フォーム内の戻されたデータを、アプリケーション・コード内のそれに対し定義されたデータ構造内に挿入する。次に、応答１２１３を、ブラウザへサーブし戻す１２１５。最後に、ダイナミックコンテンツに対する要求が、アプリケーションが実行している他の処理を許容できない程に止めたり遅らせたりする、拡張処理を必要とするときがあることに注意されたい。このような問題を回避するために、ＥmＷe b^TMサーバは、以下のようなサスペンド／レジューム・プロトコルを実装している。このサスペンド／レジューム・プロトコルは、サーバが維持し実行するスケジューラの文脈内に存在する。スケジューラは、実行されるべきスケジュールされたサーバタスクのタスクリストを含む。図１３は、その処理が他のアプリケーションの動作と干渉すると予想される、ＥＭＷＥＢ_ＳＴＲＩＮＧタグを含むドキュメントをブラウザが要求する場合の状況を示す。ドキュメントに対する最初のＨＴＴＰ要求１３０１に対し、在来のように肯定応答する１３０３。ＥＭＷＥＢ_ＳＴＲＩＮＧタグに遭遇すると、制御をアプリケーション内の適当するソースコード・フラグメント１３０５ｂへ転送する１３０５ａ。そこで、アプリケーションは、ＥmＷebサーバのサスペンド関数１３０７をコールし、ＥＭＷＥＢ_ＳＴＲＩＮＧタグ位置において生成されたファンクションコールに、ダミー値１３０９を返す。サスペンド関数１３０７のコールは、スケジューラに、タスクリストからＥＭＷＥＢ_ＳＴＲＩＮＧ処理タスクを除去させる。アプリケーションが最終的にオリジナルのファンクションコールで要求されたダイナミックコンテンツを準備すると、アプリケーションはＥmＷeb^TMサーバのレジューム関数１３１１をコールする。レジューム関数をコールすると１３１１、ＥＭＷＥＢ_ＳＴＲＩＮＧにタスクリスト上のタスクを現在のタスクとして処理することを要求する。ＥmＷeb^TMサーバは、ＥＭＷＥＢ_ＳＴＲＩＮＧタグで定義された関数１３０５ｄを再度コールすること１３０５ｃによって応答し、このときは直ちにアプリケーションから応答を受け取り、この中で要求したダイナミックコンテンツ１３１３が返される。次に、このダイナミックコンテンツをブラウザにサーブする１３１５。このサスペンド／レジューム機能は、分散処理環境において特に有用である。分散処理環境の１つのプロセッサ上で埋め込み形のアプリケーションが動作しているとき、その分散環境内の他のプロセッサからしか得られないダイナミックコンテンツが要求された場合、サスペンド／レジューム機能を用いることによって、分散環境の通信経路を介してダイナミックコンテンツを得ることの必要性に基づくロックアップや処理の劣化を防ぐことができる。例えば、制御または管理プロセッサおよび種々の通信デバイスを含む分散システムを考えてみよう。管理プロセッサ上で実行されている埋め込み形のアプリケーションは、通信デバイスの任意のもののコンフィギュレーション・データについて問い合わせを受けることがある。サスペンド／レジューム機能がなければ、そのデータを得ることは、種々の通信デバイスの制御のため管理プロセッサが使用している通信経路を停止させ、処理性能を劣化させてしまう。本発明の記述した実施例は、その種々の利点を例示している。例えば、生め込み形アプリケーションは、これでＧＵＩをもつことができることになり、そしてこのＧＵＩは、ＧＵＩのビューを行うのに使用するもののアプリケーション・プラットフォームのいずれにも独立のものとなる。例えば、ＧＵＩは、在来のブラン，Ａpple Ｍacintosh，ＷebＴＶ box等を通して作動させることができる。また、埋め込み形アプリケーション用のＧＵＩの開発は、大幅に簡単になる。その外観および感触の設計は、在来のＨＴＭＬ設計技法（在来のクライアントサーバ・システムを使った外観および感触の直線的なプロトタイプ化、単純なＨＴＭＬ拡張を使用）を使用して行う。埋め込み形アプリケーションとの統合は、開発者が、どのような特別のインターフェースの学習あるいは開発を必要としないが、むしろ、ある種のＨＴＭＬ拡張を使って、アプリケーション・ソースコードをＨＴＭＬコンテンツ内に直接組み込む。さらに別の利点は、埋め込み形アプリケーション全体は、ＨＴＴＰ互換サーバおよびサーブすべきコンテンツとは、アプリケーション・ソースコード、スタティックデータ用のデータ構造、およびダイナミックデータ用のソースコードの最小限に低減させることができることである。以上、本発明について、その特定の実施例に関連して説明した。しかし、本発明の範囲内に入ると考えられる種々の変更が、当業者には明らかなはずである。例えば、本発明は、ＨＴＭＬをソースとするコンテンツに制限されるものではない。本発明の文脈の中で、任意のマークアップ言語を使用することができる。また代替的には、コンテンツ・ソースは、生のテキストとすることができ、これは、ユーザインターフェースの出力が１つ以上の自動的なソフトウェア・テキストフィルタによっても処理されるような状況では、特に適している。したがって、本発明の範囲は、添付の請求の範囲の記載の適正に解釈される範囲によってのみ、制限されることを意図している。

───────────────────────────────────────────────────── フロントページの続き (72)発明者ローレンス，スコット・ディーアメリカ合衆国マサチューセッツ州01742 −4042，コンコード，オールド・マールバロ・ロード 560

Claims

【特許請求の範囲】１．ダイナミックエレメントを有するグラフィカルユーザインターフェースを提供する方法であって、マークアップ言語で書かれた少なくとも１つのテキスト・ドキュメント内に前記グラフィカルユーザインターフェースのエレメントを定めるステップと、前記ドキュメント内のあるロケーションに、アプリケーション・ソースコードの１つのセグメントを含むコード・タグを含めるステップと、前記マークアップ言語を解釈するクライアントに対し、前記テキスト・ドキュメントをサーブするステップと、前記ロケーションに遭遇したときに、前記クライアントに対し、前記アプリケーション・ソースコード・セグメントが表す１つの命令シーケンスを実行した結果から得た１つの文字シーケンスをサーブするステップと、から成るグラフィカルユーザインターフェース提供方法。２．請求項１記載の方法であって、さらに、前記ドキュメント内に、アプリケーション・ソースコードの１つのセグメントを含む少なくとも１つの更なるコード・タグを含めるステップ、を含むこと、を特徴とするグラフィカルユーザインターフェース提供方法。３．請求項１記載の方法であって、さらに、前記グラフィカルユーザインターフェースを集合的に定める複数のドキュメントを提供するステップと、および前記テキスト・ドキュメントおよび前記複数のドキュメントを、ディレクトリ・ツリー内のファイルとして記憶するステップと、を含むこと、を特徴とするグラフィカルユーザインターフェース提供方法。４．請求項３記載の方法であって、さらに、前記ディレクトリ・ツリーおよび該ツリー内の前記ファイルをコンパイルして、コンテンツ・ソースを含むアーカイブにするステップと、および前記サーブするステップの前に、コンテンツ・ソースを前記テキスト・ドキュメントにデコンパイルするステップと、を含むこと、を特徴とするグラフィカルユーザインターフェース提供方法。５．ダイナミックエレメントを有するグラフィカルユーザインターフェースを提供する方法であって、マークアップ言語で書かれた少なくとも１つのテキスト・ドキュメント内に前記グラフィカルユーザインターフェースのエレメントを定めるステップと、前記ドキュメント内に、プロトタイプ・タグが識別するストリングを含めるステップと、前記マークアップ言語を解釈するプロトタイプ化・クライアントに対し前記テキスト・ドキュメントをサーブするが、前記プロトタイプ・タグを認識せずまた表示しないが、前記ストリングを表示するステップと、および前記テキスト・ドキュメントをコンテンツ・ソースにコンパイルし、前記プロトタイプ・タグとこれが識別した前記ストリングとを省略するステップと、から成るグラフィカルユーザインターフェース提供方法。６．請求項５記載の方法であって、さらに、前記ドキュメント内のあるロケーションに、アプリケーション・ソースコードの１つのセグメントを含むコード・タグを含めるステップであって、前記プロトタイプ化クライアントは、前記コード・タグを認識せずまた表示をしない、前記のステップ、を含み、前記さらに含むステップは、前記アプリケーション・ソースコード・セグメントを前記コンテンツ・ソース内に含めるステップ、を含むこと、を特徴とするグラフィカルユーザインターフェース提供方法。７．請求項６記載の方法であって、さらに、前記コンテンツ・ソースを前記テキスト・ドキュメントのレプリカにデコンパイルするステップと、前記レプリカをユーザ・クライアントにサーブするステップと、および前記レプリカ内の前記ロケーションに遭遇したときに、前記ユーザ・クライアントに対し、前記アプリケーション・ソースコード・セグメントを実行することにより発生された結果から得た１つの文字ストリームをサーブするステップと、を含むこと、を特徴とするグラフィカルユーザインターフェース提供方法。８．請求項７記載の方法であって、さらに、前記ドキュメント内に、アプリケーション・ソースコードの１つのセグメントを含む少なくとも１つの更なるコード・タグを含めるステップと、および前記ドキュメント内に、コード・タグが識別した少なくとも１つの更なるストリングを含めるステップと、を含むこと、を特徴とするグラフィカルユーザインターフェース提供方法。９．ダイナミックエレメントを有するグラフィカルユーザインターフェースを提供する方法であって、マークアップ言語で書かれた少なくとも１つのテキスト・ドキュメント内に前記グラフィカルユーザインターフェースのエレメントを定めるステップと、前記ドキュメント内のあるロケーションに、アプリケーション・ソースコードの１つのセグメントを含むコード・タグを含めるステップと、前記ドキュメント内に、プロトタイプ・タグが識別するストリングを含めるステップと、前記テキスト・ドキュメントをコンテンツ・ソースにコンパイルするステップと、前記コンテンツ・ソースを前記テキスト・ドキュメントのレプリカにデコンパイルするステップと、前記テキスト・ドキュメントの前記レプリカを、前記マークアップ言語を解釈するクライアントにサーブするステップと、および前記レプリカ内の前記ロケーションに遭遇したときに、前記クライアントに対し、前記アプリケーション・ソースコード・セグメントを実行することにより発生された結果から得た１つの文字ストリームをサーブするステップと、から成るグラフィカルユーザインターフェース提供方法。１０．請求項９記載の方法であって、さらに、前記ドキュメント内に、アプリケーション・ソースコードの１つのセグメントを含む少なくとも１つの更なるコード・タグを含めるステップと、および前記ドキュメント内に、コード・タグが識別した少なくとも１つの更なるストリングを含めるステップと、を含むこと、を特徴とするグラフィカルユーザインターフェース提供方法。１１．媒体に記録したソフトウェア製品であって、マークアップ言語のドキュメントをネイティブ・アプリケーションプログラミング言語のデータ構造にコンパイルできるマークアップ言語コンパイラを含み、該コンパイラは、前記ネイティブ・アプリケーションプログラミング言語のコンパイラによるコンパイルのためのファイルでセーブされるべきアプリケーション・ソースコードの１つのセグメントとして、含まれるテキストを指定する１つ以上のコード・タグを認識すること、を特徴とするソフトウェア製品。１２．データのエントリのため表示されたフォームを有するグラフィカルユーザインターフェースを提供する方法であって、マークアップ言語で書かれた少なくとも１つのテキスト・ドキュメント内に前記グラフィカルユーザインターフェースのエレメントを定めるステップと、前記ドキュメント内で、ユーザから要求されまたネイティブ・アプリケーションプログラミング言語で書かれたアプリケーションが使用するデータアイテムをネーミングするステップと、および前記テキスト・ドキュメントを、前記ネーミングしたデータアイテムに関し前記ネイティブ・アプリケーションプログラミング言語でのデータ構造定義を含むコンテンツ・ソースにコンパイルするステップと、から成るグラフィカルユーザインターフェース提供方法。１３．請求項１２記載の方法であって、前記テキスト・ドキュメントは、開発の間はプロトタイプ・クライアントを使ってビューを行い、使用の間はユーザ・クライアントを使ってビューを行い、さらに、前記プロトタイプ・クライアントおよび前記ユーザ・クライアントの両方によるビューを行うため、前記マークアップ言語で理解されるタグ内の前記データアイテムをネーミングするステップと、および前記コンテンツ・ソース内に、前記コンテンツ・ソースをサーブするときに前記データアイテム用のデフォルト値を与える関数の定義を含め、また前記データアイテムを前記ユーザ・クライアントが返すときにアプリケーション特有の動作実行する関数の定義を含めるステップと、を含むこと、を特徴とするグラフィカルユーザインターフェース提供方法。１４．アプリケーション用のグラフィカルユーザインターフェースを開発するためのコンピュータをベースとする装置において、該装置が、マークアップ言語で書かれたドキュメントを操作することができるエディタと、前記マークアップ言語で書かれたドキュメントを表示することができるビューアとを備え、前記装置がさらに、ネイティブ・アプリケーション・ソースコード言語のソースコード・フラグメントを含むコード・タグを認識するマークアップ言語コンパイラであって、前記コード・タグは、他の場合には前記マークアップ言語の１部分ではなく、前記コンパイラは、前記ソースコード・フラグメントのコピーを含む前記ドキュメントの前記ネイティブ・アプリケーション・ソースコード言語での表現を出力として発生すること、を特徴とするコンピュータ・ベースの装置。１５．請求項１４記載の装置であって、前記マークアップ言語コンパイラは、さらに、他の場合では前記マークアップ言語の１部分ではない開始プロトタイプ・タグと終了プロトタイプ・タグを認識し、前記出力の表現は、前記開始プロトタイプ・タグおよび前記終了プロトタイプ・タグ並びに前記ドキュメント内のそれらの間に現れる全てのコンテンツを省略すること、を特徴とする装置。１６．アプリケーション用のグラフィカルユーザインターフェースを開発しプロトタイプ化する方法であって、ＨＴＭＬファイルにアクセスするステップと、前記ＨＴＭＬの各部分をカプセル化して、その中にソースコードを入れるステップと、カプセル化した部分をもつ前記ＨＴＭＬからソース・モジュールを発生するステップと、サーバ用のソースコードを発生するステップと、前記アプリケーションをクロスコンパイルしリンクするステップであって、これにより前記ソースコード・モジュールと前記サーバとは実行可能なオブジェクトコードを発生する、前記のステップと、から成る方法。１７．請求項１６記載の方法であって、さらに、前記オブジェクトコードを走らせるステップと、ビューアにより要求されたときに前記のコンパイルしたカプセル化したコードを実行するステップであって、前記カプセル化したコードは前記アプリケーションに関連している、前記のステップと、を含むこと、を特徴とする方法。１８．請求項１７記載の方法であって、さらに、前記コンパイルしたカプセル化したコードの実行により返されたデータを、前記ビューアが表示可能なフォームに変換するステップ、を含むこと、を特徴とする方法。１９．請求項１８記載の方法であって、さらに、前記コンパイルしたカプセル化したコードの実行により返された前記データは、前記アプリケーション内の変化の結果として時間中変化すること、を特徴とする方法。２０．コンピュータ読み取り可能媒体に固定したデータ構造であって、前記データ構造は、互いに通信するクライアントおよびサーバを含むコンピュータシステムにおいて使用するためのものであり、前記データ構造が、前記アプリケーションに関連した実行可能なコード、サーバ・コード、アプリケーション・コードを含むカプセル化した各部分をもつ、クロスコンパイルし、記憶し、リンクしたＨＴＭＬファイルであって、前記実行可能なコードは、前記ＨＴＭＬファイルをサーブしたときに走らせ、これにより、前記アプリケーションに関連したリアルタイム・ダイナミック・データを提供する、前記のＨＴＭＬファイル、を含むこと、を特徴とするデータ構造。