With XForms having fairly spotted support and with so few simple explanations of what it does, "What XForms does (and what it doesn't do)" (by John Boyer) attempts to address confusion about the XForms specification's purpose and reasoning.

The opening paragraphs:

The purpose of XForms is to express the core XML data processing asset used in sophisticated data collection scenarios.

In fact, it would be better if XForms were called the XML data processing language (XDP or XDPL) because XML is about standardizing data and about 80% of business transactions are based on filling out some kind of form to collect the transactional data.

To your Humble Editor's eyes, this reads something like this: XForms is a way to fill out an XML document in such a way that the document is valid, including validation by DTD or by Schema.

There's more to it, of course. Selected from the rest of the article:

XForms is all about thinking of the data first and driving outward to how that data gets exposed to applications. Perhaps the most prevalent of such applications are for presenting the data to a human user, though even human users have highly varied capabilities. For example, the desktop user and the PDA user have very different visual capabilities. Of course, this argument extends easily to meeting the far greater accessibility needs of the sight-impaired.

...

I sometimes get asked whether XForms will next extend itself to standardizing the actual presentation layer. Clearly, from above the answer is no. XForms standardizes the core XML data processing asset, and more work will go into doing a better job of that. The key issue we want is to address interoperability and reusability across applications and user contexts of the data processing behaviors that are fundamental to completing a transaction.

Have you used XForms? Whether you have or have not, what's your understanding of it? Is the specification useful to you?

for me, the Consorisium and people that in the beack of standard, must learn what is usability. We know they have a power, but for me, XForm is to complex.

Why dont you make an easy thing to develop. to make our nightmare less than it.

The idea of XForm is cool, but the spec.

Learn from the EJB 2.1 case, and EJB 3.0 new spec. event still new but better.

Anyone have try ObjectWeb OBS?

Frans,

It is quite surprising to hear about "too complex" here on the TheServerSide, when you look at the jungle that Java and J2EE technologies have become, especially in the area of user interface frameworks.

On the contrary, XForms is simplicity in person when compared with all this: it is markup-based (think of it as "super-HTML forms"), declarative (no Javascript mess to handle events and actions), powerful (in particular it does a lot of what Ajax does, but in a declarative way), and much more.

I will not try to argue that the XForms spec is easy to read. Unfortunately, most specs are difficult to read, whether produced by W3C or the JCP. While it is good for developers to read specs (in fact too few developers do it), it is not a required first step: you have XForms books, tutorials and examples that can guide you through the basics. I should also mention that the XForms working group is quite open to external suggestions, and has recently started doing most of its discussions in public mailing-lists, see:

http://www.orbeon.com/blog/2006/04/03/w3c-xforms-working-group-going-public/

For some cool XForms examples (that will work in stock IE and Firefox), check out these Orbeon PresentationServer (OPS) examples. It's all open source:

http://www.orbeon.com/software/get-excited

There are now implementations that don't require plugins or heavy clients, but are Ajax-based and run in any modern browser. Check out in particular our upcoming talk about XForms and Ajax at the XTech conference in Amsterdam in a couple of weeks:

http://xtech06.usefulinc.com/schedule/detail/133

Once you have started using XForms, you just can't go back to anything else ;-)

XForms is simplicity in person when compared with all this: it is markup-based (think of it as "super-HTML forms"), declarative (no Javascript mess to handle events and actions), powerful (in particular it does a lot of what Ajax does, but in a declarative way), and much more.
...
Once you have started using XForms, you just can't go back to anything else ;-)

Well, I hope that it is indeed possible to have "super-HTML forms" without all usual hurdles, but currently it does not look like it. Actually, I just got quite inspired with XForms initiative as well as with Orbeon server and XForms runtime. I do believe that this is the way to go comparing to some current and emerging server-based solutions that spit out HTML/Javascript mess.

But some of your samples do not behave well, and this is very sad. Take your ATM Example. It does not use redirection after input data is submitted. Well, this is what I actually expected, after all it is 2006, and everyone uses Javascript/XHR, right? No. Instead, your sample uses simple server-side forwarding with no resubmit check!

So, I enter the account number and get the balance: 100. Then I withdraw 10 from it, this works and I get to "Anything Else" page. Instead of leaving, I reload this page couple of times (the POSTDATA dialog is shown, of course). Then I click Back button to return to "View Account" page and reload it. It displays "70".

