This information is in part taken from the O'Reilly book XForms Essentials. Used with permission.
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.
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:
my:is used for most user-provided instance data.
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.
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"> <instance> <inv:Invoice> <my:InvoiceLine> <my:InvoicedQuantity unitCode="PKG">5</my:InvoicedQuantity> <my:Item> <my:Description>Box of Protractors; 500 count<my:Description> </my:Item> </my:InvoiceLine> </inv:Invoice> <instance> <bind nodeset="my:InvoiceLine/my:Item/my:Description" required="1"/> <submission id="s" method="put" action="po.xml"/> <model>
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.
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
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.
In the next lesson, you will learn more about XForms properties such as "required".