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 better e 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

> I'm going to reverse my position on message/part to a certain extent. It is no more correct to use schema to describe the abstract "parts" of a message then it is to use message/part as "simple" substitute for describing the structure of a single logical "part". 
> 
> The problem is that the complexity allowed by various permutations of the part element's element and type attributes and the SOAP binding's style and use attributes prevents the emergence of a single clear idea of what a "part" is. I believe that an overall simplification of type/element and style/use is the best way to address this problem.
> 
> A brief sketch of such a simplification is shown below. These are just some initial thoughts and are not intended to be a complete proposal. 
> 
> <wsdl:definitions 
>   xmlns:wxs="http://schemas.xmlsoap.org/wsdl/type/xml-schema" 
>   ...>
> 
>   <wsdl:types>
>     <xs:schema ...>
> 
>       <xs:element name="MyHeader1">
>         ...
>       </xs:element>
> 
>       <xs:element name="MyHeader2">
>         ...
>       </xs:element>
> 
>       <xs:element name="MyBody">
>         <xs:complexType>
>           <xs:sequence>
>             <xs:element name="p1" .../>
>             <xs:element name="p2" .../>
>           </xs:sequence>
>         </xs:complexType>
>       </xs:element>
> 
>     </xs:schema>
>   </wsdl:types>
> 
>   <wsdl:message ...>
>     <wsdl:part name="a" wxs:element="ns:MyHeader1"/>
>     <wsdl:part name="b" wxs:element="ns:MyHeader2"/>
>     <wsdl:part name="c" wxs:element="ns:MyBody"/>
>   </wsdl:message>
> 
>   <wsdl:portType .../>
> 
>   <wsdl:binding ...>
>     <soap:binding .../>
>     <wsdl:operation ...>
>       <soap:operation .../>
>       <wsdl:input>
>         <soap:header 
>           parts="a b" 
>           format="http://schemas.xmlsoap.org/wsdl/format/literal/"/>
>         <soap:body 
>           parts="c" 
>           format="http://schemas.xmlsoap.org/wsdl/format/rpc-encoded/"/>
>       </wsdl:input>
>     </wsdl:operation>
>   </wsdl:binding>
> 
> </wsdl:defaintions>
> 
> The key points are:
> 
> * The unqualified @type and @element on wsdl:part are gone. @xws:element is the only way to reference message content defined in schema. You can't reference types directly (types don't appear in messages, elements do). If you want to reference content definitions that use a different type language, you define a qualified attribute specifically for that type language. 
> 
> * @style, @use and @encodingStyle(?) are replaced with @format of the type anyURI. An URI for the combinations of style/use/encodingStyle make sense would be defined. For example: document/literal would be “http://schemas.xmlsoap.org/wsdl/format/literal” and rpc/encoded with SOAP encoding would be “http://schemas.xmlsoap.org/wsdl/format/rpc-encoded”. A single @format attribute allows the universe of recognized formats to be expanded without inventing new attributes and avoids discussions about the meaning and value of things like document/encoded.
> 
> * @format may appear only on the soap:body and soap:header elements and not the soap:operation or soap:binding elements. It applies to all the listed parts. If you want to apply different formats to different parts, you have to use multiple soap:body or soap:header elements. However, a given format may place restrictions on this. For example using the rpc/encoded format would require that only a single body part can be specified (I think this is what will be required for SOAP 1.2).
> 
> * @namespace on soap:body is gone.
> 
> * @message on soap:header is gone. Only the parts listed in the input/output message associated with the operation can be part of the message.
> 
> Hopefully this will inspire some productive thoughts and discussion.
> 
>   == Mike ==
>

Received on Saturday, 11 May 2002 00:24:32 UTC