Re: Write Programs That Don't *Do* Anything ... Express Relationships/Rules
Frank Manola <fmanola <at> acm.org>
2009-12-10 15:06:43 GMT
Roger--
Re the subject: I think there are already too many people who write programs that don't do anything; no
additional encouragement is necessary.
There are also "cons" to the approach you're describing. You might want to do some background reading in
topics such as logic programming, relational programming, and rule-based programming. That's
essentially what you're talking about (with the addition of angle-brackets).
--Frank
On Dec 10, 2009, at 7:49 AM, Costello, Roger L. wrote:
>
> 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.
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe <at> lists.xml.org
> subscribe: xml-dev-subscribe <at> lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
_______________________________________________________________________
XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe <at> lists.xml.org
subscribe: xml-dev-subscribe <at> lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
RSS Feed