是否有人嘗試運行此XML模式比較器？

Question

[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已更改：注釋已刪除。 等.....等

謝謝詹姆斯:)

Answer 1

首先，您所指的工具是我第一次看到它，因此，請隨便說些什么我都說一下。 快速瀏覽可供比較的選項后，我敢猜測您在此處有幾個選擇。 考慮到之前我是如何看過XSD和XML比較工作的，我首先需要解釋一些事情。

對於許多任務，XSD被簡化為XML或純文本。 您對XSD的期望似乎與比較兩個簡單XML時所看到的期望非常相似，即使名稱空間不同：

命名空間是您的問題。 通常，比較XSD與不同目標名稱空間的工具不應假定具有相同名稱的全局內容。 這是因為目標名稱空間也可以用來避免沖突並優化同音異義詞（家具中的表與計算/數據庫中的表）。 在您的情況下，它似乎用作版本控制機制，因為您希望繼續比較具有相同本地名稱的實體，即使完全限定名稱（由架構的targetNamespace限定）也不同。

對於您使用的API，似乎沒有一個可以提供名稱空間映射的選項（出於比較目的，將不同的值視為相同）。 我想說，看看報告的結構，這僅僅是因為更改名稱空間肯定會破壞一切……

嘗試手動遍歷模式定義的對象列表（例如元素 ， 復雜類型等），通過它們的本地名稱（在源/目標集中）手動匹配它們，然后一一調用（例如，對於元素 ）。 對於復雜類型，您可能需要手動遍歷其內容模型。

另一個策略（如果XSD不太復雜，則更容易）是將修訂復制到一個臨時位置，將targetNamespace字符串替換為舊值，然后在工具支持的情況下運行。

但是，比較XSD是一個非常復雜且有趣的主題，僅僅是因為什么是“重要”更改（是否中斷）與您使用該XSD的方式有關。 換句話說，以某種方式更改XSD不會對基於XSLT（了解XSD或不支持XSD）的代碼產生影響，而對於使用JAXB生成的類的人而言，這將是一場災難，而.NET使用者則不會。必須更改一行代碼...

上面顯示了其他情況，例如“傳遞”影響，其中更改基本類型（Depends Modified）將破壞XSD生成的代碼...而所描述的XML絕對相同。