我们正在构建一堆SOAP Web服务来支持各种后端系统的访问。
在定义我们的请求/响应消息XML时，我们看到多个服务需要具有不同“强制/可选”字段的“帐户”对象。
我们应该如何在同一条消息上定义和强制执行这些“强制/可选”字段的验证？我看到了这些选项
优点：设计时间清晰度。
缺点：对象类型的扩散，对象的重复使用，
优点：设计时间清晰度。
缺点：不确定是否支持Extend + Restriction功能（java，.Net）
优点：简单
缺点：没有设计时验证。需要通过规范文档传达字段要求。
你对此有何想法？
答案 0 :(得分：2)
我必须假设：i）你称之为可选字段的一些实际上是对所有帐户都不适用的字段（没有意义）和ii）我们不是在谈论琐碎的场景（比如两个每种情况都有2个字段的帐户类型。
首先，我要说除非你真的很幸运，从需求的角度来看，无论你选择什么样的选择，你最终都会得到某种“运行时验证”。 XML Schema无法表达一些常见的数据验证要求，例如交叉字段验证;或者仅仅是因为XML中的数据不足以提供规则以验证消息的完整性（消息中的数据是XML正在被解除/编组时可用的内容的子集）。
其次，我会避免通过restricton导出新的复杂类型;从创作的角度来看，你在重用方面没有取得多大成就，你最终可能会遇到XSD如何解释代码工具的问题。我喜欢认为通过限制获得的初衷是为人们提供在xsd中使用的工具：重新定义场景;对于那些不想摆弄其他人创作的XML Schema的人。如果拥有（作者）模式，可以通过首先定义“较小”对象并从中定义 extend 来解决限制的需要。
关于“对象的扩散”，你也可以选择＃2选项（与＃1相比）;我的意思是，我所知道的所有工具都会为你在XSD中的每个命名（全局）复杂类型创建一个类;因此，如果您必须拥有三种类型的帐户，那么对于方案＃1，您将有三个，如果您选择从一个或多个基类扩展，那么将有四个，或者如此;最糟糕的情况是后者需要三个专业（具体如果你愿意的话）;无论如何，从我的经验来看，现实生活场景中的差异并不能真正地决定这种或那种方式。
扩展XML Schema中的基类型有利于重用;然而，重用会带来耦合;如果您从前向/后向兼容性的角度分析这一点，那么在基类型中扩展某些内容可能会破坏一些不希望更改的服务客户端的XML解组（反序列化）他们的代码库，但你想只为所有人维护一个Web服务端点;在这种情况下，依赖于合成器末尾的xsd：any的前向兼容性策略（xsd：sequence）将在您的第一个版本中变得无用，并扩展您的基本类型。
还有更多;因此，我不认为有正确的答案，只是因为你似乎通过设定你的利弊而暗示的标准。
我在下面的所有首选选项都假设您高度重视要求以确保服务的向前/向后兼容性，并且您希望最大限度地降低客户必须处理服务的成本（因为XML架构更改） ）。
我想说，如果您的所有域名（特别是帐户）可以完全建模（假设基本上没有未来的变化）和，那么就有足够的共性来证明重用，然后选择＃2。否则，请使用选项＃1，因为我还没有看到不会改变的事情......
如果你的域的建模可以完成80％或更多（或者你认为很高的某些数字）和有足够的通用性来证明重用，那么我仍然会选择＃2，但需要注意的是，每个帐户的公共属性的任何未来扩展都必须应用于每个帐户（基本上通过执行＃1将您的选项转换为混合帐户）。
除此之外，我会去＃1。哇，我简直不敢相信我写了所有这些......