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