john-boyer

Spotlight on XForms 1.1 Features in Lotus Forms

Lotus Forms has supported XForms for a number of years now, and you can get a good idea of all the features supported from the XFDL reference manual.

However, now that XForms 1.1 has been finalized, I've had a number of questions about shining a spotlight on the XForms 1.1 specific features in Lotus Forms.  Quite a number of XForms 1.1 features were improvements to the semantics of pre-existing XForms 1.0 features, and no small number of those improvements were based on feedback from the IBM Victoria Software Lab, so obviously we implement those and it would be too long to go into them.  The spotlight will be on Lotus Forms features syntactically activated with new XForms 1.1 vocabulary that was not available in XForms 1.0.

One of the coolest and most powerful additions to XForms 1.1 were the if and while attributes on XForms actions.  XForms actions are behaviors like changing data values, insert or deleting nodes, or making web service calls, and they can be set to happen in response to events like a button press (DOMActivate) or user input (xforms-value-changed).  The if and while attributes enable XForms actions to be conditionally or iteratively executed when these events occur.
  
Lotus Forms supports the context and origin attributes on insert and delete actions.  These attributes enable handling of empty repeating data, and they allow repeating data to be copied from a data template.  It is much easier to handle dynamic table data with these features.  Also, when deleting a data node representing a row of a table, if the table becomes empty, then the above if attribute can be used on an insert to detect that this has happened, and insert a new empty data node.  The net result observed by the user is that deleting the last row of a table looks like it just clears out that row so that the user can start immediately entering more data.
 
Lotus Forms also implements the XPath function compare(), which means a form author could use XForms actions with the if and while attributes to sort or search data, if the need arose.  Several other functions are implemented, including:
  • random() - in case you want to write a Lotus Form that plays Black Jack
  • current() - to help with data table lookups
  • power() - for exponential calculations such as compounded interest payments
  • days-to-date() - can be used in combination with days-from-date() to do simple date math like "today plus 90 days"
  • seconds-to-dateTime() - can be used in combination with seconds-from-dateTime() to do dateTime math like "now plus 3 hours"
  • local-date() - provides the date for the end-user, rather than the UTC date
  • local-dateTime() - provides the end-user date and time, rather then the UTC date and time.

Lotus Forms supports the display of images obtained from XForms instance data, in both button and label items, using the mediatype="image/*" attribute setting on xforms:output.

 
Lotus Forms supports the xforms:* datatypes, which allow an empty string to be valid on the corresponding xsd:* datatypes, like xsd:date.   Whereas pure XML schema datatype definitions are intended to define what constitutes valid completed data, this feature of XForms recognizes the importance of a good user experience before and during completion of the form.

Finally, Lotus Forms supports several of the new features of xforms:submission, including: 

  • the method="put" and method="delete" attribute settings to round out access to ATOM publishing services
  • the relevant and validate attributes, which allows a submission to turn off data validation and relevance pruning. This can be used to implement a "Save to Server" capability so that a user can perform a fill experience over multiple sessions.
  • the serialization="none" attribute setting to enable an xforms:submission to perform simple URL activation.
  • The targetref attribute, which enables a web service call to replace only a portion or subtree of a data instance.
  • The replace="text" attribute setting, which allows a web service call to replace the content of the target data node, rather than the data node itself.  This is useful for accessing web services that return textual content rather than XML.

Lotus Forms also has a number of XFDL extensions that add value to the integration with XForms, but that is the subject of another blog for another time.

Looking forward to XForms 1.2 Progress

As we start off the business of a new decade, I already find myself looking forward to the improvements in XForms 1.2. 

I know, I know, we just released the XForms 1.1 Recommendation, which contained a huge bundle of new features and architectural improvements. Still, the working group has been energetically advancing on still more features and improvements even as we closed the loop on the W3C process in the latter half of last year. I am very pleased with the completion of XForms 1.1, but the only constant is change, and we have an excellent array of new technical results to achieve in XForms.

The working group has put a fair bit of effort into the triage of features to separate nearer term (and simpler) objectives from those features of a more architecturally significant nature, which tend to get put in the "XForms 2.0" bucket.

