[http://www.membrane-soa.org/soa-model-doc/1.4/java-api/compare-schema-java-api.html]
我试过了，但我能从我的模式中得到的只有这个 targetNamespace 从（schema1 的命名空间）更改为（schema2 的命名空间） 而且我使用与下载部分中的包完全相同的代码和完全相同的库。如有任何建议，我将不胜感激。
我的目标是兑现他们的承诺：D
元素 createResponse 已更改： 复杂类型已更改： 顺序发生了变化： 添加了元素 NewElementForTest。
ComplexType GetAllType 已更改： 注释已删除。 等等……等等……
谢谢詹姆斯 :)
【问题讨论】：
首先，您提到的工具是我第一次看到它，所以我对它说的任何话都持保留态度；在快速查看可供您比较的选项后，我敢猜测您在这里有几个选项。考虑到我之前看到 XSD 和 XML 比较的工作方式，我需要先解释一些事情。
对于许多任务，XSD 被简化为 XML 或纯文本。您对 XSD 的期望似乎与比较两个简单 XML 时所看到的非常相似，即使命名空间不同：
命名空间是您的问题。一般来说，比较具有不同目标命名空间的 XSD 的工具不应该假设任何关于具有相同名称的全局内容。这是因为目标命名空间也可用于避免冲突和改进同音异义词（家具中的表与计算/数据库中的表）。在您的情况下，它似乎被用作版本控制机制，因为您希望继续比较具有相同本地名称的实体，即使完全限定名称（由架构的 targetNamespace 限定）不同。
对于您正在使用的 API，似乎没有可以提供命名空间映射的选项（即出于比较目的，将不同的值视为相同）。我想说，看看报告的结构，这仅仅是因为更改命名空间肯定会破坏一切......
尝试手动循环遍历模式定义的对象列表（例如elements、complex types等），手动匹配它们的本地名称（在源/目标集中），然后调用一个尽你所能（例如elements）。对于复杂类型，您可能需要手动遍历其内容模型。
另一种策略（如果 XSD 不是那么复杂，则更容易）可能是将修订复制到临时位置，将 targetNamespace 字符串替换为旧值，然后使用您的工具支持的内容运行。
虽然比较 XSD 是一个非常复杂和有趣的主题，但仅仅是因为什么是“重要的”变化（破坏与否）取决于您如何使用 XSD。换句话说，以某种方式更改 XSD 不会对基于 XSLT（XSD 感知与否）的代码产生影响，而对于使用 JAXB 生成的类的人来说将是一场灾难，同时 .NET 使用者不会必须更改一行代码...
上面显示了其他情况，例如“传递性”影响，其中更改基类型（取决于修改）会破坏从 XSD 生成的代码......而描述的 XML 绝对是相同的。
【讨论】：