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

Take away all the fluff ( ie: crap )

[grasshoppa]

and we get "New forms standard"

TLA's

[mummers]

I'm sorry, but this late on a Friday, that many TLA's in a /. article just makes me want to lie down and rest my weary head.

Re:TLA's

[theNote]

Its stories like this that remind me never to take /. too seriously.

in a nutshell...

[selderrr]

xforms is fully buzzword compliant and serves as an excellent tool for dumb managers to wank with.

bleh.

[Telastyn]

Maybe I'm just becoming old before my time, but I don't see how any of these recommendations, or any advancement to the web in the past 10 years has improved it.

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., in (slow) development since 1995 and still used in many useful apps like GeomView and Lyx.

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.

So many links

[Anonymous Coward]

After all that, I think Bender summed it up best:

"Interesting! No, wait, the other thing. Tedious."

Re:So many links

[Anonymous Coward]

There should be a -1 tedious mod choice.

Thank god.

[Duncan3]

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?

Re:Thank god.

[ITgrrrl]

Considering the number of consonants in the acronyms Xforms is likely a plot of slavic coders, 'cause I'm thinking that the next big set-up of off-shore code gerbil cages is Russia

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, go to W3Schools, which also has lots of other stuff. But knock off the buzzwords, people!

Re:Thank god.

[dasunt]

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

Re:Thank god.

[Tablizer]

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

Good point. Ideally validation should also be done on the server side in case JavaScript is broken or hacked on the client-side. However, that often requires double-coding unless a framework is built that does it for you.

A trickier issue is database-based validation where lookups have to be done on server-side data. For example, JavaScript can check that the Employee Number is indeed numeric, but it cannot by itself verify that it is a valid employee in the database. JavaScript cannot really do that without launching independent posts, which gets complicated and nasty to manage/code. I find JavaScript buggy and hacky in current browsers, and different users will have different versions.

Re:Thank god.

[flacco]

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

I presume it might be useful for prevalidation to avoid multiple idiotic user errors from hitting the server, but of course you wouldn't trust it to actually validate the data before using/storing it.

Re:Thank god.

[whereiswaldo]

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

My take on this: if you can validate on the client side, it saves you from having fancy (and tedious to write) code on the server side which repopulates the HTML page and allows the user to fix the problem. You still check for invalid data on the server side, but error messages can be curt and no repopulating forms BS.

All depends on what kind of site you're designing, of course.

Re:Thank god.

[bzzzt]

It will not save you from doing server side checks. FE: Checking a telephone number on the client could be a simple all-digit check while on the server you could check if some record hasn't been entered before (you'd need a complete list of entered records on the client if you'd like to validate that client side). Luckily, frameworks like Struts (jakarta.apache.org/struts) make it easy to build the repopulation + error messages stuff and also provide a framework for javascript validation.

Re:Thank god.

[Anonymous Coward]

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),

Sorry to break it to you, but you MUST do that anyway. Clients cannot be trusted.

Re:Thank god.

[serial frame]

I'll bet the Unix world is pretty tedious.

Re:Thank god.

[obi]

you have to do server-side input validation in any case. Never trust the client.

Re:Thank god.

[Anonymous Coward]

I'm posting as an AC cause I'm at my sister's house.
You want the server to do the form validation cause you never know nor can you ever trust the user's input. They might make a local copy of the form and send SQL statement to your server, or code so see what can be done to hack and break your system.
At best, you offer JavaScript to do the original form validation, then you revalidate the input when it is on the server side.
And for it being tedious? A few well written functions can cut down on a lot of work.

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.

Re:Thank god.

[sketerpot]

The ugliness I was talking about was the part where you need to interact with the user to get the required field informatrion right. That is ugly.

Re:Thank god.

[Anonymous Coward]

My take on this: if you can validate on the client side, it saves you from having fancy (and tedious to write) code on the server side which repopulates the HTML page and allows the user to fix the problem.

You can currently validate input client-side, using JavaScript.

If the user does not have a JavaScript-enabled browser, that's almost certainly their choice. Most likely, they've turned off JavaScript for some reason and they're used to dealing with sites that don't work correctly.

If the users actually don't have JavaScript support, they're using some ancient browser in esoteric conditions (text-mode browser or whatever). In these conditions, XForms won't work either. JavaScript is more generally useful feature to add to a browser, so it will be implemented before XForms.

If the user chooses to use a non-JavaScript-enabled browser, they can deal with curt error messages upon submitting forms. Lots of sites won't work for the user; yours will work but will simply be a little less friendly. On the other hand, if you use XForms instead of JavaScript, your site won't work.

Given that JavaScript is more ubiquitous than XForms, JavaScript can do more varied types of validation checks due to its programmable nature and that sites that use JavaScript for validation rather than XForms will continue to work with older browsers, what exactly is the purpose of XForms? I'm looking for a real-world example of where this technology would be used.

And this "repopulating forms BS" is anything but "fancy." It simply involves stuff like this:

<input name="foo" type="text" value="<?= $_GET['foo'] ?>" />

or

<input name="foo" type="text" value="<% foo %>" />

Or whatever it looks like in your web programming language. Items in <select>s are usually generated from some data, not written explicitly, so you just add a check to see if the current <option> is the one the user selected. There's one more "if" statement at the top of the form which spits out a message if there was some validation problem. This is hardly "fancy."

Key Feature

[billstr78]

Key Goals of XForms

• 
  
• Support for handheld, television, and desktop browsers, plus printers and scanners
  
• Suspend and Resume support
  

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!

Re:Key Feature

[Anonymous Coward]

You used the wrong button to post. The one you're looking for is marked ON/OFF, just below the floppy drive on your computer. Use it next time ...

Wow, welcome to the future

[Rosco P. Coltrane]

What next? Motif for the WWW?

Maybe they should have used a different name ...

How will this change things?

[Erwos]

I'm interested in how this will change the way things work now. Anybody want to explain?

-Erwos

Re:How will this change things?

[jjeffries]

It's far too late to change the way things work now.

Re:How will this change things?

[LarryRiedel]

What I would want from XForms is that a web site does not need to send a bunch of JavaScript crud along with a page that has a form, or even worse that the user has to submit the form back to the server just to find out that there were simple errors that could have been detected on the client if the form object inside the browser had enough knowledge and intelligence to eliminate relatively simple mistakes.

XForms should make it much easier to just define what the user needs to put in the form, and the browser will take care of displaying it nicely and eliminating simple mistakes. I do not think the idea is to provide a fundamental new feature; it is a way to make it so that something which is commonly needed can be easily provided without the need for a special programming toolkit.

Larry

Re:How will this change things?

[Captain Large Face]

I believe it just offers a wider variety of form controls (as well as other features -- can't be arsed to RTFA as it's 0130 here), such as sliders etc... This might enable the deployment of more applications that currently cannot take advantage of the web's benefits...

Re:How will this change things?

[Anonymous Coward]

Your first paragraph is exactly what XForms is intended to replace. Validation will be done on the client, by the XForms implementation in the browser, which will validate against, for example, XSD datatypes. Things like adding or deleting an entry on the form will also be handled on the client. And when you're done, the server receives a pre-validated XML document as form submission. What could be easier?

Re:How will this change things?

[iabervon]

You can put forms into other sorts of things than html in the same way that you'd put them in html.

A form can do some useful extra things without using javascript, which lets browsers get the user better feedback as to what will happen when they activate a control.

The form can specify more information about how the controls go together.

The value submitted by the form is in xml, so it can be structured.

There are a couple of new inputs, and the input tag is replaced with a set of tags, one per type, which matches the rest of xml (and html) better. It also has some additional combinations.

It also gets the specification of what you're trying to ask the user separated from how the form is arranged, allowing the browser to format things better for different devices.

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:How will this change things?

[__past__]

Considering the superb support for advanced concepts like accesskey, tabindex (which have been in HTML for years), XML "standards" like XLink, XPointer or client-side XSL (-T and -FO), or sane IMT handling in current client and server software, I'd expect it to change the way things ought to be done but aren't, and nothing else until a military superpower finds a way to connect bad markup practice with terrorism.

Re:How will this change things?

[Yakman]

Your first paragraph is exactly what XForms is intended to replace. Validation will be done on the client, by the XForms implementation in the browser, which will validate against, for example, XSD datatypes. Things like adding or deleting an entry on the form will also be handled on the client. And when you're done, the server receives a pre-validated XML document as form submission. What could be easier?

Which you then have to go revalidate again at the server end because you can't trust anything you get from the client. Still, not much different from the way a lot of web apps work today but probably a bit more "standardised" which is nice.

Re:How will this change things?

[jcast]

1) decouple data, logic, and presentation

Am I the only one with warning bells going off in my head? This sounds to me like `make writing it wrong harder' (which increases average difficulty), rather than `make writing it right easier' (which decreases average difficulty). Ultimately, successful standards are those which most decrease average difficulty, regardless of how execrable the solutions they produce (i.e., C), not those that most increase average difficulty, regardless of how beautiful the solutions they produce (i.e., Ada).

Re:How will this change things?

[jcast]

