Re: Some questions on the base sming document

["Joel M. Halpern" <joel@longsys.com>]

Thank you for the clear reply.

On the issue of the ordering of "key" fields, the concern I have with a 
"should" is that I am not clear on how even a human being would know 
whether the fields are in the right order.  If we mandate that the fields 
are in significance order, then any translator (human or machine) can use 
that fact.
If we do not require this, then even a human being who is translating will 
need to examine each listed attribute and confirm that they are in the 
proper order.  But, if the reader is going to have to do that anyway, then 
the most it is worth saying is "it can be helpful to the reader of this 
class if the fields are in significance order", which is even weaker than 
"should".

Yours,
Joel M. Halpern

PS:  "Should" is always an interesting condition to use in our 
documents.  Sometimes, the receiver of the message can tell if the sender 
(in this case reader and writer) has abided by the "should", and therefore 
gets a benefit from the fact that most cases will follow the 
rule.  Sometimes there is a robustness benefit if most people follow the 
"should".  Otherwise, "should" is not much better than "may".  I suppose we 
could recomment that the description clause include a sentence as to 
whether the keys are in order, so that at least a reader has a clue?
     The other side of this question is whether there is ever a need to 
violate this "should".  If there is never a good reason to put them in 
other than significance order, then just make it a MUST.


At 12:43 PM 3/13/01 +0100, Frank Strauss wrote:
>...
>Joel> 1b) "If present, the attribute list must not contain any attribute more
>Joel>     than once and the attributes should be ordered so that the
>Joel>     attributes that are most significant in most situation appear first.
>...
>Joel> More significantly, what
>Joel> does the second sentence mean?  Are we requiring that the attributes
>Joel> be ordered?  If not, why include the "should" since the system will
>Joel> not be able to take any advantage of the ordering to help searches
>Joel> unless it knows that the ordering is always met.
>
>In many situations the order can be regarded as a hint on a reasonable
>order of INDEX elements in the SNMP mapping, for example. It *can*,
>thus the word "should". The `system' you mention can be an SNMP
>manager, which obviously can rely on the order of instance identifying
>sub-identifiers.  The question is, how the SMIng core classes are
>mapped to SNMP tables.  For this mapping process (done by a human
>being, not automatically) I think it's useful to suggest that the
>order of the `unique elements' should be meaningful where appropriate
>and not completely irrelevant.