RE: issue: optional parts in <message>?

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.

Received on Friday, 10 May 2002 21:29:17 UTC