RE: updated findings on whenToUseGet

I certainly can't speak for the workgroup, but it's my impression that 
most of those who have been involved in discussing this issue understand 
why GET with a resource-identifying body is not a solution.  The whole 
purpose of any work on an HTTP/GET binding would be to ensure that URI's 
and GET are used in a manner consistent with both the letter and the 
spirit of the web architecture.  Furthermore, I would expect that the tag 
still has the option to non-concur with whatever might be proposed by the 
XMLP group, so I would expect that we all have a shared interest in coming 
to a mutually agreeable solution.  While I agree that your concern is 
legitimate, I'd be surprised if it were a problem in practice.   Thanks 
very much.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







"Larry Masinter" <LMM@acm.org>
Sent by: www-tag-request@w3.org
05/18/02 12:15 PM
Please respond to LMM

 
        To:     "'Dan Connolly'" <connolly@w3.org>
        cc:     <www-tag@w3.org>, (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        RE: updated findings on whenToUseGet


The updated "finding" still seems to assume that "GET with
body" has something to do with solving the problem of insuring
that important resources should be accessible via a URL. But
if the data to access the resource is in the body (or in any headers
or anywhere other than the URL itself), then the goal isn't
accomplished. There's no difference between POST and GET-with-body
as far as accomplishing the stated objective.


>    * All important resources should be identifiable by URI.
> + 
> +    In particular
> + 
> +      + using GET for safe operations (read, query, view, ask,
lookup, ...) on
> +        HTTP resources makes them identifyable by URI, while using
POST does
> +        not


Does not what? Maybe I am not reading your 'diff' notation correctly.


>      The content type "application/x-www-form-urlencoded" is 
> inefficient for
>      sending large quantities of binary data or text 
> containing non-ASCII


It's not exactly right to talk about a 'content type' when encoding data
in a URI. The awkward name 'application/x-www-form-urlencoded' was made
up for creating a MIME body that is encoded using the URI mechanism,
but for talking about the URI-encoding method, it's just the URI
encoding
method.

>  We expect these limitations to be address in future 
> specifications (@@e.g. XForms?) and deployed in due course.

It's not in the XForms charter to solve this problem, I don't think.

Received on Saturday, 18 May 2002 22:16:43 UTC