Re: [eman] eman framework issue: Do we start from a software design or do we start from the physical world?

I concur with Juergen's concern about how to approach the Framework.
A key concern I have is that the software modeling approach seems to
lead to a document which has more apparent complexity to the reader
than the alternative.   I say apparent because for implementation, the
result might be the same.  However, the apparent complexity is likely
to deter some people from implementing or using EMAN at all.
--Bruce

On Tue, Aug 13, 2013 at 2:17 AM, Juergen Quittek <ietf@quittek.at> wrote:

> Dear all,
>
> Before the IETF meeting I posted high-level comments on the new version of
> our framework draft (draft-ietf-eman-framework-08) and on the alternative
> framework proposal from Bruce (draft-nordman-eman-er-framework-01).
>
> Now I send a series of individuals mails each focusing on a particular
> issue that I found in one or the other draft. For each issue I try to point
> out how the drafts address it and what the differences are.
>
> My first point is about our very general approach to describe the eman
> framework: Do we start with describing a software design and map this to
> the real world? Or do we start with describing the physical world an derive
> a model from it?
>
> The two drafts are quite different in that respect. draft-ietf-eman-framework-08
> (EMAN Framework) rather develops the framework from a software model while draft-nordman-eman-er-framework-01
> (ER Framework) starts from the physical world. Here is an example that
> illustrate the difference.
>
> EMAN Framework section 4.2 Energy Object:
>
>         4.2 Energy Object
>
> An Energy Object is an abstract class that contains the base
>         attributes for Energy Management.  There are three types of
>         Energy Objects: Device, Component and Power Interface.
>
>
> ER Framework, section 2.5 Energy Object:
>
> 2.5.  Energy Object
>
> Devices, Power Interfaces, and Components are all Energy Objects (EOs).  The term
>    "entity" in the Requirements draft generally corresponds to Energy
>    Object.  The kinds of data available for an EO depends on its type as
>    shown in Figure 1.
>
>
> This is just one example out of many similar instances that can easily be
> found in those drafts.
>
> The different choices made by the drafts result in different ways of
> describing the framework.
>
> The ER Framework describes which information is reported for an Energy
> Object (power, state, voltage, etc.) while the EMAN framework tells us
> which attributes (power, state, voltage, etc) the class Energy Object
> has.
>
> So the basic question that occurs to me is: Do we want to define our
> energy management framework as an object-oriented (software) model or do we
> want to describe a view of physical systems?
>
> This would be the core question to be answered for addressing this issue.
>
> Of course, in the end we need a data model for interoperable exchange of
> information based on our framework.
> But for this purpose we already have other documents. Here the candidates
> for  are MIB modules using SMI that do not support the concepts of classes
> and inheritance (which also holds for YANG modules using XML).
> :
> Cheers,
>     Juergen
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
>
>

-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
*nordman.lbl.gov*
BNordman@LBL.gov
510-486-7089
m: 510-501-7943