This information is in part taken from the O'Reilly book XForms Essentials. Used with permission.

What is binding?

As you read in the last lesson, XForms accomplishes data capture through two components, the XForms Model and XForms User Interface. The connection between these two parts is called the binding, and it uses a common W3C technology called XPath.

In order to take advantage of binding, form authors need to provide an XML template, called instance data, that provides a place for entered data to reside. The instance data can either be initially empty (for a blank form) or can hold initial data (in the case of a pre-populated form). The ref attribute on each form control, seen previously, actually holds an XPath expression that points to a location in the instance data.

If you've had some experience with XPath, you probably know that XPath deals with node-sets, where a node is a fundamental bit of XML such as an element or attribute. Whenever XForms uses the ref attribute, it aplies the first node rule, so that even if XPath would normally return several nodes, only the first (in the order that things appear in the document) is used by XForms. In contrast, the attribute nodeset indicates that multiple nodes are in play.

Quick note on namespaces

Any serious XML work will inevitably run into XML namespaces, with the telltale xmlns attributes. Since this is the XForms Institute, not the Namespaces Institute, several simplifications are used here:

default namespace
The default namespace is applied to XHTML. It is possible that by the time XHTML 2 is finialized that XForms will share a namespace, so XForms elements too are considered defaulted.
user namespace
The prefix my: is used for most user-provided instance data.
A few other namespace prefixes, such as ev: for XML Events may appear, and will be explained as needed.

Keep in mind that in XPath expressions, no default namespace applies, and thus prefixes must be used liberally.

How binding works

First of all, as a child of the model element, an element called instance is needed to provide the instance data, which can be either inline XML, or in a separate document pointed to by a src attribute. For example, a fragment of a UBL document:

<model id="m1">
        <my:InvoicedQuantity unitCode="PKG">5</my:InvoicedQuantity>
          <my:Description>Box of Protractors; 500 count<my:Description>
  <bind nodeset="my:InvoiceLine/my:Item/my:Description" required="1"/>
  <submission id="s" method="put" action="po.xml"/>

This code sample includes the submission element as before, and additionally an instance element populated with real-world XML. It also has a bind element, the key to the power of XForms: it can work directly with nearly any kind of XML in existence.

The nodeset attribute gives a hint how this element works: it selects all the my:Description elements in the document. In a purchase order, you would expect several line items to be present, each with a description field. The XPath expression selects them all, and applies a property called "required" to each.

The XPath works much like a directory path, with each step descending one level into the XML. An attribute step is accomplished with a leading @ character, as in html:a/@href.

Do you recall?

In the area below, enter the nodeset attribute and XPath expression necessary to reach all unitCode attributes (a child of my:InvoicedQuantity), using the instance data above as a guide. (Hint: Don't forget the '@' at the attribute step) When you are ready, click the button to reveal the correct answer.

View Source : Validate

In the next lesson, you will learn more about XForms properties such as "required".