Hi Ron,
Thank you for adding those issues. I agree
with focussing on SDO-124, SDO-126, and SDO-127 today. The categorizations
you chose look reasonable.
Could you update SDO-128 to reference the new issue
SDO-125 instead of "Issue C" from my email?
-Blaise
----- Original Message -----From: Barack, RonSent: Tuesday, April 15, 2008 3:03 AMSubject: AW: [sdo] Issues List for Containment DiscussionHi All,I've added Issues into the JIRA for each of these
T Key Summary Assignee Reporter Pr Status Res Created Updated Due SDO-128 Allow Properties to Have Composite Keys Ron Barack Ron Barack ; "Major - Major loss of function.")
UNRESOLVED 15/Apr/08 15/Apr/08 SDO-127 Allow the Opposite of a Containment Property to be Containment Ron Barack Ron Barack UNRESOLVED 15/Apr/08 15/Apr/08 SDO-126 Define the concept Containment Ron Barack Ron Barack UNRESOLVED 15/Apr/08 15/Apr/08 SDO-125 Add API indicating Key Properties Ron Barack Ron Barack UNRESOLVED 15/Apr/08 15/Apr/08 SDO-124 SDO Type to XML Schema Algorithm to Handle Relaxed Containment Requirements Ron Barack Ron Barack UNRESOLVED 15/Apr/08 15/Apr/08
Von: Blaise Doughan [mailto:blaise.doughan@oracle.com]
Gesendet: Montag, 14. April 2008 22:43
An: sdo@lists.oasis-open.org
Betreff: [sdo] Issues List for Containment DiscussionHello 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 RequirementsThe 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 RequirementsAn 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: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 PropertiesSDO 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 ContainmentThe 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 ContainmentUsing 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: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:---Issue F - Allow Properties to Have Composite KeysMany 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