Re: Some questions on the base sming document

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

Hi!

Joel> Thank you for the clear reply.
Joel> On the issue of the ordering of "key" fields, the concern I have with
Joel> a "should" is that I am not clear on how even a human being would know
Joel> whether the fields are in the right order.  If we mandate that the
Joel> fields are in significance order, then any translator (human or
Joel> machine) can use that fact.

I think, there could be situation where there is no single `right'
order that is appropriate for all possible mappings.

An example: Imagine the smRunTable of the DISMAN-SCRIPT-MIB would have
been modeled as an SMIng class. Its `unique' statement would contain
the elements { smLaunchOwner, smLaunchName, smRunIndex }. In SNMP
mappings the order of these elements in the `index' clause would be
significant wrt efficient list retrievals by owner or by name. Both
could be useful.  Hence, it is difficult to say, which order of these
elements is 100% right in the SMIng definition. But maybe in most
cases, there's an order that the author estimates to be more useful
than another.

If a human or a compiler maps an SMIng `unique' clause to an SNMP
mapping's `index' clause, and if there are no other conditions that
would favor any variation, then the order should be kept unchanged.
[should I cut&paste this sentence to the snmp mapping document? ;-)]


Joel> If we do not require this, then even a human being who is translating
Joel> will need to examine each listed attribute and confirm that they are
Joel> in the proper order.  But, if the reader is going to have to do that
Joel> anyway, then the most it is worth saying is "it can be helpful to the
Joel> reader of this class if the fields are in significance order", which
Joel> is even weaker than "should".

I think this "should" is appropriate, because it says to the SMIng
module author that he should (must?) regard the order as significant,
if he favors a certain order of the elements' significance in most
common use cases. As with any other piece of a module, further details
should be specified in the related `description' texts.


Joel> PS:  "Should" is always an interesting condition to use in our
Joel> documents.  Sometimes, the receiver of the message can tell if the
Joel> sender (in this case reader and writer) has abided by the "should",
Joel> and therefore gets a benefit from the fact that most cases will follow
Joel> the rule.  Sometimes there is a robustness benefit if most people
Joel> follow the "should".  Otherwise, "should" is not much better than
Joel> "may".  I suppose we could recomment that the description clause
Joel> include a sentence as to whether the keys are in order, so that at
Joel> least a reader has a clue?

A reminder to give all relevant details in `description' clauses could
be applied to each and every subsection. Instead I kept a note in another
piece of text that could become a SMIng guidelines document some day
(currently, it serves just as a very short reminder file to me. it's
available at http://www.ibr.cs.tu-bs.de/projects/sming/):

          <t hangText="Variations from `the SHOULD case': ">
            In any case where a piece of a SMIng module violates
            a rule from the SMIng specifications that SHOULD be
            observed, the module author has to explain the reasons
            and all relevant details with special care in the
            related description clause.
          </t>


Joel>      The other side of this question is whether there is ever a need
Joel> to violate this "should".  If there is never a good reason to put them
Joel> in other than significance order, then just make it a MUST.

Maybe. It was my feeling that in cases where a condition cannot be
clearly determined, a `conditional must' does not help a further.


 -frank