W3C home > Mailing lists > Public > www-forms@w3.org > May 2006

Declarative and imperative programming [was RE: Deploying (accessible) XForms today?]

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Thu, 11 May 2006 12:13:09 +0100
To: <www-forms@w3.org>
Message-ID: <00ab01c674eb$e2ee6a50$7e01a8c0@Jan>


> But here is where Ian Hickson is right: at some point, you 
> will write something like this:
> <xf:action ev:event="xforms-value-changed">
>    <xf:setvalue ref="my/node/a">Hello</xf:setvalue>
>    <xf:send submission="my-submission"/>
>    <xf:setvalue ref="my/node/b" 
> value="instance('some-instance')/node-b"/>
>    <xf:toggle case="ok-case"/>
> </xf:action>
> The above clearly *is* scripting. It doesn't use Javascript 
> as far as the developer is concerned, and it uses a level of 
> semantics above what you usually do with Javascript, but it's 
> imperative scripting
> nonetheless: it gives the XForms engine instructions that 
> must be executed in a sequential order.

It most definitely is *not*...:)

I have to disagree with both you and Hixie here. (I also looked at Hixie's
arguments over a year ago in an article called "The 'XForms Myth' Myth" [1],
if anyone is interested, and there is an interesting reply from Hixie on
there, too.)

The reason I would say it's not like scripting is because of what you are
not seeing in those four lines. To work this through, let's say that the
snippet you showed was some new XML programming language called 'xf'. In
this code you have set a value, submitted some data, set another value, and
then toggled some part of the display; we agree that this certainly seems
all very imperative.

However, let's add a bit more functionality. For example, we would like to
say that if the value in 'my/node/b' is not an integer, an error message
should be rendered. We'll continue to develop our new language ('xf'), but
in our 'imperative mindset' and, after much debate on the lists and
consultation, we decide to add an xf:if test, and an XPath function that
tests the value of a node against some datatype:

  <xf:setvalue ref="my/node/b" 

  <xf:if expr="valid(my/node/b, 'xs:integer')">
      I need an integer...give me an integer!

It all looks fine, and when you're dealing with small bits of code like this
it seems pretty logical for a language designer to say "we need to add a
feature so that we can do a test and then do something with the result of
that test".

But of course, you know as well as I do that this is not at all 'fine'. It's
labour-intensive, unmanageable, and will produce 'spaghetti' code just like
JavaScript does...except it will do it in XML!

(As an aside, there is a common misconception that XML = declarative; this
mistake comes up, for example in discussions about languages like XAML,
which are assumed to be declarative just because they are XML-based.)

So, how did the XForms designers approach this question? Well, as everyone
now knows they took the declarative or 'functional' approach [2], but they
also made sure that they looked for what you might call patterns. In our
example, a traditional programming approach would be to say, "although the
use case is to test the type of a node before showing an error message, I'm
going to add a feature that allows *anything* to be tested, and *any action*
to be carried out after that test". In this case the 'traditional' approach
certainly appears to give lots of power, but in reality it gives too much.

The XForms approach does thing differently, and says that if there is a
common 'pattern'--in this case it's along the lines of "if some value fails
to be validated show an error message"--then we should provide support for
that pattern, rather than trying to generalise it too much.

The result is firstly, that XForms provides the author with a nice simple
way of saying that 'my/node/b' must be an integer:

  <xf:bind nodeset="my/node/b" type="xs:integer" />

And secondly, XForms provides the author with a nice easy way to indicate
that some message should be displayed if the value is not an integer:

  <xf:input ref="my/node/b">
    <xf:label>Node B:</xf:label>
      I need an integer...give me an integer!

With the bind statement, the author:

 * doesn't have to remember to check the type of this
   node everywhere that the node might have changed;

 * and if they want to change the type--say, to double
   or float--they don't have to search their code for
   all occurrences of statements that check the type;

 * and if they do make the change, by putting the
   'declaration' in just one place they don't run the
   risk of discovering later on that they didn't
   change every occurrence.

In other words, accuracy is increased and maintenance time and bugs are

That's the beauty of bind, but with the input and alert combination, the
XForms design really leaps light-years ahead of our procedural/imperative
alternative, by completely decoupling the *state* of the data from its

Instead of having the imperative 'if this do that' approach, we have a
highly flexible, decoupled architecture, where each 'component' doesn't need
to know much about any other 'component':

 * the xf:alert does not need to know *why* the control is
   invalid, it just needs to know that it is;

 * the input doesn't need to know anything about the
   existence of the alert;

 * the bind statement doesn't need to know why the data
   has changed, it just needs to know that when it does
   change it should check the data type again;

 * the bind statement also doesn't need to know what is
   'listening' to know when the data goes invalid, it
   just needs to know that it should notify whatever is
   listening when the data is invalid (not an integer).

The combination of these 'decoupled' objects is that you can independently

 * the test in the bind statement (integer, etc.);

 * the control that is using the data (from input to
   range, for example);

 * the message to be given to the user (in the alert);

all without affecting any of the others...in fact without even needing to
know that the others exist!

The key thing therefore in the design of the language is to try and find
patterns that can be broken down into declarative statements. And the
impressive thing about the patterns that have been found so far (i.e., the
current specifications) is that they are sufficiently powerful to have meant
we are only just now needing to add 'if' and 'while' statements. In other
words, we've been producing useful forms without them for a couple of years
now, which shows the range of use-cases that are captured by the
decoupled/declarative approach.

So, in summary, the only reason Hixie (or you, Erik!) are able to say that
those four lines are imperative is because they don't show what is happening
'for free'. But adding more functionality to that program will quickly show
how XForms is very far removed from an imperative language.

Finally, I had much the same discussion over on the SVG list in November
2004, which I summarised on my blog at the time:

  Loosely Coupled Objects and Declarative Programming

Many of the same issues came up then, so whether people agree with my points
or not, they might find the different positions people adopted in that
thread of interest.( Also, the article looks at XForms' relationship to OO
programming, not just the imperative procedural discussion.)

There are also a few other articles on my blog on XForms and declarative

  XForms: An Executable Pattern Language:

  On Adobe and XForms via Declarative Programming, Wizards and Aspects



[1] http://internet-apps.blogspot.com/2005/03/xforms-myth-myth.html

[2] Many of the early XForms language designers have a background in, or
sympathy for, what you might call functional programming. I'm thinking here
of Steven Pemberton, T. V. Raman, John Boyer and Roland Merrick...those are
the ones I know for sure, but it wouldn't surprise me if other early
contributors were also of the same view.

Mark Birbeck
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
b: http://internet-apps.blogspot.com/
w: http://www.formsPlayer.com/

Download our XForms processor from
Received on Thursday, 11 May 2006 11:15:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:17 UTC