| From | Sent On | Attachments |
|---|---|---|
| Barack, Ron | Oct 16, 2008 9:10 am | |
| Mary McRae | Oct 16, 2008 9:33 am | |
| Barack, Ron | Oct 16, 2008 9:38 am | |
| Mary McRae | Oct 16, 2008 9:50 am | |
| Barack, Ron | Oct 17, 2008 12:12 am | |
| Mary McRae | Oct 17, 2008 5:38 am | |
| Barack, Ron | Oct 17, 2008 7:10 am | |
| Mary McRae | Oct 17, 2008 7:17 am |
| Subject: | RE: [sdo] AW: Package names for SDO Java Specification | |
|---|---|---|
| From: | Mary McRae (mary...@gmail.com) | |
| Date: | Oct 17, 2008 7:17:03 am | |
| List: | org.oasis-open.lists.sdo | |
Title: Package names for SDO Java Specification
Thank you Ron, for your patience, and for that explanation! In that case, I have no problem with the TC continuing to use commonj; the concern was that the work was being identified as that of another organization (OSOA) rather than OASIS. Obviously any copyright or ownership information comments should identify OASIS and the TC.
Regards,
Mary
From: Barack, Ron [mailto:ron....@sap.com] Sent: Friday, October 17, 2008 10:07 AM To: mary...@oasis-open.org Cc: sd...@lists.oasis-open.org Subject: [sdo] AW: Package names for SDO Java Specification
Hi Mary,
It's a common practice to begin package names with something identifying the organization. Eg, at SAP, most code begins with "com.sap". There's nothing that requires this, it's just a convention, motivated by the wish avoid conflicts (like XML namespaces).
If we were designing SDO from scratch, we'd certainly use the "org.oasisopen" prefix. The problem is, most of the member companies already have implementations of SDO, and these implementations offer interfaces that have the "commonj.sdo" prefix. What is worse, these implementations have built up substancial user communities. If we chnage the package prefix, then we cannot make SDO 3.0 compatible with SDO 2.1, any chance of providing users with a smooth transition is lost. And that will have a negative influence on the acceptance of the spec. If it had only to do with the implementation itself or internal users, then I guess that most companies would simply accept the costs and upgrade, but we don't want to endanger the acceptance of our spec unneccessarily.
SDO is actually old that the OSOA collaberation. When it moved to OSOA, it kept the commonj prefix because of the same considerations that motivate us now.
I've tried to find out who "owns" the commonj namespace. I believe that no one does. Rather, it is simply a convention used by IBM and BEA (when they existed) specifically for use in "common" standards. We would like to continue to use this convention for our work under the OASIS banner.
Ron
------------------------------------------------------------------------------
Von: Mary McRae [mailto:mary...@gmail.com] Gesendet: Freitag, 17. Oktober 2008 14:42 An: Barack, Ron; mary...@oasis-open.org Cc: sd...@lists.oasis-open.org Betreff: RE: Package names for SDO Java Specification
Hi Barack,
Actually, it's supposed to be org.oasisopen. We are requiring that instead of org.osoa. It's my understanding (and I am not a programmer so excuse my poor explanation) that a prefix identifying the organization must be used. What organization is commonj.sdo associated with? I was guessing that this was the next layer following org.osoa ...
Mary
From: Barack, Ron [mailto:ron....@sap.com] Sent: Friday, October 17, 2008 3:17 AM To: mary...@oasis-open.org Cc: sd...@lists.oasis-open.org Subject: AW: Package names for SDO Java Specification
Hi Mary,
I had the impression that OASIS was requiring the "org.oasisj" package prefix be used in all interfaces defined by an OASIS TC. If there is no such requirement, then I guess there is no problem.
Can I report back to the TC that OASIS has no objection to us continuring to use the "commonj.sdo" namespace?
Ron
------------------------------------------------------------------------------
Von: Mary McRae [mailto:mary...@gmail.com] Gesendet: Donnerstag, 16. Oktober 2008 18:54 An: Barack, Ron; mary...@oasis-open.org Cc: sd...@lists.oasis-open.org Betreff: RE: Package names for SDO Java Specification
Hi Ron,
The question from the SCA/J TC was about use of org.osoa in the package name ... I'm not sure what the problem would be with the "common.sdo" part but I'll need more clarification from you.
Mary
From: Barack, Ron [mailto:ron....@sap.com] Sent: Thursday, October 16, 2008 12:42 PM To: mary...@oasis-open.org Cc: sd...@lists.oasis-open.org Subject: AW: Package names for SDO Java Specification
Hi Mary,
There are 2 packages involved:
commonj.sdo
and
commonj.sdo.helper
Thanks,
Ron
------------------------------------------------------------------------------
Von: Mary McRae [mailto:mary...@gmail.com] Gesendet: Donnerstag, 16. Oktober 2008 18:38 An: Barack, Ron; 'Mary McRae' Cc: sd...@lists.oasis-open.org Betreff: RE: Package names for SDO Java Specification
Hi Ron,
Can you be more explicit as to the package names you'd like approved? I'm guessing you're referring to the prefix information ...
Thanks,
Mary
From: Barack, Ron [mailto:ron....@sap.com] Sent: Thursday, October 16, 2008 12:06 PM To: Mary McRae; Mary McRae Cc: sd...@lists.oasis-open.org Subject: Package names for SDO Java Specification
Hi Mary,
The SDO TC has expressed the desire to continue to use the "commonj.sdo" package names for all interfaces defined by the SDO/J specification.
We are aware that a similar request has come from the SCA/J TC, and the request was finally rejected. However, one of the rationals for this decision was that SCA does not have an existing user base. This is not the case for SDO. Serveral companies have existing products that use the "commonj.sdo" package. These products have a wide customer base. We expect a push back from our users if we now require repackaging. The will be a significant blow to the acceptance of SDO 3, of the entire SDO TC effort. Because of this, we would like to request that we be allowed to use the "commonj.sdo" package.
Of course, this does not affect the namespaces used in any XML and XSDs that we define. For XML, we will continue to use the OASIS standard namespaces.
Thank you for your consideration, Ron





