I have an WSDl here where I have two different namespaces for the operation/message to be called and for the element to be used in that message. This is defined as two schemas within an wsdl file.
The reason is that a java-Value-Object is transfered over a webservice and for an automatic mapping this value-object has a different namespace then the message it is in. The operation is called document/literal.
With this scenario nusoap will create an invalid XML because it will not print out the namespace for the complex-type.
The XML that is created is:
And the awaited XML is:
<ccdInvalidateIPaymentId xmlns="http://ccd.billing.einsundeins.de"><in0 xmlns="http://rw.payment.valueobject.facade.crm.einsundeins.de"><IPaymentID/><success>1</success><username>tester</username></in0></ccdInvalidateIPaymentId>
As you see the difference is the missing namespace for parameter "in0".
I have debuged around some time and found the piece of code which is responsible for that: in class.wsdl.class on line 1453-1467 these namespace-things are handled.
When the current typeClass is an "element" (this is the case for "ccdInvalidateIPaymentId" then the namespace is inserted when qualified.
But then when the type is "complexType" (like for the part "in0") no Namespace is added to the XML tag at all.
So it seems that nusoap do not await that there could be different namespaces for the message and for the complex-types sended there. Correct?!
My fix would be to replace line 1465 in class.wsdl.php by the following code:
if (isset($typeDef['typeClass']) && $typeDef['typeClass'] == 'complexType' && !empty($ns))
$elementNS = " xmlns=\"$ns\"";
$elementNS = '';
But to be true - I don't know if this has any unawaited side-effects, but generally it would add some more namespaces - even in cases where the namespace of the message and the type is the same - but this is not that bad, or ?!
Scott, thank you for your opinion on that.
I had problems with this patch because some java-Clients do not seems to want a namespace information for an element when the namespace is the same then the ns of the parent element.
So I have adopted that patch on my system to check the namespace of the message/part and the holding element. If it is the same namespace it is not repeated - else it is added ...
because I do not really know how to really fix this I will use this "better-then-nothing-patch" for us ...
@Scott: If you could look into this this would be great, I can send WSDl too if needed.