Everything you say is dead on. Axis' support for doc/lit is extremely buggy. That said, it can't improve unless the developers know about those problems. Enter bugs so that they can get fixed.
The idea is that eventually WS tools will move to doc/lit as a default. The problem is that most tools right now default to rpc/enc so there is going to be a painful period where support is weak and you will need to wait a while for support to mature a bit. -----Original Message----- From: Paul Mackles [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2003 3:21 PM To: '[EMAIL PROTECTED]' Subject: The whole soap-encoding vs. doc/literal debate Hi, After lurking on this list for the last month or so as well as reading various articles, I convinced myself that I had better start using doc/literal encoding for the rpc style web service that I am working on - even though things were working pretty well using soap-encoding (using php and soap::lite on the client-side and java on the server-side). Not suprisingly, after switching to doc/literal encoding, I started getting different, not so desirable, results. Specifically, the java Maps I was passing from java to perl were no longer being deserialized as real perl hashes on the the perl-side. I still haven't figured out what I am doing wrong but before I torture myself anymore, I need somebody to tell me why I shouldn't just go back to using soap-encoding. I understand soap-encoding is vague in certain respects and makes life more difficult for the toolkit implementors but what about us folks who are just building apps? Why should we care? I know my WS works with soap::lite and I am pretty sure it will work with dotnet. Lacking any real world experience in using WS I am struggling with these questions. For what its worth, I noticed that both the amazon and google WS apis use soap-encoding - should I be taking any solace in that? Thanks, Paul
