Smarter Everyone, Smarter Everything, Smarter Everywhere

XForms: The big picture and the details

John M. Boyer 3 Comments 1,200 Visits

An interesting comment showed up on my prior post that seemed worth discussing as part of getting around to talking about what XFDL does for (and with) XForms.

In the last post, I talked about what XForms does and what it doesn't do from the big picture perspective. XForms does seek to standardize the language for the core information processing asset expressed within a form. XForms does not seek to standardize the exact presentation of a user interface. XForms delegates this task to different XML host languages like XHTML or XFDL (or others in the future like, hopefully, VoiceXML). These host languages exist to satisfy different requirements that exist beyond the core information processing requirements, but XForms allow us to design the underlying application once and handle presentment and other orthogonal requirements as the separate issues that they are.

The comment came in saying that one thing XForms doesn't do is allow the URL of a submission to be dynamically calculated. This is a technical limitation that does not affect the big picture of what we're trying to achieve with XForms. The XForms language does contain some technical limitations like this. Many of them are being addressed in XForms 1.1. This issue in particular should be addressed in the very next working draft of XForms 1.1.

However, because we have to deliver products that can be used to build applications now, it sometimes happens that implementations have to lead the standard with custom extensions until the standard comes along and specifies the common way that everyone on the working group agrees is the way the language will express a feature.

In XFDL, we make relatively few changes to XForms because we want our documents to be as conformant as possible. However, this particular issue of a dynamic URL comes up in almost all of the forms applications we have every deployed, so we did not feel we could make our next release of Workplace Forms without some ability to do a dynamic URL on an XForms submission. At the same time, we do like it to be clear to the form author when an extension is being used. As a result, the addition was made using an attribute in the XFDL namespace. This makes it easier to find those bits of our XForms-based documents that will need special attention when trying to get them to interoperate with other XForms implementations.

In the upcoming release of Workplace Forms, you can create XForms-based applications that include a dynamic URL component by using an xfdl:actionref attribute instead of an action in the xforms:submission. The content of xfdl:actionref is an XPath expression whose result is the node containing the desired URL. Of course, the full power of XForms calculations can be brought to bear on that node to allow dynamic calculation of all or any portion of the final URL.

In XForms 1.1, I am expecting a more general mechanism that will allow the instance data to be used to set not just the URL, but eventually many of the other parameters too.

[Read More]

