Ron, Done. I added it to the SDO specification XML fidelity issues list.
Frank. Ron Gavlin <[EMAIL PROTECTED]> wrote on 04/10/2007 01:44:36 PM: > Hi Frank, > > Agreed. Would you be willing to raise this issue with the spec group > or is there a mechanism you would prefer I use to accomplish the > same? Let me know. > > - Ron > > ----- Original Message ---- > From: Frank Budinsky <[EMAIL PROTECTED]> > To: [email protected] > Sent: Tuesday, April 10, 2007 1:11:17 PM > Subject: Re: Problem deserializing element with attribute and xsi:nil="true" > > > 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] > > --------------------------------------------------------------------- > 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]
