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: ISSUE 124: Proposal


Hi,

I would like to formulate my idea, expressed in another thread, as a proposed approach to issue 124.

I think that the approach combines some of the positive features of both Oracle's and XCalia's proposal, reuses a pattern already used in SDO 2.1, therefore fits in well with the rest of SDO, and is backwards compatible.

Types may have one or more properties annotated as "orphan" properties.  Orphan properties that are defined through an XSD are annotated with sdo:orphan="true".  Orphan properties that are defined through the API have an open content property {commonj.sdo}Orphans with value true.

This annotation may only be used on a read-only multivalued property.  The annotation may not be used on a property with a data type.

This annotation may only be used on a property with containment="true".

Calling a set method on a property, or modifying the list returned by this property must throw an exception.

Getting the value of this property (either through DataObject.get() or through the static interface) returns a list of objects that are referenced by the graph, but not contained in the tree whose root is the node having the "orphans" property and whose type matches the type of the property.
 
{commonj.sdo}DataGraph gets a new property with the orphans annotation, and type DataObject.  However, other types may also have a similarly annotated properties.

The orphan property may appear in a tree:  at the root or at a leaf node.  Types with orphan properties may even appear with trees whose roots have orphan properties, or as "brothers" of such, etc.  In such cases, an implementation is free to place the referenced object in the list of any suitible property, however, the implementation must also assure that the normal rules of containment apply, namely, that the referenced object appears exactly once in the graph.

Having such a property, it is easy to create a technical root type.  Users can specify if they what the technical root to give the referenced objects in a "heap" or to sort them by type.

By putting an orphan property on a Business Object (like Employee, Department, Address), we get XML that looks like the XML produced from Blaise's algorithm.  That is, without unexpected root nodes.

Best Regards,
Ron


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