AW: [sdo] ISSUE 124: Proposal

Hi Christophe,

 

Whether the implementation stores the referenced objects in 
memory or calculates them as part of the serialization is an implementation 
detail.  All we are doing with declaring orphan 
properties is simply to allow the user control of where there orphans are 
marshalled, given the user a bit of control over how the XML looks.   
If you want to think of the orphans as being only in XML, and not in memory, 
that's OK.  As far as SDO is concerned, the orphan properties (like 
the tech root) vanishes when SDO parses the XML,  However, when the XML is 
processed by some other framework, the fact that SDO produces awkward XML 
could create a barrier to integrating SDO with other XML frameworks.  
As Radu pointed out, it's a little bogus to have a {commonj.sdo}DataGraph 
object, whose root element is a technical root.   It would be 
less awkward to combine {commonj.sdo}DataGraph and 
{commonj.sdo}TechnicalRoot.

 

Like I said, the only reason to define orphan properties is 
to control where orphan objects are serialized into the XML.  If it 
is desireable to seperate the orphans by type (the way XCalia originally 
suggested), then this can be specified.  If you want the orphans 
collected at a particular type (eg, Employee or Department), then this 
is doable too.

 

 

 

Von: Christophe Boutard 
[mailto:] 
Gesendet: Montag, 5. Mai 2008 
11:50
An: Barack, Ron; 
Betreff: RE: 
[sdo] ISSUE 124: Proposal

Hi Ron, 
everyone,

 

Here are my comments 
inline…

 

Best 
Regards,

--Christophe

 

 

De : Barack, Ron 
[mailto:] 
Envoyé : mercredi 30 avril 2008 
10:40
À : Christophe Boutard; 

Objet : RE: [sdo] ISSUE 124: 
Proposal

 

Hi 
Christophe, everyone,

 

I really 
want to try to resolve SDO-124 at next weeks meeting.  Let's try to find a 
solution that combines aspects of the various approaches, and see if we can get 
everyone to sign up to it.

 

The 
criticism that the orphan properties are visible through the API is valid, and I 
agree that users will typically not want to see such properties amoung their 
business objects.  On the other hand, {commonj.sdo}DataGraph is not a 
business object, it's already a technical object, but I guess that not 
everything will be packed in a DataGraph.

 

<Christophe>

I 
want to be sure to get your point. Are you talking about the DataGraph object in 
memory or only its XML serialized format. The end of the mail let me think that 
you are talking about the in memory object.

If it 
only deals with XML that’s fine for me but in the other case I would not like to 
have to maintain the graph closure in memory

</Christophe>

 

One 
solution would be to make orphan properties even more special: to make them 
invisible.  That is, orphan properties appear neither in the list of 
propertys defined by a type, nor in the instance properties of the data 
object.  They appear only when generating XSD from the type metadata, and 
of course, in the XML generated by an XMLHelper.save().  This is 
essentially the behaviour that Oracle has proposed for orphans, the only 
difference is that they are not generated, but created as part of the type 
definition.

 

 

<Christophe>

It is 
almost the same question. You said that the “hidden” properties only appear in 
the XML, so the question is why do we need to have these properties definitions? 
I think that they can be generated by the implementation at XML serialization 
time.

More 
generally I’m really interested in the concept of having invisible properties in 
SDO even independently of the Containment discussion

</Christophe>

 

The 
burden is still on the user to define the appropriate orphan properties, or to 
pack his objects in a DataGraph.  Therefore, it is still possible to 
generate GraphNotClosed exceptions.  If we want to make these exceptions a 
thing of the past, we need to have technical root as a fallback mechanism.  
We'd need to extend the proposal as follows:

 

<Christophe> 

I’m 
really not convinced by the first statement  As I said in previous emails I 
think that these technical things should be managed by the implementation 
otherwise it will introduce a lot of complexity for the 
users.

I’ve 
also a particular question about the way objects are packed in a DataGraph. I’m 
worrying about seeing some mechanisms that ensure the DataGraph closure in 
memory.

Let 
me try to develop this point…

