XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Lessons learned from the XML experiment

On Mon, Nov 11, 2013 at 5:38 PM, Michael Kay <mike@saxonica.com> wrote:

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.

Giant +1 to the above. Very well put. I tend to use the term "strong static typing" as a shortcut for the various systems of constraints from mainstream imperative programming and RDBMS, inherited into XML from both.  For me the problem with not with the very idea of constraints but with the widespread nature of strong static typing. I agree with you that constraints are an imperfect response by imperfect programmers developing applications for imperfect humans in an imperfect world. But strong static tying is not really the language of the real, imperfect world. We miss the opportunity to allow developers to express constraints in language flexible enough for the real, imperfect world. And there is nothing esoteric about what such better constraints systems would look like. DTLL is a pretty good start. Another problem is one you hinted at: "So why do you reject the data, rather than just marking it suspect?" Rather than making constraint testing a 0 or 1 gateway, why not have systems that support annotations based on assertions, and these can be dealt with further along the process chain, including by rejecting the input if necessary, or perhaps through some sort of fixup or notification of humans in a governance role. Again there is a useful exemplar of such a system: Schematron.


--
Uche Ogbuji                                       http://uche.ogbuji.net
Founding Partner, Zepheira                  http://zepheira.com
Author, Ndewo, Colorado                     http://uche.ogbuji.net/ndewo/
Founding editor, Kin Poetry Journal      http://wearekin.org
Editor & Contributor, TNB     http://www.thenervousbreakdown.com/author/uogbuji/
http://copia.ogbuji.net    http://www.linkedin.com/in/ucheogbuji    http://twitter.com/uogbuji


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


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

Copyright 1993-2007 XML.org. This site is hosted by OASIS