[
https://issues.apache.org/jira/browse/TUSCANY-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545037
]
Frank Budinsky commented on TUSCANY-1918:
-----------------------------------------
There is also a related feature in the charter for SDO 3. See item 10 in the
"Function (V3.0)" section: http://www.oasis-open.org/committees/sdo/charter.php
Note that SDO 3 TC at OASIS welcomes all interested parties.
> Support for dynamic containment
> -------------------------------
>
> Key: TUSCANY-1918
> URL: https://issues.apache.org/jira/browse/TUSCANY-1918
> Project: Tuscany
> Issue Type: New Feature
> Components: Java SDO Implementation
> Affects Versions: Java-SDO-Next
> Reporter: bert.robben
>
> In SDO, the boundaries of a datagraph are defined by the containment
> relation. Only objects which can be reached from the root object by following
> properties that are contained are part of the datagraph. Containment is
> defined at the type level.
> In cases where applications need to dynamically select what information they
> want, this fixed containment relationship is an issue. For instance, suppose
> in a medical context you have defined a number of types defines to represent
> patients together with their clinical (e.g. procedures they have taken) and
> administrative data (for instance their address). The type definition needs
> to decide on the containment of the clinical and administrative data. However
> it is hard to decide whether or not the administrative and clinical data
> should be contained because some applications might only need clinical or
> administrative data and others might need both. In cases where the type
> system is large or where there are large volumes of data involved (for
> instance in the example, procedures could have an associated pdf-report
> property) this becomes a real issue.
> Current solutions within the SDO framework could be (for the interested,
> there has been a mail thread about this a while ago in the user mailing list)
> - Each app shoud define its own type with an appropriate containment
> relation. The downside of this is a proliferation of types.
> - The main types should not have any containment relations. Containment is
> specified using a synthetic type. Think of this as a special list type that
> contains its elements. The root of the datagraph then would be an instance of
> such a list type. All instances that are needed should be put in this flat
> list.
> I would like to propose an alternative solution. In this solution,
> containment would not be specified at the type level. Whenever the boundary
> of a datagraph is needed (for instance when an xml document it be generated
> or a datagraph is to be exchanged between for instance a client and a
> server), the application should provide appropriate information that
> specifies exactly what is part of the graph and what not. This can be seen as
> a select clause for sql, or even better as a set of fetch joins in Hibernate.
> This would give the application control over exactly what it wants. In the
> example for instance, the application can easily decide at each point whether
> or not it would want the address information together with the patient data.
> This proposal would have a number of interesting implications.
> - What is the implication of this for cases where datagraphs are represented
> as xml documents that should be according to an xml schema?
> - How to deal with links to objects that don't belong to the datagraph? One
> strategy could be just to drop them. Another one to provide some kind of
> proxy.
> Interested parties can have a look at our SDO implementation (see also JIRA
> 1527 and 1493) where we try to support this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
