CODEWITHSUNDEEP
xsd
Bob Stuart
Bob Stuart

Reputation: 103

How to compare 2 xsd schema files for equivalent functionality

I would like to compare 2 XSD schemas A and B to determine that all instance documents valid to schema A would also be valid to schema B. I hope to use this to prove that even though schema A and B are "different" they are effectively the same. Examples of differences this would not trigger would be Schema A uses types and Schema B declares all of it's elements inline.

I have found lots of people talking about "smart" diff type tools but these would claim the two files are different because they have different text but the resulting structure is the same. I found some references to XSOM but I'm not sure if that will help or not.

Any thoughts on how to proceed?

Upvotes: 8

Views: 10765

Answers (2)

Mads Hansen
Mads Hansen

Reputation: 66723

Membrane SOA Model - Java API for WSDL and XML Schema

package sample.schema;

import java.util.List;
import com.predic8.schema.Schema;
import com.predic8.schema.SchemaParser;
import com.predic8.schema.diff.SchemaDiffGenerator;
import com.predic8.soamodel.Difference;

public class CompareSchema {

  public static void main(String[] args) {
    compare();
  }
  
  private static void compare(){
    SchemaParser parser = new SchemaParser();

    Schema schema1 = parser.parse("resources/diff/1/common.xsd");

    Schema schema2 = parser.parse("resources/diff/2/common.xsd");

    SchemaDiffGenerator diffGen = new SchemaDiffGenerator(schema1, schema2);
    List<Difference> lst = diffGen.compare();
    for (Difference diff : lst) {
      dumpDiff(diff, "");
    }
  }
  
  private static void dumpDiff(Difference diff, String level) {
    System.out.println(level + diff.getDescription());
    for (Difference localDiff : diff.getDiffs()){
      dumpDiff(localDiff, level + "  ");
    }
  }
}

After executing you get the output shown in listing 2. It is a List of differences between the two Schema documents.

ComplexType PersonType has changed:   Sequence has changed:
    Element id has changed:
      The type of element id has changed from xsd:string to tns:IdentifierType.

Upvotes: 3

Petru Gardea
Petru Gardea

Reputation: 21638

My approach to this was to canonicalize the representation of the XML Schema.

Unfortunately, I can also tell you that, unlike canonicalization of XML documents (used, as an example, to calculate a digital signature), it is not that simple or even standardized.

So basically, you have to transform both XML Schemas to a "canonical form" - whatever the tool you build or use thinks that form is, and then do the compare.

My approach was to create an XML Schema set (could be more than one file if you have more namespaces) for each root element I needed, since I found it easier to compare XSDs authored using the Russian Doll style, starting from the PSVI model.

I then used options such as auto matching substitution group members coupled with replacement of substitution groups with a choice; removal of "superfluous" XML Schema sequences, collapsing of single option choices or moving minOccurs/maxOccurs around for single item compositors, etc.

Depending on what your XSD-aware comparison tool's features are, or you settle to build, you might also have to rearrange particles under compositors such as xsd:choice or xsd:all; etc.

Anyway, what I learned after all of it was that it is extremely hard to build a tool that would work nice for all "cool" XSD features out there... One test case I remember fondly was to deal with various xsd:any content.

I do wonder though if things have changed since...

Upvotes: 3

Related Questions