Issues List for Containment Discussion

["Blaise Doughan" <blaise.doughan@oracle.com>]

Hello All,

 

Since there is alot to discuss I have identified the following key issues from my containment proposal, these will be the discussion points for tomorrows meeting:

 

 

Issue A - Relax Containment Requirements

 

The core issue is the removal of the following from section 2 "Architecture" from the SDO specification:

 

"A data graph consists of:
• A single root DataObject.
• All the DataObjects that can be reached by recursively traversing the containment Properties of the root DataObject."

 

The removal of this part will allow data graphs with less containment to still be valid according to the specification.

 

---

 

Issue B - SDO Type to XML Schema Algorithm to Handle Relaxed Containment Requirements

 

An impact of resolving Issue A is that the SDO Type to XML schema algorithm (see section 10 "Generation of XSD from SDO Type and Property" from the SDO specification) needs to be enhanced.  The proposal can be found in the "Enterprise Data Model – To XML Schema" section of the following document:

 

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

 

With this proposal SDO 2.1 compliant metadata will continue to generate the exact same XML schemas.  This proposal is an enhancement  to the existing algorithm and not a replacement or alternative.

 

---

 

Issue C - Add API indicating Key Properties

 

SDO already has the concept of key properties, but there is currently no API to ask if a property represents the key.  Take the following example from section 13 "ChangeSummary XML format".  The "SN" property is the key property for the Employee type, and is used by the Company type to represent the non-containment property "employeeOfTheMonth" in XML.

 

<company:company name="MegaCorp" employeeOfTheMonth="E0004">
    <departments name="Advanced Technologies" location="NY" number="123">
        <employees name="John Jones" SN="E0001"/>
        <employees name="Jane Doe" SN="E0003"/>
        <employees name="Al Smith" SN="E0004" manager="true"/>
    </departments>
</company:company>

 

Proposal:

• Add a new property on Property called "key".
• Add API to Property "public boolean isKey()"
• Allow the XML schema to be annotated to indicate the key node.  To remain backwards compatible nodes of type xs:ID would automatically be recognized as key properties. 
• If a key property is not present the XML representation is the same as it is in SDO 2.1.
• Update the SDO Type to XML Schema Algorithm from Issue B to make use of key properties.

---

 

Issue D - Define the concept Containment

 

The SDO specification does not currently define containment.  I propose the following definition (I believe this definition to be fully compatible with SDO 2.1):

 

"For a property representing a relationship between two types A and B, then the property is considered containment if instances of Type A may not share instances of Type B.  In addition Type C may have a containment relationship to Type B, but an instance of A and an instance of C may not both reference the same instance of B through containment relationships."

---

 

Issue E - Allow the Opposite of a Containment Property to be Containment

 

Using the definition of containment proposed in Issue D, it is reasonable to allow the opposite of a containment property to be a containment property.  This is a usefule mechanism for representing metadata from relational databases and JPA entities.  Refer to sections "Example – Relational Database", and "Example – JPA Entities" from the document below:

 

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

 

Allowing this combined with the SDO Type to XML Schema algorithm from Issue B allows multiple XML schemas to be derived from SDO types.  Refer to sections "Example #1 – Root Type is Address", "Example #2 – Root Type is Employee", and "Example #3 – Root Type is PhoneNumber" from the document below:

 

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

 

--- 

 

Issue F - Allow Properties to Have Composite Keys

 

Many data technologies such as relational databases and JPA entities make use of composite keys.  If SDO is to be able to represent data from these sources then it to will require the ability to have composite keys.

 

Proposal:

• Allow more than one property in a type to be isKey=true (see Issue C).
• Modify the XML representation of DataObjects to handle the multiple key case.  If 0 or 1 key properties are present the XML representation is the same as it is in SDO 2.1.
• Modify the XML representation of ChangeSummary to handle the multiple key case.  If 0 or 1 key properties are present the XML representation is the same as it is in SDO 2.1.

 

-Blaise