- From: Don Box <dbox@microsoft.com>
- Date: Mon, 24 Feb 2003 19:37:40 -0800
- To: "Simon Fell" <soap@zaks.demon.co.uk>, <xml-dist-app@w3.org>
> -----Original Message----- > From: Simon Fell [mailto:soap@zaks.demon.co.uk] > Sent: Monday, February 24, 2003 7:17 PM > To: xml-dist-app@w3.org > > > I thought that the requirements detailed in R028 would require the > description of SOAP encoded messages. Last time I checked, you can describe the SOAP encoding from Part II in XML Schema. > 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 ? People too often conflated SOAP's encoding style (a.k.a. SOAP/1.1 section 5) with the utterly underspecified WSDL/1.1 use="encoded" feature. The two were orthogonal. > 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. For one, I believe that XML schema (or RNG for that matter) can capture the Part II encoding for those that elect to use it. More to the point, if for some reason XML Schema (or RNG) are inadequate, I would far rather see people NOT bastardize XML schema the way that WSDL/1.1 did. > 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 Monday, 24 February 2003 22:38:13 UTC