Smarter Everyone, Smarter Everything, Smarter Everywhere
John M. Boyer 060000VMNY 1,585 Views
Well, it's only two days into the W3C Tech Plenary and already I have enough things to write about that I cannot possibly inflict it all upon you in one blog entry. So, I'm just going to give an overview so that I'll remember to talk about some of this stuff in more detail later.
But first, an excellent bit of humour from another long-time W3C member who also happens to live in Canada (a little knowledge of Canadian geography and politics helps with this one):
Liam: Where do you live?
John: I live in Victoria, which is near Vancouver.
Liam: Oh, I live in Ontario, which is near Toronto.
Well, it was funny when Liam said it :-)
Anyway, for the first two days here I have been able to sit as observer on other working groups as well as have some individual discussions of some importance. Here is a summary:
The chat with Liam also included his hopes for XForms eventually adopting XPath 2.0. More about this in another blog entry...
Sat in for a while on the Compound Document Formats working group. Major topic of discussion was event flow between DOMs. How do a parent and child document come to agreement on whether events flow between them? Where does the capture phase start? More to come...
Sat in on the XHTML working group. Major topic: XML events. Specifically, how to upgrade XML events to offfer authors the ability to dynamically add and delete listeners after the document is first loaded. There's not a lot of complexity semantically, but the discussion of the vocabulary involved led to a very exciting discussion about the meaning of namespaces, especially as applied to attributes. This will be a beaut of a blog entry...
Talked with Doug Schepers, who was very interested in having a declarative way of doing AJAX-like things so that the functionality could be securely enabled even with scripting off. I told him I would demo it tomorrow in my part of the Rich Web Application Backplane panel. It's called XForms. More to come...
Finally, had a very good chat with Jose Kahan and Thomas Roessler about making progress on correcting the impedance mismatch between canonicalization and xml:id, with implications for a revision of XML Signatures. Lots more to come...
Stay tuned for more on these points!
As the world wide web transforms from a vehicle of information dissemination and e-commerce transactions into a writable nexus of human collaboration, the Web 2.0 technologies at the forefront of the tranformation may be seen as special cases of a more general shift in the conceptual application model of the web.
The classic 3-tier model has the web browser and OS on a thin client tier, the traditional server tier offerings for data persistence and workflow or business process managment, and a fat middle tierof custom JEE code. The custom middle tier code has two responsibilities. It has to invoke allthe server tier API calls necessary to perform business transactions, persist data and the like. But frankly, the server tier has received work for decades, so its scalable, robust and has well-definedeasy to use APIs. So, the bulk of the work in today's web applications consists of back-filling for theunderpowered thin client tier. To achieve a single business transaction, we have to do a complicated juggling act of the multiple pages, some only conditionally presented, each collecting some small amountof information that has to be validated, and the results aggregated until the transaction is ready.
The Web 2.0 application model is essentially a 2-tier model. It was a little hard to recognize that thistransition was happening in the early days when Web 2.0 just meant blogs and wikis. At that time, Web 2.0just meant content democratization, which is the idea that non-technical users could create andshare content on the web without needing to involve web application programmers. This was quiterightly viewed as a revolutionary breakthrough because it did for the web what the word processor did forthe personal computer. But if you remember that it takes two points to make a line, and then look atat the history of the personal computer, it's trajectory as a revolution did not become evident until the second killer application of computing, the spreadsheet. This application created what we callprocess democratization. This is the idea that non-technical users, or semi-programmers,could define how computing power would be dispensed to solve problems without needing to involve high-endapplication programmers. This was revolutionary because the non-technical users who were enabled to definetheir own processes were closer to the business problems and also far more numerous. The same thing isnow happening on the web, and it is the next phase of Web 2.0.
The Web 2.0 server tier is smarter than it used to be, exposing its capabilities directly to the Web 2.0 client tier with web services, REST services, or feeds and ATOM publishing.Similarly, the Web 2.0 client tier can connect directly to these services without needing the JEE web developer in the middle. Through AJAX presentational libraries like Dojo and AJAX data interaction libraries like Ubiquity XForms, the client is smart enough to drive not just simple user interfaces, but data validation, conditional user interface presentation, and access to web services throughout the end-user fill experience. It is even smart enough to offer webtop design and deployment experiences for these applications.
In this regard, I would like to draw your attention to the most exciting product addition in the new Lotus Forms 3.5 release. The new product,Lotus Forms Turbo, provides non-technical users with a web experience for the design and deployment of data collection forms and reporting functions.To get an idea of how the non-technical user is enabled, see the new YouTube videos on Lotus Forms Turbo.If a picture is worth a thousand words, these videos are priceless, so I'll stop writing because when you see, you'll know![Read More]
John M. Boyer 060000VMNY 1,381 Views
The IBM Workplace Forms product suite will make your life easier. It simplifies by an order of magnitude the work of creating and maintaining forms applications.
Sometimes I hear people say "Forms. Hey, name, address, pepperoni, extra cheese. I know about forms. Nothing new there." Well, guess again because we're not talking about those kind of forms. After all, hey, you do already know all about those kind of forms.
In this blog, I'd like to be able to talk to you, the developers in our community, about what makes IBM Workplace Forms different and better for forms applications. We'll talk about bigger picture trends, architectures and models, but in at least equal measure we'll talk about the nitty gritty, the pointy brackets, the XForms, the XML and other technologies behind it all. And best of all through our dialogue we'll develop a community of the most efficient and effective forms application developers on the planet.
For now, let's start with some links you can use to get your hands on some software to test drive.
Here are the reference manuals and user docs for the currently released version:
Now, for me, here's the really exciting link. Our upcoming new version will be available in 26 languages and combines rich XML processing capabilities of XForms with the precision presentation, rich user experience and superior authoring experience of Workplace Forms.
Here's a link to the current public beta:
(This is the Lotus main beta page. The direct link is http://www.lotus.com/ldd/beta/workplaceformsbeta.nsf/)
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
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
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]
John M. Boyer 060000VMNY 1,488 Views
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?
John M. Boyer 060000VMNY 1,313 Views
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
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.
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.
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.[Read More]
John M. Boyer 060000VMNY 1,434 Views
Now you can get free access to the trial versions of IBM Workplace Forms software. The trial software includes the Eclipse-based visual design environment as well as the rich client viewer (a desktop application and web browser plugin). The suite includes a server component that delivers the form viewing and rich user experience with a zero footprint on the client (using the existing web browser only with no client-side install). However, the server product is not part of the trial software.
Workplace Forms supports development and deployment of XML forms and XForms-based XML forms in the following languages: Chinese Simplified, Chinese Traditional, Croatian, Czech, Danish, Dutch, English International, Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese Brazilian, Romanian, Russian, Slovakian, Slovenian, Spanish, Swedish, and Turkish.
One final note is that in order to get the trial software, you have to get an IBM developerworks ID. But that's free and easy to do, and the benefits immediately begin with access to the most powerful, advanced, pure XML electronic forms system on the market today.[Read More]
The annual World Wide Web Conference is being held next week in Banff, Canada. It's about an hour's flight from Victoria, where I live, so of course I'm going!
I served on the program committee of the XML Web Data track this year. Competition to get into the conference is quite stiff, so recommending a paper for acceptance is a low probability event. Of the nine papers I reviewed, most were really good, and a couple that I had hoped would make it to the program will indeed appear. I am pleased to be chairing a session on Thursday May 10 that includes one such paper (I did not receive the other two for review).
I will also be presenting in the W3C Track on Friday at 1:30 as part of an Architectural Integration session organized and chaired by Steven Pemberton. I will be presenting on The W3C Rich Web Application Backplane, a forward-looking view of the possibilities for integration and composition of web applications leveraging W3C formats and APIs.
Finally, I'll be presenting in the Dev Track on Saturday at 1:30. My talk will demonstrate a schema-initiated drag-and-drop design experience for XForms using the Lotus Forms Designer.
Hope to see you there![Read More]
John M. Boyer 060000VMNY 1,480 Views
Got a request today to provide more specific information on exactly where to find the XFDL reference manual.
The documentation site link in my prior post includes a link to the currently released XFDL Reference Manual. For ease of use, the following appears to be the specific link on that documentation site:
Note that you will ultimately receive the XFDL reference manual in PDF; we always publish our language manual in PDF because PDF is good at static readonly documents. XFDL is good at dynamic interactive precision forms applications, but that doesn't mean the language manual should be expressed in it.
On a separate note, you can find a fairly comprehensive technical introduction to the integration between XFDL and XForms in my XML 2005 conference paper. The upcoming version of IBM(R) Workplace Forms(tm) will be accompanied by an updated reference manual that describes the union of XFDL and XForms exhaustively, but at 36 pages, the conference paper actually gives quite a thorough start to those interested in the pointy brackets. Here's the link:
John M. Boyer 060000VMNY 965 Views
XForms 1.0 Second Edition has been published today at http://www.w3.org/TR/xforms/
To get an idea of the quality and quantity of improvements made to XForms, please see http://www.w3.org/2003/10/REC-xforms-10-20031014-errata.html
Based on this improved foundation, the XForms working group will now be focusing its energies on the completion of XForms 1.1. To get an idea of what will be available, check here: http://www.w3.org/TR/xforms11/
The one comment I would make about the above working draft is that the we will almost certainly revert to using the same namespace currently used for XForms 1.0, and instead use some mechanism within the language to do versioning.
In keeping with my prior post about signatures and namespaces, it is important to version a language either internally or by updating the namespace URI. Previously, we chose the namespace route because XForms is designed to be hosted within another language, so it has no root element of its own to which a version could be attached.
However, XForms 1.1 is using some special schema wizardry that allows it to have a "chameleon" namespace, which will make it easier to import XForms into a host language like XHTML without namespace qualification. I'm not a big fan of doing this, especially for host languages other than XHTML because it becomes harder to find the XForms within another document and host the XForms functionality separately from the original host language.
Nonetheless, the feature is there and it occurred to me during the W3C tech plenary that the chameleon namespace could be used to put XForms 1.1 back into the XForms 1.0 namespace. That means that XForms processors trying to determine what semantics to attach to the vocabulary need some other way to make their decisions. So we simply have to solve the versioning problem without using a change of namespace URI.
The camp that wanted us not to change namespaces will be happy. My own XSLTs will be happy too.[Read More]
The World Wide Web Consortium, or W3C, produces the "standards" for all sorts of web technologies with which we are all familiar, including XML, XSLT, XML Schema, HTML, CSS, PNG, ..., and XForms. The W3C calls these things "Recommendations" because after due process and careful review and implementation, the World Wide Web Consortium recommends the technical specification for world-wide development and deployment. And this is what has happened to all the recommendations listed above.
But just as software goes through maintenance and refinement, so to do the specifications that describe the software. For example, XML 1.0 is itself currently at fourth edition, and XML Schema 1.0 is at second edition.
On October 29, 2007, the W3C approved the third Edition of XForms 1.0 as a Recommendation, superceding the second edition from March 2006 and the first edition from October 2003. This release of the specification is quite important to the XForms community as it represents over 300 refinements, clarifications and corrections that have arisen in the last 18 months. The W3C Forms Working Group has worked very hard these past 18 months on what I would call "enterprise hardening" of XForms, and the numerous differences produced by the group can be viewed in the second edition errata page as well as the third edition diff-marked version.
Next up from the W3C Forms Working Group is an expected transition of XForms 1.1 to Candidate Recommendation. Stay tuned for more on that...[Read More]
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".
Well, now that I can finally log in to the blog system again, it's time for an update on XForms 1.1.
The working group has been addressing the "last call" comments of the community since last call officially ended back at the end of April. Although we got a pretty healthy review during the March and April review period, it so happens that we have received an equal or slightly greater number of review comments after the official review period. The working group has been treating these comments with the special "last call" status as well. This not only maximizes our responsiveness to our community but also, frankly, makes for the highest quality specification, which I think is quite important at the current stage of XForms within the big wide world.
As a side comment, I would say that the bar of technical precision is extremely high, in my opinion, relative to most other W3C groups, and in XForms 1.1 (as well as the new editions of XForms 1.0), we have had great success at tightening up our most sophisticated and powerful features, which is to the benefit of our users.
Since last call started on XForms 1.1, there have been nearly 150 comment records created in our database, which is quite a lot, but the number of records does not tell the full story because very many of those records report half a dozen or a dozen issues at a time, usually amounting to one person's feedback about an entire module within the spec. It is more telling to have a look at the diff marks in the editor's draft of XForms 1.1. There are over 650 and counting!
The working group met in Madrid last week to continue work on the last call. Many thanks go to our gracious hosts at SATEC, who not only provided all the facilities we needed to do the work (and a great dinner on Thursday), but whose members went out of their way for us after the meetings by driving us back to our hotels in the evenings!
When the meetings began in Madrid, we had 48 remaining last call comment records to address. I organized them into related categories, provide a sensible order of attack, and did my best to predict how long to spend on each topic. It was pretty daunting, though, because some of these issues were still open because they were the hardest to deal with and were deferred to the face to face meeting for that reason. I was mightily pleased with how hard the Forms Working Group worked in Madrid. Everyone did their best to elucidate all sides of each technical issue, and to compromise in order to reach consensus. We had a number of issues that were hard because both sides of a debate were crystal clear and each side could even see the sensibility and consistency of the other side, depending on the fundamental set of "axioms" one accepts about XForms as a language and application platform. Yet still, we managed to produce resolutions and then action items for 39 of the last call comment records.
Of the 9 remaining, 3 were resolved on the latest teleconference. Suffice it to say that the next month or so will be busy indeed as we complete all the action items related to the working group's decision and also come to consensus on those last six issues. Hopefully, we can advance XForms 1.1 to "Candidate Recommendation" before the publishing moratorium that is coming before the W3C Technical Plenary in Boston in November. It'll be a close call, but either way the long-awaited "CR" for XForms 1.1 should occur in the next two months at the outside.
Candidate Recommendation is a very important step in the W3C process. It says that the working group thinks the language is done, and the concerns of the wider community about it being done have all been addressed. This is the level of stability in the specification that is needed to support the second meanning of "Candidate Recommendation", which is that it is the "Call for Implementations". To be honest, many implementers have already added support for half or more of the new XForms 1.1 features, but this is the time period in which the working group must formally show a full implementation and at least two interoperating implementations of all features. XForms has no shortage of implementations, but starting to "dot the i's and cross the t's" on the implementation report before the year end.
Clearly, there has never been a better time to be working on XForms![Read More]
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.
John M. Boyer 060000VMNY 1,617 Views
XForms 1.1 is now a Last Call Working Draft!
The transition to "last call" is a declaration that the document is ready for general review by W3C working groups and the web community at large. It is also the final step in the working draft phase of the W3C Recommendation track. The general review period ends April 5, 2007. Afterward, the last call review comments are answered and the document typically proceeds to "Candidate Recommendation".
The spec now weighs in at a healthy 195 pages (well, the browser reports that it would take that many letter sized pages). You can get a more visual idea of the amount of work that has gone into XForms 1.1 by viewing the diff-marked version, which shows changes relative to XForms 1.0 Second Edition.
So, you ask, why would one want to use XForms 1.1? The answer is that you may already be using some aspect of 1.1 even in your XForms 1.0 forms today. The reality of standards work is that implementations lead the ratification of the full spec as implementers try the various designs to make sure they solve real customer problems. So the different implementations of XForms are each shipping with no small fraction of XForms 1.1 functionality pertinent to their respective customer bases. Often, the features are expressed as some kind of extension, but when the customer needs the feature now, then building it a way that the upcoming version of the language describes is just using good sense.
Some specific examples of XForms 1.1 functionality you may need right away are
There are lots of further additions and refinements to XForms 1.1, from more XPath functions to refinements of user interface controls, and I encourage you to see those diffs and find out what's coming.[Read More]
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.
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.[Read More]
John M. Boyer 060000VMNY 1,873 Views
After the Candidate Recommendation announcement for XForms 1.1 at the end of last year, the public implementation report period now begins in earnest. To celebrate the candidate recommendation, today you can now access a 25-minute podcast (MP3) I made to explain to you What's new in XForms 1.1 and why you should care.
And now for a very interesting news item. You know how good it feels to see a prediction you made come true? Well, that's me right now, and oh is it sweet. For some time now, I've been telling you about the new wave Web 2.0 client tier based on technologies like XForms. We deliver that vision to today's to web browsers using either a server that boils things down to the "assembly language of the web" or a client plugin. Either way the web is not solely defined by web browser vendors. Well, at the XML conference in December 2006, I saw it clear as day that the search companies were going to play an important role in demonstrating this. What'd'ya know, the first thing this year and Yahoo! has announced its strategy to foster a mobile ecosystem and deliver the best mobile internet experience to billions of consumers. The underlying technology for delivering on this strategy is the Yahoo! Mobile Developer Platform, which includes XForms. Google can't be far behind![Read More]
John M. Boyer 060000VMNY 1,581 Views
In the final day of the XForms face-to-face meeting today, we made great progress for XForms 1.1 defining synchronous or asynchronous submission.
A number of current implementations of XForms 1.0 perform instance data relevance pruning and validation followed by initiation of the data submission. The upload and download of octets occurs asynchronously, and when completed, the xforms-submit-done or xforms-submit-error is dispatched. However, the current recommendations for (DOM2) XML events and XForms actually describe a synchronous procession that starts with dispatching an xforms-submit through fives steps of default processing from relevance pruning and data validation all the way through to completion and dispatch of xforms-submit-done or xforms-submit-error.
A difference of behavior occurs when an action sequence contains a
In reality, form authors should put the follow-on actions after a send into a handler for the xforms-submit-done event, since actions over data should only be run if the submission succeeds. Still, what's a working group to do?
We'll be adding a new attribute, probably called mode and probably having the value synchronous or asynchronous, so that the form author can choose which behavior is best. The synchronous behavior will have other advantages like suspending user interaction with form controls, but the default will undoubtedly be asynchronous.
Meanwhile, XForms 1.0 authors, get into the habit now of putting actions that operate over submission response data into the xforms-submit-done handler, not after a send action.[Read More]
A rich client platform (RCP) is a framework of widgets, widget containers and other processing capabilities that facilitate sophisticated application development and deployment. One important aspect of RCPs is that they tend to be highly cross-platform because platform support is provided by the framework.
In both cases, you get sophisticated capabilities and cross-platform support. In the case of RCPs, you get these benefits by learning a framework, deploying the platform to the client-side and developing applications targeted for the platform. The one negative here is that you are invested heavily in the platform, so if some aspect of the platform is a showstopper (such as large download size), then you won't be able to deliver the application. In the case of RIAs, you get the benefits by learning a framework (browser HTML/JS/AJAX + J2EE), deploying the platform to the server side and developing applications targeted for the platform. The one negative here is that you are heavily invested in the platform, so if some aspect of the platform is a showstopper (such as no offline operation of the application), then you won't be able to deliver the application.
XForms solves the RIA/RCP conundrum by providing a framework for expressing the core data processing asset of an XML-based application independently of the deployment paradigm. There are XForms implementations of both types, RCP and RIA. In particular, the IBM Lotus Forms Webform Server is a product that converts an XForms-based Lotus Form into a rich internet application (RIA) automatically. The IBM Lotus Forms Viewer is a rich client platform (RCP) that provides the run-time for XForms-based Lotus Forms. The application developer is free to think about the application without thinking so much about the pecularities of how it will be deployed.[Read More]
John M. Boyer 060000VMNY 1,843 Views
The W3C recommended a migration to XML of web content in January 2000. It's called the XHTML recommendation. The language was further updated to XHTML 1.1 in 2001, and again it was approved by the W3C membership as a full recommendation. The point is that these recommendations represent more than 6 years of the W3C recommending an XML basis for the future of the web.
The XForms working group defines an important web technology: the next generation of web forms. The technology became a recommendation in 2003 and had a significant refinement earlier this year. Again, XForms has been approved by the W3C membership.
One reason behind the strength of the XForms community is its broad applicability as a web technology. XForms defines the core XML data processing asset, whether the data processing needs be simple or complex. It is designed to be connected to numerous host languages like XHTML, SVG, Voice XML, XSL-FO and even XML vocabularies like XFDL (the one used on Workplace Forms to provide a secure, high-precision presentation for XForms).
The point is that the web is more than just what web browser makers implement. Part of the reason for this is that web browser makers don't tend to make much money on web browsers, so their desire to pour development dollars into their proper maintenance is stunted. As a result, web technologies have flourished from numerous third parties who are helping to define the future nature of web content. Frankly, the browser makers so this coming and created the notion of a plugin precisely to allow web technologies to flourish without their having to do all the work. Really, it's analogous in that respect to open source.
I think the W3C has somewhat lost sight of these facts recently. There appears to be some fear that browser maker lag in implementing some of the recommendations equates with the W3C not "leading the web to its full potential." I respectfully disagree. The situation is not nearly so black and white. The web is supposed to work this way. The web cannot afford to be constrained to the limitations of a browser maker hegemony, especially when they don't even really want the job and have given us the tools to catch our own fish, so to speak.
This brings us to the topic of the recent escalation of Web Forms 2.0 from a member submission by a web browser maker to a first public working draft. The original W3C Team acknowledgement strongly encouraged that the work of accounting for the member submission be placed squarely in the new charters of the XForms and HTML working groups. I can only conjecture that its publication as a working draft of the WAF WG was designed to make sure that the issues raised by Web Forms 2.0 do get addressed, and right soon.
Don't get me wrong. Web Forms 2.0 has some good ease-of-authoring features. By ease-of-authoring I do also mean to imply a smoother migration path for existing HTML-based web content. Members of the XForms working group have been tracking the development of this document, and it turns out to be not too difficult to accommodate the most critical features. However, there are features of Web Forms 2.0, like the repeat construct, which diverge from the conceptual model of XForms for no apparent reason. I would expect that such divergences would be replaced by the XForms basis in the future. One aspect of Web Forms 2.0 that does need the most work is that it really is asking the W3C to take a giant 6 or 8 year leap backward away from an XML basis for web content. This seems a less viable demand, esp. since tag soup HTML UAs are perfectly capable of recognizing markup that isn't ill-formed!
In general, it is true that ease of browser implementation of new features is one important concern, but IBM believes that there are many important factors that contribute not only to the total cost of ownership of web applications but also to the ability to create and maintain a significantly broader spectrum of current and future web technologies. IBM believes that these factors are important enough that it is essential to use new features of HTML as an enticement toward greater conformance of web content to XML syntax. Moreover, IBM strongly advocates for the renewed charter of the XForms and HTML working groups to include unification of the Web Forms 2.0 work with emphases on the ease-of-use benefits from WF2 and the XML basis from XForms. There will be compromises required of all parties, but also significant synergies that become possible by accommodating the full range of forms expertise available in the W3C.
The above are excerpts from the full IBM position statement, which has been posted to the W3C chairs list, the W3C AC Forum, and the public lists of the XForms, HTML and Web Application Formats working groups. See the XForms posting and the WAF WG posting.
In conclusion, I do not by any means want to constrain XForms to only one host language (XHTML). However, I also do not want to downplay the importance of the XHTML host language in helping to bring the great technology that XForms is to the people. The XForms working group is committed to a unification of the best that the Web Forms 2.0 has to offer. We already have a decent implicit data generation feature, and we look forward to expanding that to implicit data model generation so that the easier
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.[Read More]
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
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]
The XForms team finished our face-to-face meeting in Amsterdam last week. A major focus of the work on XForms 1.2 is called modularization.
The rationale for this work is the observation that the set of XML data processing problems which may have first arisen in the electronic form space are really more generally applicable to the XML data processing needs of RIAs and web applications. On the other hand, those who hear the word "form" may think they do not have a form problem because they still think of a "form" as a simple or static application like those for ordering pizza or flowers. However, XForms has solved numerous problems that keep coming up again and again throughout the W3C standards stack as well as the web application stack. By modularizing the components of XForms, we believe we can increase adoption of the components in other technologies which may not have need of all aspects of XForms.
The current view of the XForms 1.2 modularization can be viewed here. As an example of the rationale above, consider an application that may want to use the submission capability from XForms in a regular web application. The application would import the instance data module, but it might have an application-specific way of populating a data instance with data. The submission module would reference a data instance for the upload data and another instance for the submission results. An application-specific method would then be invoked to consume the submission result into the application, but the means of invoking that method could be an event handler for the xforms-submit-done event. The key issue here is that submission could be consumed by a non-XForms application without needing to incorporate the XForms recalculation engine, user interface controls and so forth.
The full elaboration of this modularization will allow applications to consume pieces of XForms incrementally, including the notion of data validation, data relevance, declarative data calculations, event-drive action scripting, repeats, switches, groups, basic user interface controls, and of course submissions.
John M. Boyer 060000VMNY 1,496 Views
What is the value proposition of an open standard?
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.[Read More]