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?]