Sorry for taking so long to reply, I wanted to be certain to take enough time to read the article. This is in fact the very first use of XForms I have seen. However, the article does mention it’s not a mature technology. Google also tells me XRX is a poor acronym as the results I get are unrelated (except for the article you pointed out). “XRX XForms” does provide more meaningful results.

The technology looks promising, definitely something to consider in the future, but I remain sceptical.

There are a few weak arguments in the article. The comparison with natural translation is very poor. The reason NLP is hard is because machines are currently unable to figure out the underlying meaning, and thus translate it. The problem with “translation” between technologies is mostly change management and human errors.

I also have the feeling that XQuery is in fact an other procedural language, only that it’s tailored to manipulate XML very well, so XRX does not really remove the need for a procedural language, it just use a simpler one.

My other main concern is the ability to integrate with other technologies. Coming from a PHP background, I’m used to querying multiple systems, mashing data and performing all sorts of operation. While XRX is very powerful and simple to use to create new applications using a single data store, I am a little worried on how it behaves with other system. It probably works just fine if those export clean XML than can be manipulated (SOAP?), but what about those with legacy interfaces you have no control over?

Splitting up the standards won’t help. They did that with CSS 3 and none of the modules are past working draft over 5 years later.

For everything that touches the end user/browser, there is no easy solution. Rendering is complicated, the specs have to be huge, compatibility will always be hard. However, for everything that is interoperability related, we have lightweight alternatives, and that was my main point.

I have mixed feelings about this. On one hand, yes, I do think that specs should try to be smaller and dome more incrementally. In fact, the XForms Working Group is working exactly in that direction for XForms 1.2: modularization, and making some of the individual pieces useful independently.

Now saying that this kind of approach is a good idea is different from saying that the opposite approach is the direct cause of such or such technology failing.

For example, one can make a very strong (in my opinion totally convincing) argument that the web has stagnated for about 6 years due to Microsoft’s complete domination of the browser market with a product which was no longer developed (IE 6). Check this chart on wikipedia to get a very clear idea of the horror of the situation:

http://en.wikipedia.org/wiki/Image:Layout_engine_usage_share.svg

It then took Mozilla years to come back with a product able to compete, slowly gain market share, and finally get to a point where things could get in motion again. The growth of Safari on the Mac started helping as well just recently.

These years of stagnation coincided with the years W3C developed XHTML and XForms among other technologies. It is pretty simple: during these years, not a *single* new client-side web technology (as in: implemented in the browser) picked up. That’s because none *could* pick up, because there was no browser onto which to deploy those new technologies. Hence BTW the success of Ajax, which could leverage IE 6.

(As for some other W3C technologies, I for one think that the XPath 2.0 / XSLT 2.0 / XQuery 1.0 are excellent. They are just not mainstream on the web, but they don’t need to. Does that mean they failed? I don’t think so.)

Food for thoughts.

-Erik

Great article Louis-Philippe.