Right. Until they come up with a way to make good markup significantly easier than bad markup (I'm a Haskell geek, so I'd suggest a good combinatorial approach, except that wouldn't work in XML), bad markup will prevail.

Re:How will this change things?

[bwt]

Wow -- you are way WAY offbase.

I would say that besides Dijkstra's "goto considered harmful", the model-view-controller design pattern is THE next most important programming insight in existance. You are probably the first person I've heard openly question it in the last five years. You should go out and buy a copy of the gang of four book and read it cover to cover three times -- it would do you well.

I have on many, many occasions seen completely unmaintainable systems choke and break on each minor change because somebody in distant years earlier violated this rule. I probably wouldn't hire a programmer these days that couldn't give me five examples from personal experience where their project paid dearly for breaking this design pattern.

Re:How will this change things?

[Anonymous Coward]

Give the guy a break... MVC isn't appropriate to everything (if I write a script to do a find/replace, should I implement it using an MVC architecture?). There's such a thing as over-architecting. Go look at XForms and decide for yourself. I know I certainly wouldn't want hand-code one of those things.

Re:How will this change things?

[jcast]

I never questioned Model, View, Controller. I questioned whether this standard (or your approach) is successful, overall, in convincing programmers to adopt this approach, or whether it's simply successful in convincing programmers to go elsewhere.

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

[Anonymous Coward]

Honestly, don't complain because it's new. If it sucks feel free to complain away. But some of us don't feel like reinventing the wheel everytime we program something. Lots of people end up writing toolkits to get around limitations in existing technology. This just standardizes it and allows us to drop some of the hacks. Granted, with web standards you have to wait a really long time before the standards are used properly with enough browsers to safely use but it's a step in the right direction most of the time.

If you want to crawl in a hole and pretend that technology will never advance, feel free. Just don't be surprised when the rest of the world leaves you behind.

Re:Not again...

[Anonymous Coward]

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, et


Yes, probably. The web has grown far beyond protocols and standards designed twenty years ago, and Perl/CGI just don't cut it. It would take me 10x as long to write a web application using Perl/CGI as it would using JSP's Servlets or any other modern standards based technology. As the uses for a technology change, so must the technology. It's a fact of life.

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

[KaiserSoze]

Sorry, I don't normally get drawn into things like this, but I have to comment.

Wow, yes, you are indeed the Master when it comes to making Perl jump and do tricks. And I loved web programming with Perl too, until I started using PHP. It simplified a lot of the "busy work" that goes into Perl CGI creation, and was generally easier to use to prototype a page and such.

The point here is that something came along that made web programming a little easier, which is what I gather XForms is. Who cares about Flash-compilers. All I care about is efficiently creating and maintaining forms code. Yes, it is relatively simple right now. That doesn't mean I won't check out a new way just to see what it's like.

Do you honestly think I'll look up to you if you grumble about how "assembly language is the only true form, new niche languages are for pussys"? Sorry, but statements such as "I can do [blah] without any of that fancy whizbang technology!" do nothing to endear me to your argument.

So, go ahead and code with pure HTML and your CGI forms, I'm sure it will look and function fairly well. But don't take it out on others if you feel time creeping up on you.

Dammit, I want back to 1995 and Slackware 3.0...

By all means, go ahead. I won't miss you.

Re:Not again...

[Khomar]

You make a good point regarding not keeping up with change, however, I think in the world of the Internet, it is a little different. For years, developing applications for the web have been incredibly difficult due to different implementations of standards with the different browsers and proprietary "features". As a web developer, I look at this new standard with dread, and it will probably be many years before I will embrace it due to incompatibility with my user's browsers. Users are notoriously slow to upgrade to the latest and greatest. We are just starting to see some stabilization in the browser market with innovation turning more toward usability features rather than standards support.

I see the new innovations in web development coming in server side tools and development suites. .NET is a good example of a new way to deliver content that is usable by the masses that makes the development of complex web applications easier. My biggest concern with a re-write of the web forms is a huge change in code (and the incompatibilities that will result) with relatively little actual gain. In looking at the list of features, I saw nothing that I cannot live without. If there is a major "must-have" feature in there that I missed, please let me know. Really.

Re:Not again...

[JessLeah]

I don't consider this "advancing". Nor do I consider it necessary... or desirable. This is simply the tech equivalent of bureaucracy. It's feature-creep on an industry-wide level.

(I'd rather say "field", but no one but me seems to think of computing as anything other than an "industry" nowadays. Or a "business".)

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

[Pieroxy]

XForms' separation of content and markup

Am I the only one thinking about how the <strong> tag died because it was just not rendered the same way from a NS to an IE browser?

The way people design their forms today is a graphic control down to the pixel. That will obviously not accomodate an embedded device and a 1280x1024 desktop. So people will just "sniff" the browser... and the whole point of "separation of content and markup" will die just right there.

Anyways, it's good to see people trying to make things move.

Re:Not again...

[Anonymous Coward]

The fact that you said "perl cgi" tells me everything I need to know about your supposed Perl knowledge that you had before you moved to PHP: absolutely none.

You might want to look up things like mod_perl, and HTML::Mason, and Template::Toolkit one of these days.

As for PHP... call me when they fix all of the bugs with references, which still don't work right.

Of course, I doubt you know what a reference is to begin with.

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!

Re:Not again...

[Anonymous Coward]

.NET is gay. It is only supported on windows severs. Who the fuck wants to run a site on a windows server? ps - I know about Mono. Notice I said supported. pss - Ignore everything I said. I'm drunk.

Re:Not again...

[sketerpot]

I thought the strong tag died because it was more work to type it instead of the b tag. Now that CSS has wide browser support, you'd think that people could just use the strong tag and be content that it would render they way they wanted it to, unless the user really wanted it some other way.

Re:Not again...

[glwtta]

Wow, yes, you are indeed the Master when it comes to making Perl jump and do tricks. And I loved web programming with Perl too, until I started using PHP. It simplified a lot of the "busy work" that goes into Perl CGI creation, and was generally easier to use to prototype a page and such.

Why do people keep bringing up CGI all the time? Hasn't it been decades since anyone (who knows something about development) actually used CGI? That's like going on and on about all the stuff that was broken in PHP 2.0 (ok, bad analogy maybe, some of it is still broken).

Ignorance of perl web development doesn't really entitle you to an opinion about it.

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.

Re:Not again...

[H*(BZ_2)-Module]

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

Perl came about in 1987 or thereabouts. Do you think that it was really needed at that point? We already had sed, sh, awk, C, and the rest of the Unix tools. For that matter when C came out we already had Lisp, Smalltalk, BCPL, Intercal, and dozens of other languages(which you didn't bother to include in your list). You also didn't mention any versions in your list. Which version of Fortran is "good enough"? Is it Fortran I, II, III, 66, 77, or 90? To be honest, I'm inclined to agree with you, up to a point. I think that far too often new technologies are adopted and succeed just by benefit of being new, without actually offering any real improvements over existing technologies. I don't think that this provides an argument to simply dismiss all new technologies though. There definitely has been, and still is, room for improvement.

Re:Not again...

[Pieroxy]

Usually, web designers and UI people would prefer having something nice and flashy, with a specific "home" look and feel, all the real estate used, very well optimized and lightweight.

They don't care about a tag that would say "this is important" without begin sure how the important thing is rendered.

Of course, that makes it hard to make a perfect cross-browser product.

not even talking about PDAs & other stuff...

Re:Not again...

[zangdesign]

A lot of this complexity has been introduced to:

1) ensure that companies can continue to market computers to
2) consumers who complain that the technology is too complex because
3) programmers just can't leave well enough alone.

It's all a part of progress and the Darwinistic natural selection process of computer engineering. Yup, I'll be obsolete in a couple of years (if not already) but so what? That's life.

It happens.

Re:Not again...

[revscat]

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!

Great! And what else can you now do with that GUI system? Can you run a DB? Can you, perhaps, run an IM client, a P2P client, an email client, listen to a streaming MP3 station, and be reading /. at the same time? Is this 64K GUI OS event driven, and can it efficiently schedule tasks?

Whatever. Sorry, friend, but you're taking that idea way too far, even if there is a kernel of truth in it.

running some beautifully written, hand-optimized C or assembly code, tuned and tweaked and whittled into glistening sleek perfection over the past 20 years.

Sure, but you're spending all your time improving existing code, while not adding any new functionality. Sure, it may not be the best. But if I have to choose between a bloated POS 1.0 version of pkzip, and no version at all, I'll pick the 1.0 version anyday.

I mean, what exactly are you proposing here? You seem to be bitching that code is bloated, and that if we just did things the "right" way -- "DAMN the shiny new tech" -- we'd be light years ahead. I don't think that's true, certainly not in any software that has a bit of maintainability or extensibility to it. Writing something in assembly would certainly make it lightning fast, but it certainly would make it difficult to improve and maintain. Over time, you wind up going backwards.

And what "shiny new tech" are you talking about? XForms? XML? HTML? CORBA? Where's the line, and how do you determine where that line is? You seem to imply that any technology developed after C++ is just redundant and worthless. If I'm wrong here please correct me.

Prove me wrong, if you can. There are good reasons why things like design patterns, OO, and other modern software design techniques have become widespread. And these reasons are above and beyond their newness. Things that are new but don't work well die, especially when better options beocme available.

Re:Not again...

[falzer]

Slackware 3.0 in 1995... ah, memories.

Re:Not again...

[shepd]

>A lot of this complexity has been introduced to:
>1) ensure that companies can continue to market computers to
>2) consumers who complain that the technology is too complex because
>3) programmers just can't leave well enough alone.
>It's all a part of progress and the Darwinistic natural selection process of computer engineering. Yup, I'll be obsolete in a couple of years (if not already) but so what? That's life.

That sounds like exactly the same argument bolt makers made before they set themselves on standard thread sizes:

1) You can ensure a market (because anyone using your bolts has to buy your nuts)
2) It's less complex when there's only one model per problem, because the company doesn't make the size you want, so you just can't do the job
3) The engineers were always looking for the perfect sized thread for the application

