Reference Relationships (was "Re: [provision] Relationship models")

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

Darran Rolls wrote:

> 4 - To allow the following relationship types to be expressed:
>     4.2  Reference at the point of creation and as an optional 
> interface.  A sample reference relationship would be a "created by" 
> relationship between a

Not sure how solid my thinking is on this, but what's in my mind on this 
topic follows below.

TERMINOLOGY
I think I prefer the term "Connection".  We could still use the term 
"reference relationship" in formal descriptions, but "connection" is 
much snappier than "reference relationship".  Besides, it sounds good 
next to the word "containment". :-)

DEFINING CONNECTION TYPES
Each type of Connection could be defined, hopefully in a manner similar 
to the way in which one defines an optional interface, since these feel 
like analogous concepts.

The definition of a connection type:
- must contain a *name*
? may specify *cardinality*         // if we want to support other than 
optional and multivalued
? may specify an *inverseName*   // if we want to specify support for 
reverse-lookup.

Examples might include:
<ConnectionType name='memberOf' inverseName='hasMember' />
<ConnectionType name='ownsAccount' inverseName='ownedByUser' />

DO WE REALLY NEED TO DEFINE CONNECTION TYPES?
I'm uncomfortable with definining connection types.  If we do this, then 
it seems like a two-stage process to determine whether a target supports 
a particular connection type:
1) determine whether the target supports the optional Connection 
interface for the object type;
2) determine whether the target supports the specified ConnectionType 
for the object type.

Do we really need this? Since we're not specifying the semantics of 
relationships, why require an enumeration of connection types?  If it 
were really important to enforce the cardinality of reference 
relationships, then it might make sense to define each relationship 
type, but is enforcing cardinality really all that important?

Could we leave the connectionType "open"?  Then no one would need to 
define connection types, and the provider would not need to validate them.


AT OBJECT CREATION TIME
A requestor should be able to specify connections to other PSOs at the 
time a PSO is created.  This could always be done after the fact with a 
specific operation (see below), but it would be nice to allow it without 
requiring a round-trip.  (Of  course, I guess you could always batch up 
a bunch of operations and achieve the same effect.)

<Account name='joeBob' ... >
   <Connection type='memberOf' toId='<Group1-ID>' />
   <Connection type='memberOf' toId='<Group2-ID>' />
</Account>

AFTER OBJECT CREATION TIME
We'll want an optional interface to define operations related to 
reference relationships:
- 'connect' (fromID, toID, connectionType)
- 'disconnect' (fromID, toID, connectionType )

For example, to add "joeBob" to group 3:
   connect(<joeBob-ID>, <Group3-ID>, "memberOf");

To disconnect JoeBob from group 2:
   disconnect(<joeBob-ID>, <Group2-ID>, "memberOf");


NOTE: If the 'toID' and 'connectionType' arguments to 'disconnect' are 
optional, this makes 'disconnect ' very powerful (but adds 
complexity--and may be unnecessary):
 - if neither 'toID' nor 'connectionType' is specified,
    disconnect removes fromID's connections of all Types to all other 
objects
 - if  'connectionType' is specified (but not 'toID'),
    disconnect removes fromID's connections of the specified type 
(regardless of referent)
 - if  'toID' is specified (but not 'connectionType'),
    disconnect removes fromID's connections to the specified object 
(regardless of type)

Making the 'toID' and 'connectionType' arguments to 'disconnect' 
optional is adds complexity and is not strictly necessary.   A set of 
queries, followed by a set of  update operations could accomplish the 
same thing.

QUERY
An optional interface for Connections should also define operations to 
query:
- listConnected(ID, connectionType, objectType)  // returns a list of IDs
? isConnected(ID, toID, connectionType)              // returns true or 
false.

For example, to find accounts belonging to group G1:
   listConnected(<G1-ID>, "hasMember", "account");

To find the groups to which object O belongs:
   listConnected(<O-ID>, "memberOf", "group");

NOTE: If the 'objectType' and 'connectionType' arguments to 
'listConnected' are optional, this makes 'listConnected' more powerful 
(but adds complexity--and may be unnecessary):
- if only 'fromID' were specified,
  'listConnected' would return the IDs of all of the objects connected 
to the specified object
  (regardless of connection type or connected object type).
- if only 'fromID' and 'connectionType' were specified,
  'listConnected' would return the IDs of all objects connected to the 
specified object 
  with a connections of the specified connection type  (regardless of 
the connected object type).
- if only 'fromID' and 'connectionType' were specified,
   'listConnected' would return the IDs of all objects of the specified 
object type
   with a connection to the specified object  (regardless of the 
connection type).