[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] Groups - 2.0-Relationships.pdf uploaded
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]