It's like a rainbow...
Hi Ron,
I've added my comments
inline
-Blaise
Barack, Ron wrote:
7C3EF93EEBC6EB4A8B4470853DE865667C79CA@dewdfe18.wdf.sap.corp
type="cite">
Hi Blaise,
comments inline.
Ron
Hi
Ron,
Some additional comments on the proposal:
General
Comments
What package will the annotations
be put in, commonj.sdo.annotation?
Yes.
Are we requiring that the
Interfaces generated from XML schemas contain the proposed annotations?
Right now, generation
is not in the spec at all. So the question is really whether
an interface without the annotations can be used as a static SDO that becomes
associated with the SDO type not though JavaHelper.define(), but
rather through eg, annotations in the XML schema. My thinking
is that in such use cases, where the static SDO is only providing an API
to access an already defined type, we don't have to require static SDOs
that have all the metadata to derive the type. The mapping just has to
work, that is, you have to get from the JavaBean accessors to the SDO
properties. I think we need this use case to be lax wrt annotations, for
backward compatibility issues. Agreed.
7C3EF93EEBC6EB4A8B4470853DE865667C79CA@dewdfe18.wdf.sap.corp
type="cite">
From Section 1.1 - Compliance
Points
"While it is expected that
implementation will provide a means to generate static interfaces based on
schema and/or other sources of metadata, the precise API for generation of
static SDO is out-of-scope for this specification. Compliance is
based on the ability to use generated interfaces as a source of metadata and
as a means of accessing data. Interoperability is achieved because
the interfaces of the static SDOs, and clients that rely on them and their
mapping to SDO metadata, can be used with any compliant SDO implementation
regardless of how the static SDOs were generated."
It is possible to test the generated interfaces. The JAXB TCKs
do this by making the class generation step pluggable, implementors write a
TCK/compiler bridge so that the TCK can generate classes using that
implementation. I'm not saying we need to do it, only that it is
possible.
I
would prefer for the spec and the TCK to focus on the runtime
requirements. For SDO to be specified and tested as a
library, rather than a build environment, and to leave all design time
functionality (like generating static SDOs) as vendor enhancements. I
agree, we could add generation as a complience point, if we
wanted. What is your preference
here?
If we're leaving
the generated interfaces vague (see above), then it makes sense as you describe
to keep the TCK focussed on the runtime requirements.
7C3EF93EEBC6EB4A8B4470853DE865667C79CA@dewdfe18.wdf.sap.corp
type="cite">
From Section 1.6 - Generation of SDO Types from Static
SDOs
Base Type For the base type, are we going to
include any special exclusions such as if your interface extends
java.io.Serializable then your type is not expected to have a base type with
instance class java.io.Serializable?
I
hadn't thought about this, but it certainly sounds reasonable to
ignore java.io.Serializable. What other interfaces fall into this
catagory? We could say that everything in java.* and javax.* is
ignored...certainly there are no interfaces there that would be relevant
static SDOs.
Ignoring the java.* and javax.* interfaces make
sense. We may also want to provide an annotation where the user can
declare this interface corresponds to a root type.
I will add this to the
next revision of the proposal.
7C3EF93EEBC6EB4A8B4470853DE865667C79CA@dewdfe18.wdf.sap.corp
type="cite">
Containment
Default Presumably the goal of annotations is to require as few of
them as possible, where the defaults are normally good enough and the user
only specifies annotations when they need to override default behaviour.
If the predominant use of SDO is with XML then containment should default to
true, otherwise it will appear annotation heavy when compared to technologies
such as JAXB.
One
the one hand, default containment=true fits better to static SDOs that
are generated from schema. But in such cases we are dealing
(probably) with generated interfaces, so it doesn't really place a burden on
the programmer to annotate the interfaces so the win here really isn't very
big. I believe this is very much offset by the fact that, when
dealing with object-oriented models, either hand written or generated
from some object-relational tooling, then default-containment=true is
typically the wrong choice. Having this default can result in
illegal models (due to cycles of containment) as well as unwanted side effects
(setting one containment implicitly removes the object from its old
containmer). The default behavior should reflect the normal Java
interpretation of properties, which is non-containment. Does this
make sense?
What is the default value for the containment property
on the Property type? I think it would make sense to use this as the
default.
The is no explicit default value defined in the spec, therefore I
think the default default rules (section 4.1.5) apply. This defines the
default default value of a boolean property is
"false".
7C3EF93EEBC6EB4A8B4470853DE865667C79CA@dewdfe18.wdf.sap.corp
type="cite">
Data Type
Properties "If
[javaType] is not a static SDO, then the implementation may create a property
with any of SDO’s defined data types, so long as the selected data type is
compliant with the Java type, according to the rules of Chapter
6." Isn't this
point overridden with the table below it?
Right. Sorry. Cut and
paste error between different versions.
From
Section 1.7.2 - @SdoOpenContentProperty
"When @SdoOpenContentProperty is
used to annotate a Java type, then its “type” attribute is
ignored." I find the above statement
confusing. I think if the type is not specified then it defaults to the
owning interface, but if it is specified then it should either be used or an
error condition should be thrown. It would be confusing for the property
to be a type other than the one specified.
I'm OK with this.
Another point wrt @SdoOpenContentProperty, if the same
open content property is defined multiple times (i.e. once at the package level
and again at the class level), is this an error condition, or does the property
defined at the class level win?
Another
possibility is to limit @SdoOpenContentProperty in packages to simple types and
complex types in other namespaces, and @SdoOpenContentProperty on a class to the
namespace of the class. Personally, I consider a doubly
defined property, like a doubly defined type, to be a user
error.
7C3EF93EEBC6EB4A8B4470853DE865667C79CA@dewdfe18.wdf.sap.corp
type="cite">
How do we specify
the XML representation of open content properties?
Good
point. I will change the target of the @SdoXml*
annotations to allow them to be set on annotations so that programmer can
apply them to @SdoOpenContentProperty.
Will @SdoOpenContentPropery now have properties of type
@SdoXml* annotations?
I
can't really think of a better way. Pretty ugly solution though. Why don't annotations
allow polymorphism????
7C3EF93EEBC6EB4A8B4470853DE865667C79CA@dewdfe18.wdf.sap.corp
type="cite">
From Section
1.8.2 - @SdoIncludePackage
Can
you further explain this annotations?
Well, it's pretty much the same as Schema's
<xs:import>.
Imagine a type with a datatype property
@SdoProperty(type="otherNS#Foo")
String getBar();
Somehow, the implementation has to know where to find the definition of
{otherNS}Foo. If we're lucky, otherNS will be something like
"urn:java:com.example.myTypes", and we can just go look up the type definition
in com.example.myTypes.package-info.java. But what if it's not?
The type could be defined in a package-info that uses @SdoURI to specify
another namespace for the types defined there. An implementation has to
know what package-info to analyse in order to find the definition of the
type. @SdoIncludePackage tell the implementation which packages should
be analysed. Does that explanation help?
This annotation appears similar to the XmlSeeAlso
annotation from JAXB 2.1. Some of the language may need to be softened
here. Currently it says the included package must be processed first (what
if the included package includes the original package?).
I didn't think we
need cycle dependencies, since schema also doesn't have them, but on
consideration, we probably do, since multiple schemaLocs can contribute to a
single namespace, but we seem to be supporting only one package per
namespace. I guess it's not really harder to handle the references
between packages than the references within a package, so I agree with loosening
this wording.
Should we change the name
to @SdoSeeAlso?
7C3EF93EEBC6EB4A8B4470853DE865667C79CA@dewdfe18.wdf.sap.corp
type="cite">
-Blaise
Barack, Ron wrote:
Hi Frank,
Good catch regarding the wording of JavaHelper.define()... Yes, the proposal for static SDOs (as was pointed out during the presentation during the vF2F) requires interfaces as static SDOs be supported. I think that JavaHelper.define() should work the same way. Interfaces MUST be suppported, vendor extensions (to POJO or generated classes) are allowed. The reason for this is to achieve portability across SDO implementations.
Regarding the use of JAXB annotations as a source of SDO metadata, we've had serveral mail threads on the topic, for instance this http://www.oasis-open.org/apps/org/workgroup/sdo/email/archives/200901/msg00036.html
And before that http://www.oasis-open.org/apps/org/workgroup/sdo/email/archives/200811/msg00007.html
Everyone, myself included, would have liked to replace static SDOs with JAXB POJOs. Unfortunately, especially when it comes to being a source of metadata, an implementation can't really do better than what the client can already do himself, call JAXBContext.generate and pass the result to XSDHelper.
Regarding the three required ways for defining types in SDO: the current proposal has nothing to do with it, this was already decided when we added JavaHelper.define().
Regarding the "optional" ways of defining types: these are not really optional features, they are vendor extensions. As I wrote above, I don't think defining types based on JAXB is very realistic, at least not as an implementation feature. I'm strengthend in this belief also by EclipseLink's JAXBHelperContext, which you notice does not use the JAXBs themselves as sources of metadata.
I don't see much of a differnce between supporting POJOs and JPAs as sources of metadata, except that for instance an implementation might want to consider @Id and @SdoKey to be synonymous. A clever implementation could also analyse the mapping and determine bi-directional properties. But unlike JAXB, the mapping between the JavaBean and the SDO properties is pretty one-to-one. In other words, if an implementation chooses to allow POJOs as static SDOs, they are already very close to a solution for JPA integration.
As far as use-cases are concerned, it comes down to the same discussion we've had before. If SDO is supposed to provide a representation for data that is independent of the source of the data, then it's pretty awkward that the only easy way to define types is XML schema. (To me, the TypeHelper.define() method is almost an SPI method, useful for implementing DAS's but not something I expect business services to have to provide.) If XSD is the only way to define types in SDO, then we need to change the definition of SDO to providing a representation for data that is independent of the source of the data, provided that source is XML.
My comments above are all about using JAXB as a source of metadata. Of course, JAXB integration (as far as moving data between SDO and JAXB, or some kind of wrapping approach) is something we'd really like to see.
Ron
-----Ursprüngliche Nachricht-----
Von: Frank Budinsky [mailto:frankb@ca.ibm.com]
Gesendet: Donnerstag, 26. Februar 2009 23:22
An: sdo@lists.oasis-open.org
Betreff: Re: AW: [sdo] Revised Proposal for Static SDOs.doc
Hi Ron,
First of all, I want to say that the annotation design looks fundamentally
good to me.
My question is what exactly is this requiring of an implementation? In
Section 2.9.1 of sdo-java-3.0-spec-cd01.doc it says this about JavaHelper:
"Implementations may impose limitations on the classes given as arguments
to the define and create methods. Some implementations may allow only
interfaces to be given, others may allow POJO classes, other
implementations may allow only classes that extend some implementation
dependent base class to be used.".
Does this mean that it is optional whether or not implementations support
defining metadata using interfaces with these annotations? My guess is
that you're answer is no. If so, then I would like to better understand
what exactly the SDO 3 story is regarding creation of metadata.
In SDO 2, we had the following story:
1. define with XML Schema required
2. define programmatically required
3. define with other sources optional (impl specific)
The proposal for SDO 3, as I understand it:
1. define with XML Schema required
2. define programmatically required
3. define with static SDO required
4. define with POJO classes optional (w/JavaHelper)
5. define with JAXB classes optional (w/JavaHelper)
6. define with JPA classes optional (w/JavaHelper)
7. define with other sources optional (impl specific)
Do I have this correct? My concern with #3 being required is that if an
impl (e.g., IBM's) wants to support #5, we're forced to support two
competing ways of doing the same thing. In our use case, we want to use
JAXB, but would be forced to provide users with two options. It
complicates things, because now we need to explain which one should be
used when. Since our use case is XML-centric and we want to use JAXB, the
standard static API for XML, our answer will always be to use JAXB. To us,
the static SDO alternative is only interesting when the canonical metadata
representation is not XML Schema, but that is not a use case we currently
want to support with our impl.
Comments?
Thanks,
Frank.
"Barack, Ron" <ron.barack@sap.com>
02/26/2009 09:34 AM
To
"Barack, Ron" <ron.barack@sap.com>, "Blaise Doughan"
<blaise.doughan@oracle.com>
cc
<sdo@lists.oasis-open.org>
Subject
AW: [sdo] Revised Proposal for Static SDOs.doc
Hi Blaise,
Embarrassing mistake here: annotations do not allow "extends" clauses. In
that case, I have a slight preference for the proposal as it is currently
written up, since it allows the user to either make something an element
explicitly or to allow SDO to decide itself. That said, I really don't
want to hold up accepting this proposal based on this issue. If this is
the only thing that is hold you back from supporting the proposal, let me
know and I will replace my @SdoXmlElement and @SdoXmlProperty with the
annotations you have specified.
For everyone else, the proposal was reviewed and discussed at the vF2F, I
think there is consensus here. I'd like to resolve ISSUE 22 (as well as
ISSUE 13, ISSUE 25, ISSUE 28 and ISSUE 29) at Tuesday's meeting.
Ron
Von: Barack, Ron [mailto:ron.barack@sap.com]
Gesendet: Dienstag, 24. Februar 2009 15:05
An: Blaise Doughan
Cc: sdo@lists.oasis-open.org
Betreff: AW: [sdo] Revised Proposal for Static SDOs.doc
Hi Blaise,
I was thinking that "null" would mean "normal SDO rules (for determining
if a property is an attribute or element) apply". With a 2 valued enum,
the runtime would have no way of knowing if the programmer expressed a
wish regarding isElement or not.
Since they share the "name" and "uri" properties, maybe @SdoXmlProperty
can be a base type extended by @SdoXmlAttribute and @SdoXmlElement?
Ron
Von: Blaise Doughan [mailto:blaise.doughan@oracle.com]
Gesendet: Dienstag, 24. Februar 2009 14:50
An: Barack, Ron
Cc: sdo@lists.oasis-open.org
Betreff: Re: [sdo] Revised Proposal for Static SDOs.doc
Hi Ron,
How about dropping @SdoXmlProperty and enhancing @SdoXmlAttribute and
@SdoXmlElement? Where do you see the node type being null?
@Retention(RetentionPolicy.RUNTIME)
@Target(@Target({ElementType.METHOD, ElementType.FIELD})
public @interface SdoXmlElement {
String name() default "";
String uri() default "";
}
@Retention(RetentionPolicy.RUNTIME)
@Target(@Target({ElementType.METHOD, ElementType.FIELD})
public @interface SdoXmlAttribute {
String name() default "";
String uri() default "";
}
-Blaise
Barack, Ron wrote:
<<Proposal for Static SDOs.doc>>
Hi Everyone,
Attached is a new proposal in which I've tried to incorporate all the
comments I got during the F2F on Friday. Blaise, I've broken out
@SdoXmlElement seperately rather than keeping it a part of @SdoXmlProperty
because annotations don't allow default values to be null, and I think
implementations need to distinguish whether the user has actually said
anything or not. Otherwise, we'd need a three-valued enum, and I just
think that's too ugly.
Comments welcome, maybe we can discuss this on Tuesday's call.
Ron
---------------------------------------------------------------------
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
|