我正在开发一个需要以XML格式保存数据的项目。问题是,随着时间的推移,我们希望数据的格式/架构发生变化。我们希望能够生成脚本以跨不同的模式版本迁移我们的数据。我们将产品分发给成千上万的客户,因此我们需要能够在客户站点运行/应用这些脚本(因此我们不能手动进行转换)。我认为我们正在寻找的是某种XML数据迁移工具。在我看来,理想的工具可以:
执行两个模式的“XML diff”以识别添加/删除/更改的节点。
允许我们指定转换函数。因此,例如,我们可能会向我们的架构添加一个新元素,该元素是旧元素的函数。 (例如,新元素C,其中C = A + B,A + B是旧元素)。
所以我认为我正在寻找一种XML diff和patch工具,它也可以应用转换功能。我正在考虑的一个工具是Altova's MapForce。我相信其他人必须处理XML数据格式迁移。你是怎么处理的?
编辑: 一点澄清。我计划做的“差异”是在架构或.xsd文件上。将对遵循给定模式的特定数据集进行实际更改。这些数据集将是.xml文件。因此它是模式的“差异”,以帮助确定需要对数据集进行哪些更改以将它们从一个方案迁移到另一个方案。
答案 0 :(得分:5)
“执行两个架构的”XML diff“以识别添加/删除/更改的节点。”
XSD是文字,所以这很简单。
但是,如果你对XSD做出了戏剧性的结构性改变,那么自动差异很大程度上是无用的。
如果您对XSD进行小的,美观的更改,这可能会有所帮助。
“允许我们指定转换功能......”
那不是很好。遗憾的是,存在一些微不足道的变化(“新元素C,其中C = A + B,A + B是旧元素”)的几率几乎为零。为什么要做出那种微不足道的改变?
不,当您“......将我们的产品分发给成千上万的客户”时,您不会做出微不足道的改变。您可以保存更改,使它们真正成为史诗,并“创造重要价值”。
不,自动架构迁移的可能性几乎为零。
相反,设计可迁移性。
确保版本号在XSD路径中显眼。理想情况下,在XSD名称中。
每次XSD更改都是严重的治理问题(SGI™)。每个人都参与其中。然后你就可以编写迁移脚本了。不是之后。没有工具。但作为XSD变革的一部分。
架构不会自发地改变。有人因为某个原因改变了它们。有人可以指定更改,以便其他人可以编写(或更新)迁移脚本。对于“自动化”工具来说,这太过于严重了。这需要真正关心真实人的大脑,好像他们的工作依赖于此。
答案 1 :(得分:3)
我最终编写了一个工具来执行此操作,并将结果作为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 link text建议的一组标准XSLT操作之后建模的。我们的代码发出的转换的完整列表可以在文档文件夹中找到XSLT Transformations.txt。
答案 2 :(得分:0)
正如@ S.Lott所说,自动化转换的能力不太可能。但是,XSLT是一个很好的工具,用于正式定义如何将XML从一种格式转换为另一种格式。它不能自动生成(据我所知),但这样做非常值得。