Issue 3112: Template should suppress add for [x..x] Attributes (mof-rtf)
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Uncategorized Issue
Severity: 
Summary: The Attribute template suppresses the "remove" operations for multi-valued
Attributes whose lower and upper bounds are the same.  [This makes sense
because removing an element would always trigger an underflow error.] However,
similar logic has not been applied to the "add" operation. We should consider
suppressing "add" operations for multi-valued Attributes whose lower and upper
bounds are the same, since the operation must always trigger an overflow error
in this case.


Resolution: 
Revised Text: 
Actions taken:
December 13, 1999: received issue
Discussion: 

End of Annotations:=====
X-Mailer: exmh version 2.1.0 09/18/1999
To: mof-rtf@omg.org
Subject: Template should suppress add for [x..x] Attributes
Mime-Version: 1.0
Date: Mon, 13 Dec 1999 12:29:54 +1000
From: Stephen Crawley <crawley@dstc.edu.au>
Content-Type: text/plain; charset=us-ascii
X-UIDL: em]!!Be_d9~"Pe9o9G!!


The Attribute template suppresses the "remove" operations for
multi-valued
Attributes whose lower and upper bounds are the same.  [This makes
sense
because removing an element would always trigger an underflow error.]
However,
similar logic has not been applied to the "add" operation. We should
consider
suppressing "add" operations for multi-valued Attributes whose lower
and upper
bounds are the same, since the operation must always trigger an
overflow error
in this case.

Discussion:

I'm not sure how this inconsistency slipped through.  It might be that
we (the RTF) reasoned as follows:

  * In the analogous case with References, the "add" operation should
    not be suppressed.  The set of objects projected from the linkset
    may have less elements than the lower (== upper) bound and
therefore
    the "add" does not necessarily cause an overflow.

  * We have (had) a goal of making the Reference and Attribute
interfaces
    the same if their respective multiplicities were the same.

Whether or not that was our reasoning, the IDL mapping currently
generates an
operation in the Attribute case whose implementation MUST be to raise
an
exception.  I don't think this is a good idea ...

Note: at worst, this is a minor inconsistency in a seldom used part of
the MOF spec.  Nothing to worry about unduly ... IMO.