The Future of XForms

By Philip Fennell
October 2, 2008 | Comments: 10

Some of the recent talk on the Mozilla XForms Project's mailing list (dev-tech-xforms) has been about the winding-down in effort on the Mozilla XForms plug-in. There has been praise for the efforts of those developers involved in the project, and quite rightly so. However, some people may be seeing this as a bad sign for XForms in general. Well, not so I say and the reasons for this are three-fold.

Firstly, as an open source project there is plenty of opportunity for other developers to step-up to the plate and carry on the good work. The old development team have stated that they are willing and able to mentor new-comers to the project.

Secondly, one browser's plug-in does not make (or break) a technology. There are other implementations out there, both client and server-side. The demise of the Adobe SVG View (ASV) plug-in hasn't stopped the progress of the embedded implementations in Safari/Chrome/Webkit, Firefox and Opera.

Gathering and Managing XML Information

XFormsXForms Essentials — You'll learn how to integrate XForms with both HTML and XML vocabularies, and how XForms can simplify the connection between client-based user input and server-based processing. If you work with forms, HTML, or XML information, XForms Essentials will provide you with a much simpler route to more sophisticated interactions with users.



Thirdly, and most importantly, is that the effort to bring XForms to the wider web appears to be going into ubiquity-xforms. As a pure client-side, cross-platform/cross-browser implementation this, in my opinion, is where the effort should be going for now. It obviously lowers the barrier to adoption because there is no requirement for plug-ins, although it does require JavaScript to be enabled in your browser; but that is a much smaller hurdle for most people.

Ultimately XForms needs to go the way of SVG and become embedded into browsers. The ASV plug-in was a flagship for SVG which provided a reference for other implementations; it showed that SVG was worth having and must have undoubtedly driven the desire to embedded this functionality in all but one of the modern browsers. The Mozilla XForms plug-in, and for that matter FormsPlayer too, has been at the vanguard of XForms development, performing the same role as the ASV plug-in of getting a technology out there for people to play with.

Although, at the time of writing, the Mozilla plug-in is not a 100% complete implementation of the XForms 1.1, recommendation it is as good a reference as there is, due to its excellent integration with the host page and browser.

I believe we're entering a transition phase where XForms plug-ins give way to other, more universal, implementations and in the fullness of time the functionality becomes embedded. This change of emphasis is good for the future of XForms and good for the future of the web too.


You might also be interested in:

10 Comments

I agree with you that ubiquity-xforms is very promising. The fact is that it seems to be a complex project. The initial roadmap is behind and I'm afraid only a subset of the XForms recommendation could be implemented with a Javascript only solution...

Even if so, a Javascript solution is perfect for most browsers, Internet Explorer being the main target. People are always reluctant to plug-in installations and there are too many versions of browsers and compatibility problems would occur.

For me, it is also time to integrate the XForms Mozilla add-in to regular FireFox versions because this add-in is today good enough. Of course, it would also be nice not to have to wait for the next FF release to get the very last Xforms add-in version. A mix of integration and add-in would be perfect.

All,

I think the rationale is very sound and simple: if you focus on the Firefox extension, you deploy to 20% of the market at best. If you focus on a JavaScript implementation, you get close to 100%!

Also, JavaScript support in modern browsers is currently improving in great strides due to fierce competition between Mozilla (Firefox), Apple (Safari), Google (Chrome), and maybe even Microsoft (IE 8) (although MS is lagging at the moment).

The time where everything had to be implemented natively in browsers has gone, witness the extreme success of libraries such as YUI, Dojo, GWT, and dozens more.

In short the shift from Firefox to Ubiquity XForms makes perfect sense.

And don't forget XForms implementations that use JavaScript and Ajax and also have a server-side component, like Orbeon Forms (of which I am a developer), which provide some benefits over pure client-side implementations (including enhanced data security).

-Erik

All,

I think the rationale is very sound and simple: if you focus on the Firefox extension, you deploy to 20% of the market at best. If you focus on a JavaScript implementation, you get close to 100%!

