Re: Multiple specification of constraints

Eric Kaun wrote:

> "mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message
> news:40404af4$0$564$e4fe514c_at_news.xs4all.nl...
>

>>This is to general. I look at it this way: There are more sets of
>>constraints, each with a different purpose. The contraints at the
>>database serve to protect the integrity of the managed set of data.
>>The constraints at the user-interface on the other hand serve to assist
>>the user in providing the data he needs to provide in order to achieve
>>his goal.

http://dictionary.reference.com/search?q=constraint

con·straint ( P ) n.

1. The threat or use of force to prevent, restrict, or dictate the action or thought of others.
2. The state of being restricted or confined within prescribed bounds: soon tired of the constraint of military life.
3. One that restricts, limits, or regulates; a check: ignored all moral constraints in his pursuit of success.
4. Embarrassed reserve or reticence; awkwardness: “All constraint had vanished between the two, and they began to talk” (Edith Wharton).

> Constraints are those things that must hold true. When possible, the GUI
> shouldn't allow users to do otherwise. However, the operations the user
> performs on the GUI can result in intermediate states which are NOT valid
> according to constraints - for example, they're just not done entering all
> the data yet. So it may be an issue of temporal granularity - the GUI has to
> guide the user toward properly-constrained data. But I'd hesitate to call
> those constraints, even if they are implied by constraints.

Why the hesitation? Many Bank-ID's have redundancy designed into them, for instance French and Belgian modulo 97 checks (they *do* differ, but that is another story). Say a customer is constructing a message of type A, containing a Bank-ID <A1> for a bank with a user interface. While the designer of the user-interface very well knows that messages A will be rejected if an account whith key <A1> is not present in the bank's database, these redundancy checks ensure, that often made mistakes (forgetting one digit, swapping two digits, mistyping one digit) result in an *invalid* number. It is not a Bank-ID, and we can tell, without having to contact the bank's database. I'ld say this is a proper constraint to assist the user. Received on Wed Mar 03 2004 - 13:35:41 CST