[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Are people really using Identity constraints specified in
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
Do you Yahoo!? Read only the mail you want - http://us.rd.yahoo.com/mail_us/taglines/spamguard/*http://promotions.yahoo.com/new_mail/static/protection.html.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|