在更新中，我有单独的键元素类型来标识对象（当数据项可以由多个属性标识时，为数据项创建单独的XSD类型是好的Web服务设计的关键吗？）所以下面单独数据元素类型的所有元素都是可选的，只支持1-n个元素的更新。
<xs:complexType name="tSomeData">
<xs:sequence>
<xs:element name="id" type="xs:int" minOccurs="0"/>
<xs:element name="name" type="xs:string" minOccurs="0"/>
<xs:element name="externalname" type="xs:string" minOccurs="0"/>
<xs:element name="manufacturer" type="xs:string" minOccurs="0" />
<xs:element name="manufacturertype" type="xs:string" minOccurs="0" />
<xs:element name="area" type="xs:string" minOccurs="0"/>
<xs:element name="doublevalue" type="xs:double" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
此类型用于：
- Get的响应（响应中的所有元素）
- 添加请求（除了id之外的所有元素，因为系统会生成它）
- 更新请求（1-n个元素，只更新请求中的元素，不更新id）
所以我的问题是：这可以吗（因为没有明确说明每个操作中tSomeData中应该有什么）？
如果我的方法不好，我应该有类型吗：
- tSomeDataAdd（所有必需元素，无id元素）
- tSomeDataUpdate（全部可选，无id元素）
- tSomeDataGet（全部为必填项，还有id元素）
（因为这样就会明确说明消息中的数据到底是什么）？
Get/Add/Update可以接受tSomeData，这将在实现中有很大帮助，并使接口定义不那么冗长。
这是一个可能会得到不同答案的问题，这取决于你问的是谁，取决于它将如何实现——从编程语言的角度来看，取决于如何进行测试和管理部署。
如果人们希望尽可能多地依赖XSD验证，而不是自己在代码中进行验证，那么"一刀切"的XSD不会减少验证。另一方面，如果我正在建模，但我已经延迟交付了，或者如果开发人员抱怨XSD到代码绑定工具生成的类数量太多，那么最好给他们最少的类；更重要的是，如果已经有一个文档描述了业务规则，和/或如果规则非常复杂，以至于除了基本的类型系统检查之外，XSD无论如何都不会做太多。。。
如果你的团队规模庞大，通常是在大型任务关键型系统上，那么你希望把所有东西都分解成小块，进行独立的开发和测试；使用特定于用例的专用模型会容易得多。我见过一些地方，每个操作都作为一个独立的部署单元来实现，以降低关键任务系统中的回归测试成本。对于这些，没有人关心类的总数，因为每个团队只关注分配给他们的一小部分；"模块"之间的耦合越小越好。
就我个人而言，我可以轻松管理大型车型；事实证明，这比必须"出售"一个多价模型更令人头疼，即使这是一种美丽和优雅思维的锻炼；既然这样的模型需要很长的说明书，出于各种原因，没有人会读，为什么要麻烦呢？。。。有趣的是，无论如何，使用一次性软件和所有这些，它可能不会产生长期的影响。。。
有很多方法可以重复使用；并且在较大模型中处于不同级别；对于你所描述的，我会选择三种不同的类型。