W3C XML Schema Interoperability?

There seems to be increasing concern within the Web services community regarding the interoperability of W3C's XML Schema.

Some would like a formally defined subset of XML Schema, omitting some of the more advanced features, that would be geared towards consumption by Web services toolkits that generate databinding code in their favorite programming language. Others simply want a definitive answer to the question: "is this schema valid?" so that when they publish the schema for others to use, they can do so with confidence such that when someone complains that their tool of preference says that the schema is not valid or is unable to process the schema, they can respond: "your tool is incorrect; suggest you contact the vendor and have them fix it".

Some want to limit the use of XML schema to a subset capable of express their service's underlying programming-language-specific data model as XML. They typically start with a Java, C# or other programming language-specific interface/data model and use a development tool to generate a corresponding schema and databinding logic. This is often referred to as the bottoms-up design approach.

Others want to leverage the full expressiveness of XML that XML Schema can offer. They are designing schema for messages and document exchanges that are typically XML-centric; although sometimes leveraging the features of XML Schema that lean towards object-orientation. This is frequently called
the top-down design approach.

Whether the service is designed using the bottoms-up or top-down approach, the service consumer code is typically generated from the WSDL/schema which means that effectively the developer of a service consumer is using the top-down approach. Even when the service is generated using the bottoms-up approach with a limited subset of XML Schema, there can be interoperability problems between development tools used by the service provider and service consumer.

Trust but verify

Regardless of approach, the advice of the old Russian adage; "trust but verify" should be followed by the Web service designer. Regardless of what the development tooling used says about the validity of the schema, use as many other sources as possible to verify the assessment. There are a number of resources that a developer can turn to in this regard:

• IBM's Schema Quality Checker


• Microsoft's schema validator


• DecisionSoft's schema validator


• W3C Schema Validity Checker (beta and "experimental")

Certainly, one can also employ multiple development tools from different vendors, but it can be somewhat costly to provide each developer with a copy of each vendor's IDE. An approach to consider would be to license a single copy of a few widely used development tools for use by the QA staff to validate schemas and possibly to generate consumer code from the WSDL/schema if time permits. If you don't have that luxury and are doing top-down development of schemas in an open standards development forum such as OASIS, circulate the draft schema amongst the various participants and have them use their favorite development tools to validate the schema and report back any issues.

If the schema validates cleanly against all of these various sources; chances are that it will not yield interoperability headaches. If the schema does not validate according to one or more of the resources, the developer should work through the issues as if they were bugs in the schema until the schema validates cleanly using multiple sources of validation.

Avoid being too clever

Finally, anyone doing schema design should avoid being too clever. KISS has never failed me. With that in mind, there are a number of resources available that offer sage advice to schema designers such as this article by Dare Obasanjo which responds to this one by Kohsuke Kawaguchi. I would recommend reading both and drawing your own conclusions.