Summary

  • W3C issued XForms 1.0 as a Recommendation on 14 October 2003. The design separated a form's model, XML instance data and user interface, linking controls to data through bindings rather than making the screen layout the whole form.
  • In the Recommendation's payment example, card number and expiry become relevant when the payer selects credit. The relevant rule also governs what the processor makes available to the user and which instance nodes are serialized for submission.

Picture a checkout clerk with the manners of a badly written web form. You choose cash. The clerk nods, then asks for your credit-card number and expiry date anyway. The boxes are on the sheet, after all. Now imagine that the clerk has a rule book that says which questions belong to which answers. Cash closes the card drawer. Credit opens it. The form stops treating its own furniture as the customer's obligation.

That small act is a good way into W3C's XForms 1.0 Recommendation, dated 14 October 2003. XForms reorganized a web form into three distinguishable parts: an XForms model, XML instance data and a user interface. The model described data and rules. The instance held the evolving values. The interface offered controls a person could use. A binding connected a control to a node in the instance. This gave the form more than a collection of visible input boxes; it gave the questions a place to explain their purpose.

The Recommendation's worked example is a modest purchase. It asks for a payment method, a card number and an expiry date. An instance element begins as an XML skeleton with those three pieces. A submission element gives the destination. The visible side has a select1 for cash or credit and input controls for the two card details. Each control carries its own label, and a ref binding points it to the relevant part of the instance. As the buyer fills the form, the instance acquires values; on submission, the processor serializes XML.

Those parts could be rearranged for different screens without changing what the data meant. The specification's select1 named the act of choosing one option; it did not dictate that every device draw the same radio button. A voice interface and a visual display could present the same choice differently. The author still had to connect each control to the right node. The abstraction was a division of labor, not a magic picture that fills itself.

Then the payment example reaches the question that makes the clerk look foolish. Card details matter when the method is credit. XForms put that condition on bind elements: the number and expiry have relevant expressions that test whether the method equals cc. Those same bindings make the values required when the credit path is active and attach a type to each value. The example's card-number type uses a 14-to-18-digit pattern; expiry uses xsd:gYearMonth. The rule is stored with the model's account of the data, where the processor can evaluate it as the buyer changes the payment method.

The Recommendation's definition of relevant gives the rule teeth. When a node is irrelevant, the processor leaves it out of the serialized submission. Its associated control is unavailable to the user, removed from navigation and unable to take focus. When the buyer chooses credit, the fields become relevant and their required values enter the path to submission. The cash customer can finally leave without answering a question about a card that never came out of a wallet.

The XML instance is important here because the form's final record has a shape chosen by its author. The sample does not merely hide a credit-card box and send every field along anyway. The model's relevance decision reaches the data that travels. This is where the three-part design earns its paperwork: a screen state, a rule and a submitted XML document have to agree about what the transaction asked for.

W3C's announcement of XForms 1.0 described that separation as a way to distinguish a form's purpose, presentation and results. In the payment example, the purpose is to record how the customer will pay; the presentation can follow the device; the result is the XML instance the processor submits. The most human part of the design is also the least glamorous. It allows a question to know when to leave the room.