Re: [sdo] Priorities for SDO 3

[Bryan Aupperle <aupperle@us.ibm.com>]

Issue 139 is near the top of my list.
 There are a number of other C++ issues, but the priority of them
priority ties into the .Net question.

Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect

Research Triangle Park,  NC 
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com

Frank Budinsky <frankb@ca.ibm.com>

01/09/2009 12:23 PM

To	sdo@lists.oasis-open.org
cc
Subject	Re: [sdo] Priorities for SDO 3

Hi Guys,

I'm pretty much in agreement with Ron's priorities. 

The only change I would make is that at least some amount of "Organization
of SDO Type System and Helpers" is a "Must Have". I think
SDO 3 should at 
least provide a clean HelperProvider class that implementations don't need
to replace (i.e., the comment in HelperProvider.java: "This class
may be 
replaced by another implementation." is a very ugly approach). I'm
planning to send some ideas on this soon. 

Thanks,
Frank




"Barack, Ron" <ron.barack@sap.com> 
01/09/2009 07:37 AM

To
<sdo@lists.oasis-open.org>
cc

Subject
[sdo] Priorities for SDO 3






Hi Everyone, 
Looking over our the main points in our charter, I would assign the 
priorities as follows 
High Priority: 
Enhancements to Static SDO (especially harmonization with other frameworks
such as JAXB and JPA) 
Improved XML/XSD Support  (our minimum requirement here is to be able
to 
parse and generate any XML document) 
Should Have: 
Organization of SDO Type System and Helpers 
Enhancements to SDO Metadata 
Nice to Have: 
Features related to the Data Access Services (DAS) Specification 
Not Required: 
Notification Support 
Interoperability with .NET 
SDO XML Path Support 
Service Level Programming API 
Already Completed: 
Relaxing containment requirements 
Very Mixed Feelings About: 
API cleanup, especially using Generics in the official APIs.  - Certainly,
the small issues here should be worked on, I'm more concerned about a 
large refactoring of the APIs.  So far, SDO 3 is shaping up to be
backwards compatible with 2.1.  Much as I think having a central class
with 160 methods severely hurts our acceptance, I'm not sure that cleaning
up the API alone is worth breaking backwards compatibility.
Best Regards, 
Ron 


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php