Re: terminology challenge

[rpresuhn-lists@dorothy.bmc.com]

Hi -

> Date: Tue, 18 Dec 2001 18:25:36 +0100
> Message-Id: <200112181725.fBIHPau24391@haerke.ibr.cs.tu-bs.de>
> From: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>
> To: abierman@cisco.com
> Cc: sming@ops.ietf.org
> In-reply-to: <4.3.2.7.2.20011218082524.01f4b180@fedex.cisco.com> (message from
> 	Andy Bierman on Tue, 18 Dec 2001 08:51:13 -0800)
> Subject: Re: terminology challenge
> References: <4.3.2.7.2.20011217095939.01ef6e00@fedex.cisco.com>
>  <4.3.2.7.2.20011215130827.01e7d6e8@fedex.cisco.com>
>  <4.3.2.7.2.20011215130827.01e7d6e8@fedex.cisco.com>
>  <4.3.2.7.2.20011217095939.01ef6e00@fedex.cisco.com> <4.3.2.7.2.20011218082524.01f4b180@fedex.cisco.com>
..
> Containment is not exactly the same as inheritance. And this does not
> really look C-like either. ;-)
..

One of the things that bothers me about all the proposals
(and perhaps this is just because I spent too much time in
CMIP-land) is that we haven't been making a clear distinction
between an object having attributes and an instance of an
object being (logically) contained in another object instance.
Instead, the SMI compells us to think in terms of INDEX
clauses, which, if inherited, make my head ache when I think
about scoping.

Some of the examples of arrays of elaborate structs with
complexly indexed attributes really seem like a kludgy way
of representing object containment.  Perhaps the need to
talk about other ways of encoding indexing information is
just a symptom of the need to properly address representing
containment, and not just the construction of elaborate
type definitions.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 randy_presuhn@bmc.com  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------