[ https://issues.apache.org/jira/browse/TUSCANY-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547879 ]
Frank Budinsky commented on TUSCANY-1918: ----------------------------------------- Hi Bert, Non-members can monitor the email archives (http://www.oasis-open.org/archives/sdo/) and the document repository (http://www.oasis-open.org/committees/documents.php?wg_abbrev=sdo), and provide comments/feedback via the email list (http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=sdo). Links to all three of these resources are found on the TC Public page at: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sdo Frank. > 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]