RE: [xml-dev] Separate data from rules ... is the XML Schema 1.1<assert>

["Costello, Roger L." <costello@mitre.org>]

Hi Folks,

Here's a recap of what I've learned from this very illuminating discussion:


XML Schema 1.0 gives you a way to impose rules on the *structure* of XML instance documents; that is, what elements and attributes XML instances can contain and where.

But there are some rules about the structure of XML instances that cannot be expressed, such as:

    A paragraph cannot appear nested within 
    another paragraph unless there is an 
    intervening table.

However, in XML Schema 1.1 you will be able to express this "structural rule" using the <assert> element.

That's the good news.

Now for the bad news.

It will require enormous self-discipline and knowledge on the part of schema developers to use the <assert> element correctly; that is, to use it for expressing structural rules. 

There will be an enormous temptation to use the <assert> element for expressing non-structural rules. 

Non-structural rules are business rules. Business rules should be not expressed in XML Schema.

Here are a few examples of business rules:

    A Level 1 manager has a maximum signature
    authority of $10K.

    An auto loan applicant, living in Ohio, is
    underage if he/she is under 18 years of age.

    If a customer has no outstanding invoices, 
    then the customer is of preferred status.

    Security Classification Rule: No paragraph 
    may have a classification higher than the 
    overall document's classification.

Business rules should be managed separately. Business rules drive the behavior of the business. They need to be analyzed for dependencies, correctness, and completeness. That's completely outside the scope of XML Schema.

Unfortunately, business rules *can* be expressed using the <assert> element. However, doing so creates a schema that is a spaghetti of 

    - rules which constrain the syntax of XML instances, and 
    - rules which influence the behavior of the business. 

I see this to be no less harmful than burying business rules inside application code;  the result of this is well documented: it results in a business that is unable to adapt to a changing environment. 

/Roger