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

[rjelliffe@allette.com.au]

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