XMLベースのサーバー - クライアントプロトコルの複数の名前空間または単一の名前空間を宣言する必要はありますか？

Question

私は現在クライアント/サーバーアプリケーションで作業しています。プロトコル用にXMLを使用したいと思います。今は、XML名前空間を宣言しXMLスキーマを作成することについて確信しています。

もちろん、サーバーとクライアントが異なるものを送信する、つまりクライアントが要求を送信し、サーバーが応答して別のタグなどを使用することは言うまでもありません。両者の共通点は、送信されるXMLデータがストリーム形式であり、ドキュメントのルートが<stream>ですが、私の言ったように、タグはそれぞれ異なります（それぞれリクエストまたはレスポンスを表します）。

今、これらの2つの異なるXM言語はありますか？それぞれのネームスペース（したがって1つのXSD）を宣言する必要がありますか？または、私はすべてを使用して、サイド（サーバー|クライアント）を定義する属性 "送信者"を追加しますか？後者の場合：どのように属性値を区別するのですか？つまり、XSDでどのタグを「送信者」の値として許可するかを宣言する方法はありますか？

Answer 1

2つの<stream>要素は異なる内容を持つため、同じローカル名を持つ2つの異なる要素ですが、異なる方法で検証する必要があります。これは、それらが別々の名前空間になければならず、したがって別々のスキーマでなければならないことを意味します。

ただし、送信者と受信者の内容が共通の要素または属性を共有する場合は、共通の内容で3番目のスキーマを追加する必要があります。他の2つのスキーマは共通スキーマをインポートします。

Answer 2

よくあることですが、これに対して正しい答えは1つもないようです。

要求と応答に同じ要素タグ（つまり、<stream>）を使用する利点はわかりません。たとえば、<request>と<response>を別々のトップレベル要素として使用できます。これはもう少し意味があるかもしれませんし、2つのメッセージタイプに別々の名前空間（およびスキーマ）を使用することについての議論も強化します。

しかし、あなたは、あなたが<stream>がunionタイプであるようなスキーマを定義することができ、要求と応答の両方のために、トップレベルのタグとして<stream>を使用するための十分な理由がある場合。組合員には、要求または応答のいずれかに適切な要素が含まれますが、両方には該当しません。この構造は、同じ名前空間に2つの辺を保持することを容易にします。

リクエストとレスポンスのプロトコルが緊密に結合されているように見えるのであれば、このルートに行く傾向がもう少しあります。レスポンス・セット内の情報のタイプが時間の経過とともに（またはアプリケーションによって）変更される可能性がある場合は、別々の名前空間が理にかなっています。