Upload
odysseus-soto
View
13
Download
0
Embed Size (px)
DESCRIPTION
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. - PowerPoint PPT Presentation
Citation preview
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.