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