Re: [provision] Groups - 2.0-Relationships.pdf uploaded

[Gary P Cole <Gary.P.Cole@Sun.COM>]

Cohen, Doron wrote:

>Gary ,
>
>To your last comment :
>
>" If RacfGroupMembership were defined as a PSO Type, the schema of the
>target would define the XML representation (i.e., elements and attributes)
>of RacfGroupMembership.  If connectionAttributes are arbitrary, how will the
>caller know which to attributes specify (and in what format)?  Would we need
>some sort of 
>schema for the connectionType?"
>
>
>I do not argue that adding group membership as a PSO type is better modeling
>the environment , but as you clearly expressed in your response, this is an
>approach that we have chosen not to take , yet. This leaves us to two
>options - leave it totally out of the SPML spec.  Or , provide a simple way
>to address it . I am for the second approach as I suggested. 
>As for the schema, the answer is pretty clear, we will need to be able to
>let the client application figure out what connection types are supported by
>the SPML implementation and what attributes are there. It therefore should
>be part of the schema representation.
>
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).

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).

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.

Perhaps we could address this shortcoming by declaring 
RacfGroupMembership to be not a PSO Type but a ComplexConnectionType.  
The provider would ensure that any RacfGroupMembership instance that is 
bound beneath User1 is properly reflected in the response to 
'getConnections(User1,Group1)'.   Assuming that each connection is 
already returned as an XML object, these would simply be returned as 
RacfGroupMembership objects rather than SimpleConnection objects.

I can imagine Jeff Bohren grimacing in pain while reading what I've just 
written, but I want to know first whether this (or something like it) 
would satisfy your requirement.

Gary