[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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:marypmcrae@gmail.com] Gesendet: Freitag, 17. Oktober 2008 14:42 An: Barack, Ron; mary.mcrae@oasis-open.org Cc: sdo@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.barack@sap.com] 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:marypmcrae@gmail.com] 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.barack@sap.com] Hi
Mary, There
are 2 packages involved: commonj.sdo and commonj.sdo.helper Thanks, Ron Von: Mary McRae
[mailto:marypmcrae@gmail.com] 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.barack@sap.com] 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, |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]