Relationships and schema representation

["Cohen, Doron" <Doron_Cohen@bmc.com>]

Gary, 

To your comments :

>Okay, so the question is now how to represent in the schema the 
>structure of information that is associated with a connectionType.  I 
>interpreted Schmuel Koller as suggesting that a pair of types  was also 
>a type, and could therefore have a schema.   I don't think this will 
>work well as stated.  For one thing, objects of two types can be 
>connected by more than one type of relationship.  For another thing, the 
>same type of relationship can connect more than two types of objects.  
>For these reasons, I believe that it would be better to represent each 
>connectionType (or at least, any connectionType that is *complex*) as a 
>separate, named type.  This would also allow a complex ConnectionType to 
>have its own structure (i.e., elements and attributes rather than just 
>attributes).

[Cohen, Doron] I agree that the connection type is more appropriate than 
the combination of two object types. 

>It would be very nice to avoid having to declaratively define simple 
>connection types.  I know that Jeff Bohren was not very enthusiastic 
>about having to define connection types in the schema, especially things 
>Like the set of object types to which each connection type would apply 
>(and the direction of a connection).

[Cohen, Doron] I do not see the harm in defining simple connections as
part of the schema with no attributes. If we are to support relationships
than I would prefer to have all relationship types explicit in the schema.

>I previously suggested that we represent a complex connection as a PSO 
>that is bound beneath one of the objects its connects and that refers 
>(by means of a simple connection) to the other object it connects. The 
>current draft specification does not address relationships, but we 
>talked about (and I believe I mentioned in email) needing to define for 
>containment relationships the PSO types beneath which each PSO type 
>could legally be bound.  This mechanism would allow a provider to 
>declare the PSO types beneath which each type of complex connection 
>could be bound.
>To revisit our RACF example, let's assume that the schema defines PSO 
>Types for User, Group, and RacfGroupMembership.  Suppose the schema also 
>declares that  PSO Type RacfGroupMembership can be bound beneath PSO 
>Type User.  Also suppose that the schema defines (or it is otherwise 
>understood) that an instance of RacfGroupMembership has a simple 
>connection to an instance of Group.  This can all be done with PSO Types 
>and simple connections.
>If I understand your position correctly, this fail to satisfy the 
>requirement to support relationships with attributes because the 
>RacfGroupMembership type is defined as a PSO Type and not as a 
>ConnectionType.  I believe that you object (and please correct me if 
>This is incorrect) because no RacfGroupMembership would be reflected in 
>the response to  'getConnections(User1,Group1)' .  Instead, to see these 
>connections, one would have to accumulate the results of calling 
>'getConnections' to Group1 from each instance of  RacfGroupMembership 
>bound beneath User1.  I agree that this is inelegant.

[Cohen, Doron] I think you got me wrong here. I do not object to having PSOs

for relationships and I agree it solves most of the problems with regard to
the schema.
It just make the result more complex and it was the desire of the TC to get
away