Come on, I thought that a new standard like XForms is supposed to improve the dreaded "double submit" issue, POSTDATA dialogs, stale pages and other related stuff. I thought that XForms are handled differently (that is, better) than regular HTML forms. Instead, I stumbled upon the same issues as in a 10-yr old HTML 2.0 application. What is the point then?

The ability to bind an XML model and to configure validation rules simplifies development, but where are usability improvements?

Take your ATM Example.

The proper link to the sample: http://www.orbeon.com/ops/goto-example/atm

Take your ATM Example.

The proper link to the sample: http://www.orbeon.com/ops/goto-example/atm

Michael, the ATM example does not use the new, Ajax-based XForms engine.

In fact the ATM example illustrates other capabilities of Orbeon PresentaionServer, namely the Page Flow Controller (PFC), which is OPS's page flow mechanism (which you don't have to use to use XForms, BTW). In this particular case, it doesn't use redirects, which is I think is not bad practice for wizards. But the PFC does have an option to perform client-side redirects as well. I hope this helps :-)

Take your ATM Example.

The proper link to the sample: http://www.orbeon.com/ops/goto-example/atm

Michael, the ATM example does not use the new, Ajax-based XForms engine.In fact the ATM example illustrates other capabilities of Orbeon PresentaionServer, namely the Page Flow Controller (PFC), which is OPS's page flow mechanism (which you don't have to use to use XForms, BTW). In this particular case, it doesn't use redirects, which is I think is not bad practice for wizards. But the PFC does have an option to perform client-side redirects as well. I hope this helps :-)

Well, it is nice that one can use XForms NG now. Still, this is a proprietary solution. It seems that XForms being a W3C spec does nothing to resolve form-submitting problems in a standard manner. I guess when John Boyer writes that XForms should rather be called the XML data processing language, he means, in particular, the lack of support for form [re]submitting, that revolves around the HTTP spec as well.

Until XForms spec improves form [re]submission and eliminates issues with double submits and stale pages, it will remain a half-baked solution. Yes, it is an improvement, but I personally want more ;) Yes, HTTP spec apparently has to be updated as well, so what?

Well, it is nice that one can use XForms NG now. Still, this is a proprietary solution. It seems that XForms being a W3C spec does nothing to resolve form-submitting problems in a standard manner. I guess when John Boyer writes that XForms should rather be called the XML data processing language, he means, in particular, the lack of support for form [re]submitting, that revolves around the HTTP spec as well.Until XForms spec improves form [re]submission and eliminates issues with double submits and stale pages, it will remain a half-baked solution. Yes, it is an improvement, but I personally want more ;) Yes, HTTP spec apparently has to be updated as well, so what?

Michael, I am puzzled by your use of the term "proprietary solution"! Orbeon PresentationServer is an open source project (under LGPL) which implements an open specification, namely the XForms W3C recommendation. I cannot imagine anything more open, really. Following this logic, what on earth would *not* be a proprietary solution then? I assume that MyFaces is a proprietary solution as well? What about all the UI frameworks that do not even implement a standard?

Regarding the "double submission" question: if this is the only problem left to solve in the world of web apps, then we are all be happy campers ;-)

Michael, I am puzzled by your use of the term "proprietary solution"! Orbeon PresentationServer is an open source project (under LGPL) which implements an open specification, namely the XForms W3C recommendation. I cannot imagine anything more open, really. Following this logic, what on earth would *not* be a proprietary solution then? I assume that MyFaces is a proprietary solution as well?

Yes, MyFaces is a proprietary solution on top of a standard J2EE spec. This is OK for a server-side framework, but XForms spec is supposed to be supported by browsers. Right now Orbeon provides XForms NG with Ajax engine because browsers do not support XForms. But future versions of MSIE or Firefox might behave differently with native XForms support (I am talking about submission, not about data binding).

Regarding the "double submission" question: if this is the only problem left to solve in the world of web apps, then we are all be happy campers ;-)

I understand that this problem does not directly relate to nature of XForms spec, but when I see "forms" in "XForms", I expect not only the API improvements, but the usability as well. I might be barking on a wrong tree :-) I will definetely try out the Orbeon server, the docs are very comprehensive.

Yes, MyFaces is a proprietary solution on top of a standard J2EE spec. This is OK for a server-side framework, but XForms spec is supposed to be supported by browsers. Right now Orbeon provides XForms NG with Ajax engine because browsers do not support XForms. But future versions of MSIE or Firefox might behave differently with native XForms support (I am talking about submission, not about data binding).

