XForms Essentials

Scientists and science fiction writers have long predicted many of the things now being made possible by web forms. For example, in a 1945 article in The Atlantic Monthly, Vannevar Bush wrote about a hypertext network he dubbed a "Memex." Even at this conceptual stage, the thought of using forms to access data came naturally, particularly in terms of drilling down through vast stores of information: "One might, for example, speak to a microphone, in the manner described in connection with the speech-controlled typewriter, and thus make his selections." How did such a technology come to be in real life?

Shortly after the initial tempering of HTML, various individuals began considering the usefulness of forms alongside hypertext. HTML Version 2.0, as presented in a document called Request for Comments (RFC) 1866, was the first time that web forms were seriously considered for standardization. That RFC captured HTML as found in common use prior to June 1994. At this point, HTML already included forms, thanks to a 1993 proposal called HTML+.

Care and maintenance of the HTML family of specifications have since been handed over to the World Wide Web Consortium, or W3C. The last non-XML-based version of HTML was version 4.01, which didn't change forms processing much. New development of the standard is taking place on a closely related technology called XHTML, where the X indicates an XML foundation. XHTML 1.0 and 1.1 were largely concerned with details of the transition to XML and ways to combine vocabularies, not with major changes to the language.

XHTML 2.0, in contrast, is making some improvements that aren't compatible with earlier flavors of HTML. The largest such change is the adoption of XForms as a replacement for the older HTML forms technology. As of August 2003, XHTML 2.0 is still under development, though it's clear that XForms will play a major role in the future of XHTML. Before we discuss XForms, however, a review of the older HTML forms technology will be helpful.

The introduction of the forms chapter in HTML 4.01 reads: "An HTML form is a section of a document containing normal content, markup, special elements called controls (checkboxes, radio buttons, menus, etc.), and labels on those controls. Users generally 'complete' a form by modifying its controls (entering text, selecting menu items, etc.), before submitting the form to an agent for processing (e.g., to a web server, to a mail server, etc.)."

The defining element for HTML forms is named, not too surprisingly, form. This element describes some important aspects of the form, including where and how to submit data. The content of this element consists of regular HTML markup, as well as controls.

Forms represent a structured exchange of data. In HTML forms, the structure of the collected data, called a form data set, is a set of name/value pairs. The names and values that are included in this set are solely determined by the controls present within the form, so that adding a new control element, as well as adding to the user interface, also adds a new name/value pair to the data set. Many authors take for granted this basic violation of the separation between the data layer and the user interface layer—a problem that XForms has gone to considerable lengths to alleviate.

Which control types are available in HTML forms? The following sections will answer this question.

<input type="text" name="name" value="Dubinko, Micah"/>

<textarea name="blogentry">&lt;strong&gt;The Joy of Named ...</textarea>

<input type="password" name="pass"/>

<input type="submit" value="Continue"/> 
<input type="reset" value="Clear Order Form"/> 

<input type="button" value="Calculate"/> 

<input type="radio" name="car" value="0"/> None<br/>
<input type="radio" name="car" value="1"/> 1 car<br/>
<input type="radio" name="car" value="2"/> 2 cars<br/>
<input type="radio" name="car" value="3"/> 3 cars<br/>
<input type="radio" name="car" value="4"/> 4 cars<br/>
<input type="radio" name="car" value="many"/> 5 or more<br/>

<input type="checkbox" name="referBy" value="td"/> Test driven a vehicle<br/>
<input type="checkbox" name="referBy" value="dlr"/> Visited an autotmotive dealer<br/>
<input type="checkbox" name="referBy" value="veh"/> Purchased/Leased a vehicle<br/>
<input type="checkbox" name="referBy" value="ins"/> Purchased automobile insurance<br/>

<select name="searchtype">
  <option selected="selected" value="all">all words</option>
  <option value="any">any words</option>
</select>

<select multiple="multiple">
  <option value="0">UNCONFIRMED</option>
  <option selected="selected" value="1">NEW</option>
  <option selected="selected" value="2">ASSIGNED</option>
  <option selected="selected" value="3">REOPENED</option>
  <option value="4">RESOLVED</option>
  <option value="5">VERIFIED</option>
  <option value="6">CLOSED</option>
</select>

<input type="file" name="attachment"/>

<input type="hidden" name="sessionID"/>

