InfoPath and XForms

InfoPath and XForms Jon Udell explores the issues with Microsoft's Jean Paoli:
"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."