+1 for option 3 as well.
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:
"Christophe Boutard"
<>
09/17/2008 10:37 AM
To
"Barack, Ron" <>,
<>
cc
Subject
RE: AW: [sdo] ISSUE 5: Defining SDO
types by JAVA types
Hi Ron, all
+1 for Option 3.
But what is the behavior of Type getType(Class)?
Do you want it to create the Type if it does not exist or just return null?
I'm not sure if there's an agreement on this (cf. emails between you and
Frank)
IMO we should keep getType returning null in order to let users ask if
a type is already defined or not.
Thanks,
--CB
-----Original Message-----
From: Barack, Ron [mailto:]
Sent: mercredi 17 septembre 2008 15:49
To: Barack, Ron; Frank Budinsky;
Cc: James Hart
Subject: AW: AW: [sdo] ISSUE 5: Defining SDO types by JAVA types
Hi Everyone,
I took an action item to make a concrete proposal regarding the API. I
think there was general consensus that we want to have at least the functionality
represented by TypeHelper.define(Class). In the call, Blaise brought
up the wish to also have TypeHelper.define(List<Class>). This
second method conflicts with TypeHelper.define(List<DataObject>)
and TypeHelper.define(List<DataObject>) since the generics in the
signature are irrelevant at runtime. There are a few options to consider:
----
Option 1: Name TypeHelper.define differently
This would mean specifying TypeHelper.defineType(Class) and TypeHelper.defineType(List<Class>)
Advantage: Relatively small change to the API.
Disadvantage: Poor seperation of "core" and language specific
SDO. We are adding more Java specific methods to TypeHelper... Do
they really belong there?
----
Option 2: Leave TypeHelper.define(List) without any generic parameters.
We could leave the API definition like it is, and just change the description,
allowing either type of list, or mixed lists.
Advantage: Even smaller change to the API.
Disadvantage: Losing type safety. General messiness.
Poor seperation of "core"
and language specific SDO. We are adding more Java specific methods
to TypeHelper... Do they really belong there?
----
Option 3: Move the functionality to JavaHelper
This would mean deprecating TypeHelper.define(Class) as well as DataFactory.create(Class).
We would then have to add a new method on HelperProvider and HelperContext
and define the new API like
interface JavaHelper {
Type
define(Class);
List<Type>
define(List<Class>);
Type
getType(Class);
<T>
T create(Class<T>);
}
Advantage: Clean separation of "core" from language
specific SDO.
Provides a place to add
new functionality, eg. createBinder()
Disadvantage: Larger change to the API (but still backwards compatible).
--------
Perhaps because I'm looking forward to adding the binder/ projector functionality,
my preference would be for option 3.
Best Regards,
Ron
-----Ursprüngliche Nachricht-----
Von: Barack, Ron [mailto:]
Gesendet: Mittwoch, 10. September 2008 23:30
An: Frank Budinsky;
Betreff: AW: AW: [sdo] ISSUE 5: Defining SDO types by JAVA types
Hi Frank,
Well, the spec says "null if not found", so I guess it all comes
down to how hard an implementation looks ;-) I alway interpreted
"found" to mean that the implementation is capable in finding
and generating SDO metadata based on reflection of the class parameter.
Even if you consider it a breaking change, I doubt any of our customers
are currently relying on the value null being returned, e.g., I doubt any
code will break if we add intelligence to the getter.
It's not the consistency with the other getType that bothers me with implicitly
definiting types, it's simply that I don't think the average user expects
a "getter" to do anything, only to retrieve values from some
kind of store. So the "principle of least surprise" would
argue for the behavior you suggest.
On the otherhand, all we are really talking about here is lazy initialization
of the type, which is not that uncommon for getter. And the effect
of your API is that we are going to force the user into constucts like
Type fooType = typeHelper.getType(Foo.class);
if (fooType == null) {
fooType = typeHelper.defineType(Foo.class);
}
everytime he want to get a type. The same is construct will have
to be used of DataFactory.create(Class), which is defined as relying
on TypeHelper.getType(). And this is probably the standard way of
creating static SDOs, right?
Doing this every time you want to create a static SDO is a chore. What's
the point of placing this extra burdon on the user? Why not add the
intelligence to the implementation, and save the users the "if".
This last point (IMO) trumps the "principle of least surprise".
It's something for which it's hard to think of a compromise. I guess
we'll just have to settle this one with a vote.
Ron
________________________________
Von: Frank Budinsky [mailto:]
Gesendet: Mi 10.09.2008 21:01
An:
Betreff: Re: AW: [sdo] ISSUE 5: Defining SDO types by JAVA types
Hi Ron,
After giving it some thought, I think that TypeHelper.getType(Class)
should not implicitly define types. We should instead add one or more
define methods that take classes as input.
The problems with TypeHelper.getType(Class) defining types are:
1) it would be a breaking change (currently the spec says it returns null
if the type is not found).
2) it would be inconsistent with the way TypeHelper.getType(uri, name)
works. I would think it would be odd to see this kind of behavior:
type = typeHelper.getType("someURI", "Person"); //
return null
type = typeHelper.getType(Person.class); // return non null
type = typeHelper.getType("someURI", "Person"); //
return non null
If we did this, I think we might also want getType(String, String) to do
implicit type definition (for example, check on the class path if there
is
a Class that, if defined, would have the correct name and URI. We could
consider this .... but personally, I think it's better to just keep
getType() as a read-only API with no side-effects.
As far as what kinds of annotations we might want to support, I think that
we could maybe handle it like bindings ... e.g., have various define
methods like: JAXBBindingHelper.defineType(Class),
JPABindingHelper.defineType(Class), etc. Each knows about binding-specific
annotations, and knows how to produce SDO metadata from them. Anyway, just
a thought.
Frank
"Barack, Ron" <>
09/10/2008 04:55 AM
To
<>
cc
Subject
AW: [sdo] ISSUE 5: Defining SDO types by JAVA types
Hi Everyone,
During the call on Sept. 2, we decided it would be best to limit the scope
of ISSUE 5 to the API question below, that is, the question of whether
"TypeHelper.getType(Class)" can implicitly use introspection
to define
types, or whether we need an explicit "TypeHelper.defineType(Class)".
Resolving ISSUE 5 along the lines of either proposal at least signifies
that Java classes are legitimate sources of metadata, that it is possible
to round-trip between static SDOs and SDO Types.
The actual annotations (or side files) used to derive the metadata (or
to
augment the metadata that is already available through reflection) can
then be discussed in a seperate issue, which we can open as a part of the
resolution of this ISSUE 5.
The interesting discussion here is to which extent can we use already
existing standards, JPA and JAXB, as annotations.
Ron
-----Ursprüngliche Nachricht-----
Von: Barack, Ron [mailto:]
Gesendet: Freitag, 1. August 2008 01:14
An:
Betreff: Re: [sdo] ISSUE 5: Defining SDO types by JAVA types
Hi Blaise,
I can only say I had option 1 in mind. The only item from option
2 I
think would be really nice to have is support for Qname for the URI
types...it's just that the string format defined by SDO requires that
clients write their own parsers, and anyway, the only reason we don't
support Qname for type anyway is that SDO is older than Java 1.4, where
Qname became part of the JDK. The different calandar classes would
be
worth supporting, too.
Annotations are something I wish we could live without, or rather, I
wish we could use JAXB's (or someone elses) annotations. Unfortunately,
the match really isn't very good: JAXB is very efficient in that
it
captures enough information in the annotations so that the XML can be
produced (note, there is no round tripping of the XSD), but we want to
capture the SDO metadata, we want to round trip SDO -> Static SDO ->
SDO...I see the Java interface as a valid alternative to XSD for storing
(non-XML oriented) metadata. On the other hand, JAXB has use cases
that
are really complex, complete support of JAXB annotations is really a
daunting task. Bottom line, I think we do need to define our own
interfaces. I put forward a proposal for the annotations some time
ago,
basically it documents how our implementation already works. You
can
find it here:
http://www.oasis-open.org/apps/org/workgroup/sdo/download.php/26370/sd03
0_annotations.doc
I'm pretty curious what others think about the idea of defining our own
annotations.
Best Regards,
Ron
Subject: Re: [sdo] ISSUE 5: Defining SDO types by JAVA types
From: Blaise Doughan <>
To:
Date: Tue, 29 Jul 2008 11:41:49 -0400
------------------------------------------------------------------------
--------
Title: ISSUE 5: Defining SDO types by JAVA types
What is the intended scope for this issue?:
Option #1: Define Types from SDO Compatible Interfaces
For me the minimum bar for this feature is to ensure that interfaces
that can be generated from an XML schema can themselves be the source of
the SDO metadata. Presumably we would also require that all generated
interfaces contain the necessary annotations (just as JAXB 2.X does with
its generated classes).
Option #2: Define Types from Any Interface
Similar to option #1, but a heck of a lot more work. We would need
to
devise ways of handling all possible Java types including:
javax.xml.namespace.QName
org.w3c.dom.Element
java.util.Calendar
javax.xml.datatype.XMLGregorianCalendar
java.util.Map
org.mydomain.foo.Employee (a POJO not an interface)
Option #3: Somewhere between Option #1 and Option #2
Somewhere between option #1 & option #2, although we should decide
where
the line will be drawn.
-Blaise
Barack, Ron wrote:
Hi Everyone,
The current discussion of containment is in large part motivated by the
wish to use other sources of metadata as a standard way to define types.
Although we at SAP have always interpreted the spec as at least allowing
this, we're probably alone in that interpretation. The spec is at
best
very unclear about how this should be done.
One possibility is to interpret TypeHelper.getType(Class) as performing
introspection of the class, and returning a type based on this
introspection. In order to standardize this behavior, all we'd need
to
do is change the second bullet point in 4.8.2 from
getType(Class interfaceClass) returns the Type for this interfaceClass
or null if not found.
To something like
getType(Class interfaceClass) returns the Type for this interfaceClass.
If the interfaceClass is not already associated with a Type, the class
will be introspected according to the algorithm in Chapter 6,
recursively creating Types as needed for all classes directly or
indirectly referenced by interfaceClass.
This is probably fairly surprising behavior. From the usability
standpoint, most people don't expect a getter to do anything other than
look up a value. On the other hand, this is really nothing more than
a
form of lazy initialization. The ClassLoader associated with the
helper
context is implicitly loaded when the helper context is created.
If we want to define a new method, then need to do a little more work,
and define a method like
defineType(Class interfaceClass) returns the Type for this
interfaceClass. If the interfaceClass is not already associated with
a
Type, the class will be introspected according to the algorithm in
Chapter 6, recursively creating Types as needed for all classes directly
or indirectly referenced by interfaceClass.
Note that neither proposal requires us to solve the knottier issue of
how the class is introspected, and converted to a SDO type. This
is
just putting another stake in the ground, saying that Java classes can
be introspected, can be sources of metadata, and that this is the API
for doing it.
Best Regards,
Ron
sd
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
