If not schema, then what?

John Cavnar-Johnson recently wrote about the shortcomings and contradictions he percieves in the [DataContract] way of annotating types to create messages in Indigo. Although I don’t know if he’s right (and I suspect only time will tell) thinking about the issues he raises led me think more deeply about some aspects of messaging-based systems than I had before.

Specifically in the “If Not [DataContract], Then What?” section he asserts that  designing messaging systems starting with Xml Schema is a bad idea because the inherent mis-match between the .NET type system and the Schema type system which others have alluded to before means that you often can’t generate an object model based on the schema you’ve designed. Maybe I’m crazy but I often find it easier to just work with the XML, eschewing the “object wrapper“ all together. I’ve done some recent work integrating two applications with biztalk. Just treating the messages as XML inside of the .NET code I’ve included in the orchestrations seemed to work fine.

John also asserts that “XML Schema is, in many respects, ill-suited for message design“ due to the “all-or-nothing” nature of schema validation” (which, ironically most people don’t do anyway). I also find it ironic that most of the “loosely coupled versioning friendlyness” that we see in web services at the moment is not due to extensible schema design and if  but due to the fact that nobody does schema validation. Did I just say “extensible schema design“? Most people don’t design schemas, they just take whatever their platform gives them when they serialize their objects to XML, and the reason they don’t do schema design - because of the inherent problems supporting all of schema in their platform of choice.

In summary:

  • What was the schema working group thinking?
  • Trying to create strongly typed object models based on Xml schema is fraught with peril, maybe just treating Xml as Xml is the way to go.
  • Designing object models and hoping that they project out onto into the world as a nice schema that can be versioned without breaking older callers is probably leaving too much up to chance.

But if we don’t use schema then what? We still need some way to describe the type or types of messages that our service accepts. Relax NG? Schematron? Thankfully people much smarter than I are working on this problem as we speak….

Update: More fairly damming coments from a recent schema workshop via Rick Jelliffe