Frank, maybe solution for the representation of composition (containment) in XSD and SDO is not so simple. Recall that one class in UML class diagram can be part of many compositions but instance of that class, in the run-time, can be part of only one whole/assembly object (well known example with class Point that can be part in run-time of either Polygon or Circle but not both in the same time).
So this would not be solution for this design problem: <xsd:element name="points" type="impl:Point" sdojava:getContainer="getCircle" minOccurs="0" maxOccurs="unbounded" /> because we do not know what is class of point's container in advance. ((DataObject)point.getContainer() should return object either of Circle or Polygon type and one of static API methods point.getCyrcle() or point.GetPolygon() will return null and other method will return something. I am developing DAS for JPA (EJB 3.0) where DAS accepts set of EJB-QL queries and returns SDO DataGraph (also applyChanges in opposite direction) and developing that graph-to-graph transformation of POJOs graph (not tree) to SDO graph (should be graph not tree) I saw couple of missing peaces in SDO specification and technology and I will try to compile that and come back as soon as I can. Regards, Miro. Miro Kandic (408)525-2596 -----Original Message----- From: Frank Budinsky [mailto:[EMAIL PROTECTED] Sent: Mon 9/17/2007 11:01 AM To: tuscany-user@ws.apache.org Subject: RE: XSD2JavaGenerator and non-containment references Miro, You are right. Bidirectional references are broken in Tuscany. They seem to have been broken when we switched over to the new (noEMF) codegen patterns. I guess nobody uses them much and we don't have a test case. Can you please open a JIRA bug report to track this? I understand your point about wanting a static (non SDO dependent) way to navigate to the container. I think this is something that we should try to change in the next version of SDO. Maybe something like this: <xsd:element name="lines" type="impl:SoL" sdojava:getContainer="getOrder" minOccurs="0" maxOccurs="unbounded" /> Maybe for now in Tuscany, we could just always generate a static method for getContainer equal to "get" + <container type name>. For example, we would generate: SoH getSoH() { return (SoH)getContainer(); } in class SoLImpl. This wouldn't be standard SDO, but a generator is allowed to generate additional implementation-specific methods and still be considered compliant. Frank "Miro Kandic \(mkandic\)" <[EMAIL PROTECTED]> wrote on 09/17/2007 01:09:38 PM: > Frank, > > actually XSD2JavaGenerator does not work in the case of any > association type that is navigable from both sides. > I have intentionally, just to test generator, made Customer-SoH > association navigable from both sides and generated code again > cannot be compiled. > > Regarding your comments on bidirectional references and > containments, I know I can get container using dynamic SDO API but I > don't want to see in a code that implements business logic any code > that is related to protocols or data implementation technologies. > Packing data to SOAP envelop or sendig data over IIOP is job of > stubs and scaletons and main stream priogrammer should not ever cast > object to classes related to those techologies. Based on the same > principales, business programmer should not be avere that object > he/she is dealing with is actually instance of some Hybernate proxy > or SDO DataObject and should not ever cast those objects to > mentioned classes unless he/she develops some tools or similar > generic software. > And I do not want to use any dynamic API if I don't have to, so I > prefer to have typed Java API and SDO specification explicitally > lists that support as one of the major requirements. So SDO should > support static API defined by XSD schema. > I think Java business programmer should be familiar with UML class > diagrams that define domain and should get only corresponding POJOs > to deal with. Code dealing with data transport or object > distribution or data persistance, where BTW one technology is "cool" > today and next day another one, should be hidden in adapters, > skeletons and stubs. > > Next is complete XSD built automatically from attached UML. > > <?xml version="1.0" encoding="UTF-8"?> > <!-- > Attention: Generated code! Do not modify by hand! > Generated by: XmlSchema.vsl in andromda-xmlschema-cartridge. > --> > <xsd:schema > targetNamespace="http://www.cisco.com/odns/soa"; > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > xmlns:sdo="commonj.sdo" xmlns:sdoxml="commonj.sdo/xml" > xmlns:impl="http://www.cisco.com/odns/soa"; > elementFormDefault="qualified"> > > <xsd:import namespace="commonj.sdo/xml" schemaLocation="sdoXML.xsd"/> > > <xsd:complexType name="Address"> > <xsd:sequence> > <xsd:element name="street" type="xsd:string" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="city" type="xsd:string" minOccurs="1" > maxOccurs="1"/> > </xsd:sequence> > <xsd:attribute name="xmlId" type="xsd:ID"/> > </xsd:complexType> > > <xsd:complexType name="Customer"> > <xsd:sequence> > <xsd:element name="orders" type="xsd:IDREF" sdoxml: > propertyType="impl:SoH" > sdoxml:oppositeProperty="customer" minOccurs="0" > maxOccurs="unbounded" /> > <xsd:element name="name" type="xsd:string" minOccurs="1" > maxOccurs="1"/> > <xsd:element name="created" type="xsd:date" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="lastUpdated" type="xsd:dateTime" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="modifiedBy" type="xsd:string" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="id" type="xsd:long" minOccurs="1" > maxOccurs="1"/> > </xsd:sequence> > <xsd:attribute name="xmlId" type="xsd:ID"/> > </xsd:complexType> > > <xsd:complexType name="Part"> > <xsd:sequence> > <xsd:element name="uom" type="xsd:string" minOccurs="1" > maxOccurs="1"/> > <xsd:element name="aggState" type="xsd:string" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="id" type="xsd:long" minOccurs="1" > maxOccurs="1"/> > </xsd:sequence> > <xsd:attribute name="xmlId" type="xsd:ID"/> > </xsd:complexType> > > <xsd:complexType name="Product"> > <xsd:complexContent> > <xsd:extension base="impl:Part"> > <xsd:sequence> > <xsd:element name="description" type="xsd:string" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="modifiedBy" type="xsd:string" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="lastUpdated" type="xsd:dateTime" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="created" type="xsd:date" > minOccurs="1" maxOccurs="1"/> > </xsd:sequence> > </xsd:extension> > </xsd:complexContent> > </xsd:complexType> > > <xsd:complexType name="SoH"> > <xsd:sequence> > <xsd:element name="customer" type="xsd:IDREF" sdoxml: > propertyType="impl:Customer" > sdoxml:oppositeProperty="orders" minOccurs="1" > maxOccurs="1" /> > <xsd:element name="lines" type="impl:SoL" minOccurs="0" > maxOccurs="unbounded" /> > <xsd:element name="number" type="xsd:string" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="receivedDate" type="xsd:date" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="modifiedBy" type="xsd:string" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="lastUpdated" type="xsd:dateTime" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="created" type="xsd:date" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="id" type="xsd:long" minOccurs="1" > maxOccurs="1"/> > </xsd:sequence> > <xsd:attribute name="xmlId" type="xsd:ID"/> > </xsd:complexType> > > <xsd:complexType name="SoL"> > <xsd:sequence> > <xsd:element name="product" type="xsd:IDREF" sdoxml: > propertyType="impl:Product" > sdoxml:oppositeProperty="soLs" minOccurs="1" maxOccurs="1" /> > <xsd:element name="soLineSch" type="impl:SoLSch" > minOccurs="0" maxOccurs="unbounded" /> > <xsd:element name="quantity" type="xsd:double" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="requestedDate" type="xsd:date" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="modifiedBy" type="xsd:string" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="lastUpdated" type="xsd:dateTime" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="created" type="xsd:date" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="id" type="xsd:long" minOccurs="1" > maxOccurs="1"/> > </xsd:sequence> > <xsd:attribute name="xmlId" type="xsd:ID"/> > </xsd:complexType> > > <xsd:complexType name="SoLSch"> > <xsd:sequence> > <xsd:element name="requestedDate" type="xsd:date" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="quantity" type="xsd:double" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="modifiedBy" type="xsd:string" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="lastUpdated" type="xsd:dateTime" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="created" type="xsd:date" > minOccurs="1" maxOccurs="1"/> > <xsd:element name="id" type="xsd:long" minOccurs="1" > maxOccurs="1"/> > </xsd:sequence> > <xsd:attribute name="xmlId" type="xsd:ID"/> > </xsd:complexType> > > <xsd:element name="DataGraphRootEl" type="impl:DataGraphRoot"/> > <xsd:complexType name="DataGraphRoot"> > <xsd:sequence> > <xsd:element name="customer" type="impl:Customer" > minOccurs="0" maxOccurs="unbounded" /> > <xsd:element name="product" type="impl:Product" > minOccurs="0" maxOccurs="unbounded" /> > <xsd:element name="part" type="impl:Part" minOccurs="0" > maxOccurs="unbounded" /> > <xsd:element name="soH" type="impl:SoH" minOccurs="0" > maxOccurs="unbounded" /> > </xsd:sequence> > </xsd:complexType> > > </xsd:schema> > > > > Miro > > > > > -----Original Message----- > From: Frank Budinsky [mailto:[EMAIL PROTECTED] > Sent: Mon 9/17/2007 7:49 AM > To: tuscany-user@ws.apache.org > Subject: Re: XSD2JavaGenerator and non-containment references > > Miro, > > Both sides of a relationship defined with sdoXML:oppositeProperty need to > be non-containment references. All containment references are implicitly > bidirectional (the reverse is the elements container), so you wouldn't > really want to use an IDREF element anyway - it's just duplicate > information. > > To get the SoH from an SoL, you can call: > > SoH soh = (SoH)sol.getContainer(); > > You could manually add a getOrder() (convenience) method in the generated > class like this: > > SoH getOrder() { return (SoH)getContainer(): } > > EMF has a way to generate this kind of method for you, but there's no > support for this in SDO. > > Frank. > > "Miro Kandic \(mkandic\)" <[EMAIL PROTECTED]> wrote on 09/14/2007 08:40:40 > PM: > > > I am having a problem with new XSD2JavaGenerator (M2 was OK) and it > > generates code that cannot be compiled in case when container > > element has non-containment reference to the container. > > Entire xsd file is attched. > > In this case I want to use static API and I want to get sales order > > header (SoH) from its lines (SoL) using the same Java code (getter) > > as in case when I use corresponding POJO's. > > It works fine if property is non-containment reference to no > > container class (SoL references product or SoH references Customer). > > > > I am a new in this community and I do not know if this is considered > > as a bug who and how should open it. Please, advise. > > > > <xsd:complexType name="SoH"> > > <xsd:sequence> > > <xsd:element name="customer" type="xsd:IDREF" sdoxml: > > propertyType="impl:Customer" sdoxml:oppositeProperty="soHs" > > minOccurs="1" maxOccurs="1" /> > > <xsd:element name="lines" type="impl:SoL" minOccurs="0" > > maxOccurs="unbounded" /> > > <xsd:element name="number" type="xsd:string" > > minOccurs="1" maxOccurs="1"/> > > <xsd:element name="receivedDate" type="xsd:date" > > minOccurs="1" maxOccurs="1"/> > > <xsd:element name="modifiedBy" type="xsd:string" > > minOccurs="1" maxOccurs="1"/> > > <xsd:element name="lastUpdated" type="xsd:dateTime" > > minOccurs="1" maxOccurs="1"/> > > <xsd:element name="created" type="xsd:date" > > minOccurs="1" maxOccurs="1"/> > > <xsd:element name="id" type="xsd:long" minOccurs="1" > > maxOccurs="1"/> > > </xsd:sequence> > > <xsd:attribute name="xmlId" type="xsd:ID"/> > > </xsd:complexType> > > > > <xsd:complexType name="SoL"> > > <xsd:sequence> > > <xsd:element name="order" type="xsd:IDREF" sdoxml: > > propertyType="impl:SoH" sdoxml:oppositeProperty="lines" > > minOccurs="1" maxOccurs="1" /> > > <xsd:element name="product" type="xsd:IDREF" sdoxml: > > propertyType="impl:Product" sdoxml:oppositeProperty="soLs" > > minOccurs="1" maxOccurs="1" /> > > <xsd:element name="soLineSch" type="impl:SoLSch" > > minOccurs="0" maxOccurs="unbounded" /> > > <xsd:element name="quantity" type="xsd:double" > > minOccurs="1" maxOccurs="1"/> > > <xsd:element name="requestedDate" type="xsd:date" > > minOccurs="1" maxOccurs="1"/> > > <xsd:element name="modifiedBy" type="xsd:string" > > minOccurs="1" maxOccurs="1"/> > > <xsd:element name="lastUpdated" type="xsd:dateTime" > > minOccurs="1" maxOccurs="1"/> > > <xsd:element name="created" type="xsd:date" > > minOccurs="1" maxOccurs="1"/> > > <xsd:element name="id" type="xsd:long" minOccurs="1" > > maxOccurs="1"/> > > </xsd:sequence> > > <xsd:attribute name="xmlId" type="xsd:ID"/> > > </xsd:complexType> > > > > Regards, > > Miro > > > > > > --------------------------------------------------------------------- > > 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]
