Documents, Schemas, Objects: An Eternal [Golden?] Braid
I'm taking a break from the Day Job task of summarizing WebData XML's experiences with XML Schema for the upcoming W3C Workshop. This task has led me to pull on the strands that entangle XML documents, schemas, and programming models with one another.
I must admit that a couple of years ago, this seemed like a simple problem. I was a schema-hating, dynamic language-loving doc-head. W3C XML Schema Definition Language seemed like a poster child for Design by Committee gone awry. The Right Thing was clearly to treat XML as XML, not serialized objects; developers should stop worrying and learn to love DOM, XPath, XQuery, and the subtle intricacies of the XML Infoset! In my heart of hearts I hope(d?) to help insinuate document-oriented approaches such as RELAX NG into the Microsoft XML tools stack.
As with many aspects of life, however, having to face up to the requirements and user cases of actual developers with real software to write that has to interact with existing databases and legacy systems has led me to an appreciation what XSD offers (warts and all). Likewise I was forced into a more pragmatic assessment of the need to get XML instances, schemas, and programs to intertwine more elegantly. These questions are on a lot of minds these days, perhaps stimulated by the W3C workshop preparations. For example some folks in the Java world are proposing a replacement for JAX-RPC that is "free from many known flaws in existing systems" by denying "the right to write web services to developers who are ignorant of XML." They are certainly right in asserting that taking programming language objects out of the braid will make the rope simpler to understand and easier to implement, but will it make it more useful? Some enthusiastically agree. Others note that it is a very purist approach and hope for a middle ground. Don Box observes that the designers of Indigo faced this challenge:
From the looks of this paper, Alpine seems close to what you get in Indigo when your service contracts use System.ServiceModel.Message directly. System.ServiceModel.Message gives you "POX"-like access to SOAP messages without imposing any additional interpretation beyond XmlReader.
I wish there were easy answers or quick fixes. Sure, lots of problems go away if you stop worrying about the little detail that most software developers are more comfortable with the CLR and Java type systems than the XSD type system; conversely they also go away if you stop worrying about the fact that XSD has too much momentum to stop. As Steve Maine put it in another recent post:
I think the goal is to dramatically reduce the level of concrete understanding you need to have about these things in order to be a productive user of the platform. WSDL, XSD, and SOAP are facts of life in the web services world, and you have to understand those things on some (hopefully high) level to be a successful services developer. However, acknowledging their existence is very different than knowing their inner workings. That’s where a toolset like Indigo can add a lot of value and remove a lot of complexity. Developers should focus on the what’s and why’s, and leave the how’s to the tools.
This is not unique to web services. That's also the philosophy we try to apply to the core XML APIs, the XML tools in Visual Studio, and the other technologies that the WebData XML team is responsible for. Over time, we certainly can do better than we now do in the XML world to make the document, schemas, and programing strands hold together better, but doing this by removing one of the strands in the name of elegance makes the overall system weaker.
Once again, it's not so important what I think, but what those using our technologies actually experience. Are you able to work around XSD's complexities and ambiguities to get real work done? Are there any alternatives that meet your needs better? Do you see XML as part of the plumbing that you would prefer to keep out of sight, or do you want to see those angle brackets right in your face? Let us know!
Mike Champion