If a 
user adds an object in the graph, I suppose that the implementation will  
automatically ensure that the object will be added to the orphans if it has no 
container. If it is not done in that way I don’t see why the orphan properties 
are not only added at serialization time.

 

If I 
understand correctly we have three approaches :

1-     
The 
user defines the orphans properties in its Types if there is no real DataGraph 
envelope.

2-     
The 
user has nothing to do if there is a DataGraph containing the Orphans. I’m not 
sure about that, I think your answers to the previous questions will help 
me…

3-     
If 1 
or 2 are not enough, then the implementation will add the Technical 
Root.

 

Having 
these three approaches could be a good point but it will lead to produce 
slightly different XMLs depending on the data graph structure to 
serialize.

</Christophe>

 

1.  
Define the type {commonj.sdo}TechnicalRoot as Frank has described it, with 2 
properties, a "businessRoot" and an "orphans" property.

 

2.  
The TechnicalRoot is specially treated during parsing (ie, 
XMLHelper.load):  it does not appear in the resulting XMLDocument.  It 
is simply an artifact of XML (de-)serialization.

 

3.  
Before serializing to XML, the various XMLHelper.save methods must first assure 
that the data graph is closed.  If it is not closed, the serialization 
mechanism must insert a technical root object as the root node of the graph 
before serializing it.

 

<Christophe> 

Agree 
with the three statements as a definition of technical 
root.

</Christophe>

 

