WS-I to profile schema? This can only end badly!

In Fumiaki Yoshimatsu's comment on my post about Kawaguchi's work, he notes that he is optimistic about the WS-I's working group focused on profiling XSD. I am not. According to the published charter, “ 'implementation-defined' interpretations of features are specifically excluded.” I don't believe it for a second.

If implementation specific interpretations are off the table, where are the interop problems with XSD? There aren't any. What people really want to do is try to profile schema so that their object serializers always work right. This is a problem for lot's of reasons, including: it's a rapidly moving target; there are already lots of existing schemas that people want to use and they should not be blocked from doing so; and almost every feature is used in some schema or other (for instance, XHTML 1.1 uses groups and redefine. If those are profiled away, you wouldn't be able to build a compliant service that sent or received XHTML in messages). A better solution is to adopt an API that gives you access to raw XML in cases where an object serializer is overwhelmed. ASMX and WSE both support this model.

This point of view might seem ironic coming from me, given what I've been saying about XSD lately. But it's precisely because XSD has so many issues that I don't want it profiled. If we all have to live with XSD, we ought to at least be allowed to live with all of it. Am I worried that my preferred model will be profiled away? Damn right. There's already a vast RPC conspiracy that's bent on turning Web services into an homage to the past. They've given us the WS-I Basic Profile Unique Signature Requirement (R2710) and WSDL 2.0's Operation Name Mapping Requirement. The next step is to squeeze XSD into a subset of our OO languages and nothing more.

Why am I so vitriolic about this? Because I remember RPC and CORBA and DCOM and Java RMI and .NET Remoting and I don't want to end up in the same place again. I'm not saying that you shouldn't be able to use Web services as a way to make RPC calls with objects as parameters, I'm saying that that should NOT BE ALL YOU CAN DO. The Web service tent is big and those of us XML messaging people should be welcome too - especially since that's how the technology actually works!

Of course, if you don't care about WS-I compliance, you can do whatever you want. But a lot of organizations will mandate compliance with WS-I profiles. What will happen when someone wants to do some XML messaging that doesn't fit into the WS-I model and the RPC-style tooling that's geared for that alone? They'll end up posting raw XML over HTTP, getting none of the benefit of the rest of the SOAP stack and supporting infrastructure. All because they aren't thinking about method calls.

In short, I do not support profiling XSD. When it comes to XSD, I may not agree with what you write; but I will defend to the end your right to write it.