OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: AW: [sdo] ISSUE 124: Another attempt


Hi Ron,

It appears to be a fair compromise, and something Oracle would be in 
favour of.

As an extension, it looks like there may be potential for allowing 
multiple orphan properties on a Type.  Then you could could have one 
orphan holder for the Address type, another for PhoneNumber type etc.  
This would allow for even more organization and not always require the 
xsi:attribute in the XML serialization.

   DataObject type = dataFactory.create("commonj.sdo","Type");
   type.set("name","holderType");

   Property p = typeHelper.getOpenContentProperty("commonj.sdo/xml","orphanHolder");

   DataObject property1 = dataFactory.create("commonj.sdo","Property");
   property1.set(p,true);
   property1.set("name,"phone-number-orphans");
   property1.set("multivalued",true);
   property1.set("type",typeHelper.get("my.namespace","PhoneNumber");
   type.getList("property").add(property1);

   DataObject property2 = dataFactory.create("commonj.sdo","Property");
   property2.set(p,true);
   property2.set("name,"address-orphans");
   property2.set("multivalued",true);
   property2.set("type",typeHelper.get("my.namespace","Address");
   type.getList("property").add(property2);


-Blaise

Barack, Ron wrote:
> Hi Blaise,
>
> As an XSD annotation, it's exactly as in your proposal:  Frank puts it in the "commonj.sdo/xml" namespace, and calls it "orphanHolder" not "orphans", but these are really trivial details.
>
> I don't like defining features that are only available through XML, so I'd like to see the equivalent functionality through the API.  This should be more or less automatic.  By defining a global attribute in SDO's schema, we are implicitly defining it as a OpenContentPropery, that is registered in all TypeHelpers.  That is, typeHelper.getOpenContentProperty("commonj.sdo/xml","orphanHolder") returns a boolean property.
>
> The effect of setting this property (to true), before calling TypeHelper.define(DataObject type) must be exactly the same as annotating the XSD.
>
> I would say this annotation is possible only on properties that are multivalued, and where dataType=false.
>
> So, through the API, an orphanHolder property is declared as follows:
>
>    DataObject type = dataFactory.create("commonj.sdo","Type");
>    type.set("name","holderType");
>    DataObject property = dataFactory.create("commonj.sdo","Property");
>    Property p = typeHelper.getOpenContentProperty("commonj.sdo/xml","orphanHolder");
>    property.set(p,true);
>    property.set("name,"orphans");
>    property.set("multivalued",true);
>    property.set("type",typeHelper.get("commonj.sdo","DataObject");
>    type.getList("property").add(property);
>    ...
>    Type.getList("property").add(businessRootProperty);
>    ...
>    Type holderType = typeHelper.define(type);
>
> I hope the behavior of "holderType" during marshalling and unmarshalling is clear.  The question is, what do we get when introspecting "holderType" (or objects instanciating this type) through the API?  The current proposal is that the "orphans" property is invisible.  That is, the "orphans" property does not turn up in the list holderType.getProperties(), or in the instance properties of any object with type "holderType".
>
> Conceptually, I think this is all more or less along the lines of your proposal, the main difference is only in that types with orphan properties are defined by the user (or by the spec, in the case of DataGraph), rather than being derived through inspection of the metadata.
>
> Does that answer your questions?
>
> Ron
>
>    
>
>
> -----Ursprüngliche Nachricht-----
> Von: Blaise Doughan [mailto:blaise.doughan@oracle.com] 
> Gesendet: Montag, 12. Mai 2008 11:05
> An: Christophe Boutard; sdo@lists.oasis-open.org
> Cc: Barack, Ron; François Huaulmé
> Betreff: Re: [sdo] ISSUE 124: Another attempt
>
> Could someone demonstrate the current proposal?  We (Oracle) would like 
> to see an example of how the orphanHolder metadata is specified (both as 
> an annotated XSD with XSDHelper and as DataObjects with TypeHelper).
>
> -Blaise
>
> Christophe Boutard wrote:
>   
>> Hi Ron, all,
>>
>> The current proposal about orphanHolder annotations for data graphs (as opposed to DataGraphs) sounds good to us.
>>
>> Thanks,
>> --Christophe
>>
>>
>> -----Message d'origine-----
>> De : Barack, Ron [mailto:ron.barack@sap.com] 
>> Envoyé : lundi 12 mai 2008 15:59
>> À : François Huaulmé; sdo@lists.oasis-open.org
>> Objet : AW: [sdo] ISSUE 124: Another attempt
>>
>> Hi Francois,
>>
>> Does your better understanding of orphanHolder annotations influence in anyway your rejection of them, and your preference for allowing this functionality only on the DataGraph type?
>>
>> Three companies (IBM, SAP, BEA) have already expressed a preference for having the annotation.  But the issue is so important, that I think it's important to have a strong concensus for the solution, for it to be something that we can all support.
>>
>>
>> Ron
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: François Huaulmé [mailto:francois.huaulme@xcalia.com] 
>> Gesendet: Freitag, 9. Mai 2008 09:22
>> An: sdo@lists.oasis-open.org
>> Betreff: RE: AW: [sdo] ISSUE 124: Another attempt
>>
>> Hi Ron,
>>
>> I think I better understand now the use of orphanHolder annotations. The eventual "orphan" property of a DataGraph would be annotated as "orphanHolder" (which is basically what Frank wrote, I wasn't sure of the context).
>> So if I got this  right, one could use straight XML and add SDO annotations to its graph in order to get closure, but without using the DataGraph "envelope"?
>>
>> There is no actual concern about the root object: we wanted to point out to the group that -if containment means composition- having a contained root object somewhat hurts our definition of containment :). As I said, this concern is more related to containment than to the XML structure of the DataGraph. This discussion about contained objects as root elements is maybe on the wrong mail thread and we might need to start a new thread for this.
>>
>> Thanks,
>>
>> --François.
>>
>> -----Message d'origine-----
>> De : Barack, Ron [mailto:ron.barack@sap.com] 
>> Envoyé : vendredi 9 mai 2008 17:59
>> À : François Huaulmé; sdo@lists.oasis-open.org
>> Objet : AW: AW: [sdo] ISSUE 124: Another attempt
>>
>> Hi Francois,
>>
>> The use case for orphanHolder properties is that you want to sent a data graph (as opposed to a DataGraph) and you want to go to closed XML, but you don't want your document to include a ChangeSummary or any metadata.  Or maybe you want closure, and change summary and no metadata.  By defining "orphans" seperate from DataGraph, we give users this ability. 
>>
>> Would your concerns about the root object of the data graph stop you from supporting the current proposal?
>>
>> Ron
>>
>> -----Ursprüngliche Nachricht-----
>> Von: François Huaulmé [mailto:francois.huaulme@xcalia.com] 
>> Gesendet: Freitag, 9. Mai 2008 07:34
>> An: sdo@lists.oasis-open.org
>> Betreff: RE: AW: [sdo] ISSUE 124: Another attempt
>>
>> Hi,
>>
>> The discussion about root element of a graph was lead by our maybe-biased-definition of containment. If containment is defined as UML composition, then "2" does not exist without "1".
>>
>> We did not say that an instance of 2's type cannot be a root element of the datagraph. You can still create an 2 instance using the DataFactory and then use it as the root element of your graph (getContainer() returns null there). But if "2" is "contained", then it sounds - from our point of view - odd to consider this object as root element.
>> In a DataDirect's DAS context, containment (UML composition) would imply that "2" is not directly accessible without "1". You need to get "1" in order to get "2".
>> Now, for updates, consider we need to create a graph to update "2". If "2" has a container (getContainer() != null) then (IOO) "1" has to be included in the graph (if "2"'s identity is only defined by its relationship to "1").
>>
>> This was the motivation behind the point we wanted to add to this discussion. It still relates to the containment discussion, though it is not directly related to the XML graph structure.
>>
>> Following Frank's proposal of "orphanHolder" annotations, we think we may need examples to fully understand the proposal. We were quite ok with Frank's original proposal, so we are interested in the reasons for this annotation.
>>
>> Thanks,
>>
>> --François.
>>
>> -----Message d'origine-----
>> De : Radu Preotiuc-Pietro [mailto:radup@bea.com] 
>> Envoyé : jeudi 8 mai 2008 21:29
>> À : sdo@lists.oasis-open.org
>> Objet : RE: AW: [sdo] ISSUE 124: Another attempt
>>
>> Hello,
>>
>> IMO, the 2.1 spec is clear that the root of the serialized document is "2":
>>
>> save(DataObject dataObject, String rootElementURI, String rootElementName)
>> returns the DataObject saved as an XML document with the specified root
>> element.
>>
>> It refers to "the DataObject" rater than "the root of the data graph containing the DataObject". I think that serializing the root would be surprising to the user; he/she can achive that effect by calling save() on dataObject.getRootObject().
>>
>> Now of course somebody may claim that serialization of orphans is inconsistent with serialization of the "main" tree, but for orphans I don't think we have a choice (unless we want to potentially duplicate the orphans).
>>
>> So I agree with this proposal; I would have also preferred the orphans property not be "special" (the same way that the change summary property is not special, it's exactly the same thing), but I thought we ruled this out in the May-06 meeting.
>>
>> Radu
>>
>>   
>>     
>>> -----Original Message-----
>>> From: Frank Budinsky [mailto:frankb@ca.ibm.com] 
>>> Sent: Wednesday, May 07, 2008 9:59 AM
>>> To: sdo@lists.oasis-open.org
>>> Subject: Re: AW: [sdo] ISSUE 124: Another attempt
>>>
>>> Hi guys,
>>>
>>> I agree that we need to clarify the question about what is 
>>> the root (1 or
>>> 2) in this example.
>>>
>>> I like the proposal, but wonder if instead of just saying 
>>> that the orphan element in Type {commonj.sdo}DataGraph has 
>>> this special serialization behavior, we could create a new 
>>> annotation, e.g., {commonj.sdo/xml}orphanHolder, which can be 
>>> used anywhere to get this special behavior using any suitable 
>>> user-defined property.
>>>
>>>     <xsd:element name=?orphans? type=?xsd:anyType? 
>>> sdox:orphanHolder="true" minOccurs=?0? maxOccurs=?unbounded?/> 
>>>
>>> Frank.
>>>
>>>
>>>
>>>
>>> "Barack, Ron" <ron.barack@sap.com>
>>> 05/07/2008 12:25 PM
>>>
>>> To
>>> "Christophe Boutard" <christophe.boutard@xcalia.com>, 
>>> <sdo@lists.oasis-open.org> cc
>>>
>>> Subject
>>> AW: [sdo] ISSUE 124:  Another attempt
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hi Christophe,
>>>  
>>> The first part of your question is maybe something that 
>>> should be addressed in the JSR 235 group, it seems to be 
>>> unclear in the spec.  I would have expected that the object 
>>> provided by the user is the data graph's root object (or the 
>>> child of the root object, if you consider the 
>>> wrapper supplied by data graph).   I would have expected the 
>>> business root 
>>> is contained by the DataGraph, effectively detached from your 
>>> node "1".
>>>  
>>> Whether "1" should be serialized is somewhat orthogonal to 
>>> the rest of the discussion.  I would say that 3.0 should be 
>>> consistent with 2.1.1.
>>>  
>>> For the orphan object, yes, this is exactly what I am saying. 
>>>  The actually "orphan" is node "5".  Node "7" is serialized 
>>> only as a part of serializing node "5".
>>>  
>>> Ron
>>>
>>> Von: Christophe Boutard [mailto:christophe.boutard@xcalia.com]
>>> Gesendet: Mittwoch, 7. Mai 2008 09:12
>>> An: Barack, Ron; sdo@lists.oasis-open.org
>>> Betreff: RE: [sdo] ISSUE 124: Another attempt
>>>
>>> HI Ron, everyone,
>>>  
>>> First of all your proposal sounds good to us.
>>>  
>>> I?ve added a picture to this email in order to be sure of the 
>>> expected behavior when you pack objects into a data graph.
>>>  
>>> So here is the scenario:
>>>  
>>> I would like to pack my data into a data graph and the object 
>>> provided by the user is ?2?.
>>>  
>>> I expect that ?1? will be considered as the business root 
>>> because it is the container of ?2?.
>>>  
>>> Then ?4? will be added to the orphans list.
>>>  
>>> It should be the same for ?5? even if the referenced object 
>>> is ?7?. The thing is that ?7? is referenced by containment 
>>> and should not be considered as orphan.
>>> In that case we have to retrieve the first object without 
>>> container and mark it as orphan. In our case it is ?5?.
>>>  
>>> I hope everything is clear?
>>>  
>>> Thanks,
>>> --Christophe
>>>  
>>>
>>>  
>>> De : Barack, Ron [mailto:ron.barack@sap.com] Envoyé : 
>>> mercredi 7 mai 2008 16:34 À : sdo@lists.oasis-open.org Objet 
>>> : [sdo] ISSUE 124: Another attempt
>>>  
>>> Hi Everyone,
>>> In Tuesday's call there seemed to be some consensus that performing a
>>> XMLHelper.save() operation using a {commonj.sdo}DataGraph as 
>>> an argument should never throw a GraphNotClosed exception.  
>>> That is, DataGraph should act as a technical root, and any 
>>> orphans referenced but not contained in the DataGraph?s 
>>> business root should be serialized as children of the DataGraph. 
>>> I've been looking at trying to make a proposal out of this.  
>>> It seems to me the most natural place to describe this 
>>> behavior is in Chapter 12, which deals specifically with the 
>>> XML serialization of DataGraphs.
>>> I would like to add the following paragraph at line 3424 
>>> (based on the word document 
>>> http://www.oasis-open.org/apps/org/workgroup/sdo/download.php/
>>> 26863/OASIS%20SDO%20For%20Java%20Spec.doc
>>> )
>>> ________
>>> The serialization of a DataGraph, whether invoked through a 
>>> DAS or java.io.Serializable or in a Web service, includes the 
>>> transitive closure of all DataObjects reachable from the 
>>> DataGraph?s root object, whether or not the DataObject are 
>>> contained, directly or indirectly, by the root DataObject.  
>>> DataObjects that are referenced but not contained must be 
>>> included in the ?orphan? elements that are part of the 
>>> DataGraphs XML representation.  Each ?orphan? element is 
>>> serialized as part of the containment tree in which it is 
>>> located, and any DataObjects referenced but not contained in 
>>> this tree must also be included among the DataGraph?s 
>>> orphans, so that the transitive closure is obtained.  
>>> References to orphaned DataObjects follow the normal rules of 
>>> XML serialization.  The serialization of a DataGraph never 
>>> throws an exception because the graph is not closed.
>>> ____________________
>>> The XSD at the end of the chapter would also need to be modified: 
>>>   <xsd:complexType name="BaseDataGraphType" abstract="true"> 
>>>     <xsd:sequence> 
>>>       <xsd:element name="models" type="sdo:ModelsType" 
>>> minOccurs="0"/> 
>>>       <xsd:element name="xsd" type="sdo:XSDType" minOccurs="0"/> 
>>>       <xsd:element name="changeSummary" 
>>>                    type="sdo:ChangeSummaryType" minOccurs="0"/> 
>>>       <xsd:element name=?orphans? 
>>>                    Type=?xsd:anyType? minOccurs=?0? 
>>> maxOccurs=?unbounded?/> 
>>>     </xsd:sequence> 
>>>     <xsd:anyAttribute namespace="##other" processContents="lax"/>
>>>   </xsd:complexType>
>>> ______________________
>>> Another small change will have to be made around line 3407, 
>>> but this is mainly editorial, and can be left to the editors.
>>> __________________________
>>> You might notice in the above text that not only is the 
>>> orphaned DataObject itself serialized, but also the complete 
>>> containment tree in which the object is located.  I think 
>>> this is necessary: first of all, because an object reachable 
>>> through getContainer() is non-the-less reachable, and 
>>> otherwise we don't really have transitive closure.  More 
>>> pragmatically, I think it will otherwise be very difficult to 
>>> create the URIs that reference the objects in any efficient 
>>> manner?suppose the reference to a leaf is found first, then 
>>> later a reference to the root.
>>> Of course, I'd agree to this proposal as a compromise, but I 
>>> do want to point out what we are losing by declaring this 
>>> functionality on DataGraph, rather than creating a new kind 
>>> of property, which DataGraph happens to have.  With this 
>>> proposal, DataGraph contains ChangeSummary, XSD, the business 
>>> object, and now orphans,  If we want to create a new type of 
>>> container, eg, with only orphans, we cannot do it.  The 
>>> functionality is specific to DataGraph.  It seems to me 
>>> allowing users to define such types is not a bad thing.  
>>> Effectively, that is the only difference between last week's 
>>> proposal and this one.
>>> Best Regards,
>>> Ron 
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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_workgr
>>> oups.php 
>>>
>>>
>>>     
>>>       
>> 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 
>>
>>
>> ---------------------------------------------------------------------
>> 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 
>>
>>
>> ---------------------------------------------------------------------
>> 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 
>>
>>   
>>     
>
> ---------------------------------------------------------------------
> 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 
>
>   


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]