Static SDO Proposal

Main Points/ Next Steps

Goals of specification

• Not about the algorithm to generate Static SDOs

• Instead, about how Static SDOs map to SDO types and properties.

• And about how SDO types can be defined through Static SDOs.– GOAL: Portability of source code!

Limitations

• When defining SDO types from Java…• Not all SDO metadata has a natural

mapping to Java.– Example: Simple Types

• Proposal does not provide for „round-tripping“ SDO metadata to Java and back.

• Not every SDO metamodel can be derived from Java. Note, this is also true of XSD, eg, multiple inheritence.

Complex Types Map to Interfaces

• This mapping is established in 2.1, but the section on static SDOs spoke also about generated implementation classes.

• Proposal:– For portability, interfaces must be supported

as static SDOs.– Implementation may support implementation

classes, enhanced POJOs, etc. But these are vendor extensions.

Support for enums

• May map to simple types with enumeration restriction.

• Enumeration class may also be the instanceClass of the simple type.

• Support automatic conversion between Strings and enumeration types.

Support for Facets• Currently no standard SDO metadata to

represent restrictions on simple types.– Is the annotation premature?

• Applied to properties, roughly equivalent to anonymous types in XSD.

• Use JSR-303?• No ability to create „registered“ simple types

through Java.– But this could be done by combining XSD and Java,

per @SchemaInfo– Previous proposal was essentially „side files that

ended in „.java“. Why not use the existing side file type?

Enhancing the Java model with @SchemaInfo

• Becomes more necessary, since the Java metamodel is not SDO complete.

• The most natural way to get XML specific data into the model, without reinventing JAXB.

• Also used for defining data types.

Alternative approaches to tuning the generated XML (1)

1.  No XML specific annotations.  If the user want to annotate something as a way of saying how he wants a Java class serialized to XML, he should use JAXB.

    (+) Avoids competition with JAXB    (+) Consistent with the idea that SDO should be data source

independent    (-) Solution applies to POJO classes only.  Static SDOs can also be

defined through interfaces.    (-) Static SDO will not be suitible for many use-cases.      (-) I think there will be pressure for vendor extensions here.

2.  Use  @schemaLoc annotation    (+) Avoids competition with JAXB    (+) XML specific information is held in an XML-friendly format (an XSD).      (+) The complete XSD is availaible, not the subset we would make

available though annotations.    (-) Problems with maintaining 2 sources of metainformation, handling

inconsistencies, finding the classes that match a XSD, etc.    (-) Static SDO still not a complete solution•  

3.  Use a subset of JAXB annotations      (+) avoids definining new annotations.     (+) more programmer buy-in.     (-) We would effectively be redefining JAXB annotations,

this is an even more offensive "competition with JAXB". 4.  Define a simple annotation to handle this use case, and

promise not to go any further down "the slippery slope".     (+) a large number of cases can be covered with a few

simple annotations.     (-) in the case of POJOs, we are competing with JAXB.

Alternative approaches to tuning the generated XML (2)

Refactoring the spec

• Current chapter 7 contains XSD -> Java „mapping principles“. Moved to chapter 3.

• Chapter 7 should focus on the XSD annotations that influence the java mapping, but not general SDO -> Java mapping.

Standard Name Mangling

• Rules for converting URIs and names to Java follow JAXB name mangling rules.

• Rules for converting package names to URIs (should) follow WebBeans approach: – Prefix with „urn:java:“– This is not currently in the write up, but could

be added.

Next Steps

Facet Metadata• Standard SDO properties to represent facets.• Modelled on XSD facets• Metadata only or fast-fail?• Support minOccurs/ maxOccurs?

Property facets

many = trueType Facet

Type MinFacet

int value

Type MaxFacet

int value

type

Type LengthFacet

int value

Integration with Standard Representations

• Is there interest in standardizing something like EclipseLink‘s JAXBHelperContext?

• Should we defer „binding/ projecting“ to JAXB/ POJO/ DOM?

• Is efficient data transfer enough (for 3.0)?

API for Efficient Data Transfer

• Currently, when converting to JAXB, we need to serialize to XML as an intermediate format. These methods could eliminate this intermediate format.

• XMLHelper– XmlStreamReader

createStreamReader(XMLDocument);– ContentHandler createContentHandler();

• XMLStreamReader (StAX) is in JavaSE 6.