Well, MyFaces is an implementation of JSF, which is part of J2EE, so I wouldn't call it proprietary.

It is true that XForms was originally intended to run in the browser, but since neither Microsoft nor Opera nor Safari are currently working on this (but Firefox is), this vision is not likely to realize any time soon. But with Ajax-based solutions, XForms is here today, and in fact there are benefits of using an implementation of XForms that lives on the server, such as:

* Improved security. XForms engine state can be kept entirely on the server. End users do not have access to the XForms engine internals. The details of secondary XForms instances and calculations, for example, can remain hidden from the user.

* Ease of upgrade. Bug-fixes, new widgets, and extensions are deployed to all clients simply by upgrading one server-side component.

* Performance optimizations. Very large XForms instances can be kept on the server instead of having to be sent to the client, therefore improving page startup time and latency.

* Shorter time to market and easier maintenance. The bulk of the XForms implementation is implemented with higher-productivity server-side programming languages such as Java and a wealth of existing libraries, instead of native C/C++ or Javascript.

Because of these benefits, I believe that Ajax-based XForms can in fact be a preferred XForms deployment solution over any other, even in the unlikely event that all web browsers end up implementing XForms natively.

I understand that this problem does not directly relate to nature of XForms spec, but when I see "forms" in "XForms", I expect not only the API improvements, but the usability as well. I might be barking on a wrong tree :-) I will definetely try out the Orbeon server, the docs are very comprehensive.

I think XForms implementations, like other user interface implementations, will mature over time and address such issues as they go. For example, we have already done quite a bit of work to handle back and reload behavior between Ajax pages and restore page state appropriately. Double submission is one of those issues that we and other implementors will certainly tackle in the future :-)

Yes, MyFaces is a proprietary solution on top of a standard J2EE spec. ...

Well, MyFaces is an implementation of JSF, which is part of J2EE, so I wouldn't call it proprietary.

Yes, my mistake. I stand corrected.

I believe that Ajax-based XForms can in fact be a preferred XForms deployment solution over any other, even in the unlikely event that all web browsers end up implementing XForms natively.

Orbeon's Ajax-based XForms implementation does not just implement the spec, it also provides interaction/usability features that are out of current XForms spec scope. Other implementations or non-Ajax implementations may behave differently. On the other hand, with Javascript support becoming a requirement, I might agree with your opinion :)

I think Frans is right to point out the complicated nature of the XForms spec, but there are people who are attempting to make it easier to understand XForms and show the power of what it can do.

One of the key things that the XForms community needs to get across to the rest of world is that XForms makes it really easy to build simple forms (I mean *really* easy), but also has the punch in reserve to do really complex stuff, like web services, schema validation, and so on.

If I can offer a link to one of my own tutorials:

  http://skimstone.x-port.net/introduction-to-xforms

you'll see that it begins with the simple stuff like tooltips and help text, and shows that they are as easy as HTML. And even when it moves on to useful forms that save links to del.icio.us or allow you to search Flickr, the forms are still tiny compared to their Ajax, C++, VB, Ruby or Java equivalents, and their logic is very easy to see.

If you want to do web services, schema validation, conditional behaviour in sub-forms, Ajax-style 'don't-change-the-page-just-change-the-data' stuff (but without getting into spaghetti-script or having to choose one non-standard library over another), and so on, then as an SOA architect you just *have to* look at XForms.

Sure it's power means the spec is complex, but don't start there--Google for material by Steven Pemberton, T. V. Raman, Micah Dubinko, Allan Beafour, John and Erik...and myself :)

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.
Download our XForms processor
from http://www.formsPlayer.com/

Why dont you make an easy thing to develop. to make our nightmare less than it.

Because 'simplicity is hard'! See e.g. Berners-Lee's 'Principles of Design': http://www.w3.org/DesignIssues/Principles.html

Thanks for posting this. I've been wondering about XForms for a while.

I've heard of XForms and I get the basic concepts. But, I still have many questions.

It seems to have Mozilla or IE render the form based on XForm XML, you need a plugin of some sort. Is this viable for most web application (public facing web applications)?

As a developer, what would XForms give me that I can not do without it. Different rendering? (Rich vs. webapp)

Each webframework (Struts, WebWork, JSF, Tapestry) has its way of doing field validation, why would I use XForm with these or instead of these?


