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

["Christophe Boutard" <christophe.boutard@xcalia.com>]

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:radup@bea.com] 
Envoyé : mardi 29 avril 2008 03:11
À : ron.barack@sap.com; sdo@lists.oasis-open.org
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: ron.barack@sap.com [mailto:ron.barack@sap.com] 
> Sent: Monday, April 28, 2008 4:40 PM
> To: sdo@lists.oasis-open.org
> 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