Re: defaults

> It would be really nice to start in that direction by
> putting defaults in the "goal, but not requirement" section
> of our requirements/use-cases document, citing the implementation
> challenges Peter et. al. have pointed out on the one hand,
> and the use cases Guus et. al. have pointed out on the other.

Considering the current level of disagreement among group members, I
would support putting defaults as a goal but not a requirement.

> Hmm... I wonder if we have an un-stated requirement for
> monotonic reasoning? I know monotonicity is a requirement,
> for scalability, in my view. I'd like to see that
> discussed in the design goals, if not listed as a specific
> requirement. (In order to make it a specific requirement,
> I should provide a compelling use case that depends
> on it. I hope to do so, but I'm not confident I'll  find
> time, nor am I confident that we'll want to devote
> much space in our document
> to that sort of thing; I hope it's sufficiently
> clear to folks after a brief design-goal level discussion).
> 
> JeffH and requirements editors, please let me know what
> you think of this suggestion.

I don't know if there is enough of a group consensus to make monotonic
reasoning a requirement. A number of individuals (Pat Hayes, Peter
Patel-Schneider, etc.) have made extremely strong cases why it should
be, but I think those who support defaults and similar techniques are by
definition against it. Thus, I think the issue should be discussed
further before we decide how to treat it in the Requirements document
(note this is my personal opinion, and does not necessarily represent
the opinions of the other editors).

Jeff Heflin
Lehigh University

Received on Wednesday, 23 January 2002 11:50:22 UTC