InfoPath and XForms

Several folks have written to ask the same question about InfoPath: why no XForms support?

Bob DuCharme, author of XSLT Quickly:

If XDocs--excuse me, Infopath--is about forms, why didn't they call it XForms? Because the name was taken by something that they've chosen to extend without even embracing. It's time that XForms showed up on more radar screens. MS people consistently hem and haw about InfoPath's relationship to XForms; I'd love to see what Paoli had to say to you about it.
Micah Dubinko, author of a forthcoming book on XForms:
InfoPath is ignoring what could be the most important related standard: W3C XForms. About the same time that Jean Paoli was starting his work on what is now known as InfoPath, a group of forms vendors started work to update the ancient html forms technology.


As a matter of fact, I did ask this question. Here's the relevant portion of the interview:

Paoli: Forms are too inflexible. You have a choice, when you want to gather data, between two families of technologies. With the family of forms, it's like having a piece of paper that doesn't grow, you write two lines of customer data, and then if you want to have a third customer, it's a big mistake, you have to take another piece of paper...and that's the form technology used today, it really sucks, people hate that. On the other side, you use Word or some other word processor, which can grow normally -- you can have spell checking, you can add rows to a table -- big advance of technology [laughs] -- but you are stuck, you cannot extract data properly from this document which is viewed as a form, you don't have the sophisticated validation that you need. So what we wanted to do was really something in the middle, which was a mix of the two things.

We had numerous marketing meetings to decide what do we call these kinds of documents: DocForms? FormDocs? We finally said, it's easier to call what we are doing a form, but then we will explain that it's far more, it's really a mix, a hybrid, a new thing between those two models.

Udell: And the name XForms had already been taken.
Paoli: Yes, but XForms does not have the same goal. The goal is to gather information. How do you gather information best? You give views on the data. We can create multiple views adapted to the kind of gathering you are doing. Think about an insurance claim. The end user is going to think about the first page, he puts name and address, the second page describes what happened, and then at the end, what he is expecting. He thinks about it as three pages. The name appears everywhere. But it appears only once in the XML file. Having multiple views helps make the user experience extremely natural.

InfoPath builds on top of XML, Schema, XSLT, XPath, XHTML, CSS, WSDL, SOAP, DOM, EcmaScript -- in other words, the XML core -- without appeal to new standards. There is undoubtedly overlap with XForms, which for example has a strong model for repeating items that can enable forms to grow dynamically in the way Paoli complains today's forms do not. On the other hand, Dubinko -- describing the goals of XForms --- writes:

The difference between a blank form and a filled out form should be minimal, and representable as an XML document.

That seems rather different from InfoPath's radical separation of data from multiple views, which in turn mandates a heavy reliance on XSLT transformation, which in turn mandates a design-time technology that can automate the creation of those XSLT transforms. All this was not undertaken lightly. Paoli has very clearly in mind a new kind of user experience that, he believes, will be optimal for data gathering. Whether the document/form hybrid really is a new thing, and more importantly, whether it really is optimal for the intended purpose, is of course something we will all judge.

Meanwhile, we would all like to hear more from Microsoft on the subject of XForms. There are a jillion HTML forms in the world. XForms, unlike InfoPath, aims to create a migration path for them, or at least for the skills that made them. That may not be the goal of InfoPath, but it is certainly a worthy goal that ought to be addressed somewhere in the Microsoft technology portfolio. How about it, guys?


Former URL: http://weblog.infoworld.com/udell/2003/02/26.html#a621