My personal favorite "simple" feature is model-based UI switching with the switch element. This may seem like a bit of a nerdy thing to perseverate on, but the switch element is the only UI control we have that is not directly controllable by a UI binding to data.  So, if a form author wants to switch UIs based on a user input, such as changing the payment details UI based on the selection of a payment, then the form author typically resorts to using group elements and the relevant model item property. But this is more than just the sense of completion we'll get from being able to say *all* UI controls can be declaratively linked to data. And it's more than just the satisfaction we'll get from providing the right tool for the job. The ability to declaratively link the state of a switch to data is critical to the save/reload web application pattern and the transaction digital signature web application pattern.

Other web application standardization efforts are focused mainly on what happens during execution of a single web page.  XForms-based technogies are a step ahead because they can more easily address the user patterns related to collaboration on the web.  Whether it is one user saving an application context and reloading it again in the future, or whether one user provides data to be loaded by a second user, the simple fact remains that data can be in any state along a continuum between empty template and fully completed, so web applications need to be declaratively responsive to that continuum. And nowhere is this clearer than when a web-based transaction is of high enough value to warrant a digital signature.  A digital signature needs to be able to capture the full current state of the web application, and having a declarative binding to the data is the easiest way to achieve that goal since it means one can simultaneously sign the web application page template(s) and the data as separate resources.

For the record, Lotus Forms has for a few years now used a legitimate XForms extension mechanism, the xfdl:state attribute, to support model-based switching.  We deemed this extension critical to our ability to address our customers' requirements for the above two web application patterns. Standardized integration of XForms with XML Signatures and other advanced security features like XAdES is, so far, in the XForms 2.0 bucket.

In conclusion, I'm not necessarily saying this is the "biggest" feature of XForms 1.2, only that it is my fave.  I'll be giving some coverage to the other XForms 1.2 features in future blog posts, so please click the 'follower' button above (top right) and stay tuned. 
 

XForms 1.1 is a W3C Standard

The theme song to Star Trek started to play in my head last night when I thought about the imminent publication of XForms 1.1 as a W3C standard (which the W3C calls a Recommendation).  It's been five years since I started putting the working group's content into the first "thin spec" working draft of XForms 1.1.

Since that time, the working group has substantially upgraded XForms to enable it to better address the emerging requirements of cutting edge web applications and interactive documents.  This has included well over a thousand spec changes to resolve differences in understanding both great and small. Many times it has happened that one person's editorial clarification is another's substantive change, so there was a significant improvement in mindshare and consensus at a much deeper level than was the case for XForms 1.0.

The biggest change, in my view, is the substantial increase in web connectivity features added to the XForms submission module. This enables XForms to properly act as a smart Web 2.0 application client.  XForms handles the interactive rich user experience of the web application, and at any point in that interaction, XForms can directly inject information into and extract information from server-side data sources and business processes exposed as web services, REST services, ATOM feeds and publishing services, etc. 

As powerful as these features are when used within a web application's HTML pages, they are all the more interesting when used to connect open standard ODF office-style documents to data sources and business processes.  Then, you get the blend of ease-of-user and familiarity features of a word processing or spreadsheet document and the desirable connectivity features of a Web 2.0 application.  For further details on these thoughts, please see my document engineering conference papers on ODF and XForms:  "Interactive Office Documents: A New Face for Web 2.0 Applications",  "An Office Document Mashup for Document-Centric Business Processes", and "Enriching the Interactive User Experience of Open Document Format" (these papers are likely to be available to you through your institutional account with the ACM, e.g. through KnowledgeGate for IBMers).

There are many other additions and refinements in XForms 1.1, which are summarized in the introduction.  Suffice it to say that five years of effort have gone into making XForms ready for prime-time, and we at IBM are very pleased to see this version of XForms advance to W3C Recommendation, especially due to the number of products we already have in market that support this computing industry standard.  With XForms 1.1, we will soon be able to realize the vision of delivering Web 2.0 applications via "A REST Protocol and Composite Format for Interactive Web Documents".

Announcing New Release of Ubiquity XForms

Ubiquity XForms version 0.7 is now available. In addition to contributing to the recent advancement of XForms 1.1 to Proposed Recommendation, this new version has many new features, fixes and highlights.  Personally I'm happiest with the progress on implementing submissions, but that may be a bit of bias because I contributed some code to deal with aspects of submissions such as serialization, validation and relevance pruning. On the other hand, I contributed code in other areas, so maybe it's just that I'm biased toward any improvements to our ability to support the XRX architecture and connect the XForms client to server-side services.

