RE: x-www-form-urlencoded

>The current working draft asks for comments about whether the
>traditional data passing system should stay for XForms.

The wording could no doubt be clearer, but one issue in our published draft
is that the urlencoding specification is 'almost-but-not-quite' conventional
urlencoding. The main change is that slashes are placed in the field names,
like "/PersonName/PersonTitle=Mr"

Nic,

Would you consider your three arguments to apply even to our modified
urlencoding?
Do you forsee any compatibility problems with existing form processing?
Would "conventional urlencoding" (as implemented in browsers today) be
preferable?
If so, do you have any suggestions on how to provide the left-over
contextual information?

Thanks,

.micah


-----Original Message-----
From: Rob McDougall [mailto:RMcDouga@JetForm.com]
Sent: Tuesday, February 06, 2001 6:47 AM
To: www-forms@w3.org
Subject: RE: x-www-form-urlencoded


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.

Regards,
Rob

-----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
fast.

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.


Thanks


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 12:39:44 UTC