Imagine building a house if every screw from every manufacturer had a different type head depending on the year it was manufactured, every bolt and nut had to be from the same company, and every plank of wood came in a flavour of the month (Oh, sorry, we don't stock 2"x4"s anymore, try our new, improved, 3.141"x5.4325" size instead).

It'd be hell. And your house would be built as well as today's computers. You'd have to tear it down ever two years and replace it.

But, what am I saying, there's always some company wants to re-invent the paradigm, or some other buzzword of the week.

Re:Not again...

[zangdesign]

But all of this is progress. It takes ten tons of crap to produce one nugget of gold - but that is the nature of our business. Most of it is indeed crap - we're writing the same code over and over to produce the same results for different customers (speaking of the industry as a whole).

It's slow progress for us; frustating most of the time; but the people who consume the products we produce clamor for more and more of it, so we must be doing SOMETHING right.

The XForms brouhaha will be yesterday's news next year, just like Java is no longer the hot new technology. But the good thing is, pieces of it will remain that will require maintenance and someone has to perform that maintenance. XForms could very well be the next COBOL, with younger developers moving onto some other cool technology, but leaving older developers to get fat and rich as they draw higher and higher pay for maintaining code that no one wants to deal with anymore, but can't afford to switch to more modern systems.

Now that I think of it, it may be time to dust off those COBOL references and put that knowledge on my resume.

Re:Not again...

[tesmako]

Ah, but the fun part here is that despite all the happy bloating most stuff is plenty fast anyway, thanks to neat hardware and so on. The real problem with software is bugs; stability and security. One of the better ways to fix a lot of bug problems has been around since the fifties, climb to higher level in program design and implementation. It tends to have a bit of a cost in performance (mostly memory-wise), but we have plenty of performance (especially memory, anyone complaining about their OS not running in 1 megabyte is just insane, RAM is insanely cheap).

So I hope that the future brings better and easier to use tools and languages, .NET is clearly a step in the right direction (though I don't agree with the design of the system in all aspects it is nice and safe and has some basics to aid modular design).

All in all what I feel is the point to be made; Programming is way too hard a task for almost all humans and also almost all programmers. Making software more robust is a lot more important than saving half a buck worth of RAM when running the program.

Come on, you know the world would be a better place if all software was written in lisp/prolog/ml/smalltalk (ok, with a bit of C thrown in for a critical loop or two :)

Re:Not again...

[renoX]

>The worst example is probably W3C XML Schema - the classical example of design by committe, hard to use,[cut]

Well, I don't know if the W3C XML Schema is good or not, but the "normal" DTD definition is really, really ugly!

Re:Not again...

[ChannelX]

I just have to say that if you don't like it don't use it and quit moaning. What I'm personally sick of are people such as yourself who seem to think that 1) the "old" ways are better. they may or may not be. 2) everyone who does web work has to make sure every browser is supported equally. clue: its not the truth. these new technologies may be very useful for some and not for others. I personally only have to worry about developing sites for IE. I code web-based business applications. I can guarantee that XForms will be very useful in that area. 3) think that they have to learn every new technology out there just because its out there. again not true.

so why not just chill out a bit huh?

Re:Not again...

[Anonymous Coward]

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 guess you're the only one, indeed. You left out object oriented and functional programming languages. And I hope that by HTML you meant CSS too :)

Re:Not again...

[hachete]

There's a perfectly good reason *why* these projects are getting more complex - particularly XML Schema, SOAP, the fight over RSS et al - and that's because people like IBM/SUN/MS don't want people like *you* building apps that put them to shame. That's right: they want the market sewn-up even before it gets to first base. It's their ball and you ain't playing with it.

So, the "useful stupid" that kicked off this rant 2 parsecs back is basically being a patsy for the big boys.

Just look for things getting yet more complex. In the name of something else, naturally.

h

Browsers..?

[Anonymous Coward]

Most important question: what browsers will allow me to use XForms? Anyone got an answer?

Re:Browsers..?

[jnana]

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.

Slashdot clearly doesn't care what the W3C thinks.

[Anonymous Coward]

Just take a look at the W3C validation results.

I gotta stop going out nights...

[FosterKanig]

...that "summary" made my head hurt.
That's a whole lotta crap jammed in a very small space.

Re:I gotta stop going out nights...

[Anonymous Coward]

Your head or the summary?

Re:I gotta stop going out nights...

[FosterKanig]

Both.

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

[Anonymous Coward]

PS: Please force browser makers to implement a spell/grammar check.

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.

Re:an open letter to w3c

[Eros]

Preach preacher.

Right on!

Re:an open letter to w3c

[grasshoppa]

PPS,

Your use of as many possible acronyms is becoming, quite frankly, disturbing. Seek professional help. Immediately.

Re:an open letter to w3c

[irritating environme]

Dude, you forgot the five layers of abstraction on the back-end:

XML-based Web services, connecting to your Application Server layer, which communicates with the Enterprise Application Integration Messaging/Queuing Layers, JDBC abstraction layers, CORBA, DCOM, interpreted/JIT-compiled ByteCode, plus all the TCP/IP messaging it all runs on across the eight servers.

Re:an open letter to w3c

[lennert]

You speak for all of us! Plain text rules.

Re:an open letter to w3c

[GigsVT]

It's more of seperating the content from the presentation.

The idea is you can write a document once, then you can run it through one doohicky and make a PDF that looks nice for printing, run it through another doohicky and make a website that looks nice (and isn't linear like the printed version), run it through a special doohicky and it makes a web site that works for blind people, etc...

Basically, once you write the content, you never have to worry about formatting, that's not your concern.

A side effect is that the semantic markup makes it really easy to do things like smart search engines, that know that "python" could either mean a snake or a programming language, and let you clearly specify which you mean.

Re:an open letter to w3c

[hey]

I agree. What is it about XML that brings out the anti-KISS in people? There won't be any web if HTML was so complicated!

Re:an open letter to w3c

[Hangtime]

AAAAAAmen Reverened. Preach on! Does anyone get the feeling this is a technology in search of a solution instead of vice versa. Now I am sure there were a lot of smart people who came together to do this but guess what, it will not be used. We need to be spending more time on content instead of trying to disaggregate content from presentation. There are now several different ways you can do this as shown in this thread and one more additional one way doesn't help. Go back and think of some interesting stuff instead of the rehashing the same thing 30 different ways.

Re:an open letter to w3c

[elemental23]

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.

Blame the software manufacturers for that. The W3C recommendations that the browser authors are just now catching up to are mostly between three (XHTML, introduced in 2000) and seven (CSS1, introduced in 1996) years old. Since then, the W3C and others have been coming up with newer, even better stuff. Take a look at XHTML 2.0 and CSS3, there's some seriously cool stuff there (but only if you're at all interested in web development, I suppose). Or would you rather everyone just sit around and wait while lazy and/or short sighted browser developers/companies take their time implementing things they should have implemented years ago?

Re:an open letter to w3c

[jcast]

Basically, once you write the content, you never have to worry about formatting, that's not your concern.

Right. And as soon as those concerned with formatting can do a decent job of it (like, say, catching up to what TeX had in the mid-80s, or what old-fashioned linotypes had even before then), I'll start listening.

Re:an open letter to w3c

[jcast]

Why? Why exactly `should' browser developers have implemented CSS `years ago'?

Re:an open letter to w3c

[GigsVT]

Linotype was a very labor intensive process. It's like comparing hand-hewn wood cabinets to assembly line prefab cabinets. Of course the former is a better quality, but an order of magnitude more work.

Re:an open letter to w3c

[jcast]

TeX is not a labor-intensive process, though, and it's still just as high-quality.

Re:an open letter to w3c

[sahala]

BTW, what is up with this whole "separate the logic from the interface" kick about.

You kind of make yourself look ignorant with this statement.

IN SOVIET RUSSIA

[Anonymous Coward]

Form submits you!

Wha?

[Anonymous Coward]

I really shouldn't have smoked that joint before reading this topic.

Gah.

Slow?

[Anonymous Coward]

"XForms is the next generation of forms for the Web, and uses an XML-based three-layer model: data model, data, and user interface."

Sounds slow to me.

Re:Slow?

[AllUsernamesAreGone]

Rediculous, look at Java Swing: that has data, model and view separation and that isn't slow.

Oh, sorry, wrong universe again. Forget I said anything...

Minor correction

[Anonymous Coward]

Two implementations, not one, passed the test suite for XForms: X-Smiles, and FormsPlayer

Re:WTF? That name is already taken, try again.

[billsf]

Cool, that was exactly what I was thinking of when i saw this posting. Instead is see some pretty strange programming tools for idiots.

Xforms cool but I'll wait

[Anonymous Coward]

Being able to describe a form with validations, presentation and calculations all in a single language is cool. This promises to let me do this with XML.

As I read all the cool features, I realize that I already get a lot of this in the NET webforms. With the postback model and code behind pages, I get presentation separation, I can write validations and event handling in a consistent language (or choice of languages) and I get all this with regular old forms on standard browsers.

With XFORMs you have the same old endless battle to have your standard consistently implemented on all these different clients. Not going to happen soon enough for me to target XFORMS just yet. If it gets adopted and the flash people don't try to kill it, I might reconsider.

Re:WTF? That name is already taken, try again.

[SpamJunkie]

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.

CSS for device independence?

[irritating environme]

Huh?

As someone who once wrote a cross-device content delivery platform for PDAs, WML/HDML phones, and browsers, I repeat:

Huh?

Craptastic.

Re:CSS for device independence?

[Anonymous Coward]

I believe you meant to say "craptacular". In the future, please endeavour to embiggen your cromulence before posting.

Re:CSS for device independence?

[Anonymous Coward]

As someone who also once wrote a cross-device content delivery platform for PDAs, WML/HDML phones, and browsers, what's your problem? Different devices have different size screens. CSS lets you give different style sheets for different types of devices. It helped me; it reduced complexity; it centralized information. I suppose your mileage may vary.

Re:CSS for device independence?

[a_n_d_e_r_s]

Wap is dead.

It was really half-dead from the start.

Re:CSS for device independence?

[jrumney]

Welcome to slashdot. Try substituting XSL for CSS, and things might start to make sense.

DOA

[Anonymous Coward]

I don't see Microsoft in the list of companies. If so, this technology will never go anywhere. If your answer is an "internet explorer plugin", then SO LONG, better luck next time.

Re:DOA

[blowdart]

Then you didn't read the link. They're there, in the same parts of the committee structure as Oracle. But you didn't seriously expect Microsoft to get listed on a slashdot article did you? Turn in your userID to Timothy please.

Re:DOA

[Zaiff Urgulbunger]

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

Mod parent up - Sad, but true *and* funny!

[Anonymous Coward]

The subject line says it all.

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

Which is presumably similar to what they said when tables and forms got added to HTML.

Yes! Let's stop all innovation and changes now, and declare computing science a finished project. Then we can go home and watch some TV

Re:HTML, Tables, and CGI

[Anonymous Coward]

Tables and forms were added very early on and were a major leap forward, analogous to adding mechanical pulse routing to a previously manually switched telephone system. The stuff we're talking about here is no comparison; sites that use it will break on a lot of browsers, and the benefits aren't nearly as great as the leap made with tables (took care of precision formatting) and forms (filled the requirements of data entry).

Today, innovation and changes to telephone signalling equipment that broke the ability of most telephones to ring would be scoffed at, and I'm saying that that's what this happy horseshit is like. Give me something that does more good than bad, and I'll get behind it.

Anyone know about a program like this?

[Anonymous Coward]

Does anyone know of a program that lets another computer "draw" in a window on my computer? Maybe we could start a "network" of these programs, like the www, only with these awesomely new programs; the servers could use whatever programming language they want to construct their input/output system...hmm...I see the letter "x" a lot in that summmarry...maybe we could call this newfangled program "X"?

independencence?

[renard]

XForms uses CSS for device independencence...

Here at /. we have human editors for spelling independencence... not to mention English grammar transcendencence... or (my favorite) just plain incoherencence...

Re:independencence?

[Anonymous Coward]

Don't sulk. This story will be re-posted soon and with different spelling errors.

Re:WTF? That name is already taken, try again.

[crucini]

Yes, this is ridiculous. It's as if these head-in-the-clouds corporate types are on a completely different planet. Kind of like Microsoft with ".NET". And the sad thing is that they're running over something that actually works to make space for something that may never work.

whoo hooo

[Zebra_X]

and yet another half assed, more complicated "standard" that not everyone will implement correctly and that will partially work but need to be fully supported. >:O

Just one simple question:

[RoLi]

Do they support combo-boxes?

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

Re:Just one simple question:

[Anonymous Coward]

Yes, XForms supports combo-boxes

Re:WTF? That name is already taken, try again.

[tarquin_fim_bim]

Xcellent post.

Au Contraire...

[xeo_at_thermopylae]

AFAIK no web (WWW) standards are 20 years old yet; 1991 is the earliest year for an HTTP specification.

And Perl works just fine, thank you, with any of the newer standards, so the term "standards based technology" is gratuitous at best.

Perl development is so much quicker than JSP servlet development partially because there are so many well-written and thoroughly debugged CPAN modules written for Perl (and partially because Perl is simply so much quicker for development!-P)

Re:Au Contraire...

[psykocrime]

Perl development is so much quicker than JSP servlet development partially because there are so many well-written and thoroughly debugged CPAN modules written for Perl

Not to burst your bubble, but there's oodles of "well-written and thoroughly debugged" code available for Java (JSP/Servlet) programmers as well. Check out OpenSymphony, the Jakarta Project, etc.

(and partially because Perl is simply so much quicker for development!-P)

I'd say that's a debatable point. :-)

Re:Au Contraire...

[Anonymous Coward]

The two URLS you provide are very small when considered aside CPAN. CPAN is no less than 100 time larger in subject area and code than the combined content of the repositories you named.

Re:Au Contraire...

[psykocrime]

The two URLS you provide are very small when considered aside CPAN. CPAN is no less than 100 time larger in subject area and code than the combined content of the repositories you named.

Right, but those are hardly the only available sources of freely available java code.

I'd guess that the amount of available Java code is within an order of magnitude of the amount of available Perl code, if one knows where to look.

The biggest thing the Java community lacks in that regard, is one centralized location to grab stuff from, akin to CPAN. But who knows, maybe java.net will grow to encompass such a position in the Java world...

Hrm...

[Anonymous Coward]

So all I see right now are people who (probably) don't understand the standard complaining about it existing, and claiming it's not needed.

The thing is, a clearer specification and better flow for form-handling most definitely is needed. Any webdesigner who's ever spent time working on "webbased applications" has quite probably experienced going completely stir crazy with building up stupid forms element by element and javascript functions for interaction between these. Even something as trivial as giving focus to an element requires a quite lengthy string: document.formname.elementname.focus();
XForms has built-in events to deal with all those far too common tasks and make webbased applications for the first time ever actually work like applications. You'll be able actually pay attention to stuff like workflow.

Sure, the XForms syntax sucks, and I'd hate to have to hand-code applications using it almost as much as I hate trying to do the same with current forms. Unfortunately given the W3C's chosen route of XML, and the need to make XForms integrate with the next "HTML" standard (XHTML 2.0), this was inevitable.
However, at the same time there's the major benefit of it being XML and thus far more likely to be computer-generatable.

XForms is not perfect. But four or five years from now when IE has finally caught up and is handling XForms without the need for any plugins, developers creating webbased applications will be giving silent prayers for the people who created the standard.

Re:Hrm...

[S.Lemmon]

Even something as trivial as giving focus to an element requires a quite lengthy string: document.formname.elementname.focus();

I've nothing against that syntax. What I hate is is stuff like having to stick that call into a timer because some browsers don't let you change focus in an onblur event. What's the point of even having onblur if when the validation fails you can't do something as simple as send the focus back to the original control without jumping through convoluted hoops? Also, ever need to do something as simple as find which element currently has focus? Writing JavaScript, even with new DOM compliant browsers, so much time is wasted finding complicated ways around silly limitations, that sometimes I wonder if its creators ever bothered to actually tryt and use it themselves.

Re:Hrm...

[Anonymous Coward]

One approach is to not use javascript. Keep everything the client sees dirt-simple. You can't trust the clients, so you have to replicate all the validation code on the server anyway. Put the smarts into CGIs that generate the HTML on the fly and you can build very complex, scalable, and professional sites without a lick of javascript, DHTML, or even CSS. You're essentially doing your own SSI processing so you can add whatever you need as you go. A side benefit is that browser compatibility is greatly increased. Put the bulk of your time investment into C CGIs, not ever-changing web "standards".

Re:Hrm...

[jcast]

The thing is, a clearer specification and better flow for form-handling most definitely is needed.

I'm to lazy to RTFA (especially if it's a W3C spec), so I'll ask you: does this specification consist of the standard `come up with a syntax that allows for 30 billion programs of a given length and declare 200 of them `correct' ' crap?

