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.
Smarter Everyone, Smarter Everything, Smarter Everywhere
John M. Boyer 060000VMNY 1,388 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!
John M. Boyer 060000VMNY 1,513 Views
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.
John M. Boyer 060000VMNY 1,390 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,287 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/)