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

Re: Collecting issues against WSDL 1.1

From: Herve Ruellan <ruellan@crf.canon.fr>
Date: Fri, 05 Apr 2002 14:56:29 +0200
Message-ID: <3CAD9EFD.8030907@crf.canon.fr>
To: Jean-Jacques Moreau <moreau@crf.canon.fr>
CC: Web Service Description <www-ws-desc@w3.org>, Sanjiva Weerawarana <sanjiva@watson.ibm.com>
Dear all,

Being member of the W3C XML Protocol Working Group, I see the following 
issues regarding the interoperability of WSDL 1.1 and SOAP 1.2.
(Note that SOAP 1.2 specification is not finished yet, so I based all my 
comments on a recent working draft which may be found at [0a] and [0b]).

- Issue 1: transmission primitives
Currently WSDL 1.1 defines 4 transmissions primitives (one-way, 
request-response, solicit-response, notification).
SOAP 1.2 defines the concept of Message Exchange Pattern (MEP) [1]. A 
MEP is a template for the exchange of messages between SOAP Nodes.

In its current state, WSDL 1.1 is not able to define which MEP a Web 
Service will use over a SOAP binding (several different MEP can define a 
one-way transmission primitive).

_Proposed solution_
As MEP are almost independant of SOAP 1.2, I would suggest replacing 
transmission primitives by MEP.

- Issue 2: style="rpc|document"
In SOAP 1.2, RPC is an extension of SOAP, that is a particular use of SOAP.

Regarding SOAP 1.2, the style attribute can only be seen as a hint that 
SOAP 1.2 is used with *an* RPC extension. It does not specify which RPC 
extension is used nor any other important informations like which 
encoding is used for the parameters...

_Proposed solution_
Remove the style attribute and create a way for defining which SOAP 
extensions are used (see below).

- Issue 3: transport="uri"
A SOAP 1.2 message can be transfered over many protocols. SOAP 1.2 
defines bindings for specifying use of underlying protocols. For example 
[2] describes *an* HTTP binding for SOAP 1.2.

The transport attribute allows to define which binding is used for a Web 
Services accessed over SOAP 1.2. However this attribute may be ill named 
(there may exists several bindings for a particular transport) and it 
does not allow specifying which options of a binding are used.

_Proposed solution_
Use the soap:binding element to define which binding is used and 
describe any other necessary informations for the use of this bindings.

- Issue 4: soap:header
 From [3]: "A SOAP header provides a mechanism for extending a SOAP 
message...". A SOAP extension not only needs to define one or more new 
SOAP headers, but also to specify the semantics of the headers and of 
the rules for processing them.

The soap:header allows defining a new SOAP header block but give no way 
of defining its semantics and processing rules.

_Proposed solution_
Remove the soap:header element and provide a way for defining which SOAP 
extensions are used (see below).

- Issue 5: SOAP 1.2 extensions
New functionnalities can be added to SOAP 1.2 through the use of 
extensions (see for example [4] or [5]).

WSDL 1.1 does not provide a way for specifying which extensions may or 
must be used to access a Web Service.

_Proposed solution_
Create a way to define which SOAP 1.2 extensions are supported by a Web 
Service, to define if their use is mandatory or not and how those 
extensions are used (which options/configurations/features are 

- Issue 6: soap:body parts
Currently WSDL 1.1 says that the parts attribute indicates which message 
parts appear somewhere within the SOAP body. Other parts may appear in 
other locations (such as attachements).

WSDL 1.1 does not specify the precise structure of the body (are the 
parts allowed to appear in any order, may they be contained in element 
information items descendant of the body...).
In addition, it does specify nothing for the parts not transmitted in 
the body.

_Proposed solution_
Have WSDL 1.1 define in a precise way the structure of the SOAP body. 
Give some directives for specifying in a Web Services description what 
happen to the parts not transmitted in the body (is it possible to not 
transmit them...).

- Issue 7: soap:body encodingStyle
In WSDL 1.1, the encodingStyle attribute is a list of uri.
In SOAP 1.2, the encodingStyle attribute is an uri. Moreover, an element 
can use an encodingStyle while some of its children use another 
encodingStyle. (Note: the usage of the encodingStyle attribute is being 
discussed currently and may differ in the final version of SOAP 1.2).

WSDL 1.1 and SOAP 1.2 does not have the same use of the encodingStyle 

_Proposed solution_
Change the WSDL 1.1 use of the encodingStyle attribute.

- Issue 8: soap:address
WSDL 1.1 uses the soap:address element to specify the destination of the 

The way of targetting a WSDL message through SOAP 1.2 is dependant on 
the binding used and may also depend on the MEP used. The soap:address 
element may not be sufficient to describe this targetting.

_Proposed solution_
The target of a WSDL message should be defined in the soap:binding element.

Hervé Ruellan


[0a] http://www.w3.org/2000/xp/Group/2/03/23/soap12-part1-1.37.html
[0b] http://www.w3.org/2000/xp/Group/2/03/23/soap12-part2-1.46.html
[1] http://www.w3.org/2000/xp/Group/2/03/23/soap12-part2-1.46.html#soapmep

Jean-Jacques Moreau wrote:
> Dear all,
> I seem to have volunteered myself for collecting an initial list
> of issues against the WSDL 1.1 specification.
> I you have any such issue, can you please send them to me asap so
> I can add them to our issues list _before_ our first face-to-face
> meeting?
> Thank you,
> Jean-Jacques.
Received on Friday, 5 April 2002 07:58:47 UTC

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