RE: Issue - 7 minOccurs=0 etc

I should point out that we have a lot of internal debate about how
service operations that *retrieve* database data handle NULLs.  In one
camp are those who believe we should just leave them out of the message
to minimize the message size (hence minOccurs="0" on all nullable
columns).  In the other camp are those who think we should always
include NULL values in the message to help force a consistent record
shape (makes it easier to build transforms), which would change the
strategy to *never* use minOccurs="0" and *always* return NULL data as
xsi:nil="true".  

 

One effect of going with the latter approach is you eliminate the
problem where type serializers forget to set members that have default
values in the schema to NULL if the element is not present in the
message (an issue I submitted today).  

 

On that, the first camp basically says "yes, true, but it sucks to be
never allowed to use minOccurs="0" in a service response.  Transform
authors should have to read schemas like the rest of us."  The second
camp pulls out a 2000 line XSL file and says, "Here - debug this."  We
all down our pints, go home, and repeat this debate 3 months later. 

 

________________________________

From: public-xsd-databinding-request@w3.org
[mailto:public-xsd-databinding-request@w3.org] On Behalf Of
jon.calladine@bt.com
Sent: Tuesday, January 24, 2006 10:06 AM
To: public-xsd-databinding@w3.org
Subject: RE: Issue - 7 minOccurs=0 etc

 

To promote discussion around the interpretation and exploitation of
minOccurs=0 and nillable="true" here is an excerpt from an exchange
with Erik

 

[Erik: The soapbuilders [original] conclusion was to avoid nillable
completely because the toolkits were unpredictable, which I suppose just
amplifies the problem :-).  I assume that nillable was added to the XML
Schema specification mainly to distinguish empty content from a NIL
value.  Databases already do this - and without nillable, there was no
solution for accurately mapping data between a database and an XML
document (at least for string types).  So, I think schema authors should
keep in line with that intent.  minOccurs="0" means simply that the
message does not need to include the element to still be considered
valid.  So, the missing piece of the puzzle is to have some way for
developers to make it clear that a value was "left unsaid".  Nillable
can be used independently and just states that messages can explicitly
state the value of an element.  

 

I don't know if this helps but the guidelines we use for binding message
data to databases goes like this:

 

Scenario       

minOccurs="0"

Nillable="true"

Database Interpretation

Message is "new data".

Only for elements representing values that can be NULL or have a DEFAULT
constraint.

Same

Elements not in the message are omitted from the INSERT SQL, Elements
with xsi:nill="true" attributes are in the INSERT SQL with NULL values

Message is "update data".

Used for all element declarations except key fields (or other
row-identifying elements).  Updates might only contain fragments of
database records.

Used only on elements representing database columns that can contain
NULL values.

Elements not in the message are omitted from the UPDATE SQL, Elements
with xsi:nill="true" attributes are in the UPDATE SQL with NULL values

Message is "retrieved data" and the database column list is static.

Used only on elements representing database columns that can contain
NULL values.

Used only on elements representing database columns that can contain
NULL values.

 

Message is "retrieved data" and the potential list of columns received
is unknown at compile time (columns not requested are omitted from the
message).

Used for all element declarations except key fields (or other
row-identifying elements).  

Used only on elements representing database columns that can contain
NULL values.

 

 

One other points on this:  Our standard is to disallow empty database
values - there are no values of "" in the database, they have to be
NULLs.  This means our schemas always have restriction facets to make
sure the data is in bounds: minLength, etc.  Maybe the Databinding WG
should validate my thinking with the W3C XML Schema WG?]