XML 架构迁移
我正在开发一个项目，需要以 XML 格式保存数据。 问题是，随着时间的推移，我们预计数据的格式/模式会发生变化。 我们想要做的是生成脚本来跨不同模式版本迁移数据。 我们将产品分发给数千名客户，因此我们需要能够在客户站点运行/应用这些脚本（因此我们不能仅手动进行转换）。 我认为我们正在寻找某种XML数据迁移工具。 在我看来，理想的工具可以：
对两个模式进行“XML 比较”以识别添加/删除/更改的节点。
允许我们指定转换函数。 因此，例如，我们可能会向架构中添加一个新元素，该新元素是旧元素的函数。 （例如，新元素 C，其中 C = A+B，A + B 是旧元素）。
所以我想我正在寻找一种 XML diff 和 patch 工具，它也可以应用转换功能。 我正在寻找的一个工具是 Altova 的 MapForce 。 我确信这里的其他人都必须处理 XML 数据格式迁移。 你是怎么处理的呢？
编辑： 澄清一点。 我计划做的“差异”是在架构或 .xsd 文件上。 实际的更改将对遵循给定模式的特定数据集进行。 这些数据集将是 .xml 文件。 因此，它是模式的“差异”，可以帮助找出需要对数据集进行哪些更改才能将它们从一种模式迁移到另一种模式。
I am working on a project where we need to save data in an XML format. The problem is, over time we expect the format / schema for our data to change. What we want to be able to do is to produce scripts to migrate our data across different schema versions. We distribute our product to thousands of customers so we need to be able to run / apply these scripts at customer sites (so we can't just do the conversions by hand). I think that what we are looking for is some kind of XML data migration tool. In my mind the ideal tool could:
Do an "XML diff" of two schema to identify added/deleted/changed nodes.
Allow us to specify transformation functions. So, for example, we might add a new element to our schema that is a function of the old elements. (E.g. a new element C where C = A+B, A + B are old elements).
So I think I am looking for a kind of XML diff and patch tool which can also apply transformation functions. One tool I am looking at for this is Altova's MapForce . I'm sure others here have had to deal with XML data format migration. How did you handle it?
Edit:
One point of clarification. The "diff" I plan to do is on the schema or .xsd files. The actual changes will be made to particular data sets that follow a given schema. These data sets will be .xml files. So its a "diff" of the schema to help figure out what changes need to be made to data sets to migrate them from one scheme to another.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
“对两个架构进行“XML 比较”以识别添加/删除/更改的节点。”
XSD 是文本，因此这很简单。
但是，如果您对 XSD 进行重大结构更改，则自动差异将基本上毫无用处。
如果您对 XSD 进行小的外观更改，这可能会有所帮助。
“允许我们指定转换函数...”
这不是很好吗？ 遗憾的是，发生一些微小变化（“新元素 C，其中 C = A+B，A + B 是旧元素”）的可能性几乎为零。 为什么要做这种微不足道的改变？
不，当您“……将我们的产品分发给成千上万的客户”时，您不会做出微不足道的表面改变。 您保存更改，使它们真正成为史诗般的内容，并“创造重大价值”。
不，自动模式迁移的可能性几乎为零。
相反，应针对可迁移性进行设计。
确保版本号在您的 XSD 路径中显眼。 理想情况下，在 XSD 名称本身中。
每个 XSD 更改都是一个严重的治理问题 (SGI™)。 每个人都参与。 您可以立即编写迁移脚本。 不是之后。 不是用工具。 但作为 XSD 更改的一部分。
架构不会自发改变。 有人出于某种原因改变它们。 有人可以指定更改，以便其他人可以编写（或更新）迁移脚本。
这实在是太严重了，不能信任“自动化”工具。 这需要真实的人真正关注这一点，就好像他们的工作依赖于它一样。
"Do an "XML diff" of two schema to identify added/deleted/changed nodes."
XSD's are text, so this is trivial.
However, if you make dramatic structural changes to the XSD's, the automated diff will be largely useless.
If you make small, cosmetic changes to the XSD's, this might be helpful.
"Allow us to specify transformation functions..."
Wouldn't that be nice. Sadly, the odds of there being some trivial change ("new element C where C = A+B, A + B are old elements") are almost nil. Why make that kind of trivial change?
No, when you "... distribute our product to thousands of customers", you don't make trivial, cosmetic changes. You save up the changes so that they are truly epic, and "create significant value."
No, the odds of there being an automated schema migration is nearly zero.
Instead, design for migratability.
Be sure that the version number is prominent in your XSD paths. Ideally, in the XSD name itself.
Each XSD change is a Serious Governance Issue (SGI™). Everyone participates. And you write the migration scripts right then and there. Not afterwards. Not with tools. But as part of an XSD change.
Schema don't spontaneously change. Someone changes them for a reason. That someone can specify the changes so someone else can write (or update) the migration script.
This is far, far too serious to trust to "automated" tools. This requires real brains of real people really focusing on this as if their jobs depended on it.
我最终编写了一个工具来执行此操作，并将结果作为 SourceForge 项目发布。
什么：
此工具可帮助创建脚本以将 XML 数据从 XML 架构的一个版本迁移到同一架构的更高版本。 该工具通过区分 XSD 文件并发出 XSLT 2.0 来自动迁移 XML 数据来创建这些脚本。 这对于简单的数据更改非常有效，并且可以用作更复杂的数据更改的“起始”代码。
地点：
https://sourceforge.net/projects/xsdevolver/
背景：
我工作的公司销售一种收缩包装的应用程序，我们根据指定的 XSD 架构以 XML 格式保存工作簿。 随着时间的推移，我们预计此模式的格式会发生变化。 我们想要一种方法来帮助我们区分随着时间的推移而演变的模式版本，并生成初始 XSLT 以将数据从较旧版本的模式迁移到较新版本的模式。
用法：
XMLSchemaEvolver SchemaVersion1.xsd SchemaVersion2.xsd
输出：
显示哪些元素已更改的架构差异
XSLT 将 XML 数据从 SchemaVersion1 转换为 SchemaVersion2
它是如何工作的？
基本思想是这样的：
1) 比较两个xml 架构 (xsd) 文件。
2) 每个更改都被分类为 INSERT、DELETE、MOVE 或 RENAME 操作。
3) 对于每个操作，发出简单的 XSLT 来执行所需的数据更改。
4) 这些数据更改操作是根据 Jesper Tverskov 链接文本。 我们的代码发出的转换的完整列表可以在文档文件夹中的 XSLT Transformations.txt 中找到。
I ended up writing a tool to do this and released the result as a SourceForge project.
What:
This tool helps create scripts to migrate XML data from one version of an XML schema to a later version of the same schema. The tool creates these scripts by differencing XSD files and emitting XSLT 2.0 to automatically migrate XML data. This works well for simple data changes and can be used as "starter" code for more complex data changes.
Where:
https://sourceforge.net/projects/xsdevolver/
Background:
The company I work for sells a shrink-wrapped application where we save a workbook in an XML format according to a specified XSD schema. Over time, we expect the format of this schema to change. We wanted a way to help us diff schema versions as they evolve over time and generate initial XSLT to migrate data from older versions of the schema to newer versions of the schema.
Usage:
XMLSchemaEvolver SchemaVersion1.xsd SchemaVersion2.xsd
Output:
A schema diff showing what elements have been changed
XSLT to translate XML data from SchemaVersion1 to SchemaVersion2
How does it work?
The basic idea is this:
1) Do a diff of two xml schema (xsd) files.
2) Each change is classified as an INSERT, DELETE, MOVE or RENAME operation.
3) For each of these operations, emit simple XSLT to carry out the desired data change.
4) These data change operations are modeled after a set of standard XSLT operations suggested by Jesper Tverskov link text. A full list of the transformations emitted by our code can be found XSLT Transformations.txt in the documentation folder.
正如 @S.Lott 所说，自动化转换的能力不太可能。 然而，XSLT 是一个出色的工具，用于正式定义如何将 XML 从一种格式转换为另一种格式。 它不能自动生成（据我所知），但以这种方式做事是非常值得的。
As @S.Lott says, the ability to automate transformations is unlikely. However, XSLT is a fantastic tool for formally defining how to transform XML from one format to another. It can't be automatically generated (as far as I know), but it's well worth doing things this way.