>执行两个模式的“XML diff”以识别添加/删除/更改的节点.
>允许我们指定转换函数.因此,例如,我们可能会向我们的架构添加一个新元素,该元素是旧元素的函数. (例如,新元素C,其中C = A B,A B是旧元素).
所以我认为我正在寻找一种XML差异和补丁工具,它也可以应用转换功能.我正在寻找的一个工具是Altova’s MapForce.我相信其他人必须处理XML数据格式迁移.你是怎么处理的呢?
编辑:
一点澄清.我计划做的“差异”是在架构或.xsd文件上.将对遵循给定模式的特定数据集进行实际更改.这些数据集将是.xml文件.因此它是模式的“差异”,以帮助确定需要对数据集进行哪些更改以将它们从一个方案迁移到另一个方案.
XSD是文本,所以这是微不足道的.
但是,如果您对XSD进行了戏剧性的结构更改,那么自动差异将很大程度上无用.
如果您对XSD进行小的,美观的更改,这可能会有所帮助.
“允许我们指定转换函数……”
这不是很好.可悲的是,存在一些微不足道的变化的可能性(“新元素C,其中C = A B,A B是旧元素”)几乎为零.为什么要做那种微不足道的改变?
不,当您“……将产品分发给成千上万的客户”时,您不会做出微不足道的改变.您可以保存更改,使它们真正成为史诗,并“创造重要价值”.
不,自动架构迁移的几率几乎为零.
相反,设计可迁移性.
>确保版本号在XSD路径中很突出.理想情况下,在XSD名称中.
>每个XSD变更都是严重治理问题(SGI™).每个人都参与其中.然后你就可以编写迁移脚本了.不是之后.没有工具.但作为XSD变革的一部分.
架构不会自发地改变.有人因为某个原因改变了它们.有人可以指定更改,以便其他人可以编写(或更新)迁移脚本.
对于“自动化”工具来说,这远远不够严重.这需要真正关心真正人的大脑,好像他们的工作依赖于此.