<fieldset>
  <legend>Personal Information</legend>
  <input type="radio" name="mstatus" value="M"/> Married<br/>
  <input type="radio" name="mstatus" value="S"/> Single<br/>
  <input type="radio" name="mstatus" value="X"/> Decline to state<br/>
</fieldset>

<form action="http://example.com/cgi-bin/submit-here" name="shake-poll">
  <p>Poll: to be or not to be?</p>
  <input type="radio" name="thequestion" id="radio1" value="b"/>
  <label for="radio1">To Be<label><br/>
  <input type="radio" name="thequestion" id="radio2" value="n"/>
  <label for="radio2">Not To Be<label><br/>
  <input type="radio" name="thequestion" id="radio3"/>
  <label for="radio3">Other (please specify)<label><br/>
  <input type="text" name="othersel"/>
</form>

According to developers, the most commonly cited problem with HTML forms is their dependency on scripting languages. Real-world HTML forms are reliant on script to accomplish many common tasks such as marking controls as required, performing validations and calculations, displaying error messages, and managing dynamic layout. This dependency results in complex documents, which are expensive and time-consuming to maintain, since a full-time programmer is practically necessary when dealing with that much script.

XForms helps reduce the need for script in several ways: by defining a framework for simple, XPath-based calculations and validations, by providing better user feedback on the status of the form, through dynamic features such as repeating tables and optional sections, and through a system of XForms Actions—elements that cause commonly needed actions such as setting focus or changing a data value.

A second limitation of HTML forms is the difficulty of initializing form data, as commonly happens when web sites "remember" past users and provide them the courtesy of not having to repeatedly enter information. As shown earlier, each form control has its own unique way of defining initial data, with small bits of initialization data spread all across the document. This means that in order to process a blank form into a filled form, either a new document needs to be constructed piece by piece, or an existing document needs to be patched in numerous places—one of the reasons why template-replacement facilities are commonly found in application servers. Constructing such forms is CPU-intensive and leads to bottlenecks on high-volume servers.

In XForms, form data is provided from an initial XML file, which can be external to the form definition. Since XForms is also flexible enough to deal directly with most XML data formats, piping initial data into a form is typically a simple matter of pointing a src attribute to an existing XML data source.

A third limitation of HTML forms is that the encoding formats, urlencoded or multipart, represent only "flat" data, or name/value pairs. Many types of forms, including purchase orders, would benefit from a richer data representation.

XML is a better foundation for most business documents than a flattened set of names and values. Since it has XML support as a fundamental requirement, XForms excels at helping users create those kinds of documents.

More subtle, but still serious, is a fourth fundamental design flaw in HTML forms: a hidden assumption of a one-step process—from a client to a server—with processing finishing there. In the real world, forms often travel in more complicated paths. For example, a vacation request form might go to a supervisor for approval, then to the human resources department, and finally to accounting for final processing. Managing HTML forms in such a workflow scenario involves reinterpreting the data format at every stage. Perhaps this is one reason why HTML forms aren't commonly seen in use for workflow.

XForms enables a different pattern: it allows form data, as an XML file, to be routed to various workstations, as needed. At each stop, the data is loaded into a form, which provides a viewport into editing all or parts of the document, and submitted again. This process can be repeated as many times as necessary, with any number of participants.

As the HTML Working Group became increasingly aware of the limitations inherent in HTML forms, they decided that they needed to develop a new, non-backward-compatible specification for web forms. To do this, they formed a subgroup (which later became a full Working Group) to define the requirements and begin the initial design work of XForms. They set out to produce a system that would fulfill the following requirements:

After a number of internal and published requirements documents, the first XForms draft specification was published on April 6, 2000. The title of this document, "Datamodeling Proposal for XForms," gave a strong hint about how undeveloped this initial effort was. In fact, the final versions of the XForms specification bear no resemblance at all to this first attempt.

Why was this? At the time the initial XForms Working Draft was under development, another W3C specification called "XML Schema" was gradually progressing through the W3C channels. In what later proved to be a costly diversion, the XForms Working Group initially decided to make the XForms data types differ from the ones in XML Schema, "due to different usage scenarios and target audiences." As an alternative, the specification spelled out a "simple syntax," which consisted of a number of XML tags such as string, money, and group, where the tags needed to be nested in a structure that mirrored the desired shape of the final XML that would be submitted. For example, to submit XML that looked like:

<poll>
  <vote>Vanilla</vote>
</poll>

You would have needed an XForms "data model" such as this:

<xform>
  <group name="poll">
    <string name="vote">
  </group>
</xform>  

Although avoiding all traces of XML Schema was attractive to some, it proved to be more trouble than it was worth for a W3C specification. Thus, on August 15, 2000, a very brief Working Draft was published, containing not the XForms specification but, rather, the message: "The Working Group is currently studying how to support forms where the data model is defined by an XML Schema plus form specific properties. The previous version of the XForms Data Model is being obsoleted while this work is underway."

The December 2000 and February 2001 Working Drafts expanded on this new direction, and rolled into the document the XForms User Interface and other pieces that were initially conceived as separate specifications. (The final version of the specification defines modules that have much the same effect.) One other notable aspect of these documents is that they contain the first reference to the XForms Model, or the core definition of a form independent of any user interface. And, of course, XML Schema datatypes made their appearance, though simple syntax clung on as an extra section.

By the publication of the June 2001 Working Draft, people were starting to gain more experience with XForms authoring. With this experience came the realization that the simple syntax wasn't actually simplifying matters. The core problem was that the simple syntax was required to redundantly mirror the structure of the instance data, or initial XML used as form data, forcing authors in many cases to create the same structure twice in slightly different ways. Even worse, it created interoperability problems between XML-Schema-XForms and simple-syntax-XForms. So out went the simple syntax. XML Schema datatypes turned out to not be that bad after all, and the initial instance data itself held all the structural information needed. Things were starting to look up. In short, this Working Draft was the first to strongly represent the final XForms specification.

A few more publication cycles followed in August and December 2001. These updates consisted mostly of editorial work, though a few notable new features included script interfaces to interact with instance data and a cleaned-up processing model. This led the way for the January 2002 "Last Call" Working Draft, and the associated call for public review of XForms. In five weeks, the public mailing list for comments received around 150 substantive comments—each of which needed to be discussed and given a response. Comments ranged from the aesthetic ("please use only lowercase tag names") to the technical ("don't deprecate the HTTP GET method") to the political ("don't publish again until you have a test suite"). Often different submitters made contradictory requests. All in all, it took several months, and an additional publication in August 2002, for the XForms Working Group to sort through all of the advice, make the necessary changes, and send responses to each comment, as required by the W3C process.

Finally, in November 2002, the XForms Candidate Recommendation was released, along with a call for implementations. Strong support from business and open source implementers, collected at a meeting in February 2003, helped identify pieces of the specification that were hard to implement. As of this writing in August 2003, XForms has reached the Proposed Recommendation stage, and is poised to become a final W3C Recommendation shortly thereafter.

The XForms "simple syntax" mentioned earlier served a worthy purpose: to make authors of existing HTML forms comfortable enough to consider making the jump to XForms. So, when the "simple syntax" went away, what replaced it? Literally nothing. Instead of trying to simplify form authoring by adding an additional layer of markup, the designers made XForms remain useful when removing a layer of markup. This extra layer is what needs to be written for the XForms Model, which can be safely omitted in forms of roughly the same complexity as an HTML form with no script. Unofficially, this became known as "lazy author" processing, in deference to the time-honored concept in software engineering of "constructive laziness," or the ability to recognize and actively bypass unnecessary work.

Example 1.14 shows a form that accomplishes the same goals as the earlier HTML form: a poll.

<select1 ref="mainsel" appearance="radio" selection="open">
  <label>Poll: to be or not to be?</label>
   <item>
    <label>To Be</label>
    <value>b</value>
  </item>
  <item>
    <label>Not To Be</label>
    <value>n</value>
  </item>
</select1>

Note that no specific choice is needed for an "Other, please specify" selection, since XForms supports the concept of "open selection" lists, where the user is allowed to freely enter additional list values.

Additionally, to make the form submittable, a small bit of markup is required in the head section of the document, as seen in the following code.

<model>
  <submission action="http://example.info/xml-submit"/>
</model>

Unlike the proposed simple syntax, only a minimal amount of keyboard typing is needed for the XForms Model; in fact, little more than a URL to accept submitted data. The main part of the form is specified as user interface form controls: here, select1. Note, too, that the "Other, please specify" choice isn't needed, since XForms supports open selection lists natively. If the user manually entered both as a choice, the resulting XML submitted would look like this:

<instanceData>
  <mainsel>both</mainsel>
</instanceData>

On the other hand, if the user accepted the initial choice, the shorter storage value given in the value attribute would be used:

<instanceData>
  <mainsel>b</mainsel>
</instanceData>

While the lazy author syntax saves typing, it also is severely limited in power, lacking any kind of calculation or validation structure. For this reason, the XForms specification encourages form authors to use the full capacity of XForms. The following chapters describe how to do this.

Despite the name, XForms is being used for many applications beyond simple forms. In particular, creating and editing XML-based documents is a good fit for the technology.

A key advantage of XML-based documents over, say, paper or word processor templates, is that an entirely electronic process eliminates much uncertainty from form processing. Give average "information workers" a paper form, and they'll write illegibly, scribble in the margins, doodle, write in new choices, and just generally do things that aren't expected. All of these behaviors are manually intensive to patch up, in order to clean the data to a point where it can be placed into a database. With XForms, it is possible to restrict the parts of the document that a user is able to modify, which means that submitted data needs only a relatively light double-check before it can be sent to a database. (One pitfall to avoid, however, is a system that is excessively restrictive, so that the person filling the form is unable to accurately provide the needed data. When that happens, users typically give bad information or avoid the electronic system altogether.)

Various efforts are underway to define XML vocabularies for all sorts of documents. Perhaps one of the most ambitious is UBL, the Universal Business Language, currently being standardized through OASIS (the Organization for the Advancement of Structutured Information Standards). The goal of UBL is to represent all different sorts of business documents—purchase orders, invoices, order confirmations, and so on—using a family of XML vocabularies. XForms is a great tool with which to create and edit UBL documents.

As an example, this section will develop an XForms solution for creating and editing a UBL purchase order. The first step is to define the initial instance data, which is a skeleton XML document that contains the complete structure of the desired final document, but with only initial data. This document serves as a template for newly-created purchase orders, and provides a framework on which to hang the rest of the form.

Example 2.1 shows what a UBL purchase order document looks like. Figure 2.1 shows, in the X-Smiles browser, an XForms document capable of creating such a document.

<Order xmlns="urn:oasis:names:tc:ubl:Order:1.0:0.70" 
xmlns:cat="urn:oasis:names:tc:ubl:CommonAggregateTypes:1.0:0.70">
  <cat:ID/>
  <cat:IssueDate/>
  <cat:LineExtensionTotalAmount currencyID="USD"/>
  <cat:BuyerParty>
    <cat:ID/>
    <cat:PartyName>
      <cat:Name/>
    </cat:PartyName>
    <cat:Address>
      <cat:ID/>
      <cat:Street/>
      <cat:CityName/>
      <cat:PostalZone/>
      <cat:CountrySub-Entity/>
    </cat:Address>
    <cat:BuyerContact>
      <cat:ID/>
      <cat:Name/>
    </cat:BuyerContact>
  </cat:BuyerParty>
  <cat:SellerParty>
    <cat:ID/>
    <cat:PartyName>
      <cat:Name/>
    </cat:PartyName>
    <cat:Address>
      <cat:ID/>
      <cat:Street/>
      <cat:CityName/>
      <cat:CountrySub-Entity/>
    </cat:Address>
  </cat:SellerParty>
  <cat:DeliveryTerms>
    <cat:ID/>
    <cat:SpecialTerms/>
  </cat:DeliveryTerms>
  <cat:OrderLine>
    <cat:BuyersID/>
    <cat:SellersID/>
    <cat:LineExtensionAmount currencyID=""/>
    <cat:Quantity unitCode="">1</cat:Quantity>
    <cat:Item>
      <cat:ID/>
      <cat:Description>Enter description here</cat:Description>
      <cat:SellersItemIdentification>
        <cat:ID>Enter part number here</cat:ID>
      </cat:SellersItemIdentification>
      <cat:BasePrice>
        <cat:PriceAmount currencyID="">0.00</cat:PriceAmount>
      </cat:BasePrice>
    </cat:Item>
  </cat:OrderLine>
</Order> 

