Re: Requirements Feedback

[Frank Strauss <strauss@ibr.cs.tu-bs.de>]

Hi!

Jason, Jamie writes:

Jamie> Some questions regarding some of the SMIng requirements.

Although some of your concerns are more questions than comments, I've
added them to the issues. I thinks it's better to note all remarks
instead of loosing any input on issues that are not worded unprecisely.

Jamie> 1.  Can someone please elaborate on the differences between #14
Jamie> (Instance Pointers) and #15 (Row Pointers).  Can they be
Jamie> thought of in this way?  Instance pointers are typed pointers,
Jamie> whereas row pointers are void pointers.  With the distinction
Jamie> being that an instance pointer may only reference a row in one
Jamie> type of table, while a row pointer may reference a row in any
Jamie> kind of table?

Added.

Jamie> 2.  In example for #20 (Events), the event linkDown has (or
Jamie> seems to have) two attributes - one of type status and a
Jamie> description.  Is it possible to have more attributes for an
Jamie> event?

Added as a comment to the Specs section. My answer:

    <p>
      Frank: I'm not quite sure, whether you mean attribute in the sense
      of a SMIng keyword to specify more information about a modeled event,
      or whether you mean attribute in the sense of a class attribute.
      In fact, the former is true: the status and description are just
      SMIng keywords with the same semantics as status and description
      within a class or attribute or whatever construct. There is *no*
      way to specify which objects/attributes have to be trasmitted over
      the protocol when an instance of this event is emitted. This has
      to be done in the protocol dependant mapping. The only context
      information of this construct is the fact that the event is defined
      within a class construct, which means that each instance of a
      linkDown event is concerned with an instance of the Interface class.
    </p>

Jamie> 3.  #28 (Categories) - is this akin to C++ namespaces
Jamie> (apologies to those who are not familiar with them) in that
Jamie> they allow for scoping in order to reduce/prevent name
Jamie> collisions?  Or, is this the purpose of #68 (Module Namespace)?
Jamie> If #68 serves this purpose, I would like some more
Jamie> clarification on #28 so that I can get them straight in my
Jamie> mind.

Added.

Jamie> 4.  I would like to second the idea that #29 (Agent
Jamie> Capabilities) be removed from the SMIng requirements.  This
Jamie> does not seem to belong at this level.

Added.

Jamie> 5.  Would it be possible to name #33 (Classes) to something
Jamie> like "Attribute Groups"?

Added.

Jamie> 6.  #39 (Arrays) - is this as Andrea thought (a multi-valued
Jamie> attribute), or is it a set of multiple attributes?  I can see
Jamie> use for having a set of multiple attributes (which is what I
Jamie> had thought it was).

Added.

Jamie> 7.  Am I right in assuming that #64 (Make Status Information
Jamie> Optional) refers to status information that is most useful to a
Jamie> human?  For example, if something is deprecated, a compiler
Jamie> could inform the user that they are depending on/deriving
Jamie> from/referenceing something that has been deprecated in a
Jamie> manner similar to how the Java compiler does.  If we go down
Jamie> the path of keeping the status information for the purpose of
Jamie> providing meaningful information from compilers, do we go down
Jamie> the road of also supplying additional information.  For
Jamie> example, in the case of a deprecated class that is inherited
Jamie> from, should there also be information that states the name of
Jamie> the new class that should be inherited from instead?

Added.

 -frank