Re: issue: optional parts in <message>?

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 UTC