hmm...

[Yaa 101]

Is there a commit and rollback system into this standard?

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.

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

[Chokolad]

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

Can you elaborate on how exactly Beast of Redmond totally bastardized XML ? Just curious...

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

[molarmass192]

Sure thing, take a look right here. 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. 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:This yanks the rug out from under Office 2003!

[Chokolad]

Well, Office 2003 has not been shipped yet, so this does not mean that redistribution of XSD will not be allowed in RTM. It is still Beta. And still, I hardly call this bastardization. You can validate this stuff with schema, right? Schema is good old standard XSD, right ? Xml does not have any new non-standard fields? Where is bastardiaztion.
I am pretty sure you will be able to redistribute Word XSD after Office 2003 ships.

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

[Anonymous Coward]

Well, try to download those schemas, and you'll find some 404s...

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

[Tsu Dho Nimh]

Let me start by saying that Microsoft has been promising "native XML" since 1997 when it was scheduled to appear in the next version of Office.

With its integrated set of servers, services, and programs, the Microsoft Office System provides developers with the tools ... if you don't buy the end-to-end solution, you have only an office suite that writes an XML document to their defaults. Looking at their default XML, and comparing it to the default XML out of OpenOffice, I shudder at the thought of having to parse it. As usual, they have taken a perfectly coherent system and bolloxed it up. The schemas they refer to are AFAIK, binary blobs that only their software can read, not the usual XML ASCII schema such as used by OpenOffice.

Also, these solutions are only available in the "professional" version of Office, which means some versions of Office 2003 are more equal than others. Any other version "can be saved in a native XML file format which can be manipulated and searched using any program that can process industry standard XML" ... but you are stuck using their idea of XML, which as you can see from the link provided by the first reply, is not exactly easy to follow.

"The Microsoft(R) Office System enhances XML support in the 2003 versions of the Office applications and introduces new applications, which put XML in the hands of the information worker and enable businesses to reap the full benefit and promise of this revolutionary technology. .... Some of the XML capabilities in this document are only available in Microsoft Office Professional Edition 2003 ... Like Word 2003, Excel 2003 can act as a smart client for XML Web services ....

Needless to say, those "XML web services" are not really XML, they are Microsoft server extensions, working off proprietary Microsoft DLLs, working with the Rich XML produced by Microsoft's proprietary software.

New with the Microsoft Office System, InfoPath 2003 uses a forms metaphor to capture information according to a customer-defined XML schema .... InfoPath solutions that send data from the desktop environment to backend systems via XML Web services. With the XML Web Services being totally Microsoft. InfoPath is also totally Microsoftian, totally proprietary, and with its ability to reach into the desktop and web server and alter data and install programs, a security nightmare. Think Active X on steroids.

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

[Tsu Dho Nimh]

