How to verify that one XSD schema is a subset of another XSD schema?

Question

How can I verify that one XSD schema is a subset of another XSD schema?

We are creating a system-of-systems application using a collection of \"blueprint\" XSD schemas (

Answer 1

Thank you, @13ren, for your “beep” :)

This is a long comment, rather than an answer. I'll start from my earlier exchange with 13ren, more precise, it provides to a user all that is needed to define such an analysis model. What I meant is that in QTAssistant (this one) we have an XSD compare function; being XSD-aware, it does already a lot of things that text or XML-aware diff tool can't do (e.g. it doesn’t care how many XSD files, their layout changes between versions, etc.) For the provided UI, the diff engine works against the source model as opposed to the PSVI one. We could customize it to use the PSVI instead, since the latter is one step closer to what you actually need. We could also include the ability to have a custom rule set augment the compare between “base” and “revision”, in other words to allow the user to override the “=” operator we currently use.

I recognize that we don’t have anything out of the box allowing to override the compare of xsd:pattern facets; nor for something that to a human is easy to recognize such as xsd:positiveInteger vs. xsd:integer + xsd:minInclusive=1. Or comparing an xsd:all to a xsd:choice or xsd:sequence; and for the same we don’t parse out selectors and fields for XSD constraints which, much like regular expressions, wouldn't be easy to deal with.

Assuming that the goal is to find as many “discrepancies” as possible as opposed to rule them out entirely, QTAssistant has three more features which are helpful:

• for a given root element, it creates the complete list of simple XPaths. It can be applied as a quick way to spot "rogue" data. Out of the box this method of comparing doesn’t take into account structural patterns, i.e. if XPath1 and XPath2 denote two siblings in an instance XML, that XPath1 must precede XPath2), etc.
• It comes with a built in Query XSD Analyser. SQL can be used to query the XSD metamodel of a set to "spot" things that point out things a compare tool may be designed to ignore (for feasibility) and would therefore require a report to a human to decide.
  • XSD Refactoring (XSR). It is the only engine in the industry (that I know of at least) that is built from ground up with XSD refactoring and analysis in mind. I would think that if you can rule out xsi:type and, ideally, the use of substitution groups as well (on this one I still have to think) we could make available what we call the “canonicalization transformation” – a fancy word to convert a schema set to a Russian Doll design style, by relying on the PSVI model instead. There are many things that could be at play here: the use of id attribute, collapse of superfluous sequences, replacement of single option xsd:choices, etc. - which is why we have it in developement, but not published yet.

Another thing for which we had to provision in our compare (and you may want to consider) had to do with equivalence not only of the XSD/XML, but of the artifacts generated from XSD (e.g. Java classes through JAXB); to top it off, extensibility patterns, those that make use of wild cards (xsd:any and anyAttribute).

We (QTAssistant) are currently interested to work with you through some more specific requirements (we would need to start with an exchange of representative XSDs, NDAs I would assume, etc.), out of band, to see if indeed we could make it work. If you wish to proceed, feel free to contact me through the support address of the website associated with my SO profile.