Hi Ron, I agree that SDO can't ignore this, but I think it's bigger than just a Tuscany bug. The spec will need to say how xsi:nil is handled.
Frank. Ron Gavlin <[EMAIL PROTECTED]> wrote on 04/10/2007 12:13:14 PM: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
