Perhaps -- but with SOAP Section 5 we encountered interoperability issues with types as simple as booleans. And when you start using complex types, you frequently need to supply custom deserializers because the containers are incompatible. We generally don't experience interop issues with doc/literal unless we use some of the more advanced constructs, such as <choice> groups.
Anne ----- Original Message ----- From: "Simon Fell" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 19, 2003 1:22 AM Subject: Re: design question On Wed, 18 Jun 2003 23:17:24 -0400, in soap you wrote: >Doc/lit doesn't define type mappings, but it definitively specifies the >structure of the message via XML Schema. Because the two applications know >in advance exactly what the message structure is, the details of how the >SOAP message processor maps the XML Schema to language types doesn't matter >to the other application. When using rpc/encoded, the two applications have >not agreed to a specific message structure. The SOAP message processor >generates the SOAP message structure based on it's specific interpretation >of SOAP Section 5, and there's no definitive schema of the message. The >interoperability issues arise when two different SOAP message procesors >interpret SOAP Section 5 slightly differently. > >Anne In my experience I haven't found 2 toolkit that support the same subset of XSD yet (cause no one supports the whole of XSD), so doc/lit whilst in theory is more interoperable, in practice isn't. section 5 has its issues, but i think the doc/lit camp are making mountains out of molehills about them, whilst not mentioning the practical problems that doc/lit currently has. Cheers Simon www.pocketsoap.com
