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: Thu, 26 Jan 2006 10:33:55 -0000
Message-ID: <C71BA56B989C434C99D266651C86D6AC10C52A27@i2km31-ukdy.domain1.systemhost.net>
To: <peter.hendry@capeclear.com>, <public-xsd-databinding@w3.org>
>>  where ???? may be either minOccurs="0" or nillable="true".
or neither! (minOccurs="1" & nillable="false" the default) but either
 >>  <E1 A1="text"></E1> <!-- or <E1 A1="text"/> -->
should always result in a *content* (not value) of "" because
xsi:nil='true' has not been set on the instance doc.
This is what I took Sandy's mail to mean ( but help me if I am missing
something): that tools must allow null content in conjunction with
attributes. I think our experience of tools in the past has not always
been great in this respect in that, when unassigned by the code,
elements defined as minOccurs=0 may still be sent down with
xsi:nil="true" irrespective of  the nillable assignment in the schema
and not including any attributes marked use="required" (not that 2
wrongs make a right but this is doubly wrong)

	-----Original Message-----
	From: public-xsd-databinding-request@w3.org
[mailto:public-xsd-databinding-request@w3.org] On Behalf Of Peter Hendry
	Sent: 25 January 2006 09:49
	To: public-xsd-databinding@w3.org
	Subject: Re: ISSUE-7 minOccurs=0 & xsi:nil
	I think Sandy Gao's mail about xsd:default handling is very
relevant in this discussion. Sandy states
	    "Similarly for xsi:nil (which people also tend to
	            it applies to element content too (as opposed to
element itself). 
	            When xsi:nil is true, the element still has a value:
all its attributes 
	            plus its content (which happens to have nil value)."
	Consider the case of a complexType with simpleContent that has
	    <complexType name="A">
	          <extension base="string">
	             <attribute name="A1" type="string"/>
	    <complexType name="B">
	          <element name="E1" type="tns:A" ????/>
	    <element name="BE" type="tns:B"/>
	where ???? may be either minOccurs="0" or nillable="true". 
	In this case should the possibility of minOccurs="0" be ruled
out because if the attribute "A1" has a value then how do you tell
whether an empty element "E1" is null or "" (the empty string)? 
	If we have
	    <complexType name="B">
	          <element name="E1" type="tns:A" minOccurs="0"/>
	Then does the document
	  <E1 A1="text"></E1> <!-- or <E1 A1="text"/> -->
	result in the value "" or null for field E1 in an object model?
I believe in this case nillable="true" would have to be used to make
this clear.
	Paul.V.Biron@kp.org wrote: 

			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.

		The update-semantics of Erik's use-case are NOT part of
the XML Schema 
		spec.  That is, it is completely up to the markup
language designer (i.e., 
		schema author) do decide what the difference between
		        <child xsi:nil='true'/>
		is...with regard to the expected behavior in a receiver.
		xsi:nil means no more nor less than what is stated in
section 2.6.2 of the 
		spec [1].:
		        ...signaling that an element should be accepted
		        valid when it has no content despite a content
		        type which does not require or even necessarily
		        allow empty content. An element may be valid
		        without content if it has the attribute xsi:nil
		        with the value true. An element so labeled must
		        empty, but can carry attributes if permitted by
		        the corresponding complex type.
		So, this means that our advise to tool builders should
be that they give 
		users the option of specifying what xsi:nil='true'
means...e.g., whether 
		it has Erik's update-semantics or something else
		[1] http://www.w3.org/TR/xmlschema-1/#xsi_nil
Received on Thursday, 26 January 2006 10:34:21 UTC

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