1 / 15

Static SDO Proposal

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.

odysseus-soto
Télécharger la présentation

Static SDO Proposal

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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 Type Facet Type MinFacet int value Type MaxFacet int value 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.

More Related