OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[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]