20040824 Working Group Call.

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

Participants in Tuesday's working group call discussed
Gerry Woods' containment use case document.  This draft
illustrates three different approaches to modeling containment.
- Approach #1 (Schema) added a 'parent' attribute to the schema.
- Approach #2 (Jeff's) extends the core 'add' operation.
- Approach #3 (Generic) used a generic relationship capability.

Attendees:
- Doron Cohen (BMC)
- Gearard Woods (IBM)
- Jeff Bohren (Open Networks)
- Gary Cole (Sun)

With the "Schema" approach, the 'add' operation remains simple.
The downside is that interoperability suffers.  Without a
standard schema, the existence and semantics of a 'parent'
attribute are unknown.  Mr. Woods suggested (and participants
agreed) that schema approach was overall the least desirable.

The "Generic" approach assumes a generic relationships capability.
This approach further assumes that a capability can have a schema.
Mr. Woods pointed out that defining a schema for a capability
would require us to enrich the meta-data associated with a target.
Participants also pointed out that using a single and generic
capability to model both containment and reference relationships
would require additional meta-data to define each type of relationship.

Participants then discussed whether containment and reference
differ enough to justify using different mechanisms to model them.
The general conclusion that these two differ fundamentally.

Where targets use containment (e.g., in directory services):
- Containment is often *mandatory*.
  (i.e., Some objects cannot stand alone and
  can be bound only beneath other objects.)
- Containment is generally *hierarchical*.
  (i.e., An object can have at most one parent.)
- Containment requires *referential integrity*.
  (i.e., The parent must exist when a child is added.
  When one requests to delete a parent,
  either all descendants are automatically deleted
  or the request to delete a parent is refused--
  with a message saying the container isn't empty.

Where targets use reference relationships, by contrast:
- References are *optional*.
- References are generally "many-to-many".
- References can be "stale" or invalid.
  (i.e., The referent may not exist.)

In Jeff's approach (we could also call it the "Extension" approach),
an optional containment capability extends the core 'add' operation
to add a required 'parent' argument.  An optional reference capability
extends the containment 'add' operation to add optional reference
arguments.  The main criticism of this approach was that having
optional capabilities extend the core verbs sets a bad example.
You can't do this for long without painting yourself in a corner.
For example, the reference 'add' must extend the containment 'add'
(rather than the core 'add') in order to allow a single 'add'
that supports both containment and reference relationships.

In spite of these concerns, Mr. Bohren's "extension" approach
was considered to be by far the "cleanest" approach of the three.

A fourth approach was revived for discussion.  Mr. Bohren
several times mentioned that he wished the core operations
supported containment.  Participants recalled the main
objections raised when this approach was originally discussed:
- The burden (and oddity) of a provider implementing
  required containment operations
  when the underlying target does not do so.
- If a provider does not implement containment,
  the requestor must "program-by-exception".

Nonetheless, participants felt that it was worth
re-examining this "Core" approach in case it turns out
to be less heinous overall.


Action Items:
-------------
1)  Gerry Woods will enhance his draft to discuss
    a fourth approach: putting containment in the core.

2)  Jeff Bohren will add a 'getParent' operation
    to his proposal.  This permits upward traversal.
    (For downward traversal, 'search' should suffice.)

3)  Gary Cole will start an email thread to discuss
    issues related to the semantics of PSO ID:
    - scope of uniqueness
    - mutability
    In short, are IDs GUIDs or are IDs names?