«

We have a customer who sent us a WSDL containing the following
snippet:

<message name="PP6000.Execute">
<part name="Xmlreaderlvcaux" type="xsd:string"/>
</message>

We imported this into our tool (webMethods) and had problems invoking
a call to the other. Installing a sniffer, I noted the following
being sent:

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlnssd="http://www.w3.org/2001/XMLSchema"
xmlnssi="http://www.w3.org/2001/XMLSchema-instance"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<ser-root:Execute xmlns:ser-root="http://..[removed]..."
SOAP-ENC:root="1">
<_x0058_mlreaderlvcaux xsi:type="xsd:string">random
text</_x0058_mlreaderlvcaux>
</ser-root:Execute>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

As you can see, the parameter name was remapped from Xmlreaderlvcaux
to _x0058_mlreaderlvcaux. I opened a service ticket assuming this was
an error, and I was referred to this URL:
http://www.w3.org/TR/2003/REC-soap12...30624/#namemap, which
does indicate that this application name can (should?) be mapped as
indicated (section B1-6 Case 3).

So, before I tell my customer he needs to fix his soap server, I
wanted to confirm that even though the parameter name was not remapped
in the WSDL he sent us, his server should still accept the remapped
name when we send it back. Or was our toolkit incorrect in its
remapping of the name, since the WSDL did not include the remapping?
I guess I'm just trying to figure out which end is at fault here.

And yes, if I manually intercept the message and change the part name
back to its original name, the other side does accept the message.

Thanks