RE: Issue: SOAP binding violates separation of abstract definitions concrete bindings

There is no element named xsd:string or xsd:timeInstant. These are types and
would require the type syntax if the examples are correct. So, it isn't
showing a violation of the restriction, it is just one of the many, many
errors in the 1.1 specification.

David Cleary

  -----Original Message-----
  From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
Behalf Of Prasad Yendluri
  Sent: Tuesday, June 04, 2002 4:49 PM
  To: Web Service Description
  Subject: Re: Issue: SOAP binding violates separation of abstract
definitions concrete bindings


  I should also add that the Spec also contains examples that violate this
requirement of abstract parts be defined using type if use is "encoded".
  See Example 4 in section 3.1.

     <message name="GetTradePriceInput">
          <part name="tickerSymbol" element="xsd:string"/>
          <part name="time" element="xsd:timeInstant"/>
      </message>

      <message name="GetTradePriceOutput">
          <part name="result" type="xsd:float"/>
      </message>

      <portType name="StockQuotePortType">
          <operation name="GetTradePrice">
             <input message="tns:GetTradePriceInput"/>
             <output message="tns:GetTradePriceOutput"/>
          </operation>
      </portType>

      <binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
          <soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
          <operation name="GetTradePrice">
             <soap:operation soapAction="http://example.com/GetTradePrice"/>
             <input>
                 <soap:body use="encoded"
namespace="http://example.com/stockquote"

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
             </input>
             <output>
                 <soap:body use="encoded"
namespace="http://example.com/stockquote"

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
             </output>
          </operation>>
      </binding>

  The parts of the message GetTradePriceInput are defined using "element"
form and the one in GetTradePriceOutput is defined using "type" form. Where
as at the binding level both specify use=encoded. See the highlighted areas
above.

  Regards, Prasad

  Prasad Yendluri wrote:

    Section 2.3 (Messages) of WSDL spec permits defining parts of a message
using either "type" or "element" attribute:
    <definitions .... >
        <message name="nmtoken"> *
            <part name="nmtoken" element="qname"? type="qname"?/> *
        </message>
    </definitions>

    Section '2.3.2 Abstract vs. Concrete Messages' also states:

    Message definitions are always considered to be an abstract definition
of the message content. A message binding describes how the abstract content
is mapped into a concrete format.

    However, section '3.5 soap:body' in the SOAP bindings section requires
that the parts be defined using the "type" if the "use" is "encoded":

    The required use attribute indicates whether the message parts are
encoded using some encoding rules, or whether the parts define the concrete
schema of the message.

    If use is encoded, then each message part references an abstract type
using the type attribute. These abstract types are used to produce a
concrete message by applying an encoding specified by the encodingStyle
attribute.

    If use is literal, then each part references a concrete schema
definition using either the element or type attribute.

    No explanation is given why the parts need to be defined using "type" if
"use" is "encoded". The SOAP binding scheme is therefore requiring that
things be defined in a particular way at the abstract level,  violating the
separation of abstract definitions and applying multiple concrete bindings
to the same abstract level definitions.

    We should either remove the restriction or clearly state why this
restriction needs to be there. No justification is provided in the spec for
this, other than simply having one statement that calls for it.

    Regards, Prasad