Write Programs That Don't *Do* Anything ... ExpressRelationships/Rules

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

Hi Folks,

Recently I read something [1] that is very exciting and want to share what I learned. 

Rules are important. And they are everywhere.

A key new feature of XML Schema 1.1 is the ability to express rules. For example, you can express this rule:

    Level 1 managers can sign off on purchase requests 
    that do not exceed $10K.

Rules are all about expressing relationships. Recall from your school days you learned this mathematical relationship:

    2 + 3 = 3 + 2

This relationship uses specific values. You learned that the relationship can be generalized: 

    For any value x and any value y:

        x + y = y + x

You can call this a relationship or a rule. And it always holds true.


Here's another example: 

    A rectangle that is 6 units in length and 
    5 units in breadth has this area:

        30 = 6 * 5

This can be generalized to:

    Area = Length * Breadth

It is important to recognize that this relationship is not "assigning" Area the result of multiplying Length and Breadth, i.e., it isn't doing anything. Rather, it is a statement of the relationship that exists between the Area of a rectangle and its Length and Breadth: 

    If you multiply Length and Breadth the result is 
    the Area of the rectangle.

x, y, Area, Length, and Width are called variables. They are called variables, not because their values vary, but because they are symbols that denote any value.


One more example: 

   The sequence (3, 2) is the reverse of this sequence (2, 3).  
   We can express the relationship like this:

       (3, 2) = reverse((2, 3))


In all three examples the expressions are not doing anything; rather, they are stating relationships/rules. 

Imagine writing a program which doesn't do anything; instead, it is simply a collection of relationships/rules.

There are several reasons for doing this:

Your program can be executed in parallel or in any order. For example, consider the following program which consists of two statements:

-----------------------------------------------
Variables:
      Let s1 denote the sequence (2, 3).
      Let s2 denote a sequence.
      Let Length denote the value 6.
      Let Breadth denote the value 5.
      Let Area denote an area of a rectangle.

Program:
        1. Area = Length * Breadth
        2. s2 = reverse(s1)

Output:
        The area is: Area
        The reverse of the sequence is: s2
-----------------------------------------------

Clearly the two program statements can be executed in any order or even in parallel.

Furthermore, suppose the program outputs this XML document:

<Document>
      <Rectangle>
            <Length>6</Length>
            <Breadth>5</Breadth>
            <Area>30</Area>
      </Rectangle>
      <Sequence>
            <Original>
                  <First>2</First>
                  <Second>3</Second>
            </Original>
            <Reversed>
                  <First>3</First>
                  <Second>2</Second>
            </Reversed>
      </Sequence>
</Document>

Then we can use XSD 1.1 assertions to validate the program's output (and thereby implicitly validate the program):

<assertion test="Area = Length * Breadth" />
<assertion test="(Reversed/First, Reversed/Second) = reverse((Original/First, Original/Second))" />


We've seen two benefits to writing programs as a collection of relationships/rules:

First, your program statements can be executed in any order or even in parallel. This means that your program doesn't have to run on a von Neumann machine.

Second, using XSD 1.1 assertions you can (implicitly) validate your program.

Wow!  Wow!

And there's a third benefit: the program statements can be incrementally updated. In the above program, suppose the rectangle is stretched, thus resulting in a new Length and Breadth, that's okay because it simply results in updating this relationship:

    Area = Length * Breadth

The other relationship is not impacted.

Incremental updates, processing in any order or even in parallel, and program validation ... awesome!

What I've just described is XSLT (and XSD 1.1 for validation).

XSLT and XSD 1.1 rocks!

/Roger

[1] XSLT 2.0 and XPath 2.0 by Michael Kay, p. 986 - 987.