AW: [sdo-comment] support for dynamic containment

[bert.robben@agfa.com]

Hi Ron,

We applied user-defined containment for the exchange of data. To this end, 
we introduced the concept of a Snapshot (*). A snapshot is an opaque 
container of data that can be converted to and from DataObjects or normal 
(of even more exotic) java objects. While creating such a container you 
have to supply a SnapshotDefinition. The prime example of such a 
definition is a selectclause that enumerates all properties that you want 
to include in the snapshot. A select clause is typically created from a 
comma-separated list of property paths. The SnapshotDefinition defines 
what part of the object graph can be reached.

So we don't attach this information to the dataobjects or types but pass 
it as a parameter each time we need it.

For CopyHelper.copy, this would be something like

        CopyHelper.copy(DataObject source, Scope scope)   // where Scope 
is something like SnapshotDefinition

For XMLHelper.save() I can imagine something similar. However because the 
structure of your xml depends on the scope, there are issues when you want 
to be compliant to an xsd. I don't have a good solution there, but I also 
would not qualify myself as an XML expert so others might have good ideas 
here.

Because this user-defined containment is not a part of the data objects 
itself, it's not such a problem exchanging them.

best regards,

Bert

PS: Agfa is unfortunately not an OASIS member. Traditionally, we're much 
more active in the Healthcare standardization sector (IHE etc).
PPS: (*) At first I tried to avoid adding this concept, but it turned out 
that the notion of containment was so deep inside a DataGraph that I 
either had to distort DataGraph a lot or invent something new.


Bert Robben | Agfa HealthCare
Platform Architect | HE/Technology Platform Team
T  +32 3444 8407 | F  +32 3444 8401

Quadrat NV, Deinsesteenweg 114, 9031 Drongen, Belgium
http://www.agfa.com/healthcare/
R.O.: Septestraat 27, B-2640 Mortsel, Belgium | RLE Ghent | VAT BE 
0426.312.921 | IBAN BE95570125275558 | Citibank International PLC, B-1050 
Brussels
Click on link to read important disclaimer: 
http://www.agfa.com/healthcare/maildisclaimer



"Barack, Ron" <ron.barack@sap.com> 
06/12/2007 13:48

To
Bert Robben/AMOCZ/AGFA@AGFA, <sdo-comment@lists.oasis-open.org>
cc

Subject
AW: [sdo-comment] support for dynamic containment







Hi Bert,

Thanks for bringing this up.  I think it's very appropriate that the very 
first message on this list should deal already with the issues surrounding 
containment.

I'm curious exactly how you are imagining the API here.  How would 
containment (and other XML related) information be imposed on a datagraph, 
eg, when the user wants to do an XMLHelper.save, CopyHelper.copy, or 
simply turn on change-logging?  One way we've considered doing this was to 
pass in a reference to an XSD as an additional parameter.  The 
disadvantage of such an approach is the extra complexity it introduces 
into the API.

At SAP, we've considered (and prototyped) several approaches towards 
adding containment information on-the-fly.  The approach that we are 
currently pushing is probably something along the lines of what you mean 
by option 1, each app defining "its own type".  Each application (I mean 
here Java EE applications, eg, things deployed in an EAR) has its own 
HelperContext, therefore, its own implicit registry of types.  The problem 
of adding (or changing) containment information on the fly becomes the 
problem of moving DataObjects between HelperContexts, for which we will be 
proposing a few specific methods in SDO 3.0.  We don't see the 
disadvantage of a proliferation of types.  After, applications  typically 
want to have their own type registry, and not have to worry about 
conflicts with other applications. 

By the way, is Agfa an OASIS member?  You might want to consider joining 
our TC.

Best Regards,
Ron

-----Ursprüngliche Nachricht-----
Von: bert.robben@agfa.com [mailto:bert.robben@agfa.com] 
Gesendet: Dienstag, 4. Dezember 2007 16:29
An: sdo-comment@lists.oasis-open.org
Betreff: [sdo-comment] support for dynamic containment

Support for dynamic containment
-------------------------------

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.

Frank Budinsky let me know that this is closely related to charter item 
(10.  Relaxing Containment Requirements).


I posted this also as a feature request on the Tuscany JIRA (
https://issues.apache.org/jira/browse/TUSCANY-1918).

Interested parties can have a look at our SDO implementation (which we 
donated to Tuscany) (see also Tuscany JIRA 1527 and 1493) where we try to 
support this.






Bert Robben | Agfa HealthCare
Platform Architect | HE/Technology Platform Team
T  +32 3444 8407 | F  +32 3444 8401

Quadrat NV, Deinsesteenweg 114, 9031 Drongen, Belgium
http://www.agfa.com/healthcare/
R.O.: Septestraat 27, B-2640 Mortsel, Belgium | RLE Ghent | VAT BE 
0426.312.921 | IBAN BE95570125275558 | Citibank International PLC, B-1050 
Brussels
Click on link to read important disclaimer: 
http://www.agfa.com/healthcare/maildisclaimer

---------------------------------------------------------------------
To unsubscribe, e-mail: sdo-comment-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: sdo-comment-help@lists.oasis-open.org