How many schemas?

Edd Dumbill's latest column on xml.com summarizes Roger Costello's summary of some current discussions in the community under the title “Fallacies of Validation“.

There are some interesting points about the general naivete of assuming that you can design a single schema (or even use a single schema language ;-) for an entire system of any complexity. I did a talk at the Applied XML DevCon last fall that described how the system I've been working on uses multiple schemas for the same XML dialect in order to assert different things at different points (the talk ran on MSDN TV in two parts: one and two). This approach works very well, except for one thing. Both developers and tools expect a single definition of a schema for a given namespace. This turned out to be such a problem that we moved away from this model, at least for now. One of the things I like about RNG -- although I realize it isn't intrinsic to that language -- is that people seem more willing to think of a description of a language as being a local view, not a global definitive thing.

I'd like to get back there with XSD, because it can potentially really simplify versioning. If you had a version attribute in your dialect and selected an appropriate XSD based on that, you could have n schemas for n versions without changing your namespace. That means they could all deserialize to the same set of classes (if you want to do that), they work with the same set of XPath queries and XSL transformations, etc.

The big issue in the Web Service space is the definition of a contract. If your schema is a localized view, how do you specify a shared contract? The WS-* specs define it in prose. But then how do you test it for compliance? There in lies the problem. Arguably each party should use schema that enforces as many requirements as they care to assert. Getting people to accept that view is an uphill battle.