可以进行哪些向后兼容的 XSD 更改？答案

【问题标题】：What backward-compatible XSD changes can be made?可以进行哪些向后兼容的 XSD 更改？
【发布时间】：2015-05-12 18:28:23
【问题描述】：

如何在不影响消费应用程序的情况下更改 REST 接口的 XML 架构（如果它们不升级）？

【问题讨论】：

这些现有消费者是否根据（旧）模式验证 XML 数据？如果他们这样做，你没有很多选择。您不能添加新元素和属性，甚至是可选的，因为它们不存在于旧版本的架构中，因此无法验证。

【解决方案1】：

以下是一些请求 XSD 更改示例，您可以和不可以进行这些更改以保持与先前界面版本的向后兼容性。

可以做

【讨论】：

你需要改写你的答案来考虑消息的方向；就目前而言，您的回答部分错误。例如，在响应中添加必需元素可能不会破坏旧客户端。可以从响应中删除一个枚举值（如果有多个），而不会产生不利影响。
@PetruGardea 如果现有消费者针对（旧）模式验证响应，则响应中额外的必需元素仍然会造成问题。
@ErwinBolwidt - 如果消费者根据旧模式验证响应，那么这里有两个选项（保持问题相关）：a）如果该字段是可选的，服务器必须“刮“新字段以匹配客户端的版本，或者 b) 客户端模式是前向兼容的，因此服务器不需要做任何事情。在这两种情况下，您的观点都变得无关紧要。您的评论还提供了不正确的信息，因为它忽略了架构可能已设置为向前兼容的事实，即使用某种可以验证其他内容的 xsd:any/anyAttribute
@PetruGardea 我在 OP 的问题中没有看到任何提及为使架构“向前兼容”做了任何特别的事情。如果 OP 有这样的远见，我相信他或她会在问题中提到这一点。
@PetruGardea：我已经更新了我的答案，以澄清它与 request 消息更改有关。我邀请您为 responses 写一个相应的答案，因为我尊重您在该领域的专业知识。我敢肯定，除了接口定义中明确的约束之外，您会注意不要对调用者的实现做出任何假设。谢谢。

【解决方案2】：

【讨论】：