Footnote: bare is in the eye of the beholder

For WS-I Basic Profile compatibility it should not only have only one child element, there is another requirement that you only have one operation with that signature! So you can't have two methods that take the same argument.

So, while I agree with you two guys that bare is much nicer, I think the general advice right now should be to NOT use it, if you want to interop with other stacks.

You can of course be WS-I BP compliant by using only one argument and only having one methods per class that has that message signature (i.e. only one method that takes that type as a parameter), but that by itself is quite a complicated guidline already, right? And then: While you can implement an Axis (that being the other main stack, right?) service that interops with that, it is a pain. Things might improve with Axis 1.2, which is in beta right now. But again, if you just want easy interop with what is running right now on the servers in this world, you can't really count on that.

On the other hand: If you don't use bare, you have a slightly less elegant solution but don't have to worry about any of these interop problems. Way better, right?

Obviously all this changes once you take WS-Addressing into account. But if you want interop right NOW, you are much better adviced to leave your fingers from that.

Maybe you should point out these points on your main blog? I remember implementing a couple of web services with bare without knowing all that, expecting that interop with Axis would be easy. I had to change everything back after trying things out and it was just incredible difficult to find good information on all this.

Interesting - I wasn't aware of the BP constraint you mention. It does seem to counter-indicate the use of doc/literal/bare from an interop standpoint.

Tim?

Ah - I spoke too soon. Tim has already addressed this. That's what I get for being offline for a while. :p