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

[Frank Manola <fmanola@acm.org>]

Roger--

This distinction about "structure" still doesn't seem all that clear- 
cut.  What about your security rule?:

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

This seems like a constraint on the structure of the document (the  
fact that it may be based on the value of an attribute doesn't change  
that).  Looking at this the other way, in what sense does this rule  
"drive the behavior of the business" (other than the behavior of  
constructing documents that are consistent with the rules)?

Also, you say

> 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.


What about the "structure" (or contents) of individual (which may or  
may not be complex) values?  For example, would you object to defining  
a security classification type in XML Schema for the "classification"  
attribute in your original example having values top secret, secret,  
confidential, and unclassified?

--Frank

On Jun 17, 2009, at 1:42 PM, Costello, Roger L. wrote:

>
> 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
>