我是否必须声明基于XML的服务器客户端协议的多个或仅声明一个命名空间?

我是否必须声明基于XML的服务器客户端协议的多个或仅声明一个命名空间?,xml,xsd,protocols,Xml,Xsd,Protocols,我目前正在开发一个客户机-服务器应用程序,我想使用XML作为协议。现在,我不确定如何声明XML名称空间和创建XML模式 不用说,服务器和客户端发送不同的东西,即客户端发送请求,服务器响应请求,因此使用不同的标记等等。双方的共同点是,发送的XML数据是流式的,文档的根被称为,但正如我所说的,中的标记是不同的(每个分别代表请求或响应) 现在,这是两种不同的XM语言吗?我应该为它们每个声明一个名称空间(从而声明一个XSD)吗?或者我应该使用“一对所有”并添加一个属性“发送者”来定义端(服务器|客户端)

我目前正在开发一个客户机-服务器应用程序,我想使用XML作为协议。现在,我不确定如何声明XML名称空间和创建XML模式

不用说,服务器和客户端发送不同的东西,即客户端发送请求,服务器响应请求,因此使用不同的标记等等。双方的共同点是,发送的XML数据是流式的,文档的根被称为
,但正如我所说的,中的标记是不同的(每个分别代表请求或响应)

现在,这是两种不同的XM语言吗?我应该为它们每个声明一个名称空间(从而声明一个XSD)吗?或者我应该使用“一对所有”并添加一个属性“发送者”来定义端(服务器|客户端)?在后一种情况下:如何区分属性值?也就是说,如何在XSD中声明允许哪个标记作为什么“发送者”值?

由于两个
元素具有不同的内容,它们是具有相同本地名称的两个不同元素,但需要进行不同的验证。这意味着它们必须位于单独的名称空间中,因此是单独的模式


但是,如果发送方和接收方的
元素的内容共享相同的元素或属性,那么您应该添加第三个模式,该模式具有相同的内容。其他两个模式将导入公共模式。

通常情况下,似乎没有一个正确的答案

我不知道对请求和响应使用相同的元素标记(即,
)有什么好处。例如,您可以使用
作为单独的顶级元素。这可能更有意义,并且还将加强对这两种消息类型使用不同名称空间(和模式)的论证

但是如果您有充分的理由使用
作为请求和响应的顶级标记,那么您可以定义一个模式,使得
是一个
联合类型。工会成员将包含适用于请求或响应的元素,但不能同时适用于两者。如果这样做似乎是正确的,那么这种结构将更容易将双方保持在同一名称空间中

如果我认为请求和响应协议是紧密耦合的,那么我会更倾向于走这条路线,这样对一个协议的更改可能也需要对另一个协议进行更改。如果响应集中的信息类型可以随时间(或应用程序)而改变,那么单独的名称空间将更有意义