Slashdot Mirror
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."
xforms is fully buzzword compliant and serves as an excellent tool for dumb managers to wank with.
When will I end this grieving ? When will my future begin ?
Now it's also "the next generation of web forms". Gag me with a buzzword.
It's not as if the original XForms were unknown, either -- it comes up second in a Google search for "Xforms". These jokers should have known better.
Feh.
After all that, I think Bender summed it up best:
"Interesting! No, wait, the other thing. Tedious."
I was having a ton of trouble teaching people how to use and . It's good to see that they went and solved the complexity problem.
Maybe they think if they make forms complex enough, and break enough browsers, the cheap labor in India won't take their jobs?
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
Suspend and Resume. Oh, that'll be usefull for last minute regret when making large online purchaces.
Click here to submit form to purchase $2000 computer... Wait! I changed my mind. Suspend. Suspend. Hmmm... I can always use another computer, Resume!
Jebus. Every time you look around, they're introducing some new technology designed to help us. (And half the time, it's based around XML.) Am I really the only one left on this planet that believes that assembly language, C, BASIC, Cobol, Fortran, Forth, Pascal, HTML, and Perl are "good enough" for anything, and there's no need for another billion languages, "standards", plug-ins, etc.?
I can make "plain old CGIs written in Perl" jump up and do tricks without any fancy new whizbang technology telling me it's time to re-evaluate the whole way I make Web forms. Not to mention the fact that this is going to be a nightmare to integrate into all of the browsers.
When people started talking about Flash as if it were some sort of an IEEE-blessed, completely open standard, and as if it were available in all browsers, (I'm sorry, but "the most common browsers on the most common operating systems" doesn't count), I knew the Web was going downhill fast. Now we're mired in our own complexity, we have a billion plug-ins (Flash, Shockwave, Quicktime, Windows Media Player, etc. etc. etc.)... and now they're telling us that plain old <FORM> isn't good enough. Dammit, I want back to 1995 and Slackware 3.0...
Honey, I shrunk the Cygwin
dear world wide web consortium,
thank you for your recommendation of yet another over-complicated standard for the world wide web. while we do appreciate the time and effort it takes to keep coming up with esoteric standards that involve the letter 'x', we currently are not searching to implement any additional layers of abstraction into our website viewing experience. we currently have xml backends that are interpreted by xslt's to generate style sheets that are controlled by dhtml, and feel that adding another abstraction layer to what was originally a simple way to serve a formatted text page would take us into the realm of meta-meta-meta-meta-programming, and that's probably two meta's too many for us. we have decided that we would rather spend our time creating interesting content, than debugging at what level our standards-based fancy pants websites are breaking on each browser.
so, while you guys are doing good job there in lotus-eating land, we on the real web will be passing on this standard.
thanks,
the world wide web
Two implementations, not one, passed the test suite for XForms: X-Smiles, and FormsPlayer
See the following bugzilla item for XForms support in Mozilla: http://bugzilla.mozilla.org/show_bug.cgi?id=97806. There are also plugins available for some present browsers. See the implementations section of http://www.w3.org/MarkUp/Forms/ for more info.
Just like Firebird. What really gets me is not the fact that these names have already been taken but that at least two seperate people on earth think these are good names for their projects. Firebird is a bad name and it's only made worse by the Thunderbird project, confusing as hell. One should be called Fire and one Thunder, now that's pretty cool. Except for the fact that Fire is an IM on the Mac.
XForms is a bad name. Sure, it kinda sounds like XHTML. Here's a reality check: XHTML is a bad name. X2 was a bad name for a movie, XP is a bad version number and so is MX. X is a stupid letter. Don't go tacking it onto everything you name just to make it sound cool. A name doesn't make something cool, but it sure can make it sound stupid.
Don't even try to explain that extensible starts with an X instead of an E unless you're speaking in ebonics, and in that case, mad props.
Huh?
As someone who once wrote a cross-device content delivery platform for PDAs, WML/HDML phones, and browsers, I repeat:
Huh?
Craptastic.
Hey, I'm just your average shit and piss factory.
Here at /. we have human editors for spelling independencence... not to mention English grammar transcendencence... or (my favorite) just plain incoherencence...
(Combo boxes are those in which you can both enter a text and choose from a list - for example the "location" bar in most browsers.)
Xcellent post.
You might not appreciate this, but decoupling data, logic and presentation is a good thing for us all. If I can have a form control that pulls the applicable bits out of an OpenOffice (also XML) file and displays it appropriately for the web or the PDA, or sends it to a database that needs is ... I'm one happy dataslinger.
The ability to do this sort of thing is what Microsoft has been touting as the next best thing coming soon to an expensive proprietary desktop near you as soon as they get a handle on that security stuff. But from what I have seen of the Microsoftian version of XML (totally bastardized by the Beast of Redmond), and what little I have done with Java IDEs ... this will be much easier and cleaner to implement.
Way back in 2000 I had a hard look at how you'd deliver an XForms form to a legacy device, and concluded that it was in the general case virtually impossible using standard tools. So I said so. As far as I know, there's still no way, and no one has produced any sensible response to this problem.
I'm old enough to remember when discussions on Slashdot were well informed.
XML is inefficient enough in terms of processing power. Every derivative of XML like XSL, XForms, and any other derived "language" of XML is exponentially more inefficient. I do use XML for some things - the things it does well (config files, multi-lingual sites, etc.). However, I would argue that no matter how many acronyms with an "X" in the name you use, there is more straight forward, more maintainable, and MUCH more efficient code out there.
One of the biggest problems with running Linux for non-geeks is configuration. Every app has its own .appnamerc or appname.conf with its own peculiar syntax and options. Now that we have a standard for filling out forms, we can build the infrastructure for a single front end to them all.
So, for each *rc or *conf file, we need an XForms Model that describes the form and how to validate it, and an X-forms-aware UA like Mozilla (but you can't get there from here!), or perhaps on the server side through Apache and Cocoon's XMLForm to handle the work of getting the input. XForms can become the glue that holds Linux together.When users can right-click on something, select Properties from the menu, and configure it in a consistent interface, one of the biggest impediments to Linux use by non-techies will be removed.
[100% ISO 646 Compliant]
SVM, ERGO MONSTRO.
While Xforms is great and all M$ already (almost) has a production-ready implementation of their own new form standard in InfoPath, which is part of the yet-to-be-released Office 2003.
I got to test InfoPath myself this week, and found it to be a tool which was intuitive, powerful, easy to use, and standards-compliant.
Yes. The M$ product complied to every widely accepted standard possible. It uses XML almost exclusively, seems to have an extensive API, and uses syntactically correct XHTML wherever it can.
Xforms isn't even a standard yet. Don't bash M$ for not complying to it. In fact, it's quite different than Xforms in that it's designed for MUCH MORE than the web (in fact, I find that it's not really geared twoard the web at all)
So, for now, Microsoft seems to have produced a working next-generation form solution before any of the open groups or competitors. (Note: Windows is by no means my primary OS. I use Linux extensively, as well as Mac OS X, and am typing this from my Mac)
-- If you try to fail and succeed, which have you done? - Uli's moose
- 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.I usually only come to /. for the news content, so reading this whole thread has depressed me, seeing as how it purports to come from knowledgeable, savvy technical people.
Having followed the development of XForms for the last couple of years, I have to say I'm pretty impressed. For instance, I've seen a stunning demo of an implementation by Oracle, where the same form has been filled in over a PC screen, a mobile phone screen, a regular phone by speaking and being spoken to, and even over an Instant Messenger buddy. The same form not different forms that do the same thing, or different forms generated from a central hybrid. People, you cannot do that with HTML forms. Until you understand the power of having a live XML instance in your form, you haven't understood the power of XForms.
Go and look at the Google search example on FormsPlayer.com and tell me that's not cool; or the live map search with XSmiles.
I know it's tough, just when you've got your head round HTML, Javascript, the DOM and all that stuff, to be told that there is something new coming that also has to be learnt, but please don't go judging it because of its name, TLA's, the fact that the spec is hard to read, or that it's new until you've actually seen it in action and tried it out.
I've been told that no other W3C spec has had so many implementations before it was even a recommendation. I think that that fact alone means we should take it seriously and try to evaluate it rationally.
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.
Been there, done that, produced the inferior proprietary clone!
/. !
See Info Path.
NB: It might not be inferior. I just said that 'cos this is
Lets say I'm building a web based app. to allow users to create/update/delete records. I create a database table to store these records in. I use SQL to do this. I write documentation detailing the table layout, field types and sizes.
I write some script on the web server to perform the SQL create/update/delete and to squirt suitable (X)HTML at the user. I also have to include data validation here, which involves knowledge of the database layout... no problem, I've got my documentation!
Oh, and I want to include some validation at the client end so the user doesn't have to wait for the round-trip to be told that they've missed some information or something. So thats a little JavaScript, again involving knowledge of the DB layout.
And bingo! Its done.
But then the boss says they want to add some extra fields to the "record", so I've now got to:
- Modify the database schema
- Update my documentaiton
- Modify the web server script to create/update/delete the new field *AND* validate it!
- Modify the HTML to include the new field
- Modify the client JavaScript validation
Its a lot of maintenance work, and a lot of places for things not to work right. Lots of potential for errors/SQL injection vunerabilities.Now just with that lot, you could use XSchema to describe the data record *once* and use that to update the database, update the documentation (okay, generate docs from the XSchema) and build server and client side form validation.
You'd then just be left with updating the HTML to include the extra field.
But beyond that I imagine there should be a way to submit the form directly to the database server maybe? Certainly, the amount of coding required at the web server should at least be negligable - and completely automatable.
Which I'd guess is what MS InfoPath is all about?
A product that allows you to describe data *once* and easily, visually, build forms would make it childs play for an unskilled, non-programmer type to create database applications.
I do hope that Mozilla/OpenOffice/mySQL or someone does some joined up thinking with all this, because otherwise Microsoft *might* be about to roll out a complete end-to-end solution based on their own proprietary crap!
NOTE - This is pure speculation as I don't know much about InfoPath. It *might* be fully open standards based!! However, if it isn't, then it will still be a compelling product, and more worryingly, a product that would very much tie an organisation into MS software.
Before you mock Xforms, keep in mind that it is at least on track to be a W3C open standard. Perhaps you've also heard of something called "WinForms" which is part of the .NET framework currently being pushed by that big evil monopoly that's trying to turn the Web into a closed system. Despite having told everyone in the previous decade what a bad idea it is to embed applets in web pages, they're now pushing exactly that idea -- but now they call it "smart clients."
.NET only? Or XForms, a W3C standard that will eventually get implemented everywhere? I know which ring I'm throwing my hat into.
So, you decide. WinForms, on IE with
Tired of FB/Google censorship? Visit UNCENSORED!
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)
we currently are not searching to implement any additional layers of abstraction into our website viewing experience.
I have to disagree. There is a serious lack of an HTTP-friendly standard for GUI business forms. The current standards are optimized for e-brochures, not business forms. While it can possibly be bent screaming and fighting into an almost-acceptable business form under certain vendor's browsers, one gets charley horses doing such. HTML+JavaScript+DOM is nasty for non-trivial forms.
We need a standard purposely targeted for business forms. (I even proposed one of my own because I fealt something was needed. See my other reply.)
However, this proposal does look a bit overdone.
Table-ized A.I.