XForms - Who Needs Killer Apps?

by Kurt Cagle

The XML 2007 Conference has come and gone, with as usual a number of thought provoking talks and controversies. During the evening of the first day, there was a special XForms Evening, with a number of the industry gurus in that space providing very good examples of why XForms is a compelling technology and here to stay.

In the final keynote session, though, Elliott Rusty Harold sounded a somewhat more alarming note, indicating that while XForms does have a huge potential, there are no killer apps out there for it, and without significant support from the various players in this space it will be dead within the year.


7 Comments

Rajesh G Manwani
2007-12-16 21:24:25
Hi,


I am not Xml Developer but is interested in making use of it considering its huge recognition base. But I do have one doubt
if in type of application I am working on, Is Xml a suitable choice, from performance point of view.


I am developing a client-server application. I have thought of an architecture where client generates the request and keepts in Xml format somewhere in the network and intimates server to read the request. While I have tested the application, I am wondering if would have used network -sockets to pass the complete request details to server, would the appliction had performed better? Can someone guide me on this.

Andreas
2007-12-17 02:08:29
A killer app can give a push and you just need a topic with great concern. Such a topic can be genealogy and XForms can be a great tool to handle this since XSLT is able to work on text files. Most people still use the old gedcom text files although the latest gedcom version was one of the first standards using xml. The group of gedcom users is huge enough to contain people that learn XForms and spread it. The most will simply ask for things like Prism or Sidewinder, if they support XForms and XSLT 2.0 and IE doesn't. This is just an idea, but I'm not a developer.
Dustin Whitney
2007-12-18 09:43:02
I don't know if I agree with Kurt. To me, you'd only use XForms if the data structures that composed your data model were built in XML. I think the largest benefit of using XForms is that you can modify your data model directly, instead of having to compose it from the parameters of a form post. In fact, if my data model weren't composed in XML, I'd find using XForms more of a hassle, because transforming an XML document into classes (supposing I'm using Java) would be WAY more of a pain than using a standard form post.


I agree with Elliott. I think if XForms is to survive some killer app needs to be developed. XForms makes editing XML documents easier, so IMHO it's XML that needs the killer app. Usage of XML needs to skyrocket, then XForms will do just fine.


One idea I had recently was along the lines of Amazon's SimpleDB. I can only think of a few really good uses for SimpleDB. However if SimpleDB allowed me to create collections, dump XML documents in them, and query them with XQuery, I think we'd see the usage of XML skyrocket. There would be semantic web projects popping up all over the place -- all that used XForms to edit content. I don't know if building that kind of app would scale in the way that I'm sure SimpleDB does, but it would be interesting to see.

Kurt Cagle
2007-12-18 10:34:19
One of the things I've been watching for some time is the dichotomization between the popular and enterprise spaces in terms of XML technology adoption. XML has become very pervasive in most enterprise applications, to the extent that it has begun shifting the balance in terms of how both data and documents are stored in that space - and one of the questions that keeps coming back to me is one of how to get that XML into the web portals and communicating with web clients.


A significant portion of the "popular" space, on the other hand, has been built on mySQL/PHP, and PHP in particular has only just recently reached a point where they had a decent XML parser to speaker (based on libXML), so as a consequence, XML plays a considerably smaller role there.


My expectation is that over time, pressure is going to build in the system to "pipeline" data content (I'll address this in a post here shortly). SQL has no clear syndication strategy - records are returned as text which has to be parsed according to sized fields and then output into the object du jour, which in general is neither standard nor readily persistable across the wires.


I can really see only two formats that might even come close to such a messaging format - XML and JSON. JSON's popular among Javascript programmers because its the "native" format - there's relatively little cost incurred to parse or serialize it, but JSON lacks both XML's flexibility (it's a poor document format, for a number of reasons) and it also incurs a larger overhead with other systems, especially those that have poor reflection stories.


Expect to see more of XML making its way to the client, and keep your eyes peeled beyond just the browser in that regard. In the mobile space, XML is already the standard protocol of choice, and for an increasing number of browser-lite apps - web enabled clients that are not necessarily themselves browsers or based upon browsers, this holds true as well.


Joel Amoussou
2007-12-18 11:51:00
Kurt,


Thanks for another great article on XForms. I agree with your point of view. XForms has a bright future. In our consulting practice in different companies, we see a lot of very painful problems that XForms can fix easily. What it takes is developers and architects who can step out of their comfort zone and experiment with new ideas. Most importantly, it takes technical leadership that encourages and rewards that attitude.


Joel Amoussou
Efasoft

Adrian
2007-12-19 11:56:20
>In fact, if my data model weren't composed in XML, I'd find using XForms more of a hassle, because transforming an XML document into classes (supposing I'm using Java) would be WAY more of a pain than using a standard form post.


Two points...


1. Using a standard form post (HTML 4 Forms) means your model (Java class) isn't available in your form. So you can't write any dynamic behavior using model-based programming, unless you refresh the entire page on each interaction (not totally ridiculous, but a bit old fashioned).


2. Java classes <-> XML is very easy using JAXB & annotations.

Philip Fennell
2008-01-08 04:05:20
I don't believe that a 'killer app' is the issue regarding the life expectancy of XForms. It is the realisation that declarative programming is the 'killer app' for the web. When people wake-up to what can be achieved using XForms' bindings, model item properties and XPath; whole swathes of client-side scripts will be swept away. In addition, once you have captured the logic within your XForms enable web application the principles are immediately re-usable in other projects without having to right a whole new set of code to support the same types of rules.


The same applies to presentation of content and user-interaction. The depressing lack of interest in the SMIL Animation module is another example of how declarative programming has been under-valued. Most people will have only encountered it through SVG but it is a standalone module in it's own right, and as such could be used in XHTML. My experiences with SVG, Mutation Events and SMIL Animation suggest, like with XForms, that you can say goodbye to piles of tedious client-side scripts, the endless reinvention of JavaScript libraries that all do the same thing anyway and look forward to a future where you declare what you want to happen and the client does it for you.


This is not to say that JavaScript is history, not by a long chalk, but declarative programming is much better at doing the everyday stuff like sticking in a constraint here, defining what part of the content should appear when I click there; and when XML Events 2 steps into the picture the more specialised behaviours that require scripting can be hooked into the events mechanism in a declarative way too.


Don't think about any one technology and then look around for an application to build instances of it. Is there a JavaScript 'killer app'? No, I don't so. There are editors with useful code features that people use to make JavaScript work for them. You can edit XForms in an editor and editors may have useful XML editing features. What people must do is look at what it means to use a technology and how it can change their way of thinking and working. That way, the technologies have the potential to sell themselves by example.


So, bring on the implementations of SMIL Animation, XML Events, DIAL and XForms and lets free ourselves from the shackles of client-side scripting and cross-browser support.