Luciano, The case I mentioned was more of a bottom-up case , in that we started with the Java REST-like interface.
So say I start with this interface, write a Java impl, expose a service over <binding.atom>. Now in order to invoke this same impl over a different binding like <binding.ws>, I generate an <interface.wsdl> and place this configuration on my component service description. To me it sounds like you're assuming this would have an impact on the actual wireformat of the binding.atom invocation of the existing service. My assumption was that it would NOT impact the wireformat at all. So the presence of a doc-lit-wrapped <interface.wsdl> does not necessarily mean that a wrapper element will appear in the payload XML. The WSDL interface is abstract and the concrete "binding" to a binding-specific format is something for us to define. I'm not saying that should be the final word on the subject... just explaining my assumptions. But this also explains why I viewed this as more of a tweak in using the right Tuscany databinding APIs rather than adding support to handle a fundamentally new type of wire format. After working on the JMS binding with its spec-defined default wireFormat where a doc-lit-wrapped WSDL doesn't necessarily result in a wrapper element being serialized onto the wire (for a single parm)... I guess at least there is some precedent for the idea that a doc-lit-WSDL doesn't, for all bindings, result in serializing a document literally conforming to the message part schema. But it does all seem a bit ugly to me I admit... Scott