"All the versions of Office 2003 will have support for what we call Native XML. Native means a native file format of Office. In this case we have SpreadsheetML within Excel and a new one for Word, WordML. Both of these formats save files as XML." ... "We didn't create WordML to be an interoperable format." Microsoft Office Product Manager Simon Marks.

XML is supposed to be interoperable

Microsoft has taken the stance that small companies aren't likely to make use of custom-defined schemas because an IT staff skilled in XML and familiar with the XSD specification is needed to write one ... I will admit that schemas are a PITA to define and write, but there are industry-specific schemas already out there, and the tools to make writing them easier are there too. Microsoft's concern for the small business is just an excuse to sell crippleware and licence upgrades.

http://www.smallbusinesscomputing.com/biztools/a rticle.php/2194131

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

[smallpaul]

In what sense is the XML only readable in Word? You don't need an XSD to read XML. If you spend an hour eyeballing that XML you will get the gist of it and if you download the CDK you will get the precise definition of it. There is no need to redistribute the schemas!

We don't need no backwards compatibility

[Simon Brooke]

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.

Re:We don't need no backwards compatibility

[Anonymous Coward]

Your original complaint seems to be about not being able to use XSLT to do the job. Correct me if I'm wrong, but XSLT is turing-complete, so if it is possible at all, it is definitely possible with XSLT (though possibly hard).

The fact that there are already commercial implementations doing what you want (delivering XForms to legacy devices) seems to imply that it is possible :-)

Re:We don't need no backwards compatibility

[tupshin]

I actually don't see a substantial drawback to doing the HTML transformation in one XSL pass and the data population in a second one. In fact, it would seem that this is a good conceptual split so that you can have one conversion (to unpopulated html) that is data-source independent, and is probably generalized for all of your forms, and another one that is smaller, customized to individual forms, and specific to a given source. XSL chaining shouldn't be computationally prohibitive, but if it is, the first transformation could be cached (on a per-browser type basis) to remove the run-time cpu costs.

The more I think about it, the more I like the split, even in terms of utilizing it from XSL.

-Tupshin

Re:We don't need no backwards compatibility

[Phantasmo]

We need to stop worrying about legacy devices and think about forwards compatability. The WWW needs solutions that will be able to adapt to tomorrow's requirements and gracefully step down in favour of new technologies that can better meet those requirements.

There's no reason to stay in the technological stone age because "Big Company X" won't get with the program.

features

[Pflipp]

Well the majority of the comments here is containing just question marks, so I guess it doesn't do any harm if I post some myself, and even put a question before them.

Thing is, I happen to get annoyed with Web development as soon as I either want a user to input formatted text (just yer basic bold, italic, etc.) or I want to enable them to create an ordering in the list of objects they own. The latter currently involves a multiple selection box and a small-print A4 full of JavaScript garble.

So I guess anything should be O.K. when it solves the above problems. But does it? (Honestly: idunno, and I'm not sure if I want to read a W3 document right now ;-)

Re:features

[Zaiff Urgulbunger]

It will do.

But not just yet.... wait a few years for better coverage.

Re:features

[iantri]

Thing is, I happen to get annoyed with Web development as soon as I either want a user to input formatted text (just yer basic bold, italic, etc.) or I want to enable them to create an ordering in the list of objects they own. The latter currently involves a multiple selection box and a small-print A4 full of JavaScript garble.

It sounds like you are trying to write a word processor and a personal inventory system with HTML and Javascript and a bunch of back-end crap.

Why?

Just write a proper application and be done with it.

It seems everyone now thinks that there should be 'web-based' applications..

Re:features

[Pflipp]

The need to write in style (b iu) on the Web is already demonstrated by Slashdot. Luckily we're most techies here, so you can sell HTML as a "logical way" of biu-ing.

For the latter, there's not much need for a web-based gallery/ selling system if it's not on the web, eh? :-)

Thing is, HTML widgets were created when the need for this wasn't present. Nowadays every GUI toolkit enables programmers and users to write in style to certain extents. People expect it for Web maintenance systems. Ordering of objects (e.g. of pages) is also something that keeps popping up. (Admitted, there's also no single way to do this in GUI toolkits) The lack of controls we have makes these things hard to do in a user-friendly way.

two meta's too many?

[devphil]

Isn't that carrying alliteration a little too far?

(Hint: say it aloud.)

Okay, I'm sorry. I've just always liked that one.

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?

[shaklee]

I agree. When I first ran into XML as a method for transporting data, I asked two very fundamental questions: How does markup get applied to a database table, and why would you pay the price of 40 bytes of XML markup to deliver four bytes of integer data? The problem with XML is that it assumes the markup and data are intertwined (thus the word "markup.") Also, it encourages the use of a general XML parser. Why write an optimized parser when you can grab a working general parser? Writing parsers is hard and expensive work. However, a general XML parser is hugely inefficient beyond the point where anyone caring about performance even begins to think about using a general parser. XML to deliver terabytes of data, by either marking up the data in the database itself or dynamically applying the markup on delivery of terabytes of data, is so inefficient it defies discussion. Why would anyone of any sanity even consider it? It blows my mind. Time and time again, when I bring these points up to my colleagues, they have no answer, or they are not systems programmers and say really, really uninformed systems programming things like "CPU cycles are free" or "disk space is free."

Re:Doesn't anyone care about efficiency?

[Anonymous Coward]

Sure, it's no way near as efficient as a properly structured binary format.
On this subject, XForms, we are dealing with standards from W3. So you want a binary protocol for web content? Or want to give some strange story about HTML being more efficient than XML?? Because we all know how well structured HTML is, and we also all know how easy it is to parse HTML compared to XML....

- straigth forward : I don't know. I think an XML file i usually nearly self-documenting. Whereas if I had a binary file I'd have to go through a bunch of docs just to get started.
- more maintainable : again, personal preference, etc. I'd say that with proper utilization of the XML related standards, especially namespaces and versioning thereof leads to excellent maintainability.
- more efficient code : efficient in what way. Runtime execution - without doubt. In development time, I think XML is excellent. If you have to worry about performance (cpu or memory) use SAX. If not go-ahead and use a tool to create code based on your XSD.

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

Re:Doesn't anyone care about efficiency?

[Anonymous Coward]

Nope! Efficiency concerns are so 80's.

-1 Redundant.

[Randolpho]

Looks like the prevailing opinion is that this sucks. I'm afraid I have to agree, after a cursory glance. Looks like they overthought the problem.

Personally, I'd much prefer a simple extention of the current sytem to support other gui input controls, like, say, combo boxes.

Re:-1 Redundant.

[Zaiff Urgulbunger]

Personally, I'd much prefer a simple extention of the current sytem to support other gui input controls, like, say, combo boxes.
Thats a solution to a different problem.

XForms probably won't help you in the immediate future. It will help a huge amount once everyone is using clients that understand XForms..... so 5 years time?

It Should

[The Monster]

does it run the GNU/Debian process?

It should. Seriously....

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.

To enable Web content developers to meet these challenges XForms will be designed to cleanly distinguish between form instance data, form description (called the em>XForms Model), and form presentation (called the XForms User Interface).

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.

Re:It Should

[Anonymous Coward]

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.

Brilliant! In fact, all we need is a standard way for an XML file to indicate which XForm should be used to edit it, in the same way there is a standard way to say which stylesheet should be used to present it, and we're up and running! Great idea!

Re:It Should

[Anonymous Coward]

Classic MacOS never needed anything like this, and arguably it was one of the easiest and most consistent UIs ever built. As a matter of fact even Unix already has the "consistent interface": it's called "text editor". Your idea, on the other hand, is just Windows influenced junk.

Re:It Should

[larry bagina]

his idea is overly-complicated, but almost every linux/unix config file is designed differently, and requires reading a manual page or HOWTO to get to the finer points.

I'd hope that kde and gnome provide a framework to help make loading/saving preferences easier. I know openstep/gnustep/macos x has property list (and xml) file support built in. Load and save your preferences in a consistent format that's easy to edit in a text editor, and provide a nice GUI screen if you want to.

Re:It Should

[FooBarWidget]

"I'd hope that kde and gnome provide a framework to help make loading/saving preferences easier."

*cough* GConf and KConfig *cough*

Geez people, why can't you keep up with GNOME and KDE development? They've had unified configuration systems for years.

Re:It Should

[FooBarWidget]

All (or at least, nearly all) desktop GUI apps already have a GUI for configuration. The apps that do not are commandline apps, and non-techies will not use them anyway. So the problem you describe is non-existant.

Re:It Should

[darylp]

Two separate unified configuration systems, that is.

This XForm configuration idea will be, thankfully, desktop agnostic.

Re:It Should

[FooBarWidget]

And why is being 2 separate config systems a problem? To the end user, there is no difference. He sees a GUI configuration dialog, clicks on a few things, and it works. He doesn't, and shouldn't have to care about implementation details.

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?

[Anonymous Coward]

To Uli's moose: you've succeeded at failing at whatever it is you failed at. Do I get a prize?

Re:Microsoft InfoPath?

[Zaiff Urgulbunger]

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

Like that lets you off the hook! ;)

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.

Is the Forms interface limited?

[pfafrich]

I've long suspected that there was something not quite right about the forms interface. Its always seemed a bit ugly. Not particullarly clever, and much worse than input choices you can get on standalone apps and games.

These are really just niggling fealing, somehow it could be better.

One particular niggle is the text box input. I want to do a web forum and I want to make it really easy to input quite rich text. I'm like the user to create rich content with italics, paragraphs, links, embedded pictures and tables. But my uses are a non technical crowd so html markup will not do!

I want an interface as easy as Word, no I want an interface as easy as a computer games six year olds can play.

