Re: Background information on GET and XForms (was: GET should be encouraged...)

----- Original Message -----
From: "Paul Prescod" <paul@prescod.net>
To: <www-tag@w3.org>
Cc: "Micah Dubinko" <MDubinko@cardiff.com>
Sent: Monday, February 25, 2002 6:54 PM
Subject: Re: Background information on GET and XForms (was: GET should be
encouraged...)


> Micah Dubinko wrote:
> >
> > Not speaking on behalf of any Working Group or person but me...
> >
> > Yes.
> >
> > For sending XML or multipart/form-data serialized instance data, GET
makes
> > no sense.
> >
> > For sending application/x-www-urlencoded instance data, GET is the
logical
> > choice.
>
> I think that the HTTP way to think about it is: "what does the client
> want the server to do?" If you want it to get information for you, like
> a Google results page, then you use GET and
> application/x-www-urlencoded. If you want the server to accept and
> process information then you use PUT or POST and XML or
> multipart/form-data. You choose the syntax based on the semantics you
> are trying to achieve.


Paul, how do the semantics of the two things you described differ?
The google results page is exactly what happens when  "accepts and
processes data".

The web information space is enabled by the clinet never knowing, caring
or specifying "what the server does", only defining in some way what
information it wants.
Whenever the information retreival function is repeatable and has no side
effects,
then it is useful to reuse the input as a URI.

The only problem is when the URI gets really very long indeed.

> > I understand that there are proposals for flexible submitInfo processing
in
> > XForms, separating out the 'locator' portion from the 'body' section.
We'll
> > see what the Working Group approves.
>
> That sounds intriguing.
>
>  Paul Prescod
>

Received on Wednesday, 20 March 2002 08:25:23 UTC