OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Are people really using Identity constraints specif ied in

[ Lists Home | Date Index | Thread Index ]


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>


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS