This weekend I started looking at XForms. I didn’t know much about it, but what I had a suspicion that it could be a standard that could be leveraged as a standard/best practice method of letting people build forms that would submit data into a content management system like Documentum.

I picked up XForms: XML Powered Web Forms by T.V. Raman. I plowed through the first 80 pages and then grew restless–I wanted to try some of it on my own and the book really didn’t lend itself to that. It’s more reference than how-to. I did find the early chapters valuable, though. When I was ready to try some out on my own, I used the following resources:

Here’s what I’ve learned, so far:

XForms is awesome. When it is adopted by the W3C as a full-blown standard, and production implementations exist, it will not be too soon.

See the above resources for details, but the gist is that HTML forms have outstayed their welcome. Anyone who has ever developed a web app knows this. You end up jumping through all kinds of hoops to do validation, conditionally hiding fields or sections of forms, building dynamic dropdown lists, and what I call progressive disclosure, or showing/hiding entire sections of forms based on field selections or other criteria. Top it all off with coming up with ways to handle the data on submission and you’ve got a large portion of your development effort going towards mundane tasks.

XForms changes all of that. You define your data structure using XML. You can even use an XML Schema if you want. Then, you describe the form using XML. The UI widgets on the form get bound to pieces of the data structure (the model) using XPath. The widgets are described in a presentation-independent way. That means the form can easily be used in devices other than the web browser.

When the form gets submitted, the form data magically fills in the data structure you defined and the server receives a well-formed XML document.

An XForms page can also dynamically pull data in to the form. So, for example, you could write a web service that could be used to populate a dropdown list. I’m assuming you’d do something like this to retrieve the data after it is submitted for editing. So far, I haven’t tried any examples where the data actually gets stored in a back-end repository and then gets retrieved for editing.

The idea of defining the data model separate from the presentation of the form is very appealing. And I like the ability to tie the validation in to the data model via XML schema. It reminds me of the good ole Notes days where documents are collections of fields that can be displayed in many different ways as defined by one or more forms. But, this is all based on XML and Schemas.

Once you get those documents into the repository (relational, native XML, or content management system) you can do anything with it you want like build “views” or lists of documents sorted any way you want using XSLT.