読み取り専用Webサービスのシナリオ
このようなパラメータ化ならうんざりするぐらいお馴染みだと思うならば、それは、Webサービスを使っているときに実際に同じ問題が起きているということです。とりあえず、HTTP GETプロトコルに基づいた読み取り専用Webサービスだけを考えてみましょう。読み取り専用Webサービスが使われそうな2つの異なるシナリオを取り上げます。
1つ目のシチュエーションは、何らかの理由で問題のモデルをクライアント環境内に直接簡単に収めることができない場合です（データベースにホストされているとか、セキュリティの権限が絡んでいるなど）。こうしたサービスを「便宜的なサービス」と呼ぶことにします。理論的には情報をローカルにホストすることもできますが、そうするのは効率的ではありません。このケースでは、データ環境は基本的に静的です。同じ呼び出しを異なる時期に2回実行した場合、時間以外のパラメータが同じなら、2つの呼び出しは同じコンテンツを返します。このような呼び出しのスキーマを作成することは理論的に可能で、このスキーマには特定の値のセットが含まれることになります（大きくなる可能性はあります）。このアプローチの良い例が、郵便番号を地域の特定の区域にマッピングする郵便番号簿でしょう。郵便番号簿は変更される可能性がありますが、モデル作成者が気にしなければならないほど頻繁に変更されるものではありません。
しかし、もう1つのシチュエーションはかなり興味深いものです。このケースはサービス自体が動的な環境を扱っています。たとえば、典型的なWebサービスとして、1日の始まりから現在の時間までの普通株の変動（+/?で差分を通知するようなもの）を取得するものを取り上げてみましょう。ポイントだけ説明すると、このサービスは、前回通知した期間以降に値が増加した特定の株のセットを一覧で表示します。この場合のタクソノミーは機能的かつ動的です。これをラジオボタンのリストとして実装し、個々の株をラジオボタンで表すならば、Webサービスをリフレッシュするたびにボタンの数やボタンのコンテンツが変化することになるでしょう。
これはXFormsに限ったことではありません。実際、AJAX（Asynchronous JavaScript and XML）全般に見られるもっとたちの悪い問題の1つは、データモデルが拡散して分散するほど、データモデルのインスタンスを検証するのがますます難しくなるということです。そのため、オブジェクト指向プログラミングでもXMLでも、これまで考案されてきた検証の概念の大部分は役に立ちません。
さて、ここで重大な疑問が出てきます。果たして検証は必要なのでしょうか？ たとえ完全に信頼できるネットワークでも、「何らかの形態の検証は必要」という答えになるでしょう。そのようなネットワークでも、どこかの時点でXML（または関連するシリアライズされたコンテンツ）を作成する必要があり、そのXMLの作成プロセスに欠陥がある可能性があります。しかし、それにまつわる検証はむしろ包括的なユニットテストに組み込まれています。箱に封をし、この閉じたシステム内のコンテンツは有効で一貫性があると確定した後では、エラーの原因となるものはモデル自体の欠陥から来るものとしか考えられず、それは当然ながら検証では解決できません（そのような検証はモデルの一部です）。
しかし、XMLコンテンツが環境の外側から入ってくる可能性を作った時点で、検証は困難になります。また、XMLの主な役割が異種のシステム間でメッセージをやり取りするフォーマットであるため、システムに入ってくるコンテンツが内部的に一貫性がありかつ正当なものであることを判断する何らかの方法が必要になるでしょう。
しかし、静的なスキーマ言語は、せいぜい構造型または基本型の検証を提供できるに過ぎません。それでさえ、モデルが複雑になるに従って、そうしたスキーマが適切にコンテンツを検証できる可能性は運次第なものになります。モデルの外側に存在するタクソノミー情報は、とりわけ動的なコンテキストでは、検証することができません。さらに、メッセージの正当性は検証できません。
1つ考えられるソリューションは、SOAP/WSDLの相互交換に特化した複雑なWebサービスのインフラストラクチャをセットアップし、識別管理のための連携システムを確立し、すべてを暗号化されたまとまりとして扱い、関係するすべてのシステムにまたがるハンドシェークメカニズムを本格的に構築して、インターネットという基本的に信頼できないネットワークを、閉じたプライベートな完全に信頼できるネットワークに変えることです。このアプローチは、ほとんどのWS-*イニシアチブの作成に大いに役立ちます。
