- From: Mark Baker <distobj@acm.org>
- Date: Wed, 25 Feb 2004 09:56:48 -0500
- To: Joe Gregorio <joe@bitworking.org>
- Cc: "'www-tag @ w3. org'" <www-tag@w3.org>
FWIW, I've thought long and hard about this for some time, and have recently had some first hand experience designing and implementing a new forms language[1]. One of my issues with forms and PUT/DELETE, is that unlike GET and POST, neither of those methods progress the hypermedia application(*). Another way of saying that, I think, is that POST can be parameterized (and GET too, though not necessarily so) such that the state to which the application transitions is a function of some input data separate from the set of representations available to the agent. But with PUT and DELETE, at any place in the application, an agent has the option of PUTting or DELETEing a resource independent of the particular application that it's participating in (i.e. unparameterized). I believe this explains why PUT and DELETE support can be (and typically *is*) handled "outside the browser window" (i.e. File->Delete, File->Save), but parameterized-GET and DELETE need "form buttons" inside the window. (*) note that since PUT and DELETE can both return response entities, they *could* be used to progress the application. But, I haven't yet seen an example where that makes sense, and as mentioned, believe that the semantics of those methods are consistent with them not doing so. But I don't know for certain that there isn't some value there, though I'm confident, based on my experience, that the value isn't anywhere near as high as you seem to be saying, Joe. [1] http://www.markbaker.ca/2003/05/RDF-Forms/ Mark.
Received on Wednesday, 25 February 2004 09:55:48 UTC