> Perhaps -- but with SOAP Section 5 we encountered interoperability issues > with types as simple as booleans.
I know at least one implementation that does not handle booleans well, NuSOAP. And guess what: it still has problems with booleans using doc/lit. It was not Section 5 that caused these particular problems, just the way in which the code was written. With your background at Systinet, I am sure you have experience with many more implementations than I, but my experience has been that interop problems were mostly bugs, unimplemented parts of the spec (such as multi-dim arrays) or complex types. The exception was working with the MS SOAP Toolkit, the client for which does not emit xsi:type attributes for elements when using the WSDL-based "high level API". Although the SOAP spec did not mandate the use of xsi:type, most implementers recognized its essential nature. > And when you start using complex types, > you frequently need to supply custom deserializers because the containers > are incompatible. When WSDL is used, it can be the basis for generating de- serialization (and serialization), with no difference between rpc/encoded and doc/lit (in my experience). Without WSDL, you are writing the code yourself. > We generally don't experience interop issues with > doc/literal unless we use some of the more advanced constructs, such as > <choice> groups. My experience is that, when using WSDL, the interop between relatively complete implementations such as Axis and .NET is excellent for both doc/lit and rpc/encoded. The less complete the WSDL support, such as with NuSOAP, the poorer the interop for both doc/lit and rpc/encoded. I originally went off the deep end when ws-i recommended the use of doc/lit exclusively, mainly because there is such an established installed base of rpc/encoded services, both public (e.g., Amazon) and private (e.g. everyone I worked with between 1999 and 2002). I now believe that going forward, it makes sense to have only a single way of constructing messages, and doc/lit is as good as SOAP encoding, and does not introduce new constructs (e.g. SOAP Array) that XML schema does not already have. However, I consider the choice primarily a matter of pragmatism, and dislike statements regarding interop, because I really don't agree with them. I think WSDL does much more to aid interop than doc/lit ever will. OK, enough of my diatribe. Long live doc/lit. Scott Nichol Do not reply directly to this e-mail address, as it is filtered to only receive e-mail from specific mailing lists.
