W3C home > Mailing lists > Public > public-xsd-databinding@w3.org > January 2006

ISSUE-7: xsi:nil and minOccurs=0

From: Databinding Issue Tracker <dean+cgi@w3.org>
Date: Thu, 12 Jan 2006 09:31:02 +0000 (GMT)
To: public-xsd-databinding@w3.org
Message-Id: <20060112093102.BD1D8331F8@kearny.w3.org>

ISSUE-7: xsi:nil and minOccurs=0


Raised by: Paul Downey
On product: Basic

Many type serializers do not use xsi:nil and minOccurs=0 as schema designers
intend.  Given this schema type:

<xs:complexType name="UpdateMsg">
            <xs:element name="Name" />
            <xs:element name="Fax" minOccurs="0" nillable="true" />

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 xsi:nil="true").

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.  Thanks!

Erik Johnson
Epicor Software Corp.

 * Assume there is a simpleType restriction in place like minLength="1"


Received on Thursday, 12 January 2006 09:31:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:58:12 UTC