Hi,
I am concerned that the term "aggregate objects" is very general and may carry some implicit assumptions that may not apply to the "attribute groups" we are considering. The term "attribute groups" came into being because there were implicit semantics associated with the well-known terms such as struct, class, and so on. I somewhat dislike Frank's proposed text because it draws a comparison between attribute groups and C structs and Java classes, but C structs and Java classes have specific semantics that we want to make very clear might not apply to the term "attribute groups".
One of the problems we have is that the working group hasn't quite nailed down just what an attribute group is, what it is allowed to contain, how it can be used, how atomic access must be handled, and so on; we're still debating those issues.
Some people believe strongly that to really take advantage of object-orientation, methods that are bound to the data within a "class" are needed. Others believe strongly that using methods violates the whole design philosophy of SNMP simplicity, which is based on having a clear separation between the data definitions (mib modules) and the small number of protocol-specific verbs that can act on *any* data definition.
The term "attribute groups" was chosen by the WG because in discussions to date, methods and associations and constraints have been largely rejected. The term "class" was replaced in the document with "attribute group" because "attribute group" says this is just a group of attributes, not a group of attributes and methods and associations and so on. The term "aggregate object" does not indicate that the thing contains only attributes.
As I recall the change from class to attribute group was the result of discussion in the WG meeting in Minneapolis, when Bob Moore raised the question and the audience murmured agreement with the concern that the term class carried semantic baggage and we should use a term that was more descriptive of the intended semantics.
I believe the term attribute group was chosen by consensus of the working group, and should continue to be used.
my $.02
dbh
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Thursday, September 20, 2001 7:31 AM
> To: Frank Strauss; sming@ops.ietf.org
> Cc: Jason, Jamie; 'Fred Baker'
> Subject: RE: dumb questions/comments regarding smi-ng
>
>
> Franks answers Fred and Jamie:
>
> > Fred> if so, may I suggest a minor text edit?
> > Fred>
> > Fred> "..., also referred to as 'aggregate objects', ..."
> > Fred>
> > Fred> I read those sections, and the concept of aggregate
> > objects never
> > Fred> entered my mind while reading them.
> >
> > As long as we don't use a certain term, we should not say
> that we do.
> > I have no strong opinion on which term would be better
> > `aggregate objects'
> > or `attribute group', but I think we should not use both.
> >
> If we agree that we mean the same thing, then maybe a compromise:
>
> "..., to some people better known as 'aggregate objects', ..."
>
> Bert
>