Mike wrote: > Yes, the example element "MyBody" corresponds directly to the "method struct" for RPC as you describe. The idea is to represent the RPC struct in the same way that a struct passed as an RPC parameter would be represented in WSDL 1.1. It is more appropriate to use schema here then message/part. > > > > I think it makes a lot of sense to list the header parts with the abstract message rather then identifing them only down in the binding. As you point out, you get reuse by importing a schema and referencing the header elements from each message. If we really need a powerful message type system, we should use schema instead of message/part. > > > > Having the each soap:header and soap:body element identify a single part each is conceptually a little simpler but more verbose. I do think the soap:header and soap:body should be the same (either both parts or both part). > > > > When you say "I still believe that retaining the <message> construct makes life easier for implementers, particularly when generating clients from WSDL docs." do you mean keeping message/part in general makes things easier (which I agree with) or that keeping message/part for RPC where each part is a parameter makes things easier (which I do not agree with)? > I mean message/part in general, as a part of the WSDL model. It makes sense to use schema to represent RPC messages, it's straightforward. I see opportunities to simplify implementation of a WSDL reader this way. RC > > > == Mike == > >Received on Saturday, 11 May 2002 10:50:43 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:20 GMT