developerWorks: This is a developerWorks podcast. I'm Scott Laningham. I'm joined by Dr. John Boyer, Lotus® Forms architect and chair of the W3C Forms Working Group that produces the XForms standard. He's here to talk about XForms 1.1, what's new, and why we should care. Welcome, John.

Boyer: Thanks very much, Scott.

developerWorks: Now, before we talk about what's new in 1.1, XForms 1.1, I'd like to get your thoughts on, in a general sense, the importance of XForms. I mean, we spoke with XML and metadata consultant Dan McCreary back last summer on this podcast, and he gave us his thoughts on the basics of XForms and talked about its value. But you come from a little different perspective on this, and I'd love to hear your thoughts on it.

Boyer: Well, that's a great question. I do actually like to give the business perspective or a little bit of business perspective even for a technical audience because I find that we're often having to justify our technical choices in terms of benefit to the business.

So I think that if you look at it from the business perspective, you should be caring about XForms because they allow you to create cheaper and to maintain robust and dynamic Web applications that collect data. Form is a sort of thing that collects data, but you can do that poorly or you can do that well, right? And if you're able to do it well, and you're able to do it cheaply, then you know, that's going to correspond to lower RFP bids, that's going to correspond to winning more deals if you're a services company, or if you're an IT developer building an in-house application, it's going to translate to a lower total cost of ownership. And aside from just those, you know, getting the initial deal, there's issues like customer satisfaction, retention, repeat business. Those things are part of the equation because of reliability of XForms applications.

And so the types of things that I'm talking about are sort of more esoteric things. You know, people don't care about technology for its own sake. They don't care about XForms for its own sake. They care about efficiency, they care about flexibility, they care about accountability. And you know, XForms is a word that implies a technical solution that addresses those things that people actually care about. And if you think about how much might we care about those things, there's a statistic that 80 percent of the business processes today are based on or depend on forms, data collectors in some way.

And for that reason, I tend to argue that XForms 1.1 is the killer app of Web 2.0 because of the order of magnitude improvement that it gives in creating these data collection applications and also the wider audience of potential creators of these applications that it enables.

developerWorks: That's very helpful. I mean, that certainly speaks to the business value, that 80 percent you're talking about. Now, I'd like to hear more about Web 2.0 later on, but right now I'm wondering if maybe you might talk a little bit more about how this business value is being created from a technical perspective.

Boyer: All right. So, you've probably filled out a classic, you know, name, address, pepperoni, extra-cheese type of form, or ordered flowers or something like that. Those types of forms don't sound very interesting or complicated. They don't sound like the business end of the deal, so to speak. But that's really because the HTML forms, their capabilities were sort of baked in the mid-1990s. And you know, in and of themselves, they're insufficient for creating really interesting applications.

But despite that, there's this huge pent-up customer demand for creating full-featured interactive applications. And customers don't want to hear about limitations, right? So what's been happening over the last 10 or 15 years is we've had several Band-Aid solutions that have been showing up, starting out with things like CSS, moving into JavaScript and the ability to dynamically manipulate the HTML. Ajax communications, the latest sort of buzzword, that allows you to dynamically refresh portions of the page without having to do a full page reload. You know, all of these things are providing incremental improvements that are addressing some of the most urgent pain points, but they're really just a set of disparate, as I say, Band-Aids to an overall problem that we have.

And I kind of look at them together as the assembly language of the Web, right? With this set of disparate technologies, you can build up a lot of applications, but for anything of more than modest sophistication, it quickly becomes untenable for human beings to maintain them over time, to even create them in the first place as they become quite sophisticated.

developerWorks: Right.

Boyer: Human beings tend to need higher-order languages so that they can see the forest for the trees, so to speak.

developerWorks: Sure. Yes.

Boyer: So anyways, I mean, it's just that we have a harder time grasping things when there's too much detail pointed at us all at once, right? I think that's why we've invented computers in the first place. And I think it's also why if you have to code your applications in something that's Java™ or JavaScript, the more of that type of coding you have to do the more complicated it gets relative to expressing your applications, which is what XForms allows you to do.

developerWorks: I think I get what you're saying about current HTML forms, applications with JavaScript having that simpler, brittle thing. But I'm not sure I understand what XForms means by the word form and why building an XForm is easier than coding, for example.

Boyer: That's a good question. It goes back to that name, address, pepperoni, extra-cheese type of form, you know? A lot of people, they think of forms as paper documents — very static. They don't do very much. They collect data, but they do it poorly. And I think there's a lot of latitude when you think of the word form as just meaning a data collector. It can do it poorly, or it could do it well, right?