How does it compare with XUL and the Microsoft version of XUL (whatever that is called)?

There are two articles I found that talk about using XForms with JSF....

http://www-128.ibm.com/developerworks/edu/j-dw-java-jsfx-i.html

http://weblogs.java.net/blog/johnreynolds/archive/2004/07/improve_jsf_by.html

Maybe if I get some time, I will read the above two articles and come up with some better questions.


RE: Humble Editor?

Who? Joe? :o)

Rick Hightower (linked in),blog
JSF, Spring, and Hibernate training and consulting

I've heard of XForms and I get the basic concepts. But, I still have many questions.It seems to have Mozilla or IE render the form based on XForm XML, you need a plugin of some sort. Is this viable for most web application (public facing web applications)?

This is not correct, so I will repeat it: there are now Ajax-based XForms implementations, which *do not* require plugins of any sort. One example of such an implementation is Orbeon PresentationServer (OPS), and it is open source:

http://www.orbeon.com/software/get-excited

As a developer, what would XForms give me that I can not do without it.

This is a little like asking what you can do in Java that you cannot do with assembly language: the answer, of course, is nothing! Yet people tend to use more Java than assembly for building web apps!

The power of XForms resides elsewhere. It frees you from writing Javascript code, using instead declarative markup. The benefits are that maintainability is greatly enahanced, especially today when Ajax libraries out there are one cent a dozen (in other words, they have not consolidated yet). By using XForms, at least you are basing your application on an established standard. As an illustration of what you can do, for example, with *no* user-written Javascript code at all, you can implement all the examples available on this page:

http://www.orbeon.com/software/get-excited

There are of course many more examples available out there, such as the ones provided by Mark Birbeck.

XForms also frees you up from many deployment hurdles associated with server-side frameworks such as JSF. Like good old HTML, you can produce XForms+XHTML pages from Java, PHP, ASP, you name it.

Finally, and this is a very important realization, XForms can be seen as a declarative Ajax library, which allows you to implement many use cases that you would implement instead with bare-metal Ajax.

I have used XForms recently for a large project in government. It was touted as something that would make life much simpler, easier to add new forms etc.

Regardless of its 'benefits', what it did was require that everyone who developed on the project know xforms. Now, everyone who was on the project new standard jsp technologies such as struts, jsf etc. We had complex form structures that didnt work particularly well in XForms, they would have been complicated in struts/jsf as well, but the difference was, everyone already knew those technologies. Everyone who started on the project needed intensive training in xforms.

So the requirement that everyone who worked on the project (and everyone who was going to maintain it forever) know xforms in my opinion is far too large for the limited benefit. This criticism is not limited to XForms, but a myriad of other java technologies.

We need to write applications for the people who are going to maintain them.

To recommend XForms, it would have to do something amazingly special, and, it is just a method for getting form data into xml structures. Above that, it does very little that cant be done easily in JSF/Struts. And imagine the response if I placed a job ad that said "Struts/Java skills required" compared to "XForms/Java skills required".

XForms is a technology in my opinion, does not have a place in commercial software development. Too hard, not enough people know it, and it doesnt solve any problem that cant already be solved using existing, well understood, technologies.

Regards
Dr. Greg Day

I have used XForms recently for a large project in government. It was touted as something that would make life much simpler, easier to add new forms etc.Regardless of its 'benefits', what it did was require that everyone who developed on the project know xforms. Now, everyone who was on the project new standard jsp technologies such as struts, jsf etc. We had complex form structures that didnt work particularly well in XForms, they would have been complicated in struts/jsf as well, but the difference was, everyone already knew those technologies. Everyone who started on the project needed intensive training in xforms.So the requirement that everyone who worked on the project (and everyone who was going to maintain it forever) know xforms in my opinion is far too large for the limited benefit. This criticism is not limited to XForms, but a myriad of other java technologies. We need to write applications for the people who are going to maintain them.To recommend XForms, it would have to do something amazingly special, and, it is just a method for getting form data into xml structures. Above that, it does very little that cant be done easily in JSF/Struts. And imagine the response if I placed a job ad that said "Struts/Java skills required" compared to "XForms/Java skills required". XForms is a technology in my opinion, does not have a place in commercial software development. Too hard, not enough people know it, and it doesnt solve any problem that cant already be solved using existing, well understood, technologies.RegardsDr. Greg Day

