SDO is just a part of the release schedule for the whole of Tuscany, The 
next Tuscany release is planned for around the end of the month. I think 
the goal is to have Tuscany releases every few months anyway.

Frank.

Ron Gavlin <[EMAIL PROTECTED]> wrote on 07/10/2006 11:00:56 PM:

> Frank,
> 
> Thanks for the detailed explanation. I'll keep an eye out for progress 
> on the ChangeSummaryType property support.
> 
> BTW, do you have any plans to distribute Tuscany SDO releases more 
> frequently? It would be nice to get incremental releases with new 
> features/bug fixes every couple months.
> 
> Thanks again,
> 
> - Ron
> 
> Frank Budinsky wrote:
> > Ron,
> >
> > This is an area of the spec that is full of holes. The bottom line is 
that 
> > in SDO 2.0.1 the Java interface commonj.sdo.DataGraph has no defined 
> > relationship to the DataObject that would be created from the 
complexType 
> > BaseDataGraphType, other than the one vaguely implied by this example. 

> > DataGraphs are not DataObjects in the current spec, Tuscany, or any 
other 
> > implementation of SDO that I'm aware of. The SDO collaboration group 
has 
> > been discussing changing this in SDO 2.1. The general feeling is that 
it 
> > would be good to make DataGraphs proper DataObjects (it would solve a 
lot 
> > of the other questions like how do you create a DataGraph), but we 
need to 
> > define the behavior of DataGraph/DataObject methods like getDataGraph, 

> > getChangeSummary, and getRootObject, some of which are duplicates 
> > (declared in both interfaces), and all of which have ambiguous 
behavior in 
> > the combined DataGraph/DataObject case.
> >
> > As far as Tuscany is concerned, a prereq is to get ChangeSummaryType 
> > properties to work - which we've started working on, but still need a 
few 
> > weeks. Once we have that working, we can start implementing DataGraph 
as a 
> > proper DataObject (ahead of the 2.1 spec). After that, I think you 
could 
> > do what your asking for.
> >
> > Short term, I think you're out of luck.
> >
> > Frank.
> >
> > Ron Gavlin <[EMAIL PROTECTED]> wrote on 07/10/2006 04:20:32 PM:
> >
> > 
> >> I am attempting to use Tuscany SDO to pass a DataGraph as a 
> >> parameter to a document-wrapped web service method, similar to the 
> >> "Web services and DataGraphs Example" on pages 137-139 in the SDO 2.
> >> 01 specification. In my case, however, I am attempting to wrap the 
> >> DataGraph within a statically-generated DataObject that represents 
> >> the method being invoked. The relevant portions of the schema are as 
> >> 
> > follows:
> > 
> >> <!-- from the spec -->
> >> <element name="companyDataGraph" type="company:CompanyDataGraphType" 
/>
> >> <complexType name="CompanyDataGraphType">
> >> <complexContent>
> >> <extension base="sdo:BaseDataGraphType">
> >> <sequence>
> >> <element name="company" type="company:CompanyType" />
> >> </sequence>
> >> </extension>
> >> </complexContent>
> >> </complexType>
> >>
> >> <!-- my addition -->
> >> <xsd:element name="updateCompanies" type="UpdateCompanies" />
> >> <xsd:complexType name="UpdateCompanies">
> >> <xsd:sequence>
> >> <xsd:element ref="companyDatagraph" />
> >> </xsd:sequence>
> >> </xsd:complexType>
> >>
> >> Should a full SDO 2.01 implementation support this use case? If so, 
> >> how close is Tuscany to being able to support it? In particular, 
> >> when I run Tuscany XSD2JavaGenerator, the class generated for 
> >> CompanyDataGraphType extends DataObjectImpl and not DataGraphImpl. 
> >> Is fixing this simply a matter of enhancing the XSD2JavaGenerator to
> >> recognize "sdo:BaseDataGraphType" extensions and make these classes 
> >> extend DataGraphImpl instead of DataObjectImpl? Is serializing/de-
> >> serializing a DataGraph as a child of a DataObject doable?
> >>
> >> - 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]

Reply via email to