And the pent-up demand from customers of the Web is to obviously do it very well, and that applies a certain amount of issues both in terms of the quantity of data that has to be collected as well as the quality of the experience that you have when you collect that data. I mean, collecting 10 times the data isn't just 10 times as hard, you know, because once again, the forest-for-the-trees type of concept, we see the big picture and then we drill down into the details. And that causes us to create data that has hierarchy, right?

And that's where XML, things like XML, are coming from, is to introduce that hierarchy. But we need to be able to surface that hierarchy in the user interfaces, which takes extra work, and we need to be able to have all of our commands, and scripts and so forth respond to that hierarchy, which takes extra work, beyond just the fact that you've got 10 times as much raw data or leaf nodes, if you will, to have to process. So and then there's the qualitative terms, too. I mean, if you think about, you know, having to fill out 10 times as much data, certainly there's going to be complexities there.

I think there's a U.S. tax form, for example, where there's six pages of instructions that help you figure out whether to check a single checkbox, right? That's very hard for a person to deal with if they're dealing with something like a static HTML form where they have to go read the instructions. They want a little more guidance or help in terms of making that decision.

So users are expected a guided interview experience. They're expecting that they're being told when there are errors that have been made, how to fix them, what to do next, right? They need all of that sort of stuff. So if you want a dynamic interactive Web application that solves the whole line-of-business-data-collection problem, that's what you're going to be using XForms for — that's when it's going to give you that order of magnitude increase of efficiency over today's Web application technologies.

developerWorks: John, talk a little bit more about that, if you would, about why it's such an improvement over those technologies.

Boyer: I guess I've been talking about the complexities of just creating the user experience on the glass, but in order to get the full picture, we probably should take a step back and think about the sort of the classic architecture, either the three-tier or possibly four-tier, and you squint at the middle one, but there's a larger architecture going on, you know, because a form as a data collector doesn't exist alone by itself. If you're going to collect data, it's always to drive some back-end business process. And if you're just collecting data, but then it doesn't do anything, then it's a useless process.

So we collect data on the glass, on the client tier, what we call the client tier. And this is where the HTML and the JavaScript engine lives. This is where your Web browser lives, and it's where the end user is interacting with the document. But way over on the other side, there's what we call the server tier. This is where all of the big iron applications are, the databases, the content managers, workflow processing engines, all of that sort of stuff. These are the things that perform the business transactions, and they store the information on behalf of the end user.

And on both of those sides — the client tier and the server tier — there's a relatively stabilized cost of how many end users am I trying to serve and how much is the software going to cost. And you know, there's not a lot of variability there. The really interesting stuff happens in the middle because that's where a lot of the custom logic for a particular application lives. We call this the middle tier. And remember I told you a moment ago, you might be able to squint at the middle tier and see two parts. Well, part of the middle tier is focused toward the server tier. This is where you're making the applications or the API calls to the server tier to store database entries, or to store content, or to make a transaction of some kind.

And you know, that code is fairly, it's relatively easy to write because there are robust APIs available. But the majority of work in the middle tier is actually focused in the other direction toward the client tier, so it's the client-focused middle tier, is where you're juggling all of the HTML pages and all of the JavaScript and all of that sort of stuff that corresponds to completing an entire transaction, right? Because for these larger applications that have more data that they're trying to collect, they're going to interact with the user over several client/server requests during a single session. And you need code in the middle tier that's actually juggling all of that stuff and saying, "Here's the next page, here's the next page."

So you've got not just JavaScript coding on the client tier, but you've got more Java coding on the client-focused middle tier, and you've got even more Java coding on the server-focused part of the middle tier. So I guess this is getting pretty long, but the point is that now that you understand that background, you can understand how XForms is actually combatting all of this coding complexity in three ways, one for each of those areas where the code actually exists.

So the first one is that as far as XForms is concerned on the client tier, we're trying to make an architectural shift to having sort of a smart document where the user-interaction layer for the full transaction is actually encoded in that one document so that it's kind of a bit of a rich client perspective even though you don't have to deploy it that way. But the point is that you're not doing a bunch of Java coding to juggle all of the HTML pages and make all the transitions and so forth. So sort of for those who know about the model view controller terminology, this MVC layer is actually built into this document format so that you're not writing Java code on the middle tier. So that's way number one.

Number two is that XForms actually makes a shift, I guess, away from pure scripting or pure imperative coding. It actually has a hybrid design where the scripting commands that you use are very powerful and focused on the actual data because the transaction data is the really important thing.

