''XformsTechnology is MVC - in other words, Xforms are applications in their own right. Is it reasonable to believe that XForms backed by BPMSes are about to replace most procedural languages for enterprise computing?''

XForms (''see'' http://www.w3schools.com/xforms/) do seem to be an improvement over ordinary HTML forms, but the question heading this page seems to hint that XForms and BPMSes are going to eat the world.  Is there something I'm missing here?  And BPMSes, or Business Process Management Systems (eg., the "Rules-Driven BRMS" made by http://www.rulespower.com) seem on first read to be yet another attempt at creating an all-in-one push-the-Go-button software generator.  Am I missing a genuine revolution here?  Or is this simply another buzzword-compliant evolutionary step in the same old direction?  Colour me "skeptical but open-minded."  I'd like to see more evidence before agreeing that this is one of two technologies that are going to "replace most procedural languages for enterprise computing."

''BlubParadox is definitely an AntiPattern.''

Are you implying that I'm "looking up," BlubParadox-wise, at XForms and BPMSes?  Perhaps, but I'd like to think it's healthy skepticism combined with the simple recognition that there is NoSilverBullet.  Actually, I'm quite open minded about XformsApplications, but simply want to see evidence of their value.

''Xforms are pretty new - XFormFaces, the free backward-browser-compatible player - only came out a couple months back. I know of no enterprise developments using 'em yet - though google has some. I'm asking a question based on the idea that most MVC patterns aren't programming any more - they're copy and paste. Ergo, stick 'em in the database where you can operate on 'em without having to retest, etc, just because someone wants a grid instead of a bunch of pulldowns, or euros rather than yuans, or whatever validation/behavioural trivia the business user thinks up next.''

''This is revolutionary because it means the only things a real programmer would be needed for are (a) really complex business domain logic, (b) scalability issues, and (c) database/dataspace schemata supporing BPMSes. The rest can be authored by a technically unskilled BA or low-paid Bangalorean outsourcer.''

When you write that "[t]he rest can be authored by a [non-programmer]," what do you mean by "the rest?"  Client-side and user interface behaviour, i.e. the functionality that XForms is intended to facilitate?  Do you have any statistics on what percentage of business application space belongs to client-side and user interface behaviour (assuming that is the "non-programmer" part) vs. the percentage that will still require a real programmer?

''No, I don't have any stats. But most business apps I've been involved in are extremely data-centric, and the ones that have taken to BPM wholeheartedly have scarcely any procedural logic left in the middle - just validation/workflow rules engines and the odd bit of web-service glue. I guess these odds and sods - the framework within which the app is developed - are still targets for enterprise architects and RealProgrammer'''''s. But "the rest"  - the guts of the app - its business-oriented behaviours, appearance, and contents - are where the XForms play.''

On XformsTechnology, a statistic of 80% was tossed about.  Or does that not apply here?  And if it does, where did it come from?

''It was grabbed from MicahDubinko at http://www.xml.com/pub/a/2001/09/05/xforms.html : "The goal of XForms is to provide the 20% of necessary functionality to eliminate 80% of the need for scripting." Based on my somewhat limited experience I'd back that. Stats on my question here though - I got none. --PeterMerel''

The combination of XForms and BPMSes strike me, at least in philosophy, as somewhat similar to business-oriented CASE tools of the late 80's and early 90's, workflow tools of the early to mid 90's, and for XForms at least, the capabilities easily available in fat-client forms like those in Visual Basic Classic and .NET, MS Access, Powerbuilder, Delphi, Oracle Forms, and that gaggle of long forgotten business-oriented CASE tools.  Or am I missing something here?

This brings me in a roundabout way back to the original question.  Is it reasonable to believe that XForms backed by BPMSes are about to replace most procedural languages for enterprise computing?  I'd have to say no, or at least no more than forms painters and clunky CASE tools did when fat-client development was de rigueur.  Is it perhaps more reasonable to believe that XForms will, at best, make it easier to finally catch up to the mid-90's in terms of forms and form painter sophistication for Browser-based client development?

Or, again, am I missing something here?

''I think so but then again it might be me. While I agree that AllPanaceasBecomePoison and SpecificationIsNotSolution - at least that's the flavour I'm getting from you I'd like to agree with - I think the point here is to push app and business logic as low down the tier-totem-pole as possible so they can be varied without programmer coding or ProgrammerTest''''''ing. This seems to me a good and powerful idea outside the CultOfCommoditization.'' --Pete.