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

Sorry, missed that one.

Now done.

Jean-Jacques.

Prasad Yendluri wrote:

> 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
>
>

Received on Thursday, 27 June 2002 04:27:20 UTC