The actual payload is a little more complex than that.
The payload really looks like this (even this is somewhat simplified):
In this payload, the MatchPartyUpdatePayload element itself is optional (if the name, address, phone, and emails hasn’t changed, no need to specify the payload). Within the MatchPartyUpdatePayload element, Name, Address, Phones, and Emails are all optional (they are only needed if the data is being changed). Within some of those arrays, the objects themselves have optional fields (e.g., Line2 and Line3 for the NonStandardUS object).
The problem with the null-safe access is that it is putting the null at the lowest level. For example, let say that I have no Address element, what I am ending up with is a fully populated Address element with all values set to null. This doesn’t work for me because the NonStandardUS address element, if present, has 4 required fields and 2 optional fields. And the Foreign and NonStandardUS fields are mutually exclusive. My validation code verifies that any Address element has at least the 4 fields set to non-null/non-empty values. What would be better for me would be for the entire address list to be either empty or set to null without creating the nested address object and setting all 6 fields to null.
My company has some very large payloads (100s of fields with optional elements at various points in the message hierarchies, some of which are objects or arrays of objects). Having the Mapper set dozens of leaf node fields to null quickly becomes intractable since I would have to write a script to walk the entire tree and prune off the elements where all fields are set to null, starting at the leaf nodes and working my way back up. If I have to do that, I might as well just write a script to do the mapping the way I need it in the first place, right?
Hope this helps,