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

Re: Issue:soap:body binding description confusing when use is "literal"

From: Jean-Jacques Moreau <moreau@crf.canon.fr>
Date: Thu, 23 May 2002 11:36:07 +0200
Message-ID: <3CECB807.29A53BD1@crf.canon.fr>
To: Francisco Curbera <curbera@us.ibm.com>
CC: Prasad Yendluri <pyendluri@webmethods.com>, "WS-Desc WG (Public)" <www-ws-desc@w3.org>
Is this then calling for a new issue to be opened?


Francisco Curbera wrote:

> Prasad,
> As I recall it, the intended interpretation matches the one you found in
> the WSDL yahoo groups list. I think there was some concern at the time with
> failing to  fully specify the contents of the body element - as your
> interpretation seems to imply.  I have to agree, though, that the whole
> element/type issue is ready for a thorough review.
> Paco
> Prasad Yendluri <pyendluri@webmethods.com>@w3.org on 05/07/2002 07:23:03 PM
> Sent by:    www-ws-desc-request@w3.org
> To:    "WS-Desc WG (Public)" <www-ws-desc@w3.org>
> cc:
> Subject:    Issue:soap:body binding description confusing when use is
>        "literal"
> I tried to look for an issue that might have captured this but, there does
> not seem to be any that capture this specific issue. I am hoping that this
> would be a simple case of someone on the list giving the correct (and
> intended) interpretation of the text in the spec that I draw attention to
> below:
> "Section 3.5 soap:body (binding)
> The soap:body binding element provides information on how to assemble the
> different message parts inside the Body element of the SOAP message.
>    If the operation style is rpc each part is a parameter or a return value
>    and appears inside a wrapper element within the body (following Section
>    7.1 of the SOAP specification). The wrapper element is named identically
>    to the operation name and its namespace is the value of the namespace
>    attribute. Each message part (parameter) appears under the wrapper,
>    represented by an accessor named identically to the corresponding
>    parameter of the call. Parts are arranged in the same order as the
>    parameters of the call.
>    If the operation style is document there are no additional wrappers, and
>    the message parts appear directly under the SOAP Body element. "
> This I understand. However later in the same section we have the following
> text.
> "If use is literal, then each part references a concrete schema definition
> using either the element or type attribute. In the first case, the element
> referenced by the part will appear directly under the Body element (for
> document style bindings) or under an accessor element named after the
> message part (in rpc style). In the second, the type referenced by the part
> becomes the schema type of the enclosing element (Body for document style
> or part accessor element for rpc style).
> The confusing part (to me) here is the last sentence above. What is this
> really saying for "document" style? Is this same as a part with the "schema
> type" as given by the "type" attribute of the part will appear directly
> under the body or something else? That is, this is same as the "element"
> case but for the fact the an element of the "type" must appear in the body
> as opposed to the element itself (as in the "element" case)?
> I have seen people interpret this to mean something radical. E.g. from the
> WSDL yahoo groups list (see: http://groups.yahoo.com/group/wsdl/message/753
> ):
>                 >So for a document/literal operation the XSD type
> referenced by the message
>                 > part becomes the schema type of the SOAP Body element.
>                 > Presumably this mean that a document/literal operation
> can only reference a single
>                 > message part that uses the 'type' attribute to refer to
> an XSD type? Can
>                 > the message only have one such type?
> This seems to be wrong interpretation of the text (undelined above). Any
> comments?
> Thanks, Prasad
Received on Thursday, 23 May 2002 05:36:55 UTC

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