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

Re: Closing on NIM requirements - New Thread for CIM/DMTF



on 04/18/2000 3:09 AM, Andrea Westerinen at andreawest@mindspring.com wrote:

> I do agree that CIM should be simplified (which I am actively working to
> bring a proposal forward to the DMTF).  However, the basic constructs and
> thinking behind CIM are reasonable. Perhaps some details are flawed, but I
> do not know of one design that was perfect in its first iteration.

I broke this off to a separate title since these questions/issues may
different than the main topic currently under discussion.  Perhaps these
issues have been dealt with, if so, sorry for raising them again.

1. Since I assume DMTF is not giving change control of CIM to the IETF, we
should take whatever we want from it, leave what we do not want and change
it (of course with proper attribution) to be whatever is sufficient and
necessary for our purposes. I am aware that is what some people are working
toward. The point is that it is fine to make proposals to other
organizations and cooperate with them. Our first goal should be for
developing what works where that includes elements of timeliness, simplicity
and implementability.

2. I appreciate the comments people have made that the model we are talking
about is necessarily complex. We must also be sensitive to willingness and
ability to undertake work with the model by others. This is particularly
true for the applications people. Also it needs to be simple enough so that
at a high level operational people can grok it as well. In the presentations
I have seen, minimally the top level seems unaproachably complex. One
suggestion to help would be to create a bit more of a hierarchy than exists
now. 

3. On the topic of attributes and operations, I find that I agree with the
traditional OO views, that is that the class definition includes three parts
(at least when expressed in UML) The Class name, attributes and operations.
I found a review of the book Fundamentals of Object-Oriented Design in UML
by Larry Constantine helpful. This may appear to be in conflict with other
observations I have made about the requirement that we be able to take
things expressed this way and use the tools we have to realize them.  In
some places this will be easy and in some places this will be hard. This is
the 'Reality' string Harald and I had yesterday.

/jon