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

RE: x-www-form-urlencoded

From: Rob McDougall <RMcDouga@JetForm.com>
Date: Tue, 6 Feb 2001 09:47:00 -0500
Message-ID: <311000B0752ED211B61700805F0D6B090183986A@ottmail3.jetform.com>
To: www-forms@w3.org
I think the WG is pretty unanimous about retaining url-encoding.  The main
reason is for backwards compatibility with existing apps.  We want people to
be able to move up to an XForms client without having to alter their server
software and be able to run an XForms server application that still runs
with older browsers.

I think you can safely assume that url-encoded is here to stay.


-----Original Message-----
From: Nic Ferrier [mailto:nferrier@tapsellferrier.co.uk]
Sent: February 5, 2001 11:00 PM
To: www-forms@w3.org
Subject: x-www-form-urlencoded

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 Tuesday, 6 February 2001 09:47:48 UTC

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