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

Re: ISSUE-7 minOccurs=0 & xsi:nil

From: <jon.calladine@bt.com>
Date: Tue, 24 Jan 2006 17:54:09 -0000
Message-ID: <C71BA56B989C434C99D266651C86D6AC10C52A21@i2km31-ukdy.domain1.systemhost.net>
To: <public-xsd-databinding@w3.org>
For those that haven't seen this already the recent thread (started by
Erik who raised this issue) on soapbuilders provides some more
background and discussion on this subject.
 
http://groups.yahoo.com/group/soapbuilders/message/10581
 
of particular interest here might be the suggestion contained in Simon
Fell's posting
 
http://groups.yahoo.com/group/soapbuilders/message/10584
 
 
<snip>
For tools that map to objects, what I'd like is for it to be mapped to
something like

private String myFoo;
private boolean myFooExists;

public void getMyFoo() {
return myFoo;
}

public void getMyFooExists {
return myFooExists;
}

public void setMyFoo(String foo) {
myFoo = foo;
myFooExists = true;
}

This doesn't seem like rocket science to me, and .NET comes so close,
except the missed the myFooExists = true in the MyFoo setter, which
makes the client code the somewhat bizzare looking

x.MyFoo = "fred"
x.MyFooSpecified = true;

Except that they only do the specified thing for a subset of simple
types, so you don't actually get the specified thing on Strings.
I've lost count of the number of people that run into this, they just
have x.MyFoo = 123 then wonder why the server is ignoring their MyFoo.
</snip>
 
 
In an exchange with Erik J he observed:
 
<Erik>
*	There needs to be a way to set a value to NULL while also
keeping myFooExists=true.  So, if you call setMyFoo(NULL), myFooExists
still needs to equal true.  We may need a resetMyFoo() function to both
clear the current value *and* set myFooExists to false. 
*	It would be good for toolkits to provide a class-level field
indicating whether *unassigned* (myFooExists=false) should be serialized
as empty elements with xsi:nill="true" attributes (where allowed by the
schema).  That might be convenient for developers. 
*	"default" attributes on element declarations are handled
differently between XML schema and databases.  In databases, you incur
the default value by leaving the column out of an INSERT statement
altogether.  In XML Schema, the default value is incurred by including
the element with empty content.  If a schema has "default" value for
element "MyFoo" and the class instance has myFooExists=false, I don't
have a preference if the toolkit (a) puts the MyFoo element into the XML
with the default value or (b) puts MyFoo into the XML with empty
content.  I personally like (b) because the presence of the "default"
declaration means that the receiver will "make right" the message if the
element content is left empty.  But most developers and toolkits would
probably find (a) much easier to deal with.
</Erik>
 
This first requirement would add something like this to Simon's
suggestion
 
private String myFoo;
private boolean myFooExists;

public void getMyFoo() {
return myFoo;
}

public void getMyFooExists {
return myFooExists;
}

public void setMyFoo(String foo) {
myFoo = foo;
myFooExists = true;
}
 
public void resetMyFoo() {
myFoo = null;
myFooExists = false;
}
public void setMyFooNull(){
myFoo = null;
myFooExists = true;
}

I would like to hear other peoples interpretation of best behaviour for
the case where myFooExists=false and a default value is assigned in the
schema.
 
Regards, jonC
Received on Tuesday, 24 January 2006 17:54:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:20:36 GMT