[
Lists Home |
Date Index |
Thread Index
]
Len,
Why have the schema muck with this stuff at all?
If you are going to have to use another layer to do the
validation - why separate out part of it and delegate
it elsewhere?
And especially if you create registries of definitions
that are referenced by the transactions - then it becomes
moot - since the registry provides you the ability to
manage the rules and propagate changes. That's the rub.
Hard wiring in local contraints usually comes back to
haunt you - even if you think what you are hardwiring is
unlikely to ever change....
Cheers, DW
=============================================================
Quoting "Bullard, Claude L (Len)" <len.bullard@intergraph.com>:
> 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
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
|
