Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
The Internet Programming IT Technology

XForms Becomes Proposed Recommendation 247

Posted by michael from the xml-for-everyone-whether-they-like-it-or-not dept.
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."
This discussion has been archived. No new comments can be posted.

XForms Becomes Proposed Recommendation More

XForms Becomes Proposed Recommendation

Comments Filter:

  • in a nutshell... (Score:4, Funny)

    by selderrr ( 523988 ) on Friday August 01, 2003 @05:43PM (#6592487) Journal
    xforms is fully buzzword compliant and serves as an excellent tool for dumb managers to wank with.

  • WTF? That name is already taken, try again. (Score:5, Informative)

    by Dr. Zowie ( 109983 ) * <slashdot&deforest,org> on Friday August 01, 2003 @05:46PM (#6592514)
    Jesus Christ, doesn't anyone look out for name collisions anymore? XForms is a GUI toolkit for X. [std.com], in (slow) development since 1995 and still used in many useful apps like GeomView [geomview.org] and Lyx [lyx.org].

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

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

    Feh.

  • So many links (Score:4, Funny)

    by Anonymous Coward on Friday August 01, 2003 @05:46PM (#6592515)
    After all that, I think Bender summed it up best:

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

  • Thank god. (Score:4, Interesting)

    by Duncan3 ( 10537 ) on Friday August 01, 2003 @05:46PM (#6592519) Homepage
    I was having a ton of trouble teaching people how to use <form> and <input>. 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. (Score:5, Informative)

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

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

      • Re:Thank god. (Score:4, Insightful)

        by dasunt ( 249686 ) on Friday August 01, 2003 @09:51PM (#6593708)

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

        • 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. (Score:5, Interesting)

          by whereiswaldo ( 459052 ) on Friday August 01, 2003 @11:03PM (#6593965) Journal
          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. (Score:3, Informative)

            by whereiswaldo ( 459052 )
            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 mo

  • Key Feature (Score:5, Funny)

    by billstr78 ( 535271 ) on Friday August 01, 2003 @05:47PM (#6592521) Homepage
    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!
  • What next? Motif for the WWW?

    Maybe they should have used a different name ...
  • I'm interested in how this will change the way things work now. Anybody want to explain?

    -Erwos

    • 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 b

    • 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

    • Re:How will this change things? (Score:4, Informative)

      by bwt ( 68845 ) on Friday August 01, 2003 @09:41PM (#6593662)

      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)

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

  • Not again... (Score:4, Insightful)

    by JessLeah ( 625838 ) on Friday August 01, 2003 @05:51PM (#6592544)
    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... (Score:2, Insightful)

      by ocelotbob ( 173602 )
      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

      • 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 t

      • 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
        • 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.
          • 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... (Score:2, Informative)

      by porter235 ( 413926 )
      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-sh i t that happend during the browser wars and is a

      • Re:Not again... (Score:3, Insightful)

        by __past__ ( 542467 )

        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 w

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

  • an open letter to w3c (Score:5, Insightful)

    by joe_bruin ( 266648 ) on Friday August 01, 2003 @06:02PM (#6592611) Homepage Journal
    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 (Score:4, Insightful)

      by Khomar ( 529552 ) on Friday August 01, 2003 @06:13PM (#6592681) Journal

      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.

      • 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 effec

    • Re:an open letter to w3c (Score:4, Interesting)

      by irritating environme ( 529534 ) on Friday August 01, 2003 @06:17PM (#6592704)
      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.


    • Isn't that carrying alliteration a little too far?

      (Hint: say it aloud.)

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

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

    • we NEED something (Score:2, Interesting)

      by Tablizer ( 95088 )
      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
    • 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

  • Minor correction (Score:2, Informative)

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

  • CSS for device independence? (Score:3, Funny)

    by irritating environme ( 529534 ) on Friday August 01, 2003 @06:13PM (#6592677)
    Huh?

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

    Huh?

    Craptastic.

  • independencence? (Score:5, Funny)

    by renard ( 94190 ) on Friday August 01, 2003 @06:18PM (#6592712)
    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...

  • 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: (Score:3, Interesting)

    by RoLi ( 141856 ) on Friday August 01, 2003 @06:25PM (#6592745)
    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.)

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

  • 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 [w3.org]. As far as I know, there's still no way, and no one has produced any sensible response to this problem.
    • 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
    • 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.
  • 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 any
  • 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.
    • 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
  • 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.

  • Microsoft InfoPath? (Score:5, Insightful)

    by moosesocks ( 264553 ) on Friday August 01, 2003 @06:48PM (#6592898) Homepage
    While Xforms is great and all M$ already (almost) has a production-ready implementation of their own new form standard in InfoPath [microsoft.com], 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? (Score:3, Insightful)

      by Nevyn ( 5505 )
      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.

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

  • This is big. (Score:5, Informative)

    by CYwo1f ( 166549 ) on Friday August 01, 2003 @07:10PM (#6593029) Homepage
    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.

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

    • 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 br

  • So much noise, so little signal (Score:3, Insightful)

    by Anonymous Coward on Friday August 01, 2003 @07:15PM (#6593058)
    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 (Score:5, Informative)

    by duncanFrance ( 140184 ) on Friday August 01, 2003 @07:16PM (#6593066)
    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.

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

  • Before you mock Xforms... (Score:3, Interesting)

    by IGnatius T Foobar ( 4328 ) on Friday August 01, 2003 @08:39PM (#6593453) Homepage Journal
    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.

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

  • XSLT (Score:2)

    by Tomster ( 5075 )
    "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, an
  • <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?
  • 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 [w3.org])

Slashdot Top Deals

Never tell people how to do things. Tell them WHAT to do and they will surprise you with their ingenuity. -- Gen. George S. Patton, Jr.

Close