Also, JavaScript support in modern browsers is currently improving in great strides due to fierce competition between Mozilla (Firefox), Apple (Safari), Google (Chrome), and maybe even Microsoft (IE 8) (although MS is lagging at the moment).

The time where everything had to be implemented natively in browsers has gone, witness the extreme success of libraries such as YUI, Dojo, GWT, and dozens more.

In short the shift from Firefox to Ubiquity XForms makes perfect sense.

And don't forget XForms implementations that use JavaScript and Ajax and also have a server-side component, like Orbeon Forms (of which I am a developer), which provide some benefits over pure client-side implementations (including enhanced data security).

-Erik

Good points.

We have been developing XForms-based applications for the MN Department of Revenue/ Property Tax Department for about 1.5 years now. Initially we used the Mozilla plugin...but eventually we moved over to Orbeon (excellent implementation).

We are very happy with the move to Orbeon. Our development and deployment cycles are more stable, shorter and do not have to worry about browser limitations. Computing load is primarily on the server - that we can control. We use Orbeon primarily as a "presentation server" - we do not use its pipeline architecture since we already have a ReSTful pipeline architecture. Our forms (complex) are mere consumers for our ReSTful services.

XForms 1.1 is a great, complete markup model for developing business applications. Where the forms actually get processed - in the client or server will keep changing upon circumstances like history has shown us. For now, server-side implementations of XForms like Orbeon and IBM's e-forms (Lotus forms) seems to be working very well.

After studying AJAXForms, I have been able to integrate its main Java parts inside a unique XSLT 1.0 stylesheet. I have already tested it successfully, on client-side transformation, with Internet Explorer, FireFox and Safari (there is some nasty bug in Opera XSLT engine about embedded apply-template with select attribute within call-template...) and loading time is good !

AJAXForms performs a conversion of every XPath expression to Javascript objects using Jaxen capabilities so I had to analyze XPath expressions with XSLT 1.0 only (some named templates with a stack mecanism based on strings manipulations...).

It is now an only pre-alpha version at http://sourceforge.net/projects/xsltforms/ (axis not yet supported,- unary operator not well supported, ..., different bugs in Javascript parts,...).

Once quick thing on the topic itself; if anyone is interested in the some of the ideas that led to my work on Ubiquity XForms you might be interested in Ajax and progressive browser enhancement, Ajax makes browser choice irrelevant...but we still need standards, and A Standards-based Virtual Machine.

But the main reason for my comment is that despite formsPlayer being mentioned in the article, there is no link to its website.

It's a bit of an omission, given that the people who devised the whole approach that lies behind Ubiquity XForms also devised formsPlayer, and the experience of working on the one definitely led to the other.

Anyway, formsPlayer is now also part of the Ubiquity family at Ubiquity formsPlayer.

Regards,

Mark

Mark Birbeck
http://webBackplane.com/mark-birbeck

@ Mark,

Sorry and yes you are quite right, I should have put the link in there, and I have more shame for not correcting that since our previous discussion on the subject.

Regards,

Philip Fennell

I just don't get what the benefit is (of Xforms) over HTML Forms ((X)HTML + CSS + Javascript)?

Now moving forward, if I want to use XForms I use ubiquity-xforms which is bascially a *hack* to get the HTML to behave as if it was an XForm...?

Why not just create HTML?

If it's (percieved as) useful technology, people will want it (the plug-in I mean)... For example: Flash Player anyone?

IMHO comparing SVG (adoption) to XForms is wrong. Organisations like Mozilla, Apple, Opera, Google want the open web to succeed, Microsoft wants a competing technology - a technology that can do 90% of what the (proprietry) Flash Player can do is (very) appealing.

@ What do I know

I just don't get what the benefit is (of Xforms) over HTML Forms ((X)HTML + CSS + Javascript)?

It depends upon what you're doing. For me, if I'm interacting with XML data and/or wish to benefit from the XML tool-chain server-side then XForms is a natural choice for building client-side webapps as you are interacting with the data on the same level and they can be built very quickly

