Transcript Static SDO
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 „roundtripping“ 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 Alternative approaches to tuning the generated XML (2) 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. 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 = true Type MinFacet int value type Type Facet Type MaxFacet int value 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.