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 - SPML V2 Working group Call added


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

Gary

Darran.Rolls@Sun.COM wrote:

>1) Should relationship operations re-use/extend core verbs?
>
>   Jeff Bohren has proposed the following:
>
>   - spmlcontain:add (since add may require containment).
>
>   - spmlref:add (desirable to minimize SPML calls).
>
>   - use spml:modify to add/replace/remove connections.
>
>   - use spml:modify to update complex connection info.
>
>   - use search to query by reference relationship.
>
>
>
>   pro: keeps protocol simple (adds fewer verbs).
>
>   con: makes protocol confusing (overloading; bad pattern).
>
>   pro: containment sometimes required as part of create.
>
>   pro: references desirable as part of create (fewer calls).
>
>
>
>
>
>2) Represent each complex connection as a PSO?
>
>   pro: keeps protocol simple (adds fewer verbs).
>
>   con: scalability burden on provider (ID namespace).
>
>   con: scales worse than native resource (e.g., RACF).
>
>   rebuttal: complex connections are rare.
>
>             Since most connection types are simple,
>
>             benefit of simplicity outweighs burden of scale.
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]