ISSUE 46: Serialization of Metadata

["Barack, Ron" <ron.barack@sap.com>]

Title: SDO Namespaces

Hi Everyone,

 

Reviewing the next batch of issues, I came across this one, which also rang a bell because of the current effort to publish our XSDs.

 

SDO 2.1 actually published an XSD in which metadata (Types and Properties) could be persisted.  The file is "xml/sdoModel.xsd". Curiously, there is no API for the generation or processing of XML files that match this schema, and AFAIK, there are no references to the schema in the specification.

 

The JIRA has to do with how references to types are represented in this XSD.  Namely, when the type is in another namepsace, how is the reference resolved?  Besides that, there are other problems.  For instance,

 

1.  there is no representation of global (ie, open content) properties.

2.  it is not clear how facets, or any other XML or Java attributes can be added.

 

I was wondering if anyone is generating or reading meta information according to this schema.  If not, it might be a good idea to just use the XSD that is generated from the {commonj.sdo}Type as the starting point.  This is consistent with the "Types are DataObjects" approach, about which I believe that there is general consensus.  It also gives us an API that can be used to generated and process the XML, and is an open model, giving implementations a way to add facets and other open content to the types.

 

However, there are also some problems to be solved in this approach.

 

1.  references to Types.  By default, this would need to be the XPath of the referenced type within the current document.  Even if the referenced type is in the document, this would be completely unreadable, and when the referenced type is outside the document (eg., is a standard type, like sdo:int) then this would result in a file-not-closed exception

 

2.  global properties.  We need to somehow associate the properties with a namespace.  This is not in the definition of {commonj.sdo}Property.

 

 

I would also like to address some other requirements here.  For instance, we have use-cases where it is necessary to serialize the entire registry that is associated with a HelperContext.   And we would also like to pack the information within the serialization of a DataGraph, the way that DataGraphs can also contain XSD (and EMOF).

 

This leads to a serialization format in with a hierarchy that looks something like this:

 

   <registry>

        <namespace uri="xs:AnyUri">

             <property .../>

             <type .../>

        </namespace>

   </registry>

 

TypeHelper would then get a method like getRegistry() that would return this DataObject, and the data object could be serialized (or deserialized) using XMLHelper.

 

 

Best Regards,

Ron