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

Hi,

I was not sure if this made it into to the issues list (sorry can't find
it).

Regards, Prasad

-------- Original Message --------
    Subject: Issue: SOAP binding violates separation of abstract
             definitions concrete bindings
Resent-Date: Tue, 4 Jun 2002 16:28:09 -0400 (EDT)
Resent-From: www-ws-desc@w3.org
       Date: Tue, 04 Jun 2002 13:28:57 -0700
       From: Prasad Yendluri <pyendluri@webmethods.com>
         To: Web Service Description <www-ws-desc@w3.org>

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