Re: [provision] SPML 2.0 Relationships proposal...

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

Jeff Bohren wrote:

> Attached is the first draft of my proposal for handling relationships. 
> This covers both containment and references. It supports references 
> with attributes. It also supports relationships (both kinds) as search 
> criteria and also as search results. I believe that this proposal 
> meets all of the requirements discussed so far.
>
Thanks, Jeff.

1) I was under the impression that each target would declare the 
capabilities that it supports, but you seem to be saying that the 
containment capability will be declared at the level of an individual 
PSO type.  This is more granular than I had understood the target's 
capability map to be.

2) The second sentence in the Containment section could be 
misinterpreted to mean that you propose to change the core 'add' 
operation.  Perhaps it could be reworded along the lines of :
   The optional containment interface will define an 'add' request
   that extends the core 'add' request.....

3) It may be worth mentioning (for the benefit of reviewers) that 
containment is a simple relationship.  You brought this up in today's 
discussion, and I thought this was an excellent point of clarification.

4) I would be happier if gave these operations different names (rather 
than simply overloading a signature or--in this case--extending a core 
operation under the same name in a different namespace).  I'd rather 
call this operation "addChild" or "addToContainer".  I suggest renaming 
"spmlcontain:AddRequestType" to "spmlcontain:AddChildRequestType".  The 
AddChildRequestType could still extend spml:AddRequestType.  I just want 
to give the operation a different and more descriptive name.

5) Along the same lines as the previous comment, I'd suggest that we 
rename the 'move' operation to 'setParent' or 'setContainer'.  (I know 
that 'move' means 're-parent' in LDAP-land, but I'd prefer to make this 
more explicit.)  Of course, "spmlcontain:SetParentRequestType" could 
still extend "spml:BatchableRequestType".

6) I liked your comment about unidirectional relationships, and I 
suggest adding (for the benefit of reviewers) a sentence like:
    NOTE: Specifying reference relationships as unidirectional does not 
preclude a provider
    representing relationships as bidirectional; rather, this becomes a 
feature
    or an artifact of that provider's implementation.

7) Same comment as (1), this time for reference relationships.  
Declaring support for a reference capability at the level of an 
individual PSO type is more granular than I had previously understood a 
target's capability map to be.  (I thought each *target* declares the 
optional interfaces it supports.)

8)  The terminology of "Reference ID", "Referent ID" and "Reference 
Attributes ID", while technically accurate, can be confusing.  I suggest 
using terms like "From ID" and "To ID" and "Connection ID" (if not as 
the actual terms then at least to explain them).
    From ID - identifies the reference--the source or "from" object.
    To ID - identifies the referent--the target or "to" object.
    Connection ID - (optional) identifies an object that represents
                          any "extra" information about this relationship.

9)  I think you forgot a field: "Connection Type".   You could call this 
"Relationship Type", but it's the same idea.  Several connections, each 
of a different type, may connect any two objects.  Each connection type 
in essence defines a separate namespace.  (Without this, a request to 
delete or modify a connection might remove or update the wrong connection.)

10)  I really wish there were some way to avoid making the (optional) 
relationship object a PSO (and giving it an ID).  As we discussed at 
Long Island, persistently storing these objects (and mapping each to the 
appropriate target object or API) creates scale problems for a 
provider.  Experience suggests that the number of connections may be an 
order of magnitude or more greater than the number of objects connected.

Rather than identifying a complex connection by an ID, could we specify 
a complex connection instance by its From ID, To ID, and Connection 
Type?  If a provider can map these identifiers to the appropriate target 
object or API, then we avoid persistently storing each complex 
connection object as a PSO (and continually having to map its ID).

In the case of the RACF, these arguments map cleanly to the API.  In the 
case of a directory object, it might be necessary to find the connection 
object by starting at one end (either source or target) or by searching 
for an object that connects both the "fromID" and the "toID".

As a consequence, one would modify connection attributes by passing any 
object representing a complex connection as part of the 'connect' 
request.  A single 'connect' verb could implicitly modify any existing 
connection between the specified "from" and "to" objects (as it does in 
RACF), or we could define separate  verbs to "addConnection" and 
"modifyConnection".

Do you see any problems with this kind of approach?  Is it possible to 
avoid representing each complex connection object as a PSO?

11) Same as (9): need "Connection Type" in order to uniquely specify an 
connection (instance). 

12) As mentioned in (10), prefer to have explicit 'connect' and 
'disconnect' verbs.  However, I suppose that a single "modifyConnection" 
could be used to add, modify, and delete connections.

13) It's clear from the definition, but we should mention (for the 
benefit of reviewers) that SearchRequestType is defined in the "spmlref" 
namespace and that this extends but does not change the core interface? 

14)  Same as (13), except for Search Response.

15)  We would not want including connections to "bloat" the size of 
every PSO returned by spmlref:search.  You mentioned some options to 
control whether connections (or perhaps which connections types) would 
be returned?

Gary