Lists Home |
Date Index |
A few more things of potential interest.
Given my previous post - on how we differentiate b/w business rules and semantic constraints due to the action part - We tend to see some other differences b/w business rules and semantic constraints - with constraints(/rules) being associated with priority/precedence, etc - in case of rules in most scenarios only a single rule gets selected - where as in constraints it can be a set (you incrementally add constraints).
The result of the above distinction is we know that constraints do not affect the state of the system - while rules can affect the state of the system.
With priority in picture - you tend to get into the monotonic vs. non-monotonic issues.
Also we find the following categories in case of syntactic constraints:
1. type constraints (datatyping)
2. format constraints (date formants, number formats, string formats)
3. the ubiquitious integrity constraints
4. structural constraints/path constraints/relationship constraints
An excellent, important discussion! Below I have summarized what I
as the key issues. Comments are very welcome.
Here are the two problems that we have been considering:
A company has employees. The current company policy is that the
of employees is 16. What happens when a 15 year old whiz kid is hired?
Validation by the IT department of the data file for this new employee
result in sending up error flags. Should the IT department run the
business, or should the business run the IT department?
A person from the UK makes an online purchase from a US supplier. The
supplier requires entry of a two-letter code in the "State" box and a
numeric value in the "postal code" box, despite the fact that the
entered UK as the country. So, the person entered "ZZ" as the state and
12345 as the postal
code. Does validation result in forcing people to
supply incorrect information?
In discussing these problems, two categories of validation were
1. "Syntactical" or "structural" validation
2. "Semantic" or "business rule" validation
"Syntactical" or "structural" validation is useful in eliminating a
number of mechanical data entry errors, such as leaving out required
or putting strings in fields that require numbers (e.g. phone numbers,
"Semantic" or "business rule" validation captures some aspect of a
requirements. An example is validating that a credit card is
There are two categories of tools for doing validation:
1. Declarative-based tools
2. Procedural-based tools
The declarative-based tools include XML Schemas, XForms, CAM. The
of these tools is that the constraints they express
are easily changed.
disadvantage is limited expressiveness (consequently, it may be very
difficult to express semantic/business rule constraints using these
The declarative-based tools are typically client-side tools.
of these tools is that they have rich expressiveness. The disadvantage
that changes are not as easily made. The procedural-based tools are
typically back-end tools.
The declarative-based tools are better suited for "Syntactical" or
The procedural-based tools are better suited for "Semantic" or
In a highly distributed system there is no definable "back-end" where
business rules may be validated. In such a case, it may be beneficial
push semantic/business rule
validation out to the client-side.
If you are going to validate, then validate! In Problem #2 the user was
forced to enter a 2-character state code, despite being from the UK.
Several people noted that the problem was not with too much validation,
with not enough validation. If the system had been doing a good job
validating then "ZZ" would not have been allowed for the state code.
Further, full validation would have determined that if the country code
UK then no value is required for the state code.
Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now.