OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Comments on Blaises Proposal


Hi Everyone,

Much as I like aspects of this proposal, there are several fundamental problems with it.  In particular, Blaise's claim that "makes use of containment properties when they are present and handles things when they are not" is false.  The fundemtental problem is that what Blaise calls "orphans" can not be determined by analysing the metadata, you have to look at the actual instances.  Using the proposed algorithm, it is still possible to generate documents with unresolved references.

I want to point out that this, or any other proposal regarding containment within a context is somewhat orthogonal to the issue 66.  Issue 66 solves the more general problem of moving data between contexts in which the definition of the types varies slightly.  Both containment and instance class are our first targets, but certainly we believe this to be a a way in which other problems, such as versioning, can be addressed.

Nonetheless, let's compare, at a very high level, the approach to containment of the two approaches.

One of the problems we've got when dealing with different application using different sources of metadata is that the definition have to sync-up.  In standard SDO 2.1, metadata comes basically from XSD.  The standard defines how to convert this to Java, and it's expected that the users of the java interfaces take what they get.
 
Blaise's proposal at least allows a second route.  It allows the data to be defined from Java, and any XML clients have to take what they get.
 
That we've tried to achieve with Issue 66 is to "meet-in-the-middle".  That is, for instance, some aspects of the model can be defined in Java, the things that effect XML can be defined in XSD.  Both sides can be kept a little happy.

In other words, the project method allows the XML structure to be added in after the Properties are already defined, without touching the application that is defining the properties.  None the less, the XML client has a large degree of flexibility in defining the document he wants.

Please find my detailed comments to Blaise's proposal in the attached document.


Best Regards,
Ron


-----Ursprüngliche Nachricht-----
Von: blaise.doughan@oracle.com [mailto:blaise.doughan@oracle.com] 
Gesendet: Donnerstag, 3. April 2008 22:05
An: sdo@lists.oasis-open.org
Betreff: [sdo] Groups - Proposal - Containment and Enterprise Data Models (SDO-EnterpriseDataModel.doc) uploaded

This is the containment proposal I mentioned during the conference call on
April 1, 2008.

 -- Mr. Blaise Doughan

The document named Proposal - Containment and Enterprise Data Models
(SDO-EnterpriseDataModel.doc) has been submitted by Mr. Blaise Doughan to
the OASIS Service Data Objects (SDO) TC document repository.

Document Description:
The SDO spec to date has primarily concerned itself with deriving SDO
metadata from XML schema.  As such containment has come to represent the
concept of nesting as it relates to XML elements.  We prefer to think of
containment as a type of "privately owned" concept.  For the association
"residence" between types "Employee" and "Address" if instances of
"Employee" may not share references to instances of "Address" then it is a
containment relationship:  
 
Containment:  employeeDO1.get("residence") == employeeDO2.get("residence");
 // This can never be true
Non-Containment:  employeeDO1.get("residence") ==
employeeDO2.get("residence");  // This can be true
 
Using the above interpretation of containment it becomes easy to derive SDO
metadata from other sources, such as JPA entities, JAXB objects, relational
databases, etc. (the doc provides an example of deriving SDO metadata from
a relational database).  These sources may not have a concept of nesting,
but they are aware of data sharing rules.  Of course DataObjects require an
XML representation, and containment has been an important part of that. 
The attached proposal contains an algorithm that makes use of containment
properties when they are present and handles things when they are not.

View Document Details:
http://www.oasis-open.org/apps/org/workgroup/sdo/document.php?document_id=27848

Download Document:  
http://www.oasis-open.org/apps/org/workgroup/sdo/download.php/27848/SDO-EnterpriseDataModel.doc


PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.

-OASIS Open Administration

SDO-EnterpriseDataModel.doc



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]