if I want to use XForms I use ubiquity-xforms which is bascially a *hack* to get the HTML to behave as if it was an XForm...?

I think that getting the XForms functionality to the browser without using plug-ins is a good stop-gap until more native/plug-in support is available. Let us not forget the purpose of JavaScript, it is there to extend the functionality of the web browser as required. In the case of Ubiquity-XForms, JavaScript is doing it with respect to a published recommendation from the W3C that is well thought-out and well documented. In my opinion, anything that uses JavaScript, without reference to a standard, is a *hack* to the web, and that includes 'HTML Forms ((X)HTML + CSS + Javascript)'.

If it's (percieved as) useful technology, people will want it (the plug-in I mean)... For example: Flash Player anyone?

Yes, you're right, and in the case of Flash, the plug-in was able to work across multiple browsers because it didn't have to interact with the content of the host page in the same way that XForms does. This means different browsers require different plug-ins and the plug-in's ability to interact with the host page is very much governed by the browser. Mozilla Firefox is a model example of how a browser should be built for an inclusive web.

IMHO comparing SVG (adoption) to XForms is wrong. Organisations like Mozilla, Apple, Opera, Google want the open web to succeed, Microsoft wants a competing technology - a technology that can do 90% of what the (proprietry) Flash Player can do is (very) appealing.

My point about the comparison between SVG and XForms adoption was that the plug-ins pave the way for native implementations. ASV unquestionably did this for SVG and FormsPlayer/Mozilla XForms have started the process for XForms. However, due to the problems with interaction between the form and the host page, plug-ins are not the answer for some browsers (IE) and that is why, hopefully, the JavaScript implementations will bridge that gap in the short term and help drive-up adoption.

I'm not sure what the oblique reference to Silverlight has to do with this. Are you implying that Silverlight is non-proprietary? I'm sure you're not, but Flash/Flex is very *hacky* in comparison to XForms and I can't fully vouch for Silverlight, but from what I have seen it is a classic Microsoft attempt to drag people into the ugly world of vendor look-in rather than extending the openness of the web.

I hope that you will not be averse to XForms as such but that you haven't had the need to interact with XML in a way that would enable you try XForms and see its many subtleties and excellent features.

I think that the struggle is over.
Applications with simple and effective means to allow everyone access to information they need whether for travel, learning, asking for help in choosing a product, talk to others, share knowledge , ask different questions, and many other things have been fixed long ago SmallTalk.
The hierarchy of database died suddenly in the 1980s, relational databases have replaced. For the purposes of charity to one of the richest men on this planet, I will not say who said that the relational data architecture would last a thousand years.
The dispute about the different ways to specify how to make drawings in color on a painting is nothing more elegant and artistic. Some ways to do this are not very clean, they are made using inserts that can invite the Trojans. Other ways are free and limited or suspected, but stylish enough to be able to imprison the client
It turns out that effectively manipulate what we need every day if you are a student or an industry leader or provider of health care (just a few samples), it is necessary that our data is stored in a flexible format.
This format is simple, very flexible, agile, and is available as needed, without limitation enrichment.
This format was called XML. A good way to store data in a warehouse and not to distort them is to save them in their native form. This good practice has been appointed NXD.
It remains to articulate all this efficiently with maximum comfort and total safety of Accessibility for the user who is not necessarily a scholar, because the user may be a sick child or a deaf old man who seeks a Paper or a tourist looking for a museum. A good method was proposed, it is called Rest. From this set of virtual brick was invented a style archirectural: XRX / NXD. As a matter of fact and as far as I know XSLTForms is the best choice for the leftmost letter.
I never encountered Alain Couthures, I discovered its work in 2009 March, we have exchanged a lot of mails and messages, we have only one phone call. I have tried and test the product and made non trivial samples.
I have also searched, analysed, made scaffolding about storage. My choice is NXD, especially Mark Logic. Anybody can prefer other data management provider but a NXD one is required.

News Topics

Recommended for You

Got a Question?