XForms is replacing the forms part of XHTML, which in turn, is replacing HTML.
XHTML is mostly a cleaned-up version of HTML. It is not a rewrite of HTML. It is just a bit of fine-tuning and a few changes to bring HTML into alignment with some basic rules of XML, and their implications.
XForms is a rewrite.
However, XForms does not replace all of XHTML – just part of it. Only the part that has to do with forms and GUI controls.
That part of HTML kind of sucks, so it is no great loss. There is not much to miss (or love) that goes away.
HTML form controls were based on the GUI components that were around in the early 1980s. They were designed to work in the same way that dumb terminal forms worked on ancient mainframes back in the 1960s and early 1970s, except you could use a mouse. Wow.
XForms form controls on the other hand are pretty sexy, work much nicer on the page, and are easier for developers to define/update than their HTML predecessors.
To make a gross generalization, HTML forced designers to pick which of a limited set of crude/simple GUI controls to use to display and allow editing of each piece of data. In XForms, it is all much easier than that.
In HTML 1, 2, 3.2, 4, 4.01, and XHTML 1 and 1.1, data-checking (validation) of user input/commands had to be done on the server using custom logic for each different form. Any local checking or smart defaulting (or context-driven hiding/disabling) of control values would have to be programmed separately, in a completely different programming language – JavaScript.
In XForms, which can be used standalone, in XHTML pages, and/or in conjunction with other neat things like SVG and CSS, developers do not have to specify certain controls for capturing certain field values.
Instead, they just allude to a piece of data and describe the data and what it is – a free text field, a choice of several different values, a range of numbers – that sort of thing. It is really simple.
The XForms-capable browser does the thinking of what controls to use to display/edit the field. If it has a slider, it uses it. If not, it lets the user pick the number and verifies it is in range.
Things like a slider, hot tips or tooltips or hover tips, range-checking, value-matching, etc. – no longer require writing any custom JavaScript. It is automatically handled by the browser.
The developer simply supplies an XSD (W3 XML Schema) definition of the valid data, the browser uses that to make its choices and enforce those decisions.
Developers can write the XSD by hand, generate it from their object and/or persistence model, write it in RELAX NG and tell Trang to translate it into the more tedious XSD format, or simply get someone else to do it. Each of these can be the “best choice” for someone.
On the server side, they can revalidate the data against the XSD, which obviously they have. They can write special checks if they need to do so. Often, it will be unnecessary to write any programming to do these checks – they would simply duplicate the rules the XSD is already able to enforce.
The data is transfered from the XForms client (i.e. browser) to the web server in XML format. These makes it easy to update the data model directly, since object-oriented programming languages already have multiple 3rd-party libraries that can do this.
Dealing with XML, which can easily be schema-validated and deserialized back into objects, that is received from a client application is simple.
Likewise, serializing Java (or whatever) objects to XML is totally simple. Numerous packages, including a built-in Java class, can do this. A programmer/architect simply has to pick which one to use in his particular web application.
So if it is that easy, what does a programmer have to do then?
Design objects for each major entity in their system, a simple object structure for how things fit together, decide which subset of the overall structure is needed in the context of each command, and decide what commands the application needs to have and what data-entry/searching/updating/deltion/action forms the application needs to have.
Same things as before. Just far fewer of them. And, thanks to the cleanness of the XForms data formats, many of these remaining tasks can be automated with code generators,
Even test data can be automatically generated from a schema. Free, open source class libraries to do that in Java have existed for years.
The job of the analyst is not diminished, they can simply expect to get more software that implements their idea/vision faster.
The power/ability of the web page designer is not diminished, they are simply burdened with less requirements to deal with minutia and data/constraints/scripts. They can instead focus on what they are good at – making the page look beautiful with great artwork and CSS rules.
The workload of and demands upon the programmer go down too with XForms. The boring mundane stuff he had to do with HTML forms goes away. He can focus on matching up objects to forms.
The XSD file can handle the data validation needs. Often, the programmer will not even create the XSD for a page, someone else will do create it and test it.
Programmers can be less involved in “programming” data entry forms. Instead, they will be mostly/completely freed of that responsibility and can focus on correctly implementing the commands that are specified in the business purpose of the application:
- total monthly journal entries, balance the books, post to General Ledger
- send high-priority email to physician with subject “dangerously high levels of XYZ in patient Joe Sickly” and relevant lab results in the body of the email, with the full test results included in a formatted document as an attachment
- invoke ruleset for suggesting patient diagnosis based on symptoms presented, demographics, current infection-control context, and so forth
- invoke XML to PDF report generator
- run the monthly accounts receivable reports and sent out bills and late notices
- run the monthly accounts payable reports and print checks and prompt operator to verify they printed successfully
- generate a dashboard page for web-based DSS so executives can have an at-a-glance view of their overall business
A lot of calculations will be taken out of the hands of run-of-the-mill application programmers. Most programmers will just call “glue logic” that someone else tells them to call, use templates someone else hands them, allude to rulesets and persistence definitions that someone else supplies them. Plus, integration test and debug – or refer problems to those who wrote the work-products that seem to be failing so they can rerun their own unit tests and integration steps.
Eighty percent of applications programming is tedious, repetitious, redundant, but necessary drudgery.
Eighty percent of that programming can go away, simply by replacing HTML forms with XForms.
Guess what companies are going to do?