The markup used by UBL seems slightly verbose, but this is necessary to capture all the small variations that occur in the purchase orders used by different organizations. Note that the cat:OrderLine element can repeat as many times as necessary, though only a single occurrence is needed for the initial instance data. Also note that the root element uses a different XML namespace than the rest of the document. Thanks to the context node rules in XForms, the root element never needs to be directly referred to, and thus form authors can happily ignore this minor detail.

The next step is to create an XForms document that will serve to edit the initial instance data. XForms itself does not define a document format. Instead, a host language such as XHTML or SVG, combined with XForms, needs to be used. As of this writing, XHTML 2.0, which natively includes XForms, is progressing through the W3C Recommendation track. This example, however, uses the established XHTML 1.1, with XForms elements inserted in the appropriate places. As a result, this example will not validate against any XHTML DTD. Even so, it is still XML well-formed, and browsers that understand XForms presently do a good job rendering this document.

The latter part of this chapter describes complications that occur when combining vocabularies; the opening lines of the XForms document shown in Example 2.2 provide a foregleam, using an arcane XML syntax called an internal DTD subset to declare certain attributes as document-unique IDs.

<?xml version="1.0"?>
<?xml-stylesheet type="text/css" href="style.css" ?>

<!-- the following extremely ugly code is necessary
to make ID attributes behave as expected -->
<!DOCTYPE html [
  <!ATTLIST object id ID #IMPLIED>
  <!ATTLIST model id ID #IMPLIED>
  <!ATTLIST bind id ID #IMPLIED>
  <!ATTLIST instance id ID #IMPLIED>
  <!ATTLIST submission id ID #IMPLIED>
  <!ATTLIST group id ID #IMPLIED>
  <!ATTLIST repeat id ID #IMPLIED>
  <!ATTLIST case id ID #IMPLIED>
]>

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:ev="http://www.w3.org/2001/xml-events"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:xs="http://www.w3.org/2001/XMLSchema"
      xmlns:u="urn:oasis:names:tc:ubl:CommonAggregateTypes:1.0:0.70"
      xmlns:xforms="http://www.w3.org/2002/xforms">
  <head>
    <title>Create a Purchase Order</title>

After the usual XML declaration, the document starts out with a reference to a CSS file to provide style information. Next, the DOCTYPE declaration and the several ATTLIST statements are necessary to make sure that the several ID-typed attributes that will be used are actually treated as IDs.

Following that is the beginning of a normal html element, with several namespace declarations that will be used later in the document. Last is the standard HTML head element, with a title.

The next several lines, in Example 2.3, make up the XForms Model—essentially everything there is to know about the form other than how it will look or otherwise be rendered.

<xforms:model id="default">
  <!-- schema="schema.xsd" -->
  <xforms:instance src="ubl_samp.xml"/>
  <xforms:submission action="file://tmp/ubl.xml" method="put" id="submit"/>

  <!-- a few things are always required -->
  <xforms:bind nodeset="u:IssueDate" required="true(  )" type="xs:date"/>
  <xforms:bind nodeset="u:OrderLine/u:Quantity" required="true(  )"
      type="xs:nonNegativeInteger"/>
  <xforms:bind nodeset="u:OrderLine/u:Item/u:BasePrice/u:PriceAmount"
      required="true(  )" type="xs:decimal"/>
  <xforms:bind nodeset="u:OrderLine/u:Item/u:SellersItemIdentification/u:ID"
      required="true(  )"/>

  <!-- a few basic calculations -->
  <xforms:bind nodeset="u:OrderLine/u:LineExtensionAmount" type="xs:decimal"
      calculate="../u:Quantity * ../u:Item/u:BasePrice/u:PriceAmount"/>
  <xforms:bind nodeset="u:LineExtensionTotalAmount" type="xs:decimal"
      calculate="sum(../u:OrderLine/u:LineExtensionAmount)"/>

The xforms:model element is the container for the entire XForms Model. In a document with only one such element, an id attribute isn't strictly needed, though it is good practice to always include one. With the addition of the attribute schema="UBL_Library_0p70_Order.xsd" it would be possible to associate a pre-existing XMLSchema with this form, though that option is commented out here. XML Schema processing would add significant overhead, and the few places that require additional datatype information can be easily specified separately. The xforms:instance element, with the src attribute, points to the initial instance data that was listed earlier. The xforms:submission element indicates that activating submit on this form will write XML to the local file system.

