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]
Separate data from rules ... is the XML Schema 1.1 <assert> elementa step backwards?

Hi Folks,

In the book Business Rules Applied, Barbara von Halle presents the Business Rules Methodology, which fundamentally is about separating rules from data: [1]

    A business rules methodology specifically
    removes rule considerations from the data
    and process tracks.

    The data and process tracks are reduced in
    content because they are devoid of rule

    You deliver a data structure with minimal
    rules in it.


Consider this XML document:

    <?xml version="1.0"?>
    <Document classification="secret">
        <Para classification="unclassified">
          One if by land, two if by sea;
        <Para classification="confidential">
          And I on the opposite shore will be, 
          Ready to ride and spread the alarm
        <Para classification="unclassified">
          Ready to ride and spread the alarm
          Through every Middlesex, village and farm,
        <Para classification="secret">
          For the country folk to be up and to arm.

Here's an example of a business rule:

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


XML Schema 1.1 introduces a new element: the <assert> element. It may be used to express business rules. 

The Security Classification Rule may be expressed like this:

    <element name="Document">
                <element name="Para" type="ParaType" maxOccurs="unbounded">
            <attribute name="classification" type="classificationLevels" 
            <assert test="if (@classification eq 'top-secret') then 
                             not(Para/@classification != 'top-secret') else 
                          if (@classification eq 'secret') then 
                             not(Para/@classification = 'top-secret') else
                          if (@classification eq 'confidential') then 
                             not(Para/@classification = 'top-secret') and 
                             not(Para/@classification = 'secret') else
                          if (@classification eq 'unclassified') then 
                             not(Para/@classification = 'top-secret') and 
                             not(Para/@classification = 'secret') and 
                             not(Para/@classification = 'confidential') else
                          true()" />

Notice the use of the <assert> element to express the security classification business rule.

This example illustrates the co-mingling of data and rules. According to the Business Rules Methodology this is not advisable (it hinders the ability of a business to make changes).

Up till this moment in XML's history the separation of data and rules have been enforced by the technologies:    
   - Data structure and vocabulary was 
     expressed and managed using XML Schema 
     or RELAX NG, and 

   - Rules were expressed and managed using 

The <assert> element changes things. Rather than technology enforcing the separation of data and rules, it is incumbent on developer discipline to enforce the separation.

Is the XML Schema 1.1 <assert> element a step backwards? 


[1] Business Rules Applied by Barbara von Halle, p. 66-67. For more information on the Business Rules Methodology see:

  - Business Rules and Information Systems by Tony Morgan
  - Principles of the Business Rules Approach by Ronald G. Ross
  - Wikipedia: http://en.wikipedia.org/wiki/Business_rules_approach

[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