Comments on WS-I profiling XSD

My post on WS-I potentially profiling XSD brought a range of comments, largely in two themes. Erik pointed out the fundamental difference between the work done by the WS-I Basic Profile Working Group 1.0 (of which both he and I were members) to resolve ambiguities with SOAP and WSDL and the work being considered with XSD. In short, there aren't any real ambiguities with XSD. The investigation of XSD as a potential target for profiling is being driven by users of the technology who are frustrated by the uneven coverage that their OO tools provide for mapping to XSD. This is a tooling issue, however, and should not lead the industry to restrict a core technology in the WS stack. I agree with Erik completely. If your development tool of choice can't handle an aspect of XSD, don't try to restrict what I do, pick a different tool. Randy added that, from his perspective, subsetting XSD wouldn't help anyway. He believes that the major problem with XSD is not what it offers, but what it does not. My opinion on this point is pretty clear.

David and Marc responded to my comments about the vast RPC conspiracy. Marc doesn't like the use of an action header at the transport protocol or SOAP level; David does. I think a SOAP-level action header is very useful, in fact I often describe WS-Addressing, which provides an Action header, as the missing piece of SOAP.

That said, I'm not sure how far I'd push the notion of the action URI having no relation to the extended name of the element inside a message body. There are some special cases where this makes sense, i.e., an action URI that can be associated with any element at all. While people (including me) often talk about wanting to disconnect the action URI from the payload of a message, I don't know how useful it would actually be. Certainly the higher-level specs like WS-Eventing and WS-MetadataExchange do not take that approach; they tie action URI and body element together.

Some have argued that, for instance, you might want a PO as the element in the message body, then multiple actions like submit, process, log, etc. This model works well in the abstract, as long as you only have one piece of information you are processing. Imagine you were modeling a transfer of funds from one account to another. The action would be transfer, but what would go in the body? Three elements, one representing the source account, one representing the destination, and one representing the amount? I prefer a single element that contained all three pieces of information, so that I could process the whole request as a single entity independent of the SOAP envelope's body. In that case, I need an element that represents the transfer of funds. As long as I'm doing that sometimes, would it be so bad to do it all the time, even if that element only contains one child, as in the case of submitting a PO? Increasingly, my answer is yes. (In fact, this ties into my preference for doc/literal/bare services, which allow me to receive the outermost element of a message instead of stripping it away and handing me all of its children.)

So, after thinking about it for the last couple of days - and chatting with Marc, who I saw over the weekend - I think I would commonly define a new element for each action, except where I want an action whose associated element is unknown (essentially a wildcard). It's this latter requirement that is stymied by the WS-I's unique signature requirement; you can't build a compliant service that works that way. I was too hasty lumping WSDL 2.0 in there, though. WSDL 2.0 does allow you to build a service like that, provided that you express how operations are differentiated using the mechanism detailed by the operation mapping requirement. The obvious solution is to rely on the WS-Addressing Action header. Now that WSA is in the hands of the W3C, one hopes they'll define the appropriate mechanism for integration with WSDL 2.0 and we can be done with this problem.