Description:
------------
The SOAP extension handles the return of a single complex type perfectly (eg. the test script schema030.phpt) but the encoding changes if another part is added to the response. It looks like it is not able to get the type information from the WSDL correctly when there are multiple parts.

Consider a server exposing two functions, test1 and test2 via SOAP 1.1 using rpc/encoded style. Suppose the first returns the testType complex type from schema030.phpt (a sequence of an integer followed by a string) and the second returns two parts, the first a testType complex type and the second a simple type, say a string.

Simple client and server scripts are available (see attached) and operate in WSDL mode.

The SOAP response for test1 will be that expected in schema030.phpt. In particular the one return parameter is encoded as:
<testParam xsi:type="ns1:testType"><int xsi:type="xsd:int">123</int><str xsi:type="xsd:string">str</str></testParam>

Now the test2 simply adds a second part to the response so we expect:
<testParam xsi:type="ns1:testType"><int xsi:type="xsd:int">123</int><str xsi:type="xsd:string">str</str></testParam>
<strParam xsi:type="xsd:string">example</strParam>

but we actually get:
<testParam xsi:type="SOAP-ENC:Struct"><int xsi:type="xsd:int">123</int><str xsi:type="xsd:string">str</str></testParam>
<strParam xsi:type="xsd:string">example</strParam>

The xsi:type attribute of the testParam tag changes when an extra part is included in the message.

Similar behaviour occurs when the testParam part is changed to an array of the testType complex type: one part works fine but with two parts the array is encoded like:
<testParam xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="SOAP-ENC:Struct[1]"><item xsi:type="SOAP-ENC:Struct"><int xsi:type="xsd:int">123</int><str xsi:type="xsd:string">str</str></item></testParam>
where again SOAP-ENC:Struct should be ns1:testType but also SOAP-ENC:Array should be ns1:ArrayOftestType where ArrayOftestType is defined as a restriction on SOAP-ENC:Array to only accept elements of type testType.

Note that one can work around this problem by creating a SoapParam object with a SoapVar object for the problem return part(s) as if in non-WSDL mode.

Reproduce code:
---------------
Simple client and server scripts are available for test at
http://mantis.york.ac.uk/~alex/client.php and
http://mantis.york.ac.uk/~alex/server.php
using the WSDL at
http://mantis.york.ac.uk/~alex/test.wsdl

The source is available at
http://mantis.york.ac.uk/~alex/client.php.txt and
http://mantis.york.ac.uk/~alex/server.php.txt

Expected result:
----------------
The client should produce:
test1:
...
Response:
...<ns1:test1Response><testParam xsi:type="ns1:testType"><int xsi:type="xsd:int">123</int><str xsi:type="xsd:string">str</str></testParam></ns1:test1Response>...
test2:
...
Response:
...<ns1:test2Response><testParam xsi:type="ns1:testType"><int xsi:type="xsd:int">123</int><str xsi:type="xsd:string">str</str></testParam><strParam xsi:type="xsd:string">example</strParam></ns1:test2Response>...

Actual result:
--------------
The actual output observed is:
test1:
...
Response:
...<ns1:test1Response><testParam xsi:type="ns1:testType"><int xsi:type="xsd:int">123</int><str xsi:type="xsd:string">str</str></testParam></ns1:test1Response>...
test2:
...
Response:
...<ns1:test2Response><testParam xsi:type="SOAP-ENC:Struct"><int xsi:type="xsd:int">123</int><str xsi:type="xsd:string">str</str></testParam><strParam xsi:type="xsd:string">example</strParam></ns1:test2Response>...

Notice how the testParam xsi:type attribute changes between test1 and test2.