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" <>
02/26/2009 09:34 AM
To
"Barack, Ron" <>, "Blaise Doughan"
<>
cc
<>
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:]
Gesendet: Dienstag, 24. Februar 2009 15:05
An: Blaise Doughan
Cc:
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:]
Gesendet: Dienstag, 24. Februar 2009 14:50
An: Barack, Ron
Cc:
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
