Callers can send message instances
that either (a) include the "Fax" element with content*, (b) exclude the "Fax"
element altogether, or (c) include the "Fax" element without content but with an
xsi:nil="true" attribute. Type serializers, however, do not usually
support scenario "b" because programming languages can't distinguish
whether a type member is intentionally NULL or just
Message receivers usually interpret
the lack of an element as "left unsaid" and the presence of an element with
empty content and an xsi:nil="true" attribute as "set to NULL". Type
serializers summarily convert type members with NULL values to xsi:nil
declarations, which can cause unintended data changes on the server.
Data binding tools need to have a
way to distinguish unassigned type members (which should be ommitted from the
serialization) from members assigned to NULL (which should be serialized with
It seems like this problem is
similar to database programming. Columns excluded from an UPDATE statement
are not summarily set to NULL – they are left unchanged. Maybe solutions
to database binding could be reviewed for schema?
I know the whole xsi:nil /
minOccurs=0 issue has been well-trodden, but I wanted to submit this facet of
the problem because there is some real pain.
Erik Johnson Epicor
there is a simpleType restriction in place like