[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sdo] Re: Comments on Blaises Proposal
Hi Blaise, OK, that makes a little more sense, but I still can't see how this can possibly work. I think the case where Y is a containment reference is the more common case. Let's say that Y = Department. and Department has a (one-way) containment reference to Employee. With your model, there is no way you could add an address to an Employee that's in some Department, because of the reverse containment reference. Another problem is if there are two tables with the PK,FK joins, for example, a PERFORMANCE_EVALUATION table. With your design, there would be another bidirectional containment reference between Types Employee and PerformanceEvaluation. As a result, it would be impossible to set both the address and evaluation properties of an Employee. Frank "Blaise Doughan" <blaise.doughan@oracle.com> 04/10/2008 04:07 PM To <sdo@lists.oasis-open.org> cc Subject Re: [sdo] Re: Comments on Blaises Proposal Hi Frank, You are correct, the examples from the email broke the containment rules which exist in both SDO 2.1 and my proposal where an instance of a DataObject is only able to referenced through one containment property. My intent for the example was to prevent both Address and Employee from being the root type. If it helps, below are the corrected examples: Example #1 We all agree on employee having a containment relationship to address. X --non-containment--> EMPLOYEE --containment--> ADDRESS <x> <employee> <address>...</address> </employee> </x> Example #2 My proposal allows the opposite property from Address to Employee to also be containment. Again containment refers to the data sharing rules. Using the data sharing rules an Address object can be marshalled as follows. Y --non-containment--> ADDRESS --containment --> EMPLOYEE <y> <address> <employee>...</employee> </address> </y> Example #3 Your argument is that the Address type can not have the opposite property to Employee be containment. With this restriction in the resulting XML employee data could not be nested within address data. This also forces employee to have a key that address can make use of to represent the non-containment relationship. Y --non-containment--> ADDRESS --non-containment --> EMPLOYEE <y> <address employee="1">...</address> <employee id="1">...</employee> </y> -Blaise ----- Original Message ----- From: "Frank Budinsky" <frankb@ca.ibm.com> To: <sdo@lists.oasis-open.org> Sent: Thursday, April 10, 2008 3:41 PM Subject: Re: [sdo] Re: Comments on Blaises Proposal Blaise, A = Y B = EMPLOYEE C = ADDRESS So, "instances of Type Y & EMPLOYEE may not share a reference to an instance of Type ADDRESS through those containment properties" implies this is invalid: Y --containment--> ADDRESS --containment --> EMPLOYEE because the inverse of "ADDRESS --containment -> EMPLOYEE" is also a containment reference, so EMPLOYEE and Y would be sharing the ADDRESS through containment properties. Or is there some other special rule that I'm missing? Frank "Blaise Doughan" <blaise.doughan@oracle.com> 04/10/2008 01:20 PM To <sdo@lists.oasis-open.org> cc Subject Re: [sdo] Re: Comments on Blaises Proposal Hi Frank, I have responded to your comments below: [Frank] For your Example #2, below: > Y --containment--> ADDRESS --containment --> EMPLOYEE This would not be possible with your model because the EMPLOYEE -> ADDRESS reference is also containment, so you could not have the Y-containment reference also pointing to the ADDRESS (it breaks the exclusivity/ownership rule of containment). [Blaise] The three examples from my previous email were meant to be seperate and distinct from each other. The following rule always applies: Types A & B may have containment properties to Type C, but instances of Type A & B may not share a reference to an instance of Type C through those containment properties. [Frank]Also, you say: > Your argument is that the Address type can not have the opposite property to Employee be containment. With this restriction in the resulting XML employee data could not be nested within address data. Why not? This is exactly how your algorithm serializes the non-containment "contact" reference (from PhoneNumber to Employee) in Example #3 of your proposal document. Your algorithm consolidates non-conainment references and orphans. What's different about this case? [Blaise] The only place where non-containment and orphans can be consolidated is in the complex type corresponding to the root type (during schema generation). I added the types X & Y into the example in an attempt to clarify this point. The examples in the email below do not correspond to a different algorithm, they just have different root types. -Blaise ----- Original Message ----- From: "Frank Budinsky" <frankb@ca.ibm.com> To: <sdo@lists.oasis-open.org> Sent: Thursday, April 10, 2008 10:26 AM Subject: Re: [sdo] Re: Comments on Blaises Proposal Hi Blaise, Maybe the light just hasn't gone on yet, but my head is really starting to hurt :-) For your Example #2, below: > Y --containment--> ADDRESS --containment --> EMPLOYEE This would not be possible with your model because the EMPLOYEE -> ADDRESS reference is also containment, so you could not have the Y-containment reference also pointing to the ADDRESS (it breaks the exclusivity/ownership rule of containment). Also, you say: > Your argument is that the Address type can not have the opposite property to Employee be containment. With this restriction in the resulting XML employee data could not be nested within address data. Why not? This is exactly how your algorithm serializes the non-containment "contact" reference (from PhoneNumber to Employee) in Example #3 of your proposal document. Your algorithm consolidates non-conainment references and orphans. What's different about this case? Frank "Blaise Doughan" <blaise.doughan@oracle.com> 04/09/2008 04:52 PM To <sdo@lists.oasis-open.org> cc Subject Re: [sdo] Re: Comments on Blaises Proposal Hi Frank. To be clear my proposal asks that the following existing API all be allowed to return true wrt the example model: employeeType.getProperty("residence").isContainment() == true; employeeType.getProperty("residence").getOpposite().isContainment() == true; addressType.getProperty("resident").isContainment() == true; addressType.getProperty("resident").getOpposite().isContainment() == true; The above truly reflects the data sharing rules. The data sharing rules are very useful for determing how data can be written to XML, I will demonstrate with the following examples. Example #1 We all agree on employee having a containment relationship to address. X --containment--> EMPLOYEE --containment--> ADDRESS <x> <employee> <address>...</address> </employee> </x> Example #2 My proposal allows the opposite property from Address to Employee to also be containment. Again containment refers to the data sharing rules. Using the data sharing rules an Address object can be marshalled as follows. Y --containment--> ADDRESS --containment --> EMPLOYEE <y> <address> <employee>...</employee> </address> </y> Example #3 Your argument is that the Address type can not have the opposite property to Employee be containment. With this restriction in the resulting XML employee data could not be nested within address data. This also forces employee to have a key that address can make use of to represent the non-containment relationship. Y --containment--> ADDRESS --non-containment --> EMPLOYEE <y> <address employee="1">...</address> <employee id="1">...</employee> </y> The reason I am proposing that a property and its opposite property can be containment is because it reflects the data sharing rules. Data sharing rules are useful because they allow a better XML representation. Example #2 is better than example #3 (as example #3 requires a key that truly isn't necessary). -Blaise ----- Original Message ----- From: "Frank Budinsky" <frankb@ca.ibm.com> To: <sdo@lists.oasis-open.org> Sent: Tuesday, April 08, 2008 9:14 PM Subject: Re: [sdo] Re: Comments on Blaises Proposal Hi Blaise, You said: > In the relational database example two tables that related to one another because the primary key is also the foreign key would result in a bidirectional containment relationship. Absolutely, I agree, but a bidirectional containment relationship is a containment reference in only one direction. The inverse of the containment reference is NOT also a containment reference, it's an explicit (named) "container" reference. Looking at your EMPLOYEE and ADDRESS tables, it seems clear to me that the containment reference is from Employee to Address. The ADDRESS table has a FK to the EMPLOYEE table which says there is a 1-1 relationship where ADDRESSES can't exist without a corresponding EMPLOYEE. Therefore, Employees would own Addresses in the logical model. The "residence" containment reference is exactly what I would expect, and that's even what you say on page 20. Now, I understand that you can take this a step further (especially when you bring JPA into the picture) to say that the logical model's reference is bidirectional with an explicit inverse named "resident". But, that should be the end of story - you've defined a bidirectional containment reference. What I don't understand is why you need to take this a step further and also say that you need a new kind of special relationship where both ends are containment - "bi-containment" as opposed to "bi-directional containment". That's the part I just don't understand, and it sounds like maybe others are also confused by? Frank "Blaise Doughan" <blaise.doughan@oracle.com> 04/08/2008 05:02 PM To <sdo@lists.oasis-open.org> cc Subject Re: [sdo] Re: Comments on Blaises Proposal Hi Frank, The proposal is based on the premise that it is a worthy endeavor to derive SDO metadata from sources like (relational databases and JPA entities) in addition to XML schema. At this point I'm not 100% sure we agree on this premise. My document demonstrates that bi-directional containment relationships exist in the world (atleast in relational databases and JPA), as such the proposal introduces bi-directional containment to SDO. I have responded to your points below: [Frank]The EMOF definition is exactly the same except for the part about bidirectional composition, which I think is conceptual nonsense and needs to be removed from the proposal. [Blaise] I do not agree that SDO containment equals the EMOF definition of composition. In my examples I have demonstrated that containment relates to things like the JPA OneToOne and OneToMany mappings. The JPA OneToOne mapping is allowed to be bidirectional and is very useful. I have also demonstrated that the underlying database structure represents bi-directional containment. We can continue to debate the definition, but I am more interested in what metadata you would like to see derived from the examples I've provided in my proposal. As soon as you allow containment on both ends of an association, you're guaranteeing containment cycles. By definition, A1.getContainer().getContainer() == A1. Are you proposing that we remove the restriction about containment cycles? [Blaise] Cycles between two objects should be allowed. [Frank]Assuming A1 references E1, what would A1.getRootObject() return - A1 or E1? What about E1.getRootObject()? Why would introducing this kind of complexity be good for SDO? [Blaise] Assuming a bi-directional containment relationship between A1 and E1, then E1.getRootObject() would return A1, and A1.getRootObject() would return E1. The benefit for SDO would be to represent metadata that came from sources other that XML Schema. Also the ability to generate per type XML messages (That all conform to the same data sharing rules). Again assuming that it is a worth while goal to generate SDO metadata from sources like relational databases and JPA entities (useful for a DAS), what metadata would you like to see generated? Note that metadata derived from XML schema would not result in any containment cycles. [Frank]All this aside, I can't even see what criteria one would use for deciding to define such an association. [Blaise] There are two examples in the document that demonstrate when this applies. In the relational database example two tables that related to one another because the primary key is also the foreign key would result in a bidirectional containment relationship. Also in the JPA entity example a bidirectional OneToOne relationship results in a bidirectional containment relationship in SDO. In fact, it seems to me that your algorithm would produce the same results if only the residence reference was containment (i.e., resident was non-containment). Your step #6 seems to be the key. Couldn't a slightly different version of step #5 even do the same thing if neither end of the association were containment, that is, if you say that 1-1 non-containment references to orphans should serialize in place? Even as it is, I think the algorithm would produce resonable serializations, even if the residence-resident association was completely non-containment. [Blaise] It may be confusing because the object model is shallow and the complex type for the root type is converting the reference relationships to nested relationships, adding another object to the model might make things clearer. [Frank] I really can't see why we need to invent a new modeling concept (bidirectional composition) for SDO - that would seem pretty extreme to me. [Blaise] I do not see the extreme aspect to this proposal. None of the APIs change, it simply allows the back pointer of a containment relationship to be containment. It's not a new modeling concept (JPA has this), it's just new to SDO. -Blaise ----- Original Message ----- From: "Frank Budinsky" <frankb@ca.ibm.com> To: <sdo@lists.oasis-open.org> Sent: Tuesday, April 08, 2008 3:51 PM Subject: Re: [sdo] Re: Comments on Blaises Proposal Hi Blaise, The EMOF definition is exactly the same except for the part about bidirectional composition, which I think is conceptual nonsense and needs to be removed from the proposal. As soon as you allow containment on both ends of an association, you're guaranteeing containment cycles. By definition, A1.getContainer().getContainer() == A1. Are you proposing that we remove the restriction about containment cycles? Assuming A1 references E1, what would A1.getRootObject() return - A1 or E1? What about E1.getRootObject()? Why would introducing this kind of complexity be good for SDO? All this aside, I can't even see what criteria one would use for deciding to define such an association. In fact, it seems to me that your algorithm would produce the same results if only the residence reference was containment (i.e., resident was non-containment). Your step #6 seems to be the key. Couldn't a slightly different version of step #5 even do the same thing if neither end of the association were containment, that is, if you say that 1-1 non-containment references to orphans should serialize in place? Even as it is, I think the algorithm would produce resonable serializations, even if the residence-resident association was completely non-containment. I really can't see why we need to invent a new modeling concept (bidirectional composition) for SDO - that would seem pretty extreme to me. Frank "Blaise Doughan" <blaise.doughan@Oracle.com> 04/08/2008 09:45 AM To <sdo@lists.oasis-open.org> cc Subject Re: [sdo] Re: Comments on Blaises Proposal Hi Frank, If the definition I'm proposing for containment matches the one in EMOF that is great. Containment is referred to many times in the SDO spec and factors into many aspects, so I feel there is value in defining it in the SDO spec. If the EMOF definition of composition implies a "part-of" relationship in which a bidirectional composition relationship is not allowed then my definition is new and different since it would allow this. You are correct in that the only possible bi-directional relationship with containment in both directions is a 1-1. This type of relationship is not uncommon in relational databases and is well supported by JPA. -Blaise ----- Original Message ----- From: "Frank Budinsky" <frankb@ca.ibm.com> To: <sdo@lists.oasis-open.org> Sent: Monday, April 07, 2008 5:14 PM Subject: Re: [sdo] Re: Comments on Blaises Proposal Hi Blaise, > 1. A clear definition of what containment is: I think the definition is very clear already. As you pointed out, the spec currently says that containment is the same as EMOF composition. This is a well known concept, the same concept as UML bi-value aggregation, as I said below. Your clarification isn't saying anything new or different. > 3. Allowing both properties involved in a bidirectional relationship to be containment=true. Unless I've missed something, this doesn't work for anything but 1-1 relationships. Assume you have A1 with "resident" (containment) references to E1 and E2. If you also say the E1 to A1 reference ("residence") is a containment reference, rule #1 is already broken (because E2 is also pointing at A1). What am I missing here? Frank. "Blaise Doughan" <blaise.doughan@oracle.com> 04/07/2008 11:19 AM To <sdo@lists.oasis-open.org> cc Subject Re: [sdo] Re: Comments on Blaises Proposal Hi Frank, My proposal contains small changes with a big impact: Clear means of deriving metadata from sources such as relational databases and JPA entities. Multiple compatible XML representations for SDO DataObjects: If you exposed your DAS through a web service you could define your underlying model once and have per type XML messages (see the proposal for examples of this). Full backwards compatibility. What is being proposed is the following: 1. A clear definition of what containment is: "For a property representing a relationship between two types A and B, then the property is considered containment if instances of Type A may not share instances of Type B. In addition Type C may have a containment relationship to Type B, but an instance of A and an instance of C may not both reference the same instance of B through containment relationships." 2. Removing the restriction that each data object must be reachable by containment. This requirement is directly related to the XML representation and this is why the proposal contains a modified algorithm for converting DataObjects to XML. 3. Allowing both properties involved in a bi-directional relationship to be containment=true. This is required when deriving metadata from sources other than XML schema. Below are my responses to your email: [SAP1] How does this differ from the UML concept of aggregation. [Blaise-08/04/03] I guess this depends on your definition of aggregation in UML. The following is the important concept: Containment: employeeDO1.get("residence") == employeeDO2.get("residence"); // This can never be true Non-Containment: employeeDO1.get("residence") == employeeDO2.get("residence"); // This can be true [Frank] My ("the") definition of UML aggregation is "a has-a (whole/part) relationship". [Blaise-08/04/07] My hope was to just use a UML word like aggregation or composition and found it to imprecise. Martin Fowler once wrote, "Aggregation is a part-of relationship. It's like saying that a car has an engine and wheels as its parts. This sounds good, but the difficult thing is considering what the difference is between aggregation and association". And according to Martin Fowler, Jim Rumbaugh has the following to say about aggregation, "Think of it as a modeling placebo". [Frank]Aggregations can either be shared (i.e., a part can be used in more than one aggregations) or exclusive (also known as by-value aggregation or composition). SDO containment is the latter (exclusive aggregation); a part can be used in only one aggregation/container - which is returned by the getContainer() method. Blaise's definition, above, seems to be the same thing. If so, what exactly is the proposed containment change? [Blaise-08/04/07] The SDO 2.1 spec does not clearly define what a containment relationship means. In section "3.6.3 Containment" it comes close by stating the corresponding term in EMOF is called "composite". See my proposed definition of containment at the beginning of this email. [Frank]The only thing that seems different (and very strange, in fact) is the example of an association where both ends have containment=true. Allowing this seems to be fundamentally at odds with the concept - i.e., a part cannot contain its whole. [Blaise-08/04/07] According to my definition above both ends of a containment relationship may have containment=true. I could not find the following requirement related to containment in the SDO 2.1 specification: "a part cannot contain its whole". [Frank]How would we know which is the whole and which is the part, given both can be either according to the metadata? [Blaise-08/04/07] My proposal includes an example of deriving metadata from a relational database. There is a relationship formed between the EMPLOYEE and ADDRESS tables, since they relate to each other by having the same primary key values. In this example we know for each employee there is a unique address, and for each address there is a unique employee. There is no way to know which one is the whole and which is the part. Sounds like you want some new kind of bidirectional relationship that says one end or the other is containment, but the metadata won't say which end. Is that it? If so, how would the DataObject.getContainer() method work? [Blaise-08/04/07] There is no need for a new kind of bidirectional relationship, my proposal is to allow the opposite property to be a containment relationship. getContainer() continues to work as it does today. In my particular example for the relationship between Employee and Address: getContainer for instances of Employee would return an instance of Address, and getContainer for instances of Address would return an instance of Employee: DataObject anAddressDO = anEmployee.get("residence"); anAddress == anEmployee.getContainer(); // return true anEmployee == anAddress.getContainer(); // return true [Frank]Thanks, Frank. -Blaise ----- Original Message ----- From: "Frank Budinsky" <frankb@ca.ibm.com> To: <sdo@lists.oasis-open.org> Sent: Monday, April 07, 2008 12:00 AM Subject: Re: [sdo] Re: Comments on Blaises Proposal Hi Guys, I like the proposed mapping to XSD for models that don't have containment references. However, that said, I really don't understand what change is being proposed for containment here. I think I need a better answer to Ron's question from below: [SAP1] How does this differ from the UML concept of aggregation. [Blaise] I guess this depends on your definition of aggregation in UML. The following is the important concept: Containment: employeeDO1.get("residence") == employeeDO2.get("residence"); // This can never be true Non-Containment: employeeDO1.get("residence") == employeeDO2.get("residence"); // This can be true [Frank] My ("the") definition of UML aggregation is "a has-a (whole/part) relationship". Aggregations can either be shared (i.e., a part can be used in more than one aggregations) or exclusive (also known as by-value aggregation or composition). SDO containment is the latter (exclusive aggregation); a part can be used in only one aggregation/container - which is returned by the getContainer() method. Blaise's definition, above, seems to be the same thing. If so, what exactly is the proposed containment change? The only thing that seems different (and very strange, in fact) is the example of an association where both ends have containment=true. Allowing this seems to be fundamentally at odds with the concept - i.e., a part cannot contain its whole. How would we know which is the whole and which is the part, given both can be either according to the metadata? Sounds like you want some new kind of bidirectional relationship that says one end or the other is containment, but the metadata won't say which end. Is that it? If so, how would the DataObject.getContainer() method work? Thanks, Frank. "Blaise Doughan" <blaise.doughan@oracle.com> 04/04/2008 11:14 AM To <sdo@lists.oasis-open.org> cc Subject [sdo] Re: Comments on Blaises Proposal Hello All, I think this is going to turn out to be a very good discussion on containment :), There are some points in the proposal I would like to draw attention to: 1. Full Backwards Compatibility A number of TC members have made strong cases for backwards compatibility and my proposal supports this. A user defining SDO 2.1 compatible metadata will not see any change in behaviour wrt my proposed changes. 2. Relaxed Containment Requirements The proposal allows for a data graph to have no containment relationships. This reflects the case where SDO metadata is derived from unannotated Java classes/interfaces. Since XML handling is a core part of the spec (XMLHelper, XSDHelper, DataObject serialization), the proposal provides an algorithm to keep these concepts valid. Ron has pointed out that the algorithm can fail, but it fails in the same way as all other XML binding tools. The alternative is to not allow the XML serialization of DataObjects without all the necessary containment which is difficult to determine and is unnecessarily restrictive. 3. DAS The proposal contains an example of deriving SDO metadata from a relational database. XML schemas are then derived wrt different SDO types. I am excited about the idea that the data source metadata could be defined once, and then per type XML messages (one for findAddress, another for findEmployee) could be used each of which reflects the core metadata. Below are my responses to the points raised by Ron's email: [Ron] Much as I like aspects of this proposal, there are several fundamental problems with it. In particular, Blaise's claim that "makes use of containment properties when they are present and handles things when they are not" is false. The fundemtental problem is that what Blaise calls "orphans" can not be determined by analysing the metadata, you have to look at the actual instances. Using the proposed algorithm, it is still possible to generate documents with unresolved references. [Blaise] I do not believe the claim is false. Solving the object-to-XML impedance mismatch requires that each object be reachable by containment, the onus is always on the user to ensure enough containment relationships are in place (this is true in both SDO 2.1 and JAXB 2.0). The algorithm could prevent all broken references by allowing remaining orphan instances to be adopted by the complex type corresponding to the root type. The algorithm borrows from the "technical root" originally proposed by Xcalia, but instead of requiring an additional object, the algorithm gives a place for non-contained data to go. [Ron] I want to point out that this, or any other proposal regarding containment within a context is somewhat orthogonal to the issue 66. Issue 66 solves the more general problem of moving data between contexts in which the definition of the types varies slightly. Both containment and instance class are our first targets, but certainly we believe this to be a a way in which other problems, such as versioning, can be addressed. [Ron] Nonetheless, let's compare, at a very high level, the approach to containment of the two approaches. [Ron] One of the problems we've got when dealing with different application using different sources of metadata is that the definition have to sync-up. In standard SDO 2.1, metadata comes basically from XSD. The standard defines how to convert this to Java, and it's expected that the users of the java interfaces take what they get. [Ron]Blaise's proposal at least allows a second route. It allows the data to be defined from Java, and any XML clients have to take what they get. [Blaise] My proposal involves a reinterpretation of what containment means. In SDO 2.1 containment represented a nested relationship between DataObjects. A DataObject of Type A can be nested within a DataObject of Type B in the resulting XML if an instance of Type A cannot be shared between instances of Type B. Containment in SDO 3.0 should not simply represent nesting, but the underlying concept that enables nesting. This does not simply allow a "second route", but makes it easier to derive an SDO metadata from multiple sources. It is more useful for containment to model the data sharing rules from a relational database or JPA entities, then to be an artificial mapping of these sources to an XML schema. [Ron]That we've tried to achieve with Issue 66 is to "meet-in-the-middle". That is, for instance, some aspects of the model can be defined in Java, the things that effect XML can be defined in XSD. Both sides can be kept a little happy. [Blaise] The issue 66 proposal works well when the SDO model being projected has no containment relationships and is projected into a context with containment relationships. This is a well proven approach demonstrated by technologies such as JAXB and JPA. It becomes more difficult when projecting a model with containment to a model with containment. [Ron]In other words, the project method allows the XML structure to be added in after the Properties are already defined, without touching the application that is defining the properties. None the less, the XML client has a large degree of flexibility in defining the document he wants. [Blaise] A common TopLink/EclipseLink use case is the following. A programmer is creating an application to access relational data and expose it as a web service (XML). They create an object model and apply JPA metadata in the form of annotations to map the objects to the database. Now in order to map these same objects to XML the user needs to apply JAXB annotations. When I do this I always look at the JPA annotations to find out the data sharing rules so I can apply containment/nesting relationships. There are N ways to map an object model to an XML schema, when I take into account the data sharing rules from the JPA annotations there are always <N ways to map the annotated object model to an XML schema. If SDO metadata evolves to represent real relationships between data it can ease the transition from one form to another. [Ron]Please find my detailed comments to Blaise's proposal in the attached document. Best Regards, Ron Responses to document comments: [SAP1] How does this differ from the UML concept of aggregation. [Blaise] I guess this depends on your definition of aggregation in UML. The following is the important concept: Containment: employeeDO1.get("residence") == employeeDO2.get("residence"); // This can never be true Non-Containment: employeeDO1.get("residence") == employeeDO2.get("residence"); // This can be true [SAP2] Address has ?eId?, is that because there is a 1:1 relationship between employee and address. But if that?s the case, I wouldn?t expect an SDO representation to give them both keys, the reference to the ?main? object should be enough? [Blaise] The domain model used in this example was derived from a relational database so I brought in all the primary keys. If Address is never used as a root type, and is only referenced through containment relationships then it would not need an ID (to satisfy SDO). [SAP3[You have a bi-directional relationship, that is containment in both directions. In 2.1 this is not allowed (since it would result in an endless loop when serializing). How would we ever find the ?root? of a datagraph? Would we have to check for cycles? [Blaise] When generating an XML schema if the value of containment property is being converted then the property representing the back pointer to the parent must not generate an XML element. Instead the XML schema should be annotated to indicate that this relationship exists. [SAP4]Wouldn?t it be possible to take the document structure you define later and apply it here? What would be the effect? Would this be equivalent to the transitive closure? I?m asking because when we?re coming from unannotated classes, there is default no containment, and therefore no meaningful change summary. It would be good if we could apply your algorithm to solve this problem. [Blaise]If the scope of ChangeSummary was changed from containment to the datagraph itself then the document structure in the document would apply. [SAP5]I like this. But it?s rather besides the point for the containment proposal, isn?t it. Unless you require that all non-containment properties have keys, which you?re not doing, right? [Blaise] It is not the non-containment properties that keys but their values. This is particulary useful for SDO Types with composite keys. [SAP6]It?s interesting that you have non-containment as the default case, exactly the opposite of what JAXB does. How does this proposal relate to the topic of JAXB alignment. Are we defining new annotations? [Blaise] For the purpose of this document I kept the annotations strongly linked to the Property metadata. Since Property had a property called "containment" I introduced an annotation called "Containment". The specifics of the annotations can be worked out as part of a seperate discussion. [SAP7]In your definition of containment, Address is exclusively owned by employee, right? [Blaise] Yes see my response to [SAP2]. [SAP8]In your example the traversal path is always clear, but I don?t believe this is generally true. Especially if we are coming from Java interfaces, where the order of the properties is undefined. [Blaise] The order of properties is unrelated to the traversal path. [SAP9]I believe there is a conceptual problem here. It is not Types that are ?orphaned?, but objects. A type could still have some containment relationship to another type, but instances of that type used someplace else, in a non-containment relationship. [Blaise] In the SDO Type to XML Schema algorithm containment relationships in SDO translate to nesting relationships in XML schema. As such types can definitely be orphaned, the solution to this is to have the complex type corresponding to the root type "adopt them" although this relationship is represented in the XML schema it is never realized as a property on the root type. Instances can also be orphaned, the algorithm makes the same assumption as SDO 2.1 and JAXB that all the necessary containment relationships are in place, if this is not sufficient then the root complex type will need to be adapted to always expect orphans. [SAP10]I?m trying to imagine your use-case. Is it something like this? You have something like a DAS with methods like getAddress(), getEmployee(), etc. And even though the SDO representation of the results are the same, you want to have a different schemas for each result type. Is that correct? This is an extremely cool idea! [Blaise] That is the exact use case we have in mind. The core data model is derived from the data source, then data is requested based on a particular SDO type. The XML representation of this data should have the queried type as the root type. [SAP11]Traversal path is not sufficiently defined. It seems to mean, if I?ve already seen the type, I don?t generate the element. Is this right? In your examples, every time a reference is thrown out based on this rule it happens to be the back-pointer to a containment relation. I agree that in this case, we can throw the data out of the XML. However, this does not hold in general. [Blaise] If the SDO type has already been seen and an XML complex type has already been generated then don't generate another XML complex type for it. When converting properties to elements then if the property is containment create a nested element, otherwise create an element representing a FK. Imagine a node that has a containment relationship to itself (say, Person.children). That?s of course, a trivial example, but you could have more complex models, where this would be impossible to analyse. [Blaise]Not sure if the answer to the above point addresses this, but a SDO type can have a containment property of the same type as the owning type. I think this algorithm makes the fundamental mistake of thinking that containment is a feature of the metadata, where it?s really a part of the data. [Blaise] Can you comment further on containment being part of the data? See also the following comments. [SAP12]Lets imagine adding ?Department? to this model. Department has a relationship to Employee, and has a non-containement relationship to address. The type ?Address? won?t be an orphan, but the XML would contain unresolved references. [Blaise] See my response to [SAP13] Maybe there should be a property ?orphans? that has type ?Object?, rather than a set of elements? [Blaise] During the marshalling process "orphans" can be determined, there is no need to explicity track them as a property value. Also the orphans change depending on the type of the root object. [SAP13]Same problem. In a general case, the list of employees that is property of this object might not be the complete list that you want to have in your orphans. In such cases, this is broken. [Blaise] This algorithm does make the assumption that if there are containment relationships defined for a SDO type then they will hold all the instances that will be referenced by non-containment relationships. This is assumption is also made by SDO 2.1 and JAXB 2.0. This assumption could be removed by adding elements to the root complex type to hold onto all orphaned instances. [SAP14]How do we know when to apply this algorithm, and when to apply the algorithm specified in SDO 2.1? I think there might be backwards compatibility issues here. Maybe we need a flag to determine this. [Blaise] I do not see the algorithm specified here as being a second algorithm. Instead it is an ammendment to the 2.1 algorithm. When converting SDO 2.1 compliant metadata to XML schema the algorithm will produce the same XML schema. Of course the algorithm also supports the proposed metadata. -Blaise ----- Original Message ----- From: "Barack, Ron" <ron.barack@sap.com> To: <blaise.doughan@oracle.com>; <sdo@lists.oasis-open.org> Sent: Thursday, April 03, 2008 6:22 PM Subject: Comments on Blaises Proposal Hi Everyone, Much as I like aspects of this proposal, there are several fundamental problems with it. In particular, Blaise's claim that "makes use of containment properties when they are present and handles things when they are not" is false. The fundemtental problem is that what Blaise calls "orphans" can not be determined by analysing the metadata, you have to look at the actual instances. Using the proposed algorithm, it is still possible to generate documents with unresolved references. I want to point out that this, or any other proposal regarding containment within a context is somewhat orthogonal to the issue 66. Issue 66 solves the more general problem of moving data between contexts in which the definition of the types varies slightly. Both containment and instance class are our first targets, but certainly we believe this to be a a way in which other problems, such as versioning, can be addressed. Nonetheless, let's compare, at a very high level, the approach to containment of the two approaches. One of the problems we've got when dealing with different application using different sources of metadata is that the definition have to sync-up. In standard SDO 2.1, metadata comes basically from XSD. The standard defines how to convert this to Java, and it's expected that the users of the java interfaces take what they get. Blaise's proposal at least allows a second route. It allows the data to be defined from Java, and any XML clients have to take what they get. That we've tried to achieve with Issue 66 is to "meet-in-the-middle". That is, for instance, some aspects of the model can be defined in Java, the things that effect XML can be defined in XSD. Both sides can be kept a little happy. In other words, the project method allows the XML structure to be added in after the Properties are already defined, without touching the application that is defining the properties. None the less, the XML client has a large degree of flexibility in defining the document he wants. Please find my detailed comments to Blaise's proposal in the attached document. Best Regards, Ron -----Ursprüngliche Nachricht----- Von: blaise.doughan@oracle.com [mailto:blaise.doughan@oracle.com] Gesendet: Donnerstag, 3. April 2008 22:05 An: sdo@lists.oasis-open.org Betreff: [sdo] Groups - Proposal - Containment and Enterprise Data Models (SDO-EnterpriseDataModel.doc) uploaded This is the containment proposal I mentioned during the conference call on April 1, 2008. -- Mr. Blaise Doughan The document named Proposal - Containment and Enterprise Data Models (SDO-EnterpriseDataModel.doc) has been submitted by Mr. Blaise Doughan to the OASIS Service Data Objects (SDO) TC document repository. Document Description: The SDO spec to date has primarily concerned itself with deriving SDO metadata from XML schema. As such containment has come to represent the concept of nesting as it relates to XML elements. We prefer to think of containment as a type of "privately owned" concept. For the association "residence" between types "Employee" and "Address" if instances of "Employee" may not share references to instances of "Address" then it is a containment relationship: Containment: employeeDO1.get("residence") == employeeDO2.get("residence"); // This can never be true Non-Containment: employeeDO1.get("residence") == employeeDO2.get("residence"); // This can be true Using the above interpretation of containment it becomes easy to derive SDO metadata from other sources, such as JPA entities, JAXB objects, relational databases, etc. (the doc provides an example of deriving SDO metadata from a relational database). These sources may not have a concept of nesting, but they are aware of data sharing rules. Of course DataObjects require an XML representation, and containment has been an important part of that. The attached proposal contains an algorithm that makes use of containment properties when they are present and handles things when they are not. View Document Details: http://www.oasis-open.org/apps/org/workgroup/sdo/document.php?document_id=27848 Download Document: http://www.oasis-open.org/apps/org/workgroup/sdo/download.php/27848/SDO-EnterpriseDataModel.doc PLEASE NOTE: If the above links do not work for you, your email application may be breaking the link into two pieces. You may be able to copy and paste the entire link address into the address field of your web browser. -OASIS Open Administration --------------------------------------------------------------------- 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]