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

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



Wow. This is a good discussion thread that seems to be shaking out some
requirements along the way. Let me see if I can summarize the discussion
to this point:

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.

(might be good to enumerate these to reduce confusion)

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.

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.

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?> 

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?)

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).

Comments?

-- mark
begin:vcard 
n:Carlson;Mark A.
tel;pager:3978021@skytel.com
tel;cell:720-841-3072
tel;fax:303-272-8427 / x78427
tel;home:303-494-2162 
tel;work:303-272-8417 / x78417
x-mozilla-html:TRUE
url:http://mark.carlson.net
org:Sun Microsystems, Inc. - Jiro Group http://www.jiro.com;Network Storage
adr:;;2990 Center Green Court South;Boulder;CO;80301;USA
version:2.1
email;internet:mark.carlson@sun.com
title:Solutions Architect <img src="http://www.jiro.com/images/jiro_clr_61x83.jpg";>
fn:Mark A. Carlson
end:vcard