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."

Comments

Not again...

[JessLeah]

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...

Re:Not again...

[ocelotbob]

standard HTML forms may be Good Enough for most uses on a machine with a relatively large display, etc, but it begins to break down when porting XHTML to embedded platforms, mobile platforms, etc. XForms' separation of content and markup means that it'll be easier and more usable to port to new platforms and areas.

To consider your analogy, Perl, C and company are great for scripting and application building, but at the same time, sometimes you need to roll your own language to perform operations that just weren't needed 10 years ago. Progress is good; sometimes it's beneficial to throw everything out, and start from scratch. See what's broken and fix it permanently. At least, until the next new technology comes around ;3. But such is life in the tech world. Get used to it, or you'll be sweeping floors with all the old PL/I and Flowmatic programmers who didn't want to adapt either.

Re:Not again...

[JessLeah]

Oh, come off it. First of all, I would never call anyone a "pussy" or not a "real man", since (among other, more important reasons) I'm a girl. Secondly, it has nothing to do with "niche" versus "non-niche". I'm just freaking sick of people MAKING our field more and more and more and more and more complex, year after wretched year. There is no Law Of Physics which states that computing will get more and more complex, changing year after year. This is something which we as techies have brought upon ourselves.

If, instead of continually reinventing the wheel, we would focus on refining EXISTING technologies, we would be so much further down the road now. Imagine a 4GHz Pentium 4 (or, as I'd prefer, a dual 2GHz Power Macintosh G5) running some beautifully written, hand-optimized C or assembly code, tuned and tweaked and whittled into glistening sleek perfection over the past 20 years. The OS would boot in under 1MB of RAM, including the TCP/IP stack, the Web browsing environment, the sound server, the firewall and the file browser. "System Requirements" sections on software boxes would be a thing of the past, since the software would work on virtually any computer released in the past 15 years. The whole system would include beautifully refined and trimmed APIs, perfected over a decade or more, for all programmers to write to.

But no, at some point along the line, the emphasis in the computing field went from efficiency and quality to "OOH! LOOK! SHINY!". That is where we started to go downhill.

Here is an exercise for you, Mr. New-School Thinker. Go buy a Commodore 64. (or use an emulator...) Install Contiki on it. There you have a complete GUI system that runs in 64 kilobytes of RAM. That's KILOBYTES, not megabytes! The sort of devil-may-care, newer-is-better school of thought you advocate is what has prevented this sort of thing from being a marketable reality. An ounce of restraint on the part of coders would have done so much 10 to 20 years ago, when code bloat started on its eternal downward cycle. I should have seen something bad coming down the pike the instant when I bought Windows 3.0 (this was "back in the day" when it was new) and it brought my '286 to a crawl. Meanwhile, Appleworks, arguably a more complex software system than the entirity of Windows 3.0, ran beautifully on piddly little Apple IIs with 32KB or so of RAM.

And people like you keep advocating newer, bloatier, more "complexified" (to borrow a word from Star Control 3) solutions to fundamentally simple problems.

Some day, I hope to get off my rear end, and prove all of you wrong, by making an OS the right way-- that is, optimize, optimize, optimize, and optimize some more, and DAMN the shiny new tech!

Re:Not again...

[__past__]

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.

Unfortunatly, no. That was how the W3C got big, and it was really good at it: Being an independent gremium where best practices from competing vendors were consolidated for the sake of interoperability.

But that is not what they are doing today. They silently switched from standardization to specification, developing "standards" out of the blue - and they suck at it!

The worst example is probably W3C XML Schema - the classical example of design by committe, hard to use, theoretically unsound, with lots of stuff bolted on without real integration late in the process (like the gHorribleKludge date/time types). And now they force it in into every other spec. They are seriously alienating huge parts of the community - take XPath2/XSLT2 for example, there have been quite some implementors stating that they don't plan to support it, ever (for example the ones of 4XSLT (Python) and libxslt (C)) - their user base doesn't need it (and yes, the userbase itself said so), and it makes the implementation way more complex than it has to be for XSLT1.

I certainly don't want the browser wars back, but I miss the old, working W3C.

an open letter to w3c

[joe_bruin]

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

Re:an open letter to w3c

[Khomar]

Amen to that. I don't really see anything in the standard that cannot be done with the current technology (except the suspend/resume... but as another poster noted, WHY?!). While this argument is often a bad one in that it can cause one to be stuck in the past forever, in the case of web development, stability is better than progress. The web is finally starting to reach a point (after many, many years of frustration) where everyone is using the same standard and most users have capable web browsers. Yet, just when the job of the web developer is looking to become almost managable, they want to add an entirely new mess that will involve a whole new generation of browser incompatibility and proprietary "features". There just aren't enough compelling reasons to face the compatibility nightmare. Yet another worthless standard...

BTW, what is up with this whole "separate the logic from the interface" kick about. While it is an interesting programming model, I do not see why an entirely new standard is required to support it. This kind of thing is already possible given existing server-side technology. Just wondering.

This yanks the rug out from under Office 2003!

[Tsu Dho Nimh]

The current design of Web forms doesn't separate the purpose from the presentation of a form. XForms, in contrast, are comprised of separate sections that describe what the form does, and how the form looks. ... These form controls are directly usable inside XHTML and other XML documents, like SVG.

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.

Doesn't anyone care about efficiency?

[sedrik]

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.

Re:Doesn't anyone care about efficiency?

[tupshin]

Depending on your delivery platform, however, the "costs" of XML do not have to be at runtime. This spec will allow you to create a UI independent method of representing a form-based interaction. The transformation to the actual delivery format (e.g. html or swf) can happen offline, so there doesn't need to be any run-time costs. In addition, the XForms XML representation of a form is likely to more compact then the HTML equivalent. Therefore the wire costs are less then current form based(web) applications. Net efficiency gain from today instead of a loss.

-Tupshin

Microsoft InfoPath?

[moosesocks]

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)

Re:Microsoft InfoPath?

[Nevyn]

So, for now, Microsoft seems to have produced a working next-generation form solution before any of the open groups or competitors.

But it's always easier to make the compromises you want, for what you want, than it is to work with a group and come up with something everyone is happy with. So this isn't a supprise, or even unexpected.

So much noise, so little signal

[Anonymous Coward]

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.

Re:Thank god.

[dasunt]

If Xforms allows the browser to verify fields, doesn't that mean we base our security on trusting the client?