And then there are these declarative constructs for the user-interface layer that say "I'm going to bind to the data," so when more data shows up, more user interface shows up. And you don't have to write more script commands to make that happen. When data disappears, user-interface controls disappear. Formulas that maybe run and get automatically updated, and all you've done is written a one-line script that says add or delete a piece of data.

developerWorks: Very nice.

Boyer: Right?

developerWorks: Yes.

Boyer: Frederick Brooks used to be an IBM Fellow quite a while back, and he was famous for, there's a book called the Mythical Man Month, and he did this awesome study where if you tried to compare the complexity of code and how it grew as a function of how long the code got, how many lines of code there actually were. And he found that the growth in complexity was actually governed by this formula which is greater than linear. So what that means is, if you have 10 times the code, it's not just 10 times more complicated to create it, it's more like 30 times more complicated.

And so you can kind of understand from that where if you've got a language like XForms that's trying to reduce that length of code, that the the efficiency benefit from your reduced complexity is going to be more than 10 times simpler, it's going to be 30 times simpler.

So getting rid of coding is obviously very important. We've done two ways, and I think the third way is, I talked a little bit about some relatively simpler code that you have to build on the server side to talk to those server tier applications -- you know, the databases, and so forth.

Well, here we have an interesting phenomenon that's happening with what we call the Web 2.0 server. And this is where a lot of these server-tier applications are starting to expose Web services, restful services, Atom or RSS feeds, things like that, to actually push the server tier I would say back so that there's less and less coding that's needed to actually be able to interact with those server-tier applications directly.

So what's happening is that you've got XForms pushing the client tier towards the exact line where the Web 2.0 server tier now exists so the two can actually talk to each other without any coding in the middle. And that's where we're coming from when we're saying, this is a really a killer app for Web 2.0.

developerWorks: Yes, I was going to say, I remember you saying that earlier, and I think you said you think it's the killer app for Web 2.0. And is that why? Is that the whole of it? Or is there more to why you feel that way?

Boyer: I guess in a nutshell, you know, that's it. I mean, if you look back at the computing industry before there was a Web, I mean, and what were the killer apps of that time, you know, you had the word processor, it was the one application that really allowed people to create content that they could, you know, that they could share with other people.

developerWorks: And the spreadsheet too, right? I mean, those were kind of the two.

Boyer: Yes, that's right. And the spreadsheet allowed people to create and share content, but it got even better because it had sort of dynamic calculations that would happen where people could say, "Well, when someone types in this piece of content, that means this other stuff has to happen over here, to calculate a total, or a subtotal or tax, or whatever else it was."

And this took the computing power out of the hands of pure coders and put it into the hands of the direct line-of-business people who understood the business problems it had. And this is essentially what XForms is allowing you to be able to do with the Web. So for example, I mean, it turns out you can write an XForm that will feed your blog, or feed your wiki if you want it to. But really it's the fact that there's arbitrary data content that the end user wants to be able to create, and the server side is kind of the memory of the Web.

And the server tier in Web 2.0 is actually exposing things that an XForm can directly talk to. So XForms surrounds all of that desire to create and store content and share it with other people directly without need for the programmer in the middle.

developerWorks: So I'm seeing this smart document that interacts with the end user that you're talking about with XForms. What about the Web browser part of it? I mean, does it actually run an XForm, the end user's Web browser? How does that work?

Boyer: Well, you know, that's actually a great question because, you know, XForms kind of grew up in enterprise applications where people had more control over what actually got deployed to the desktop. So being able to say, "I've got a rich-client plugin that can plug into the Web browser" is obviously better in those scenarios, but increasingly, when we start talking about Web 2.0, we're talking about citizens facing applications for government or public-facing applications from the enterprise.

And it becomes a lot more difficult to say "Hey, in order to use this technology, you have to deploy or download and install this extra plugin." So you get a lot of companies that want to be able to do that anyway, but it really isn't the sweet spot in terms of getting XForms ubiquity out there. But it turns out that XForms today, XForms capabilities, are being realized in all the major Web browsers without the need even for a download. And they're doing this, obviously well, they're doing it in three ways.

One is that yes, there is the plug in possibility, but without a plug-in they're doing it in two ways. The first is a server-side compiler. Remember, I guess a little earlier I talked about HTML and JavaScript and Ajax being kind of the assembly language of the Web.

developerWorks: Right.

