Tested also using PHP Version 5.2.5-3 same result....

As this still seems to be an issue, here is a complete reproducer:


$soapClient = new SoapClient('service2.wsdl', array ('trace' => 1));

$params = array('code' => 'foo');
$soapClient->newOperation($params);


WSDL excerpt:

<xsd:element name="NewOperation">
  <xsd:complexType>
   <xsd:choice>
     <xsd:sequence>
       <xsd:element name="firstName" type="xsd:string"> </xsd:element>
       <xsd:element name="surName" type="xsd:string"/>
     </xsd:sequence>
     <xsd:element name="code" type="xsd:string"/></xsd:choice>
  </xsd:complexType>
</xsd:element>

(You can find the whole WSDL example file over at http://pastebin.com/UZrPCuJt)


Actual result:

Fatal error: SOAP-ERROR: Encoding: object hasn't 'firstName' property


If you move element name "code" being the first child of <xsd:choice> the code snippet above is working as expected.

I can reproduce this with PHP version 5.3.5 in Ubuntu.

Moving element around in xsd is not a solution for me.

Is there any other workaround available without touching WSDL and XSD?

This issue is also reproducable for PHP 5.3.8. It would be kind to fix it very soon.

It's not really a solution to the bug, but it does make it work. In the passed 
parameters, define all the fields he's claiming as "Missing property".

So if you're using an array, and it says it's missing property 'GetData', do:

$requestArray['GetData'] = '';

and so on with each field, until it's working.

The above example of just putting empty strings for all the other choice fields is 
not working, sure it does not give you the error anymore but in my case the server 
is accepting the first choice as the choice even if I enter data for the second 
choice as well.

Hi,

I'll give a try to help to solve that bug.

I think I identified the problem.

Algorythm for choice validation is : 

<xsd:choice>
     <xsd:sequence>
       <xsd:element name="firstName" type="xsd:string"> </xsd:element>
       <xsd:element name="surName" type="xsd:string"/>
     </xsd:sequence>
     <xsd:element name="code" type="xsd:string"/>
</xsd:choice>

- Enter choice element
- Take first sequence sub element
- Try to match list of elements against properties given to the function
- If fail (like in that example because we use element code instead of the sequence) => pass to second choice
- Try to match list of elements.......
- Success !
- return OK

And that is correctly implemented for what I saw in the soap_encoding.c file in source code of PHP extension.

However, I guess the problem is located in the part of the function analysing the node element of the chain.

If one of the mandatory parameters are note matched, that part of function will generate a php_error with E_ERROR severity level, I guess it's raising exception immediatly in the PHP engine and so it's stopping execution of the algorythm.

To try to solve partialy that problem, we can see that the strict parameter is set to 0 at sub call of model_to_xml_object from a choice segment.

case XSD_CONTENT_CHOICE: {
			sdlContentModelPtr *tmp;
			HashPosition pos;
			int ret = 0;

			zend_hash_internal_pointer_reset_ex(model->u.content, &pos);
			while (zend_hash_get_current_data_ex(model->u.content, (void**)&tmp, &pos) == SUCCESS) {
				int tmp_ret = model_to_xml_object(node, *tmp, object, style, 0 TSRMLS_CC);
				if (tmp_ret == 1) {
					return 1;
				} else if (tmp_ret != 0) {
					ret = 1;
				}
				zend_hash_move_forward_ex(model->u.content, &pos);
			}
			return ret;
		}

However, I think it is not enough, if choice content not only element but also sequence or list or union or any other groupment of element, it will pass the element in that group with it's normal strict level. Not with 0, so it will produce the error log raisin the exception.

Solution could be to try to propagate the strict property to 0 if coming from choice segment, but have to do that on all other segment of code for group type xml tag...

I succeed to confirm my theory by using same example than above but like that :

<xsd:element name="NewOperation">
  <xsd:complexType>
   <xsd:choice>
     <xsd:element name="code" type="xsd:string"/></xsd:choice>
     <xsd:sequence>
       <xsd:element name="firstName" type="xsd:string"> </xsd:element>
       <xsd:element name="surName" type="xsd:string"/>
     </xsd:sequence>
  </xsd:complexType>
</xsd:element>

$params = array('firstName' => 'foo', 'surName' => 'fooBar');
$soapClient->newOperation($params);

In that case, first iteration will pass the element without problem as the stric parameter has been forced to 0 and then when it will reach second iteration with the sequence it will match against our parameters.

So if you only have element in your choice or only element and at end something group type of element, it will work. Not if group type of element is somewhere else.

Reason is, I believe, because of group of elements are not type by themself. Sequence, union and list are not type. It doesn't make sense to pass them to srict or not strict in a choise case. When you make your array or parameters thoses levels dosen't appear. You don't need to create a key sequence to make it work. It's just usefull for schema interpretation.

It's leading me to other part of the problem. If we propagate strict value to 0 to each sub element of a sequence, it will obviously work, but will not really follow the schema as well. You could describe a schema with mandatory elements in a sequence even the sequence can be ignored by the choice legaly.

Exemple :

<xsd:choice>
     <xsd:sequence>
       <xsd:element name="firstName" type="xsd:string"> </xsd:element>
       <xsd:element name="surName" type="xsd:string"/>
     </xsd:sequence>
     <xsd:sequence>
       <xsd:element name="age" type="xsd:string" minOccurs="1"> </xsd:element>
       <xsd:element name="birthDate" type="xsd:string" minOccurs="0" />
     </xsd:sequence>
</xsd:choice>

You'd like to get an error if someone try to use the second choice and forget to put a paremeter age. It woudln't work if you propagate the strict parameter to value 0 to the element node matching...
It's meaning it is legal is this situation to fail to find a matching choice.

So, ultimately it's lead to only one real solution to my eyes. Create a way to disable the raise of php_error at element matching if we are in a choice process.

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.