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
Von: Blaise Doughan
[mailto:blaise.doughan@oracle.com] Gesendet: Dienstag, 17. Februar
2009 14:07 An: Barack, Ron Cc:
sdo@lists.oasis-open.org Betreff: Re: AW: AW: [sdo] Proposal for
Static SDOs
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
|