1. Static SDO Proposal Main Points/ Next Steps

2. 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!

3. 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.

4. 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.

5. 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.

6. 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?

7. 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.

8. 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

9. 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)

10. 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.

11. 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.

12. Next Steps

13. Facet Metadata Standard SDO properties to represent facets. Modelled on XSD facets Metadata only or fast-fail? Support minOccurs/ maxOccurs? Property facets many = true Type Facet Type MinFacet int value Type MaxFacet int value type Type LengthFacet int value

14. 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)?

15. 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.