Re: Intepretation: whenToUseGet-7

----- Original Message -----
From: "Paul Prescod" <paul@prescod.net>
To: "TAG" <www-tag@w3.org>
Sent: Tuesday, February 19, 2002 9:17 AM
Subject: Intepretation: whenToUseGet-7


> I'm having trouble interpreting the section of the IRC logs on this
> issue.
>
> > 1. GET should be encouraged, not deprecated, in XForms
> >
> > TBL: I think that the XForms WG didn't have any force behind
> > decision to deprecate GET, so this part is done.
>
> I don't know what that means. Is XForms merely supposed to take out the
> deprecation? Or are is this saying that they can't deprecate something
> from the IETF? Or ....?

Theer was aa consensus on the TAG that GET should be encoraged,
not deprecated ineth XForms spec.    The XForms spec invokes
HTTP in parts - it is under their control which HTTP methods the
XForms implementor must/should use.  The TAG consensus was that
for the XForms spec should call out the use of HTTP's GET whenever the
process had no side-effects.

No one is talking about XForms changing the IETF HTTP 1.1 spec to make
GET deprecated!

> > I propose we write this up as a hole in the architecture - the
> > parameters are ridiculous to represent as an identifier, but
> > it's nonetheless idempotent. There should be something just
> > like POST but with QUERY to tell the proxy that there are no
> > side effects.
>
> I could interepret this two ways. One is: "In general, XForms results
> will be structured as XML so they should use QUERY instead of GET. So
> the deprecation of GET is appropriate." Another interpretation is: "in
> some RARE cases the information to be processed will be very complicated
> and thus not amenable to mapping into the identifier namespace and in
> those RARE cases it makes better sense to use QUERY."

This was a personal comment by me in the meeting.  I am not sure that
 it is the right way to go.  Theer are good reaons for and against.
The reasons for include that when a query is for examplel the schema
validation
of a literal document, then the query URI s as long as the document
contents,
which may just not scale.  It may not be sound engineering to save the
entire contents of documents in URIs.  Resons against generating Query
include that it might be used when GET would have done fine, and
the "use GET" rule would have been broken, and a perfectly good
bookmarkable resource lost to the web.

> I am very nervous about undercutting the URI namespace. As TimBL said:
>
> "URIs are the lynchpin of the Web arch"
>
> The vast majority of safe, idempotent forms can and should be mapped
> into the URI namespace.


I absolutely agree, and the TAG is I think in consensus there.

> Furthermore POST can turn *on* caching.
> Therefore I see the benefits of QUERY as being minor, especially when
> judged against the potential confusion it will cause when people start
> using it instead of GET for things that could have been mapped to
> identifiers.

Good point.  It isn't just a question of turning on caching.
It is a fundamental change in the user operation from making a
commitment to not making a commitment.   I woudl like
to see browsers use a different pointy hand icon for GET and POST.
If we consistently used a form of POST which had no side effects, it would
have the cursor shape like "GET" links.

As HTTP1.1 says, "In particular, the convention has been established that
the GET and
   HEAD methods should never have the significance of taking an action
   other than retrieval. These methods should be considered "safe." This
   allows user agents to represent other methods, such as POST, PUT and
   DELETE, in a special way, so that the user is made aware of the fact
   that a possibly unsafe action is being requested."

That difference would have to be pulled out so that the c;lient and server
are
aware of it *before* the operation.  Yes, the server can turn on caching by
responding
with a document with an expiry date, but that feature doesn't allow the
client to say,
with the POST, "I am doing this on the understanding that I am not commiting
myself to anything and I will be responsible for no side-effects".
To add this functionality would need either a new method or reliance on
a Mandatory extension header using HTTP extensions.

I think some folks might misread my choice of term "QUERY" as maning only
database-query-like thinsg (small) --maybe FUNCTION or
FUNCTNCTIOnwithREALLYbigARGUMENTS would be better
As far as I am concerned, the this is not a decided isuue because of these
tradeoffs.

Tim


>  Paul Prescod
>

Received on Tuesday, 26 February 2002 11:27:59 UTC