Like I 
said, I think it would be good (and I think, it's doable) to resolve SDO-124 
next week.  Can I ask everyone to spend a few cycles evaluating the 
proposals, bringing forward issues.  It's also OK to send an email saying 
if a solution is satisfactory... this gives me an idea of how far we are from 
reaching consensus.

 

 

Thanks,

Ron

 

 

 

 

Von: Christophe 
Boutard [mailto:] 
Gesendet: Dienstag, 
29. April 2008 22:24
An: Barack, Ron; 

Betreff: RE: [sdo] RE: Spam detected by the 
Fortinet Antispam RE: [sdo] ISSUE 124: Proposal

Hi Ron,

 

Here are my comments 
inline...

 

-----Message d'origine-----
De : Barack, Ron 
[mailto:] 
Envoyé : mardi 29 avril 2008 
19:28
À : Christophe Boutard; 
Objet : 
AW: [sdo] RE: Spam detected by the Fortinet Antispam RE: [sdo] ISSUE 124: 
Proposal

 

Hi Christophe,

 

Drawing a distinction between "the role of Containment in 
the DataGraph Closure and the concept of Composition" sounds very interesting, 
but I'm not at all sure what exactly you are suggesting.  What API changes 
are you thinking about?  Would containment no longer be used in generating 
XML?

 

<Christophe> 

I’m not thinking 
about API modifications but mainly in clarifying things.

 

Let me try to 
elaborate…

1.    
From my point of view a DataGraph is a set of interconnected DataObjects by 
Containment or Non Containment. At this point the containment is nothing more 
than a specific kind of relationship. It does not participate to the DataGraph 
definition

2.    
Then Containment itself should be defined as composition.

3.    
Finally from the XML serialization point of view, the concept of DataGraph 
closure should be introduced. But only at this point in order to maintain the 
Data Model and its XML serialized format totally decoupled. This closure can 
rely on Containment and the orphans management has to be integrated in order to 
ensure a tree based structure because we are dealing with 
XML.

</Christophe>

 

Whether or not surfacing the orphans through the API is a 
bug or a feature is a matter of taste.  As with ChangeSummary, I imagine 
the most common case to be that the user packs his data objects inside of a 
{commonj.sdo}DataGraph, and since DataGraph has an orphans property, the user 
will never have to  worry about whether the graph is closed.  In this 
case, I don't think it's intrusive to say that DataGraph has an orphans property 
that is accessible through the API... In fact, there could be use-cases for it 
(though none come to mind right now, other than some sort of error 
checking).

 

<Christophe>

I think I got your 
point  but I’m not comfortable with a concept which introduces something (I 
mean some properties) without any meaning in the business model represented by 
the SDO Types. As said in my previous email we have to be careful because having 
this kind of orphan Properties always present in each DataGraph could lead us to 
problems when trying to create relationships between two 
DataGraphs.

But I’m interested 
in concrete use cases for that but basically if we consider that a user has to 
choose between “containment” and “non containment” for a relationship, I think 
that he should only be focused on the semantic aspect of that choice which is 
“composition or not”.

I may be wrong but 
currently I think these use cases will be more technical than business oriented 
and in consequence the orphans management should be 
hidden.

</Christophe>

 

I'm not sure that any of the proposals has any solution 
for managing references that are unresolved within a graph, but resolvable in 
some larger context.  For that, we need a concept of identity.  We 
also need to be able to choose between whether we serialize object or their 
Ids.  Please see the 4th and 5th paragaphs of 
http://www.oasis-open.org/apps/org/workgroup/sdo/email/archives/200804/msg00069.html 
for an idea of how SDO-66 (together with SDO-125 and SDO-128) could maybe help 
here.

 

<Christophe>

I really like the 
idea of having KeyTypes compatible with Types in order to represent a kind of 
“Hollow” DataObjects. Now from a DAS point of view I’ve planned to start ASAP a 
discussion in order to distinguish the difference between “null” and “not 
loaded” which means when you call myDO.get(“aDataObjectProperty”) and you get 
null, does it mean that the property is "loaded and null" or just "not loaded". 
It seems to be again a new reason for being synchronized between DAS and SDO 
TCs.

</Christophe>

 

Best Regards,

Ron

   

 

-----Ursprüngliche Nachricht-----

Von: Christophe Boutard 
[mailto:] 

Gesendet: Dienstag, 29. April 2008 16:31

An: 

Betreff: [sdo] RE: Spam detected by the Fortinet Antispam 
RE: [sdo] ISSUE 124: Proposal

 

Hi all,

 

Due to OASIS membership issues, Xcalia members were 
temporarily unable to post on and receive messages from the SDO3 mailing list 
since mid past week.

 

Now everything has been fixed, and I'll try to provide 
some points we wanted to make about the containment issue.

 

First from a pure TechnicalRoot point of view, I really 
like Frank's proposal which make the TechnicalRoot more generic and so more easy 
to standardize.

Just as a quick reminder because his email has been sent 
one week ago, I paste here his XSD proposal :

<xsd:complexType 
name="TechincalRoot">

    <xsd:sequence>

      <xsd:element 
name="buisinessRoot" type="xsd:anyType" minOccurs="1" maxOccurs="1" 
/>

      <xsd:element 
name="orphans" type="xsd:anyType" minOccurs="0" maxOccurs="unbounded" 
/>

    </xsd:sequence>

  </xsd:complexType>

 

  <xsd:element name="xmlDataGraph" 
type="TechnicalRoot"/>

 

From our point of view, this proposal is a very good one 
and we do not have particular reasons for having a "per type" list of orphans 
except the following example:

Suppose that a Company has 10000 Employees by non 
containment. These two employees share the same Address by non 
containment.

Then the produced XML will be:

<xmlDataGraph>

    <businessRoot 
xsi:type="tns:Company"

      
<name>Company1</name>

      
<employees>Employee1</employees>

      
<employees>Employee2</employees>

      ...

      
<employees>Employee10000</employees>

    </businessRoot>

    <orphans 
xsi:type="tns:Employee">

      
<name>Employee1</name>

      
<address>Address1</address>

    </orphans>

    <orphans 
xsi:type="tns:Employee">

      
<name>Employee2</name>

      
<address>Address1</address>

    </orphans>

      ...

    <orphans 
xsi:type="tns:Employee">

      
<name>Employee10000</name>

      
<address>Address1</address>

    </orphans>

 

    <orphans 
xsi:type="tns:Address">

      
<street>Address1</street>

    </orphans>

  <xmlDataGraph>

 

Now assume that a modification is made on the Address1 
instance. The ChangeSummary will reference it but having all the orphans stored 
at the same level will lead to check the 10000 employees in order to locate the 
Address. I'm not sure this a SDO specific problem (it may be more a XML parser / 
XPath / SDO implementation issue) but it may raise a performance 
issue.

 

 

