Re: [xml-dev] Lessons learned from the XML experiment

[Michael Kay <mike@saxonica.com>]

> 
> No.  'Data' never requires constraints.  It just is.  The constraints reflect our preference for simpler situations that are easier for us to record and especially to process.  The world, even people, is always more flexible than we can accept.
> 
> We forget that, and run off and create giant piles of constraints, and pretend that they are capabilities rather than signs of our (and our tools') deep brokenness.
> 


It has always struck me how almost all examples of "integrity constraints" found in the database literature are constraints we choose to impose on the world, rather than constraints that the world imposes on us - classic examples being that employees must be aged over 16 and under 65. I often ask people who design such systems what they would do if they are informed that the director of the company's operation in Egypt has just hired a 12-year-old tea boy. Tell him he's not allowed to do that?

Such a challenge tends to get one of a number of responses:

(a) I didn't write the rules, they are in the process manual / requirements / etc. 

(b) Yes it could happen that someone's name contains characters that aren't in Unicode, or that their salary exceeds $2 billion, or that they were born in outer space, but we have decided on grounds of cost / system complexity that we aren't going to handle this case.

(c) The constraint is there not because we don't want to handle this case, but because we know our system contains a component that can't handle this case and we therefore need to provide a filter that catches this case before it reaches that component (i.e., yes, we know our systems are broken, but that's life).

(d) The constraints are there to catch implausible input because there is a high probability that if these conditions are violated, the data is bad. [So we do you reject the data, rather than just marking it suspect?]

In a perfect world, we wouldn't put such constraints in our systems. However, I don't think that systems that have such constraints are "deeply broken". On the contrary, I think all human attempts to monitor, regulate, and systematize the world we live in rely on putting things into categories and labelling the categories as if they were unambiguous. Constraints saying that every company has two or more directors are typically imposed by legislators rather than IT people, and it's often IT people who have to cope with the fact that the constraints are broken (does the company cease to exist if the directors are killed in a plane crash?). We simply don't have the ability to design systems without such constraints, and a constraint language that enables us to be explicit about the constraints the system is imposing makes the system less broken than it would be if the constraints were there but not clearly articulated.

Michael Kay
Saxonica