Re: issue: optional parts in <message>?

Mike,

I agree 100% that having all parts at the abstract level including the headers clearly represented in a message is very desirable. In the examples you show all parts come from the same schema but, I take that does not rule out multiple sources (perhaps imported into the same schema).

I am a bit on the fence regarding combining doc/rpc and encoded/literal into one format attribute (URI?). I see them as two disjoint concepts. I agree that there is a great deal of confusion around this and if any I would perhaps move to eliminate the RPC style and have only doc style, as the latter can be used to capture the former. This would simplify things as only literal /encoding  distinction needs to be stated at the binding level. However I also see the advantages offered by the RPC style to rpc style interfaces.

Regarding element vs type, my preference would be to use type and do away with element. I see element as an instance and it does not make sense to define a type using an instance. I would like to understand the advantages on the flip side however. In your example you still use the name attribute on  parts while using the element hence I take that is not a factor here.

Regards, Prasad


Mike Deem wrote:

> 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 ==
>
> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
> Sent: Wed 5/8/2002 8:12 PM
> To: Jeffrey Schlimmer; WS-Desc WG (Public)
> Cc:
> Subject: Re: issue: optional parts in <message>?
> "Jeffrey Schlimmer" <jeffsch@windows.microsoft.com> writes:
> >
> > Just to be clear, are we thinking we aren't going to make _any_ changes
> > that would break existing WSDL 1.1 documents? That's a pretty stiff
> > constraint and can be used to "resolve" many of our open issues.
> >
> > --Jeff
>
> Of course we are! We will make breaking changes, but I'm just very
> concerned that *removing* message is not a 1.1 to 1.2 kind of change.
>
> The approach Mike Deem suggested of augmenting message with the
> direction we intend to go in was much more reasonable IMO. I believe
> he's going to post a more complete proposal after looking at impact
> on the bindings too. (Or that's what I asked that he do and he didn't
> reply otherwise.)
>
> Bye,
>
> Sanjiva.