Greg, your experience of course cannot be discarded. It is easy to believe that if you take a "Java shop", i.e. a development team that has been doing Java development for a very long time and masters all the intricacies of Java and a particular Java user interface framework such as JSP or JSF, then XForms will be a hard sell and developers may not be more productive with XForms at first. However, I think that learning XForms for a seasoned JSF developer should be a reasonably easy task, and developers should be able to get up to speed really fast.

Also, one thing to realize is that nowadays a significant part of the web application world does not use Java at all. In fact, many developers who do use Java are fed up with the complexity of Java in general. An indication of this is the astounding success of Ruby on Rails, and scripting languages like PHP (without even talking about ASP). For many applications, requiring developers who not only know all the intricacies of an object-oriented language, but also a huge set of APIs, and a very particular UI framwork, and all the compilation and deployment nightmares associated with it, well, all this is simply often quite overkill.

I for one strongly believe that you can be much more productive with XForms than with any other technology I know when it comes to designing complex web forms. But one thing to realize is that even though XForms as seen its first incarnation in 2003 (with a second edition of XForms 1.0 just finalized in March of this year), is after all just in its infancy, and it just takes time for the development community to understand what XForms is and what it does, what implementations work, what your deployment options are, how XForms integrates with your backend logic, etc.

 But the working group is very active, implementations are maturing and coming along quite nicely, more and more resources around XForms are available, and I believe that the day will come where XForms will be mainstream :-)

The problem with xforms, if I try and state it sucinctly, is that it is not mainstream.

I believe this is simply because everything you can do with xforms can be done with JSF/JSP, ruby on rails, asp etc.

XForms may or may not be more productive, but I believe that question is not particularly relevant. It would have to be orders of magnitude more productive before making inroads into mainstream.

if you perform simple cost/benefit analysis, the benefits are kinda cloudy (maybe improved productivity, how much?). The costs are increased learning curve for everyone, from developers to support staff, for the lifetime of your application.

This criticism is not limited to xforms, but to many 'framework' products in general. I have seen in numerous examples when the latest cool framework from (insert random framework provider here) caused massive issues simply because it meant upskilling the entire development team AND the support team AND anyone who ever worked on the application in the future.

Frameworks should be approached VERY carefully IMHO. You need to understand that you are signing up to upskilling your entire development/support team for the lifetime of your app, which in most cases far outweighs any 'productivity gains'.

Cheers
Greg

Well, the thing about XForms that sets it apart from the general Java frameworks you mention, is that they were written with client interpretation in mind. In that sense XForm's aim is much broader than 'just' supporting developing webapps. If browsers would uniformily support XForms - and backport that support too - it would make a good candidate for making the web a lot more usuable (form a 'usability' point of view) than it is today with every designer inventing how a user interface should work him/herself.

just quickly looking at your message while I am meant to be working...
:-)

1. "If browsers would..." Why would they? When will they? What if they don't?
2. Usability is a very difficult concept to pin down. I just don't see people giving up flexibility in order to conform.

Xforms seems to be a solution to a problem that is not very well formed. What is it meant to do?
1. Get html form data into xml documents.

This is not a difficult problem.

It may make a good candidate, but the corollary of that statement is that now it doesnt. So why learn it? Why use it?

It really does seem to be a technology waiting for a problem to turn up, or waiting for external things (browser support) to make it worthwhile.

cheers
Greg

Regarding the double submit problem that Michael mentioned, it should be noted that just because a particular deployment has the problem doesn't mean that XForms has the problem.

XForms is a platform for building applications. It is possible to let some flaws throught the door in any such platform. But that does not mean the platform is flawed, it means the application has a bug.

It would be easy to write an XForm for the ATM example you mentioned so that it does not have the problem.

The original author of "XForms is too complex" is reading the XForms recommendation and having the exact same problem that everyone had years ago when they tried to read the XML recommendation itself.

The XForms recommendation is *not* meant for you to learn how to write XForms. There are numerous books, tutorials and other resources available for free that actually can help you with this. Though many resources exist, here is a shameless plug for my own paper at XML 2005: Please read at least section 2 of the paper at http://www.idealliance.org/proceedings/xml05/abstracts/paper74.HTML

The intended audience of all W3C recommendations, including XForms and XML, is the processor implementer. No spec is perfect, of course, but if you're only trying to learn to write XForms, you probably should not ever read the XForms recommendation. You'll find it a fair bit more useful if you're going to write an XForms processor. Just like the XML recommendation!