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