Suggest @src on xf:bind

Dear all,

ABSTRACT
The current definition of xf:bind connects business rules too closely with
the user interface. xf:bind is much better seen as being closer to the data
and schema, than the UI, and for this reason needs to be expressible outside
of the UI (i.e., external to an XForms form). This will also promote re-use
of rules in large systems.

Within XForms 1.0 the easiest way to achieve this would be by allowing
linking properties on xf:bind. For XForms 2.0 I would suggest that xf:bind
is taken out altogether to a separate spec, sitting above XML Schema.


INTRODUCTION
One of the clear advantages to using XForms to build 'Internet Applications'
is the ability to clearly delineate lines of responsibility for various
parts of the system. For example, one person could be given the task of
creating all of the help text, captions, hints and so on for an application,
and placing these in a database or XML document. It is then a simple matter
for all forms to use the common text, but more importantly, maintenance of
the text does not become a programming issue (i.e., it is *not* maintenance
of a form, but simply maintenance of some data or file).

Similarly, the fact that schemas can be external to the forms allow for
changes to the underlying data structure, which are managed independently to
the forms themselves.

And of course, the instance data itself can be managed completely
independently of the forms that use it. For example, programmers and
database administrators can create documents that contain lists of clients,
invoices, or whatever, without having to concern themselves with how that
data will appear in a form.


EXTERNAL BINDINGS
In this spirit - that XForms makes *maintenance* of a large system easier -
I would like to suggest we go further, and have a more widespread use of the
'src' attribute as defined in 3.2.2. Whilst there are a number of situations
that I think this would be useful for, I think the easiest to incorporate
into the spec would be xf:bind.

Adding linking properties to xf:bind would allow a set of bindings to be
defined and maintained, independently of the form or forms in which they
appear. This would allow bindings to be declared centrally so that they move
in harmony with one or more schemas, independently of any one particular
form.


EXAMPLE 1 - Centralised Business Rules
An example might be that we have a central schema that allows the creation
of a delivery address as follows:

  <Delivery type="3">
    <Address>
      <Street1>4 Pear Tree Court</Street1>
      <PostCode>EC1R 0DS</PostCode>
    </Address>
  </Delivery>

Whilst the schema can express the connection between the elements, it cannot
express that the delivery address is only required if the delivery type is
'3'. It may be, for example, that delivery type '1' means that the delivery
address should be picked up from the purchaser's records, whilst delivery
type '2' might mean the delivery address should be picked up from the
recipient's records. This third option is required when neither address is
suitable, and therefore requires that an actual address is entered:

  <xf:bind nodeset="Address" required="/Delivery/@type=3" />

The notion that "an additional address must be provided if the delivery type
is '3'" is essentially a business rule that may apply across an entire
application, or even anywhere that this schema is used. It is therefore
important that rules such as these can be maintained centrally without
concern for where these rules are used. It would be useful, for example, to
be able to do something like this:

  <xf:model id="mdlPurchase" schema="schemas/purchase.xsd">
	<xf:instance src="purchase.xml" />
	<xf:bind src="bindings/address.xml" />
  </xf:model>


EXAMPLE 2 - Populating Templates
An example that does not revolve around a schema would be when using some
data to generate a chart, by filling in a chart template. The source data
could be in one instance, and the SVG template in another instance. xf:bind
is then used to 'build' the chart from the data, poking the data from the
source into the correct positions in the chart, perhaps with modifications,
scaling, and so on:

  <xf:bind
   nodeset="xforms:instance('instSVG')/svg:rect/@height"
 
calculate="xforms:instance('instData')/item[count(current()/../preceding-sib
ling::svg:rect)+1]"
  />
  <xf:bind
   nodeset="xforms:instance('instSVG')/svg:rect/@y"
   calculate="182 - ../@height"
  />

In the previous example the @height of an svg:rect is set to the data from
some data source, and the vertical position (@y) is then calculated from the
@height. The power of xf:bind is that whilst our SVG template may stay the
same (and we would want it to, to promote re-use), if the format for the
source of the underlying data changes we can change our bind statements.
However, as things stand, xf:bind is a feature of the form, not the data.


EXAMPLE 3 - Server-side Validation
A third advantage to having externally defined xf:bind statements is that a
server could use the information as part of its validation process. Whilst
we would not expect XForms necessarily to define exactly how the server goes
about establishing what bind rules were used when a particular form was
filled in, there is at least the possibility that they can be found, if they
are externally defined.

This will be very important when building large systems and workflow
applications. If we take the address example given earlier, there is nothing
to stop an address being submitted by some other means, in which the
delivery type is '3' and there is no additional address. This logic needs to
be defined somewhere for the server, so it may as well be in a document
containing xf:bind statements.

(This may require modularising the schema so that we can validate the bind
documents, which is a longer term issue touched on below.)


PROPOSAL 1
One possibility is to add to 3.3.4, under 'Special Attributes':

  Linking Attributes 
  Optional link to externally defined binding information. If the
  link traversal fails, it is treated as an exception (4.5.2 The
  xforms-link-exception Event).


The link behaviour is already defined, in that the target document is
embedded underneath the element that contains @src during the document load
phase (as described in 3.2.2). Since xf:bind elements can be nested then the
syntax of xf:bind would be unaltered. For example:

  <xf:bind src=" bindings/address.xml" />

would simply result in:

  <xf:bind>
    <xf:bind nodeset="Address" required="/Delivery/@type=3" />
  </xf:bind>

As far as I can see all xf:bind attributes are optional, so an xf:bind that
serves only to contain other xf:binds is already legitimate.


PROPOSAL 2
Another way of achieving this would be to have another attribute on xf:model
called @binding. This would be much like @schema in that it would refer to a
'binding' document. I would prefer this solution because it would allow
things like this (i.e., re-use of binding rules even within a form):

  <xf:model id="m1" binding="#b">
    ...

  <xf:model id="m2" binding="#b">
    ...

  <bind:bind id="b">
    ...

The problem is that it would require larger changes to XForms, namely the
removal of xf:bind to a separate spec (no bad thing, for reasons I gave
earlier about server-side validation, but unlikely to happen). I include it
here just for completeness.


CONCLUSION
Being able to define bind rules independently of any one particular form
would be very useful. In the short term this could best be achieved by
allowing linking properties on xf:bind.

Regards,

Mark


Mark Birbeck
Co-author Professional XML and
Professional XML Meta Data,
both by Wrox Press

Download our XForms processor for IE
from http://www.FormsPlayer.com/

Managing Director
x-port.net Ltd.
4 Pear Tree Court
London
EC1R 0DS

E: Mark.Birbeck@x-port.net
W: www.x-port.net
T: +44 (20) 7689 9232

Received on Monday, 17 February 2003 15:46:12 UTC