Re: [provision] Groups - SPML V2 Working group Call added

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

Jeff Larson wrote:

> Gary P Cole wrote:
>
>> The side-by-side comparison below may help in discussing both:
>> - whether to re-use core verbs or to define explicit verbs for 
>> relationships.
>> - whether to represent each complex connection as a PSO.
>>
>> Function                         Extended Verb               Explicit 
>> Verb
>> -------------------         ------------------            -------------
>> add beneath parent        spmlcontain:add               addChild
>> (re-)specify parent         spmlcontain:move             setParent
>>
>> add with references        spmlref:add                      addChild
>> add reference                 spml:modify-add/rep        
>> connect(fr,to,ct[,cco])
>> remove reference           spml:modify-del/rep         
>> disconnect(fr,to,ct)
>> modify reference info      spml:modify(cco-id)         
>> connect(fr,to,ct[,cco])
>
>
>
> I haven't been following this, but the Explicit Verb approach looks 
> more natural.
> Would these be peers to addRequest whereas the Extended Verbs are some
> kind of annotation to addRequest? 

Yes.  The proposal on the table is to have 'spmlcontain:addRequestType' 
extend 'spml:addRequestType', adding a 'parent' attribute.  Gerry Woods 
objects to having verbs in optional interfaces extend core verbs--he 
feels that this is a bad pattern to set.  I suggested the explicit verb 
names--I think that these are clearer and easier to explain.

>
> One question, in the "add reference" function, what do the from and to 
> arguments
> represent, an object, or a specific attribute of an object?  I would 
> imagine
> that creating a reference requires more than just the two object 
> endpoints,
> since objects may refer to many things through different attribute.

The "from" and "to" arguments identify the two connected objects.  The 
"ct" argument is the connectionType (each of which would be represented 
as an attribute with the current implicit representation of 
relationships with SPML 1.0 and the DSML binding). 

I've suggested that there can be at most one connection of a specific 
connection type between any two objects.  That is to say, there cannot 
be two 'memberOf' relationships between user U and Group G.

The "cco" argument is an optional complexConnection object.  A complex 
connection type has "information on the arrow" that must be represented 
as an object.  (For instance, the connection of a user to a group in 
RACF can have SPECIAL, OPERATOR, AUDITOR privileges.  The connection of 
a user to an Entrust GetAccess group must have an expiration date.)

Jeff Bohren has proposed representing each complex connection object as 
a PSO.  I'm trying to avoid persistently storing each complex connection 
object (and giving it an ID).  My concern is scale--since connections 
may outnumber objects by an order of magnitude.  I've suggested that the 
combination of "fromID", "toID" and "connectionType" is enough to 
uniquely identify a connection.  A provider can map this triple to the 
appropriate native object or API.

gary