What XForms does (and what it doesn't do)

John M. Boyer 64 Comments 5,168 Visits

The purpose of XForms is to express the core XML data processing asset used in sophisticated data collection scenarios.

In fact, it would be better if XForms were called the XML data processing language (XDP or XDPL) because XML is about standardizing data and about 80% of business transactions are based on filling out some kind of form to collect the transactional data.

An XForm contains one or more XML data instances. An instance is an arbitrarily structured XML data document that is typically an instance of some XML schema that expresses the static validation rules for a target namespace.

One can write an XForm without an XML schema by just expressing the XML data in an instance. This is because XForms provides other channels of data validity checking that can be easier to work with when only simple data type validation is needed. For example, you can use an XForms type declaration to associate an xsd:date or similar data type to an XML data node without writing an XML schema for your XForm.

But XForms validity checking is also dynamic, in recognition of the fact that validity of some values can be based on other values or the aggregation of other values. For example, in an interlibrary article request, the upper bound page number in the journal must not be less than the lower bound page number. Or, the user is only authorized to make a purchase order with less than $10,000 total value.

The latter example is important because it leads to the conclusion that we not only need a way of testing data values relative to other data values, but also that we need a way of calculating data values that are then used in validity tests.

From there, it is not a big leap to conclude that generalized XML data processing requires some way to indicate dynamically whether further changes should be allowed to certain pieces of data or whether certain parts of the data are still applicable to the transaction based on other data values. A good example is a mortgage preapproval form that can handle both single and joint applications. The co-applicant data is only relevant if the user selects the joint application mode.

XForms allows the form author to express formulae for these aspects of data, which are called model item properties, or just MIPs. Not too surprisingly, the names of these MIPs are readonly and relevant.

Of course, there is no point in representing data, calculating values over data, and validating data if you have no way to change the data. XForms allows simple content data values to be changed, but it also allows insertion and deletion of larger blocks of data that contain internal structure because this is essentially what's needed to add or delete a row from a table.

Most importantly, XForms offers form controls that expose data to the surrounding application context. If the data changes, the form controls change. This includes not only exposing a changed simple content data value, but if a set of form controls are associated with a repeated sequence of structured data, and the number of data nodes in the sequence changes, then form controls are created or destroyed as needed to respond to the change of data.

XForms is all about thinking of the data first and driving outward to how that data gets exposed to applications. Perhaps the most prevalent of such applications are for presenting the data to a human user, though even human users have highly varied capabilities. For example, the desktop user and the PDA user have very different visual capabilities. Of course, this argument extends easily to meeting the far greater accessibility needs of the sight-impaired.

For this reason, the XForms form controls represent what I've often called an intent-based user interface. It's kind of neat to see the term popping up more frequently now. It gets to the heart of the matter: XForms does not provide a presentation layer. XForms relies for presentation on a host language like XFDL (in Workplace Forms) or XHTML (in web browsers). I am certainly hoping that VoiceXML will come to the conclusion that they should soak up the benefits of XForms rather than reinventing all of this stuff over again (partly because almost everybody underestimates how much work goes into it until it's too late; but maybe they will prove to be wiser than the rest).

I sometimes get asked whether XForms will next extend itself to standardizing the actual presentation layer. Clearly, from above the answer is no. XForms standardizes the core XML data processing asset, and more work will go into doing a better job of that. The key issue we want is to address interoperability and reusability across applications and user contexts of the data processing behaviors that are fundamental to completing a transaction.

[Read More]

Workplace Forms and products like DB2 Viper

John M. Boyer 648 Visits

The powers that be asked the dW bloggers to help spread the word about the download availability today of DB2 Viper Release Candidate 1.

Please see www.ibm.com/db2/viper

You can also get more info from

New DB2 Viper forum

This Technical Article

dW Search

Anyway, why does this make sense on a blog about Workplace Forms?

As I said before in this blog, the purpose of a form is to collect data. If you want to collect data about a pizza order, you don't want us, but obviously there are more sophisticated information needs than that, right!

Question is, once you've got the data, what do you do with it?

There's always a server side to any web application. Products like DB2, Content Manager, and Portal Document Manager are about providing high strength persistence tiers for the consumption of data collected across an enterprise or across enterprises. Products like WebSphere Application Server and WebSphere Portal Server are about creating that middle layer that creates the logical bridge between from the point where you have the data to the point where you know what to do with it (something has to decide where to put the data, what data to retrieve, etc.).

And IBM Workplace Forms is there to put a beautiful face on it all by intelligently collecting data of any level of complexity while providing a richly textured user experience. And DB2 Viper is an especially good fit with IBM Workplace Forms because our forms contain XForms, which is a pure XML play, and the most significant addition to DB2 in Viper is the native-XML data model.

[Read More]

Why is IBM so pumped up on XForms?

John M. Boyer 664 Visits

IBM is interested in all manner of open standards, including XForms, because they allow organizations to express their information assets in a format that can more easily be preserved as one incorporates more technologies into an application over time to meet evolving business requirements.

As Kevin Kelley (STSM, emerging standards) explained in a telecon this morning, the standards are like an on-ramp that allows assets to be developed over time. If you care about reuse of those assets, then you care about standards.

To be honest, this is the same argument that drove XML to the ubiquity it currently enjoys. With XML, we sought to standardize how data models are expressed. With XForms, we seek to standardize the expression of processing models over that data.

Some upcoming posts:
1) What does XForms actually offer?
2) How does XFDL fit into the above open standards story?
3) What makes XFDL+XForms an ideal format for archival, transaction auditabilty, and transaction security purposes?
[Read More]

Feed for Blog Entries ▼ Feed for Blog Comments ▼