XML 架构迁移

Question

我正在做一个项目，我们需要以 XML 格式保存数据。问题是，随着时间的推移，我们希望数据的格式/模式发生变化。我们希望能够做的是生成脚本以在不同的模式版本之间迁移我们的数据。我们将我们的产品分发给成千上万的客户，因此我们需要能够在客户站点运行/应用这些脚本(因此我们不能仅手动进行转换)。我认为我们正在寻找的是某种 XML 数据迁移工具。在我看来，理想的工具可以:

1. 对两个模式进行“XML 差异”以识别添加/删除/更改的节点。

2. 允许我们指定转换函数。因此，例如，我们可能会在我们的模式中添加一个新元素，它是旧元素的函数。 (例如，新元素 C，其中 C = A+B，A + B 是旧元素)。

所以我想我正在寻找一种 XML 差异和补丁工具，它也可以应用转换功能。我正在寻找的一个工具是 Altova's MapForce .我相信这里的其他人不得不处理 XML 数据格式迁移。你是怎么处理的？

编辑:一点澄清。我计划做的“差异”是在架构或 .xsd 文件上。将对遵循给定模式的特定数据集进行实际更改。这些数据集将是 .xml 文件。因此，它是架构的“差异”，有助于确定需要对数据集进行哪些更改才能将它们从一种方案迁移到另一种方案。

Answer 1

“对两个模式进行“XML 差异”以识别添加/删除/更改的节点。”

XSD 是文本，所以这很简单。

但是，如果您对 XSD 进行了重大的结构更改，则自动差异将基本上无用。

如果您对 XSD 进行小的外观更改，这可能会有所帮助。

“允许我们指定转换函数...”

那不是很好吗。可悲的是，发生一些微不足道的变化(“新元素 C，其中 C = A+B，A + B 是旧元素”)的可能性几乎为零。为什么要进行这种微不足道的更改？

不，当您“...将我们的产品分发给成千上万的客户”时，您不会进行微不足道的外观更改。您保存更改，使它们真正成为史诗般的，并“创造重大值(value)”。

不，自动架构迁移的可能性几乎为零。

相反，应针对可迁移性进行设计。

1. 确保版本号在您的 XSD 路径中很显眼。理想情况下，在 XSD 名称本身中。

2. 每个 XSD 更改都是一个严重的治理问题 (SGI™)。每个人都参与。然后你就在那里编写迁移脚本。不是之后。不用工具。但作为 XSD 更改的一部分。

   架构不会自发改变。有人改变他们是有原因的。有人可以指定更改，以便其他人可以编写(或更新)迁移脚本。

这太严重了，不能相信“自动化”工具。这需要真人的真正大脑真正专注于此，就好像他们的工作依赖于此一样。