W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2002

Issue: SOAP binding violates separation of abstract definitions concrete bindings

From: Prasad Yendluri <pyendluri@webmethods.com>
Date: Tue, 04 Jun 2002 13:28:57 -0700
Message-ID: <3CFD2309.34608EE3@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"?/> *

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

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
Received on Tuesday, 4 June 2002 16:28:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:23 UTC