OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: ISSUE 22: Java Annotations and SDO Metadata


Title: ISSUE 22: Java Annotations and SDO Metadata

Hi all,

On this week's call we had an interesting discussion about ISSUE 22: Java Annotations and SDO Metadata.
The discussion was based on Ron's proposal:
http://www.oasis-open.org/apps/org/workgroup/sdo/email/archives/200809/doc00000.doc

I will try to summarize this discussion:

There was an agreement that it is an useful feature to create SDO types by introspecting Java interfaces or classes. The API to use this feature will be JavaHelper.define(Class).

In cases where the information in the Java interfaces/classes are not rich enough to create the SDO type information, Java  5 annotations can be used to add these missing information.

SDO's Java code generator should be able to generate these annotations.
Radu mentioned that it still must be possible to generate plain interfaces/classes without SDO in the imports.

The chapters 1.1.1 @SdoTypeMetaData and 1.1.3 @SdoPropertyMetaData describe structured annotation classes to add information to types and properties.

The discussion was less about the content of these annotations but rather if the annotations should be structured or with a single value.

Pros for structured annotations:
+ annotations are bundled
+ developer has to learn fewer annotations and can use syntax completion in it's IDE
Cons:
- developers could be more familiar with single valued annotations as used in JPA or JAXB

The chapter 1.1.2 @SchemaInfo raised a big discussion if this annotation is useful.
The idea of this annotation is to provide a link from the Java interface/class to the XML schema. This link is similar to the package-annotation in schemas, just the other way round. With the @SchemaInfo annotation the JavaHelper could receive the missing type information from the XSD and so further annotations wouldn't be needed.

The advantage of this link to XSD is that the definition of types could be done in one step. The enrichment of already defined types to merge Java-based and XSD-based metadata is not necessary.

The concerns about this annotation are that the mapping between the types defined by analyzing Java and the types defined by XSD is not clear.

Also resolving the schema could be difficult.
This annotation would be a simple way to connect Java interfaces/classes with very XML specific metadata.
May be, we need an API to connect interfaces or classes with SDO types or whole schemas.

The chapter 1.1.5 Code generation template for DataType types describes in the current proposal a way to define simple types by dummy interfaces.

The most attendees in the call agreed that this way is some kind of ugly because the interfaces will never be used in the real coding. That could confuse the users.

The advantage of this approach is that the dummy interfaces are an easy way to represent hierarchies in the simple types similar to complex types.

There was a comment that user defined simple types are very uncommon in Java-driven data models, so these dummy-interfaces would be needed in very few cases.

As an alternative to these dummy-interfaces the usage of package annotations should be considered.

Stefan.

Stefan Bünnig
Senior Developer
NetWeaver C Tools

SAP AG
Rosenthaler Straße 30
10178 Berlin
T   +49 30 41092-608
F   +49 6227 78-42807
M  +49 172 3088-367

mailto:stefan.buennig@sap.com
www.sap.com

Sitz der Gesellschaft/Registered Office: Walldorf, Germany
Vorstand/SAP Executive Board: Henning Kagermann (Sprecher/CEO), Léo Apotheker (stellv. Sprecher/Deputy CEO), Werner Brandt, Claus Heinrich, Gerhard Oswald, John Schwarz, Peter Zencke

Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory Board: Hasso Plattner, Registergericht/Commercial Register Mannheim No HRB 350269

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]