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]
