Dois-je déclarer plusieurs ou un seul espace de nom pour un protocole client-serveur basé sur XML?

Question

Je travaille actuellement sur une application client-serveur et j'aimerais utiliser XML pour le protocole. Maintenant, je ne suis pas sûr de déclarer les espaces de noms XML et de créer des schémas XML. Inutile de dire que le serveur et le client envoient des choses différentes, c'est-à-dire que le client envoie des demandes et que le serveur y répond, et utilise par conséquent des étiquettes différentes et ainsi de suite. Ce que les deux parties ont en commun, c'est que les données XML envoyées sont de type flux et que la racine du document est <stream>, mais - comme je l'ai dit - les tags sont différents (chacun correspondant à une requête ou à une réponse).

Maintenant, sont ces deux langages XM différents? Dois-je déclarer un espace de nom (et donc un XSD) pour chacun d'eux? Ou dois-je en utiliser un pour tous et ajouter un attribut "expéditeur" à la définition du côté (serveur | client)? Dans le dernier cas: Comment puis-je différencier les valeurs d'attribut? Autrement dit, comment déclarer dans la XSD quelle balise est autorisée pour quelle valeur "expéditeur"?

Answer 1

Étant donné que les deux éléments <stream> ont des contenus différents, ils sont deux éléments différents avec le même nom local, mais doivent être validés différemment. Cela implique qu'ils doivent être dans des espaces de noms distincts, donc des schémas séparés.

Toutefois, si le contenu des éléments <stream> de l'expéditeur et du destinataire partagent des éléments ou des attributs communs, vous devez ajouter un troisième schéma, avec le contenu commun. Les deux autres schémas importeraient le schéma commun.

Answer 2

Comme c'est souvent le cas, il ne semble pas y avoir une bonne réponse à cela.

Je ne sais pas quel avantage il y a à utiliser la même étiquette d'élément (c'est-à-dire, <stream>) pour la demande et la réponse. Vous pouvez, par exemple, utiliser <request> et <response> en tant qu'éléments de niveau supérieur distincts. Cela pourrait être un peu plus significatif, et renforcerait également l'argument de l'utilisation d'espaces de noms distincts (et de schémas) pour les deux types de message.

Mais si vous avez de bonnes raisons d'utiliser <stream> comme la balise de haut niveau pour les demande et la réponse, vous pouvez définir un schéma tel que <stream> est un type union. Les membres du syndicat contiendraient des éléments appropriés pour les demandes ou les réponses, mais pas les deux. Cette structure rendrait plus facile de garder les deux parties dans le même espace de noms, si cela semble être la bonne chose à faire. Je serais un peu plus enclin à suivre cette voie si je voyais que les protocoles de demande et de réponse étaient étroitement couplés, de sorte que les changements apportés à l'un nécessitent probablement des changements à l'autre. Si les types d'informations dans le jeu de réponses peuvent changer au fil du temps (ou par application), alors des espaces de noms distincts auraient plus de sens.