[Fedora-suds-list] Null/optional items in complex types

[Jeff Ortel]

Hey Martin,

Handling NULL and nil is tricky in XML.  There is a big difference between the 
presents/absence of a element and having the element be empty <middleName/>.  Handling 
these nodes depends on how they are defined in the XSD.

Suds follows these rules which (I believe) directly reflect XSD/XML specifications:

An /optional/ element that is omitted from the document is just that - not specified.  So, 
suds will not create an attribute for it in the unmarshalled object.

A /required/ element that is omitted from the document is represented in the unmarshalled 
object as an attribute with a value = None.  It's supposed to be there and isn't.  It's 
absence is interpreted as nil.  Although technically, it's required by the XSD so it's 
absence makes the document invalid.

An /empty/ (nil) element <middleName xsi:nil="1"/> contained in the document is 
represented in the unmarshalled object as an attribute with a value = None.  But, this 
element must be defined in the xsd as <xs:element xs:nillable="1"/>.

An /empty/ (non-nil) element <middleName/> contained in the document is represented in the 
unmarshalled object as an attribute with a value = ''.  None (nil) must be represented in 
the document with xsi:nil="1".

See inline below.

Hope this helps :)

-jeff

On 05/06/2010 02:20 AM, Martin Aspeli wrote:
> Hi,
>
> We are calling a service getUserDetails(). It returns a complex type
> "userDetails" with various fields, let's say first/middle/last name to
> keep it simple. The WSDL says middleName is optional (it has
> <xs:element minOccurs='0' name='middleName' type='xs:string'/>).
>
> Our code expects the return value to have a middleName attribute with
> a value of None if the middle name is not set.

Because it is optional (minOccurs='0'), suds will not create an attribute when the node is 
not in the document.

>
> However, what's happening is that the service (being written by a
> third party, I believe using JBoss and Axis) is not returning anything
> at all for this attribute. The complex type simply doesn't have it, so
> when we do details.middleName, we get an AttributeError.

Right.  It's optional so you need to check first.

>
> I can't post the WSDL or response XML here on a public list, but
> basically it looks to me like the response is omitting the tag for the
> middle name altogether and Suds just ignores it, rather than
> consulting the WSDL and saying "this property should be here, it's not
> in the response, set it to None", as we were expecting.

Since <middleName/> is optional, it's not necessarily /supposed/ to be there.  It's 
optional so it /may/ be there.

>
> Actually, there's one other problem: In the userDetails complex type,
> we have an attribute that's of another complex type, say "address". If
> This is not set, it comes through as an empty tag "<address />" in the
> response body. Suds treats that as an empty string, instead of None,
> as I would've expected.

As described above, empty does not always = None.

>
> So:
>
>   - Is this a problem with our understanding of Suds?

I think so.

>   - Is this a bug in Suds?

Don't think so ;)

>   - Is this in effect an invalid response from the server?

Seems valid to me.

>
> Cheers,
> lMartin
> _______________________________________________
> suds mailing list
> suds at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/suds

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5126 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.fedoraproject.org/pipermail/suds/attachments/20100506/c2b80d86/attachment-0001.bin