John's proposal to eliminate implementation defined attributes
     http://www.eda.org/itc/hm/0291.html about 2/3 to 3/4 down in
     the message. (See Below)

     This was John's proposal to avoid the issue mentioned in IM29C
     above with non-existent integer attributes.

>>     regarding your proposal to disallow implementation-defined attributes, 
I realized that another consequence of this proposal is that the 
Override*Attribute() methods become obsolete because all standard 
attributes are read-only and cannot be overridden. 


====================================================
Excerpt from message 0291

> 
> > Similarly, NumberOfObjects() returns a proper and valid range for 
> > indexing so there's no excuse for violating that, therefore index 
> > out of bounds should be considered fatal. 
> 
> Same comment as above. 
> 
> > Finally, for any given object kind there's a fixed and clearly 
> > specified set of attributes that go with it. 
> 
> No, I think this is incorret. There is a fixed *minimum* set 
> of attributes, but the spec allows the implementation to add 
> attributes and objects of its own. It is easy to envision 
> even portable SCE-MI code accessing implementation specific 
> attributes. For example, different implementations might use 
> such attributes to store information that allows the application 
> to fine tune its performance or change aspects of how the 
> implementation handles messages. So highly tuned SCE-MI IP code 
> might want to probe for different attributes to find out if it 
> is running under a particular implementation. 


johnS: 
I wonder if we should tighten this up to restrict it 
to just the necessary parameters to characterize the interface 
which is what the pre-defined ones do. 


My concern is that as soon as you allow implementation defined 
parameters, you allow for unportable code. 


Restricting it to a standard set guarantees portability. 


> 
> Another aspect is that the current defined standard set of 
> attributes may be augmented in the future and some users may 
> want to write code that can run on several versions of SCE-MI. 



johnS: 
If standard object kinds are augmented in the future then we can 
assume newer code that accesses new object kinds on older interfaces 
well see NumberOfObjects() = 0 in those cases so, there's still 
no need for expanded error status. 


> 
> If all you get is a fatal error on looking up a non-existent 
> attribute, then the application code has no way of telling 
> what the error really was. Ok, it could just assume that 
> it was just a benign fatal error (isn't that an oxymoron, anyway?) 


johnS: 
Again, I think if we restrict the parameter set to only that 
defined in the standard we resolve this. Do you agree ? 


That is not to say we cannot expand the standard parameter 
set in future revisions. But restricting parameters to the 
standard set guarantees that code is portable among vendors. 


In retrospect, so far in our implementation we've had no need 
to expand the SCE-MI parameter set. We handle all vendor 
specific parameters in a separate config file. This is probably 
the way it should be anyway since once cannot possibly predict 
all the different possible vendor specific parameters within 
that standard. Therefore, my feeling is that the specification 
should not concern itself with this. 


> such as attribute not found and continue, but then if it was 
> really a true fatal error it is likely to get more and perhaps 
> the application will segfault eventually without giving the 
> user a good indication of what went wrong. 


johnS: 
I guess I'm looking for a "closed system" where there is 
minimal ambiguity. We already handle all possible fatal errors. 
And all possible recoverable errors are handled on a call by 
call basis for each of the calls where it is relevant. I would 
prefer to keep this philosophy for future enhancements of the 
interface.