Living with XSD

Aaron has a thoughtful response to my outburst over RelaxNG. His point is that there are a lot of forces at play here other than just the technology, the industry concensus is that we should use XSD, and it's too late to change that. The gist of it is that consensus is as as important as technological superiority, and very hard to reach. Since we've got it with XSD, we should go with it, warts and all. He uses HTTP as an example of a technology that isn' t brilliant, but is very successful because of concensus. We've all built amazing things using HTTP, so we know this approach can be successful.

Of course, this doesn't explain why everyone is so interested in developing a standard way to send SOAP messages over raw TCP. We have concensus on SOAP over HTTP, which, warts and all, has been shown to work. With the arrival of the http.sys driver on Windows Server 2003 and XP SP 2, any process can accept HTTP traffic (other platforms provide similar support). Yes, there are still connection establishment issues because of firewalls and other infrastructure, but do we really need to develop a new SOAP transport protocol to solve them? Can't we just bend HTTP around and make do? Couldn't we poll, or phase-shift by parking calls, or... Here, a lot of people think that we can't, they want to create something simpler that more directly meets our needs. So there is ongoing work on implementations of SOAP over TCP. Over time a standard will emerge and WS stacks will implement it and systems will start using it instead of HTTP. Both will live side-by-side and you'll be able to pick the one that better meets your needs.

So back to XSD and RNG. Isn't it the same issue? Can't we just bend XSD around and make do? Here, a lot of people think that we can...

So why is that?

I think the answer stems from how one looks at the WS stack and the feature set of an implementation. Support for TCP is considered a new feature. A move from XSD to RNG is considered an implementation detail. That is, as long as you believe that developers don't want to and/or should never see any XML. In that case, it's easy to say “well, the tool builders are willing to suffer so that no one else has to, XSD will be hidden, the developers will write C#/VB.NET/Java classes and it just won't matter.“

But there is a group of people - of which I'm one - who believe that the definition of a system's message schema is not an implementation detail projected from a set of OO types which are the source of truth. In fact, they believe just the opposite: that a system's message schema is the source of truth and the OO types you choose to project in a particlar process is the implementation detail. There are lots of reasons they feel this way:

• They're defining message formats and portType definitions for use across their organization or with partner organizations and need to be toolkit agnostic
• They want to pass XML-based data through Web services, but also process it and store it other ways (e.g., put it into a database) and they need definitions independent of Web services that can apply throughout their system
• They are using network hardware to process their XML messages for performance and security, the device is configured independently of any particular service and needs knowledge of the standard schemas the organization uses
• They have experience working with COM tools that tried to hide IDL and they know they were more successful when they started there
• They take the SOA tenet that says share schemas, not types to heart and don't want to write their schemas indirectly by writing types

Around a year ago, I spoke to a room full of system designers at an event at the local MCS office in Waltham. I asked them about schema-first or code-first development of Web services. All of them said schema-first. One of them went further. He asked when my company would provide tools for that. I told him you could already to it with xsd.exe, wsdl.exe, etc., but he was having none of it. He wanted to know when the IDE would not only support but actively encourage people to develop that way.

In short, people out in the world want to be able to start with schema definitions. Yes, the concensus in the industry is that XSD is indeed the answer for that (and there is increasing tool support for it), but more and more people are finding out how unpleasant an answer it is. The same way we're working on support for TCP as a simpler, more effective alternative to HTTP in many scenarios, we should as an industry be developing support for RNG as a simpler, more effictive alternative to XSD. This is as important a feature as anything else being added to the WS stack.

All that said, I'm not holding my breath. As I said in my original post - and Aaron echoed in his - XSD has a ton of momentum. Even if the industry changed direction today, it would still be a long time before we had RNG-based tooling. So no matter what, we're going to have to live with XSD for the foreseeable future. I've been feeling that for a long time now and have been working on an approach to XSD that approximates what I get from RNG. I'll try to get it written down here in the next couple days.