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

Re: NIM requirements/conventions (was Re: Methods in the NIM requirements)



A couple of quick points (up here rather than inline due to
the nesting).

> > An information model needs to be able to be
> > mapped to any number of data models such as:
> >
> > Repositories - Directories, databases, etc.
> > Protocols - SNMP
> > APIs - C++, Java, etc.

Not to be anal-retentive, but I think you really need to
conside the repository in conjunction with the protocol when
you do a mapping. For example, in doing an LDAP mapping, the
protocol places a number of constraints on what can be
stored in and retrieved from the data store.

I'm not convinced that APIs affect the structure of data in
the information model; they certainly must be considered
when mapping to a specific repository.

> ... me to believe that we should also expand this
> to describe supported paradigms, since protocols
> are an embodyment of a paradigm.

Perhaps, though I'm having some trouble getting my head
around modeling push vs. pull semantics. This could easily
be done in a data flow model, but we're talking about an
information model. Walter, if you could elaborate a bit,
that would certainly help.

> > Object properties that only have the semantics
> > of READ/WRITE or READ-only are (by convention?)
> > called ATTRIBUTES. (Is this correct?)...
> >
> Yes.

Sorry, I disagree. Attributes and properties are synonyms. A
property represents something that is used to describe some
aspect of a class. One can in the model define more
elaborate semantics (e.g., a transitory attribute whose
lifetime is some subset of the object's lifetime) if it
makes sense. Of course, this may present some mapping
difficulties...

Finally, regarding the final thread of methods, what you are
asking for is to provide specific guidelines on a general
modeling technique. I don't think that this is reasonable or
doable.

regards,
John

----- Original Message -----
From: "Weiss, Walter" <WWeiss@lucentctc.com>
To: "'Mark A. Carlson'" <mark.carlson@sun.com>;
<nim@ops.ietf.org>
Sent: Tuesday, May 02, 2000 9:20 AM
Subject: RE: NIM requirements/conventions (was Re: Methods
in the NIM requirements)


> Mark,
>
> This is a very nice summary. Comments inline.
>
> > -----Original Message-----
> > From: Mark A. Carlson [mailto:mark.carlson@sun.com]
> >
> > An information model needs to be able to be mapped to
any number of
> > data models such as:
> >
> > Repositories - Directories, databases, etc.
> > Protocols - SNMP
> > APIs - C++, Java, etc.
> >
> This was in the requirements doc. In addition, my
discussion with John leads
> me to believe that we should also expand this to describe
supported
> paradigms, since protocols are an embodyment of a
paradigm. For example,
> some paradigms are follow a push model while others follow
a pull model.
> Specifically, a device may have configuration pushed to it
via SNMP or a
> device may pull configuration using LDAP (or some other
protocol). More
> importantly, some paradigms are synchronous
(transactional) while others are
> asynchronous. I have provided some examples of this
previously. Here is
> another example. In some cases an SNMP SET will cause an
immediate change in
> the state of the device (like the BandwidthAllocation
assignment). In other
> cases, an SNMP SET will be written to NVRAM and will only
take effect after
> a reboot. Sometimes this is assumed in the standard making
the transaction
> change config as opposed to change state. In other cases
it is an
> implementation choice. We should be able to accomodate
both cases in the
> model. Therefore, I think these are reasonable
requirements to add.
>
> > Even though the information model should be independent
of any
> > mapping to a data model, thought needs to be given to
conventions
> > that might make a mapping difficult or impossible.
> >
> Yes.
>
> > The information model needs to support properties of
objects that
> > have various usage semantics, for example: strict
READ/WRITE,
> > READ/CLEAR, WRITE-only, READ-only, etc. All of these
semantics
> > need support in the information model, however, there is
a
> > requirement for supporting certain semantics
differently.
> >
> Ok. At my first glance I thought you were talking about
attributes here but
> you really mean the object. That's fine.
>
> > Object properties that only have the semantics of
READ/WRITE or
> > READ-only are (by convention?) called ATTRIBUTES. (Is
this correct?)
> > <Is this special classification of semantics due to the
ease of
> >  mapping to repositories?>
> >
> Yes.
>
> > Objects also have behavior (defined as something other
than mutating
> > or accessing a property - except for the CLEAR semantic)
that need to
> > be modeled. The convention for modeling this behavior is
to specify
> > it as a METHOD with (presumably) passed parameters,
returned values
> > or exceptions, all of which are typed, etc.
> >
> > Object properties that have semantics other than
ATTRIBUTE will need
> > to have METHODs defined that specify these other
semantics (such as
> > mutating the property to a reset state). (Question: how
do you relate
> > these property mutator methods back to the property they
mutate?
> > Is there a requirement for method/property naming
conventions?)
> >
> As I said yesterday, I think the METHODs requirement is
not up to snuff in
> the requirements doc. Concerns about overspecification
aside, the more
> precisely we specify the operational boundaries of
METHODS, the more
> interoperable they are and the more precisely we can
assess various language
> alternatives.
>
> > Finally, since METHODs are difficult to map to
repositories, they
> > should only be used to model non-ATTRIBUTE property
semantics or
> > other object behavior. However, this should be at the
> > discretion of the
> > modeler(s).
>
> This one sets my hair on end. I agree with the principle,
but the reason I
> have been pushing so hard on this point is because I
believed that people's
> definition of "behavior" was all over the map. If we can't
put our finger on
> the criteria for using an attribute or method, than usage
will be open to
> interpretation and the choice of which is used will be
more a function of
> who wrote the object.
>
> It is quite clear that we will need a guidelines document
here. Is there
> interest in the group for starting such a document? This
work would focus
> the discussion of the Methods off of the list to just the
authors and allow
> the list to continue with requirements. I think the
guidelines also would be
> useful in the language discussion. If you are opposed to
this work, send it
> to the list. If you would like to voluteer, send me a
note.
>
> regards,
>
> -Walter.
>
>