In any case, there's lots of good core XForms features that have been added as well as noteworthy extension features.  My personal favorites are the calendar and checkbox controls used for date and boolean type XForms inputs, the new map controls, and the very simple javascript function extension.  Check out the loan-lowercase.html sample and its format.js file, for example.

And this blog entry would not be complete without my mentioning a special word of appreciation to the folks at webBackplane for all their contributions in general but especially for the Ubiquity XForms rollup system, which consolidates the many files of the processor into a single file to be deployed on your server.  I have an internal project right now that uses the rollup, and it provides us with the high level of performance we expected/required in our applications.

Full details of the version 0.7 release can be found here: <http://code.google.com/p/ubiquity-xforms/wiki/Release0Point7>

XForms 1.1 to Transition to Proposed Recommendation

The XForms 1.1 specification was approved for transition to Proposed Recommendation.  Publication as a Proposed Recommendation is currently expected next Tuesday.

In order to achieve this transition, we presented a report of multiple implementations of XForms based on an expansive test suite, we presented the disposition of all formal comments received on the candidate recommendation, and we presented the important changes, which were those changes that the community would reasonably want to hear why they were not substantive deviations and were interoperably implementable.

Advancement to Proposed Recommendation essentially says we're "putting it to a vote" now.  The member companies of W3C vote on advancement of XForms 1.1 to Recommendation, and they have until Sept. 22 to cast their votes.  Based on the many significant improvements that have been made in XForms 1.1, and the rigorous standardization process we have followed, we are obviously quite optimistic about the outcome of the vote.

I am also especially pleased that both the IE7 and FF3 browser implementations of Ubiquity XForms were included in the implementation report.

Verifying XML Signatures on Lotus Forms Documents

Back in March, I wrote about the open standards basis of Lotus Forms documents. This entry included comments on the use of the XML Signatures standard in combination with XForms within the XFDL markup of Lotus Forms.



Now I'd like to draw your attention to a developerWorks article we've now published on the technical details of Verifying Lotus Forms XML Signatures with Java. This article explains how a JSR 105 compliant implementation, such as can be found in the Apache security library or in Java 6, can be used validate the XML signatures created by the Lotus Forms client software (either the Web Form Server or the client-side Forms Viewer plugin).



Generally, a Lotus Forms document consolidates the client-side of the business process function. This could be a many-step process for an individual or it could be a process that spans many individuals who are collaborating to perform a business transaction. Applying an XML signature on a Lotus Form protects the markup of the consolidated client experience, not just the transactional data created by users. Users don't "see" the XML markup of data for a transaction. They visually see (or aurally sense with accessibility software) the whole "contract" that gives context to the data content. An XML signature applied by Lotus Forms client software signs the whole agreement. The above mentioned article explains how open standards based software can be used to complete the server-side function of validating the XML signatures in order to secure the transactions of a business process. Since Lotus Forms are XML documents based on XForms, this means that the entire business process workflow on a Lotus Form can be achieved with open standards based software.

Verifying XML Signatures on Lotus Forms Documents

Back in March, I wrote about the open standards basis of Lotus Forms documents. This entry included comments on the use of the XML Signatures standard in combination with XForms within the XFDL markup of Lotus Forms.

Now I'd like to draw your attention to a developerWorks article we've now published on the technical details of Verifying Lotus Forms XML Signatures with Java. This article explains how a JSR 105 compliant implementation, such as can be found in the Apache security library or in Java 6, can be used validate the XML signatures created by the Lotus Forms client software (either the Web Form Server or the client-side Forms Viewer plugin).

Generally, a Lotus Forms document consolidates the client-side of the business process function. This could be a many-step process for an individual or it could be a process that spans many individuals who are collaborating to perform a business transaction. Applying an XML signature on a Lotus Form protects the markup of the consolidated client experience, not just the transactional data created by users. Users don't "see" the XML markup of data for a transaction. They visually see (or aurally sense with accessibility software) the whole "contract" that gives context to the data content. An XML signature applied by Lotus Forms client software signs the whole agreement. The above mentioned article explains how open standards based software can be used to complete the server-side function of validating the XML signatures in order to secure the transactions of a business process. Since Lotus Forms are XML documents based on XForms, this means that the entire business process workflow on a Lotus Form can be achieved with open standards based software.

XForms, XFDL and Lotus Domino