The next several lines contain xforms:bind elements, each of which selects a specific part or parts of the instance data, applying various XForms properties to the selection. The language used to select the XML parts, or nodes, is called XPath, which is perhaps better known as the selection language used in XSLT, XPointer, and XML Signature. The next chapter describes XPath in detail. XForms includes defaulting rules that simplify most of the XPath selection expressions, declared on the nodeset attribute, and called model binding expressions. The first model binding expression selects the one-and-only u:IssueDate instance data node, marking it as required and of the XML Schema datatype date, which provides the hint that this particular data should be entered with a date-optimized form control, such as a calendar picker. The second model binding expression applies to however many u:Quantity elements happen to exist at any given time, and marks all of them as requiring user entry, along with the XML Schema datatype xs:nonNegativeInteger.

The next few model binding expressions set up the two calculations that are fundamental to a purchase order: calculating the total amount for a line item (price times quantity), and the total for the whole order (sum of all line items). The calculate attribute holds an XPath expression that gets evaluated to determine a new value for the node to which it is attached. The calculation for line items is ../u:Quantity * ../u:Item/u:BasePrice/u:PriceAmount, where the asterisk means multiply, and the operands on either side of it are path expressions, relative to the u:LineExtensionAmount element. In turn, the calculation for the grand total is sum(../u:OrderLine/u:LineExtensionAmount), which uses the function sum( ) to add up all the values from individual u:LineExtensionAmount nodes. Like a spreadsheet, recalculations will occur whenever needed, and dependencies among calculations will automatically be handled in the correct order. For example, individual line items will always be multiplied out before the overall total is summed up.

The definition of the XForms Model continues with the lines in Example 2.4.

<!-- a second instance, temporary data not to be submitted -->
    <xforms:instance id="scratchpad">
      <temp xmlns="">
        <currencyOptions>
          <option value="EUR">Euro</option>
          <option value="GBP">Pound</option>
          <option value="USD">Dollar</option>
        </currencyOptions>
      </temp>
    </xforms:instance>
    
    <!-- global setting of currencyID -->
    <xforms:bind nodeset="u:OrderLine/u:LineExtensionAmount/@currencyID"
        calculate="../../u:LineExtensionTotalAmount/@currencyID"/>
    <xforms:bind nodeset="u:OrderLine/u:Item/u:BasePrice/u:PriceAmount/
        calculate="../../../../u:LineExtensionTotalAmount/@currencyID"/>
  </xforms:model>
</head>

An XForms Model can have more than one xforms:instance element. The usual reason for this is to hold temporary, non-submittable data that is used in the form. In this example, various currency codes, and the longer descriptions of each, are kept in a separate location for maintainability. This is also a good example of initial instance data occurring inline in the XForms Model, though it could easily also be another external XML document. The instance data XML itself is not defined in any namespace, so the xmlns="" declaration is essential to turn off the default XHTML namespace that would otherwise be in effect at this point.

The last two xforms:bind elements set up a mapping across the several currencyID attributes that can occur in a UBL document. The form is set up to include a form control that selects the current currency, placing it in the node at u:LineExtensionTotalAmount/@currencyID. The two bind elements in this section then copy the value to the appropriate two places in each line item. In theory, each line item could use a different currency type but, for simplicity, this example sets up two calculations that copy the main selection, which is kept on the u:LineExtensionTotalAmount element, to every other currencyID attribute (the number of which will depend on how many line items are in the order). With this, the XForms Model and the head section of the XHTML document come to a close.

From here on out, the rest of the code is the visible user interface to construct an UBL purchase order. Example 2.5 continues with the definition. Figure 2.2 shows the user interface that results from this portion of the XForms code.

<body>
  <xforms:group>
    <xforms:input ref="u:IssueDate">
      <xforms:label>Order Date</xforms:label>
    </xforms:input>

    <xforms:select1 ref="u:LineExtensionTotalAmount/@currencyID"
      appearance="minimal" selection="open">
      <xforms:label>Currency to use throughout this form</xforms:label>
      <xforms:itemset nodeset="instance('scratchpad')/currencyOptions/option">
        <xforms:label ref="."/>
        <xforms:value ref="@value"/>
      </xforms:itemset>
    </xforms:select1>

    <xforms:output ref="u:LineExtensionTotalAmount">
      <xforms:label>Order Total: </xforms:label>
    </xforms:output>
  </xforms:group>

