On Feb 15, 2008 10: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? >
Its also important to recognize that Apache is about community and projects need a scope that is broad enough to foster a community. To maintain an active community there needs to be something to keep developers participating after the 2.1.1 RI is done, otherwise why even do this at Apache? If a goal is to continually extend the capabilities of SDO and to feed innovation into future versions of specifications then thats going to work better if there is a single SDO community not communities split between separate Apache projects. Other Apache projects have managed to produce RIs without splitting the work out into a seperate project so i'm sure the same could be done here - separate builds or SVN branches or sub projects under the one SDO TLP. ...ant