Second point concerns a remark from Blaise saying that the 
TechnicalRoot does not address the following use case where TypeA has a 
containment property to TypeB and where we want to have B as the document 
Root.

Indeed the TechnicalRoot is not (currently) able to deal 
with that use case for the following reason: We assume that containment 
relationships are there for defining a "Composition" which means (IMO) that the 
instance of Type B is only reachable from its parent.

I think that the Oracle's proposal also consider contained 
object with the same semantic and for that reason I'm a little bit lost by a use 
case which consider a non identifiable object as a root.

 

 

Now I'm back to the last proposal made by Ron (on 
SDO-124)...

 

First, the good point is that it seems to allow everyone 
to produce any kind of XML but based on Xcalia's TechnicalRoot implementation 
experience, I'm a bit worrying to see that the concept of "orphan properties" 
accessible from the API.

 

As I said in our last document and during the F2F meeting, 
our first TechRoot implementation was still visible for the users. We 
encountered lots of problems when trying to merge data graphs (e.g. create 
references from a datagraph to another) and mainly issues to maintain the 
different "orphans" lists (not only data but also information relative to change 
summaries).

 

I would like to spend more time thinking about use cases 
based on Ron's proposal and summarize up the Xcalia point of 
view.

 

The first thing for us is to clarify the "containment" 
definition which may imply a clean distinction  between the role of 
Containment in the DataGraph Closure and the concept of 
Composition.

We believe that the Containment should only be used for 
the second role.

IMO, this point is very well explained in Blaise's 
proposal.

 

Then the second point consists in being able to serialize 
a non closed graph. For this particular point, I think whatever the solution is 
(Blaise's proposal, Ron's, TechRoot, a combination of all) the main point is to 
consider the solution as an artifact for serialization and not an evolution of 
the SDO model.

 

In consequence users should not be aware of this technical 
things and again (IMO) do not have to define themselves the orphan 
properties.

 

Best Regards,

--Christophe

 

-----Message d'origine-----

De : Radu Preotiuc-Pietro [mailto:] 

Envoyé : mardi 29 avril 2008 03:11

À : ; 


Objet : Spam detected by the Fortinet Antispam RE: 
[sdo] ISSUE 124: Proposal

 

This is a very interesting proposal. Obviously I like the 
aspect of

having DataGraph take on the extra duties. Two 
comments:

 

1) I think this "sdo:orphan" property is still special: 
even if one can

only get it, still, this get is different than the normal 
SDO get which

simply returns the reference. In this case, get() will 
involve building

the closure of the tree starting at the node the method is 
called on,

because between any two calls, the set of orphans might 
change. That's

not necessarily a show-stopper, but it's still "special 
behavior", even

compared with getChangeSummary().

 

2) I am wondering if we should also have the restriction 
that the type

of the property must be "DataObject", so that we can use 
xsi:type to

transmit the type information for the orphans. I don't 
think we need the

element names for the orphans, but the types we probably 
do.

 

Radu

 

> -----Original Message-----

> From:  [mailto:] 

> Sent: Monday, April 28, 2008 4:40 PM

> To: 

> Subject: [sdo] 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

> 

 

Notice:  This email message, together with any 
attachments, may contain information  of  BEA Systems,  
Inc.,  its subsidiaries  and  affiliated entities,  that may 
be confidential,  proprietary,  copyrighted  and/or legally 
privileged, and is intended solely for the use of the individual or entity named 
in this message. If you are not the intended recipient, and have received this 
message in error, please immediately return this by email and then delete 
it.

 

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the 
OASIS TC that

generates this mail.  You may a link to this group 
and all your TCs in OASIS

at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

 

 

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the 
OASIS TC that

generates this mail.  You may a link to this group 
and all your TCs in OASIS

at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php