Is Schematron a rules language?

By Rick Jelliffe
January 23, 2009 | Comments: 1

Many readers will have come across various initiatives regarding so-called business rules such as the W3C Rules Interchange Format and so on, and some may have wondered where Schematron fits into these efforts. Schematron's assertions are held in rule elements, but is Schematron a rules language at all?

I see three different uses of the term "business rules".

The first comes down saying that there are static constraints that only apply to atomic data or structures, and then there are dynamic constraints that apply between data values and elements etc. This view is associated with DBMS developers: the static constraints are things that belong in a schema, and the dynamic constraints are business rules that belong in an application. I suppose XSD v1.0 is a good example of this split. In this usage, then Schematron certain is a language for business rules.

The second is the kind of use that S1000D (aerospace documents) has with its Business Rules system: it provides a mechanism for stating various policies about the information in natural language and for associating those policies with elements (through an XPath.) According to Joel Amoussou, S1000D v3 will ramp this up by expressing them with Schematron, which allows them to be tested. (Indeed, you can also express constraints in Schematron that you cannot test: see this blog item.)

The third kind is where there the rules form an if-then pattern: there is a test but also some consequence or action. This is the model for the W3C RIF for example. Schematron is not this kind of rules language: it detects the presence or absence of patterns in a document, using a pretty good XPath mechanism, and it can report the results (e.g., using the standard Schematron Report Validation Language SVRL). And you could then grade the reports in turn using a subsequent Schematron schema. But Schematron has no built in notion of actions or results.

In fact, the rule element in Schematron is the least semantically interesting element in a schema: the Schematron assertion is a concept (a positive natural language statement), the Schematron pattern is a concept (a way for a schema document to be composed of multiple independent loosely-coupled sub-schemas without necessarily being restricted to namespaces), and the Schematron phase is a concept too. But Schematron rules are only really a container to establish a context, not some conceptual class. Assertions are important, patterns are important, phases are important, but rules are just plumbing.

The reason I don't have a problem with the ISO standard for Schematron to be called rules-based validation - Schematron is that Schematron belongs to the class of simplest data-driven forward-chaining expert systems and rules is a standard term of art for these systems: operationally, Schematron is just a big case statement. (Some people may even say that Schematron is not an expert system because it doesn't use strategy. That is cool.)

You might also be interested in:

1 Comment

Slightly off topic, I suppose. But what should I use for a Schematron implementation? Should I use the "reference" implementation?

News Topics

Recommended for You

Got a Question?