A free market for XSD and tool interop

Paul posted a couple of comments (one, two) related to my last two posts. He is willing to work at the XML level, but wants to make sure that his services can be consumed by people using .NET, BEA, IBM and other platforms. He suggests that subsetting XSD would define “a floor”, not “a ceiling”. It would be a base-line for interop, but one could do more. From my past experience working on a WS-I WG, I can tell you that the floor idea doesn't work very well. What people really want to define is a subset that is both a floor and a ceiling, and four walls, and no doors or windows. That's what concerns me.

Here's what I think we should do instead...

Imagine a world where the tools consuming WSDL and XSD and emitting code were smart enough to look at the description of a message exchange and offer a range of choices about how the data can be exposed to you as a programmer:

1. Individual typed parameters parsed out of the body of a message
2. One typed parameter representing the body of a message
3. An XML tree representing the body of a message
4. An XML stream representing the body of a message

You could choose which representation you want to program against. For some message formats, some options might not be available. This requires only marginally smarter tools than we have now. They just have to be smart enough to say “well, I can give this to you as a DOM instead of objects“ instead of “I couldn't give you objects so I failed“. With .NET tools you can get the DOM if you know how, but the tools don't help you at all. I don't know how well this works for other toolkits, but given that the current draft of JAX-RPC 2.0 allows a client to work with raw XML if desired, hopefully the server will be able to as well. (This is why I keep saying that there aren't XSD interop problems, only object serializer interop problems.)

Anyway, if tools worked that way, you'd know that there is always a way that you can produce and consume anything. However, some ways may be harder than others, depending on what you were trying to do and how you prefer to write your code.

As a service provider, I follow the advice of my stepfather who told me once, when I started working freelance, “Always make it easy for people to pay you.” It's amazing how well that advice translates into all kinds of spaces. Here, it means that it is in my best interest to design an API that works with the tools that potential customers want to use. If I'm inside a small company where everyone uses exactly the same tool, I can let it take care of this for me. If I'm publishing services on the public Internet, I need to think about what tools my customers are using and how far I'll go to help them. If I'm building services for key business partners, I'm probably somewhere in between.

As a service consumer, I need to decide how badly I want or need to consume a service. If I really really really need to use a given service, I'll adopt program against it anyway I can to make my system work right. But if its too hard, that might trump my desire to use the service and I'll do something else.

Here are two real world examples (sorry, I can't give names)...

I once spoke at length about this problem with a man working on services that the financial company he worked for was going to expose to customers. They built their services with .NET and tested them with one Java kit (I forget which, but I think it was Apache). They told their customers that it would be easiest to use one of those two kits to consume the services. However, if their customer wanted to use some other kit, they offered to help on their end, potentially building another instance of a service if that's what it took to make their customer happy. They were dedicated to making it easy for there customer to pay them.

On the flip side, I've also seen a Web service API whose input was an XPath query and whose output was arbitrary XML. The idea was that it was generic enough to sit on top of any source of information. The problem was that many people coding against it didn't need to talk to any source of information, they needed to talk to a particular source of information. They had to pay a huge generic-ness tax, and eventually they simply walked away.

If we had tooling that worked the way I described above, I think things would balance out. And it would leave the door open for tools to continue to evolve and improve, which a profile would not (at least not without either not complying - which is likely to violate company policy - or writing a new profile).

Meanwhile, Paul asked for advice on what you should do if your company needs to write services that will be consumed by a lot of different users. The simplest step is to write your schema first and keep it as simple as possible, preferring composition over inheritance and fancy type tricks. The great work the SoapBuilders group did means that most of this stuff will work fine. You can use complex types and repeating sequences of simple and complex types. My approach to this is described here.

(A ha, you may say, that's exactly why we need a subset of XSD. In fact, Tim, you've defined one yourself, so why are you so against WS-I doing it?!?? The answer's easy: I take an approach that works for me. I don't claim anyone else should take the same approach; that's up to them. For instance, I like to use multiple global element decls so that I can schema-validate arbitrary subtrees of a document. Randy does not like to use multiple GEDs because it confuses some document authoring tools. I don't want WS-I telling either of us what we can and can't do here. We, like our tools, should have flexibility and reserve the right to change our minds. Once there is a standardized subset, it will be very hard to go outside that, even when there are good reasons.)