even seems to be the magic number for the W3C. Seven years after releasing XSLT 1.0 (which also debuted XPath), they followed up with XPath 2.0, XSLT 2.0, and XQuery 1.0, all unarguably better and more powerful than their predecessors. In a similar vein, XForms 1.0 debuted in 2002 to remarkably little fanfare. After seven years of testing, probing, real-world case studies, and rethinking about the underlying assumptions on which it was based, the W3C recently released XForms 1.1
, at a time when people are beginning to seriously examine the potential for the technology.
XForms 1.1 has not changed its (apparently unique) underlying structure: an XForms document consists of a model made up of one or more XML instances, along with controls that are bound via XPath to the model. This approach ensures that you can work with the whole model directly in the client, maintain its own internal cohesiveness and validity, and send parts or the entire model to the server as desired.
Indeed, at first blush, the differences between this version and XForms 1.0 are difficult to see. The enhancements do exist, though, and are actually quite significant. For the most part, they are areas where the initial specification was either ambiguous or was becoming outdated in the face of evolving web technologies.
This article highlights some of the notable new features of XForms 1.1 and introduces some of the early implementations of this latest version.
Templates are easily one of the most requested XForms capabilities. In XForms 1.0, when you insert a new XML construct into the model, it has to come from an existing structure in the instance. This unfortunately means that should you want to start with an empty node and then add more content to it, you have to create a temporary template and then play games with hiding it. In XForms 1.1, you can specify a template resourcea node and its descendants in a separate instance of the modelto incorporate as a child of another element. The origin
attribute on the <xsl:insert>
element points to the node to be used as the template. Another facet of the new <xf:insert>
commands is that they have been extended beyond the repeat block; in fact, they can work with any node now.
Beyond making it easier to add new content generically, templates also make it easier to add node content of different kinds simply by changing the XPath of the origin. You can use this to create "preset" templates that contain appropriate starter information (custom user templates), and can also pull in templates that have different underlying data structures (such as different form elements for U.S., Canadian, or European addresses). When a node and descendants from a template are cloned into the model, you can release the template in favor of other templates (which are also now easier to download), keeping client-side memory footprints low.
One of the most significant effects of templates is that they effectively enable you to construct whole XML structures dynamically, doing more than simple duplication of existing nodes. While you are still dependent upon the templates in question for construction (unlike with XQuery or XSLT, where you could construct such nodes dynamically), this feature makes it much easier to build fairly rich structures (especially compartmentalized ones) from component parts.
Submission has been dramatically beefed up to make XForms content submission much more robust, effectively turning it into a first class client. XForms is now capable of supporting a number of new functions:
- You can now design submissions to work with SOAP, RESTful services, Atom-based services, and even non-XML output, based upon the serialization attribute. This enables tasks such as uploading just the text contents of a given node (useful, perhaps, for sending JSON messages) or using XForms as a blogging platform.
- The method attribute on submissions now allows you to pass any QName to the server, rather than only HTTP methods such as GET, POST, and PUT (this includes DELETE, one of the more problematic HTTP methods in XForms 1.0).
- The action attribute has been replaced with a resource attribute (which is used a great deal in XForms 1.1 for a number of elements, not just <submission>) and a <resource> element (which can take a value attribute that can then contain an XPath evaluation expression). This makes it much easier to dynamically change the target of a submission.
- Submissions can disable (and re-enable) both validation and relevance. This solves one of the more vexing XForms problems: storing a temporarily invalid block of XML content that was used for draft content editing.
- The targetref attribute is used in conjunction with the replace="instance" flag, making it possible for the results of a submission to replace only a specific node in a document instance, rather than the whole document. Again, you can use this to build the contents of a given data instance dynamically.
- Submission events are now much more informative, able to pass such information as whether a given submission was successful (200 or 300) or not (400 or 500).
- The new <header> element, part of the submission block, makes it possible to send additional header content, such as authentication information, along with the message.