Comments about my post on XSD and type substitution...

Two new comments about my post on avoiding type substitution in XSD arrived in my inbox this morning...

First, Mike says he comes from a RelaxNG perspective, and finds the notion of modeling XML schemas in terms of objects bizarre. I'm with you brother. If I were granted one wish to change something in the XML and Web services world in which I live, it would be to get people to embrace RelaxNG instead of, or at least next to, XSD. I long for attribute-element cooccurance constraints, non-determinism and a focus on structure rather than complex type. It would make the world a better place. But all the tooling and the specs are going toward XSD and I don't know if we can come back. As an alternate strategy, I do my best to show people how to use XSD in a RelaxNG way.

Second, Jon thought my advice that one not use substitution at all was perhaps a bit strong. He thought it just needed to be used carefully. I'm tempted to agree. But the problem is that people aren't careful about it. You rarely see a schema that explicitly blocks either type or element substitution. To me, a schema without that says “our contract is open along this dimension”. But very few SOAP stacks or type marshalers are prepared for a new derived type or substitutable element to come along. People - or, more accurately, their tools - are producing contracts that they don't intend to meet. Or, more accurately, conctracts that they only intend to meet sometimes, i.e., when they know what all the derived types are. Unfortunately, XSD doesn't have a way to define a closed set of derived types or substitutable elements. Without that, you're opening yourself up for trouble.

It's worth noting, by the way, that the SOAP schema doesn't block either type or element substition. The SOAP spec, on the other hand, doesn't speak at all about complex types and mandates that, for instance, the body element be named {http://schemas.xmlsoap.org/soap/Envelope/}Body. That is an accurate expression of what a SOAP processor expects. It also means that the schema isn't really an accurate reflection of the contract...