[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: terminology challenge




Juergen,

> You are using "containment" while talking about modeling "contained
> in" relationships - which I think CMIP name bindings are doing. How
> important do you think modeling "contained in" relationships really
> is? And do we need special language constructs for modeling this
> particular relationship?
>
> I think even the CIM modelers do not have language support for
> "contained in" relationships - CIM folks, please speak up if I am
> wrong.

Actually, the CIM "folks" are looking at this and related questions
this week.  I think we need to be careful to remember that aside
from cases like cards, slots, and chassis, we're all using
"containment" in a metaphorical sense.  In reality, there are two
closely related, but distinct concepts that have been intertwined
since (at least) CMIP / GDMO:

1. Naming scope - An instance of class A can be given a unique
   relative distinguished name within / under an instance of
   class B.
2. Existence scope - An instance of class A can be tied to an
   instance of class B, such that the instance of class A will
   cease to exist if the instance of class B does.

Both of these notions are clearly present in CMIP / GDMO, with
X.500 naming (DNs built up from RDNs), and with CMIP DELETEs
conditioned either with "deletes contained objects" or with
"only if no contained objects."

What's explicitly present in CIM today is Naming scope, where
a naming hierarchy is created via Weak associations.  However,
there is a restriction that has proved to be awkward: a class
can only be Weak to one superior class.  GDMO Name Bindings
do not have this restriction.

It's still very much a work in progress, but CIM people are
now looking at the question of whether Naming might have
been the wrong thing to focus on all along.  (Note that this
is my characterization of what's going on with CIM - other
CIM modelers might say it differently.)  Suppose we took
Naming off the table completely, by eliminating hierarchical
naming within a CIM Name Space.  Even if every instance had
a single naming property that uniquely identified it within
the Name Space, there would *still* be a need to represent
possible Existence scopes.  (I've finally worked my way
around to your question of whether there's a way to
represent "contained in" relationships formally in CIM!)

In the Policy model, for example, a Policy Condition can
have, as its "Existence Superior," either a Policy Rule
(if it's a rule-specific condition) or a Reusable Policy
Container (if it's a reusable condition).  We had a very
hard time expressing this idea in the existing CIM Policy
model, because Existence scope is hidden in Naming scope,
and a class can have only one Naming scope.  IF (and it
really is still a matter of "if") CIM goes to flat naming
within a Name Space in its next version, I think it will
need to introduce a formalism for identifying the
possible Existence scope(s) for a class.  This formalism
would replace Weak in CIM, and it would correspond to the
Existence scope aspect of GDMO Name Bindings.  It would
thus be exactly what you asked about - a formal way of
indicating (what I see as) the *literal* meaning of the
metaphorical "contained in" relationship: Existence scope.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com