[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sdo] ISSUE 5: Defining SDO types by JAVA types
Hi Ron, Everyone, Are we going to consider this Java specific to the spec at this time and not require compliance of this feature for other languages? I am not sure how feasible this would be to try to translate to other widely used languages that don't support the passing of types or have integral reflection constructs in the language. In C++, there seems like a couple of options to have something equivalent, but I don't know if it would actually fulfill the same use cases or if those use case can be applied effectively in a language such as C++. In any case, I believe there would need to be annotations and the solution would be complex in C++ and would require a complex solution. Especially if this feature is partly in support of the cast type operation to convert any instance of these typed SDOs from an SDO to a POC++O and back. I have wondered if the complexity of this in C++ is even a plausible expectation from SDO. So if we solve this issue, should we determine if the spec only requires this of certain languages or if it should be in the top level specification at all, or maybe even an optional requirement and not necessary to be consider fully SDO 3.x compliant? I agree that the spec may say a compliant implementation would implement these interfaces and adhere to these concepts and use cases... but if the implementation of those concepts would be unrealistic for any modern language should we make it a blanket SDO spec requirement and make it difficult or unrealistic for those modern languages to have fully compliant implementations. I am not saying that the implementation maybe unrealistic of an expectation in C++ and out weigh the worth of supporting the use cases; I honestly don't know if it would be without understanding the issues and implications much better. Can we just make sure until we understand those issues and what it means for other languages that we are careful about putting any concrete core SDO compliance requirements based on the use cases driven from very java "friendly" use cases? Thanks, James -----Original Message----- From: Barack, Ron [mailto:ron.barack@sap.com] Sent: Wednesday, September 10, 2008 2:55 AM To: sdo@lists.oasis-open.org 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:ron.barack@sap.com] Gesendet: Freitag, 1. August 2008 01:14 An: sdo@lists.oasis-open.org 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 <blaise.doughan@oracle.com> To: sdo@lists.oasis-open.org 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]