[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]