[
Lists Home |
Date Index |
Thread Index
]
John Sowa posted the following to the CG list.
Not surprisingly, I disagree with the conclusion
in this situation, but I do agree with the
rest of the text:
"The basic point of the paper is the following
restriction: "all quantifications are bounded
by some variables". This kind of restriction
is very common for most practical applications.
For database queries and constraints, an even
stronger restriction holds: every quantifier is
bounded by a *constant*, namely the cardinality
(number of rows) of the corresponding table.
In natural languages, it is extremely rare to
find any sentence with an unrestricted quantifier.
Even when the word "everything" is used, some
implicit domain is almost always intended.
Furthermore, those domains are almost always
finite. (The major exceptions are books, papers,
and courses on mathematics.)
In logic, a noun phrase such as "every employee"
maps to a typed, sorted, or restricted quantifier
of the form (Ax:Employee). Those quantifiers
usually have a constant upper bound, although
that bound may be very large for the domains
of people, bacteria, or web pages.
This means that for most practical applications,
theories stated in first-order logic with restricted
quantifiers are decidable. However, the domains
might be so large that even a polynomial amount
of time is beyond the age of the universe.
Bottom line: The most important issue is
scalability, not decidability."
From: Roger L. Costello [mailto:costello@mitre.org]
Hi Folks,
Here are some thoughts:
1. Constraints on data are not equal to business rules.
2. Business rules change. Constraints on data do not.
3. Constraints on data should be specified in XML Schemas. Business rules
should not. Business rules should be specified in higher level application
code.
Example:
A company has employees. The current company policy on the minimum age
requirement is 16. Should the company create an XML Schema that constrains
<minimum-age> to 16? Or, should the company create an XML Schema that
simply constrains <minimum-age> to an integer, and let applications higher
up provide further constraints?
Answers:
- Mandating that the minimum age of an employee be 16 is a business rule.
It is highly likely to change over time.
- The value of the <minimum-age> must be an integer. This is a constraint
on the data. It will not change over time.
Therefore, an XML Schema should simply constrain <minimum-age> to be an
integer. Higher level applications should implement the business rule that
<minimum-age> be further constrained to 16.
Comments?
How would you characterize the distinction between "business rules" and
"constraints on data"? /Roger
|