Just ran across a good developerWorks article on Integrating Lotus Forms with Lotus Domino.



Domino is a web application and web services platform that is often used in combination with the Lotus Notes rich client platform. However, as this article shows, it is possible for Domino to have broader reach out to all web browsers without a large client-side installation. The intelligence and interactivity of XForms are combined with the high precision presentation layer of XFDL to describe a rich client experience, but the Lotus WebForm Server is used to convert that to HTML and AJAX that is natively understood by the web browser. The net result is that XML data processing and web services from Domino servers are extended right out to the webtop.



Of course, if you do have the Lotus Notes client platform installed, then the story gets better because the Notes replication capabilities can be brought to bear for when a user needs to work in offline/disconnected mode. You can also use the Notes Composite Application Framework to create mashups involving Lotus Forms and other application components deployed to the Notes client. Whether you use the Lotus Forms Viewer or the Lotus Forms WebForm Server to render a Lotus Form in Notes application component, you have access to a running Lotus Form using an API. This gives you getters and setters, of course, so you can push data from other components into the Lotus Form, but you can also set up event listeners that are notified of changes made within the Lotus Form, so you can push changes from the Lotus Form to any other component in your mashup.



But net-net, if you want to extend your Domino applications and services beyond the usual enterprise IT boundaries and get access to new B2C and G2C market opportunities, using Lotus Forms is a way to do it. See the new article for technical details.

XForms, XFDL and Lotus Domino

Just ran across a good developerWorks article on Integrating Lotus Forms with Lotus Domino.

Domino is a web application and web services platform that is often used in combination with the Lotus Notes rich client platform. However, as this article shows, it is possible for Domino to have broader reach out to all web browsers without a large client-side installation. The intelligence and interactivity of XForms are combined with the high precision presentation layer of XFDL to describe a rich client experience, but the Lotus WebForm Server is used to convert that to HTML and AJAX that is natively understood by the web browser. The net result is that XML data processing and web services from Domino servers are extended right out to the webtop.

Of course, if you do have the Lotus Notes client platform installed, then the story gets better because the Notes replication capabilities can be brought to bear for when a user needs to work in offline/disconnected mode. You can also use the Notes Composite Application Framework to create mashups involving Lotus Forms and other application components deployed to the Notes client. Whether you use the Lotus Forms Viewer or the Lotus Forms WebForm Server to render a Lotus Form in Notes application component, you have access to a running Lotus Form using an API. This gives you getters and setters, of course, so you can push data from other components into the Lotus Form, but you can also set up event listeners that are notified of changes made within the Lotus Form, so you can push changes from the Lotus Form to any other component in your mashup.

But net-net, if you want to extend your Domino applications and services beyond the usual enterprise IT boundaries and get access to new B2C and G2C market opportunities, using Lotus Forms is a way to do it. See the new article for technical details.

Consuming DB2 Web Services with Lotus Forms

Check out this developerWorks article for a step-by-step guide to deploying a DB2 web service and then consuming that web service using the Lotus Forms Designer.



Once the WSDL for a particular DB2 web service is pulled into your Lotus Forms Designer, you select and autogenerate a data instance and a specific service, drag-and-drop the data instance onto the design canvas to autocreate the user interface, and then generate the run-time XForms submission for the service. The article above shows exactly how to do each step.



A smart XForms client and a smart interface to the server database mean no custom code in the middle. Thus, computing power is made available to a broader class of IT knowledge workers who require only forms and database skills. Process democratization in action.

Consuming DB2 Web Services with Lotus Forms

Check out this developerWorks article for a step-by-step guide to deploying a DB2 web service and then consuming that web service using the Lotus Forms Designer.

Once the WSDL for a particular DB2 web service is pulled into your Lotus Forms Designer, you select and autogenerate a data instance and a specific service, drag-and-drop the data instance onto the design canvas to autocreate the user interface, and then generate the run-time XForms submission for the service. The article above shows exactly how to do each step.

A smart XForms client and a smart interface to the server database mean no custom code in the middle. Thus, computing power is made available to a broader class of IT knowledge workers who require only forms and database skills. Process democratization in action.

The Way Forward for HTML5

Despite all the excitement about the possibilities that HTML5 offers for a better world wide web, I believe there is a critical flaw in the go-forward plan of those who are feeling the momentum.The problem is that they still haven't got ~80% of the web browser makers on board!By which I mean they haven't got you-know-who.



