Re: Proposal for Extensions to HTML4

Contrary to popular opinion, I plan on using XForms on the Web, and I
suspect that many others like me, who are business application developers,
will embrace XForms because it satisfies their need to build applications
for the Web. There is a large pent up demand for
converting/migrating/transforming client/server applications to a browser
based interface, but that is a daunting prospect for a lot of developers
because it is so difficult to build HTML forms that live up to the
programming rigor that is prevalent in the traditional environments.

I think you have a narrow view of forms, because up until XForms it
required a herculean effort to build complex applications with HTML forms
and so there are very few examples of them out there. This proposal does
not satisfy my needs and is nothing more than a band-aid to the flawed
(from an application developers standpoint) functionality of HTML forms.

The separation of presentation from content is such a fundamental piece of
good application development that it should not be underestimated and is
vitally important to be able to scale the engineering effort. With XForms,
the server components can concentrate on data and downstream business
logic. It does not have to concern itself with presentation and various
controls. If the UI needs to change to reflect a different order of fields,
the server component does not have to be changed.

This proposal makes the assumption that XForms is hard for authors to
understand, that it is hard to grasp XML and some new tags, and yet are
able to easily comprehend ECMAScript, DOM and the additional elements and
attributes in this "XForms Basic". I just don't buy that. Web authors who
lean to the graphic designer end of the spectrum do not like scripting (and
ours here, with a passion). Whereas we've got developers producing XForms,
who've had no previous experience of HTML, without any problems at all and
the whole approach is very natural to them.



Some specifics:

> "... field may have no value, in which case they aren't "successful", do
not take part in submission"
The concept of a null value is very important and does not mean "not
relevant". If I am editing an address form, how do I remove the contents of
a second address line when I move to a simpler address? So is the server
component supposed to understand that the absence of an element means
deletion? Which means the form and server are tightly coupled because the
server has to know exactly what fields are painted so it can perform
actions on elements it is not told about.

> Help attribute: "However, there is some doubt that this is actually a
useful feature."
Excuse me, of couse help is important when developing applications. Hints,
via a title attribute, are not good enough because there visibility is only
fleeting and requires the user to pause a while. You can't easily use hints
to provide links to more in depth information such as concepts, background
data and references. You can't use hints to take other data on the form and
suggest a suitable value for this field.

> Repeat
And this is supposed to be easier than XForms!

> Seeding a form with initial values
This does not address the concept of separation of presentation from data
because there is a one-to-one link between data and form controls. In other
words the HTML form is not a viewport on to the data.
There is no ability to load dynamic <option> data, other than via script.

> XML Submission
Yes, the data may be submitted as XML, but it is not in a particularly easy
structure to work with. The proposal is not very clear on nested repeats -
an example would help, but it looks like the concept of a hierarchy is
lost.
Nor is this scheme useful for interfacing with web services, who dictate
the XML vocabulary to use. Do you propose web services create another
interface based on this <submission><field /></submission> scheme?

> "... output control can be populated ... The semantics of this practice
are somewhat dubious..."
The concept of dynamic "boilerplate" text - text that has the appearance of
static text but is generated dynamically is very fundamental. Again it goes
to the separation of presentation and content.
However, as output controls are not in the submission data you lose some
round-tripping, which means the outputs to be preloaded should be in their
own form with a separate source.




Andy Heydon

Received on Friday, 5 December 2003 20:12:40 UTC