But I don't want Flash, not easilly indexable. I have big misgiving about XML, somehow the XML stuff, XLink, XPath, XCSS, Xtc seems too complicated. HTML had a nice simplicity to it, XML just seems to have lost the elegance.

I also want a spell check button on the slashdot post comment page!

Re:Is the Forms interface limited?

[Bitsy Boffin]

You want HTMLArea - http://www.interactivetools.com/products/htmlarea/

Re:Is the Forms interface limited?

[illuin]

Yep, HTMLArea definitely rocks, but be warned that you'll have to dig a beta of it out of CVS, and then it will only run on Mozilla 1.4+ and IE6 (at least in my experience).

Of course, the fact that it's cross platform/browser at all is quite an accomplishment. Also, here is a whole list of other online WYSIWYG html editors.

just my 10 beer's

[azorka]

What's wrong with content-style-logic?
If /.' folk's cant get it perhaps you should leave the forum?

Re:just my 10 beer's

[jcast]

Nothing's wrong with content-style-logic. As long as doing things that way really is long-term easier for the problems people actually face.

I wonder how long it takes...

[AntiOrganic]

...for Internet Explorer to not implement it, and no one uses it.

Re:WTF? That name is already taken, try again.

[DrCode]

No kidding! When I first read the headline, I couldn't believe that something as dated and ugly as Xforms was being made a standard.

Re:WTF? That name is already taken, try again.

[pizen]

So I guess you're not fond of satellite radio?

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:This is big.

[Anonymous Coward]

Finally a comment that wasn't "Oh looky another convoluted standard I can't be bothered to understand but will bitch about anyway!"

Re:This is big.

[Tablizer]

You get hierarchical data, as opposed to the flat list of query parameters you have today.

What kind of hierarchies?

Re:This is big.

[Bitsy Boffin]

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

Nothing to stop you from doing this now.

document.getElementById('some_form').innerHTML += '<input type="file" name="file_' + n + '"/>';

using innerHTML cause I'm lazy, but you could use the DOM functions of course.

What I want to see though is the ability to STYLE file inputs, specifically the Browse button associate with said input. It is SOOOOOOOOOO annoying if you're designing a nice interface with iconic buttons or whatever floats yer boat to be landed with the crappy default Browse button on a fscking file upload !

Re:This is big.

[Anonymous Coward]

- You get hierarchical data, [...]
- You get to reuse your form handling code to service SOAP requests, too. Instantly.

Plus, by allowing tu submit using the PUT HTTP method, XForms greatly improves the REST Web Services style far more than it helps RPC-based (aka SOAP) based WS architectures.

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.

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:This is really a good thing

[Anonymous Coward]

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

Umm, no. HTML forms are exactly the right thing for what they were intended for at the time they were specified, before new-media wankers decided that HTML was de rigueur for "creating multimedia user interfaces for value-added mCommerce eFulfillment services!!!!1".
That is to say, XHTML 1.0 forms are so completely right that if you seem to find brokenness in them because of your particular form of design wankage, you're not using them right.

That is not to say that XForms might do something right as well; that XSLT thing you describe sounds pretty nice, for instance, apart from XSLT being far crazier in that bad, sinking feeling kind of way than CSS will ever be. Assuming that you aren't e.g. fetching something from out of a SQL database or anything otherwise complex that would require robust error management or other I/O type tasks. But I digress.

Referring to an earlier post (not yours, I suppose) about XForms' output having structure where vanilla forms didn't, I have to say I'm completely impressed by the apparent lack of understanding wrt what namespacing really means (or how arbitrary it is in the end) expressed in that single comment. How hard can it be to stick a bit more complex name fields in a form, perhaps add a hidden field for context, and then let a sewerside Perl script (or some such) do a sufficiently dynamic transformation on whatever CGI parameters and context it receives? It's not like XForms could be more expressive than plain HTML forms apart from things like lists of structures, which I don't know about not having studied the spec.
Like, damn! How hard can it be to actually think about what a NEW and IMPROVED specification really changes, instead of jumping all over it while wanking with complete abandon and impressive fury?

(this post was written before my second cup of $caffeinated_beverage, which I hope explains any bursts of incoherent rambling.)

Woohoo!

[Anonymous Coward]

More bloat! More redundancy! More broken web pages! More non-content! What's not to like about this?

Can contemporary browsers implement this?

[Tailhook]

Just wondering; with enough Javascript, could a contemporary browser implement XForms? My thinking is that a really hairy pile of XSLT could make your XHTML+Javascript do XForms.

XForms, as a replacement for "traditional" forms, while a good idea in theory, is a scary idea in practice because we all know we'll have to wait about half a decade for the implementations to catch up, and suffer all the bugs from half-baked implementations in the mean time. On the other hand, I've witnessed enough proprietary "form builder" and "form runtime" (think CICS, Oracle Forms 2.x and up, etc) systems to know that the world needs a generic, comprehensive starting point to build on. This wheel has been reinvented thousands of times already. Perhaps now it can stop. So as a general purpose forms mechanism, it's a great idea.

Hmm

[Julian Morrison]

Now maybe it's just me, but I suspect that this will have web designers gnashing their teeth like nothing else. You can't specify what the form looks like, just "this is a thing wherein you pick one from the following items". All your pixel perfect graphics will be garbled when you design with xforms and the browser takes it upon itself to render a picklist instead of a set of radio buttons, or some such.

This stuff is all solving an extremely transient problem (weak displays on phones and handhelds - you think they'll still be that bad in five years?) by making everyone else suffer.

Re:Hmm

[multi io]

(weak displays on phones and handhelds - you think they'll still be that bad in five years?)

Unless medical advances enable people to comfortably read font sizes of 1 mm (nobody wants huge displays on mobile phones) -- yes, I think they will.

And "conventional" displays will also be improved...

Re:WTF? That name is already taken, try again.

[6e7a]

XP is a bad version number and so is MX.

Am I the only person who noticed Micro$loth commandeer the eXtreme Programming buzz a few years ago? You gotta admit, it was pretty clever of them to steal a buzz, but it makes them seem even slimier to me. Now XP mean a version of Windoze and Agile Programming (AP) means testing, pair programming, and refactoring.

Re:Hmmmm..... InfoPath anyone?

[Zaiff Urgulbunger]

Its far bigger than just being able to manage clients. Since it allows automated validation, you could in fairly simple instances do away with much of the middle tier. I'll explain but start at the top...

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:

1. Modify the database schema
2. Update my documentaiton
3. Modify the web server script to create/update/delete the new field *AND* validate it!
4. Modify the HTML to include the new field
5. 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.

Re:Slashdot clearly doesn't care what the W3C thin

[henc]

Let's hope they stop thinking and start doing for a second. (Then they can get back to thinking...) h

Finally some people chiming in with support.

[Maul]

I'm looking forward to XForms, personally. They will add a whole new level of control for data input over the web. I think XForms have quite a bit of potential, if browsers begin to implement them, that is.

Question Is

[Bruha]

Will these new standards only be 100% compatible with Internet Exploder or will we finally have something that will be fully xBrowser?

I'm kinda tired of nitpicking webpages due to various "features" being handled differently.

Personally I'm tired of the Redmond HTML/Java standard and am ready for a Internet Standard.

Meh.

[sbwoodside]

I'm surprised to see this on /. I looked at XForms a while ago because I was writing an XML based server side forms system, and I could have used the Apache XML Cocoon support for XForms to do some stuff. The truth was that XForms just shifted some of the complexity to the browser, they didn't really add much that wasn't already possible, they just made it easier.

At this point I asked myself, will this be showing up in most browsers any time in the near future? I don't think so. There's no overriding need.

Compare: SVG. There's an overriding need, and it's coming fast.

simon

Before you mock Xforms...

[IGnatius T Foobar]

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

So, you decide. WinForms, on IE with .NET only? Or XForms, a W3C standard that will eventually get implemented everywhere? I know which ring I'm throwing my hat into.

Re:Before you mock Xforms...

[Anonymous Coward]

This is one of those nonsense posts which just make you want to go...

HUH!?

You know it's time to start another project...

[Anonymous Coward]

...the moment someone steals the name of yours (XForms) to use it for another thing, probably thinking "Hah! Ill bet noone will remember the original."

Yippee we can write a hierarchical parser too!

[tjstork]

XSLT is barely comprehensible as a language, and XFORMS in conjunction with that is completely absurd. Every X that the W3C comes out with and argues against HTML makes me think they should have quit the X's and just gracefully extended the original HTML

Re:Yippee we can write a hierarchical parser too!

[tupshin]

Just because XSLT is a declarative language doesn't make it incomprehensible. Just different.

Making a clean break from HTML was the best thing they could have done. It was a broken dead-end.

-Tupshin

Re:Yippee we can write a hierarchical parser too!

[Mybrid]

As Socrates once quipped, "the unXamined life isn't worth living."
Let's examine the life of HTML. HTML has a distinct advantage over any XML derivative: it is human readable and understandable. Children can learn HTML . The popularity of the WEB is in huge part due to the accessiblity of HTML by a huge audience that is far, far larger than just professional programmers. Quite the opposite for XML.

I argue XML is a broken dead-end.
1.) XML is not readable by any audience other than computer professionals.
2.) Since XML is for computer professionals then then it begs the question: does it fit that audience? I argue it is too cumbersome and verbose and therefore an eventual dead-end. Why do I need to see <phone> 655-7970 </phone> everytime? Just give me the schema and a tab delimited file of records that fit the schema?

If the idea is to give greater flexibility for document presentation, you'll want a PDF format or a fully compliant SGML implementation via a TOOL that doesn't require you to understand the SGML or PDF language itself. When was the last time you interacted and editted PDF directly? Why should you?
The only person who needs to understand the SGML or PDF is the developer of the TOOL.

