Hi Blaise,
Even assuming this approach to XML annotations, we may
still need @SchemaInfo in order to get simple types into the system. Do
you agree?
The trouble with the nullable annotation as you defined it
is that there's no way to get nullable to be unset. I don't know if this
is a problem.
Our definition of keys is very much based on JPA. I
was thinking we could use @Id, etc. If this is a problem,
we can certainly add a @SdoKey and a @SdoKeyType
annotation.
Since orphans aren't business properties, I don't see them
as being relevant.... If I wanted to ship an unclosed model using XML, I would
pack it in a DataGraph (or UnclosedDataGraph, per my other
email)
Talk to you in a few minutes,
Ron
Hi Ron,
Below are some additional comments on the static SDO
proposal.
@SchemaInfo
Wrt @SchemaInfo we would rather see
the necessary info captured in annotations. After looking at the metadata
required it would be quite minimal and nothing that could be considered in
competition with JAXB. I believe this corresponds to item #4 on slide 9 of the
slide deck you send out today. It could look something like the
following:
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE) public @interface SdoXmlType
{ String name() default
""; String uri() default
""; boolean mixed() default
false; }
@Retention(RetentionPolicy.RUNTIME)
@Target(@Target({ElementType.METHOD,
ElementType.FIELD}) public @interface SdoXmlProperty
{ String name() default
""; String uri() default
""; XmlNodeType nodeType(); // A
new enum with values ATTRIBUTE and ELEMENT
}
@SdoType
Your proposal appears to be missing abstract and
alias name properties, was it meant to look like the
following:
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE) public @interface SdoType
{ boolean open() default
false; boolean sequenced() default
false; String name() default
""; String uri() default
""; boolean abstract() default
false; String[] aliasName() default
{}; }
@SdoProperty
We would like
to see the nullable aspect added to the @SdoProperty annotation. Currently
your proposal states that this corresponds to true in the property if the Java
dataType supports null, we would like to be able to restrict that further (you
already can when defining types from XSD and DataObjects so why not from
Java?). It would look something like:
@Retention(RetentionPolicy.RUNTIME)
@Target(@Target({ElementType.METHOD,
ElementType.FIELD}) public @interface SdoProperty
{ String type() default
""; String name() default
""; String opposite() default
""; boolean containment() default
false; String[] aliasNames() default
{}; int propertyIndex() default
-1; boolean nullable() default =
true; }
Keys & Orphan
Properties
How do you see keys and orphan properties relating to
annotations?
-Blaise
Barack, Ron wrote:
7C3EF93EEBC6EB4A8B4470853DE86566707097@dewdfe18.wdf.sap.corp
type="cite">
Hi Blaise,
Yes, I think that if a type were created
through JavaHelper.define() were given to XSDHelper.save(), then somehow the
annotation must be translated to a restriction.
Again, my motivation is mainly to make the metadata model
for types defined through java as consistent as possible with the metadata
model for types defined through XSD.
Fail fast exceptions are, in my opinion, a good thing,
especially for restictions like string length. But, like I said, whether
we do validation is a seperate issue than the question of whether the
restrictions can come from java or only from schema.
Have you thought about @SchemaInfo?
Ron
Hi
Ron,
As of yet I'm not proposing anything, I'm just trying to get a
feel of why we're thinking of adding facets. Is your intent that they be
added solely as metadata? You mention that they are not necessarily for
schema generation, but would they be used here?
-Blaise
Barack,
Ron wrote:
7C3EF93EEBC6EB4A8B4470853DE86566707059@dewdfe18.wdf.sap.corp
type="cite">
Hi Blaise,
I see the facets mostly as metadata, for clients to use
or ignore. Not necessarily for schema generation, but also for
generating UIs and portlets. Originally, I had the goal to make the
types that could be generated from a java class just as rich as the types
that could be generated from XSD. In this proposal, I've move
significantly back from the goal, especially when it comes to registered
dataTypes, but I think, where possible, we should try to achieve a similar
level of expressiveness.
The question of if and when we do validatation is a bit
orthogonal, we would want exactly the same behavior for types defined
through JavaHelper.define as we have for XSDHelper.load. In our
implementation we do fail fast validation, but not of things like minOccurs
(@Size(min=)) since they may be invalid only transiently. We also have
some exception handlers so that users may "catch" errors themselves.
Before adding such a construct to SDO, I guess we'd have to agree that fail
fast should be the default standard behavior. Are you proposing
this? Again, since the behavior would also apply to types defined by
XSDHelper.define() I see this as an orthogonal issue (to whether we have
java annotations and what they are).
I agree that we should learn from JAXB experience
and avoid on-demand validation.
I'm not sure I get the point of your last
paragraph... Are you implying that facets are too un-java-like to fit
comfortably in as Java annotations? Would you rather leave
them out of the proposal?
Ron
Hi
Ron,
What role do you see facets playing?
- Fail fast validation (i.e. set a string that is too long or add beyond
the max size of a list, then immediately throw an exception)?
- On demand validation (create a validator class that you can use to
confirm the object is valid)?
- More metadata for better schema generation?
In JAXB we found
more often than not the XML schemas users were using was more of a rough
guideline of how the XML should look as opposed to the exact
specifications. Where validation could occur in JAXB the spec group
added plenty of validation event handlers where users could programmatically
choose to ignore them. If we supported fail fast validation in
SDO, we would also need the mechanisms to allow users to override this
behaviour.
JAXB had support for on demand validation, but it was
deprecated in JAXB 2.0, ultimately all the participants agreed that nobody
was using this feature. In the almost 3 years since the release of
JAXB 2, I haven't had a customer ask for this functionality back.
In
terms of schema generation (from a JAXB perspective), Java users have
different expectations of XML schema than XML users do. JAXB Java
users want an XML schema they can use with Web Services, they rely on Java
typing to constrain there model. They choose int/long/float to
constrain their numeric types instead of relying on
maxInclusive/minInclusive.
-Blaise
Barack, Ron wrote:
7C3EF93EEBC6EB4A8B4470853DE86566706F9D@dewdfe18.wdf.sap.corp
type="cite">
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
Hi
Ron,
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." Thinking
ahead to when the HelperContext creation issue is solved, and users can
freely switch between SDO implementations won't the only portable
approaches be to use only interfaces and dynamic proxy objects, or produce
impl classes using only byte codes? I'm not saying this is bad, only
that this appears to be what needs to happen.
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
|