Hi Frank, Thanks for clearing this issue up for me. I appreciate it.
Now that Tuscany has implemented this new SDO 2.1 design, it seems pretty important to support Property.isNullable(). Is there a JIRA # for this issue? Is it planned for M3? For us, the SDO 2.1 behavior may prove problematic without it. Thanks again, - Ron ----- Original Message ---- From: Frank Budinsky <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, March 6, 2007 12:14:38 PM Subject: Re: SDO - XML Schema element with default attribute behaves as if nillable="true" Hi Ron, The serialization behavior is based on isSet() behavior, so you should be concerned abou it :-) A property is serialized only if isSet() is true. The SDO 2.1 design is that isSet() returns true if the property has been set (period). Unlike EMF, it has nothing to do with the default value. So if you set to null (valid or not), isSet will return true and you'll get an element serialized and xsi.nil will be used to represent a null value. We've already implemented this behavior in Tuscany. Frank. P.S. Another new feature in SDO 2.1 is Property.isNullable() to determine whether or not null is a valid value for a property. We haven't implemented this in Tuscany yet. Ron Gavlin <[EMAIL PROTECTED]> wrote on 03/06/2007 11:56:22 AM: > Hi Frank, > > Thanks for the quick reply. > > I'm less concerned about the actual isSet() behavior and more > concerned with 1. serialization and 2. the behavior of unset() vs. > set(null). In M2, when nillable = "false", unset() and set(null) > behave similarly in that both adhere to the same serialization > semantics. OTOH, when nillable = "true", unset serializes as an > absent element whereas set(null) serializes w/xsi:nil="true". The > presence of a default attribute triggers the nillable = "true" > serialization semantics. How is this supposed to work in SDO 2.1? > How does it work currently in the Tuscany SVN head? How will it work > in Tuscany M3? > > Thanks in advance. > > - Ron > > ----- Original Message ---- > From: Frank Budinsky <[EMAIL PROTECTED]> > To: [email protected] > Sent: Tuesday, March 6, 2007 11:39:23 AM > Subject: Re: SDO - XML Schema element with default attribute behaves > as if nillable="true" > > > What specifically do you mean by: > > > makes the SDO runtime treat quantity as if the element also had the > attribute, nillable="true". > > If you're referring to the behavior of isSet() after you call set(null), > then this is a feature inherited from EMF. If a property was a default > value, the property becomes EMF-unsettable, so isSet() will always return > true after set(). The fact that null is not a legal value (since the type > is not nillable) is a validation issue. > > Note that in SDO 2.1, all features will behave this way - even the ones > without default value. There was a clarification in semantics of isSet in > the 2.1 SDO spec, so this EMF-specific behavior will no longer apply. > > Frank > > Ron Gavlin <[EMAIL PROTECTED]> wrote on 03/06/2007 11:13:51 AM: > > > Greetings, > > > > I am using the M2 SDO release. Assume I have registered a schema > > that includes the following snippet: > > > > ... > > <xs:element name="item" maxOccurs="unbounded"> > > <xs:complexType> > > <xs:sequence> > > <xs:element name="title" type="xs:string"/> > > <xs:element name="note" type="xs:string" minOccurs="0"/> > > <xs:element name="quantity" type="xs:nonNegativeInteger" > > minoccurs="0" default="0" /> > > <xs:element name="price" type="xs:decimal"/> > > </xs:sequence> > > </xs:complexType> > > </xs:element> > > ... > > > > It appears the presence of a default attribute on the "quantity" > > element makes the SDO runtime treat quantity as if the element also > > had the attribute, nillable="true". Is this a bug? If so, I'll be > > happy to register a JIRA issue. Let me know. > > > > - Ron > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
