RE: issue: optional parts in <message>?

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)?

 

  == Mike ==
 

 -----Original Message----- 
 From: Bob Cunnings [mailto:cunnings@whitemesa.com] 
 Sent: Fri 5/10/2002 9:30 PM 
 To: www-ws-desc@w3.org 
 Cc: 
 Subject: Re: issue: optional parts in <message>?
 
 

 Hello,
 
 I'm assuming that in the example the element "MyBody" corresponds directly to the "method struct" for the RPC per the SOAP RPC convention, when the format ".../rpc-encoded/" is in force. If so, I'm assuming further that this element definition describes the method parameters prior to the application of soap encoding rules. Are these assumptions correct?
 
 From an implementation pov, this looks like a nice streamlining, with sufficient information retained. I think that the collapse of @style, @use, and @encodingStyle into the "format" attribute makes sense. It allows more freedom, at the moment it's too easy to view the format space as being only 2 dimensional with axes "document/rpc" and "encoded/literal".
 
 The one thing that stands out is the constraint that header entry elements reference <parts> of a _single_ message associated with the operation (along with the body parts). I'm wondering if it will interfere with a desire to compose in a freer manner, with soap:header declarations directily referencing parts in <import>'ed messages (perhaps provided by third parties e.g. security extensions), on an as needed basis. Of course the header entry <part> defined in one's own single message can directly reference an _element_ in the foreign schema if it is imported. The effect should be the same, but I wonder if there is drawback to doing it that way. What's new in this approach seems to be that any header entry definitions are now captured in the abstract definition of the operation, by virtue of the reference to a single message containing both body and header parts. Does this represent a convenient bundling of related parts, or a forcing together of what might be viewed as orthogonal parts, which might betterbe left to the binding? Maybe I'm misconstruing the situation.
 
 I also notice that the soap:header element is using an attribute "parts" which appears to be a list, whereas in the current WSDL version uses "part" of type NMTOKEN, requiring a separate soap:header element for each header entry. If it remained as is, then the issue of specifying different formats for different parts goes away for header entries.
 
 I still believe that retaining the <message> construct makes life easier for implementors, particularly when generating clients from WSDL docs.
 
 Thanks,
 
 RC

Received on Saturday, 11 May 2002 04:08:39 UTC