Should we really care about legacy?

Hi,

XForms is presented as the successor of HTML forms. It is supposed to become
the next solution for forms on the web. A requirement is that there be
transition path from HTML forms to XForms. Because of this there are at least
two legacy links in the specification: HTML and HTTP. I wonder whether this
state of affairs is not going to restrain the evolution of XForms and if the
support of this legacy is worthwhile.

What would be a situation in which legacy could interfere with an XForms-based
solution? For example, a form created with XForms could produce form data which
can be processed with an existing active web-component. Such a form would have
to be flat for obvious reasons. I think it is unlikely that XForms would be
used for this for two reasons. First, something would have to be developed
anyway to produce the new form, so providing a new form data processor too
wouldn't be a real problem. Second, one could stick to HTML forms for this,
because the only added value of XForms left in this case is the separation of
form content and presentation. However, this can also be achieved with a naked
HTML form and a style sheet.

The most important reason for using XForms is that it can handle structure.
Because of this it will be possible to have master-detail relationships in
forms. In such a case, using a serialisation format which can be understood by
legacy systems doesn't make sense, because they would only understand the
encoding but not the content. I therefore think text/xml (or derived types) is
the only relevant format as a minimal requirement for an implementation.

The reason why we have this legacy is the strong web-orientation of XForms. In
my opinion the specification would have more value if it didn't refer to the
web directly, but only specified, in isolation, what is required if it is used
in a web context. XForms covers much more than browsers and web-servers. It is
the most interesting way to create forms applications in general.

XForms could be implemented, for example, as a GUI component. Such an
implementation could expose the whole form as a DOM tree. The application using
the component could then use DOM Events to interact with it. This means that
not even the submission method is fixed. The submitted content, however, is.
The application could register a handler for the submit event and use another
protocol than HTTP for the actual submission.

I think the central part of the specification should only cover behaviour and
content. Separate sections could explain how the data, which is to be
submitted, is serialised in the various contexts. Obvious contexts are plain
HTTP, SOAP over any protocol such as HTTP, SMTP, etc., and even IIOP. In the
latter case the action attribute of submitinfo could be a name from a CORBA
name space or a JNDI name of an EJB. These are just examples.

Regards,

Werner.
-- 
Werner Donné  --  Re BVBA
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be

Received on Friday, 25 January 2002 11:36:47 UTC