Do I have to declare multiple or just a single namespace for an XML-based server-client protocol?

Question

Hello dear Stackoverflow community

I'm currently working on a client-server application and I'd like to use XML for the protocol. Now, I'm rather unsure about declaring the XML namespaces and creating XML schemas. Needless to say that server and client send different things, i.e. the client sends requests and the server responds to them, and therefore use different tags and so on. The thing both sides have in common is that the XML data being sent is stream-like and the document's root is called <stream>, but - as I said - the tags in are different (each standing for a request or response respectively). Now, are these two different XM languages? Shall I declare one namespace (and thus one XSD) for each of them? Or shall I use one for all and add an attribute "sender" to defining the side (server | client)? In the latter case: How do I differentiate between the attribute values then? That is, how to declare in the XSD which tag is allowed for what "sender" value?

Thanks in advance!

Answer 1

Since the two <stream> elements have different contents, they are two different elements with the same local name, but need to validate differently. This implies that they must be in separate namespaces, hence separate schemas.

However, if the contents of the sender's and receiver's <stream> elements share elements or attributes in common, then you should add a third schema, with the common contents. The other two schemas would import the common schema.

Answer 2

As is often the case, there doesn't seem to be one right answer for this.

I don't know what advantage there is to using the same element tag (i.e., <stream> ) for the request and response. You could, for example, use <request> and <response> as separate top-level elements. That might be a bit more meaningful, and would also strengthen the argument for using distinct namespaces (and schemas) for the two message types.

But if you have good reasons for using <stream> as the top-level tag for both request and response, then you could define a schema such that <stream> is a union type. The union members would contain elements that are appropriate for either requests or responses, but not both. This structure would make it easier to keep the two sides in the same namespace, if that seems like the right thing to do.

I'd be a little more inclined to go this route if I saw the request and response protocols as being tightly coupled, such that changes to one probably require changes to the other as well. If the types of information in the response set can change over time (or by application), then separate namespaces would make more sense.