W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2003

WSDL 1.2 drops "use", keeps "encodingStyle"

From: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>
Date: Wed, 26 Feb 2003 09:45:46 +0100
Message-ID: <3E5C7EBA.5090609@crf.canon.fr>
To: Simon Fell <soap@zaks.demon.co.uk>
CC: xml-dist-app@w3.org

Simon,

No worries, the "use" attribute has been removed, but the 
"encodingStyle" attribute is still in.

Two differences with WSDL 1.1:
1) encodingStyle accepts a single URI only, not a list of URIs;
2) encodingStyleDefault[1] specifies a default encoding for all 
operations in a binding.

Sorry if this was not entirely apparent in Arthur's rational.

Jean-Jacques.

[1] 
<http://dev.w3.org/cvsweb/~checkout~//2002/ws/desc/wsdl12/wsdl12-bindings.html?content-type=text/html#_soap_binding_encoding>

Simon Fell wrote:
> I thought that the requirements detailed in R028 would require the
> description of SOAP encoded messages.
> 
> Whilst I understand the interop issues around encoded messages, and
> why you'd want to avoid it, shouldn't that be resolved at the SOAP
> level ?
> I'm concerned that if WSDL ends up being able to describe only a
> subset of valid SOAP messages, all that means is yet another format
> will appear to describe the set of messages WSDL can't describe.
> 
> Cheers
> Simon
> www.pocketsoap.com
> 
> On Mon, 24 Feb 2003 14:29:58 -0800, in soap you wrote:
> 
> 
>>The WS Description WG wanted to point out a change we made to WSDL 1.2
>>that changes the way messages that use SOAP Encoding are described, and
>>solicit your reaction.  The "use" attribute on WSDL 1.2's <soap:body>
>>element has been dropped.  The rationale (compiled by Arthur Ryman of
>>IBM) follows.
>>
>>The WSDL 1.1 SOAP binding currently has a use attribute which can take
>>the values literal and encoded. The use attribute interacts with the
>>encodingStyle attribute. The cases are as follows:
>>
>>1. use="literal", encodingStyle="". The SOAP message is exactly as
>>described by its XML schema, but nothing is claimed about how the schema
>>was derived.
>>
>>2. use="literal", encodingStyle="some-URI". The SOAP message is exactly
>>as described by its XML schema and the schema was derived using the
>>encoding algorithm identified by some-URI. The writer of the message is
>>required to create it exactly as described by the schema. The knowledge
>>of the encoding algorithm can be exploited by tools that might generate
>>a data structure from the schema. The main example here is SOAP
>>encoding. WS-I.org is defining a new algorithm for object graphs.
>>
>>3. use="encoded", encodingStyle="some-URI". The SOAP message is not
>>necessarily as described by the XML schema which was derived using the
>>encoding algorithm identified by some-URI. There may be variants in the
>>message not described in the schema. The reader of the message is
>>required to understand all variants. For example, in SOAP encoding,
>>element content can appear inline or via reference (e.g. for
>>multi-reference objects).
>>
>>4. use="encoded", encodingStyle="". This case is not allowed. If the
>>SOAP message is encoded then there must be an encoding style.
>>
>>WS-I.org has studied interoperability problems and has come to the
>>conclusion that only use="literal" should be used where interoperability
>>is required. Since interoperability is one of the main features of Web
>>services, it seems reasonable to follow this recommendation in WSDL 1.2.
>>This recommendation does not really restrict the message content. It
>>only restricts how the message is described in WSDL. Case #3 is
>>disallowed. This places the burden on the Web service implementor to
>>describe the messages exactly.
>>
>>In many cases, SOAP encoding can be described by an accurate schema,
>>e.g. if the data is tree like. Also, the new WS-I.org proposal for
>>encoding object graphs does have accurate schemas. It is therefore not
>>necessary to remove the encodingStyle attribute since this is a valuable
>>hint to tools. However, if only use="literal" is supported, then the use
>>attribute can be safely dropped.
> 
> 
Received on Wednesday, 26 February 2003 03:46:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:13 GMT