There's really only one way to break the loggerjam and move forward with advancing thestate of the web. We need to get you-know-who out of the way of progress by showingthat we can innovate on the web with or without their participation. We have now shown that this is feasible by way of the ubiquity strategy based on our abilityto deliver an interactive web application language in multiple web browsers with no client-side plugins and no server-side processing of the language. Click here to visit the project.



For all web advancement technologies, including HTML5, the longer term effect of the ubiquity strategy should be that the late bloomers are shamed into implementing the advancements, thereby obviating the need for the ubiquity code. But meanwhile the ubiquity strategy is the way to enable web advancement technologies including HTML5 to emerge (in the proactive verb sense of the word).

The Way Forward for HTML5

Despite all the excitement about the possibilities that HTML5 offers for a better world wide web,
I believe there is a critical flaw in the go-forward plan of those who are feeling the momentum.
The problem is that they still haven't got ~80% of the web browser makers on board!
By which I mean they haven't got you-know-who.

There's really only one way to break the loggerjam and move forward with advancing the
state of the web. We need to get you-know-who out of the way of progress by showing
that we can innovate on the web with or without their participation. We have now shown
that this is feasible by way of the ubiquity strategy based on our ability
to deliver an interactive web application language in multiple web browsers with no
client-side plugins and no server-side processing of the language.
Click here to visit the project.

For all web advancement technologies, including HTML5, the longer term effect of
the ubiquity strategy should be that the late bloomers are shamed into implementing the advancements,
thereby obviating the need for the ubiquity code. But meanwhile the ubiquity strategy is the
way to enable web advancement technologies including HTML5 to emerge (in the proactive
verb sense of the word).

Angels and Demons... and XForms

So, I went to the movies recently and saw the new Dan Brown flick Angels and Demons. Probably not much of a spoiler to mention that the plot suspense is derived from the need to defuse an antimatter bomb placed somewhere in Vatican city, and everybody's favorite symbologist is called in to decipher the clues that may help lead to its location.

And they only have until midnight to find it. And the baddies are going to kill a Cardinal every hour before the big bang just to prove how serious they are.

As a taunt, the baddies provide a webcam view of the bomb, which is in a place lit by artificial light. So, someone in the story has the brilliant idea of shutting off the power around town until they see the lights go off where the bomb is located, and the law enforcement folks dutifully begin working through each section of the power grid in sequence.

This is the point where I had some difficulty maintaining a sense of edge-of-your-seat suspense. It seemed to me that they could find out where the bomb was located before the baddies killed their first Cardinal by turning off half the power grid, then a quarter, then an eighth, and so on just like a binary search. I managed to force myself out of this funk and enjoy the movie by convincing myself that nobody in the story would have reasonably known about a binary search, but the point remains that relying on the right algorithm can save you a lot of brute force work.

In the case of deciding whether to use an XForms-based solution or to hand-roll your own data-intensive web application with a pile of javascript to drive the client-side, it's the same issue really. Do you want to do a lot of brute force work yourself, or do you want to benefit from the topological sort algorithm built into the XForms computation engine? In a world of angels and demons, the declarative updating of XForms is like a get out of hell free card. The problem with the imperative approach of javascript is that it's process-based (step-by-step) whereas client-side usability is best served by a less structured, more free form experience. Users pick what they want to update and when, and the program has to be responsive to all permutations of their behavior. Better to let the machine figure out how to keep everything in synch. That's why we have machines.

Angels and Demons... and XForms

So, I went to the movies recently and saw the new Dan Brown flick Angels and Demons. Probably not much of a spoiler to mention that the plot suspense is derived from the need to defuse an antimatter bomb placed somewhere in Vatican city, and everybody's favorite symbologist is called in to decipher the clues that may help lead to its location.



And they only have until midnight to find it. And the baddies are going to kill a Cardinal every hour before the big bang just to prove how serious they are.



As a taunt, the baddies provide a webcam view of the bomb, which is in a place lit by artificial light. So, someone in the story has the brilliant idea of shutting off the power around town until they see the lights go off where the bomb is located, and the law enforcement folks dutifully begin working through each section of the power grid in sequence.



