Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@i...>: > 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@m...] > > 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> > >
|
