Smarter Everyone, Smarter Everything, Smarter Everywhere

Today is an exciting day for the IBM Victoria Software Lab because today we have been pushing the new version of the IBM Workplace Forms product line into the IBM release queue. General availability is on June 13th, but it's on its way folks!

The IBM Workplace Forms product line is designed to simplify the process of creating and maintaining forms-based web applications. The flagship knowledge product of the product line is an XML vocabulary called XFDL, which is an XForms-enabled language that provides a rich and precise presentation layer for XML data. The IBM Workplace Forms software supports the full life cycle of XFDL documents, from creation to run-time to processing of completed form documents.

The IBM Workplace Forms Designer is an eclipse-based visual development environment for creating XFDL documents. It has a main canvas for drag-and-drop design of the user interface. The drag-and-drop palette has all the usual suspects for atomic form controls as well as containment controls like repeat tables and group/switch panes. The user can also add custom groups of controls to the palette as single new controls. This makes it easy to standardize constructs like toolbars or address blocks across all forms in a workspace.

The product line offers two alternatives for deploying XFDL functionality to the client-side: the IBM Workplace Forms Viewer and the IBM Workplace Forms Server - WebForm Server. The viewer provides the full implementation of the XFDL language, including rich user experience, precision presentation layout, spell-checking, email client integration, accessibility, rich text support, custom viewer extension modules, offline fill experience, and digital signature security. While some XFDL features such as digital signature generation and offline fill require a viewer, the WebForm Server is a remarkable product that provides a significant portion of the viewer functionality to web-browser-only client machines (i.e. a zero footprint install). It does this by converting the XFDL to a pile of HTML, JavaScript and AJAX calls that would be challenging at best to write and maintain by hand (rather like writing assembly language when you could be writing in a high level language). The user interacts with the HTML, and the tag-value pairs of data are merged back into the XFDL document for processing by the back end of a web application-- just as if the viewer had been used.

It is no surprise that a form filled with the Viewer and with WebForm Server are indistinguishable to the web application developer. Our intent is to provide a single document paradigm for the form design and the web application development. So, both of our form run-time products are based on a common API that understands and implements much of XFDL. Although the nature of XFDL as an XML vocabulary means that standard XML tools could be used to process XFDL documents, the XFDL API is also made available to the web application developer. The idea is that your servlet/portlet will require less coding if you use an API that understands not just XML, but the XML vocabulary of the document. For this reason, the IBM Workplace Forms Server contains not just the WebForm server, but also the API.

Rounding out the Server product is the IBM Workplace Forms Server - Deployment Server. This server facilitates mass deployment of the Viewer and custom viewer extension files by providing an on-demand install experience that can be customized by the server adminstrator.

We usually think of a document as a file. A file is, at the operating system level, a unit of information. The OS can associate properties with it (like who can read it or write it), and the file can easily be moved from directory to directory or computer to computer with standard tools like FTP, email, or flash drive.

The XML recommendation defines a document as that which conforms to BNF rule #1 of the XML syntax. Of course it is useful if an XML document is the sole content of the unit of information being transferred, i.e. if the XML is the only thing in a file. This is because XML tools tend to be built with programming languages that expose services of the operating system.

However, the most important part of an XML document is capable of being contained within another document. In fact, XML canonicalization strips away the part of an XML document that would prevent the result from appearing as element content.

This is the idea that XForms uses when it expresses XML instance data within a larger document, and specifically within the <xforms:instance> element. Of course, the <xforms:instance> element can also reference a whole XML document using the src attribute, but in both cases, the result is parsed into the live running instance data. The user interacts with the XML data document, and the XML data document is what is returned to the server by an <xforms:submission>.

This paradigm works well enough if you think of a form as an ephemeral view of a back-end database or content repository. However, people find it easier to work with a document in the file sense of the word. we like to save our document, email it, reload it the next day or on a new computer, and especially on a computer that has become disconnected from the net or from the original web application context that would be associated with the ephemeral view kind of form.

Enter the document-centric approach of Workplace Forms, the technological basis of which is an XML document whose element names belong to the XFDL and XForms vocabularies. Moreover, the underlying XML data document is still incorporated by the <xforms:instance> just like all other XForms-based documents.

A key difference is that being a document implies that the form with eventually have to be re-serialized, e.g. to save or sign the form. XForms doesn't really talk about how to reintegrate the live, modified XML data back into the document, but in truth it's really not that hard. The main technical hiccup on the XForms side is that the src attribute takes precedence over the content of <xforms:instance>, so when the live data is synchronized back into the form, the src attribute has to be eliminated.

