XML模式兼容性策略

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

在理想世界中,所有的需求都是预先知道的。xml规范将被起草以反映这些需求,然后再也不会改变。但在现实世界中,影响接口的漏洞会在项目的整个生命周期中被发现。其中一些变化的影响是良性的(例如引入一个新的非必需字段)。不过,对于其他类型的更改,可以选择以“不干净”的方式来实现它们,以保持向后兼容性,也可以选择以“更干净”的方式来实现它们,而不这样做。

例如,假设有一个新的需求,即在模式中“Field1”出现的地方添加“Field2”。由于“Field1”和“Field2”在功能/逻辑上是分组的,因此最自然的方法(我们称之为“方法1”)是替换以下用法:

<Field1></Field1>

具有

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

方法1的优点是易于实现和维护。最大的缺点是它破坏了接口。必须更改字段1的所有现有XPath。另一种方法(“方法2”)是在Field1旁边引入Field2,而不使用分组标记。

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

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

我的问题是,面对新的需求,处理xml更改的行业标准/最佳实践是什么 它是:

1. 将apporach 1强加于客户(新需求=接口更改)
3. 分支代码库。在分支中实施方法2,在主干中采用方法1(在项目开始时不太可行)。