[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: AW: [sdo] Proposal for Static SDOs
Hi Blaise,
From Section
1.3
I agree, interfaces are the standard java construct
for static SDOs, and I think any clients that care about portability have to use
them only. The mapping from SDO non-datatype Type to interface is
established at least since SDO 2, and I did not intentionally weaken this.
In this paragraph, I wanted to say that we are not standardizing that java
interfaces/DynamicProxy always be used, eg, clients should not rely on there
being a client proxy implemention. This allows implementation to chose
other means of implementing the interface (eg, a generated implementation
class), and opens the doors to other types of static SDOs, eg, POJOs or the
generated class itself.
Section 1.7.4 -
@SdoProperty
My intention was
that @SdoProperty would only be necessary if the default mapping needed to be
modified (eg, to set the containment behavior). We want unannotated
interface to be usable, after all. On the other hand, I think
@SdoTransient would only make sense if we were dealing with an annotated (POJO)
class. On a Java interface (that is being implemented using a
DynamicProxy, say), it wouldn't make any sense. And since interfaces are
our only standard for static SDOs, having something like @SdoTransient seems
like something that should be left to be a vendor extension. On the other
hand, if we standardize bytecode weaving as something that must be
supported, then you are right, we need @SdoTransient.
Section 1.7.6 -
@SdoFacets
Using JSR-303 is
a great idea, and I will try to update the proposal accordingly. I cases
where the JSR does not provide an annotation that maps 100% to an
XSD restriction, how do you see proceeding? Should we define our own
annotatins, eg, commonj.sdo.validation.Pattern,
commonj.sdo.validation.MinExclusive? What about annotations by the JST
that do not match XSD restrictions, like @NotNull.
Really, the
fundamental problem here is that we don't have any standard SDO model
for restrictions/facets. I our implementation we have a bunch of open
content properties used for this purpose. Do you agree we should
standardize this?
Best
Regards,
Ron
Von: Blaise Doughan
[mailto:blaise.doughan@oracle.com]
Hi Ron,Gesendet: Freitag, 13. Februar 2009 21:16 An: Barack, Ron Cc: sdo@lists.oasis-open.org Betreff: Re: AW: [sdo] Proposal for Static SDOs Below are some initial comments, more to follow. From Section 1.3 "The implementation of the returned
DataObject MAY be a dynamic proxy, the result of byte code enhancement or
weaving of a POJO JavaBean or a class that was generated during the
application’s build process." Section 1.7.3 - @SchemaInfo Still working on comments for this one. Section 1.7.4 - @SdoProperty Does an accessor need an @SdoProperty annotation to be included as a property? If not can we provide an annotation like @SdoTransient to prevent some accessors from being converted to properties? Section 1.7.6 - @SdoFacets Do we need to define our own annotations or can we leverage JSR-303 Bean Validation? -Blaise Barack, Ron wrote: 7C3EF93EEBC6EB4A8B4470853DE865666C77F9@dewdfe18.wdf.sap.corp type="cite">Hi Frank, Thanks for bringing this up, since I somehow left it up of my "main points" presentation. There may need to be wording changes in the proposal, but my intention was: SDO URI -> Java Package: Use JAX-B name-mangling. Java Package -> SDO URI: uri = package.getName(). The disadvantage of the first rule is that when generating POJOs using JAXB and static SDOs from the same XSD, the default behavior will be to overwrite the classes. On the other hand, it save us from having to come up with a new algorithm. I looked through the JAXB spec and I didn't find any behavior at all for describing the other direction. I don't like the idea of using the "" namespace. An important use case for us is going from unannotated classes to a reasonable SDO model. Using the "" package would mean that the class names have to be unique (over all packages), which I think is an unreasonable restriction. The problem with the rule in my proposal is that the URI is not a legal URI in XML. This didn't really bother me, since it's still a legal SDO URI. The WebBeans approach sounds like a reasonable improvement on the proposal I sent out. Ron -----Ursprüngliche Nachricht----- Von: Frank Budinsky [mailto:frankb@ca.ibm.com] Gesendet: Dienstag, 10. Februar 2009 21:02 An: sdo@lists.oasis-open.org Betreff: Re: [sdo] Proposal for Static SDOs Hi Ron, Regarding the package name to/from URI mapping, your document says they're the same value, but that won't work. For example: "http://a/b/c" is not a valid package name. I thought we were thinking about using the JAX-B mapping rule for URI -> package name. In the other direction (package name -> URI) JAX-B just uses "" for the URI by default (if there is no annotation). Is that what we want to do as well? I heard that the WebBeans spec is proposing a Java to XML namespace mapping of the following form: " urn:java:<package qualified Java Class>". Seems kind of strange, but maybe it's a good idea to make SDO3 and WebBeans behave in the same way. Frank "Barack, Ron" <ron.barack@sap.com> 02/09/2009 06:52 AM To <sdo@lists.oasis-open.org> cc Subject [sdo] Proposal for Static SDOs <<Proposal for Static SDOs.doc>> <<Static SDO.ppt>> Hi Everyone, Here is the proposed wording for Chapter 3 of the Java Spec, and a PPT describing what I think are the highlights and main discussion points of the proposal. Comments of course welcome. Hopefully, everyone will have time to review this before next weeks virtual F2F. Ron [attachment "Proposal for Static SDOs.doc" deleted by Frank Budinsky/Toronto/IBM] [attachment "Static SDO.ppt" deleted by Frank Budinsky/Toronto/IBM] --------------------------------------------------------------------- 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]