An optional XML element can be left out. A nillable element can appear with xsi:nil="true". These are separate permissions, and Spyne, then still using the rpclib package name, coupled them in a way that produced invalid responses.
My first patch changed the condition that decided whether to serialize an empty member:
-elif subvalue is not None or (not v.Attributes.nillable or v.Attributes.min_occurs > 0):
+elif subvalue is not None or v.Attributes.min_occurs > 0:The old expression included a None value merely because the member was not nillable. That sent an explicit nil for an optional field whose schema did not permit one. Removing that branch let an absent optional value stay absent.
| Schema property | Question it answers |
|---|---|
minOccurs="0" |
May this element be omitted? |
nillable="true" |
May this element explicitly carry nil? |
The first patch merged.
The second patch, merged two days later, repaired the receiving side’s soft validation. An explicit nil had to be checked against the field’s own nillable setting. The code also tried to consult _has_non_nillable_children, an attribute that did not exist on the affected model attributes. Removing it stopped valid nillable strings from failing that check.
The fixes were small because the model already contained the two pieces of information. The problem was asking one of them to answer the other’s question. Each patch corrected one decision about how absence or nil passed through the protocol.