This is the point where I had some difficulty maintaining a sense of edge-of-your-seat suspense. It seemed to me that they could find out where the bomb was located before the baddies killed their first Cardinal by turning off half the power grid, then a quarter, then an eighth, and so on just like a binary search. I managed to force myself out of this funk and enjoy the movie by convincing myself that nobody in the story would have reasonably known about a binary search, but the point remains that relying on the right algorithm can save you a lot of brute force work.



In the case of deciding whether to use an XForms-based solution or to hand-roll your own data-intensive web application with a pile of javascript to drive the client-side, it's the same issue really. Do you want to do a lot of brute force work yourself, or do you want to benefit from the topological sort algorithm built into the XForms computation engine? In a world of angels and demons, the declarative updating of XForms is like a get out of hell free card. The problem with the imperative approach of javascript is that it's process-based (step-by-step) whereas client-side usability is best served by a less structured, more free form experience. Users pick what they want to update and when, and the program has to be responsive to all permutations of their behavior. Better to let the machine figure out how to keep everything in synch. That's why we have machines.

It's a happy birthday...

Happy birthday to me!

Here's to XForms ubiquity;

In FireFox and IE.

Happy birthday to me!

But seriously folks, IBM is a proud sponsor and contributor to the Ubiquity XForms open source project, and the Lotus Forms team has exciting plans for capitalizing on the ability to have XForms support directly within a web page.

Gone is the distorting lens of limitations imposed by the fraction of language features that the dominating browser makers are prepared to support today. The Ubiquity movement is all about freeing us, as consumers of the interactive web, to express open standards for software that meets our customers' technical requirements and deploy our solutions directly to the web.

Gee, with all this birthday fun, the next thing I really ought to do is go on a Safari!

It's a happy birthday...

Happy birthday to me!



Here's to XForms ubiquity;



In FireFox and IE.



Happy birthday to me!



But seriously folks, IBM is a proud sponsor and contributor to the Ubiquity XForms open source project, and the Lotus Forms team has exciting plans for capitalizing on the ability to have XForms support directly within a web page.



Gone is the distorting lens of limitations imposed by the fraction of language features that the dominating browser makers are prepared to support today. The Ubiquity movement is all about freeing us, as consumers of the interactive web, to express open standards for software that meets our customers' technical requirements and deploy our solutions directly to the web.



Gee, with all this birthday fun, the next thing I really ought to do is go on a Safari!

The open standards basis of XFDL and the value of Lotus Forms documents

A Lotus Form is a document currently expressed in an XML vocabulary called XFDL (html version, pdf version).

This is significant enough, in and of itself, to be set off in a paragraph. XML is a de facto industry standard from the W3C, and this means that widely deployed, interoperable, industry standard software toolkits can be used to introspect and manipulate the content of XFDL, i.e. Lotus Forms documents, thus mitigating issues of vendor lock-in.

But the story gets better...

The XFDL format internally employs W3C standard XForms, so without further reference to any vendor-specific documents, the standard indicates where in the XFDL document to look for the data content created by an end-user who fills in the Lotus Forms document. Anyone with access to a Java reference manual could write code to prepopulate data into an XFDL (Lotus Forms) document before it is delivered to an end-user, and they can write code to extract data from the document when it is returned to the server for processing.

But the story gets even better...

XFDL incorporates the W3C XML Signatures standard, so widely available industry standard tools are available from multiple vendors for validating the security of digital signatures in XFDL documents. In addition to the Apache XML Security implementation, it is notable that Java itself now natively contains support for XML Signatures (JSR 105).

These standards mean that the entire server-side lifecycle of the Lotus Form can be achieved without being locked into using any particular vendor's API. Any application server, any portal server, any server-side environment that can receive HTTP POSTs and process XML in the POST data can be used in combination with Lotus Forms.

And if you ever hear a vendor try to play up high availability of a client-side browser plugin for processing their favorite file format, ask them "Plugin?? What plugin??" With Lotus Forms, you don't need a browser plugin at all because the Lotus Forms Web Form Server converts the XFDL into dynamic HTML that can be processed directly by the browser with no plugins at all. Best of all, when the user finishes interacting with the Lotus Form, the resulting XFDL document is delivered to the application server endpoint, where it can be processed as XML using the standard APIs.

The open standards basis of XFDL and the value of Lotus Forms documents

A Lotus Form is a document currently expressed in an XML vocabulary called XFDL (html version, pdf version).



