Very soon, I'll be heading off to the W3C Technical Plenary.
Sure, it's in Cannes, but it's also in February, so it's all business.
This is a time when many W3C working groups congregate in order to have time to have intergroup meeting times. So, the XForms working group will have its face-to-face meeting later in the week, but so will a dozen or more other groups. Similarly, the compound document format group chaired by Kevin Kelly will meet earlier in the week. I plan to sit in on some of that as an observer and to talk as needed about the intersection of XForms and compound document formats.
The mid-day of the plenary is a time for common presentations, one of which is a panel presentation called "Rich Web Application Backplane". Kevin is the chair of the panel, which has a number of panelists including yours truly.
The panel is basically about the notion that we have lots of rich XML processing capabilities available now, expressed as XML. This allows for compound documents that are capable of aggregating the data, views, rich user experience, and web services needed to complete a sophisticated web application transaction.
While some further work can be done to do a better job of creating more seamless integration of various components in the W3C stack, a lot of the foundational technologies are already there and in pretty good shape, so herewith is the rallying call to pull them together into an XML backplane capable of supporting the design of rich web applications.
One of the things I really like is the potential for XML events to be the glue that binds together nicely modularized XML technologies into an effective, intelligent compound document. I think an update to XML events would be useful to add certain key features, but even as-is the capture and bubble phases combined with event context have allowed me to express an integration of XML signatures into a compound document format that includes XForms and a first class presentation language (XFDL, of course).
Of course, whenever we talk about advancing the conceptual model of the web in some way, we get a certain amount of feedback about whether we are talking about evolutionary change or revolutionary change. The latter causes IT folks ot go weak in the knees over deployment issues, so branding something revolutionary is really about trying to stop it from happening.
This means that you can have a staged migration to a rich native client that directly runs the high level language because the conceptual model expressed by the language can be delivered, with few limitations, to today's client platforms-- zero footprint.
In the IBM Workplace Forms space, we call the native client "Viewer" and we call the zero-footprint version "WebForm Server". The idea is that you design an XFDL form containing precision presentation, rich user experience and business logic/dynamic interactive capabilities using XForms within the XFDL. Then, you deliver it using one of these two interactive rendition engines.
A demo of this capability is how my panel segment will end. After all, nothing trumps being able to show some of the kinds of capabilities that would be enabled by the rich web application architecture.
Smarter Everyone, Smarter Everything, Smarter Everywhere
John M. Boyer 060000VMNY 1,331 Views
I did a customer site visit out in Washingto DC earlier this week (I live on the west coast of Canada). On the plane next to me there was a guy who had a book to read with a title that was something like "Three men, a raft and the most dangerous river". It appeared to be about three guys who navigated the Amazon in a raft.
Perhaps it was just my mood at the time, but it struck me as a little ironic to read a book about it. It's just so much the kind of thing you have to do.
Well, while we're in the land of giant leaps... forms applications are like that too. You can read, but you have to *do* too.
For my own case, the Workplace Forms beta download is accompanied by a reasonably substantial sample form that I wrote to help illustrate for you a number of the important features that are available, such as a wizard-like or guided-interview modality attached to the front end of a "traditional" form.
The internal markup is highly commented and laid out so that you can really get an understanding at the pointy bracket level even if you only have a text editor for exploration (though the beta also includes our eclipse-based designer product).
So, speaking of doing (and also to fulfill my promise to talk about the nitty gritty), it seemed a good idea to share with you one of the interesting things I learned from this form.
The typical form is designed to be used in a particular business context. In general, you will not find that a form (of the size and scope that Workplace Forms targets) is easily purposed to serve multiple locales or business contexts. The "mortgage preapproval" sample form was created to give people in many locales some idea of what the product set can do, but it's not really the intent to address all locale-specific peculiarities. For example, a more realistic form in Russian would have the formulae and inputs adjusted to collect monthly salary information rather than yearly information. And in some locales, it isn't even appropriate to collect interest on a loan, nor is it appropriate to accept a service like a loan for free, so interest is something that is informally negotiated rather than being driven by an exact compound interest formula.
Anyway, as I said we just wanted to provide a form that would give a good idea, so we ended up with the task of translating the form to many languages.
Something I didn't expect happened because I put some localizable strings into certain XML attributes, like an XForms calculate or the value attribute of an xforms:setvalue. The word "Electricity" becomes "L'Electricitie" (pardon my omission of accented characters).
The addition of the apostrophe is problematic when in an attribute because the attribute contains an XPath expression. So you have double quotes around the attribute value, so that single quotes are used around the literal value, and the apostrophe conflicts with that. Moreover, the apos character entity is of no help because that is an encoding consumed by the XML parser, not the XPath parser, so it is converted from a character entity to the literal character by the XML parser so that the XPath parser still receives the offending character.
So, it seems forms have to be designed so that strings intended for humans don't appear in XML attributes that contain XPath expressions. My apologies to my European friends, who no doubt know this already. As I said, pardon my French.
John M. Boyer 060000VMNY 1,281 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 1,157 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/)