Dare argues that code-first is better for interop

Here we go again...

I just read Dare's new post claiming that code-first WS contract development is better for interoperability. His argument is that not all tools support all of XSD, so if you design Web services contracts directly using XSD/WSDL, your chance of interoperability is actually lower than if you do code-first and let your tools map your classes to XSD/WSDL. Here's my favorite part:

Every XML Web Service toolkit that consumes WSDL/XSD and generates objects has different parts of the XSD spec that they either fail to handle or handle inadequately. Many of the folks encouraging contract first development are refusing to acknowledge that if developers build schemas by hand for use in XML Web Services, it is likely they will end up using capabilities of XSD that are not supported by one or more of their consuming applications. The post from XML-DEV is just one example of this happening. When I was the program manager for XML Schema technologies in the .NET Framework I regularly had to help customers who had to deal with the interoperability problems they encountered because they'd read some article extolling the virtues of schema first design which failed to acknowledge the realities of the XML Web Service landscape.

I work for a company that believes - as do the many of our customers - that contract-first development makes sense. My company spends loads of time supporting people with interoperability problems and as many or more come from toolkit-generated schemas as from hand-created ones. Toolkits are no better at producing interoperable schemas than people are (witness DataSets as just one example, there are more).

The great irony of Dare's argument is that it is the toolkits themselves that drive people to contract first. Do you think we all like writing XSD/WSDL ourselves? When a group of industry people get together at the WS-I to talk about XSD interop problems, various folks argued for a standard set of schema interop tests the results of which would be published to show which kits supported which features, guess which parties had no interest in supporting that?

People turn to XSD/WSDL because their goal is to defining agreements that are by definition toolkit-independent so that they can use whatever tool meets their needs. Call me wacky, but I think the best way to do that is to produce a contract independent of a toolkit. Of course, as Dare observes, this only works if you restrict yourself to a subset of XSD/WSDL:

From my experience "contract first" design is actually more likely to lead to interoperability problems than "code first" design. The only time this isn't the case is when the schema designer actually pays attention to use a minimal subset of XSD as opposed to using its full capabilities.

In fact, this is exactly what people do. Some even publish the result; here's the subset from HP. A toolkit vendor may dislike this lowest-common denominator approach, but it's the only one that works today. Perhaps tomorrow, when Indigo and JAXB/RPC 2.0 deliver full XSD support that will change, or perhaps not.

So I agree with Dare that you have to keep things simple. I don't agree that relying on your tool is the best way to do that.