Hi Frank, Here is the link to Ed Merks response to my question on the Eclipse EMF news group: http://www.eclipse.org/newsportal/article.php?id=23403&group=eclipse.tools.emf#23403. I've included the content of his post below:
"Well, it's more of a limitation really. An xsi:nil is typically used by EMF only to serialize explicitly a null value for an unsettable single-valued feature, i.e., it's used to represent a Java null value. None of the EObject lists allow a null object to be contained, so this doesn't work well for multi-valued references. Although many folks think of xsi:nil as the way to serialize a null value, that's not really sufficient for how XML Schema actually defines what it means. What nillable really means is that an element is allowed to have no element content despite the fact that its complex type might well require there to be element content; it can still carry attributes. To represent this properly, you really need to create an actual object, not just have a null value, and that object needs to be able to represent that state of xsi:nil being true. One way to implement that would be for the EObject to have a boolean feature corresponding to the xsi:nil "attribute". The problem with the approach of modeling it as a feature is that the complex type itself gives no indication that it might be used with a nillable element. So another approach is for every EObject to simply have additional state to represent this xsi:nil value in general. But that seems a high price to pay for all users of EMF to address a "corner case" in XML; it has no real meaning for models that just have features and don't specify whether these features are serialized as attributes as opposed to elements. So to be honest, I've quietly been playing ostrich hoping this limitation would stay buried in the sand..." Since EMF is a general-purpose modelling tool, it is easier to sympathize with its inability to handle this XML Schema "corner case". However, since XML Schema is a first-class citizen in the SDO world, I don't think Apache Tuscany SDO can bury this issue. If you agree, I'll go ahead and open a JIRA for this issue. Thanks for your help. - Ron ----- Original Message ---- From: Frank Budinsky <[EMAIL PROTECTED]> To: [email protected] Sent: Wednesday, April 4, 2007 8:21:23 PM Subject: Re: Problem deserializing element with attribute and xsi:nil="true" It sounds like xsi:nil is taking precedence and the attribute is getting lost. It still sounds like a bug. This is the standard EMF loader, so it sounds like it may be an EMF bug. Maybe you could ask the question on the EMF newsgroup and report back your findings? Thanks, Frank. Ron Gavlin <[EMAIL PROTECTED]> wrote on 04/04/2007 06:40:38 PM: > No, get("intRange") returns null and ((IntegerRange) > get("intRange")).get("min") returns an error. > > - Ron > > Frank Budinsky wrote: > > It sounds like a bug. Are you saying that get("intRange") is not null, but > > get("min") on the intRange is 0 (unset)? > > > > Frank > > > > Ron Gavlin <[EMAIL PROTECTED]> wrote on 04/04/2007 05:14:10 PM: > > > > > >> Greetings, > >> > >> I have the following global element in a schema: > >> > >> <xsd:element name="query"> > >> <xsd:complexType> > >> <xsd:sequence> > >> <xsd:element name="intRange" type="IntegerRange" nillable="true/> > >> </xsd:sequence> > >> </xsd:complexType> > >> </xsd:element> > >> > >> <xsd:complexType name="IntegerRange"> > >> <xsd:attribute name="min" type="xsd:integer" /> > >> <xsd:attribute name="max" type="xsd:integer" /> > >> </xsd:complexType> > >> > >> When I use Tuscany SDO to deserialize the instance document below, > >> the intRange min property does not appear to be set. Is this > >> expected behavior or a bug? > >> > >> - Ron > >> > >> <query> > >> <intRange min="1" xsi:nil="true"/> > >> </query> > >> > >> --------------------------------------------------------------------- > >> 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]
