Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: Java-SDO-Next
    • Fix Version/s: Java-SDO-Next
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        Frank Budinsky added a comment -

        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.

        Show
        Frank Budinsky added a comment - 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.
        Hide
        bert.robben added a comment -

        Interesting. How would that work? I don't know too much about OASIS. Would that involve becoming a member?

        Show
        bert.robben added a comment - Interesting. How would that work? I don't know too much about OASIS. Would that involve becoming a member?
        Hide
        Frank Budinsky added a comment -

        Hi Bert,

        If you want to join the TC and attend the regular telecons, you (or your company) needs to be an OASIS member. We'd love to have you Alternatively, anybody can observe what's going on and provide comments.

        Details can be found at: http://lists.oasis-open.org/archives/tc-announce/200710/msg00011.html

        Frank.

        Show
        Frank Budinsky added a comment - Hi Bert, If you want to join the TC and attend the regular telecons, you (or your company) needs to be an OASIS member. We'd love to have you Alternatively, anybody can observe what's going on and provide comments. Details can be found at: http://lists.oasis-open.org/archives/tc-announce/200710/msg00011.html Frank.
        Hide
        bert.robben added a comment -

        Hi Frank,

        unfortunately becoming an Oasis member is a bit too expensive.

        How can I best observe then what's going on? I had a brief look at the oasis pages but couldn't find much details on SDO v3 except from the link you gave.

        Also, is there some forum for discussions and comments? Or do you use Tuscany (mailinglist/jira) for this?

        Bert

        Show
        bert.robben added a comment - Hi Frank, unfortunately becoming an Oasis member is a bit too expensive. How can I best observe then what's going on? I had a brief look at the oasis pages but couldn't find much details on SDO v3 except from the link you gave. Also, is there some forum for discussions and comments? Or do you use Tuscany (mailinglist/jira) for this? Bert
        Hide
        Frank Budinsky added a comment -

        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.

        Show
        Frank Budinsky added a comment - 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.
        Hide
        bert.robben added a comment -

        Ok, I've subscribed to the comment email list.

        Should I forward the comments I've put in the JIRA issues also to the comment list?

        Bert

        Show
        bert.robben added a comment - Ok, I've subscribed to the comment email list. Should I forward the comments I've put in the JIRA issues also to the comment list? Bert
        Hide
        Frank Budinsky added a comment -

        Hi Bert,

        Yes, please forward your comments to the OASIS list. Also please mention the charter item (10. Relaxing Containment Requirements) that they're related to.

        Thanks,
        Frank.

        Show
        Frank Budinsky added a comment - Hi Bert, Yes, please forward your comments to the OASIS list. Also please mention the charter item (10. Relaxing Containment Requirements) that they're related to. Thanks, Frank.
        Hide
        Amita Vadhavkar added a comment -

        This issue has a dependency on spec. waiting on that.

        Show
        Amita Vadhavkar added a comment - This issue has a dependency on spec. waiting on that.

          People

          • Assignee:
            Unassigned
            Reporter:
            bert.robben
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development