W3C home > Mailing lists > Public > www-tag@w3.org > January 2002

QUERY

From: Mark Baker <distobj@acm.org>
Date: Wed, 30 Jan 2002 12:51:51 -0500 (EST)
Message-Id: <200201301751.MAA11889@markbaker.ca>
To: timbl@w3.org (Tim Berners-Lee)
Cc: gtn@rbii.com (Gavin Thomas Nicol), w3c-forms@w3.org, www-tag@w3.org
> I suppose thedecision as to whether QUERY should be introduced or GET
> expended depends on how much they will share.

I'm not a big fan of a new method for submitting complex queries, nor
even extending GET to support a body if that body is in any way used to
change the meaning of the URI(*).  A query really should be identifiable
by a URI.  IMHO, if urlencoded syntax is insufficiently expressive for
some particular query then you could do this;

POST /query HTTP/1.1
Host: example.org
Content-Type; application/x-complex-query

[query goes here]

which would return;

HTTP/1.1 201 Created
Location: http://example.org/queries/12371232

A GET on that URI would return the query results.

I do see *some* value to a new method that is side-effect free and
carries a body, but I don't see it being used for queries.  I see it
being used for things like converting a document from one format to
another.  However, I don't see enough value in this over POST to justify
going to the effort of deploying it.

(*) I would consider using a body on GET iff it were used as a header,
such as if a SOAP envelope (minus the body - note to self, suggest to
XMLP to remove requirement for at least one body element) were there.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com
Received on Wednesday, 30 January 2002 12:49:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:04 GMT