XForms Becomes Proposed Recommendation

leighklotz writes "The W3C has announced that XForms is now a Proposed Recommendation, after certification of one full implementation (open source Java XSmiles from Finland) and two more implementations of each feature (the Internet Explorer plug-in FormsPlayer and the Java standalone Novell xPlorer). XForms is the next generation of forms for the Web, and uses an XML-based three-layer model: data model, data, and user interface. XForms uses CSS for device independencence and is designed for integration into XHTML 2, SVG, and other XML-based markup languages. A host of other implementations are available or in progress, but my pick for most interesting is DENG, which is an XForms to Flash compiler written in Flash. DENG supports XForms, SVG, RSS, XHTML, and CSS. XForms is in consideration for other standards as diverse as Universal Remote Controls and the UK Government Interoperability Framework, and was developed with the participation of IBM, Oracle, Xerox, Adobe, Novell, SAP, Cardiff, PureEdge, and a host of other companies, universities, and invididuals."

WTF? That name is already taken, try again.

[Dr. Zowie]

Jesus Christ, doesn't anyone look out for name collisions anymore? XForms is a GUI toolkit for X. [std.com], in (slow) development since 1995 and still used in many useful apps like GeomView [geomview.org] and Lyx [lyx.org].

Now it's also "the next generation of web forms" [w3.org]. Gag me with a buzzword.

It's not as if the original XForms were unknown, either -- it comes up second in a Google search [google.com] for "Xforms". These jokers should have known better.

Feh.

Minor correction

[Anonymous Coward]

Two implementations, not one, passed the test suite for XForms: X-Smiles [xsmiles.org], and FormsPlayer [formsplayer.com]

HTML, Tables, and CGI

[Anonymous Coward]

All this happy horseshit is interesting and exciting to work with and is a welcome relief from the boring world of straight HTML and a few tables, but sites that stick with the basics can still look great, be fast, be much less expensive to implement, and work with far more browsers than those that wander off into the realm of whiz-bang.

Re:Just one simple question:

[Anonymous Coward]

Yes, XForms supports combo-boxes

This is big.

[CYwo1f]

I, personally, can't wait until XForms is supported by all the major browsers. I've been planning for it in my web development framework for a few reasons. The benefits of having the browser construct an XML document and submit it back the server are tremendous:

• You get hierarchical data, as opposed to the flat list of query parameters you have today. This makes a huge difference in the expressibility of a form. In fact, the XForms spec outlines some support for, for instance, dynamically adding controls to a form. No more re-submitting because those 3 file upload controls weren't enough for you, extend the form offline via javascript!
• You get to reuse your form handling code to service SOAP requests, too. Instantly.
• Form data can be serialized by the browser or by a more specialized client, and submitted later on (this is the Suspend and Resume another poster mentioned). How about being able to disconnect from the internet, copy that article submission form to your laptop, and fixing all those typos while you wait for that call from your editor? Or even submitting the form via an alternate method, SOAP or even email if your server supports it.
• Accessibility. This isn't something I worry about on a daily basis, but there are many people who do. XForms controls are fairly platform-agnostic, and cater better to those with visual or other disabilities. Plus they're more easily adapted to novel input devices, like a cellphone.

If you're a frustrated web developer itching for a simpler way of living, this may be your ticket. Even today, you should consider supporting XForms on your back end, while translating to the simpler HTML forms for today's web clients. I am.

Re:Not again...

[porter235]

Man... RTFM... this isn't to replace perl. It's to make development of web apps in languages like perl EASIER.

And as for w3c "standards" these are not plug-ins and are not called standards because they are supported by everything.. hell, they don't even call 'em standards, they call them recomendations.

These are layed out so that people creating the browsers of tomorrow can work together to prevent any more messed-up-browser-detection-required-scripting-shi t that happend during the browser wars and is a fact of life still today for most web developers.

Don't worry, now that it is a W3C Proposed Recommendation, browsers like mozilla will start to work towards it, and then someone talented will write a perl module so that you too can start using Xforms with even more ease of use in your favourite language, than you currently have using plain old s!

This is really a good thing

[duncanFrance]

I'm surprised at the number of negative posts I've seen already.

This is actually a good thing. HTML forms are badly broken at every level, as anyone who has actually tried to build a decent UI with them will know.

I have been using the draft specification for a while to produce forms in my software and it is useful because it lets me write code (PHP) which produces XFORMS XML, without worrying about how it will look. I then pass the XML through a transform and end up with good old html. Because the actual layout is produced by a transform, I can let my designers choose which transform they want to use to get the kind of prettiness they like. I can get complex layout, with sexy results, without having to write hideous html or wrangle with the cruft that is CSS each time.

That's just the layout side of things. The three-level model give me much more control over adding scripting behaviours (Javascript), abstracting the form control out into PHP classes etc. etc.

If you don't understand why html forms are broken, I suggest you start playing with Xforms. Once you grok it you won't look back. When I first came across Xforms, I thought "great, loads of complexity for no good reason" too.

Re:DOA

[Zaiff Urgulbunger]

Been there, done that, produced the inferior proprietary clone!

See Info Path [microsoft.com].

NB: It might not be inferior. I just said that 'cos this is /. !

Re:This yanks the rug out from under Office 2003!

[molarmass192]

Sure thing, take a look right here [simonstl.com]. Take special note of the 8 XML namespaces in the parent tag. Now go take a look at those individual namespaces and you'll see what he means. Just so you know, you can't because they're only available in the Word Content Developer's kit [microsoft.com]. No problem, download the kit get the XSD's and you're done right? Wrong, MS explicit forbids ANY redistribution of the XSDs. So, in effect, you wind up with an XML that can ONLY be read in Word. Useful ain't it?

Re:Thank god.

[sketerpot]

The thing about xforms is that I see, lurking underneath the buzzwords and nasty looking XML namespaces (ugh. UGH!), that there is some good technology here. The old HTML forms are okay, but you get the feeling that they are a bit too lightweight. They have no support for input validation, so you either have to do that with server scripting (which is typically a lot of work, and ugly at that), or stick in a bunch of nasty javascript. Xforms looks like a way to give the browser more knowledge about what is supposed to go into the fields, and let it figure out how to get it---what validation to do, and even how to display the forms, which should be very useful on, say, handheld computers. Not all the world uses MSIE 800x600 24 bit monitors, and not all the world can display normal forms that way they're intended to be displayed.

For some good information on how to actually use xforms [w3schools.com], go to W3Schools, which also has lots of other stuff. But knock off the buzzwords, people!

Re:How will this change things?

[bwt]

Some of the key advantages will be:
1) decouple data, logic, and presentation
2) allow client side rules-based validation
3) spits back an XML record, maybe w/ schema validation
4) replaces a lot of javascript with markup
5) highly device independent (eg render an XForm via telephone, web browser, handheld)

Re:Thank god.

[whereiswaldo]

Some people need to re-read my post. I would _never_ suggest omitting the server-side checks. I'm suggesting that bad data can be flagged to the user by javascript rather than more complex code on the server side which repopulates form elements, etc.. and presents the data the user has entered plus any error messages. That part is tedious. The data is still validated on the server side but handler code can be as simple as "you entered an invalid address". Period.

As one poster replied, Struts can do more complex repopulation work for you, if using Struts is an option to your project.