Our current DAS implementation only has support for SDO types, and most of our users, if not all, are SDO users that need support for Relation Database stores. Based on this, I think this discussion should also consider having DAS together with SDO, either in Tuscany or in a different SDO TLP Incubator project.
On Fri, Feb 15, 2008 at 2:39 AM, Mike Edwards <[EMAIL PROTECTED]> wrote: > Folks, > > A few observations inline. > > > Ron Gavlin wrote: > > I think consolidating the two SDO implementations under a single > > implementation would be good for the entire Apache SDO community. My > concern > > would be that no Tuscany SDO features be lost in the transition. The > > new implementation should provide most of what I can currently achieve > > using both EMF and Tuscany SDO. For example, EMF features like integrated > validation should be > > available in the new implementation before the old implementation is > dumped. It might be a good idea to poll the Tuscany SDO community to identify > the EMF features currently being used by Tuscany SDO community. It might also > be interesting to poll the Eclipse EMF SDO 1.0 community and ask the same > question. Maybe many of the existing Tuscany SDO test cases could be > re-written for either 1). the new implementation or 2). the CTS, to minimize > the loss of functionality during the transition. > > There is a fundamental tension here which I think it is important to > recognise. > > On the one hand, we want to ensure a lively and progressive Apache SDO > community that continually extends the capabilities of SDO to better > suit the needs of users. Innovation is a bit part of this story. > > On the other hand, we're trying to promote an open (and open source) > approach to the standardization of the SDO interfaces, to help ensure > consistent implementation of SDO across products both commercial and > open source. There is a JSR and a set of activities taking place in > OASIS for this. Part of that work is to produce an RI and a TCK, open > to all. However, an RI must be just that - an exemplary implementation > of the specification, the whole specification and nothing but the > specification. Similarly, the TCK must be testing compliance of > implementations with the specification, the whole specification and > nothing beyond the specification. This demands limitations on innovation. > > So, there is some careful work required in building both forward-looking > innovative capabilities and at the same time creating somewhat rigid RIs > and TCKs, which are inevitably tied to specific versions of a > specification. I think that the proposal to have a second SDO project > in Apache is regarded as one way to approach these conflicting > requirements. It may not be the only way, but at least it would provide > clear dividing lines that both contributors and users can understand easily. > > It will take some careful thought to combine these aspects within one > project in a way that works for all contributors and for all users. > > One of the reasons that Tuscany is NOT an RI and does NOT contain a TCK > for SCA is because it fosters freedom in the implementation of new > capabilities that go well beyond the current SCA specifications. Some > of these will feed into future "standard specifications", I'm sure. > > > > > >>From my perspective, the priorities for Apache SDO moving forward should > be: > > > > 1. Align Apache SDO with the JAXB specification. > > The static SDO implementation should be JAXB-compliant. > > > > 2. Align Apache SDO with the JPA specification. It should be simple to use > a OpenJPA to persist SDO graphs. > > > > 3. Provide data binding support for popular Java open source WS stacks, > especially Axis2 and CXF. > > > > Yes, all good innovative stuff. > > I could toss in a few more, such as having an SDO implementation for > JavaScript to address AJAX applications. > > But how to square this with the RI and TCK with fixed functions matching > the SDO 2.1 specification? > > > > - Ron > > Yours, Mike. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
