W3C home > Mailing lists > Public > www-forms@w3.org > February 2001


From: Nic Ferrier <nferrier@tapsellferrier.co.uk>
Date: Tue, 06 Feb 2001 03:59:35 +0000
Message-Id: <sa7f76f3.060@tapsellferrier.co.uk>
To: www-forms@w3.org
The current working draft asks for comments about whether the
traditional data passing system should stay for XForms.

I would like form-urlencoding to stay. I realise there are a number
of problems and that it doesn't perfectly fit your spec but it has one
major advantage over the 2 methods you are proposing: it is very

Both fast in terms of transfer (there is little extra weight in the
protocol outside of the state) and in terms of development.

Argument #1
I develop webapps all the time, I write (on average) about 3 form
processors a day. It's my estimation that using a more complex
protocol for form parsing would knock off 2 of those per day.

The reason? Dynamic content systems (like servlet engines, PHP, CGI
etc...) are not going to support XForms from day one... I would have
to perform the processing of the form myself in many circumstances.

Argument #2
I see form-urlencoding as a RAD tool for XForms. As a developer I
will most likely spend some time figuring out interfaces and testing
them... that will probably be done with form-urlencoded forms. Once
the forms are more concrete more descriptive protocols will be used.

Argument #3
In environments where the connection latency must be as low as
possible form-urlencoding might also be advantagous. As I said above,
there is little overhead in the protocol.

Proper syntactic description is a worry... but it can be overcome of
course; a server which sent a document to a client would be able to
associate the returning data with the correct syntax thanks to the use
of XPath. The server would simply have to cache the descriptions of
the instance data and look up the descriptions when it recieved a
corresponding request; such processing would happen invisibly to the
user and the server might present a consitent API for forms-encoded
and other encoded requests.

This *may* be really usefull in some applications. For example, light
weight clients such as PDAs or "on body" network components might not
have the bandwidth to send other forms of data. In such environments
server processing power can compensate.


Nic Ferrier

Quickly about me:
Director of free software firm Tapsell-Ferrier Limited
Author of GNU-Paperclips servlet engine
Member of standardising team for the servlet API.
Currently working on a NG web browser incorporating XForms
Received on Monday, 5 February 2001 22:49:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:04 UTC