[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] Groups - 2.0-Relationships.pdf uploaded
Shmuel Koller wrote: >Gary and Doron, to better explain: > >PML can FULLY provision Connections as follows: > ><xsd:extension base="spml:SpmlRequest"> ><xsd:sequence> ><xsd:element name="identifier" type="spml:Identifier" >minOccurs="0" maxOccurs="1"/> ><xsd:element name="identifier2" type="spml:Identifier" >minOccurs="0" maxOccurs="1"/> ><xsd:element name="attributes" type="spml:Attributes" >/> > >I added a line for identifier2 in my copy of spml 1.0 >xsd. It is an optional identifier, so the request may >have a Pair of identifiers. > >That means any SpmlRequest can have 2 Identifiers. >And everything else remains the same, we keep the >basic set of SPML commands. > >When the RA-PSP exchange occurs for a pair of >identifiers like (user1, group1) - objectclass can be >Connection and an attribute/value in the Attributes >sequence can be connectionType=RACFGroupMembership. >Thus we cover every functionality needed to provision >Connections. > >That means we do not need connect and >modify-connection commands: >Connect is done via spmlAdd (id1,id2) >Modify connection is likewise spmlUpd(id1, id2) >Similarly Disconnect will be done by spmlDel(id1,id2) > >SchemaExchange I think is typed in spml 1.0 by the >objectClass. The objectClass determines the set of >Attributes (the schema). > >To cover Connection, the Schema Exchange must also >have objectClass=Connection, and an attribute >ConnectionType=RACFGroupMembership, if it is desired >to have this granularity of SchemaExchange. > >The main point is Identifiers pair as an option of >every SPML request. And solve all issues while keeping >simplicity - to have full coverage of "provisioning a >connection". That is - give SPML implementations the >power to provision Connections while containing this >power in the SPML commands (with two identifiers) - >and not in any complex data model. > >My point Gary is not to limit (id1, id2) to >objectClass=Connection. In other words - avoid a fixed >affinity between the presence of Two identifiers and >some fixed concept (connection) in the Data Model. Its >just two identifiers in the SPML verb/command, that >will allow full semantics of provisioning Connections >- by minimal change in the Verbs (spml commands) - >change to support from now TWO identifiers. > >I hope I clarified the basic idea of identifiers >pair. >Sorry - I am not up to date of spml 2.0, and hope that >referring to spml 1.0 - just to explain this >particular idea - is OK. > > > Schmuel, All of that was clear to me from your first note. Perhaps you have not yet read my reply, in which I explain that I strongly prefer to have explicit 'connect' and 'disconnect' verbs--in part for clarity and in part because we have chosen to segment the SPML 2.0 operations into separate core and optional interfaces.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]