XML 模式兼容性策略

Question

我使用的应用程序使用大量 xml 接口进行集成和数据导入/导出。我们使用 JAXB 从这些接口映射到我们的域对象模型。我们经常面临的一个挑战是如何处理在项目过程中面对新需求时对这些接口进行更改的需要。

在理想世界中，所有需求都是预先知道的。 xml 规范将被起草以反映这些要求，然后永远不会改变。但在现实世界中，影响接口的差距会在项目的整个生命周期中被发现。其中一些变化的影响是良性的（例如，引入一个新的非必填字段）。但是，对于其他类型的更改，可以选择以保持向后兼容性的“不干净”方式或不保持向后兼容性的“更清洁”方法来实现它们。

例如，假设有一个新要求，即在架构中出现“Field1”的任何地方添加“Field2”。由于 'Field1' 和 'Field2' 在功能/逻辑上分组，最自然的方法（我们称之为“方法 1”）是替换以下用法：

<Field1></Field1>

与

<GroupingName>
    <Field1></Field1>
    <Field2></Field2>
</GropuingName>

方法 1 的优点是易于实施和维护。最大的缺点是它破坏了界面。 Field1 的所有现有 XPath 都必须更改。另一种方法（“方法 2”）是将 Field2 与 Field1 一起引入，而不使用分组标签。

<Field1></Field1>
<Field2></Field2>

方法 2 保留了向后兼容性，但违反了“DRY”，并且不保证 Field2 出现在 Field1 所在的任何地方。

我的问题是，面对新要求处理 xml 更改的行业标准/最佳实践是什么是：

1. 强制客户使用方法 1（新要求 = 界面更改）
2. 捂住鼻子，采取方法 2。
3. 分支代码库。在分支中实施方法 2，并在主干线中采用方法 1。 （在项目开始时不太可行）。
4. 其他？

Answer 1

修改 XSD 以定义命名组；不是复杂类型：

并将“Field1”的每个元素声明替换为 这确保了“Field2”必须出现在“Field1”之后的任何“Field1”出现的地方。 设置是否发生是可选的。