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
