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.