0

I was tasked with migrating an xsd generation tool to something new. But since the XSD's are part of a publicly published interface they should not change.
The new tool does things a bit differently, so when comparing the xsd's with a text diff tool I get a lot of differences, for example the order of global elements is different, order of enumeration tags is different, etc...

Anyone know a tool (or a method -> I do write code) that can compare XSD's functionally, ignoring changes that doe not change the content of the XSD?

And since I have a lot of XSD's to compare (about 740 in total) I would prefer a tool that could do them all at once and then give me some kind of report with the details.

|improve this question|||||
  • Instead, I would produce a bunch of XML files depicting what happens in your live application and validate them towards your 2 schemas. Or more precisely: create test XML files that validate under the old schema, then verify they validate to the new one. This will have various benefits, far outside of the specific XSD problem, but also I think it is more relevant to test stuff as they happen instead of XSD "purity" or "correctness" as they are often multiple way to do the same thing. – Patrick Mevzek Jan 12 '18 at 17:47
  • @PatrickMevzek Thanks for the suggestion Patrick, but I'm afraid there are just too much possible variations of xml files to validate them all. Another problem is that one of the requirements is that the XSD's themselves are the same, meaning they have the same structure, names, files, etc... The idea is that the companies that use these XSD's in their systems don't have any development work due to the switch from the old to the new system. – Geert Bellekens Jan 13 '18 at 7:23
  • Have you tried outputs of the XSD files using XML canonicalization rules? This should ensure orders and things like that, making comparison possible. In fact, it is even the only sane way to compare two XML files, and XSD are XML files. See w3.org/TR/xml-c14n and search for "C14N" in your tools (editors and XML libraries). – Patrick Mevzek Jan 13 '18 at 20:12
2

That's quite a challenge, because so many differences are possible: you may have to make compromises depending on what you actually encounter. (For example, you may or may not need to bother with named model groups, depending on whether either of the schemas you are comparing actually uses them. Most schemas don't.)

If I were doing this (and of course I'm biased towards using my own tools) I would start by using Saxon's schema validator to generate SCM (schema component model) files for both schemas. This will do a fair bit of normalization, e.g. handling the difference between inline types and references to named global types. I would then write an XSLT stylesheet to do further normalization on the SCM files, for example sorting components into a canonical order, sorting enumeration values, and so on; also, eliminating the parts of the SCM files that aren't relevant, such as finite state machine details. I would then probably write a custom XSLT comparison module to compare the two normalized SCM files (along the lines of https://dvcs.w3.org/hg/xslt30-test/file/tip/runner/compare.xsl which is used for comparing XSLT test results) - the key being that you don't just want a boolean answer saying whether they are the same or different, you want to highlight the differences. Alternatively you could use fn:deep-equal to test whether they are the same, and then using a visual diff tool to examine them side-by-side if not.

|improve this answer|||||
  • Thanks Michael, that is useful input. I'm still hoping to find a more out-of-the box solution as we will need to compare the files only once. – Geert Bellekens Jan 12 '18 at 13:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.