Why don't we replace XML with Postscript? Especially if I'm dealing indirectly with the language via some tool. After all Postcript is Turing complete and can excercise the full capability of the CPU and machine, something XML is not.

Re:Yippee we can write a hierarchical parser too!

[tupshin]

1.) XML is not readable by any audience other than computer professionals.

Dialects of XML (including XHTML) are just as readable as older style HTML.

2.) Since XML is for computer professionals then then it begs the question: does it fit that audience? I argue it is too cumbersome and verbose and therefore an eventual dead-end. Why do I need to see 655-7970 everytime? Just give me the schema and a tab delimited file of records that fit the schema?

Tab delimited files are horrible at representing hierarchical relationships, and XML is much more human readable (which is a benefit to developers) than multiple tab-delimited files.

If the idea is to give greater flexibility for document presentation, you'll want a PDF format or a fully compliant SGML implementation

That is just one of many uses that xml is put to. XML, by definition, is an extensible markup language. Some XML dialects are used for presentation, but not all, or even most.

Why don't we replace XML with Postscript?

I'm hoping this is a troll. Have you tried representing semantic information with hierarchical relationships in postscript? Certainly you can, but it's not necessarily easier in postscript than in any other programming language such a C, Perl, or LISP. In contrast, it is intuitively obvious in XML.

-Tupshin

Re:Yippee we can write a hierarchical parser too!

[Mybrid]

Excellent responses. Thanks!
1.) Dialects of XML (including XHTML) are just as readable as older style HTML.

This can be said of ANY language if the dialect is a small enough subset. However, XHTML doesn't allow for mistakes. For example, what if I have a start tag but no end? Something a human might do but XML doesn't tolerate. One can argue that HTML is plagued with malformed HTML, but the flip side is that make its more accessible to humans. HTML is forwards compatible, undefined tags are ignored. Try that in XHTML.

1.) Tab delimted files are horrible are representing hiearchical relationships.

Tab delimited files don't represent any relationship. It's just a container for data represented in a text format. The relationship is seperate from the data itself, where it should be. The relationship is stored in a schema somewhere. This points to a problem with XML data, the schema, or parts of it, is shipped with every record in the form of markup. Even tab delimited files are inefficient because if an integer is one byte, effeciency would dictate it is laughable to ship one byte of data represented as ASCII text where the integer 10000 takes 5 bytes instead of only one. If efficiency for data is desired, then binary representation is the only choice.

1.) I'm hoping this is a Troll.
Not at all. There are two disparate tasks XML claims to integrate that are a.) semantic schema information of data and b.) presentation formating. XML markup of the data itself is inefficient for delivering mass quantities of data if you just consider the binary->text coversion and disregard markup. With regards to layout, fonts, borders and presentations, Postscript is much richer.

Cheers!
-Mybrid

'Proposed Recommendation', Eh?

[dupper]

So, where can I fill out the forms to get the form to propose the possible consideration of suggesting the addition of my own protocol as an optional addition to a protoype candidate to be evaluated as a further proposed possible recommendation to the new standard?

Re:WTF? That name is already taken, try again.

[bwt]

Too late. The final call for modifications to the XForms proposal has passed. The GUI kit project should change its name, since it is a non-compliant implementation its own namesake. Or they can do nothing and confuse the crap out of everybody.

The Firebird RDBMS folks screamed loud, early, and often at the name collision. This standard has been around for YEARS, so it's a little late to play the change your name game.

Re:WTF? That name is already taken, try again.

[__past__]

Interviewer: "What do you think will be the biggest problem in computing in the 90s?"
Paul Boutin: "There are only 17,000 three-letter acronyms."

OK, so XForms is not really a TLA (and there are of course more than 17,000 of them, more like 17,576 assuming the basic 26-letter latin alphabet). But it's also not the 90s anymore, so get over it.

XSLT

[Tomster]

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

Wow... is there an XSLT that will convert that link-and-acronym-infested paragraph to English? :)

-Thomas

Forms competitors

[Tablizer]

Competitors include:

XWT

XUL

SCGUI (my pet)

Ahh, the plug-in

[Enrico Pulatzo]

<nosarcasm>This is a truly great use of the plug-in.</nosarcasm>
If this keeps up, more specs might be produced before finding their ways into the core codes of the top browsers. I mean, seriously, did IE 5 need that xslt engine?

how practical

[skryche]

A new W3C standard? Great! We should have it running in Mozilla in about two years, and it'll be standard web practice by, say, 2009.

(see also: SVG)

Re:how practical

[KjetilK]

BTW, the Bugzilla bug is 97806, go have a look (there's no use linking, Bugzilla blocks /. referrals.)

we NEED something

[Tablizer]

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.

Re:WTF? That name is already taken, try again.

[tirenours]

It is obviously an attempt to attract the younger generation. 'X' is a cool letter: just think X-Men, LXG, etc. It is a symbol that means "hi-tech", the future. Same thing for MacOS X.

IN SOVIET RUSSIA

[Anonymous Coward]

...baths take you

More XML Forms Competitors @ XUL Alliance Site

[Anonymous Coward]

I've collected more than a dozen open-source XUL (XML UI Language) motors/browser/runtimes such as XWT, Luxor, Swix, XUI, Axualize, KoalaML, JellySWT and many more at the XUL Alliance site @ http://xul.sourceforge.net that let you build UIs using XML.

Also note that XUL and XForms don't really compete but complement each other. To put it simply XUL will include XForms. XForms in a way is say like Texas is to the United States or Quebec is to Canada.

To get more technical: XForms is a databinding architecture (XML in, XML out) that needs a hosting language such as classic (X)HTML or modern XUL.

Unfortunately, the W3C suffers from the not invented here (NIH) syndrom and reinvents the wheels and pushes only its own spec. Thus, XForms needs a little clean-up to fit into the XUL architecture.

Grid control?

[Tablizer]

My GUI forms systems I have tried had lousy grid widgets (a table or spreadsheet-like thingy in which you can edit the cells and scroll around.)Whatever standard takes off, make sure it has a decent grid widget. For example, in one you had to press Enter on the last entry you did to make sure it "took". That flaw alone would probably generate a 100 support calls and grey hair. Microsoft products are the only ones with half-way decent grids, I am sorry to say (as long as they don't crash).

Re:bleh.-Alternative timeline.

[Anonymous Coward]

" Maybe I'm just becoming old before my time, but I don't see how any of these recommendations, or any advancement to the web in the past 10 years has improved it."

Or maybe a certain company (name withheld to protect the guilty) decided to barely follow the standards, and break it in other ways, so the web that we should have had ten years ago, hasn't arisen yet.

When we can get everyone on the same page then you'll be, at the very least, pleasently surprised.

yah yah

[Anonymous Coward]

[something about microsoft] hahahahahaa!!!!! w3 r l33t!!

So much noise, so little signal-Nutshell books.

[Anonymous Coward]

"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'll wait till the O'Reilly book comes out.

Re:WTF? That name is already taken, try again.

[FatRatBastard]

I always liked the urban legend that XP was Chi-Roe (Cairo, the old internal project name)

Finally, web forms are getting fixed!

[illuin]

There seem to be an enormous number of people saying that this XForms is a waste of effort and complexity; that it won't be used. I find it hard to believe that any of you have written a web application with non-trivial form-database interaction.

Forms for tasks such as editing data that contains one-to-many relations involving several tables while supporting data validation before commiting is absolutely disgusting with html's current incantation of forms. I cannot wait to have live xml objects backing forms with features like group-repeats and integrated data validation. Bring on the XForms, even if the XML is a bit complicated, at least it looks well designed and it's going to be a whole lot better thought out and implemented by than whatever most of us would cobble together.

Re:Finally, web forms are getting fixed!

[Mybrid]

Mmm, some companies have different application clients. Business logic can arguably be done in the database itself or in a middle tier share by all clients.
A non-trivial database form interaction that I've written sends all the raw strings from the posted HTML input back to the database with no client business logic. The server post scripts simply marshalls the user input into the database call. This has a couple of advantages:
1.) Client simply collects user input and passes it to the database.
2.) Business logic is owned by the database.
3.) Thin client such as handheld devices and telephony applications can share the same business logic.
4.) Data validation happens where it has too anyway -- in the database (PL/SQL code).

Of course this requires a round-trip to the server so some very simple checking for obvious stuff is done in Javascript on the client.

Finally, if your editing serveral tables on one form one questions the design of your application.
Does your user understand it?

A WebBrowser and HTML forms should not be used for complex data sets as this was never the intent. Something with application triggers would be more suitable; a 4 GL form language like Power Builder suitable to the task should be used.

Take a tip from Albert Einstein, "Make something as simple as possible, but no simpler."

Re:Finally, web forms are getting fixed!

[dukoids]

Well I am actually working on stuff like this. My biggest problem is: How to let the user select from a large list efficiently (thousands of entries) without sending all the content to the client? does xform support tree selection elements where the content is requested from the server on demand?

Re:Finally, web forms are getting fixed!

[Mybrid]

Hi! Mmm, something as complex as this cries out for a usability study and task analysis. Are all entries equally likely to be selected? One of the things that annoys me with many web sites that want your address is that "USA" is alphabetized as a country selection then it ends up at the bottom of hundreds of entries. Make the common case fast as they say. If 90% of the time "USA" is selected then
1.) USA should be the default and
2.) It should be at the top of the list.
Only you know the tasks your users are performing. Odds are the 80/20 rule applies where 80% of the time only 20% of the possibilities are used. The 20% should then be at the top so to speak.

But without further context, its hard to say what the solution is to this.

Cheers!
-Mybrid

This makes the "THIN" client big

[Baki]

What is transmitted, in the end, is a byte stream (over HTTP over TCP), so what is so big here?