This is significant enough, in and of itself, to be set off in a paragraph. XML is a de facto industry standard from the W3C, and this means that widely deployed, interoperable, industry standard software toolkits can be used to introspect and manipulate the content of XFDL, i.e. Lotus Forms documents, thus mitigating issues of vendor lock-in.



But the story gets better...



The XFDL format internally employs W3C standard XForms, so without further reference to any vendor-specific documents, the standard indicates where in the XFDL document to look for the data content created by an end-user who fills in the Lotus Forms document. Anyone with access to a Java reference manual could write code to prepopulate data into an XFDL (Lotus Forms) document before it is delivered to an end-user, and they can write code to extract data from the document when it is returned to the server for processing.



But the story gets even better...



XFDL incorporates the W3C XML Signatures standard, so widely available industry standard tools are available from multiple vendors for validating the security of digital signatures in XFDL documents. In addition to the Apache XML Security implementation, it is notable that Java itself now natively contains support for XML Signatures (JSR 105).



These standards mean that the entire server-side lifecycle of the Lotus Form can be achieved without being locked into using any particular vendor's API. Any application server, any portal server, any server-side environment that can receive HTTP POSTs and process XML in the POST data can be used in combination with Lotus Forms.



And if you ever hear a vendor try to play up high availability of a client-side browser plugin for processing their favorite file format, ask them "Plugin?? What plugin??" With Lotus Forms, you don't need a browser plugin at all because the Lotus Forms Web Form Server converts the XFDL into dynamic HTML that can be processed directly by the browser with no plugins at all. Best of all, when the user finishes interacting with the Lotus Form, the resulting XFDL document is delivered to the application server endpoint, where it can be processed as XML using the standard APIs.

The spectrum: From Enterprise to Line-of-Business Applications with Lotus Forms and XForms

Well, my frieds, it seems a good time to draw your attention to a collection of available resources that can help you understand how you and your customers can address a full spectrum computing requirements, from the enterprise information application all the way down to the simple design-deploy-collect-analyze pattern for situational applications that arise throughout the enterprise

First of all, check out the Lotus Forms Enablement videos on YouTube. There are videos that show Lotus Forms in action in government, financial, and HR scenarios where enterprise-level functionality is a must. But you can also see videos on the new Lotus Forms Turbo product, which enables business users to design and deploy simpler survey style forms for themselves in a matter of minutes.

I want to make a pitstop here to plug the value of the XForms standard in creating this array of products. XForms as a language has a strong declarative component. This means that non-trivial relationships between data and sophisticated interactional and presentational objects is simply declared by the form developer, and it is up to the form run-time system to enforce the relationships. This maps very naturally to how we human beings think and work. We say things like "Whenever I get an email from domain X, put it in my super special high priority folder". We don't directly write batch jobs that run loops over our inbox to categorize our email, and even if we did, the time at which those jobs would run would be specified declaratively! In fact, I don't think it's hyperbole to say that the universe itself operates mostly on declarative laws. Gravity just happens. If you let go something, it drops. It's the law; get used to it ;-).

The point is that the declarative language constructs of XForms are what enable Lotus Forms to accelerate enterprise-level application design, to enable end-user design of simpler applications, and to ensure interoperability between these two types of applications so that the simpler situational applications can be scaled up to the enterprise level as their value becomes more broadly established. The declarative constructs of XForms accomplish all of this due to the simple fact that it is far easier to create software that maps point-and-click/drag-and-drop design experience gestures onto high-level declarative language constructs than it is to map the same things onto huge blobs of imperative scripted code from a general purpose programming language.

And don't just take my word for it. When you finish watching some of the videos at the YouTube link above, how about going for a test drive? You can get free trial downloads of the Lotus Forms, including the client-side runtime and design environments. If you like the enterprise-level capabilities, but you don't want to deploy a client-side runtime, you can also purchase the Lotus Forms Web Forms Server, which translates Lotus Forms into standard web pages. But once you're in test-drive mode with the client-side runtime viewer, check out the Lotus Forms catalog of sample forms. Finally, you can also test drive the new offering for non-technical users directly, without having to install a thing by visiting Lotus Forms Turbo on Greenhouse, or if you'd prefer to test drive it in-house, then just download it from the free trial downloads page.

Either way, once you've gotten Turbo, see a couple of the videos then think of your own simple survey app. Design and deploy it right onto Greenhouse and see how long it doesn't take!