Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Are people really using Identity constraints
 Roger Costello wrote: > How would you characterize the distinction between "business rules" and > "constraints on data"? Misleading. Or, rather, not a distinction that necessarily should play a part in systems architecture, except as one input to the design. In the same way, the distinction between different kinds of user interfaces such as whether to use field-level validation of forms, is useful as a design consideration but not as the basic for an information architecture. Similarly, you could make a distinction between contractual constraints versus unit testing constraints. Or constraints that can be checked by your DBMS and constraints that cannot. Or constraints that can be expressed declaratively in a way to allow automatic data-binding and those that cannot. They are constraints categorized according to the particular stakeholder, not fundamental categories in their own right. The fundamental distinction I see is between constraints that are necessary (~invariant) and those that are contingent (~variant). Over time, as the schema/DTD/constraints evolve, it becomes clearer which constraints are necessary and which are contingent. An example of a necessary constraint is where two items are tightly coupled: they only make sense as pair. For example, you cannot have a table without rows. An example of a contingent constraint would be that in HTML Strict you cannot use the blink (or that in some slack HTML you can us it.) I suspect that when people make the distinction between "business rules" and "constraints on data" they often end up just trying to squeeze their necessary and contingent constraints throught the lense of technology that supports static constraints at one tier at dynamic constraints at another. Or were there is inaquate feedback processes in place to allow corrections to quality problems caught late to be introduced earlier, as a matter of continual process improvement. People evolving schemas over periods of time, or with industry-agreement standard schemas where people agree to use common names for common things, but allow the schema to be big enough to cover each individual user's requirements, tend to go to the common architecture of a loose "vocabulary" schema, that in effect just expresses the necessary constraints. Then people overlay some constraining mechanism on top, to filter out the crap they don't want to deal with and to express the items of information they are interested in. XML Schemas is admittedly not powerful enough to express contingent constraints well--they are often dynamic--, but it is rather inconvenient for expressing static necessary constraints. In part this is because of content models: you really have to fight with grammars to make them open and extensible. In particular, many people are aware that enhancing a derived schema often involves rejigging the base schema. It is because XML Schemas started from the wrong position: "lets have base schemas and be able to derive schemas from them" rather than "lets have necessary schemas and be able to declare extra contingent constraints", which would have made "open" content models the default, for example. (This is an issue Roger championed, unfortunately too late!) Schematron was designed, in part, to allow the expression of contingent constraints. In particular, the <phase> mechanism allows variants to be bundled and named and invoked together. It is also quite good for expressing necessary constraints, or being the intermediate target for application-dependent (and declarative) constraint languages. As a side issue, I notice that people often just consider Schematron a front end for XSLT, therefore some kind of cheating. The default query language binding is indeed for XPaths a la XSLT, but other query languages are possible (and have been used by people). It is a general framework for make assertions. You could make an application-dependent (e.g. geography aware, time aware, currency aware, widget aware, business-process-aware) query language and use it in a Schematron. Cheers Rick Jelliffe 
|
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
|
|||||||||