The opening of the XHTML body element marks the start of the content that is intended to be rendered. The rest of the content in this section is organized inside an xforms:group element. The first form control is a basic input control, though due to the XML Schema datatype set up in the XForms Model, most implementations will provide a date-specific entry control, such as a pop-up calendar.

The second form control is a single select control, with a hint attribute appearance="minimal" to suggest that this part of the interface should be given minimal screen estate when not activated—in other words, a pop-up list. Another attribute selection="open" indicates that the user should be able to enter arbitrary values not on the list, in which case the entered value would have to be a three-letter currency code, not the friendlier text description that comes with the built-in choices. The xforms:itemset element pulls the choices from the instance data, in this case from the secondary instance data, as can be seen by the instance( ) function in the XPath, which is needed any time the non-default instance data is referenced. A kind of repetition is going on here; despite the single xforms:itemset element, the list will have one choice for each node matched in the secondary instance data.

The output control displays data but doesn't provide any interface for changing it.

Example 2.6 is lengthier, but not difficult to understand.

<xforms:switch id="DetailHider">
  <xforms:case id="detail_hide">
    <xforms:trigger>
      <xforms:label>Show Details</xforms:label>
      <xforms:toggle ev:event="DOMActivate" case="detail_show"/>
    </xforms:trigger>
  </xforms:case>

  <xforms:case id="detail_show">         
    <xforms:group id="SellerParty" ref="u:SellerParty">
      <xforms:label>Seller Information:</xforms:label>
      <xforms:input ref="u:PartyName/u:Name">
        <xforms:label>Name</xforms:label>
      </xforms:input>
      <xforms:group ref="u:Address">
        <xforms:input ref="u:Street">
          <xforms:label>Street</xforms:label>
        </xforms:input>
        <xforms:input ref="u:CityName">
          <xforms:label>City</xforms:label>
        </xforms:input>
        <xforms:input ref="u:PostalZone">
          <xforms:label>Postal Code</xforms:label>
        </xforms:input>
        <xforms:input ref="u:CountrySub-Entity">
          <xforms:label>State or Province</xforms:label>
        </xforms:input>
      </xforms:group>
    </xforms:group>

    <xforms:group id="BuyerParty" ref="u:BuyerParty">
      <xforms:label>Buyer Information:</xforms:label>
      <xforms:input ref="u:PartyName/u:Name">
        <xforms:label>Name</xforms:label>
      </xforms:input>           
      <xforms:group ref="u:Address">
        <xforms:input ref="u:Street">
          <xforms:label>Street</xforms:label>
        </xforms:input>
        <xforms:input ref="u:CityName">
          <xforms:label>City</xforms:label>
        </xforms:input>
        <xforms:input ref="u:PostalZone">
          <xforms:label>Postal Code</xforms:label>
        </xforms:input>
        <xforms:input ref="u:CountrySub-Entity">
          <xforms:label>State or Province</xforms:label>
        </xforms:input>
      </xforms:group>
    </xforms:group>

    <xforms:trigger>
      <xforms:label>Hide Details</xforms:label>
      <xforms:toggle ev:event="DOMActivate" case="detail_hide"/>
    </xforms:trigger>
  </xforms:case>
</xforms:switch>

Figure 2.3 shows the initial state of the user interface produced by this portion of the XForms code. Figure 2.4 shows the result of toggling the switch, revealing the form controls for entering the buyer and seller information.

The xforms:switch element is a useful tool to show different portions of the user interface on command. In this case, the form controls for seller and buyer information are either entirely shown or entirely hidden. A declarative element, xforms:toggle, changes which of the xforms:case elements get to have its contents rendered, with all others suppressed. The first case, which is the default, displays only an xforms:trigger that toggles itself away, showing all the form controls in the next case in its place.

Within another group for organizational purposes, the form controls in the next section capture all the information needed about the seller referenced by the purchase order. In this case, the overall group has a label, in addition to labels on the individual form controls.

The next group, for the buyer information, is nearly identical to the one that precedes it. While earlier drafts of XForms had a technique to combine this duplicated code in a single place, that feature was dropped in favor of concentrating on getting the underlying framework correct. (One proposal involves combining XSLT with XForms, using the element template to define a template that can be instantiated multiple times throughout the document.)