Boyer: Well, it's possible to create a server-side application that will read XForms content and boil it down to the XML JavaScript Ajax automatically and then ship that out to the Web browser, and the Web browser just natively understands that stuff. Right? Now, the point of efficiency is that this is not the kind of complexity of stuff that you want to write by hand in the same way that programmers 30 years ago, they programmed in Assembler language but we don't still do that; we need those higher-order languages.

But you know, with XForms as a higher-order language, it's possible to compile it down into stuff the Web browser natively understands. And we're deploying applications all over the place that do that today. Right?

The other way that XForms is being provided natively to Web browsers is that there exists JavaScript and Ajax libraries which express actual XForms processors, so even without standing up an extra server product you're actually able to get the dynamic interactivity layers of XForms in your browsers today just by running these extra JavaScript and Ajax engines.

So these things have been written by people who are really careful, smart, meticulous, and have spent the time or invested the time to get those processors up and running so that the rest of us can benefit as we try to create our data collection applications without having to deal with that complexity over and over and over again.

developerWorks: John, this has been great in terms of a much deeper dive into XForms in general and the business value and how it works really. Talk a bit about XForms 1.1. What's new with that? Why should we be excited about that?

Boyer: Well, the thing there is, I've been saying XForms does this, XForms does this over and over again. And it turns out that what I really mean to a large extent is XForms 1.1 does this.

developerWorks: OK. I see.

Boyer: So yes, XForms 1.1 has just become a candidate recommendation of the W3C which means that the working group thinks it's ready, the larger public has actually reviewed the specification and we've addressed all of their concerns. And it's sort of the public call for formal implementations. Now, it turns out that the XForms community has been developing 1.1 for a number of years now, and there are half a dozen vendors of XForms that are already shipping products with quite a number of the XForms 1.1 features in them in order to get all of these benefits that I've been describing for talking to the Web 2.0 server tier.

So XForms 1.1 is where we really pay the greatest attention to updating the data submission capabilities — the conversations that XForms is allowed to have with the server — has gotten a lot more sophisticated.

But beyond that, you've got better data-manipulation script commands, so XForms as I said, is hybrid, it's not purely declarative. It has scripting capabilities. It's just that the scripts are very powerful, and they've been made even more powerful. And of course, has an array, quite an array of smaller improvements of how you do the user interface, what the utility functions are available to the scripts, data-type validations, and the script controller itself has received conditional and iterative scripting capabilities only in XForms 1.1.

So I list off this laundry list of things that are now available, but that's sort of an indicator that XForms 1.1 is like a traditional 1.1 release. You know, everyone who has done software knows that you produce 1.0, and 1.1 is a monster. It's not the typical dot release. It's relatively big compared to 1.0.

developerWorks: Right.

Boyer: And that laundry list of things is an indication that that's what's happening. So in order to get all these benefits I've been talking about, you actually have to do XForms 1.1.

developerWorks: This is great. Kind of as a closing thing here, are there some other favorite Web resources you want to point the listeners to to find out more about this, I mean, in addition to the W3C site?

Boyer: Well, certainly on the W3C site there is, if you go to www.w3.org, you can go to /tr/xforms11, that's where the latest version of the specification is located. You can also go to the forms working group Web page, and at that location you have all of the latest information, we have a wiki going on, we have news available. And what's the latest progress on all of the specifications. You have the mail archives that are available, and furthermore, the mail archives actually have RSS feeds that are associated with them, so you can actually set up an RSS feed in your RSS readers so you can get notifications of the technical discussions that are going on, and you can even send e-mail if you want to participate, if you feel that you've got something to say about how things are going. So once again, the working group's main page is www.w3.org/markup/forms, and you get a whole host of resources there.

Oh, and finally, I should mention from that Web page you can also get access to a list of implementers that are available. So you have quite an array of implementations to actually choose from, and there is where you'll find the list.

developerWorks: Very good. Great information. Dr. John Boyer, Lotus forms architect and chair of the W3C Forms Working Group that produces the XForms standard. John, thanks so much for doing this today. This has been very educational.

Boyer: Thank you very much. I appreciate it.

developerWorks: This has been a developerWorks podcast. Check out our other episodes at ibm.com/developerworks/podcast, or see our channel on iTunes. I'm Scott Laningham. Thanks for listening.

Resources

• W3C Forms Working Group
  
  
• XForms 1.1
  
  
• XForms Implementations
  
  
• Podcast blog
  
  

About the author

Scott Laningham, host of developerWorks podcasts, was previously editor of developerWorks newsletters. Prior to IBM, he was an award-winning reporter and director for news programming featured on Public Radio International, a freelance writer for the American Communications Foundation and CBS Radio, and a songwriter/musician.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Resources
• About the author
• Comments