Technically, the "literal" encoding of Apache SOAP is *not* the same as the literal encoding as specified by, say, WSDL 1.1. The Apache SOAP payloads will specify an encodingStyle of http://xml.apache.org/xml-soap/literalxml. To my knowledge, Apache SOAP is the only SOAP implementation that understands that style.
Although I have not studied it much, I would think that in the absence of that encoding specification, .NET would have no problem with the payloads. In fact, I would guess that if you wanted to do a little lower-level .NET coding, you could convince it to ignore the attribute. You could alternatively hook the .NET processing chain and simply remove the attribute. You will not be able to directly move to rpc/encoded with an Element, as you have probably discovered. For rpc/encoded, you need to think in terms of data types, be they primitives or classes of your own creation. You need to map your current XML to types. Scott Nichol Do not send e-mail directly to this e-mail address, because it is filtered to accept only mail from specific mail lists. ----- Original Message ----- From: "Donato, Sam (ITS)" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, December 11, 2003 4:32 PM Subject: Need to switch my RPC/Literal to RPC/Encoded > I have developed a service which contains a number of methods which return a > org.w3c.dom.Element. I Use WSAD to develop the services and it defaulted to > RPC/Literal encoding. This works great for me, however I developed it to > communicate with a .NET application which cannot use it because of the > literal part. When I try to set the output as encoded, it doesn't work with > the xml Element. > > Does anyone have a suggestion of what I should change the Element to so that > I can use RPC/encoded but still keep the XML format? >