The last part of this section is another xforms:toggle displayed along with the buyer and shipper information. Upon activation, it causes the contents of the first case to be displayed, which has the effect of hiding all the buyer and shipper interface. The XML instance data, however, continues to exist even when the means of viewing or changing are hidden from view.

Example 2.7 creates a dynamically expandable list of line items.

<!-- repeating sequence for line items -->
<xforms:repeat id="lineitems" nodeset="u:OrderLine">
  <xforms:group>
    <xforms:range ref="u:Quantity" class="narrow"
        start="1" end="9" step="1" incremental="true">
      <xforms:label>Quantity <xforms:output ref="."/></xforms:label>
    </xforms:range>
  
    <xforms:input ref="u:Item/u:Description" class="wide">
      <xforms:label>Description</xforms:label>
    </xforms:input>
    <xforms:input ref="u:Item/u:SellersItemIdentification/u:ID" class="wide">
      <xforms:label>Part Number</xforms:label>
    </xforms:input>
    <xforms:input ref="u:Item/u:BasePrice/u:PriceAmount" class="narrow">
      <xforms:label>Price</xforms:label>
    </xforms:input>
  </xforms:group>
</xforms:repeat>

<xforms:group id="RepeatDashboard">      
  <xforms:trigger>
    <xforms:label>Insert new line</xforms:label>
    <xforms:insert ev:event="DOMActivate" position="after"
      nodeset="u:OrderLine" at="index('lineitems')"/>
  </xforms:trigger>
  
  <xforms:trigger>
    <xforms:label>Remove current line</xforms:label>
    <xforms:delete ev:event="DOMActivate" nodeset="u:OrderLine"
      at="index('lineitems')"/>
  </xforms:trigger>
</xforms:group>

Figure 2.5 shows the user interface that results from this portion of the XForms code, with the first line item highlighted.

Like xforms:itemset seen earlier, xforms:repeat causes a repetition of content, once for each node in a given set of nodes—exactly the behavior needed to populate the u:OrderLine elements from UBL. All the content of xforms:repeat is effectively duplicated as many times as there are line items, which can be dynamically added and removed. The first form control on each line item is xforms:range, which allows a smoother way to select a value than typing a number; for example, a sliding indicator. The range here is from 1 to 9.

The rest of the repeating form controls are similar to ones already used in this example. One difference is the class attribute on the final xforms:input, which is used by the associated CSS to style the form control.

Outside of the repeat, a few interesting things are happening. Inside another group, an xforms:trigger is configured to insert a new line item. Another declarative action, xforms:insert, accomplishes this feat. The location of the inserted line item is either just before or just after a specific location (from the at attribute) within a particular node-set (from the nodeset attribute).

The xforms:delete action works similarly. Any repeating set keeps track of the currently active item, called the index. Both the insert and delete actions make use of the index, as obtained through the index( ) function.

The concluding part of the sample document, in Example 2.8, allows the completed document to be written to disk.

<xforms:submit submission="submit">
      <xforms:label>Write to disk</xforms:label>
    </xforms:submit>
  </body>
</html>

Figure 2.6 shows the rendering for this piece of XForms code.

The xforms:submit element is another form control, like xforms:trigger, but able to invoke the submission procedure without any additional coding needed. It contains a reference to the xforms:submission element contained in the XForms Model, which ultimately determines what happens when this control is activated. After the last form control, the XHTML document comes to its usual conclusion.

The philosophy of the XForms specification can be summed up in a single line, found in the Abstract of the official W3C XForms document.

XForms is not a free-standing document type, but is intended to be integrated into other markup languages, such as XHTML or SVG.

This approach has benefits as well as drawbacks. The benefits are that the XForms specification was completed more quickly, and without host language dependencies that otherwise might exist. The primary disadvantage is that more work needs to be done to actually integrate XForms with XHTML, SVG, or any other language.

Another W3C specification, Modularization of XHTML, provides a framework in which XHTML, or any other combination of XML-based languages, can be mixed and matched in order to provide a combined document type. Such combinations can take advantage of specific language features; for example, in XHTML a non-rendered head section can contain the XForms Model, and in SVG, a foreignObject element can enclose individual form controls.

Another attribute, src, has caused nearly as much controversy as its big brother in XHTML, href. The problem stems from tension with XLink 1.0, a W3C Recommendation, which asserts itself as the preferred technique to define any "explicit relationship between resources or portions of resources." Originally,