The only thing this changes is make the browser (once thought to be a THIN client) more complex yet again. Conceptually, a form is flat: it submits a number of key-value pairs. Putting this flat data in more interesting data structures (whether hierarcical + XML or something else) is a server side thing, the THIN client should not be bothered with it IMHO.

What do they want? Cut out the middle tier so that the browser becomes a very heavy component that can directly call web services and the whole world? So that it shall become practically impossible to ever implement a browser from scratch again? Plans like these make me feel sick.

Re:bleh.-Alternative timeline.

[garethjrowlands]

HTTP 1.1 is a big improvement over HTTP 1.0. That's progress. And CSS is a big step forward too. That's progress too.

Obligatory Futurama Reference

[LPetrazickis]

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.

Bender: Blackmail is just an ugly word. I prefer "extortion." The "X" makes it sound cool.

You do not know sh.....

[ratfynk]

He is right, the standard forms that MS is going to use are .NET Visual Studio extentions. You will not be doing simple html forms in notepad any more. CSS will go away in the MS interpretation of the net. The reason why is MS office will be able to use WinForms directly with the required hooks to your spread sheet or your document. Just think it will be so efficient all you have to do is buy MS Windows, Office, and keep it secure yourself, buy more software to protect you against crackers, and update your system. Then you can do business on the net. Without that you will not be able to exist. W3C standards are something which MS just laughs at, the last thing they want is standards for web forms. Of course the very fact that you have to shut the fucking things off so that you can use Win XP without spending half your time clicking at all the stupid MS .NET web forms that popup is a little annoying, and is pissing off alot of business people. Mozilla rules! MS sucks.

Mozilla Suport

[Palin]

Mozilla Bug for XForms Support

Favorite comment

JSP, XML, XSLT, XML, CSS and NOW XFORMS?

[Mybrid]

The current state of affairs is that most Web App servers rely on JSP's. Are we going to embed XForms in JSP's? IBM's WebSphere can not serve up raw XML and convert it to HTML due to performance issues if your web site has any real traffic. Precompiled JSP's are the only game in town. What if the precompiled JSP has XML/XForm?

XML is still not delivered to browsers in general -- we still rely on HTML converted from JSP/XML on the server. Introducing XForms is putting the cart before the horse. XML should be the lingua franca for serving up web content before building even more on top of it.We haven't learned how to walk with delivering native XML to the browser to spend any energy on yet another extension of XML.

Finally, we all know Microsoft extends everything.
Given they own 90% of the browser market you can't claim anything till Monopoly State weights in. This is just a headache waiting to happen.

Re:WTF? That name is already taken, try again.

[a_n_d_e_r_s]

Like Micrsosoft Windows XP ? Direct X ? Active/X

Re:WTF? That name is already taken, try again.

[Anonymous Coward]

It often seems like these Web/XML/Java etc. oriented people consider anything that is not either mainstream or strongly hyped marginal enough to be irrelevant.

They should consider that they want to attract, not marginalize, people who have been around long and are knowledgeable in things beyond the mainstream.

Re:WTF? That name is already taken, try again.

[Anonymous Coward]

Except for the fact that Fire is an IM on the Mac.

Fire is when something burns. GET A LIFE !!!!!!!!!!!!1111111 ;-)

Great

[Anonymous Coward]

The next W3C standard we wont be able to use because Microsoft will not implement it.

Re:WTF? That name is already taken, try again.

[kybosh]

MacOS uses X as in the Roman numeral - so it's a little less stupid than the rest.

One question

[tietokone-olmi]

Have you ever tried parsing XML in order to read in one piddly little fucking config file? Even if you have something like libxml around to do the parsing for you, you'll still have to crawl around in the fucking parse tree, comparing and checking and generally getting it in the bottom from a construction that can and will feed almost any old semi-structured garbage down to the application.

Sure, you can do quick and dirty hacks, like discarding invalid structure etc, but in the end that'll work far worse than plain old comma-separated or RFCwossname ("Field: value\n" thing, you know) config files.

Of course, all this could be solved in yet another gigantic configuration file committee who would drop an equally Golgothan pile of specification out of their collective arses, the first implementation of which would be in a wanker language such as Javur or PHP that, besides being ENIAC-style unwieldy, would thus remain inaccessible to the bulk of software written for GNU/Linux and compatible systems. WHEE!

Still, all this is beside the point. Making things more idiot-proof is not, was not and will never be the answer to "how can we make GNU/Linux more attractive to complete mouth-breathing, tie-wearing wankers?". Idiots are far too ingenious to fall for that old trick.

Config files don't have to change, just middleware

[The Monster]

Have you ever tried parsing XML in order to read in one piddly little fucking config file?

I didn't say to make the config file be in XML. I said to make the Model be in XForms, so that a consistent front end can be used for everything. You can still have your config file with colon-delimited fields in linefeed-delimited records, or linefeed-delimited fields in double-linefeed-delimited record, or whatever you want. Existing config tools that use sed / grep / awk / perl / ruby / python / <your favorite scripting language here> just keep working the way they already do

The XML is a metaconfiguration file, which tells the front end how to deal with the config file for the application, so that it is not necessary to write a GUI front end for everything, and have users learn how to interact with each one's peculiarities. You just write the Model that describes the form, and backend code that manipulates the config file into the right format.

It bears repeating, but XML is not really a document storage format; it's a document interchange format. That Open Office uses gzipped XML indicates they're more interested in the interchange than the storage; I tend to agree with them on this. I'm talking about using XForms to facilitate the interchange between the user and the program configuration.

Old hat

[fasura]

Not all the world uses MSIE 800x600 24 bit monitors

Oh damm, now someone tells me. I'be been designing everything for 1600x1200, and 32 bit colour.

Actually I like this idea and hope it works well, forms have been bugging me for ages. Too limted.

Re:WTF? That name is already taken, try again.

[Grizzlysmit]

Just change it to XFormsML then that'll do a better job at namespacing it anyway.

Bzzt -- try again. InfoPath falls short.

[Anonymous Coward]

>found it to be a tool which was intuitive, powerful, easy to use, and standards-compliant.

Consider that InfoPath only works with IE/Outlook, and can only be served from IIS+Front Page Extensions.

It's actually based on IE 6, plus lots of undocumented extensions. It is nearly impossible to programatically create InfoPath forms. The only way to create InfoPath documents to do drag-n-drop exercises.

It's purely a client-side solution, so unless you trust that 12-year-old script kiddies aren't telnetting into your server, you'll need to re-write all of the validations for the server.

All InfoPath layout is table based--the kind of thing that accessibility guides consider the cardinal sin. Non-visual users will have a terrible time navigating through InfoPath forms.

Severe platform lock-in: InfoPath only runs where IE 6 runs. No .NET CLR, no Mac, no Linux obviously, no Win CE, not even conventional paper form compatibility.

Finally, It only comes with the most expensive (subscription-based) version of Microsoft Office. The full product is required to either design, or fill forms. No support for ordinary browsers.

I'd say XForms looks pretty good on multiple levels...

Re:WTF? That name is already taken, try again.

[JamMasterJGorilla]

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.

Actually, the correct ebonics pronunciation key would be asktensible

Re:WTF? That name is already taken, try again.

[jonadab]

> Now XP mean a version of Windoze and Agile Programming (AP)

Err, I hate to disappoint you, but AP is Associated Press, the
source of three quarters of the stories in your local newspaper.
(The other quarter are non-news items included as an excuse to
get photos of local people's grandkids on the front page so
they'll buy twenty copies of the paper for all their friends
and relatives. Yes, I'm cynical about newspapers.)

I tend to agree that X has been overused in acronyms during the
last few years. Still, that's better than prepending random
vowells or possessive personal pronouns to otherwise normal words
to create brand names. (Oooh, did I step on the toes of a popular
database there? Oopse.)

As far as names being _taken_, the only way to avoid that is
to coin an entirely new word, or select one so obscure that
nobody would want it as a brand name. I favor the former
approach. I like "Fortran" as a name for a language, and
"Perl" isn't altogether bad too[1]. Of all the ones that start
with X, I like "XUL" best, for two reasons: it's actually
pronounceable, and the page served up if you try to access the
URL used in the namespace declaration made me ROFL for several
moments. (Hint: picture a certain android being possessed by
a ghost from his refrigerator... somebody has a seriously
weird sense of humor.)

[1] I'm talking about names here; if I were talking about
the languages I'd be much more enthusiastic about Perl.

I wonder if it will support...

[Trogre]

... textarea elements that actually let you limit the number of characters.

It's a pain having to code up a javascript hack just to prevent some silly person resting a teacup on the '0' key and causing a buffer overflow.

Re:WTF? That name is already taken, try again.

[minister of funk]

Honestly, there is some debate in the Ebonics Literary Community about the proper pronunciation and transliteration to English of the English word "extensible". Your assertion that it is pronounced "asktensible" is the point of view held largely by the East Coast Scholars (ECS), while the transliteration "akstensible," reigns supreme with the West Coast Scholars, who also maintain that members of the ECS are falling prey to "The Man" as evident in their language suggestions.

There is also a fringe group that is championing "akstensibizzle".

ASP.NET to the rescue

[Anonymous Coward]

it takes care of all that repopulating the form bullshit with zero coding... nice.

it will keep web developers employed

[Anonymous Coward]

at least the good ones... With all the advanced web building tools available, it's becoming easier and easier for junior level hackers to produce decent web applications. This encroaches on my position as a senior level developer, and drives salaries down.

With the coming of XForms, that's another new technology that I can become an expert at and keep commanding a high salary. The juniors will take longer to get up to speed as they have to wait for the tools to mature to enable point-and-click XForms builders.

nforms

[Anonymous Coward]

http://www.ripcord.co.nz/

This is an xforms implementation that works zero-deployment using xslt's and javascript.