(57)【要約】【課題】  分散情報処理および記憶システムにおいて、ウェブサイトサマリーのリソース記述フレームワーク・サイト・サマリー（resource Description Framework Site Summary（ＲＳＳ））フォーマットから変換済みフォーマットへの変換の方法を提供する。【解決手段】本方法は、スタイルシートを定義することと、ウェブサイトのＵＲＬを識別すること、およびウェブサイトサマリーに対して初期および変換済みフォーマットを定義すること、を含む。本方法は、さらに、ウェブページに、定義済みスタイルシートと、初期および変換済みフォーマットと、ＵＲＬと、を挿入すること、およびウェブページにおいて、挿入されたスタイルシートと、初期および変換済みフォーマットと、ＵＲＬと、が見つけられた場合に、変換を実行すること、を含む。【選択図】図１
2004334866.tif 000002
【特許請求の範囲】
【請求項１】
分散情報処理および記憶システムにおいて、リソース記述フレームワーク・サイト・サマリー（ＲＳＳ）フォーマットから変換済みフォーマットへのウェブサイトサマリーの変換の方法であって、
スタイルシート（２１０）を定義すること（１０１）と、
前記ウェブサイトのＵＲＬ（２０２）を識別すること（１０２）と、
前記ウェブサイトサマリー（２０３）に対して初期（２０５）および変換済み（２０６）フォーマットを定義すること（１０２）と、
ウェブページ（２０１）に、前記定義済みスタイルシート（２１０）と、前記初期（２０５）および変換済み（２０６）フォーマットと、前記ＵＲＬ（２０２）とを挿入することと、
前記ウェブページ（２０１）において、前記挿入されたスタイルシート（２１０）と、前記初期（２０５）および変換済み（２０６）フォーマットと、前記ＵＲＬ（２０２）とが見つけられた場合に、前記変換を実行することと
を含むウェブサイトサマリーの変換の方法。
【請求項２】
前記スタイルシート（２１０）と、前記初期（２０５）および変換済み（２０６）フォーマットと、前記ＵＲＬ（２０２）とをタグ（２１１、２１２）を介して挿入する
請求項１に記載のウェブサイトサマリーの変換の方法。
【請求項３】
前記ウェブページ（２０１）に挿入された前記スタイルシート（２１０）と、前記初期（２０５）および変換済み（２０６）フォーマットと、前記ＵＲＬ（２０２）とを、クライアント要求に応じて、アプリケーションサーバが逐次見つける
請求項２に記載のウェブサイトサマリーの変換の方法。
【請求項４】
前記タグ（２１１、２１２）を、タグライブラリ（タグリブ）（２１５）に格納する
請求項２に記載のウェブサイトサマリーの変換の方法。
【請求項５】
前記定義済みスタイルシート（２１０）は、拡張可能スタイルシート言語（ＸＳＬ）（２１０）を使用する
請求項１に記載のウェブサイトサマリーの変換の方法。
【請求項６】
前記変換済みフォーマット（２０６）を、ハイパーテキストマークアップ言語（ＨＴＭＬ）と、無線マークアップ言語（ＷＭＬ）と、Ｊａｖａ（商標）コードと、プレーンテキストと、音声（２０６）とから構成されるグループから選択する
請求項１に記載のウェブサイトサマリーの変換の方法。
【請求項７】
前記実行することは、
前記ウェブサイトサマリー（２０３）を、ＸＳＬ（２１０）を使用して、リソース記述フレームワーク・サイト・サマリー（ＲＳＳ）（２０５）フォーマットから前記変換済みフォーマット（２０６）に変換すること
を含む
請求項１に記載のウェブサイトサマリーの変換の方法。
【請求項８】
分散情報処理および記憶システムであって、
ウェブブラウザ（２００）と、
該ウェブブラウザがＵＲＬ（２０２）を介してアクセス可能なコンテンツ（２０４）に関連するウェブサイトサマリー（２０３）と、
該ウェブサイトサマリー（２０３）を初期ＲＳＳ（２０５）フォーマットから変換済みフォーマット（２０６）に変換するように動作可能なスタイルシート（２１０）と、
前記ウェブブラウザ（２００）により通信によってアクセス可能であり、前記スタイルシート（２１０）と、前記ＵＲＬ（２０２）を介して前記ウェブサイトサマリー（２０３）と、前記初期ＲＳＳ（２０５）フォーマットと、前記提示フォーマット（２０６）とを指定するように動作可能な挿入された命令を含むウェブページ（２０１）と
を具備する分散情報処理および記憶システム。
【請求項９】
前記命令を前記ウェブページ（２０１）に挿入するように動作可能なタグ（２１１、２１２）
をさらに具備する請求項８に記載の分散情報処理および記憶システム。
【請求項１０】
前記タグ（２１１、２１２）を格納するように動作可能なタグライブラリ（タグリブ）（２１５）
をさらに具備する請求項９に記載の分散情報処理および記憶システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散情報処理および記憶システムにおけるタグリブを介したウェブサイトサマリの変換に関する。
また、本出願は、「APPEARANCE PROPERTIES FOR WEB BASED APPLICATIONS USING TAGLIBS」と題する、同時係属で同時出願の本願と同一の譲受人に譲渡された米国特許出願第１０／４３４，０４５号と、「RPC TYPE SOAP SERVICE ACCESS VIA TAGLIBS FOR DYNAMIC WEB CONTENT」と題する同第１０／４３１，９３８号と、に関連する。
【背景技術】
【０００２】
クライアント／サーバコンピューティングは、２つ以上のエンティティが所与の問題の解決に参加するプログラミングモデルである。
クライアントは、解決を必要とするエンティティであり、サーバは、（通常は、一部クライアントから）十分な情報が与えられると回答を提供することができるエンティティである。
たとえば、Ｙａｈｏｏ（商標）のようなインターネットポータルの一部等のクライアントは、ユーザのポートフォリオを表示するために、会社の株式の時価を必要とする。
Ｎａｓｄａｑ（商標）またはＮＹＳＥ等のサーバは、クライアントが当該会社の銘柄記号を提供することができる限り、回答を提供することができる。
クライアントは、ソフトウェアエンティティ（ハードウェア上で実行する）であり、別のソフトウェアエンティティ（同様に何らかのハードウェア上で実行する）であるサーバといかに接触するかを知っており、銘柄記号等の十分な情報を提供し、回答、たとえば時価を受取る。
【０００３】
クライアント／サーバコンピューティングは、常にではないがしばしば分散している。
分散シナリオでは、その間隙を埋めるために、電話または電子メール等のオプションがある。
電話と電子メール通信とは、機能的には等価であるが、異なるプロトコルを用いる。
【０００４】
クライアントおよびサーバの１つの望ましい属性は、それらがプロトコル依存である、ということである。
上記例では、電話または電子メール通信に使用されるプロトコルに適応するのは、技術的にクライアントおよびサーバである。
クライアント／サーバコンピューティングでは、プロセスにプロキシが必要である場合が多い。
クライアントはアシスタントに質問を提示し、アシスタントはサーバアシスタントに連絡を取り、サーバアシスタントはその質問をサーバに提示する。
そして、回答は、同じルートを反対方向に戻ってくる。
この例のアシスタントは、クライアントおよびサーバプロトコルを独立させるプロキシであると定義され、すなわち、プロキシはプロトコルを操作する。
クライアントもサーバも、通信が電話によって行われたか、ファックスによって行われたか、あるいは電子メールによって行われたかを知る必要がなく、そのためプロトコルは両者に対して完全に透過的である。
【０００５】
サーバ自体もまたクライアントである場合が多い。
サーバは、仮定として、回答を知らなかった場合、その回答を他のもの、たとえば第三者の専門家から得ることができる。
重要なことは、クライアントがこの第２のクライアント／サーバ媒介者に気がつかない、ということである。
クライアントおよびサーバは、幾分不透明なエンティティであってもよいが、すべて比較的単純な方法で機能し、プロキシとプロトコルの特定のセットとを使用して情報を交換する。
【０００６】
ある程度一般に信じられているのとは裏腹に、インターネットはそれ自体単一ネットワークではなく、むしろ、相互接続されている別個のネットワークの巨大な集合体であり、クライアントがいずれにあるサーバにも達することができるようにする（サーバは、クライアントに「話しかける」ことを望まない場合があり、あるいはそれらが同じプロトコルを共有しない場合もある）。
【０００７】
インターネットの典型的な使用において、ユーザは、インターネット上で入手可能な情報を必要とする（たとえば、会社の住所または電話番号）。
クライアントは、略常にウェブブラウザ、たとえばＩｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ（商標）、Ｎｅｔｓｃａｐｅ（商標）またはＯｐｅｒａである。
ユーザの観点から、ブラウザは、ユーザのＰＣ、Ｍａｃ（商標）またはＵＮＩＸ（商標）／Ｌｉｎｕｘ（商標）ボックス上で実行するよくあるアプリケーションである。
コンピューティングの見地から、ブラウザは実際にはクライアントである。
【０００８】
サーバは、この例では、概して、通常会社または組織の構内で、またはサービスプロバイダにおいて、ＭｉｃｒｏｓｏｆｔのＩＩＳ（Internet Information Server（インターネット情報サーバ））、Ａｐａｃｈｅまたは他の何らかの等価物等のウェブサーバである。
クライアントおよびサーバ（またはそれらのプロキシ）は、プロトコルおよび言語に合意することができない限り、通信することができない。
インターネット上で圧倒的にもっとも使用されるプロトコルは、伝送制御プロトコル／インターネットプロトコル（Transmission Control Protocol/Internet Protocol（ＴＣＰ／ＩＰ））に基づいて低レベルプロトコルを実行するＨＴＴＰ（HyperText Transfer Protocol（ハイパーテキスト転送プロトコル））である。
ＨＴＴＰは、現文書を「離れる（leave）」ことなく追加の情報にシームレスにリンクするためにデジタル文書に「ハイパーリンク（hyperlink）」を埋め込んだ「ハイパーテキスト(hypertext）」の使用を可能にする手段として考えられていた。
このメカニズムは依然として、人間のユーザに関する限りインターネットの中心であり、文書は、何らかの方法で現文書に関連する（と期待される）他の文書へのリンクを含む。
【０００９】
サーバは、潜在的に多くのことを行うことができるため、ブラウザをwww.company-name.comに向けることにより、他の情報へのアクセス、電子商取引等を提供するそれらの「ホームページ」または何らかのポータル状画面が得られる。
しかしながら、単純で小さいＰＣベースのサーバでさえ、何千もの文書およびハイパーリンクをホストすることができるため、これらの資源に対して一様に位置を特定するためにはより粒度の高い方式が必要である。
ＵＲＬ（Uniform Resource Locator（ユニフォーム・リソース・ロケータ））は、（しばしば長たらしい）完全なアドレス名である。
ブラウザおよびサーバは、デフォルト情報（ホームページ等）を取得するための詳細の大部分を軽減するのを助けることができる場合が多いが、特定の文書の場合、完全なＵＲＬを指定しなければならない。
【００１０】
すべてのＵＲＬは、いくつかの部分から構成される。
１．プロトコル（ＨＴＴＰ等）
２．サーバ名（またはＴＣＰ／ＩＰアドレス）（www.hp.com等）
３．サーバポート番号（通常８０）
４．文書（またはindex.html等のリソース）の名前
【００１１】
このため、非常に簡単なＵＲＬは、次のようなものである。
http://www.hp.com/index.html
【００１２】
各プロトコルがデフォルトを有することからポート番号を省略したため、ＨＴＴＰに対し実際のＵＲＬは、
http://www.hp.com:80/index.html
である。
【００１３】
テキストのこの単純なストリングを使用することで、ブラウザに対し以下を行うように命令する。
１．ＨＴＴＰプロトコルを使用する。
２．ダイナミック・ネーミング・サービス（Dynamic Naming Service（ＤＮＳ（商標））に行き、www.hp.comのＴＣＰ／ＩＰアドレスを見つける。
３．そのアドレスのサーバに対しポート８０でＴＣＰ／ＩＰネットワークコネクションを開く。
４．それに対してindex.htmlと呼ぶ文書を要求する。
５．その文書を表示する。
【００１４】
静的コンテンツは、単純にファイルから読出されたコンテンツである（Ｗｉｎｄｏｗｓ（商標）のＷｏｒｄのように、たとえば\My Documents\SomeLetter.docからＷｏｒｄ文書を読出すことができ、ウェブサーバは、その文書をたとえばindex.htmlから読出すことができる）。
静的コンテンツとは、誰が文書を要求しているかに係らず、それが読出され送信される同じ文書であることを意味し、それはウェブサーバ上のファイルに存在するため、めったに変化しない。
ほとんどの人は、ウェブサイトに行きページのボタン上の通知、すなわち最終更新日ｘｘ／ｘｘ／ｘｘを見る。
静的コンテンツは、潜在的に大量の事実（またはその事柄に対する意見）を格納し容易に入手可能とする必要がある、百科事典データに適している。
コンテンツおよび文書は、サーバのハードドライブ上のディレクトリにあるファイルのセットである。
これらのファイルは、慣習的なまたは他の理由でＨＴＭＬフォーマットである、ブラウザがそれらを表示するために必要とする情報を含む。
文書の実際のコンテンツは、パラグラフ、フォント、テーブル等のフォーマットを指定するために「マークアップ」されてきた。
【００１５】
以下のＨＴＭＬ
<html>
<head>
<title>ＨＴＭＬへようこそ！</title>
</head>
<body>
<h2>ＨＴＭＬの世界へようこそ。</h2>
<p>あなたのウェブブラウザで見えるものはすべて、このような内容からなります。…
</body>
</html>
がＷｉｎｄｏｗｓ（商標）メモ帳（Notepad）にタイプ入力されwelcome.html等のファイルに保存された場合、そのファイルをダブルクリックすることにより、Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ（商標）は、開いてタイトルバーに「ＨＴＭＬにようこそ！」という語で
ＨＴＭＬへようこそ！
と表示し、マークアップは文書において、Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ（商標）の場合のように、ブラウザに対してそれをいかにフォーマットするかを命令する。
Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ（商標）を右クリックし「ソースの表示」メニュー項目を選択することにより、メモ帳はマークアップを含むすべてを開いて示す。
【発明の開示】
【発明が解決しようとする課題】
【００１６】
しかしながら、静的コンテンツには限界がある。
すなわち、確かに、静的コンテンツを使用して天気を提示することはできず、それを使用して電子商取引サイトを構築することはできないため、異なる技術が必要である。
手近の技術は、複数のプログラミングモデルおよび言語を使用して行うことができる動的コンテンツ生成である。
動的コンテンツは、実際の要求に応じて要求時に作成される場合が多く、株価の例をとると、それは、人が１時間前の古い相場または昨日の相場ではなく、最新の相場を欲する場合である。
【００１７】
ウェブ要求は、クライアントがＵＲＬを送信し、サーバがファイルからマークアップテキストを読出してそれをクライアントに返信することに過ぎない。
重要なことは、クライアント、たとえばＩｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ（商標）が、サーバがどこからＨＴＭＬを取得するかを知らずまた関心を持たない、ということである。
したがって、ウェブサーバは、それをファイルから読出す必要はないが、どこからでも取得することができる。
【課題を解決するための手段】
【００１８】
本明細書で開示する一実施形態では、分散情報処理および記憶システムにおいて、ウェブサイトサマリーのリソース記述フレームワーク・サイト・サマリー（resource Description Framework Site Summary（ＲＳＳ））フォーマットから変換済みフォーマットへの変換の方法を提供する。
本方法は、スタイルシートを定義することと、ウェブサイトのＵＲＬを識別すること、およびウェブサイトサマリーに対して初期および変換済みフォーマットを定義すること、を含む。
本方法は、さらに、ウェブページに、定義済みスタイルシートと、初期および変換済みフォーマットと、ＵＲＬと、を挿入すること、およびウェブページにおいて、挿入されたスタイルシートと、初期および変換済みフォーマットと、ＵＲＬと、が見つけられた場合に、変換を実行すること、を含む。
【００１９】
本明細書で開示する別の実施形態では、分散情報処理および記憶システムを提供する。
本システムは、ウェブブラウザと、ウェブブラウザがＵＲＬを介してアクセス可能なコンテンツに関連するウェブサイトサマリーと、ウェブサイトサマリーを初期ＲＳＳフォーマットから変換済みフォーマットに変換するように動作可能なスタイルシートと、を備える。
本システムは、さらに、ウェブブラウザにより通信によってアクセス可能であり、スタイルシートと、ＵＲＬを介してウェブサイトサマリーと、初期ＲＳＳフォーマットと、提示フォーマットと、を指定するように動作可能な挿入された命令を含むウェブページと、を備える。
【００２０】
本明細書で開示する別の実施形態では、分散情報処理および記憶システムを提供する。
本システムは、スタイルシートを定義する手段と、ウェブサイトのＵＲＬを識別する手段と、上記ウェブサイトのウェブサイトサマリーに対して初期および変換済みフォーマットを定義する手段と、を備える。
本システムはさらに、ウェブページに、定義済みスタイルシートと、初期および変換済みフォーマットと、ＵＲＬと、を挿入する手段を備える。
本システムはさらに、ウェブサイトサマリーの初期フォーマットから変換済みフォーマットへの変換を実行する手段を備える。
【００２１】
本明細書で開示する別の実施形態では、コンピュータ読取可能媒体に格納されたコンピュータ実行可能ソフトウェアコードを提供する。
本コンピュータ実行可能ソフトウェアコードは、スタイルシートを定義するコードと、ウェブサイトのＵＲＬを識別するコードと、ウェブサイトのウェブサイトサマリーに対して初期および変換済みフォーマットを定義するコードと、を含む。
本コンピュータ実行可能ソフトウェアコードはさらに、ウェブページに、定義済みスタイルシートと、初期および変換済みフォーマットと、ＵＲＬと、を挿入するコードと、ウェブサイトサマリーの初期フォーマットから変換済みフォーマットへの変換を実行するコードと、を含む。
【発明を実施するための最良の形態】
【００２２】
ほとんどのインターネット規格は、比較的古く、長い間に発達してきた。
多くのかかる規格が、表面的な意味で不可解で効果的でなく未熟であるように見える場合があるが、インターネットはそのように分散され多様化されているため、これらの規格を変更することは厄介で時間のかかるプロセスである。
【００２３】
アプリケーションサーバは、アプリケーションを展開することができるソフトウェアであり、それによりこれらのアプリケーションは、ユーザが誰であるかと、要求において何の情報が提供されたか、すなわちＵＲＬおよびたとえばユーザが入力したフォームと、に基づいて、ＨＴＭＬを動的に生成することができる。
この一例は天気アプリケーションであり、そこでは、ユーザは、たとえば自身の郵便番号を入力し、天気アプリケーションは、次の数日に亙りその地域の天気予報を取得する。
明らかに、静的コンテンツを使用してこのアプリケーションを実施しようとすることは厄介であるが、情報を取得することができるアプリケーションサーバは、ユーザ要求に応じてコンテンツを動的に生成することができる。
株価は、同様のガイドラインを辿り、電子商取引アプリケーションは、ユーザが何を購入することに興味を抱いているかに基づき、たとえばユーザのショッピングカートおよび恐らくは先の注文を示して、コンテンツを生成する。
【００２４】
アプリケーションサーバは、Ｗｉｎｄｏｗｓ（商標）ＰＣ、ＵＮＩＸ（商標）／Ｌｉｎｕｘ（商標）サーバおよびＩＢＭメインフレームコンピュータ等の種々の異なるコンピューティングシステムで実行する複雑なソフトウェアである。
アプリケーションサーバは、１）Ｗｉｎｄｏｗｓ（商標）ＩＩＳベース（基本的にＭｉｃｒｏｓｏｆｔ．Ｎｅｔ）と、２）Ｊａｖａ（商標）Ｊ２ＥＥベースと、３）Ａｐａｃｈｅプラグインベースと、のカテゴリに分類される。
Ｊ２ＥＥは、Ｊａｖａ（商標）バージョン２Ｅｎｔｅｒｐｒｉｓｅ  Ｅｄｉｔｉｏｎを表し、単に、エンタープライズコンピューティングに使用される標準Ｊａｖａ（商標）コンポーネントのセットである。
Ｊ２ＥＥアプリケーションサーバは、Ｊａｖａ（商標）プログラミング言語で書かれたアプリケーションを展開することができ、ユーザがＩｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ（商標）またはＮｅｔｓｃａｐｅ（商標）等のウェブブラウザを使用してアクセスすることができる、規格準拠の大型で複雑なソフトウェアである。
ユーザの体験は、本質的に静的コンテンツの上記例と同様であり、ユーザはＵＲＬをタイプ入力するかまたはハイパーリンク（ＵＲＬを含む）をクリックし、ブラウザが表示する（通常）ＨＴＭＬ文書のフォームで応答を受取る。
相違は、当該ＨＴＭＬは、静的コンテンツの例のようにファイルからもたらされたのではなく、アプリケーションが動的に生成したものである、ということである。
【００２５】
通常のアプリケーションサーバは、いくつかのアプリケーションを一度に展開することを可能にし、いかなる数（一定の実際的な限界内）のユーザも、アプリケーションのいずれとも同時に対話することができ、たとえば、別のユーザがＹａｈｏｏ（商標）上で局所的な天気をチェックしている間に、Ｙａｈｏｏ（商標）上で株式ポートフォリオを受取ることができる。
【００２６】
ウェブアプリケーションは、通常、１）画像および恐らくはＨＴＭL等の静的コンテンツと、２）Ｊａｖａ（商標）クラスファイルとして知られるアプリケーションコードと、３）ＪＳＰ（商標）ファイルの（通常）ＨＴＭＬマークアップ（後により詳細に説明する）とともに、アプリケーションコードと、４）種々様々な構成情報と、等を含む、ファイルのセットである。
【００２７】
ウェブアプリケーションは、しばしば、ディレクトリ（またはフォルダ）、たとえばレターフォルダ、クライアントフォルダ等に編成されることにより、ファイルをそれらが適合するカテゴリに基づいて配置する。
Ｏｕｔｌｏｏｋ（商標）等の通常の電子メールシステムはまた、ユーザに、フォルダを作成させ電子メールをそれら電子メールシステムに移動させる。
Ｏｕｔｌｏｏｋ（商標）は、実際には、ハードドライブに、指定されたフォルダ名に一致するディレクトリを作成する。
天気と呼ばれる通常のウェブベースアプリケーションでは、画像のセットは、現曇天レベル（すなわち、曇り、ほとんど曇り、ほとんど晴れ、晴れ）を示してもよい。
天気アプリケーションは、天気予報を受取ると、曇天の予報レベルを、適当な画像ファイルへのＨＴＭＬリンクに変換する。
たとえば、予報における「晴れ」という用語を、ファイル/images/sunny.gifに変換することができる。
【００２８】
以下のＵＲＬは、実際に、ほとんど晴れと推測される、ニュージャージー州Mt.Laurelの金曜日のＹａｈｏｏ（商標）予報から取っている。
<IMG SRC="http://us.i1.yimg.com/us.yimg.com/i/us/we/52/34.gif"width=52
height=52 alt="ほとんど晴れ"border=0>
【００２９】
<img>マークアップは、ウェブブラウザに対してsrc="..."によって指定されるＵＲＬに行きそれが引出す画像を表示するように命令するＨＴＭＬである。
alt="..."は、カーソルが像の上にある時にポップアップする「ツールチップ（tooltip）」、この場合は「ほどんど晴れ」を指定する。
実際のＵＲＬとディレクトリ名および画像名は、実際のサーバおよびアプリケーションによって決まる。
【００３０】
この例での画像は34.gifである。
gifは、すべてのブラウザが認識する非常に広く使用される画像フォーマットであるＧｒａｐｈｉｃｓ  Ｉｎｔｅｒｃｈａｎｇｅ  Ｆｏｒｍａｔ（商標）を表す。
他の２つのコンピュータフォーマットは、.pngおよび.jpgである。
【００３１】
ウェブサーバとアプリケーションサーバとはともに、ＨＴＭＬテキスト文書と非テキスト画像ファイルとの両方を返すことができる。
実際には、ウェブサーバとアプリケーションサーバとは、Ｗｏｒｄ文書、ＭＰ３（商標）音楽ファイル、映画、ＰＤＦファイル等を含む、いかなる種類のファイルをも返すことができる。
ＨＴＭＬ文書は非常に大きい場合が多い。
たとえば、上述したＹａｈｏｏ（商標）天気ページは、約３６０００キャラクタである。
これらのページを作成することは、静的であっても動的であっても、時間がかかる可能性がある。
【００３２】
静的ＨＴＭＬコンテンツは、ウェブ設計の専門家によって書かれる場合が多い。
上記例の場合のように単純なページを書くのは容易であるが、有用なうまくレイアウトされたページを作成するのは芸術形式である。
優れたウェブページ設計者は、優れたソフトウェア開発者であることはめったになく、優れたソフトウェア開発者は、優れたウェブページ設計者であることはめったにない。
Ｊａｖａ（商標）コードの以下の抜粋は、現在時刻が正午より前か後かにより「おはようございます」かまたは「こんにちは」のいずれかでユーザに挨拶する、単純なウェブページを生成する。
Writer writer=response.getWriter();
writer.println("<html>");
writer.println("\t<head>");
writer.println("\t\t<title>挨拶</title>");
writer.println("\t</head>");
writer.println("\t<body>");
Date date=new Date();
if(date.getHours()<12){
writer.println("<p>おはようございます！");
}else{
writer.println("<p>こんにちは！");
}
writer.println("\t</body>");
writer.println("</html>");
【００３３】
ＨＴＭＬの編集は努力を要する可能性があるが、Ｊａｖａ（商標）コードに関連して厄介になるため、よりすぐれた容易な方法が必要であった。
ＪａｖａＳｅｒｖｅｒ  Ｐａｇｅ（ＪＳＰ（商標））は、まさに通常の静的ＨＴＭＬファイルのような単純なテキストファイルであるが、それらを最初に処理して実行することができるように、それらを直接クライアントに送信するウェブサーバではなく、Ｊ２ＥＥアプリケーションサーバが必要である。
これが意味することは、ＪＳＰ（商標）ページはＨＴＭＬを越えるものである、ということであり、Ｊａｖａ（商標）とＨＴＭＬとの間隙を都合よく埋めるが、それはＪａｖａ（商標）開発者の観点からではなくＨＴＭＬ著者の観点からである。
【００３４】
上記挨拶例を、ＪＳＰ（商標）において次のように表すことができる。
<html>
<head>
<title>挨拶</title>
</head>
<body>
<p>
<%
Date date=new Date();
if(date.getHours()<12){
out.println("おはようございます！");
}else{
out.println("こんにちは！");
}
%>
</body>
<html>
【００３５】
ＪＳＰ（商標）により、<%および%>マークアップを使用してＪａｖａ（商標）コードを通常のＨＴＭＬマークアップ内に埋込むことができる。
ウェブブラウザは、これを未処理のまま受取った場合、理解しない。
このため、アプリケーションサーバは、ＪＳＰ（商標）を、実行することができる前に処理する必要があり、その実行の結果は、埋込まれたＪａｖａ（商標）コードからの出力（すなわち、「おはようございます！」または「こんにちは！」）とともに生マークアップである。
最終結果は、ウェブブラウザが、ＨＴＭＬがファイルからもたらされるようなまさに同じ方法で理解し表示することができる、ＨＴＭＬ文書である。
【００３６】
ＪＳＰ（商標）は、Ｊａｖａ（商標）コードより作成および変更が容易な規模であるが、依然として、ファイルにさらなる複雑性（故にさらなるＪａｖａ（商標）コード）が追加されるにしたがって厄介になる傾向がある。
それはしばしば、Ｊａｖａ（商標）開発者とウェブページ設計者とがＪＳＰ（商標）を作成し変更するために協力しなければならないという事態になり、明らかに理想的な状況ではない。
【００３７】
概して、<head>および<h2>のような先の例のマークアップをタグ（Tag）と呼ぶ。
それらの対応するバックスラッシュを有する</head>および</h2>マークアップを、終了タグと呼ぶ。
ＨＴＭＬ規格は、いかなるウェブブラウザも正しく理解し処理する必要のあるタグの大きいセットを定義し、したがって、ウェブページ設計者は、タグに非常に熟知し、<img>タグのsrc="..."およびalt="..."等のタグ属性を使用してそれらをいかに「カスタマイズする」かを知っている。
アプリケーションサーバがＪＳＰ（商標）ページを処理するため、ＨＴＭＬの規格以外のタグを挿入することができ、アプリケーションサーバが理解する限り、それらを実行することができる。
一例は、サーバが埋込まれたＪａｖａ（商標）コードを分離するために使用する<%および%>タグである。
タグは、ＪＳＰ（商標）に固有に関連付けられている。
ＪＳＰ（商標）の特徴は、サーバもブラウザも予め理解する必要がないが何らかのＪＳＰ（商標）の文脈でのみ意味を有したとえばコンテンツを提示するためのテンプレートとして使用される、カスタムタグを定義し使用することができる、ということである。
かかるカスタムタグのセットまたはライブラリの１つは、タグライブラリを表すタグリブ（TagLib）として知られている。
タグリブは、わずか１つの単一タグを含んでもよくあるいは文字通り何百ものタグを含んでもよい。
実際のタグリブは、アプリケーションサーバによって理解される、基本的に２つのもの、すなわち、それらが属性をサポートするすべてのカスタムタグの記述と、アプリケーションサーバがタグの代りに実行するＪａｖａ（商標）コードと、を含む、特別なフォーマットのファイルである。
【００３８】
上記挨拶の例を考慮すると、Ｊａｖａ（商標）開発者は、ＪＳＰ（商標）に実際のＪａｖａ（商標）コードを埋込むのではなく、組込みタグリブを作成しそれを、標準ＨＴＭＬと同様に容易に使用することができるウェブページ設計者に与えることができる。
開発者は、たとえば、２つの属性、すなわち午前の挨拶と午後の挨拶とを必要とする「挨拶」タグを作成することができる。
ウェブページ設計者は、タグの名前と必要な属性名のみを知っていればよい。
【００３９】
したがって、ＪＳＰ（商標）は、このようにすることができる。
<% @taglib prefix="hp" urn="..."%>
<html>
<head>
<title>挨拶</title>
</head>
<body>
<p><hp:greeting am="おはようございます！" pm="こんにちは！"/>
</body>
</html>
【００４０】
上記例は、ウェブ設計マークアップとＪａｖａ（商標）コードとの分離を示す。
タグリブは、Ｊａｖａ（商標）の能力をウェブページ設計者の管理下におく。
【００４１】
他の規格と同様に、ＨＴＭＬは、何年にも亙って著しく発達してきた。
主要な分野では、ウェブページの「ルック・アンド・フィール」を扱い、それは、ウェブ設計者が色、像、異なるフォントおよび他のフォーマットオプションを追加することにより、より多くの機能性を提供し概して視覚的により魅力あるものであるウェブページを可能にする能力を意味する。
【００４２】
これを達成するために、ＨＴＭＬに対していくつかの能力が追加された。
すなわち、１）テキスト、画像および他の特徴のレイアウトを指定する能力と、２）テキスト、画像および他の特徴の外観を操作する能力と、である。
【００４３】
「レイアウト」とは、ページの種々の要素が互いに関して画面（または印刷されたハードコピー）上にいかに配置されるかを意味する。
ＨＴＭＬページの要素、たとえばショッピングカートを、製品名、ＳＫＵ番号、価格等に対して交互の色および恐らくは異なるサイズのフォントを使用して行および列に表示することができる。
ＨＴＭＬにおける基礎をなすメカニズムは、カスケーディングスタイルシート（ＣＳＳ）として知られている。
ＣＳＳの特徴は、「イタリック体のArial１２ポイントであって、前景が赤、背景が青」等のスタイルを、commerce.cssまたはcustomer-service.css等の別個のファイルに格納することができる、というものである。
各スタイルは名前を有し、その名前を参照することにより、ＨＴＭＬ要素には、対応するスタイルが適用される。
いくつかの異なる.cssファイルに同じスタイル名を使用することができるため、いずれの.cssが参照されているかにより、ＨＴＭＬはいずれに見えてもよい。
それらが「カスケードになる」ため、いくつかの.cssファイルを逐次参照することができ、ブラウザが、「カスケード効果」が有効であるようにそれらの参照の逆の順序で正しいスタイルを探す場合、１つの.cssファイルが先に参照された.cssで宣言されたスタイルを「オーバーライド」することができ、後者は、さらに別の先に参照された.cssの同じスタイルを「オーバーライド」することができる。
１つまたは複数の.cssファイルを変更することにより、ウェブページ設計者は、ウェブページの「ルック・アンド・フィール」全体か、または実際にウェブサイトまたはウェブベースアプリケーション全体を徹底的に変更することができる。
非常に異なる機能を有する他の種類のスタイルシートがある。
【００４４】
動的コンテンツを生成する一般的に使用されているＪＳＰ（商標）以外の１つの一般的なメカニズムは、「テンプレーティング」であり、それはページ全体に対するテンプレートとして作用することができる不完全なウェブページを意味する。
動的にするために「テンプレーティング」を使用する挨拶の例は、次のようである。
<html>
<head>
<title>挨拶</title>
</head>
<body>
<p>$greeting$
</body>
</html>
$greeting$テンプレートは、実際の挨拶（おはようございます！またはこんにちは！）が表示される場所に配置される。
これは、プレースホルダとして知られており、テンプレートにおいてその位置を識別する。
いくつかの「テンプレーティング」システムまたはエンジンが使用されており、それらはすべて幾分か同じように作用する。
【００４５】
ＸＭＬは、eXtensible Markup Language（拡張可能マークアップ言語）の頭辞語であり、ＨＴＭＬのように、ＳＧＭＬの派生物である。
しかしながら、基本的にＨＴＭＬを含む他のすべてのマークアップ言語と異なり、ＸＭＬは、その言語のために定義されるタグの事前定義されたセットを有していない。
たとえば、ＨＴＭＬは、<body>、<head>、<h2>、<p>等を有するが、ＸＭＬは有しておらず、「無規制（free for all）」である。
しかしながら、文書またはファイルがＸＭＬであるためには、整形されていなければならず、すなわち、文書はいくつかの構文規則に従わなければならないが、それらの規則は、使用するタグの名前または属性のいずれも指図しない。
【００４６】
たとえば、２つの会社が一緒に業務を行っており、一方が他方から何かを購入したい場合はいつでも、発注書を送る必要があり、処理されると、請求書を購入側に送る必要がある。
この文書交換は電子的に非常に適切に行うことができ、多少自動化することができるため、会社は２つのＸＭＬ文書タイプ、すなわち発注書と請求書とを定義することができる。
【００４７】
ＸＭＬでの単純な発注書は次のようである。
<発注書>
<製品>
<sku>ABC12345</sku>
<価格>$12.50</価格>
<量>1000</量>
</製品>
<配送>
<所在名="Prod.Facility 1">
<住所>
<通り>123 Main St.</通り>
<郵便番号>12345</郵便番号>
<市>Springfield</市>
<州>NJ</州>
</住所>
</所在>
</配送>
<支払形式="振替">
<総額>$12,500.00</総額>
</支払>
</発注書>
【００４８】
対応する（非常に単純化した）請求書は次のようである。
<請求書>
<製品>
<sku>ABC12345</sku>
<価格>$12.50</価格>
<量>1000</量>
</製品>
<支払>
<総額>$12,500.00</総額>
<税率="6%">%750.00</税>
<合計>$13,250.00</合計>
</支払>
</請求書>
【００４９】
フォーマット全体はＨＴＭＬに類似するが、タグは非常に用途特定である。
上記文書は、ＨＴＭＬの大部分と異なり、構文的に整形されている。
ＸＭＬは完全に書かなければならず、そうしなければ整形されず処理することができない（すべきではない）。
【００５０】
整形されているだけでなく、ＸＭＬ文書はまた、要求された／許可されたタグ階層とともにタグと属性（およびある程度は値）を記述する２つの比較的類似した方法である、文書型定義（Document Type Definition（ＤＴＤ））またはＸＭＬスキーマのいずれかを使用して、記述することも可能である。
ＤＴＤおよびスキーマにより、ＸＭＬプロセッサは、所与のタイプの文書が整形されているとともに定義に対して有効であることを検査することができる。
ほとんどのＸＭＬ文書は、２つのステップ、すなわち１）文書を解析すること、および２）解析結果を処理すること、で処理される。
いくつかの標準パーサが存在し、すべてのＪ２ＥＥアプリケーションサーバに１つをインストールすることが必要であるため、Ｊａｖａ（商標）ウェブアプリケーションは利用可能な１つに依存することができる。
【００５１】
ＸＭＬを、何らかの種類のフォーマットでの何らかの種類のデータの表現が必要である実質的にあらゆるものに対して使用することができる。
ＸＭＬを使用する理由には、以下のものがある
（１）それは、プラットフォーム、言語およびオペレーティングシステムにとらわれない。
たとえば、ＸＭＬ発注書を、Ｗｉｎｄｏｗｓ（商標）ＰＣ上でＭｉｃｒｏｓｏｆｔ．Ｎｅｔアプリケーションにより作成し、ＨＰ−ＵＸ（商標）上で実行している提供者のＪ２ＥＥ  Ｊａｖａ（商標）発注書アプリケーションに送信することができる。
（２）他の多くのフォーマットとは異なり、文書データとフォーマットとが同じ文書に含まれる。
たとえば、ABC123412501000123 Main St.は、一見して明らかではないが、上記ＸＭＬ発注書文書のまったく同じ値は完全に意味を成している。
（３）ＸＭＬは、人間および機械が生産可能かつ消費可能である。
すなわち、ソフトウェアと人間とがともに、比較的容易にＸＭＬ文書を構成することができ、人間とソフトウェアとがともに、その文書を「理解する」ことができる。
【００５２】
ＸＭＬ名前空間は、テキストを隔離させ提供する役割を果たす不明瞭な名前である。
ＸＭＬによる１つの潜在的な問題は、異なるエンティティが同じタグを定義する可能性があるが、異なる属性およびスキーマ定義を定義する可能性が非常に高い、ということである。
また、後述するように、１つのタイプのＸＭＬ文書に別のタイプのＸＭＬ文書をともに入れることが望ましい場合が多い。
たとえば支払、クライアントもしくは発注書または請求書全体に対して２つ以上の定義がある場合、２つの会社が情報（発注書および請求書等）を交換し、各々異なるように定義されたともに<クライアント>タグを有すると、名前空間を使用して、いずれのクライアントタグが使用されているかを識別することができる。
たとえば、
<発注書>
...
<hp:クライアント>
...
</hp:クライアント>
...
<fulbright:クライアント>
...
</fulbright:クライアント>
</発注書>
【００５３】
上記例では、同じ文書がこのとき２つの異なるクライアントタグ、すなわち「HP」タグと「Fulbright」タグとを含むことができるが、それはそれらが各々異なる名前空間に属するためである。
名前空間の名前が任意であるため、「a」と「b」とが同じ結果をもたらすことができる。
【００５４】
リモート・プロシージャ・コール（Remote Procedure Call（ＲＰＣ））は、リモート（または分散）サーバに対する要求を行うクライアントに対する総称である。
利用可能な多くのＲＰＣメカニズムの中で、通常ＨＴＴＰを使用してＸＭＬ文書を送信し、別のＸＭＬ文書が戻されることにより、ＳＯＡＰ（簡易オブジェクト・アクセス・プロトコル（Simple Object Access Protocol））が実施される。
ＳＯＡＰは、２つのタイプのクライアント／サーバコール、すなわち１）ＲＰＣすなわちリモート・プロシージャ・コールと２）文書（またはメッセージ）交換とをサポートする。
【００５５】
ＲＰＣに対し、呼出すプロシージャの名前（たとえば、CalculateTax）および必要なパラメータ（たとえば、＄１２，５００．００および６％）等のすべての関連する情報を、ＳＯＡＰ  ＸＭＬ文書にフォーマットし、リモートサーバに送信する。
ここで、ＸＭＬを解析し、次のように、パラメータが提供された正しいプロシージャを呼出す。
結果＝CalculateTax(12500,0.06);
【００５６】
そして、その結果を別のＳＯＡＰ  ＸＭＬ文書にフォーマットし、クライアントに返す。
【００５７】
文書交換の場合、任意のタイプのＸＭＬ文書をＳＯＡＰ文書内に埋込み、それをリモートコンピュータに送信する。
そこでそれが抽出され、おそらくは解析され、実際のサーバに渡される。
発注書例はこのカテゴリにうまく適合し、ＳＯＡＰは、送信された発注書、請求書および種々様々の確認メッセージを得るための手段としてのみ使用される。
【００５８】
ＳＯＡＰクライアントおよびサービスが可能な限り一般的であるようにするために、それら自体いかなるＳＯＡＰ特定コードも含まない。
ＳＯＡＰはまた、プロキシも使用し、それらはバインディングと呼ばれ、要求を特定のプロトコル、サーバおよびプロシージャ名（ＲＰＣの場合）に「結合（bind）」する。
ＳＯＡＰ要求を行う場合、コードは、バインディングによって処理されるＳＯＡＰ特定のものは何も「見る（see)」ことはない。
【００５９】
ウェブサービスは、ＳＯＡＰを使用してウェブを介してアクセス可能なサーバである。
したがって、ＲＰＣスタイルウェブサービスと文書交換スタイルウェブサービスとがある。
特定のマシンにおける特定のウェブサービスのCalculateTax等の特定のプロシージャは、エンドポイントと呼ばれ、それは、ＳＯＡＰメッセージが処理するために送信される必要のある場所である。
【００６０】
ウェブサービス記述言語（Web Services Descriptor Language（ＷＳＤＬ））は、特定のスキーマを有するＸＭＬであり、ＷＳＤＬ文書は、ＲＰＣであるか文書交換であるかと、利用可能プロシージャと、それらのパラメータおよびそれらのすべてのエンドポイントと、等の、ウェブサービスに関する詳細な情報をすべて含む。
【００６１】
ＸＳＬ（eXtensible Stylesheet Language（拡張可能スタイルシート言語））により、ＸＭＬ文書を、異なる種類のＸＭＬ、ＨＴＭＬ、単純なプレーンテキストまたはＪａｖａ（商標）コード等の他の何かに変換する方法の定義が可能になる。
ＸＳＬは、文書に一定のタグが現れた場合に何をすべきかと、変換された出力がどのように見えるかと、を記述する規則のセットである。
【００６２】
特に電話の音声応答システムとＰＤＡおよび携帯電話等のローエンド無線機器とに対し、他の２つのタイプのＸＭＬ文書、すなわちＶｏｉｃｅ−ＸＭＬおよびＷＭＬ（Wireless Markup Language（無線マークアップ言語））が開発された。
エンドユーザの視点から、Ｖｏｉｃｅ−ＸＭＬおよびＷＭＬは、ＨＴＭＬが「通常の（normal）」ウェブブラウザに対して行うものと同じ役割を果たす。
ＷＭＬは、幾分かＨＴＭＬに似ているように見えるが、Ｖｏｉｃｅ−ＸＭＬは、天気または株価等の実際の情報とともに認識すべき音声文法、単語／タッチトーンを含まなければならないため、極めて異なる。
【００６３】
ＲＳＳ（ＲＤＦサイトサマリー（RDF Site Summary））は、軽量の多目的の拡張可能メタデータ記述およびシンジケーションフォーマットである。
ＲＳＳは、ＸＭＬアプリケーションであり、Ｗ３ＣのＲＤＦ（Resource Description Framework（リソース記述フレームワーク））規格に準拠し、ＸＭＬ名前空間および／またはＲＤＦベースモジュール化を介して拡張可能である。
ＲＤＦは、基本的に、オントロジシステムを扱うことにより、知識の交換をサポートする。
シンジケーションは、概して、１つのウェブサイトが恐らくは他のどこかのシンジケーションサービスからそのコンテンツの一部を受取る（借りる、貸借する、販売する）ことを意味する。
たとえば、スポーツおよびニュースのサイトは、一般にシンジケーションを使用し、たとえば、Ｙａｈｏｏ（商標）ニュースは、主としてほかの場所からのシンジケートコンテンツである。
【００６４】
ＵＤＤＩ（Universal Description, Discovery and Integration（ユニバーサル・ディスクリプション、ディスカバリー・アンド・インテグレーション））は、ウェブサービスが記述されるレジストリである。
ＵＤＤＩ自体、それに通信するために使用されるプロトコルがＳＯＡＰおよびＨＴＴＰであるという意味でウェブサービスである。
高レベルにおいて、ＵＤＤＩを、ウェブサービスを検索するための職業別電話帳としてみることができる。
ＵＤＤＩレジストリは、かかる検索を可能にするが、複数のカテゴリおよびキーワードを使用する。
また、職業別電話帳検索の結果は、電話番号と恐らくは住所に過ぎない場合が多いが、ＵＤＤＩによる検索の結果は、特に、ウェブサービスが行うことができることのみでなくそれといかにして通信するかを説明するＷＳＤＬ文書である。
【００６５】
インターネットでは、会社および組織がそれらのウェブサービスを登録するのを可能にする少数のパブリックＵＤＤＩレジストリが存在する。
誰もがこれらのレジストリを検索し潜在的にそれらの必要性に適合する適当なウェブサービスを見つけることができる。
ＵＤＤＩレジストリは明確なウェブサービスにすぎないため、民間企業および組織は、公共消費に対して利用可能な組織内ウェブサービスに対して１つまたは複数の専用ＵＤＤＩレジストリを有するように選択することができる。
【００６６】
ウェブサービスを使用するために、ＵＤＤＩは強制的ではない。
詳細（すなわち、ＵＲＬおよびＷＳＤＬ）が他の手段によって通信された場合、ウェブサービスは依然として、電話番号をすでに知っている発呼者が電話するためにそれを調べる必要がないのと同様に、使用するためにアクセス可能であり利用可能である。
わずかに異なる言い方をすると、ＵＤＤＩは、設計時（コードが設計され書かれる時）にもっとも頻繁に使用され、実行時（ユーザが実際にコードを実行する時）にはほとんど必要とされない。
【００６７】
ＳＯＡＰプロトコルを使用してウェブサービスが予測された繁殖をする場合、ウェブコンテンツは、第三者の会社または組織によりますます製作されることになる。
上述したいくつかの典型的な例は、天気予報と株価とであるが、他の多くの分野も等しく適用可能である。
有利には、ＳＯＡＰを使用するウェブサービスは適切に定義され記述される。
プロトコルは通常ＨＴＴＰであり、ＳＯＡＰ  ＸＭＬメッセージは明確な方法で送受信される。
重要なことは、ウェブサービスは通常１つまたは複数のパブリックＵＤＤＩレジストリに登録されるため、非常に容易に見つけてアクセスすることができる、ということである。
【００６８】
さらに、ウェブコンテンツを作成する人（著者）とコードを書く人（開発者）とが二分化されており、それによりＪＳＰ（商標）およびタグリブ等の技術がもたらされた。
ウェブコンテンツ著者が使用するために大量のソースから非常に異種の情報／コンテンツを入手可能とすることができる場合、開発者を必要とすることなくより豊富かつより機能的なウェブアプリケーションを開発することができる。
【００６９】
ウェブサービスを有用なものとするためには、それを公的にまたは私的にどこかに登録しなければならない。
それは、通常ＵＤＤＩレジストリ（いくつかの公的なものが存在し、それらのうちの１つはヒューレット・パッカード（Hewlett-Packard（ＨＰ））社によって運営されている）で行われる。
レジストリに格納される実際の情報は、特に、ウェブサービスが行うことができること（たとえば、株価を提供するかまたは天気予報を配信する）およびそれをいかにして呼出さなければならないか（いずれのメソッドを呼出すか（たとえば、getQuote））と、いずれのパラメータを提供すべきか（たとえば、stockSymbol）と、応答が何か（たとえば、stockPrice））と、を記述する、ＷＳＤＬ（Web Service Descriptor Language（ウェブサービス記述言語）、通常「wis-del」と表記する）のＸＭＬ文書である。
これは、ＲＰＣ（Remote Procedure Call（リモート・プロシージャ・コール））を構成するものである。
【００７０】
ＷＳＤＬ文書により、開発者は、適用可能なＳＯＡＰメッセージをいかにフォーマットするかと、ウェブサービスからＳＯＡＰ応答をいかに解釈するかと、を演繹することができる。
これは単調で退屈であるため、ほとんどの開発者は、ＷＳＤＬ文書を解釈し単調で退屈な作業を行う何らかのコードを生成する１つまたは複数のツールを使用する。
ベンダおよびオープンソースイニシアティブによっては、これらのツールを提供し、それらが実際に生成するものをプロキシと呼ぶ。
プロキシにより、開発者は、単にプロキシと対話するコードを書き、それによりプロキシはＳＯＡＰ／ＸＭＬ／ＨＴＴＰプロトコル変換の詳細を操作する。
【００７１】
したがって、ウェブサービスの使用は、従来、コード開発を必要とし、したがって常に開発者に対し非常に特定のコードを書くために時間を費やすよう要求し、後に変更が必要な場合は、開発者を再び必要としなければならなかった。
１つのオプションは、開発者が特定のウェブサービスに対してプロキシを生成しタグリブを書くというものである。
しかしながら、それは、開発者を巻き添えにするという問題全体を解決しない。
すなわち、新たな有用なウェブサービスが発見される時はいつでも、完全に新しいタグリブ（または少なくとも新たなタグ）を定義し開発しなければならない。
【００７２】
本実施形態の教示によれば、ウェブコンテンツ著者は、単一の事前に開発されたタグリブを使用して、いかなるウェブサービスにおいていかなるメソッドも呼出す。
著者は、適当なウェブサービスを見つけ、単一タグリブを使用して、いかなるコードの生成も開発者を巻き添えにすることもなしにメソッドを呼出し結果を取得することができる。
【００７３】
リソース記述フレームワーク・サイト・サマリー（Resource Description Framework Site Summary（ＲＳＳ））は、拡張可能マークアップ言語（eXtensible Markup Language（ＸＭＬ））でウェブサイトコンテンツ、すなわちウェブサイトサマリーを記述するための軽量の多目的拡張可能メタデータ記述およびシンジケーションフォーマットである。
本明細書では、タグライブラリ（タグリブ）に格納されたタグのシリーズ１００に基づいて、複数のフォーマット、たとえばＨＴＭＬ、ＷＭＬ、音声（ＶＸＭＬ）でのＲＳＳの分散情報処理および記憶システムにおける提示を可能にする、システムおよび方法を提供する。
ハイパーリンクのＲＳＳベースセットの表示は、たとえば以下のタグのシリーズを定義することによって行う。
<content: transform stylesheet="/my.xsl">
<content: include url/="http://www.hp.wm/rss.vxml"/>
</content: transform>
ここでは、ＸＳＬを使用して、ＲＳＳ  ＸＭＬフォーマットを提示ＸＭＬフォーマットに変換する。
【００７４】
図１は、本実施形態による一連のタグ、たとえばタグ１〜３を使用する方法１００を示す簡易フローチャートを示す。
図２は、本実施形態による分散情報処理および記憶システムのコンポーネントを概略的に表すブロック図である。
ステップ１０１において、第１のタグ２１１（タグ１）は、変換プロセスを開始し、「スタイルシート」の属性を、それがウェブページたとえばブラウザ２００のウェブページ２０１に挿入されるいずれの場所でも、たとえば"/my.xsl"にカスタマイズする。
ＸＳＬにより、ＸＭＬ文書を異なるフォーマット、たとえば異なる種類のＸＭＬ、ＨＴＭＬ、プレーンテキストまたはＪａｖａ（商標）コードに変換する方法の定義が可能になる。
ＸＳＬは、文書、たとえばウェブページ２０１において一定のタグが現れる時に何を行うかと、変換された出力がどのように現れるかと、を記述する標準的な規則のセットを提供する。
実施形態によっては、ＸＳＬ２１０を使用して、ウェブサイトサマリー、たとえばウェブサイトサマリー２０３を、ＲＳＳ  ＸＭＬフォーマット２０５から提示ＸＭＬフォーマット、たとえば音声ＸＭＬ（ＶＸＭＬ）に変換する。
【００７５】
ステップ１０２において、第２のタグ２１２（タグ２）が、ウェブブラウザ２００に対し、ＵＲＬ、たとえば"http://www.hp.wm/rss.vxml/"として識別されるＵＲＬ２０２に行くように命令し、ＵＲＬ２０２のコンテンツ２０４に関連するウェブサイトサマリー２０３を、ＸＳＬ２１０を使用して、初期ＲＳＳ  ＸＭＬフォーマット２０５から変換済みＶＸＭＬ音声提示ＸＭＬフォーマット２０６に変換する。
この例ではＶＸＭＬを使用するが、要求に応じて、他のあらゆる提示フォーマット、たとえばＨＴＭＬ、ＷＭＬ等が変換からもたらされてもよい、ということが理解される。
【００７６】
ステップ１０３において、先行するフォワードスラッシュ（/）記号を含む第３のタグ２１３（タグ３）が、ＸＳＬ変換タグシリーズ２１１〜２１３の終了を示す終了タグを提供する。
上記タグのシリーズは、有利には、ブラウザ２００を実行するクライアントプラットフォームによって通信によりアクセス可能である、タグリブたとえばタグリブ２１５に格納される。
タグシリーズ２１１〜２１３を、ＸＭＬとそれ自体がＸＭＬであってもよいＪＳＰ（商標）マークアップとのみを使用して、コードなしに完全に書くことができるが、従来は、等価な変換には、プログラミング言語を使用してコードをＡＰＩに書くことが必要であった。
タグ２１１〜２１３は、概して、プログラマかまたは高度な技術を有するウェブページ設計者であってもよいページ「開発者」によって指定される。
レンダリングされたコンテンツタイプを、タグ（たとえば、ネスト化されたタグ）とは無関係に複数の方法で適合させてもよい。
詳細なＸＳＬスクリプトが、ＲＳＳ  ＸＭＬの変換／マッピングを確定する。
【００７７】
変換を、適当なタグシリーズをアプリケーションサーバによりブラウザ２００に提供されるウェブページまたは他の文書、たとえばウェブページ（たとえばＪＳＰ（商標））２０１に挿入することによって、呼出すことができる。
変換の詳細は、タグにおいて指定されるＸＳＬスクリプトによって決まる。
タグ２１１〜２１３が意味論を変更する他の何らかのタグにおいてネスト化されない場合、タグ実行は、ウェブページ２０１に対するＨＴＴＰ要求によってトリガされ、それは、この時点で、ＪＳＰ（商標）の残りとともに、Ｊａｖａ（商標）コードにレンダリングされている。
通常、たとえば、ＶＸＭＬに対する要求は、ユーザからの電話または他の音声通信手段を介する音声コマンドに応答して動作している音声ポータルによって生成される。
ポータルまたはゲートウェイは、音声を解釈し、それを、アプリケーションサーバに送信されるＨＴＴＰ要求に変換する。
アプリケーションサーバは、ユーザエージェント情報を検査し、装置には応答がＶＸＭＬフォーマットである必要があると判断してもよい（たとえば、ブラウザがクライアントである場合のＨＴＭＬフォーマットとは対照的に）。
ＶＸＭＬが、ＶＸＭＬを操作するように特別に用意されたものではなく通常のウェブブラウザに返される場合、マークアップのテキストのみが表示される。
そして、この能力を使用して、適当なＸＳＬスクリプトに応答してタグに対して適当なＵＲＬを提供してもよい。
ＶＸＭＬ音声フォーマットへの変換は、ウェブサイトサマリーのフォーマット変換に対するタグ使用の柔軟性の例証となる。
【００７８】
タグシリーズ２１１〜２１３がウェブページ２０１に埋込まれた後、クライアントは、ブラウザ２００または他の適当なプラットフォームを通して、アプリケーションサーバがウェブページ（ＪＳＰ（商標））２０１に対して解決するＵＲＬ２０２に対してコンテンツ２０４を要求する。
ウェブページ２０１が、現れるにしたがって逐次クライアント要求に基づいて処理されると、テキストが応答ストリームに書込まれる。
ブラウザ２００がタグを見つけると、それは、タグリブ２１５においてそのタグを実施するように書かれたコードにアクセスし、そのコードが実行される。
そして、ウェブサイトサマリー２０３が、ＸＳＬ２１０を使用して、初期ＲＳＳ  ＸＭＬフォーマット２０５から提示ＸＭＬフォーマット２０６に変換され、それを、たとえばウェブブラウザ２００において発行することができる。
【００７９】
本明細書で開示する方法は、単純で強力であり、ウェブ／ＨＴＭＬ著者がＸＭＬベースマークアップのみを使用して動的サイトサマリーを提供することができるようにする。
したがって、タグは、非常にＸＭＬ文書に似ているように見える単純なページに対し、新たな方法で動的コンテンツを追加する能力を提供する。
これにより、従来技術に対する利点は、ウェブページ設計者が、マークアップ言語を使用して、初期フォーマット、たとえばＲＳＳ  ＸＭＬを別のフォーマット、たとえばＶＸＭＬに動的に変換することができる、ということである。
実施形態によっては、それは、タグに埋込まれたマークアップ言語を有効に使用することにより、第１のマークアップ言語フォーマットを第２のマークアップ言語フォーマットに変換することができる。
【００８０】
したがって、ウェブページ設計者は、ツールを使用しコードを書くことなしに、インターネット（ネットワークアクセス可能）におけるまたはローカルに（ファイルシステムにおいて）いかなるソースからもＲＳＳ記述を動的に獲得するウェブページを定義し、それを、いかなるネットワークアクセス可能なまたはローカルなソースからも動的に獲得することができる変換テンプレートに基づいて任意の方法で提示のためにレンダリングすることができる。
従来、同じ結果を達成するためには、プログラマが、複雑なネットワーク対応（network-aware）Ｊａｖａコードを書く必要があった。
いかなる既存の方法も、これを単純にまたは明らかに達成しない。
【００８１】
以下に併記する付録Ａ、ＢおよびＣは、ＲＳＳ  ＸＭＬフォーマットから他のマークアップ言語フォーマットに変換する従来のＸＳＬスクリプトの例を示す。
【００８２】
付録Ａ
以下は、オープンソースＡｐａｃｈｅ  Ｊｅｔｓｐｅｅｄプロジェクトからの著作権のない従来のＲＳＳ文書の例を示す。
<?xml version="1.0"?>
<rss version="0.91">
<channel>
<title>Apache Jetspeed</title>
<link>http://jakarta.apache.org/jetspeed</link>
<description>
An Open Source Enterprise Information Portal.
</description>
<image>
<title>Apache Jetspeed</title>
<url>images/jetspeed-powered.gif</url>
<link>http://jakarta.apache.org/jetspeed</link>
</image>
<item>
<title>Jetspeed 1.4 Beta 3 Released</title>
<link>http://jakarta.apache.org/builds/jakarta-jetspeed/release/
v1.4b3</link> 
<description>
Jetspeed v1.4 Beta 3が利用可能。
</description>
</item>
<item>
<title>Jetspeed Documentation</title>
<link>http://jakarta.apache.org/jetspeed</link>
<description>
Jetspeedは、エンタープライズ情報ポータルのオープンソース実施で
ある。
Jetspeedはインターネット上の複数の資源から情報を消費しようと
試み、ユーザが大量のデータを管理するのに役立つ。
この情報を、複数のコンテンツソース、すなわちローカルファイル、
ローカルアプリケーションまたはリモートＨＴＴＰソースから得るこ
とができる。
</description>
</item>
<item>
<title>Jetspeed Tutorial</title>
<link>http://www.bluesunrise.com/jetspeed-docs/
JetspeedTutorial.htm</link>
<description>リリース１．４ｂ３をカバーする現時点で最も
包括的なJetspeedチュートリアル</description>
</item>
</channel>
</rss>
【００８３】
付録Ｂ
以下は、ＨＴＭＬに変換する従来のＸＳＬスクリプトの例を示す。
<?xml version="1.0" encoding="iso-8859-1" ?> 
- <!-- 
Author:  Kevin A Burton (burton@apache.org)
Author:  Santiago Gala (sgala@hisitech.com)
Author:  Raphael Luta (raphael@apache.org)
Author:  Paul Spencer (paulspencer@mindspring.com)
$Id: rss.xsl,v 1.5 2001/12/29 04:09:24 paulsp Exp $
--> 
- <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:downlevel="http://my.netscape.com/rdf/simple/0.9/" exclude-result-prefixes="downlevel rdf" version="1.0">
<xsl:output indent="yes" method="html" omit-xml-declaration="yes" /> 
<xsl:param name="itemdisplayed" select="number(15)" /> 
<xsl:param name="openinpopup" select="'false'" /> 
<xsl:param name="showdescription" select="'true'" /> 
<xsl:param name="showtitle" select="'true'" /> 
<xsl:param name="showtextinput" select="'true'" /> 
- <xsl:template match="/rss">
- <div>
<xsl:apply-templates select="channel" /> 
</div>
</xsl:template>
- <xsl:template match="/rdf:RDF">
- <div>
<xsl:apply-templates select="downlevel:channel" /> 
</div>
</xsl:template>
- <xsl:template match="channel">
<xsl:variable name="description" select="description" /> 
- <xsl:if test="$showtitle = 'true' and $description">
- <p>
<xsl:apply-templates select="image|../image" mode="channel" /> 
<xsl:value-of select="$description" /> 
</p>
</xsl:if>
- <ul>
<xsl:apply-templates select="item[$itemdisplayed>=position()]" /> 
</ul>
- <xsl:if test="$showtextinput = 'true'">
<xsl:apply-templates select="textinput" /> 
</xsl:if>
</xsl:template>
- <xsl:template match="downlevel:channel">
<xsl:variable name="description" select="downlevel:description" /> 
- <xsl:if test="$showtitle = 'true' and $description">
- <p>
- <xsl:choose>
- <xsl:when test="count(../downlevel:image)">
<xsl:apply-templates select="../downlevel:image" mode="channel" /> 
<xsl:value-of select="$description" /> 
</xsl:when>
- <xsl:otherwise>
- <a>
- <xsl:attribute name="href">
<xsl:value-of select="downlevel:link" /> 
</xsl:attribute>
- <xsl:if test="$openinpopup = 'true'">
<xsl:attribute name="target">_blank</xsl:attribute> 
</xsl:if>
<xsl:value-of select="$description" /> 
</A>
</xsl:otherwise>
</xsl:choose>
</p>
</xsl:if>
- <ul>
<xsl:apply-templates select="../downlevel:item[$itemdisplayed>=position()]" /> 
</ul>
- <xsl:if test="$showtextinput = 'true'">
<xsl:apply-templates select="downlevel:textinput" /> 
</xsl:if>
</xsl:template>
- <xsl:template match="item">
<xsl:variable name="description" select="description" /> 
- <li>
- <a>
- <xsl:attribute name="href">
<xsl:value-of select="link" /> 
</xsl:attribute>
- <xsl:if test="$openinpopup = 'true'">
<xsl:attribute name="target">_blank</xsl:attribute> 
</xsl:if>
<xsl:value-of select="title" /> 
</A>
- <xsl:if test="$showdescription = 'true' and $description">
<br /> 
<xsl:value-of select="$description" /> 
</xsl:if>
</li>
</xsl:template>
- <xsl:template match="downlevel:item">
<xsl:variable name="description" select="downlevel:description" /> 
- <li>
- <a>
- <xsl:attribute name="href">
<xsl:value-of select="downlevel:link" /> 
</xsl:attribute>
- <xsl:if test="$openinpopup = 'true'">
<xsl:attribute name="target">_blank</xsl:attribute> 
</xsl:if>
<xsl:value-of select="downlevel:title" /> 
</A>
- <xsl:if test="$showdescription = 'true' and $description">
<br /> 
<xsl:value-of select="$description" /> 
</xsl:if>
</li>
</xsl:template>
- <xsl:template match="textinput">
- <form action="{link}">
<xsl:value-of select="description" /> 
<br /> 
<input type="text" name="{name}" value="" /> 
<input type="submit" name="submit" value="{title}" /> 
</form>
</xsl:template>
- <xsl:template match="downlevel:textinput">
- <form action="{downlevel:link}">
<xsl:value-of select="downlevel:description" /> 
<br /> 
<input type="text" name="{downlevel:name}" value="" /> 
<input type="submit" name="submit" value="{downlevel:title}" /> 
</form>
</xsl:template>
- <xsl:template match="image" mode="channel">
- <a>
- <xsl:attribute name="href">
<xsl:value-of select="link" /> 
</xsl:attribute>
- <xsl:if test="$openinpopup = 'true'">
<xsl:attribute name="target">_blank</xsl:attribute> 
</xsl:if>
- <xsl:element name="img">
<xsl:attribute name="align">right</xsl:attribute> 
<xsl:attribute name="border">0</xsl:attribute> 
- <xsl:if test="title">
- <xsl:attribute name="alt">
<xsl:value-of select="title" /> 
</xsl:attribute>
</xsl:if>
- <xsl:if test="url">
- <xsl:attribute name="src">
<xsl:value-of select="url" /> 
</xsl:attribute>
</xsl:if>
- <xsl:if test="width">
- <xsl:attribute name="width">
<xsl:value-of select="width" /> 
</xsl:attribute>
</xsl:if>
- <xsl:if test="height">
- <xsl:attribute name="height">
<xsl:value-of select="height" /> 
</xsl:attribute>
</xsl:if>
</xsl:element>
</A>
</xsl:template>
- <xsl:template match="downlevel:image" mode="channel">
- <a>
- <xsl:attribute name="href">
<xsl:value-of select="downlevel:link" /> 
</xsl:attribute>
- <xsl:if test="$openinpopup = 'true'">
<xsl:attribute name="target">_blank</xsl:attribute> 
</xsl:if>
- <xsl:element name="img">
<xsl:attribute name="align">right</xsl:attribute> 
<xsl:attribute name="border">0</xsl:attribute> 
- <xsl:if test="downlevel:title">
- <xsl:attribute name="alt">
<xsl:value-of select="downlevel:title" /> 
</xsl:attribute>
</xsl:if>
- <xsl:if test="downlevel:url">
- <xsl:attribute name="src">
<xsl:value-of select="downlevel:url" /> 
</xsl:attribute>
</xsl:if>
</xsl:element>
</A>
</xsl:template>
- <!--  We ignore images unless we are inside a channel 
--> 
<xsl:template match="image" /> 
<xsl:template match="downlevel:image" /> 
</xsl:stylesheet>
【００８４】
付録Ｃ
以下に、ＲＳＳフィードをＷＭＬカードのデッキに変換する従来のＸＳＬテンプレートの例を示す。
<?xml version="1.0" encoding="iso-8859-1" ?> 
- <!-- 
Author:  Kevin A Burton (burton@apache.org)
Author:  Santiago Gala (sgala@hisitech.com)
Author:  Raphael Luta (raphael@apache.org)
SGP: Changed to support quoting of $ as $$ to avoid problems under WML
$Id: rss-wml.xsl,v 1.5 2001/02/27 16:26:54 sgala Exp $
--> 
- <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:downlevel="http://my.netscape.com/rdf/simple/0.9/" exclude-result-prefixes="downlevel rdf" version="1.0">
<xsl:output indent="yes" method="xml" omit-xml-declaration="yes" /> 
<xsl:param name="itemdisplayed" select="number(5)" /> 
<xsl:param name="showdescription" select="'false'" /> 
<xsl:param name="showtitle" select="'false'" /> 
- <xsl:template match="/rss">
<xsl:apply-templates select="channel" /> 
</xsl:template>
- <xsl:template match="/rdf:RDF">
<xsl:apply-templates select="downlevel:channel" /> 
</xsl:template>
- <xsl:template match="channel">
<xsl:variable name="description" select="description" /> 
- <card id="channel">
- <p>
<xsl:apply-templates select="title" /> 
- <xsl:if test="$showtitle = 'true' and $description">
<br /> 
<xsl:apply-templates select="$description" /> 
</xsl:if>
</p>
<xsl:apply-templates select="item[$itemdisplayed>=position()]" /> 
</card>
</xsl:template>
- <xsl:template match="item">
<xsl:variable name="description" select="description" /> 
- <p>
- <A HREF="{link}">
<xsl:apply-templates select="title" /> 
</A>
- <xsl:if test="$showdescription = 'true' and $description">
<br /> 
<xsl:apply-templates select="$description" /> 
</xsl:if>
</p>
</xsl:template>
- <xsl:template match="downlevel:channel">
<xsl:variable name="description" select="downlevel:description" /> 
- <card id="channel">
- <p>
<xsl:apply-templates select="downlevel:title" /> 
- <xsl:if test="$showtitle = 'true' and $description">
<br /> 
<xsl:apply-templates select="$description" /> 
</xsl:if>
</p>
<xsl:apply-templates select="../downlevel:item[$itemdisplayed>=position()]" /> 
</card>
</xsl:template>
- <xsl:template match="downlevel:item">
<xsl:variable name="description" select="downlevel:description" /> 
- <p>
- <A HREF="{downlevel:link}">
<xsl:apply-templates select="downlevel:title" /> 
</A>
- <xsl:if test="$showdescription = 'true' and $description">
<br /> 
<xsl:apply-templates select="$description" /> 
</xsl:if>
</p>
</xsl:template>
- <xsl:template match="text()">
- <xsl:call-template name="dollar-cleaner">
- <xsl:with-param name="chars">
<xsl:value-of select="." /> 
</xsl:with-param>
</xsl:call-template>
</xsl:template>
- <xsl:template name="dollar-cleaner">
<xsl:param name="chars" /> 
- <xsl:choose>
- <xsl:when test="contains($chars,'$') and not(starts-with(substring-after($chars,'$'), '$'))">
<xsl:value-of select="substring-before($chars,'$')" /> 
$$ 
- <xsl:call-template name="dollar-cleaner">
- <xsl:with-param name="chars">
<xsl:value-of select="substring-after($chars,'$')" /> 
</xsl:with-param>
</xsl:call-template>
</xsl:when>
- <xsl:otherwise>
<xsl:value-of select="$chars" /> 
</xsl:otherwise>
</xsl:choose>
</xsl:template>
</xsl:stylesheet>
【図面の簡単な説明】
【００８５】
【図１】本実施形態によるタグシリーズを提供する方法を示す簡易フローチャートを示す。
【図２】本実施形態による分散情報処理および記憶システムのコンポーネントを概略的に表すブロック図である。
【符号の説明】
【００８６】
２００・・・ブラウザ、
２０１・・・ウェブページ、
２０２・・・ＵＲＬ、
２０３・・・ウェブサイトサマリー、
２０４・・・コンテンツ、
２０５・・・ＲＳＳ  ＸＭＬフォーマット、
２０６・・・変換済みＶＸＭＬ音声提示ＸＭＬフォーマット、
２１０・・・ＸＳＬ、
２１１〜２１３・・・ＸＳＬ変換タグシリーズ、
【図１】
2004334866.tif 000003
【図２】
2004334866.tif 000004