This is an excellent summary.
A few other things of potential interest that we have found...
Most constraints are associated with scope (kind of CAM's context) that determine when they are applicable/relevant for enforcement.
From what we have been seeing constraints have a validity period - kind of a start date and end date.
Also constraints can be categorized into variant constraints and invariant constraints.
Many syntactic constraints actually tend to be variant constraints.
Many constraints are also tied to the lifecycle of an object.
Constraints may have precedence/specificity/priority, and execution dependencies that determine the order in which constraints need to be executed.
We tend to differentiate b/w constraints and business rules - with action of the constraints being purely error reporting - while business rules can take any action - but this may be an arbitrary distinction (i.e. more ECA kind of rules rather than deductive rules).
Given the above distinction, most business rule actions tend to be procedural in nature - unless a vocabulary(library) of actions have been defined and the expression language enhanced to refer to this library of actions from the language.
Depending on where constraints are enforced (client side - thru javascript, etc) or back-end - the issues involved vary significantly.
You also tend to have constraint chaining - when there are dependencies b/w constraints.
Haven't come across much of constraint inferencing (kind of gets us into deductive rules, etc) but these may exist.
On a separate note I was wondering are identity constraints used in XML databases? I haven't worked on them - but was curious if anybody had any thoughts inputs on these.
prakash
----------------------------------------------------------------------------------------------------------------------------
Hi Folks,
An excellent, important discussion! Below I have summarized what I
perceive
as the key issues. Comments are very welcome.
Here are the two problems that we have been considering:
Problem #1
A company has employees. The current company policy is that the
minimum age
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
will
result in sending up error flags. Should the IT department run the
business, or should the business run the IT department?
Problem #2
A person from the UK makes an online purchase from a US supplier. The
online
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
person
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
identified:
1. "Syntactical" or "structural" validation
2. "Semantic" or "business rule" validation
"Syntactical" or "structural" validation is useful in eliminating a
certain
number of mechanical data entry errors, such as leaving out required
items
or putting strings in fields that require numbers (e.g. phone numbers,
dates, etc.)
"Semantic" or "business rule" validation captures some aspect of a
business'
requirements. An example is validating that a credit card is
acceptable.
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
advantage
of these tools is that the constraints they express
are easily changed.
The
disadvantage is limited expressiveness (consequently, it may be very
difficult to express semantic/business rule constraints using these
tools).
The declarative-based tools are typically client-side tools.
The procedural-based tools include Javascript, Java, C#, etc. The
advantage
of these tools is that they have rich expressiveness. The disadvantage
is
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
"structural" validation.
The procedural-based tools are better suited for "Semantic" or
"business
rule" validation.
Other Issues
In a highly distributed system there is no definable "back-end" where
all
business rules may be validated. In such a case, it may be beneficial
to
push semantic/business rule
validation out to the client-side.
XML Schemas, XForms, CAM, Javascript - these are all a "means to an
end".
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,
but
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
is
UK then no value is required for the state code.
/Roger