The conclusion, though, is that a Workplace Form, or XFDL document, is a cross between an office document and an mobile intelligent agent. It can be saved, reloaded, printed, emailed, archived, signed, submitted to web application and portal servers, and participate in document management, records management and content repository processes. This is how the notion of document makes a form be more than just an ephemeral view of data.

XML is fairly pervasive, so we rarely ask this question of XML anymore, but once upon a time the question came up a lot as business managers tried to figure out why the technical people were insisting on spending money to move to XML. And the truth is that the impact is difficult to measure precisely, so open standards are sometimes a bit of an uphill battle. Nevertheless, the software engineering benefits are tangible and increase in magnitude over time.

One benefit is, of course, the human resource factor. Given a schema or DTD for a pile of pointy brackets, human beings can learn a lot about your document format quickly, which means they can become proficient more quickly and be more efficient overall at moving information into and out of the document.

This has an impact on the development of software systems. The software engineering benefits of increased interoperability/looser coupling of system modules have a significant positive effect on the time and cost efficiency of software development. Really, it's the same benefits as a service oriented architecture, which is why SOA and XML documents are such a good match.

But XML standardization has a deeper impact as it also places a value on the document format. In other words, the document format becomes a product in and of itself. A software system based on an XML document format is more valuable than one that is not because it is easier for enterprises to migrate to or from the document format. The benefit to a vendor of enterprises being able to migrate to the vendor's format is immediately obvious, but the ability of the enterprise to migrate from the vendor's format is also surprisingly valuable to the vendor. This is true not just for the obvious reason that being trapped in a document format is inherently costly to an enterprise. So, the enterprise can more readily adopt a vendor's solution when it does not imply vendor lock-in, but frankly it is the capability to more easily migrate away from the vendor's solution that becomes a selling point. A vendor can say, "We know you have a choice, so we're going to be responsive to your needs and deliver quality software so you keep choosing us."

It is with all these benefits in mind that we moved the predecessor of Workplace Forms to an XML syntax called XFDL. The XFDL language is an XML vocabulary that simplifies the design, development and deployment of high precision, secure forms applications that provide a rich user experience.

Of course, the first thing we did with our new XML syntax was to report it to the W3C in a document which became a W3C Note. The purpose of a W3C Note is to bring to the attention of the W3C something that contains aspects worth of consideration for standardization. The W3C does not and never will standardize a vendor's submission. But it does take note of its own notes! A positively reviewed note is likely to result in some movement in the standardization world. In the case of XFDL, that movement has occurred all over the place, including the likes of XPath, XML Schema, XML Signatures and Canonicalization, and XForms.

Of course, XFDL now incorporates XForms to express all aspects of XFDL that it can. And like a good standard ought to do, XForms itself incorporates other W3C technologies where appropriate, like XPath and XML Schema. But XForms depends on a host language to deliver the actual user experience, and there are aspects of a precision presentation and rich user experience that properly belong at the host language level. And XFDL even encodes these bits with the most pervasive standard of all -- XML.

I am the happy owner of an excellent new book entitled "Document Engineering" by Robert Glushko and Tim McGrath. The reader goes on journey through many of the XML technologies that are brought to bear to solve business informatics problems. The journey does not jostle and stab with so many pointy brackets, but rather focuses intently on why we need all of these technologies and how to put them together sensibly.

There are so many nuggets of wisdom in the book that of course I cannot tell you all about it in this blog. Just like the Matrix, you have to see it for yourself! But I would be remiss in not giving you at least a taste, especially since the message is so closely aligned to the value proposition of XForms and, indeed, XFDL+XForms.

Service oriented architecture is a design philosophy; web services are a set of standards and techniques. (Ch. 4)

In other words, XML documents are the lifeblood of a service oriented architecture, and XML technologies are valuable because they help us overcome the limitations of rigid, monolithic systems.

With Workplace Forms, we combine XFDL and XForms to achieve a somewhat elaborated version of this view in which the forms themselves are the documents that make their way through a service oriented architecture, interacting according to their own rules of engagement to achieve validity of the contained XML data document and more efficiently achieve the intent of a business process.

In other words, the SOA is the infrastructure, the XFDL form is the medium, and the XML data is the message. With this analogy, it is easy to see that the powerful words of Marshall McLuhan are applicable: The medium is the message. The more powerful the medium, the more powerful the message. An XForms layer around XML data trumps a system in which only the XML data is standardized. An XFDL layer around the XForm... transaction auditability, digital signature security, comprehensive accessibility, rich text, globalization, and on and on. All the things we get to talk about in future installments of this blog.