Nils Millahn - [07/15/08 10:27 AM ] [added debugging information]

Steven Erat - [07/17/08 03:25 PM ] Nils, please attach the full wsdl and the capture of the SOAP Response so that I may attempt to reproduce your observations. Thank you.

Nils Millahn - [07/31/08 04:32 AM ] Apologise for the delay - I can't get any samples to you, since we worked around the issue and I don't have access to the previous webservice anymore. The wsdl declared a 'required' temperature element with 'celsius' and 'fahrenheit' attributes but no child elements. It shouldn't be too hard to replicate but unfortunately I don't have access to the required technology.

Tony O'Brien - [10/06/08 08:14 AM ] We are hitting this same issue. I'm attaching the WSDL and XSD as well as a sample SOAP Response. The message attribute on the loginWarning element is not being populated. Tracing through the code, the parser appears to believe that the loginWarning element is a simple type and as such, parses only the text node inside the element and ignores any attributes. We're using the release 3.1.0 of the SDK.

Tony O'Brien - [01/20/09 11:35 AM ] I have retested the bug (on 3.1.0 and 3.2.0) and it exists on both. The issue is not that the event.result object doesn't have those attributes, but rather the decoded value objects (generated by the Import WSDL process) does not get populated with the value for the 'message' attribute on the 'loginWarning' element. After tracing through the code, I appear to have found the area of concern in the code. In the example attached, the 'loginWarning' element has a definition stating that the maxOccurs is 1 (assumed by Flex, but that's OK). The 'roles' element however, contains an unbounded sequence of 'role' elements. In the XMLDecoder.as file (lines 1112 and 1155 in version 3.2.0), there is difference handling based on whether the maxOccurs is 1 OR greater than 1. Specifically, If maxOccurs == 1, then element = decodeElementTopLevel(definition, elementQName, parseValue(elementQName, applicableValues)); // line 1112 but if maxOccurs > 1, then element = decodeElementTopLevel(definition, elementQName, item); // line 1155 where var item:XML = applicableValues[elementOccurs]; As we can see, there is different processing between these two scenarios, but I'm not sure that it should be. The result is that in the first case (maxOccurs == 1), we perform a parseValue and rely on the XML.hasSimpleContent() function, which returns that the loginWarning element is simple, therefore just passes the toString of the loginWarning element rather than performing further parsing to get any attributes from the element. In summary, it would appear that any element which contains only attributes (no sub-elements) and the definition (either explicitly or implied) states it has a maxOccurs of 1, does not get successfully parsed back into the generated value objects. I hope this makes things a little clearer.

Lauren Park - [02/02/09 01:16 AM ] Opened.

Chris W. Rea - [02/02/09 11:03 AM ] I can also confirm this problem. Our web service was designed with heavy use of attributes instead of elements. For every element that contained another element, it would come through OK. But, for elements that didn't contain any other elements, they would be ignored during SOAP decoding, with the resulting object value in AS3 being null. For what it's worth, I captured our SOAP result and modified it by hand to add a <bogusElement /> to the non-working elements. When replayed to our AS3 app, the objects started coming through as expected. We're on 3.1.0 as well.